Architecture: the toolchain step (D3), and only looking before the go-ahead (D1)
CI / checks (push) Skipped
CI / checks (pull_request) Successful in 1m54s
CI / e2e (pull_request) Successful in 4m1s

D3's preflight and install recording become the toolchain step: a
bounded run of the item's driver model that makes the build VM and the
project's own files (pins, setup docs, CI configuration) agree, with
the repository as the record. The harness starts it when the VM isn't
set up for the project (and then it edits nothing in the repository);
the driver requests it once work is agreed, and its edits land in the
current milestone. Versions stay facts the harness reads itself; a
rebuilt VM's new host key is trusted only on the operator's word.

D1 gains the rule that until the go-ahead the agent only looks:
anything that changes something is refused by the fast path, so what
the work needs goes in the restatement.

The Development Plan's M4.2 follows: the toolchain step, in place of
recording installs.

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-08 17:18:30 +00:00
1 parent 33f9a75bac
commit 66c8ded409
2 files changed
+40 -7

No files matched your search

+27 -6
View File
@@ -591,6 +591,10 @@ mean, how it fits, its first step. Labels steer what happens next:
| `discuss` | Talks it through before anything |
| `design` | Agrees the design (D2) before any code |
- **Until the go-ahead it only looks:** reading and checking (versions,
builds, tests) run; anything that changes something is refused by the fast
path (P4). What the work will need, a toolchain change included, goes in the
restatement, so the go-ahead covers it.
- **It also talks first** when it finds the report unclear (it asks instead of
restating) or can't reproduce a bug. It never fixes a bug it couldn't see.
- **It never classifies an issue itself;** it may suggest a label. A missing label
@@ -672,15 +676,32 @@ at the latest default branch, and **set aside**, never silently discard, anythin
left over (uncommitted changes, local branches, unpushed commits), reporting it.
Build artifacts and caches in the workspace never survive into a new task.
**Toolchain preflight:** when the workspace is prepared, the agent determines what
the project needs and installs any gap **before any planning**; toolchain versions
become facts (L6).
**The toolchain step** makes the build VM and the project's own files agree: a
bounded run of the item's driver model that installs what the project needs and
keeps its pins, setup documentation (the README or wherever the project keeps it)
and CI configuration in step. **The repository is the record:** reviewed in PRs,
surviving any VM, and the same instructions a person cloning it would follow. It
starts two ways:
- **The harness starts it when the build VM isn't set up for the project** (new,
rebuilt or wiped, which the model can't know): before every run it checks the
VM's baseline, the workspace clone (cloned again if gone) and a per-project
marker that a finished step leaves. This step sets the VM up from the
repository and changes nothing in it; files out of step with reality are
reported, for the driver to act on.
- **The driver requests it** when the work needs a toolchain change, once the work
is agreed (D1); its edits land in the current milestone, so they are reviewed
with the work.
**Versions are facts the harness reads itself** (L6): it runs each tool's version
command (version commands only), checks them again before later runs and reports a
change, and a PR says what its work was tested with. **A rebuilt VM's new host
key** is trusted only on the operator's word.
**The build VM is the agent's to change:** installing packages and toolchains there,
cleaning caches or reinstalling dependencies to fix a broken build are contained,
reported but not asked about. Every install is recorded (as a fact and in scope
memory) so the VM can be rebuilt; recurring ones go into the template (X4).
Installing on any other host is dangerous.
reported but not asked about. Changes meant to last go into the repository's files
through a toolchain step; recurring ones go into the template (X4). Installing on
any other host is dangerous.
### D4. Git, branches and PRs