What happened
dotf spec review HARNESS-072-pr-stewardship printed:
[OK] Review running detached. Watch it with:
tmux attach -t review-HARNESS-072-pr-stewardship
When it finishes, review.md carries the verdict and archive reads it.
The launch had already died. What it actually left behind:
specs/HARNESS-072-pr-stewardship/review-transcript.jsonl — 0 bytes- no
review.md
- no tmux session (
tmux has-session → not running, seconds later)
- no error, anywhere, at any point
I found it only because I went looking for review.md before trusting the OK.
Root cause of the death (already ticketed) vs the defect here (not)
The death itself is #985: the launcher builds dotf secrets run -- pi … with no --only, so it resolves all 28 secrets and dies on one broken mapping (DOCKERHUB_TOKEN → an item that does not exist). That is one bug and #985 owns it.
This ticket is the other one: the launcher cannot tell a live review from a corpse, and defaults to announcing success. Scoping the wrapper fixes the current death but not this — a launch that dies for the next reason will print the same [OK]. The command's contract is "detached, come back later", so its success message is the only signal the caller gets, and right now that signal is emitted before anything has been confirmed to run.
Why this one matters more than it looks
This is the pattern-verification-fails-toward-unproven family, in the launcher HARNESS-071 hardened specifically against reviews that present as successes. #978 fixed a Gemini arm that wrote a well-formed all-A PASS having executed nothing; the bar became reach, not artifact. A launcher that reports OK for a process that never started is the same failure moved one layer out — and it is worse in one respect, because the archive gate's refusal ("no review.md") arrives much later and reads as "you forgot to run the review" rather than "the review you ran died".
Suggested fix
Do not print [OK] on the strength of tmux new-session returning 0. After launching, confirm the session is alive and the child actually started — e.g. poll tmux has-session plus a non-empty transcript for a couple of seconds — and fail loudly with the child's stderr when it is not. A dead launch should exit non-zero with the reason, not read as a queued review.
Cheap regression test: point the launcher at a command guaranteed to fail immediately and assert it exits non-zero and prints no OK line.
Reproduction (until #985 lands)
$ dotf spec review <any-spec-id>
[OK] Review running detached. …
$ ls -l specs/<spec-id>/review-transcript.jsonl # 0 bytes
$ ls specs/<spec-id>/review.md # does not exist
Found while implementing HARNESS-072 (#963, PR #986), whose own archive gate is blocked behind it.
What happened
dotf spec review HARNESS-072-pr-stewardshipprinted:The launch had already died. What it actually left behind:
specs/HARNESS-072-pr-stewardship/review-transcript.jsonl— 0 bytesreview.mdtmux has-session→ not running, seconds later)I found it only because I went looking for
review.mdbefore trusting the OK.Root cause of the death (already ticketed) vs the defect here (not)
The death itself is #985: the launcher builds
dotf secrets run -- pi …with no--only, so it resolves all 28 secrets and dies on one broken mapping (DOCKERHUB_TOKEN→ an item that does not exist). That is one bug and #985 owns it.This ticket is the other one: the launcher cannot tell a live review from a corpse, and defaults to announcing success. Scoping the wrapper fixes the current death but not this — a launch that dies for the next reason will print the same
[OK]. The command's contract is "detached, come back later", so its success message is the only signal the caller gets, and right now that signal is emitted before anything has been confirmed to run.Why this one matters more than it looks
This is the
pattern-verification-fails-toward-unprovenfamily, in the launcher HARNESS-071 hardened specifically against reviews that present as successes. #978 fixed a Gemini arm that wrote a well-formed all-A PASS having executed nothing; the bar became reach, not artifact. A launcher that reports OK for a process that never started is the same failure moved one layer out — and it is worse in one respect, because the archive gate's refusal ("no review.md") arrives much later and reads as "you forgot to run the review" rather than "the review you ran died".Suggested fix
Do not print
[OK]on the strength oftmux new-sessionreturning 0. After launching, confirm the session is alive and the child actually started — e.g. polltmux has-sessionplus a non-empty transcript for a couple of seconds — and fail loudly with the child's stderr when it is not. A dead launch should exit non-zero with the reason, not read as a queued review.Cheap regression test: point the launcher at a command guaranteed to fail immediately and assert it exits non-zero and prints no OK line.
Reproduction (until #985 lands)
Found while implementing HARNESS-072 (#963, PR #986), whose own archive gate is blocked behind it.