open/voyage
1
0
Fork 0
Code Issues Releases 13 Activity

fix: close the six defects an independent review found in the trial fixes

Browse source 
Independent read-only review of c56f852..2d29966 (2026-10-08), each defect
reproduced by the reviewer; each new test fails on that code.

- test-lock green ran ANY allowlisted command: `green --cmd "git status"`
  marked a red step green and the stop guard let it stop. The lock now
  stores the step's test command (`lock --cmd`); `green` runs only that
  one (a different --cmd, or a lock without one, exits 2). trekexecute D1
  calls `green` with no command, which also removes the quoting hazard.
- plan-gate --accept-open worked at round 1 and passed the gate; it now
  refuses while rounds are left.
- findings-schema --repo-root swallowed a following flag, or took a root
  that does not exist, and silently skipped the line check: exit 2.
- brief-review-stamp hashed only the body, so a changed `framing` or
  `research_topics` stayed "current"; it now covers the reviewed
  frontmatter too (only the post-review stamps are left out).
- red-proof red_kind read an assertion message naming SyntaxError as a
  load error; the signatures are now specific.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-10-08 07:17:45 +02:00
commit 5f9faeed4a
Signed by: ktg
SSH key fingerprint: SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q
12 changed files with 192 additions and 35 deletions
Download patch file Download diff file Expand all files Collapse all files

8
commands/trekexecute.md
View file

@ -1371,7 +1371,7 @@ runner prints TAP) says what the red was: `fail 1 of 1` on a node test file is
usually a load error, not a named failing test — say so in the step report.
**The test lock (K8).** After its red gate the helper runs
`node ${CLAUDE_PLUGIN_ROOT}/lib/util/test-lock.mjs lock --files {test files} --step {N}`;
`node ${CLAUDE_PLUGIN_ROOT}/lib/util/test-lock.mjs lock --files {test files} --step {N} --cmd "{Verify command}"`;
from then on the guard refuses Write/Edit/NotebookEdit on those files, so the
code moves to meet the test and never the reverse. The executor reads
`node ${CLAUDE_PLUGIN_ROOT}/lib/util/test-lock.mjs status` and records
@ -1492,10 +1492,12 @@ controller (Sub-step E) without the stop guard refusing every turn — the
test files stay locked against edits (operator decision 2026-10-08):
```bash
node ${CLAUDE_PLUGIN_ROOT}/lib/util/test-lock.mjs green --cmd "{Verify command}"
node ${CLAUDE_PLUGIN_ROOT}/lib/util/test-lock.mjs green
```
It runs the test command itself and marks only on exit 0; exit 1 (the test
It runs the test command the helper stored in the lock (`lock --cmd`), never
one given now, and marks only on exit 0; a lock without a stored command is
never marked (exit 2), so the stop guard keeps holding as before; exit 1 (the test
did not pass this time) is a finding for Sub-step F like a FAIL, exit 2 (could
not run) is never green. A step that is `"not-locked"` skips it.
If **FAIL**: the failure output is a finding for Sub-step F; still run D2 and