`gsd-core/workflows/quick/steps/quick-verification.md` read the verifier's
result with `grep "^status:" F | cut -d: -f2 | tr -d ' '` and routed it through
a table whose only arms were passed / human_needed / gaps_found. That read
fails two ways. Driven against the old pipeline:
never written (verifier died) -> empty -> no arm
off-schema value -> weird_value -> no arm
`status:` in frontmatter AND prose -> two lines -> no arm
valid `passed` on a CRLF checkout -> passed\r -> no arm
stale report still reading passed -> passed -> SUCCESS
`status: passed` in the prose only -> passed -> SUCCESS
off-schema `passed:bogus` -> passed -> SUCCESS
The first four leave the orchestrating agent improvising at the moment the
pipeline failed. The last three are silent false passes: staleness was never
evaluated, the match was not anchored to frontmatter, and `cut -d: -f2` splits
an off-schema value at its own colon. The CRLF row is a pre-existing Windows
bug this change closes as a side effect.
The unanchored match is DEFECT.FRONTMATTER-SCALAR-BROAD-GREP, which the code
side already fixed by name — `readVerificationStatus` parses frontmatter only,
anchored at byte 0, and is total over its input space, returning `missing`,
`unknown` and `stale` sentinels. execute-phase.md, verify-work.md and
progress.md all read this same artifact through that query already; quick was
the remaining second mechanism.
Route quick's read through it and add an explicit terminal arm.
Three details a naive swap misses:
- The step file carries the runtime shim bootstrap itself. Step files are read
and executed as their own units, so quick.md's bootstrap does not reach here.
Copied byte-identically from gsd-core/workflows/_runtime-launcher.snippet.sh,
the source sync-runtime-launcher.cjs generates every workflow's copy from.
Without it the call resolves to nothing, 2>/dev/null swallows the error, and
the fix degrades to a permanently-taken recovery arm.
- No jq. `--pick status` returns the bare value. Per #2589 a `| jq -r` pipe
yields an EMPTY variable with no diagnostic wherever jq is absent — the
Windows/Git-Bash default — which here would route a passing verification into
the recovery arm, strictly worse than the grep being replaced.
- $VERIFICATION_STATUS is a DISPLAY string ("Verified" / "Needs Review" /
"Gaps") consumed at quick.md:619 and quick.md:684, not the raw status. The
raw value lands in $STATUS and the new arm sets both, so the failure path
does not emit an empty index-table cell.
next_action / next_command are deliberately not surfaced. readVerificationStatus
discovers and parses shape-agnostically, which is what makes the status half
correct for ${QUICK_DIR}; but it also reads the directory basename as a phase
token to build those commands, and a quick dir is `${quick_id}-${slug}` with a
date-derived quick_id — so the projection carries the date as a phase argument.
Quick supplies its own recovery actions instead.
Adds tests/fix-3174-quick-verification-status-read.test.cjs under
`allow-test-rule: source-text-is-the-product` (CONTRIBUTING.md's exception
matrix; the pattern tests/verify-work-auto-transition.test.cjs already uses for
verify-work's status-query ordering). It pins five properties: the query
replaces the grep, the bootstrap precedes the call, the bootstrap matches the
canonical launcher snippet, the status-read fence is jq-free, and the terminal
arm names all three sentinels and sets the display string. Verified as a
negative control against pre-fix next: 0/5 pass there, 5/5 here.
78330e505c