Verify QA

verify-qa workflow (v3)

Overview

5-phase sub-workflow mapping CLAUDE.md "Verify 阶段 — 可选 /qa" onto harnessed runtime (Phase v3.0-3.4 W0.13a — D-04 Stage ④ Verify 7 sub + D-12 gstack 治理关卡 + Pattern A sub-workflow ship; T2.3 三层职责矩阵 + 非功能性诊断 4 条 lane 接线)。

Per-phase config loads from workflows/verify/qa/workflow.yaml; engine 4-level gate resolver evaluates phase.has_ui_changes == true via expr-eval — true 则 invoke gstack /qa (端到端 QA 验收 + UI dogfood), false 则 skip。Phase 02-05 是三层职责矩阵 + 非功能性诊断的 4 条 lane, 由 subtask.test_type 单值互斥选择 — 无 test_type 信号时全 skip (只跑 01-qa)。

Capability refs

Sister workflows/capabilities.yaml entries:

• gstack-qa — Bucket 3 治理关卡 (impl: gstack, cmd: /qa, fires_when: has_ui_changes)
• browse — Bucket 2 special-purpose (impl: gstack user-skill, cmd: /browse — 手层主导)
• playwright-cli — Bucket 2 special-purpose (impl: npm-cli, browser_probe — 未装 gstack 时的降级)
• playwright-test — Bucket 2 special-purpose (impl: npm-cli, e2e_test typescript)
• webapp-testing — Bucket 2 special-purpose (impl: gstack, e2e_test python)
• chrome-devtools-mcp — Bucket 4 tool-mcp (impl: mcp, cmd: chrome-devtools — 有 provider 时 非功能性诊断必用; provider 二选一: ecc bonus tier 或 optional 自装 manifest,两者都缺则 该 lane 不 fire,由 gate fact chrome_devtools_available 强制)

Gate ref

Sister workflows/judgments/stage-routing.yaml:

• verify-qa-ui.fires — phase.stage == 'verify' and phase.has_ui_changes == true

Sister workflows/judgments/web-testing-routing.yaml (T2.3 — 4 条 lane 各接一个 gate):

• playwright-test-default.fires → phase 02
• browse-probe.fires → phase 03
• webapp-testing-python-backend.fires → phase 04
• chrome-devtools-mcp-diagnostic.fires → phase 05

Routing rules (bundled web-testing routing — workflows/judgments/web-testing-routing.yaml)

• 写测试 提交 repo / CI 跑 → @playwright/test (默认 frontend/e2e/*.spec.ts) — phase 02
• 探查 / 调试 / 一次性确认 → /browse 主导 (token 高效, 可复用 cookies 与会话状态); 未装 gstack 时降级 playwright-cli — phase 03
• setup 需 Python 后端 (Tortoise ORM / pandas) → webapp-testing skill — phase 04
• 性能 / a11y / 内存诊断 → provider 在场时必用 chrome-devtools-mcp (NOT playwright/test/cli/webapp-testing) — phase 05。 chrome-devtools 有两个 provider,且都是 optional:ecc plugin 或自装的 chrome-devtools-mcp server。两者都缺时本 lane 的 gate (chrome-devtools-mcp-diagnostic.fires 含 chrome_devtools_available == true) 为 false,phase 05 不 fire —— 不要去调一个不存在的工具,也不要用 playwright / webapp-testing 顶替它做非功能性诊断。 开启路径二选一(只装一个,双装会产生同名双前缀调用歧义): harnessed install ecc,或 claude mcp add chrome-devtools-mcp。 当前机器的实测值:harnessed facts verify 的 derived.chrome_devtools_available (source 字段写明原因与开启路径);harnessed doctor 的 ecc check 同样会报。

How to invoke

!harnessed checkpoint intent verify-qa

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-qa — that is the CI/headless path (in-process SDK spawn that blocks the session inside Claude Code).

1. Bash: harnessed prompt verify-qa --task "$ARGUMENTS" --json → parse {prompt, max_iterations, model}.
2. Spawn a CC-native subagent (Task / Agent tool) with that prompt and model, 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-qa --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-qa --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.
3. 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.
4. On <promise>COMPLETE</promise>: write the subagent’s final output to a file, then Bash harnessed checkpoint complete verify-qa --result-file <path> --summary "<one-line>". Fail-CLOSED — it blocks unless every declared artifacts_expected file 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-file wins and is quoting-safe on Windows. --force records an audited override (evidence_status=overridden) — it does not silently pass.
5. If the complete gate blocked: Bash harnessed checkpoint fail verify-qa --failing-tests <n> to record the attempt. It prints BUDGET-EXHAUSTED / NO-PROGRESS / BREAK-LOOP once 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 治理关卡可选
• workflows/judgments/web-testing-routing.yaml — 三层职责矩阵 (脑 / 手 / 筋骨)
• workflows/capabilities.yaml — gstack-qa / browse / playwright-cli / playwright-test / webapp-testing / chrome-devtools-mcp
• workflows/judgments/stage-routing.yaml — verify-qa-ui trigger
• workflows/verify-work/workflow.yaml v2 SHIPPED phase 05-qa-conditional sister verbatim