easyinplay verify-progress workflow (v3)
Overview
3-phase sub-workflow mapping CLAUDE.md "Verify 阶段 — 必跑串行" 起点 onto harnessed runtime (Phase v3.0-3.4 W0.10 — D-04 Stage ④ Verify 7 sub + D-12 gstack 治理关卡 ref + Pattern A sub-workflow ship)。
| phase | id | upstream | model | capability / invokes | mode / artifacts |
|---|---|---|---|---|---|
| 1 | 01-gsd-verify-work |
gsd | sonnet | {{ capabilities.gsd-verify-work.cmd }} |
serial — UAT-driven acceptance |
| 2 | 02-gsd-progress |
gsd | haiku | {{ capabilities.gsd-progress.cmd }} |
serial — ROADMAP/STATE/REQUIREMENTS 同步 |
| 3 | 03-progress-update |
planning-with-files | haiku | {{ capabilities.planning-with-files.cmd }} + invokes: /plan |
artifacts_expected: [progress.md] |
Per-phase config loads from workflows/verify/progress/workflow.yaml; engine spawns each
phase as a sub-agent via @anthropic-ai/claude-agent-sdk 0.3.142+ in serial mode (顺序锁定 —
gsd-verify-work UAT 必先于 gsd-progress 状态同步)。
Capability refs
Sister workflows/capabilities.yaml entries:
gsd-verify-work— Bucket 2 special-purpose (impl: gsd, cmd: /gsd-verify-work)gsd-progress— Bucket 2 special-purpose (impl: gsd, cmd: /gsd-progress)planning-with-files— Bucket 4 核心 capability (impl: claude-code-plugin, cmd: /plan)
Routing rules (sister CLAUDE.md "Verify 阶段")
总 fire 当 phase.stage == 'verify' (sister workflows/judgments/stage-routing.yaml
verify-progress-always trigger)。无 skip 条件 — verify-work 起点必跑。
How to invoke
!harnessed checkpoint intent verify-progress
The banner above (when present) means this invocation is REGISTERED with the engine (an intent marker) — not yet compliant: the steps below (prompt → spawn → checkpoint complete) resolve it, and a per-turn
<workflow-intent>reminder persists until they run.
The numbered sequence below is the state machine — execute it with Bash. Do NOT improvise an equivalent flow from the Overview above: freelancing bypasses the engine (no ledger, no evidence guard). harnessed gives you the spawn-ready prompt; YOU spawn the subagent with a CC-native Task / Agent tool (keeps the session responsive + lets clarification round-trips reach the user).
Do NOT pipe to harnessed run verify-progress — that is the CI/headless path (in-process SDK spawn
that blocks the session inside Claude Code).
- Bash:
harnessed prompt verify-progress --task "$ARGUMENTS" --json→ parse{prompt, max_iterations, model}. - Spawn a CC-native subagent (Task / Agent tool) with that
promptandmodel, then drive delivery with harnessed's own completion gate:- on return, write the subagent's final output to a file and run
harnessed checkpoint complete verify-progress --result-file <path>— it is fail-closed on the declared artifacts, the TDD boundary, and the verbatim<promise>COMPLETE</promise>. - if it blocks, run
harnessed checkpoint fail verify-progress --failing-tests <n>to record the attempt; it prints BUDGET-EXHAUSTED / NO-PROGRESS / BREAK-LOOP when a stop condition is reached. - respawn ONLY while none of those three has fired. Any one of them means stop: re-scope the subtask, fix the blocker, or escalate to the user. Never respawn past a stop directive.
- on return, write the subagent's final output to a file and run
- If the output contains
STATUS: NEEDS_CLARIFICATION+ a question list: STOP, relay them verbatim via AskUserQuestion, append the answers to the spec, then re-spawn the same sub. - On
<promise>COMPLETE</promise>: write the subagent’s final output to a file, then Bashharnessed checkpoint complete verify-progress --result-file <path> --summary "<one-line>". Fail-CLOSED — it blocks unless every declaredartifacts_expectedfile exists, the TDD boundary passes (non-empty evidence / both the red and green sides present / the test file was not deleted), and the result carries a verbatim<promise>COMPLETE</promise>(or a structured COMPLETE status).--result <text>is the inline variant;--result-filewins and is quoting-safe on Windows.--forcerecords an audited override (evidence_status=overridden) — it does not silently pass. - If the complete gate blocked: Bash
harnessed checkpoint fail verify-progress --failing-tests <n>to record the attempt. It printsBUDGET-EXHAUSTED/NO-PROGRESS/BREAK-LOOPonce a stop condition is reached. Respawn ONLY while none of those three has fired; any one of them means STOP — re-scope the subtask, fix the blocker, or escalate to the user.
References
- D-04 Stage ④ Verify 7 sub 分解
- D-12 gstack 治理关卡 ref (verify-paranoid 后续 sub)
- workflows/capabilities.yaml — gsd-verify-work / gsd-progress / planning-with-files
- workflows/judgments/stage-routing.yaml — verify-progress-always trigger
- workflows/defaults.yaml — ralph_max_iterations.verify-progress.* values (W2.2 backfill)
- workflows/verify-work/workflow.yaml v2 SHIPPED phase 01-02 sister verbatim pattern