Rework the Development Plan around live testing and the revised architecture
CI / checks (push) Skipped
CI / checks (pull_request) Successful in 1m16s

SSH execution and the agent as a container image come first (Phase 1),
then the new loop as a thin end-to-end slice, widened milestone by
milestone with a live run after each. Outline, Vikunja and per-agent VMs
are gone; the vault, the infrastructure repository and the agent host
replace them. The survey and issue map are refreshed.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE
This commit is contained in:
dongarandClaude Opus 5.5 committed 2026-10-02 19:41:48 +00:00
1 parent b7f1f3371c
commit 7b5f0dfd18
1 file changed
+164 -237
+164 -237
View File
@@ -1,314 +1,241 @@
# Nisse — Development Plan # Nisse — Development Plan
**Status: proposed for discussion.** How to get from the code as it is to the full **Status: agreed (PR #84); reworked in PR #92 after the architecture revision (PR #90).** How
architecture in `docs/Architecture.md`, in what order, and how each step is to get from the code as it is to the architecture in `docs/Architecture.md`, in
accepted. The architecture says *what and why*; this document says *how and when*, what order, and how each step is accepted. The architecture says *what and why*;
and is revised as work lands. this document says *how and when*, and is revised as work lands.
It follows the format the architecture asks agents to use (D2): phases of **The priority is live testing.** Work is ordered so the agent runs live against
milestones, each with a goal, scope and acceptance criteria, and each marked real resources as early and as often as possible, and what each run finds steers
**pre-approved** or **needs discussion**. what comes next.
--- ---
## 1. Where we are ## 1. Where we are
A survey of the code on `main` (2026-09-30) against each architecture section. A survey of `main` (2026-10-02) against the architecture. **Done** means it exists
**Done** means it exists and matches the architecture; **partial** means something and matches; **partial**, something exists but needs changing; **none**, not
exists but needs changing; **none** means not started. started.
Only `nisse-dev` has real code (about 10,000 lines in `nisse-dev/src/nisse_dev/`). Only `nisse-dev` has real code; `nisse-core` and `nisse-ops` are placeholders.
`nisse-core` and `nisse-ops` are placeholder packages.
| Section | Status | Notes | | Section | Status | Notes |
|---|---|---| |---|---|---|
| **P** Principles | — | Guidance; each milestone below applies them | | **L1** Work model | partial | Work items table with an active pointer (M1.1); no issue intake, queue, parking or blocked items |
| **L1** Work model | partial | One work item at a time with a minted ID; but the state store is a single row (`agent_state`, `CHECK (id = 1)`), not a work-items table with an active pointer. No duties, parking or switching (only `nisse-ops` needs duties) | | **L2** Agent loop | partial | `control.py`, a fixed state machine with no-stranding, `stop`, `abandon`. Replaced by the new loop (Phase 2) |
| **L2** Agent loop | partial | `control.py`: a fixed state machine (arch → milestone gates → executing → PR open), with the no-stranding rule, `stop`, `abandon`, restart questions. To be replaced by the conversational loop | | **L3** Authority | partial | Revision binding and arrival stamping (`gates.py`); scope is still plan approval, not the issue and its conversation |
| **L3** Authority | partial | Revision binding and arrival stamping are done (`gates.py`, #74). Approvals are gates, not permissions; no pre-approved milestones, no trust dial | | **L4** Classifier | none | |
| **L4** Action classifier | none | | | **L5** Conversation | partial | Matrix transport, mentions, lenient commands; no threads, no question handling, little explanation |
| **L5** Conversation | partial | Matrix transport, mention handling, case-insensitive commands. Only the planner can ask (`ask_human`); no question handling, no explanations or progress prose, a misleading reply in `IDLE` | | **L6** Context | partial | Context fitting, per-role views and orchestrator facts (M1.2); no scope or agent memory |
| **L6** Context and memory | partial | Context fitting is done (`context.py`). The transcript isn't scoped per work item and has no attribution or orchestrator facts (#78). No scope or agent memory | | **L7** Canonical log | partial | Work item and actor on every event, `fact` (M1.1, M1.2); no `classifier_verdict`, `knowledge_retrieved` |
| **L7** Canonical log | partial | `canonical.py`: user, assistant, tool call/result, plan, gate, delegation, compaction events. Missing: work item and actor on every event, `fact`, `classifier_verdict`, `knowledge_retrieved` | | **L8** Durability | mostly done | WAL store, intents, boot reconciliation, PR adoption, comment redelivery; to move onto the new loop |
| **L8** Durability and recovery | mostly done | WAL store, intents, boot reconciliation, adopting a published PR (#75), comment cursors and redelivery (#68, #76), Quint model (`specs/`). Needs moving onto the new loop and the work-items schema | | **L9** Models and roles | partial | LiteLLM, delegation, `ask_expert`, eval capture; roles are still planner/executor, no capability profiles |
| **L9** Models, roles, helpers | partial | LiteLLM client and catalog, context budgets, delegation with passthrough and caps, `ask_expert`, tool-choice handling, eval capture. Roles are executor/planner/delegate/consultant with a frontier planner; no `driver`, no capability profiles, no driver-chosen escalation | | **L10** Knowledge vault | none | |
| **L10** Knowledge store | none | | | **L11** Injection | partial | Operator allowlists on every channel; no classifier |
| **L11** Prompt injection | partial | Operator allowlists on every channel; no classifier, no structured intake beyond Gitea's JSON | | **L12** Secrets, logging | partial | Structured state-change log; secrets in `.env`; no per-operation handout or redaction |
| **L12** Secrets, identity, logging | partial | Structured state-change log (`oplog.py`); secrets from `.env` files; no Vaultwarden, no LLDAP identity | | **L13** Execution | none | Tools run locally in the agent's process. The token leaks into the clone (#89) |
| **D2** Documents as workflow | none | Plans are posted to a Gitea issue; no project `ARCHITECTURE.md` or build plans in the repo | | **D1–D2** Workflow | none | Plans posted to a Gitea issue and gated; no issue intake, labels, or documents in the repo |
| **D3** Workspace | partial | Cloned once and reused as-is; no fetch, no fresh workspace, no preflight (#62, #27) | | **D3–D4** Workspace, git | partial | Idempotent publishing; no fresh workspace (#62), `git add -A` (#80) |
| **D4** Git and PRs | partial | Idempotent publishing (#75), committed work published (#63); `git add -A` sweeps in artifacts (#80); branches cut at publish from whatever `HEAD` is (#62) | | **D5** Review | partial | PR conversation comments only (#69), watch stall (#70) |
| **D5** Review and merge | partial | Review loop on PR conversation comments; inline comments unseen (#69); watch stall (#70); operator merges; no trust dial (#65) | | **D7–D8** Deployment, projects | none | Runs from a venv as a systemd unit on this box; one project in config |
| **D7** Deployment | none | Bring-up runs on this box as root; no VM, VLAN or egress policy | | **O**, **X** | none | No container image yet |
| **O** `nisse-ops` | none | | | `specs/` | done for now | `orchestrator.qnt` (current loop), `loop.qnt` (the architecture, #91) |
| **X** Deployment model | none | |
--- ---
## 2. The environment today ## 2. The environment today
**Supporting services** (X5) are installed and running: Matrix (Synapse), Gitea, - **Supporting services** (X5): Matrix, Gitea, LiteLLM, Vaultwarden, LLDAP with
LiteLLM, Vikunja, Outline, Vaultwarden, LLDAP with Authelia. Per-agent accounts and Authelia. The infrastructure repository exists in Gitea.
tokens are created as each agent needs them. So far `nisse-dev` has a Matrix test - **Local inference:** llama-swap on an RTX 4090 host (320 W cap). The benchmark
identity and room, a Gitea test account and sandbox repo, and dedicated LiteLLM (PR #55) chose `qwen3.8-27b` for local work.
keys. - **Models by role today:** executor `qwen3.8-27b`, planner and helper
`claude-opus-5-5`, expert `claude-haiku-4-5`. Phase 2 moves to driver and helpers.
**Local inference:** an RTX 4090 host, `inference-4090.garrett-hall.com`, running - **Bring-up** runs on this development VM (`scripts/bringup.sh`), against test
llama-swap (one model resident at a time), capped at 320 W. The executor benchmark resources: the sandbox repository, the test Matrix room, a budget-capped LiteLLM
(PR #55) chose `qwen3.8-27b` for `nisse-dev`'s local work. key; configuration in `/root/nisse-e2e/`.
- **A build VM for bring-up** is provided by the operator by hand until Terraform
**Models by role today** (`nisse-dev.example.yaml`): executor `qwen3.8-27b`, planner (Phase 6); the agent reaches it over SSH with a key from `/root/nisse-e2e/ssh/`.
and delegate `claude-opus-5-5`, consultant `claude-haiku-4-5`. Phase 2 moves to the
architecture's roles (L9): driver local, helpers frontier.
**Bring-up runs** happen on this box, against test resources: the sandbox repo, the
test Matrix room, a budget-capped LiteLLM key; configuration in `~/nisse-e2e/`.
--- ---
## 3. How we work ## 3. How we work
- **One PR per milestone,** usually. Every PR still starts with a short - **One PR per milestone,** each starting with a short implementation plan per
implementation plan per `CLAUDE.md`. For a **pre-approved** milestone that plan is `CLAUDE.md`. A milestone marked **needs discussion** starts with a design
a quick confirmation; a **needs discussion** milestone starts with a design discussion first.
discussion before any plan. - **Every change comes with tests,** through `scripts/check.sh`.
- **Every change comes with tests,** per `CLAUDE.md`, and runs through - **A live run follows each milestone that changes behaviour,** not just each phase:
`scripts/check.sh` (lint, format, unit and integration tests). a short bring-up run of what the milestone added. Findings are filed as issues and
- **The Quint model moves with the loop.** Any change to how the loop enters or either fixed before moving on or deliberately deferred.
leaves a waiting point updates `specs/`, and every counterexample is reproduced - **The Quint models move with the loop:** `orchestrator.qnt` while `control.py`
against the real code before it is fixed. runs, `loop.qnt` for the new loop, whose properties become tests as each piece
- **A bring-up run on this box ends each phase** where it can be run live. What it lands (Phase 2).
finds is filed as issues and fixed before the next phase starts, or explicitly - **`control.py` gets fixes only,** and only for what blocks a live run. New
deferred. behaviour goes into the new loop.
- **Bring-up runs on this development VM,** as root, like production. Guards: it - **Bring-up runs on this box as root,** against test resources only, with today's
touches only test resources, and keeps today's structural gates on in its gates on until the classifier and trust dial are proven (Phase 3).
bring-up configuration until the classifier and trust dial are proven (Phase 3). - **This plan is revised as we go,** in the same PR as the work that changes it.
- **This plan is revised as we go:** a milestone's scope may move once work shows
its real shape, recorded here in the same PR.
--- ---
## 4. Phases ## 4. Phases
### Phase 0 — Housekeeping ### Phase 0 — Housekeeping (done)
**M0.1 Retire the old spec.** *Pre-approved.* **Done.** **M0.1 Retire the old spec.** **Done.** **M0.2 A bring-up script.** **Done.**
- Update every section reference in code, tests, `specs/` and the `CLAUDE.md` and
`README.md` files from the old spec's A–H to the new letters.
- Delete `docs/Architecture-Build-Spec.md` (git keeps it), and the old-to-new
section table this plan carried for the purpose.
- Acceptance: `grep` finds no reference to the old spec or its section numbers.
**M0.2 A bring-up script.** *Pre-approved.* **Done.** ### Phase 1 — Execution over SSH, and the agent in a container
- `scripts/bringup.sh`: set aside the previous run's state, workspace and log;
export the ref under test; start the agent as a systemd unit, so it outlives the
shell that started it; collect the log and a readable transcript
(`python -m nisse_dev.dump`) afterwards.
- The agent runs as root on this development VM, as it will on its own VM in
production (D7), so installing packages works as it will there.
- Acceptance: a smoke run starts, answers `status`, stops cleanly, and `collect`
produces the log and transcript.
### Phase 1 — Foundations the new loop needs **M1.1 Work items in the state store.** **Done.**
These fix problems found in the live runs that **survive the loop change.** Issues **M1.2 Transcript views.** **Done.** (#78 closes when a live run confirms it.)
that only exist because of `control.py`'s state machine (#61, #79, #81) are folded
into Phase 2's design instead of being fixed twice.
**M1.1 Work items in the state store.** *Needs discussion* (schema). **Done.** **M1.3 Execution over SSH.** *Pre-approved.*
- A work-items table with an active pointer (L1); every canonical event carries its - `execute(host, command, *, secrets, stdin)` as the only way to run anything; file
work item and its actor (L7). A migration for existing stores. tools over SSH; the host bound by the harness from the project (L13).
- Acceptance: two work items back to back keep separate state and events; a - The workspace lives on the build VM: cloned there, with no token in its
restart keeps both; migration tests. configuration; the push key handed to each push only (D4, #89).
- Every secret handed out is redacted from tool output (L12).
- Tests against a throwaway `sshd` container.
- Acceptance: the existing executor and delegation tests pass over SSH; a live run
of one milestone on the operator's build VM.
**M1.2 Transcript views.** *Needs discussion* (rendering). **Done.** **M1.4 Projects** (D8). *Pre-approved.*
- Per-role rendering (L6): a role sees only its work item, attributed entries, and - The project entry in configuration: repository, default branch, build VM, label
orchestrator `fact` events; never another role's raw turns as its own (#78). defaults, secrets by name with their visibility, egress additions.
- Acceptance: the second live run's confusion can't happen (a planning call after - Acceptance: the bring-up configuration is one project entry; a second project
a milestone contains the milestone fact and PR, and no executor turns). needs only a second entry.
**M1.3 A fresh workspace at `use`, and harness-owned branches.** *Pre-approved.* **M1.5 The agent as a container image.** *Pre-approved.*
- Fetch; clean checkout of the latest base; set aside anything left over and report - A Dockerfile for `nisse-dev`, stateless with a volume for state; a Gitea Actions
it (D3). Milestone branches cut by the harness from the task's workspace; workflow that builds it and pushes to Gitea's registry on each release tag (X4).
"changes to publish" counted from the milestone's start (D4). Covers #62 and the - `bringup.sh` runs the image instead of a venv.
clone-on-use half of #27. - Acceptance: a tagged release produces an image; a live run from the image.
- Acceptance: a leftover branch, uncommitted change and stale `origin` are each
handled and reported; a second milestone's PR contains only its own commits.
**M1.4 Publish only the work.** *Pre-approved.* **Phase 1 acceptance:** a live run, from the image, of a milestone and a review
- Standard excludes in the clone, and commit only what the work changed (D4, #80). comment on the build VM.
- Acceptance: a milestone that ran pytest publishes no `.pyc`; excluded files are
reported.
**M1.5 Review intake.** *Pre-approved.* ### Phase 2 — The new loop, as a thin slice first
- Inline review comments and review bodies (#69); no stall when a watch is
replaced from its own callback (#70); replies in the thread where the comment was
made (D5).
- Acceptance: tests for each; inline comments work in the phase's bring-up run.
**Phase 1 acceptance:** a bring-up run on the current loop with two milestones and Built alongside `control.py`, reusing the state store, log, views, publisher,
a review comment, including inline ones. pollers and recovery. The first milestone is the smallest end-to-end path; each
later one widens it and is followed by a live run.
### Phase 2 — The conversational loop **M2.1 The slice.** *Needs discussion* (the loop's shape in code).
- An issue assigned to `dev-agent` → a work item (D1); a restatement in the item's
thread; a go-ahead bound to its revision (L3, L5); one milestone through
`start_milestone` / `finish_milestone` on a harness branch (D4); the PR; a review
comment answered (D5); the merge; the item closed.
- Includes what carries over: a fresh workspace at item start and harness-owned
branches (D3, D4, #62); publishing only the work (#80); review intake, inline
comments and the watch stall (#69, #70); the review-fix check after merge.
- `loop.qnt`'s properties for these paths become tests.
- Acceptance: a live run of that path, plus a crash mid-publish.
Built **alongside** `control.py`, reusing the state store, canonical log, context **M2.2 The queue.** *Pre-approved.* Several items: states, park-and-switch with
fitting, publisher, pollers and recovery; `nisse-dev` switches over when the new branches pushed, next-item order, blocked items from Gitea dependencies, a closed
loop passes its tests and a bring-up run, and `control.py` is retired. PR handled (L1, D4). Live run with two issues and a dependency.
**M2.1 Loop design and its model.** *Needs discussion.* **M2.3 Threads and labels.** *Pre-approved.* Routing by thread, ambiguous commands
- A short design note (in the PR, then folded into the architecture where it asked about (L5); `bug` grace periods, `discuss`, `design`; questions and
settles something): the loop's turns, waiting points, pending questions, plain-language go-aheads (D1). Live run.
permissions it checks, and recovery. A new Quint model for it before code, with
the no-stranding, approval-binding and at-least-once properties carried over.
**M2.2 The loop core.** *Needs discussion.* **M2.4 Multi-milestone work and documents.** *Pre-approved.* Build plans in the
- The driver-driven turn loop (L2): conversation, tool calls, pending questions, repository, `ARCHITECTURE.md` kept current, waiting for merges between milestones
`stop`, `abandon`, intents and boot recovery on the work-items schema. (D2, D4). Live run of a two-milestone feature.
- **Questions never change state** (L5): the recognition rule is decided here (Q).
- Acceptance: the new Quint model's scenarios reproduced as tests; no-stranding
under injected faults, as `test_no_stranding.py` does today.
**M2.3 Roles and capability profiles.** *Pre-approved.* **M2.5 Conversations and new projects.** *Needs discussion.* Work started in
- Roles become `driver`, `helper`, `expert`, `classifier` (L9); capability profiles conversation, record issues carrying their item's ID, the new-project flow and its
in configuration, filled from the benchmark; the driver's prompt encourages asking project entry (D1, D8, #29). Live run of a small new project.
for help; observable escalation triggers; delegation and `ask_expert` wired to the
new loop. Supersedes #46 (separate architect and planner roles).
**M2.4 Conversation.** *Pre-approved* (the behaviour is set by L5). **M2.6 Roles and capability profiles.** *Pre-approved.* `driver`, `helper`,
- Explanations with plans and revisions, finished-work summaries, progress in prose `expert`, `classifier` (L9); escalation triggers; delegation and `ask_expert` on the
(#42), handling messages that can't be acted on yet, asking mid-work (#77). new loop.
**M2.5 Documents as the workflow.** *Needs discussion.* **M2.7 Conversation.** *Pre-approved.* Explanations, progress in prose, asking
- Project `ARCHITECTURE.md` and build plans in the repo, discussed and landed by PR; mid-work (L5, #42, #77).
milestones marked pre-approved or needs discussion and whether they change code;
permissions derived from them (L3, D2).
- Milestones and projects end properly: the plan declares its milestones; a
no-change milestone that wasn't meant to change code is done; moving on checks the
PR's state; finishing closes the issue (D4, D5). Supersedes #61, #79, #81.
**M2.6 Switch over and retire `control.py`.** *Pre-approved, after acceptance.* **M2.8 Switch over.** *Pre-approved, after acceptance.* `nisse-dev` runs the new
- `nisse-dev` runs the new loop; `control.py`, its tests and the old Quint model are loop; `control.py`, its tests and `orchestrator.qnt` are removed.
removed.
**Phase 2 acceptance:** a bring-up run: a new small project from conversation to an
agreed `ARCHITECTURE.md` and build plan, two milestones (one pre-approved), a review
comment answered, a question asked by the agent mid-milestone, and a crash
mid-review.
### Phase 3 — Authority ### Phase 3 — Authority
**M3.1 Action classes and the fast path.** *Needs discussion.* **M3.1 Action classes and the fast path.** *Needs discussion.* Harmless, contained
- Every tool action classified by effect (P3); static fast-path rules per agent and dangerous actions per agent (P3, D6), static fast-path rules.
(D6); the scope each class-2 action is checked against.
**M3.2 The action classifier.** *Needs discussion.* **M3.2 The classifier.** *Needs discussion.* L4, its model, fail-closed verdicts,
- L4, including the model choice (Q), fail-closed behaviour, logged verdicts, and overrides as an evaluation set.
operator overrides as an evaluation set.
**M3.3 Permissions and the trust dial.** *Needs discussion.* **M3.3 The trust dial.** *Needs discussion.* Per project (D8); agent merging behind
- Approvals as scoped permissions, the operator-set trust dial, and agent merging protection it can't satisfy, verified by a test (D4, D5, #65).
behind branch protection the agent can't satisfy, verified by a test (L3, D4, D5,
#65).
**Phase 3 acceptance:** a bring-up run with the classifier active and gates first
on, then deliberately loosened in the bring-up configuration.
### Phase 4 — The environment ### Phase 4 — The environment
**M4.1 Toolchain preflight.** *Pre-approved.* Detect what the project needs, check **M4.1 Toolchain preflight, M4.2 recording installs, M4.3 environment repair.**
it, and install what's missing before planning; toolchain facts in the transcript *Pre-approved.* All on the build VM (D3).
(D3).
**M4.2 Recording installs.** *Pre-approved.* Every package or toolchain the agent ### Phase 5 — Memory
installs is recorded as a fact and in the project's scope memory, so the
environment can be rebuilt; recurring ones are noted for the VM image (D3, X4).
**M4.3 Environment repair.** *Pre-approved.* The driver may clean caches and **M5.1 The vault.** *Pre-approved.* The folder, per-agent mounts, control tools,
reinstall project dependencies within a task, and reports it (D3). atomic writes and provenance (L10).
### Phase 5 — Memory and knowledge **M5.2 Agent memory** (*needs discussion*) and **M5.3 scope memory**
(*pre-approved*): when notes are written and read, verbatim corrections (L6).
**M5.1 The Outline client.** *Pre-approved.* Per-agent Outline user and token, **M5.4 The operator's copy.** *Pre-approved.* Syncthing, directions per folder.
collections and documents by ID, revision reads, one writer per document (L10).
**M5.2 Agent memory.** *Needs discussion.* When notes are written and read, the ### Phase 6 — Production
index, verbatim corrections (L6).
**M5.3 Scope memory for repositories.** *Pre-approved.* Project documents read at **M6.1 The agent host.** *Needs discussion.* Containers, volumes, snapshots,
work-item start and snapshotted; summaries at close (L6). per-agent networks (X1, X2, X4).
### Phase 6 — `nisse-dev` in production **M6.2 Build VMs by Terraform.** *Needs discussion.* The template, VLAN and egress
(D7, X2), collection when idle.
**M6.1 The VM, VLAN and egress policy.** *Needs discussion.* D7, X1, X2. **M6.3 Secrets and identity.** *Pre-approved.* Per-agent secret sets on the host,
LLDAP principal (L12).
**M6.2 Secrets and identity.** *Pre-approved.* Vaultwarden machine accounts, LLDAP **M6.4 Delivery.** *Pre-approved.* Watchtower, restarts gated on an idle flag (X4).
principal, secrets out of `.env` files (L12).
**M6.3 Images and delivery.** *Pre-approved.* Gitea Actions → OCI registry → **M6.5 The browser tool.** *Pre-approved.* On the internal test network (D7).
Watchtower, restarts gated on an idle flag (X4).
**M6.4 The browser tool.** *Pre-approved.* Playwright on the internal test network
only (D7).
### Phase 7 — `nisse-core` and `nisse-ops` ### Phase 7 — `nisse-core` and `nisse-ops`
**M7.1 Extract `nisse-core`.** *Pre-approved.* A package split within the monorepo: **M7.1 Extract `nisse-core`.** **M7.2 MCP servers** (#37). **M7.3 Approved step
what both agents use moves into `nisse-core`. sequences** (O2). **M7.4 Ops intake and duties** from the infrastructure
repository (O5). **M7.5 The ops tool VM and deployment** (O6). **M7.6 Requests
**M7.2 MCP servers.** *Needs discussion.* Per (service, site, privilege) instances, between agents:** `nisse-dev` asking for build VMs (L1, O5). All *needs discussion*
tool profiles, configuration (X3, #37). except M7.1.
**M7.3 Approved step sequences.** *Needs discussion.* The ops plan format, matcher,
policy file, expiry (O2).
**M7.4 Tickets and duties.** *Needs discussion.* Vikunja intake and approvals,
scheduled checks and alert intake as duties (O5, #33).
**M7.5 `nisse-ops` deployment.** *Needs discussion.* O6.
### Not yet scheduled ### Not yet scheduled
From the architecture's open questions (Q) and older issues, to be placed when From the architecture's open questions and older issues: filing issues from
their trigger arrives: conversation; stacked PRs; releases; `nisse-ops` issuing credentials; a server
- more than one active work item per agent; database; recovering the agent host (an ops issue); more than one active work item;
- vision for 3D design and video work; vision; one local model for every agent; several forges (#26); a room per project
- one local model for every agent, or agents taking turns on the inference host; (#28).
- several forges and projects (#26); a Matrix room per project (#28); creating a
project from scratch and who owns it (#29); one agent instance per project (#30);
- infrastructure as code for agent VMs.
--- ---
## 5. Open issues and where they land ## 5. Open issues and where they land
All 19 open issues, as of 2026-09-30: | Issue | Lands in |
- **11 land in a milestone** and stay open until it is done. |---|---|
- **4 are superseded** by the new loop's design. They only exist because of | #26 multiple forges | Not yet scheduled |
`control.py`'s state machine, so fixing them there would be thrown away. They are | #27 per-project state, clone on use | M1.3 (clone on the build VM), M1.4 (projects) |
closed, with a pointer to their milestone, when this plan is agreed. | #28 room per project | Not yet scheduled (threads, M2.3, may make it unnecessary) |
- **4 are not yet scheduled** and stay open until their trigger arrives. | #29 create a project from scratch | M2.5 (ownership settled by D4, D8) |
| #37 MCP servers | M7.2 |
| Issue | Status | Lands in | | #42 per-turn commentary | M2.7 |
|---|---|---| | #62 branch at execution start | M2.1 |
| #26 multiple forges | Not yet scheduled | | | #65 agent merges approved PRs | M3.3 |
| #27 per-project state, clone on use | Milestone | M1.1 (state), M1.3 (clone) | | #69 inline review comments | M2.1 |
| #28 room per project | Not yet scheduled | | | #70 watch stall | M2.1 |
| #29 create a project from scratch | Not yet scheduled | Ownership decision first | | #77 conversational agent | M2.3 (questions), M2.7 |
| #30 agent instance per project | Not yet scheduled | | | #78 transcript scoping and attribution | Done in M1.1, M1.2; closes after a live run |
| #33 Vikunja tickets | Milestone | M7.4 | | #80 build artifacts in PRs | M2.1 |
| #37 MCP servers | Milestone | M7.2 | | #89 token in the clone's `.git/config` | M1.3 |
| #42 per-turn commentary | Milestone | M2.4 |
| #46 architect and planner roles | **Superseded** | M2.3 (one driver, helpers) |
| #61 simpler milestone gating | **Superseded** | M2.5 |
| #62 branch at execution start | Milestone | M1.3 |
| #65 agent merges approved PRs | Milestone | M3.3 |
| #69 inline review comments | Milestone | M1.5 |
| #70 watch stall | Milestone | M1.5 |
| #77 conversational agent | Milestone | M2.2 (questions), M2.4 |
| #78 transcript scoping and attribution | Milestone | M1.1, M1.2 |
| #79 ending projects and milestones | **Superseded** | M2.5 |
| #80 build artifacts in PRs | Milestone | M1.4 |
| #81 no-change milestones | **Superseded** | M2.5 |
## 6. Implementation notes ## 6. Implementation notes