M4.2: the toolchain step
The preflight becomes the toolchain step (D3, as #135 describes it): a bounded run of the item's driver model, in a transcript of its own, that makes the build VM and the project's files agree. - Started by the harness when the VM isn't set up for the project (M4.1's checks): it sets the VM up from the repository and edits nothing there (no write_file; anything a command changed is reported, left for the work). - Requested by the driver with toolchain_step(reason) once work is agreed: it installs, then brings pins, setup docs and CI configuration in step; its edits land in the current milestone. The driver gets the step's report as the tool's result, not its turns. - D1 made structural: until the go-ahead the fast path refuses what it knows changes something (and anything dangerous), with a pointer to the restatement; unknown commands still go to the classifier, so a bug can be reproduced before it's restated. - A `toolchain` actor and view; the walk asks for steps now and then. 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
97ea451629
commit
d9f2ebd5aa
10 files changed
+283
-62
No files matched your search
@@ -402,7 +402,8 @@ needs; code makes sure that happens, bounds it and checks the result.
|
||||
without it), preflight runs on the driver's model, gaps don't block. Turning
|
||||
off unattended upgrades and the template's baseline are template choices.
|
||||
|
||||
**M4.2** *(revised with the operator: in place of recording installs).* The
|
||||
**M4.2** *(revised with the operator: in place of recording installs).*
|
||||
**Done** (this PR). The
|
||||
preflight becomes **the toolchain step** (D3): make the VM and the project's own
|
||||
files agree, with the repository as the record rather than a harness-kept one.
|
||||
- Started by the harness when the VM isn't set up for the project (M4.1's
|
||||
|
||||
@@ -195,9 +195,10 @@ looking around, not doing the work. Before M2.8 this was
|
||||
|
||||
### `tuning.preflight.max_turns` — default 20
|
||||
|
||||
How many model calls the toolchain preflight may make (D3). The preflight runs
|
||||
before the driver plans, whenever a project's build VM has no marker from a
|
||||
finished one: a new project, a new or wiped VM.
|
||||
How many model calls one toolchain step may make (D3). The harness starts one
|
||||
before the driver plans whenever a project's build VM has no marker from a
|
||||
finished one (a new project, a new or wiped VM), and the driver asks for one
|
||||
when the work needs a toolchain change.
|
||||
|
||||
- **Too low:** a project with several things to install doesn't finish, and
|
||||
says so; work goes on with what's missing stated, and the next item tries
|
||||
@@ -209,7 +210,7 @@ finished one: a new project, a new or wiped VM.
|
||||
|
||||
### `tuning.preflight.command_timeout_s` — default 900
|
||||
|
||||
The limit on one command during the preflight, in place of
|
||||
The limit on one command during a toolchain step, in place of
|
||||
`tuning.tools.command_timeout_s`: installing a compiler or a language runtime
|
||||
can take minutes. Commands in ordinary runs keep their own, shorter limit.
|
||||
|
||||
|
||||
Reference in new issue
Block a user