Architecture: the toolchain step (D3), and only looking before the go-ahead (D1)
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:
1 parent
33f9a75bac
commit
66c8ded409
2 files changed
+40
-7
No files matched your search
+27
-6
@@ -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
|
||||
|
||||
|
||||
Reference in new issue
Block a user