mandao-verify

Prompt file imported from JuanGuzman-io/mandao (.github/prompts/mandao-verify.prompt.md). Fill in {{spec}} before use. Copyright stays with the author.

/mandao-verify

Budget: follow .mandao/templates/app/rules/budget.md at the start and at the end. Telemetry: follow .mandao/templates/app/rules/telemetry.md for event calls and categories.

Spec: {{spec}}

You verify that what was built is what the spec asked for, with evidence. Write the report in en. Never claim a test passed without its output.

1. Plan

1. node .mandao/bin/mandao.mjs run where {{spec}} --harness <this harness> --first "/mandao-verify {{spec}}" — if inWorktree is false, move into the worktree before any other step. Print the resume field of the where output (the command that opens this harness in the worktree) and stop.
2. node .mandao/bin/mandao.mjs run verify-plan {{spec}} gives the suites per project (unit over the files the spec's commits touched; e2e for the flows of its AC, critical ones always), missingRed (tasks with declared tests and no RED evidence), the runs deferred to CI, the trace findings and the blockers.
3. If blockers lists open tasks or uncommitted work, stop: verify comes after /mandao-implement.

2. Run, one Tester per suite

For each suite, a tester agent in a fresh context (it did not author the code):

• Unit: node .mandao/bin/mandao.mjs run tests <project> <files> — impacted tests only, under the resource budget.
• E2E: the flows of the suite's AC with the project's tests.e2e command; the full suite and the smoke of every critical flow run in CI, locally only with --full.
• Built binary or app: before testing what the project builds (a CLI, a bundle, an app), rebuild it with node .mandao/bin/mandao.mjs run build <project> — it respects the build memory floor and the test queue. If it says DEFERRED, do not force it: report that the built artifact was not re-checked (ADR 0026, Kaizen of MDO-0002: a stale build hid the real behavior).
• The Tester traces each test to its AC and clause, reads the gate logs the Leader left in _log/gates/ instead of asking for them again, re-runs the evidence, and labels a real failure PRODUCT_BUG with the evidence; it fixes only test defects and never weakens an assertion.

3. Report

Write verify-report.md from .mandao/templates/app/spec/verify-report.md, following .mandao/templates/app/rules/spec-docs.md and .mandao/templates/app/rules/doc-verify.md: the verdict as the summary, AC → tests clause by clause first (.mandao/templates/app/rules/traceability.md), then suites, TDD evidence (missingRed, changed red tests), the untagged security mentions from verify-plan (securityMentions, listed verbatim per task; they do not block, a person reads them), product bugs, deferred runs and the remaining blockers; commands and outputs only in ## Evidence. When the spec has a quickstart.md, bring its steps in line with what was built (.mandao/templates/app/rules/doc-quickstart.md). Then run the semantic Consistency Check (.mandao/templates/app/rules/consistency-check.md) over story, requirements, design and the report.

4. Status

• Any PRODUCT_BUG, failing suite or blocker → verdict: blocked; list what must be fixed and suggest /mandao-implement (a new task) or /mandao-quick when it is trivial.
• Otherwise node .mandao/bin/mandao.mjs run status {{spec}} verified (add --ci-confirmed only when CI confirmed every deferred run). If it is allowed, set status: verified in story.md and verdict: verified in the report. missingRed on a spec started before TDD (ADR 0022) is reported, not blocking.
• Either way, commit the report on its own: node .mandao/bin/mandao.mjs run commit-spec {{spec}} verify (a docs commit with Refs: <ID> and a fixed subject; never pushed).

Next: node .mandao/bin/mandao.mjs run next {{spec}} names the command that follows from the spec's state; give it, and if a fresh conversation would not be inside the worktree, give first the step back into it.