fix(execute): the step loop survives an adversarial review
An independent review of abc3083 found 15 defects, the two worst verified
in scratch repos. Each fix started with a test that failed.
- Proof of red could be "proven" by the environment: a start point
unpacked with git archive had no node_modules and no .git, so any test
failed there. The start point is now a git clone --shared checked out at
start_sha, gitignored top-level entries are linked in, and a control run
(start point + the change) must pass, or the result is not-run.
- The Test first file was never committed (the template lists it apart
from Files:) and leaked into the next step's diff. The step's scope is
now Files: + test files, staged at the checkpoint.
- New files outside Files: were invisible to every check. Every untracked
file is registered with --intent-to-add; a revert unregisters them.
- The floor guard paired renames (foo.test.js -> .bak read as clean) and
missed skipIf and node's t.skip/t.todo; prose files no longer count as
stubs.
- Phase 7.5 audited from the last step's start_sha; it now uses the run's
session_start_sha.
- The done line is written after the checkpoint and checked with --commit.
- fix_rounds never passes 5; attempts are never reset; re-control keeps
the spec/quality verdicts and earlier floor-guard rulings; the closed
stop list maps every existing stop; failed vs stopped made consistent;
the controller's effort is said, not assumed.
Tests: 1470 (1468 pass, 0 fail, 2 skipped).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
parent
382d5ccba2
commit
44dcc779a9
SSH key fingerprint:
SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q
11 changed files with 466 additions and 148 deletions
|
|
@ -1048,6 +1048,7 @@ progress file.
|
|||
"mode": "{execute | resume | step}",
|
||||
"total_steps": 0,
|
||||
"current_step": 0,
|
||||
"session_start_sha": null,
|
||||
"status": "{in_progress | completed | failed | stopped | partial}",
|
||||
"steps": {
|
||||
"1": { "status": "pending", "attempts": 0, "fix_rounds": 0, "start_sha": null, "report_path": null, "red_proof": null, "test_lock": null, "error": null, "completed_at": null, "commit": null }
|
||||
|
|
@ -1067,7 +1068,8 @@ a progress file without them still validates and resumes:
|
|||
|
||||
| Field | Written | Meaning |
|
||||
|---|---|---|
|
||||
| `steps.{N}.start_sha` | Sub-step 0 | the commit the step started from; every check reads `git diff {start_sha}` |
|
||||
| `session_start_sha` | Phase 3 | the commit the run started from; Phase 7.5 audits the whole run from it |
|
||||
| `steps.{N}.start_sha` | Sub-step 0 | the commit the step started from; every check of the step reads `git diff {start_sha}` |
|
||||
| `steps.{N}.report_path` | Sub-step 0 | the step's report file (helper rounds + the done line) |
|
||||
| `steps.{N}.red_proof` | Sub-step B | `"proven" \| "rejected" \| "not-run"` — the exit of `red-proof.mjs` |
|
||||
| `steps.{N}.test_lock` | Sub-steps B, G | `"locked" \| "released" \| "not-locked"` (K8) |
|
||||
|
|
@ -1102,6 +1104,12 @@ present in the spec at minimum — there is **no `(if wired)` conditional**.
|
|||
|
||||
### Mode-specific behavior
|
||||
|
||||
**Run start point (every mode that executes):** a fresh progress file records
|
||||
`session_start_sha` = `git rev-parse HEAD` before step 1; a resumed one keeps
|
||||
the value it has (a legacy file without it is backfilled with the parent of
|
||||
the first completed step's `commit`, or `HEAD` when none is completed). Phase
|
||||
7.5 audits the whole run from it — never from a step's own `start_sha`.
|
||||
|
||||
**mode = execute (fresh):**
|
||||
- If a progress file exists with status `in_progress`, `failed`, `stopped` or `partial`: warn that
|
||||
`--resume` is available, then wait 3 seconds (`sleep 3`) and start fresh.
|
||||
|
|
@ -1218,7 +1226,9 @@ Every stop names its class in the final report (Phase 8 `### Stops`).
|
|||
|
||||
1. **Something that cannot be undone.** A step or command whose effect cannot
|
||||
be reverted from git: deleting data outside the repo's tracked files, a
|
||||
migration against a live store, anything the plan marks irreversible.
|
||||
migration against a live store, anything the plan marks irreversible — and
|
||||
a dirty main checkout before a multi-session wave (Phase 2.55 Check 1:
|
||||
merging would lose the uncommitted work).
|
||||
2. **Something security-sensitive.** A command the executor denylist blocks
|
||||
(Phase 2.4, Sub-step D1), a write to a security-sensitive path (Hard
|
||||
rule 16), credentials or secrets in a diff.
|
||||
|
|
@ -1228,7 +1238,13 @@ Every stop names its class in the final report (Phase 8 `### Stops`).
|
|||
4. **A plan so broken that everything after it is guesswork.** The plan fails
|
||||
to parse, a ≥ 1.8 step has no `Test first:`, a step's own `On failure:
|
||||
escalate` fired (the plan's author declared that past this point is
|
||||
guesswork), or a step went up the fix ladder to the plan (Sub-step F).
|
||||
guesswork), a step went up the fix ladder (Sub-step F), the global
|
||||
iteration budget reached 0 — and the plan's own preconditions failing: an
|
||||
unmet entry condition (Phase 4), or the sandbox pre-flight exiting 77
|
||||
(Sub-step D1: the plan cannot be carried out where it runs).
|
||||
|
||||
Every stop the executor can make maps to one of these four; `stop_class` in
|
||||
the summary is that number.
|
||||
|
||||
Not on the list, and therefore never a stop: a failing test (that is a fix
|
||||
round), an ambiguity the plan leaves open (decide, and log it), a style
|
||||
|
|
@ -1311,8 +1327,11 @@ Treat this as an automatic `escalate`. Jump to the stop-and-report logic.
|
|||
The step's test is written first, and a command proves it red — never the
|
||||
model's word that "it failed first". This sub-step blocks: a step whose test
|
||||
is not proven red at its start point and green at its result does not pass.
|
||||
(A plan below 1.8 whose step has no `Test first:` skips it: `red_proof` =
|
||||
`"not-run"`, counted in the final report, never called proven.)
|
||||
|
||||
**The step's test files** are the `File:` paths under its `Test first:`. The
|
||||
plan template lists them apart from `Files:`, so everywhere below **the step's
|
||||
scope = its `Files:` + its test files**: both are built, both are committed at
|
||||
the checkpoint, and neither is a scope finding.
|
||||
|
||||
**The test command** is the step's `Verify:` command. It must be ONE
|
||||
test-runner invocation without shell operators (the allowlist of
|
||||
|
|
@ -1321,25 +1340,28 @@ with exit 2.
|
|||
|
||||
1. **The helper proves red before it builds** (Sub-step C): it writes the test
|
||||
from `Test first:`, runs the gate
|
||||
`red-proof.mjs --red-only --base {start_sha} --cmd "{Verify}" --tests {files}`
|
||||
`red-proof.mjs --red-only --base {start_sha} --cmd "{Verify}" --tests {test files, ONE comma-separated argument}`
|
||||
(the test must FAIL at the start point), locks the test files, and only then
|
||||
implements.
|
||||
2. **The executor proves it both ways after the helper returns:**
|
||||
```bash
|
||||
node ${CLAUDE_PLUGIN_ROOT}/lib/verification/red-proof.mjs --base {start_sha} --cmd "{Verify command}" --tests {Test first File paths, comma-separated} --json
|
||||
node ${CLAUDE_PLUGIN_ROOT}/lib/verification/red-proof.mjs --base {start_sha} --cmd "{Verify command}" --tests {test files, ONE comma-separated argument} --json
|
||||
```
|
||||
The test must FAIL against the start point (`start_sha` unpacked with
|
||||
`git archive`, the step's test files copied in) and must PASS against the
|
||||
result (the working tree). The start point holds tracked files only: add
|
||||
`--link node_modules` (or the repo's untracked dependency directory) when
|
||||
the test needs it.
|
||||
The test must FAIL against the start point and PASS against the result
|
||||
(the working tree), and a **control run** must PASS: the start-point copy
|
||||
with the step's whole change laid on top. The start point is a temp
|
||||
`git clone --shared` checked out at `start_sha` (a real git checkout), with
|
||||
the step's test files copied in and every gitignored top-level entry of the
|
||||
working tree (`node_modules`, `.venv`, …) linked in; `--link a,b` adds
|
||||
deeper dependency paths. A start point that fails for an environment reason
|
||||
fails the control too, so it is never read as red.
|
||||
|
||||
| Exit | `steps.{N}.red_proof` | Executor |
|
||||
|------|-----------------------|----------|
|
||||
| 0 | `"proven"` | continue |
|
||||
| 1, `not-red-at-base` | `"rejected"` | the test passes without the change, so it proves nothing: a finding for Sub-step F |
|
||||
| 1, `not-red-at-base` | `"rejected"` | the test passes without the change, so the TEST is wrong: a finding for Sub-step F, and that fix round is the one exception to the lock — the executor releases the step's test lock for it, the fix helper rewrites the test, passes the `--red-only` gate and locks again |
|
||||
| 1, `not-green-at-result` | `"rejected"` | the change does not make the test pass: a finding for Sub-step F |
|
||||
| 2 | `"not-run"` | never a pass and never proven. When the reason is the command (the `Verify:` is not one test-runner invocation) on a plan ≥ 1.8, the plan is what failed: the step goes straight up to the plan (Sub-step F, `fix_rounds = 4`, stop class 4). Any other reason (a missing test file, an unresolvable start point) is a finding for Sub-step F |
|
||||
| 2 | `"not-run"` | never a pass and never proven. **plan_version ≥ 1.8:** when the reason is the command (the `Verify:` is not one test-runner invocation), the plan is what failed: the step goes straight up to the plan (Sub-step F, `fix_rounds = 4`, stop class 4); any other reason (a missing test file, an unresolvable start point, a control run that stays red) is a finding for Sub-step F. **Below 1.8:** a step with no `Test first:`, or whose `Verify:` is not a test-runner command, is tolerated as `"not-run"` — counted in the final report among the steps without proof of red, never called proven; any other reason is a finding |
|
||||
|
||||
The exit code is the verdict, the output text is not. `base.tap` (when the
|
||||
runner prints TAP) says what the red was: `fail 1 of 1` on a node test file is
|
||||
|
|
@ -1363,10 +1385,15 @@ the step with the Agent tool:
|
|||
|
||||
Launch `subagent_type: "voyage:step-implementer"` with a short `description`
|
||||
("step {N}: {title}") and a prompt that carries, as files and values, not as a
|
||||
summary: the plan path, the step number, the step's text verbatim (every
|
||||
field, including `Interface in:`, `Interface out:` and `Review focus:` when
|
||||
present), `start_sha`, `report_path`, `mode: build`, and
|
||||
`voyage_root: ${CLAUDE_PLUGIN_ROOT}`.
|
||||
summary: the plan path, `plan_version`, the step number, the step's text
|
||||
verbatim (every field, including `Interface in:`, `Interface out:` and
|
||||
`Review focus:` when present), `start_sha`, `report_path`, `mode: build`, the
|
||||
round label (`build`, or `fix round R`), and `voyage_root: ${CLAUDE_PLUGIN_ROOT}`.
|
||||
|
||||
**A step at `fix_rounds` 5 is never built again** (Sub-step F): skip the
|
||||
launch and run only the checks (B, D1, D2, D3, E) on whatever the operator
|
||||
changed. A step at `fix_rounds` 4 on `--resume` was re-planned: launch a fresh
|
||||
`build` helper for the revised step.
|
||||
|
||||
- **Never pass the Agent tool's `name` parameter.** A named spawn becomes an
|
||||
`in_process_teammate`: it does the work, but its result never reaches this
|
||||
|
|
@ -1382,21 +1409,31 @@ present), `start_sha`, `report_path`, `mode: build`, and
|
|||
- **Wait for the helper to finish** before anything else; when it runs in the
|
||||
background, its completion notification is the signal. Never start the next
|
||||
sub-step or step while a helper runs.
|
||||
- `steps.{N}.attempts` = the number of helpers launched for the step (1 here).
|
||||
- `steps.{N}.attempts` += 1 for every helper launched for the step — this
|
||||
one, each fix round's, and the `build` helper after a re-plan. It is never
|
||||
reset, and every launch after a step's first also takes 1 from
|
||||
`iterations_remaining`, so the completion gate's reconciliation
|
||||
(`Σ (attempts − 1)`) holds across re-plans.
|
||||
|
||||
The helper's one-line answer is not evidence. After it returns:
|
||||
1. The report must exist at `report_path` with its `### Ran`, `### Saw` and
|
||||
`### Did NOT check` sections (a missing report is a finding for Sub-step F).
|
||||
2. Register the step's new files so the diff sees them: for each path in
|
||||
`Files:` that `git status --porcelain` shows as `??`, run
|
||||
`git add --intent-to-add {path}` (stages nothing).
|
||||
3. A changed path outside the step's `Files:` is a scope finding (Hard rule 2)
|
||||
for the controller. The executor does not revert it on its own.
|
||||
1. The report at `report_path` must carry a NEW section for this round
|
||||
(`## Step {N} - {round label}`) with its `### Ran`, `### Saw` and
|
||||
`### Did NOT check`; earlier rounds' sections and verdicts stay. A missing
|
||||
section is a finding for Sub-step F (stale sections do not count).
|
||||
2. Register EVERY new file so the diff and every check see it — not only the
|
||||
listed ones: for each path `git ls-files --others --exclude-standard`
|
||||
prints, run `git add --intent-to-add -- {path}` (stages nothing). A new file
|
||||
the step did not list is otherwise invisible to `git diff`, to the floor
|
||||
guard and to the controller. Voyage's own progress file and step reports
|
||||
are the one exception: never registered.
|
||||
3. A changed or new path outside the step's scope (`Files:` + test files) is a
|
||||
scope finding (Hard rule 2) for the controller. The executor does not
|
||||
revert it on its own.
|
||||
|
||||
**Rules the helper is held to** (its agent file carries them; the controller
|
||||
checks them in the diff): follow `Changes:` exactly — no improvising, no added
|
||||
scope; touch only the files in `Files:`; read `Reuses:` first; never weaken a
|
||||
test; never write a stub; never commit.
|
||||
scope; touch only the step's scope (`Files:` + test files); read `Reuses:`
|
||||
first; never weaken a test; never write a stub; never commit.
|
||||
|
||||
#### Sub-step D1 — Command verification
|
||||
|
||||
|
|
@ -1513,7 +1550,10 @@ every one with its ruling.
|
|||
— whatever they said — launch one controller with the Agent tool:
|
||||
`subagent_type: "general-purpose"`, `model: "opus"`, no `name` (Sub-step C),
|
||||
no `isolation`. It is a general helper with the prompt below, not a second
|
||||
Voyage agent. It reads the diff, not the helper's summary: it is never given
|
||||
Voyage agent. The Agent tool sets no reasoning effort, so the controller runs
|
||||
at the session's effort: run `/trekexecute` at effort `high` or above (the
|
||||
standard). A session below `high` is a decision-log entry ("controller ran at
|
||||
effort {level}"), never silent. It reads the diff, not the helper's summary: it is never given
|
||||
the step report, and it judges what changed, not what the helper says changed.
|
||||
|
||||
The prompt (fill in every `{…}`; pass the mechanical results verbatim as JSON):
|
||||
|
|
@ -1554,41 +1594,50 @@ parseable block is a failed control (a finding for Sub-step F), never a pass.
|
|||
Append both verdicts, the findings and `not_judged` to the step report.
|
||||
|
||||
**The round passes** only when ALL hold: `red_proof` is `"proven"` (or, below
|
||||
plan_version 1.8, `"not-run"` because the step has no `Test first:`), Verify
|
||||
PASS, manifest pass, every floor-guard finding ruled `justified` (and the guard
|
||||
plan_version 1.8, the tolerated `"not-run"` of Sub-step B), Verify PASS,
|
||||
manifest pass, every floor-guard finding ruled `justified` (and the guard
|
||||
ran), `"spec": "pass"` and `"quality": "pass"`. Then go to Sub-step G.
|
||||
Otherwise go to Sub-step F with every finding.
|
||||
|
||||
**Re-control after a fix** checks only what was fixed. A fresh controller gets
|
||||
the previous round's findings and the round's own change — before the fix
|
||||
round the executor saves `git diff {start_sha}` to
|
||||
`{report dir}/step-{N}-round-{R}.diff`, and afterwards hands over
|
||||
`diff -u` of that file against the new `git diff {start_sha}` — and answers,
|
||||
per previous finding, fixed or not, plus whether the round changed anything
|
||||
the findings did not name (that is a new finding). It does not re-judge the
|
||||
rest of the step.
|
||||
the previous round's verdicts, findings and floor-guard rulings, and the
|
||||
round's own change — before the fix round the executor saves
|
||||
`git diff {start_sha}` to `{report dir}/step-{N}-round-{R}.diff`, and afterwards
|
||||
hands over `diff -u` of that file against the new `git diff {start_sha}`. It
|
||||
answers in the SAME JSON block as above:
|
||||
- per previous finding, fixed or not — a finding not fixed stays in
|
||||
`findings`; whether the round changed anything the findings did not name
|
||||
(that is a new finding);
|
||||
- `"spec"` and `"quality"` for the step as a whole: the previous verdict
|
||||
carries over for every part the round did not touch, re-judged only where
|
||||
the round changed something;
|
||||
- `floor_guard`: a finding identical (same kind, file and text) to one the
|
||||
previous round already ruled keeps that ruling; only new floor-guard
|
||||
findings are ruled.
|
||||
It does not re-judge the rest of the step.
|
||||
|
||||
#### Sub-step F — Fix rounds
|
||||
|
||||
A failed round never loops sideways. **The fix rounds are capped at maximum 5 fix rounds per step, and they escalate upward** — to a fresh helper, then to
|
||||
the plan, then to the operator. The executor does not improvise a new design,
|
||||
and there is no ladder of cheaper models: every helper and every controller
|
||||
runs `opus` (Voyage runs no helper below Opus 5.5 High).
|
||||
runs `opus` (the step helper pins effort `high`; the controller follows the
|
||||
session's effort, Sub-step E).
|
||||
|
||||
| `fix_rounds` | Goes to | What happens |
|
||||
|---|---|---|
|
||||
| 1, 2, 3 | a fresh helper | Launch `voyage:step-implementer` again (no `name`, no `isolation`), `mode: fix`, with the findings (file, line, problem, fix) and the mechanical failures. It fixes only those; the tests stay locked. Then B (both ways), D1, D2, D3 run again and a fresh controller re-controls only what was fixed (Sub-step E). `attempts` +1; `iterations_remaining` −1 |
|
||||
| 1, 2, 3 | a fresh helper | Launch `voyage:step-implementer` again (no `name`, no `isolation`), `mode: fix`, with the findings (file, line, problem, fix) and the mechanical failures. It fixes only those; the tests stay locked (except in a `not-red-at-base` round, Sub-step B). Then B (both ways), D1, D2, D3 run again and a fresh controller re-controls only what was fixed (Sub-step E). `attempts` +1; `iterations_remaining` −1 |
|
||||
| 4 | the plan | **After three failed fix rounds the question is the architecture, not a fourth fix.** The step goes back to planning (below). Stop class 4 |
|
||||
| 5 | the operator | A step already sent to the plan (`fix_rounds` 4) that fails its control again after re-planning goes to the operator. The executor never builds this step again: on a later `--resume` it only runs the checks (B, D1, D2, D3, E) on whatever the operator changed. Stop class 4 |
|
||||
| 5 | the operator | A step already sent to the plan (`fix_rounds` 4) that fails its control again after re-planning goes to the operator. The executor never builds this step again: on a later `--resume` it only runs the checks (B, D1, D2, D3, E) on whatever the operator changed. If they fail again the step stays at 5 — there is no sixth round, `fix_rounds` never exceeds 5 — and the run stops again. Stop class 4 |
|
||||
|
||||
**Back to planning** (`fix_rounds = 4`): save `git diff {start_sha}` to
|
||||
`{report dir}/step-{N}-upward.diff` and write `{report dir}/step-{N}-upward.md`:
|
||||
the step verbatim, every round's findings and verdicts, and the question for
|
||||
the planner — which assumption in the step (its Changes, its Interface, its
|
||||
test) makes it fail. Then stop: step `failed`, run `stopped`, and tell the
|
||||
test) makes it fail. Then stop: step `failed`, run `failed`, and tell the
|
||||
operator to re-plan the step (`/trekplan` revises it) and run
|
||||
`/trekexecute --resume`, which launches a fresh `build` helper for the revised
|
||||
step and keeps `fix_rounds` at 4. A step whose proof of red cannot run on a
|
||||
step (`attempts` +1, `iterations_remaining` −1) and keeps `fix_rounds` at 4. A step whose proof of red cannot run on a
|
||||
≥ 1.8 plan because its `Verify:` is not one test-runner invocation goes here
|
||||
directly (Sub-step B).
|
||||
|
||||
|
|
@ -1600,9 +1649,13 @@ directly (Sub-step B).
|
|||
- When the step goes up (round 4 or 5), first save the upward files, then
|
||||
revert this step's changes (nothing of the step is committed yet):
|
||||
```bash
|
||||
git checkout -- {files from Files: field}
|
||||
git checkout -- {the step's tracked files changed since start_sha}
|
||||
git rm --cached -q -- {the step's new files: registered with --intent-to-add since start_sha}
|
||||
```
|
||||
Record failure. **Do NOT proceed to next step.** Jump to Phase 7.
|
||||
The new files stay on disk, untracked, and `step-{N}-upward.md` names them —
|
||||
nothing the step made is deleted, and none of it is left registered.
|
||||
Record failure. **Do NOT proceed to next step.** Jump to Phase 7.5 (Phase 7
|
||||
runs only when every step passed).
|
||||
|
||||
**`On failure: skip`**
|
||||
- Mark step as skipped at its first failed round, without fix rounds. Continue
|
||||
|
|
@ -1624,38 +1677,46 @@ directly (Sub-step B).
|
|||
```bash
|
||||
git add {files from completed steps' Files: fields} && git commit -m "wip: trekexecute stopped at step {N} — escalation needed"
|
||||
```
|
||||
Jump to Phase 7.
|
||||
Jump to Phase 7.5 (Phase 7 runs only when every step passed).
|
||||
|
||||
The same wip commit of completed work runs whenever a step goes up (round 4
|
||||
or 5). Release the step's test lock before stopping
|
||||
(`node ${CLAUDE_PLUGIN_ROOT}/lib/util/test-lock.mjs unlock`, `test_lock` =
|
||||
`"released"`), so the operator and the planner can edit the test.
|
||||
|
||||
#### Sub-step G — Done line, unlock, checkpoint
|
||||
#### Sub-step G — Checkpoint, done line, unlock
|
||||
|
||||
1. **The done line.** A step is done only when a script says so, and the script
|
||||
writes its line only when the test command exits 0:
|
||||
1. **Checkpoint.** Stage the step's scope — its `Files:` and its test files,
|
||||
and only those, never `git add -A` — then run the `Checkpoint:` git commit
|
||||
command exactly as written in the plan. (The test files are listed apart
|
||||
from `Files:` in the plan; staging only `Files:` would leave the step's
|
||||
test uncommitted and charge it to the next step's diff.)
|
||||
If the commit fails (nothing to commit, etc.): warn but do NOT fail the
|
||||
step. The step's verification already passed — the commit is bookkeeping.
|
||||
2. **The done line**, at the step's own commit. A step is done only when a
|
||||
script says so, and the script writes its line only when the test command
|
||||
exits 0:
|
||||
```bash
|
||||
node ${CLAUDE_PLUGIN_ROOT}/lib/verification/done-line.mjs --step {N} --cmd "{Verify command}" --report {report_path}
|
||||
```
|
||||
Exit 0 = `DONE step {N}: …` appended to the step report. Exit 1 = the test
|
||||
command failed after all: back to Sub-step F. Exit 2 = it could not run:
|
||||
never green — on a ≥ 1.8 plan that is the plan's `Verify:` (up to the plan,
|
||||
as in Sub-step B); below 1.8, a step whose `Verify:` is not a test-runner
|
||||
command records "no done line (Verify is not a test-runner command)" in its
|
||||
report and rests on Sub-step D1's exit code. Confirm with
|
||||
`node ${CLAUDE_PLUGIN_ROOT}/lib/verification/done-line.mjs --check --step {N} --report {report_path}`
|
||||
(exit 0 = present). Neither the helper nor the executor ever types a DONE
|
||||
line.
|
||||
2. **Release the test lock**:
|
||||
Exit 0 = `DONE step {N}: … exit 0 at {the checkpoint sha} …` appended to the
|
||||
step report. Confirm with
|
||||
`node ${CLAUDE_PLUGIN_ROOT}/lib/verification/done-line.mjs --check --step {N} --report {report_path} --commit {hash}`
|
||||
(exit 0 = the line names this step's commit). Neither the helper nor the
|
||||
executor ever types a DONE line.
|
||||
- Exit 1 = the test went red after the checkpoint (it passed in Sub-step E
|
||||
moments before: a flaky test or an order dependency). A finding for
|
||||
Sub-step F; the fix lands as a second commit with the same message, and
|
||||
Phase 7.5's commit count reports that extra commit as drift — said, not
|
||||
hidden.
|
||||
- Exit 2 = it could not run: never green — on a ≥ 1.8 plan that is the
|
||||
plan's `Verify:` (up to the plan, as in Sub-step B); below 1.8, a step
|
||||
whose `Verify:` is not a test-runner command records "no done line
|
||||
(Verify is not a test-runner command)" in its report and rests on
|
||||
Sub-step D1's exit code.
|
||||
3. **Release the test lock**:
|
||||
`node ${CLAUDE_PLUGIN_ROOT}/lib/util/test-lock.mjs unlock` → `test_lock` =
|
||||
`"released"` (a step that was `"not-locked"` stays so).
|
||||
3. **Checkpoint.** Stage the step's `Files:` — and only those, never
|
||||
`git add -A` — then run the `Checkpoint:` git commit command exactly as
|
||||
written in the plan.
|
||||
|
||||
If the commit fails (nothing to commit, etc.): warn but do NOT fail the step.
|
||||
The step's verification already passed — the commit is bookkeeping.
|
||||
|
||||
```
|
||||
Step {N}: PASS (committed: {hash})
|
||||
|
|
@ -1821,22 +1882,23 @@ produces an independent truth based on objective state, not self-narrative.
|
|||
2. **Filesystem check:** for each expected_path, confirm the file exists.
|
||||
|
||||
3. **Commit-count check:** count commits since session-start
|
||||
(`git rev-list --count {start_sha}..HEAD`). Expected count =
|
||||
(`git rev-list --count {session_start_sha}..HEAD`). Expected count =
|
||||
number of steps with `status=completed` (excludes Step 0 if sandbox_preflight).
|
||||
|
||||
4. **Commit-message pattern sweep:** walk `git log {start_sha}..HEAD` and
|
||||
4. **Commit-message pattern sweep:** walk `git log {session_start_sha}..HEAD` and
|
||||
confirm each commit matches one of the declared
|
||||
`commit_message_patterns` (in any order — order is advisory).
|
||||
|
||||
5. **Bash syntax sweep:** for every `.sh` file in
|
||||
`git diff --name-only {start_sha} HEAD`, run `bash -n`. Collect failures.
|
||||
`git diff --name-only {session_start_sha} HEAD`, run `bash -n`. Collect failures.
|
||||
|
||||
6. **Forbidden-path sweep:** for each `scope_forbidden` entry, check
|
||||
`git diff --name-only {start_sha} HEAD -- {path}` is empty.
|
||||
`git diff --name-only {session_start_sha} HEAD -- {path}` is empty.
|
||||
|
||||
7. **Done-line sweep:** for every step with `status=completed` that carries a
|
||||
`report_path`, run
|
||||
`node ${CLAUDE_PLUGIN_ROOT}/lib/verification/done-line.mjs --check --step {N} --report {report_path}`.
|
||||
`node ${CLAUDE_PLUGIN_ROOT}/lib/verification/done-line.mjs --check --step {N} --report {report_path} --commit {steps.N.commit}`
|
||||
(the line must name the step's own checkpoint commit).
|
||||
Exit 1 on a plan ≥ 1.8 = drift (`{check: "done-line", expected: "DONE step N", actual: "absent"}`);
|
||||
below 1.8 it is drift only when the step's report does not say why it has
|
||||
none (Sub-step G).
|
||||
|
|
@ -2213,8 +2275,8 @@ To continue (multi-session waves): re-run the same /trekexecute command (not --r
|
|||
Phase 7.6 recovery incomplete, OR the run is not verified end to end
|
||||
(Phase 7, gate clause 4)
|
||||
- `blocked` — Step 0 sandbox pre-flight exited 77; no real work attempted
|
||||
- `failed` — a step failed and On failure was revert/retry (retry cap hit)
|
||||
- `stopped` — On failure: escalate triggered
|
||||
- `failed` — a step failed and went up the fix ladder (On failure revert/retry: round 4 to the plan, or 5 to the operator)
|
||||
- `stopped` — On failure: escalate triggered, or another stop on the closed stop list (Phase 5.5)
|
||||
|
||||
**JSON summary block** (always at the end, machine-parseable):
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue