fix(execute): the progress prose validates clean
The progress file /trekexecute's prose described did not pass the command's own validator: run status in-progress and no partial, no plan_version (required), step status running and passed. Measured on the 4 real progress files: 3 used passed, 2 failed on plan_version. The prose now speaks the validator's vocabulary, site by site: schema (plan_version = the value Phase 2 parsed; run status in_progress|completed|failed|stopped|partial), fresh-mode warning, both resume rules, step start in_progress, step finish completed, the escalation staging rule, the Phase 7.5 commit count (status=completed - left alone, every successful run would read as drift and be overridden to partial) and the final write (adds partial; a sandbox-blocked run writes stopped, report result blocked). Untouched on purpose: plan_verification.status, session-state / NEXT-SESSION-PROMPT status, stats and report result, the tolerant session-orders reader list, Phase 2.6's running state. Valgt: tolerate a legacy passed on resume (one sentence after each resume rule) because Voyage is a public plugin and an in-flight run written under the old prose would otherwise re-execute finished steps. The validator gets no alias. Valgt: fresh mode also warns for stopped and partial - both are resumable, so they now get the --resume hint instead of a silent overwrite (intended behaviour change). Red: 3 of 5 new tests fail on the pre-fix text - SC4 (documented progress file validates 0/0 per run status), SC5 (offenders at trekexecute.md 1011, 1055, 1062, 1164, 1169, 1326, 1352, 1489), the legacy-sentence count. Regression guard and known-positive control green on arrival. Verify 125/125 (trekexecute-progress-schema, trekexecute, session-orders, criteria-runner, progress-validator). Suite 1388 (1386/0/2). Voyage order 20261005T104513Z-1250514346, plan step 4/5. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
parent
d5d121150e
commit
48abdb47d6
SSH key fingerprint:
SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q
2 changed files with 184 additions and 10 deletions
|
|
@ -1015,12 +1015,13 @@ progress file.
|
|||
"schema_version": "1",
|
||||
"plan": "{path}",
|
||||
"plan_type": "{plan | session-spec}",
|
||||
"plan_version": "{1.7 | 1.6 | legacy}",
|
||||
"started_at": "{ISO-8601}",
|
||||
"updated_at": "{ISO-8601}",
|
||||
"mode": "{execute | resume | step}",
|
||||
"total_steps": 0,
|
||||
"current_step": 0,
|
||||
"status": "{in-progress | completed | failed | stopped}",
|
||||
"status": "{in_progress | completed | failed | stopped | partial}",
|
||||
"steps": {
|
||||
"1": { "status": "pending", "attempts": 0, "error": null, "completed_at": null, "commit": null }
|
||||
},
|
||||
|
|
@ -1032,6 +1033,10 @@ progress file.
|
|||
}
|
||||
```
|
||||
|
||||
`plan_version` is the value Phase 2 parsed from the plan header (required by
|
||||
`progress-validator.mjs`). The status words here are the validator's:
|
||||
`PROGRESS_VALID_STATUSES` for the run, `PROGRESS_STEP_STATUSES` for a step.
|
||||
|
||||
**`plan_verification` (additive-optional):** written by Phase 7 when the input
|
||||
is a trekplan — `{status, summary, failed_criteria}`, where `status` is
|
||||
`"passed" | "failed" | "not-run"`. `null` for session specs (they have an exit
|
||||
|
|
@ -1052,14 +1057,15 @@ present in the spec at minimum — there is **no `(if wired)` conditional**.
|
|||
### Mode-specific behavior
|
||||
|
||||
**mode = execute (fresh):**
|
||||
- If a progress file exists with status `in-progress` or `failed`: warn that
|
||||
- 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.
|
||||
This allows headless runs to proceed without blocking.
|
||||
- Otherwise: create the progress file with all steps in `pending` status.
|
||||
|
||||
**mode = resume:**
|
||||
- If no progress file exists: start from step 1 (same as fresh execute).
|
||||
- If progress file exists: find the first step with status != `passed`.
|
||||
- If progress file exists: find the first step with status != `completed`.
|
||||
A legacy progress file may say `passed` for a finished step; treat it as `completed`.
|
||||
```
|
||||
Resuming from step {N}. {M}/{total} steps already completed.
|
||||
```
|
||||
|
|
@ -1161,12 +1167,13 @@ The core execution phase. Runs for modes: `execute`, `resume`, `step`.
|
|||
### Determine starting step
|
||||
|
||||
- **execute**: step 1
|
||||
- **resume**: first step where status != `passed`
|
||||
- **resume**: first step where status != `completed`.
|
||||
A legacy progress file may say `passed` for a finished step; treat it as `completed`.
|
||||
- **step N**: step N only
|
||||
|
||||
### For each step
|
||||
|
||||
Update progress: `steps.{N}.status = "running"`, `current_step = N`, `updated_at = now`.
|
||||
Update progress: `steps.{N}.status = "in_progress"`, `current_step = N`, `updated_at = now`.
|
||||
|
||||
```
|
||||
--- Step {N}/{total}: {description} ---
|
||||
|
|
@ -1324,10 +1331,10 @@ If **FAIL**, read the `On failure:` clause. Apply the retry cap: **maximum 2 ret
|
|||
Step {N}: ESCALATED — requires human judgment
|
||||
```
|
||||
Commit all completed work before stopping. Stage ONLY files from steps with
|
||||
`status: "passed"` in the progress file — collect their `Files:` fields. Never
|
||||
`status: "completed"` in the progress file — collect their `Files:` fields. Never
|
||||
use `git add -A` (risks staging secrets, binaries, or unrelated work).
|
||||
```bash
|
||||
git add {files from passed steps' Files: fields} && git commit -m "wip: trekexecute stopped at step {N} — escalation needed"
|
||||
git add {files from completed steps' Files: fields} && git commit -m "wip: trekexecute stopped at step {N} — escalation needed"
|
||||
```
|
||||
Jump to Phase 7.
|
||||
|
||||
|
|
@ -1349,7 +1356,7 @@ already passed) but is recorded as `checkpoint_drift: {expected_pattern,
|
|||
actual_message}` in the progress file. Phase 7.5 audit reports drift as
|
||||
an advisory.
|
||||
|
||||
Update progress: `steps.{N}.status = "passed"`, `steps.{N}.commit = {hash}`,
|
||||
Update progress: `steps.{N}.status = "completed"`, `steps.{N}.commit = {hash}`,
|
||||
`steps.{N}.completed_at = now`, `steps.{N}.manifest_audit = "pass"`.
|
||||
|
||||
### Step mode exit
|
||||
|
|
@ -1486,7 +1493,7 @@ produces an independent truth based on objective state, not self-narrative.
|
|||
|
||||
3. **Commit-count check:** count commits since session-start
|
||||
(`git rev-list --count {start_sha}..HEAD`). Expected count =
|
||||
number of steps with `status=passed` (excludes Step 0 if sandbox_preflight).
|
||||
number of steps with `status=completed` (excludes Step 0 if sandbox_preflight).
|
||||
|
||||
4. **Commit-message pattern sweep:** walk `git log {start_sha}..HEAD` and
|
||||
confirm each commit matches one of the declared
|
||||
|
|
@ -1714,7 +1721,9 @@ integrated result with `git log` on the current branch.
|
|||
|
||||
### Progress + state-file writes
|
||||
|
||||
Update progress file: `status` to `completed`/`failed`/`stopped`, `updated_at`, `summary`.
|
||||
Update progress file: `status` to `completed`/`failed`/`stopped`/`partial`, `updated_at`, `summary`.
|
||||
A sandbox-blocked run (Step 0 sentinel) writes run status `stopped`; its report
|
||||
result is `blocked`.
|
||||
|
||||
**Also atomically write `.session-state.local.json`** (Handover 7) at this
|
||||
convergence point — every successful, failed, stopped, or partial run that
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue