fix(ultraplan-local): Bug 2 — eliminate state-file-path template; Read tool + concrete arg
Step 5 of v3.4.1 hot-fix plan. Phase 2 of
commands/ultracontinue-local.md is rewritten to remove every curly-
brace template placeholder. The {state-file-path} substitution failure
caused the path-guard hook to crash on unresolved templates.
New Phase 2 structure:
2.a — Read the file with the Read tool (no Bash). Deterministic and
not subject to shell-substitution errors.
2.b — Schema-validate via the existing CLI shim, with the resolved
absolute path emitted as a literal string token by the model
at the time of the Bash call. Anti-substitution invariant:
STOP if about to emit any unresolved placeholder.
2.c — Interpret validator result (preserved verbatim from the
previous Phase 2 — three-way branch on valid + status).
Verification: grep -c "{state-file-path}" returns 0; full Phase 2
section contains no {lowercase-template} curly-brace placeholders.
Suite 322 -> 335 passing (+13: 7 from Step 1, 4 from Step 2, 2 from
Step 4).
This commit is contained in:
parent
25c8faf113
commit
f58b892436
1 changed files with 34 additions and 10 deletions
|
|
@ -119,21 +119,45 @@ resumable state wins.
|
|||
|
||||
## Phase 2 — Validate the state file
|
||||
|
||||
Run the validator from a Bash invocation:
|
||||
Phase 1 resolved a concrete state-file path. That path is a real string in
|
||||
your working context — never a template. Phase 2 must read and validate the
|
||||
state file without any placeholder substitution.
|
||||
|
||||
```bash
|
||||
!`node lib/validators/session-state-validator.mjs --json {state-file-path}`
|
||||
### Step 2.a — Read the file with the Read tool (no Bash)
|
||||
|
||||
Use the **Read tool** on the resolved state-file path from Phase 1. Do NOT use
|
||||
Bash for the read. The Read tool is deterministic and not subject to
|
||||
shell-substitution errors. Parse the returned JSON body programmatically.
|
||||
|
||||
### Step 2.b — Schema-validate the parsed object
|
||||
|
||||
Verify the schema by invoking the existing validator CLI shim. Emit the
|
||||
resolved absolute path as a literal string token in the Bash command — the
|
||||
exact same string you just passed to the Read tool. The validator accepts
|
||||
`--json <path>` and prints a `{valid, errors, warnings}` JSON record:
|
||||
|
||||
```
|
||||
node lib/validators/session-state-validator.mjs --json <RESOLVED-ABSOLUTE-PATH-FROM-PHASE-1>
|
||||
```
|
||||
|
||||
Interpret the result:
|
||||
Replace `<RESOLVED-ABSOLUTE-PATH-FROM-PHASE-1>` with the actual path string at
|
||||
the time you issue the Bash call. There is no template engine; the string is
|
||||
substituted by you, the model, before the Bash tool sees the command.
|
||||
|
||||
**Anti-substitution invariant.** If you ever find yourself about to emit a
|
||||
literal angle-bracket placeholder, or any other unresolved variable name, to
|
||||
the Bash tool — STOP. The resolved path is a concrete value you already have
|
||||
from Phase 1; emit the value, not a placeholder for it.
|
||||
|
||||
### Step 2.c — Interpret the result
|
||||
|
||||
- **Validator exit code != 0 OR `valid: false` in JSON output:** print the
|
||||
structured `errors[]` (each `[code] message` on its own line) and exit. Do not
|
||||
proceed to narration. Suggest running the validator directly for follow-up:
|
||||
`node lib/validators/session-state-validator.mjs <path>`.
|
||||
- **`valid: true` AND any warning has `code: SESSION_STATE_NOT_RESUMABLE`** (i.e.
|
||||
`status: completed`): print "no further sessions to resume; project complete"
|
||||
and exit cleanly.
|
||||
structured `errors[]` (each `[code] message` on its own line) and exit. Do
|
||||
not proceed to narration. Suggest running the validator directly for
|
||||
follow-up: `node lib/validators/session-state-validator.mjs <path>`.
|
||||
- **`valid: true` AND any warning has `code: SESSION_STATE_NOT_RESUMABLE`**
|
||||
(i.e. `status: completed`): print "no further sessions to resume; project
|
||||
complete" and exit cleanly.
|
||||
- **`valid: true` AND status is one of `in_progress | partial | failed | stopped`:**
|
||||
proceed to Phase 3.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue