Help Center / Concepts / Verification Before Completion

Verification Before Completion

Why Silver Bullet enforces gsd:verify-work as a non-skippable gate, what it actually checks, and when it fires.

Overview

Silver Bullet enforces gsd:verify-work as a non-skippable gate before any workflow completes. This is a §3 rule — it cannot be waived via §10 preferences or the step-skip protocol. It applies unconditionally to every non-trivial workflow that produces code changes.

The rule exists because "done" in Silver Bullet means tests pass and behavior is confirmed — not "code was written." An implementation that isn't verified isn't done. Shipping unverified work is the most common source of regressions in AI-assisted development, and this gate is the primary defense against it.

Non-negotiable. Silver Bullet's §3 rules explicitly prohibit claiming work is complete without running gsd:verify-work, and prohibit accepting a completion claim from any plugin or skill without invoking /verification-before-completion with that claim. The completion audit hook enforces this mechanically — it blocks git commits and pushes if verification has not run.

What Verification Means

gsd:verify-work performs goal-backward verification: it checks the actual outcome against the requirements and acceptance criteria defined in the GSD plan, rather than checking whether the code looks correct in isolation.

What it checks

  • Test suite passes — the automated tests for the changed code run and pass with no failures
  • No regressions — the existing test suite continues to pass; nothing that worked before is now broken
  • Acceptance criteria met — the must-have truths from the GSD plan are verified against the actual output
  • Artifacts exist and connect — files created or modified are in the expected locations and contain expected content

What it does NOT mean

  • Manual QA or visual sign-off (that's a separate step if required)
  • Stakeholder approval
  • Performance benchmarking (unless that is an explicit acceptance criterion)
  • Security audit (handled by gsd:secure-phase and the Security dimension inside /silver:quality-gates)
Assumption is not evidence. A completion claim like "the tests should pass" or "this looks correct" does not satisfy verification. The test suite must actually run and the output must show a passing result. Silver Bullet requires observable evidence, not Claude's assessment of likelihood.

When It Fires

Verification fires as the penultimate step of every workflow that produces code changes, immediately before the ship step:

  • silver:feature — Step 8: gsd:verify-work (must pass before security review and ship)
  • silver:bugfix — after TDD regression test passes, gsd:verify-work confirms full suite
  • silver:ui — Step 11: gsd:verify-work after implementation; if coverage gaps remain, gsd:add-tests fills them before ship
  • silver:devops — gsd:verify-work runs against the IaC plan acceptance criteria

Workflows where it is exempt or embedded

  • silver:fast — exempt from the full verification chain. Tier 1 goes through gsd:fast; Tier 2 goes through gsd:quick with validation flags when needed. Both use lightweight GSD verification appropriate to their bounded scope, and scope expansion escalates to the full workflow.
  • silver:research — no code changes are produced; verification is replaced by the research synthesis and recommendation review step.
  • silver:release — gsd:verify-work still runs, embedded within the milestone audit step. Additionally, the full quality gates suite + UAT audit + milestone audit run as higher-level gates.

Examples

Example 1: silver:feature completes normally

You run /silver:feature Add email notifications for order status changes. The workflow reaches Step 8. gsd:verify-work runs the test suite — all 47 tests pass, including 3 new tests added for the notification feature. Verification produces a VERIFICATION.md file with pass/fail per acceptance criterion. The security review (Step 10) and ship steps are unblocked.

Example 2: silver:bugfix with TDD

You run /silver:bugfix Login form throws 500 on empty password field. After root cause is identified, a failing regression test is written first (TDD). The fix is implemented, the regression test passes. Then gsd:verify-work runs the full suite — no other tests regressed. The fix is considered done and ship is unblocked.

Example 3: Attempting to skip

After execution completes, you type "Skip verification and ship — I'm confident it works." Silver Bullet refuses. The step-skip protocol offers: A. Accept skip (not available for non-skippable gates) / B. Lightweight alternative / C. Show current test results. The only path to shipping is running verification. The completion audit hook will block any git push regardless of what is typed.

Why two-pass review loops also matter. Verification checks functional correctness. GSD code review, framed by /requesting-code-review, checks code quality, security, and maintainability. Both must complete before ship — they cover different concerns and neither replaces the other.

FLOW 11 VERIFY and Dual-Mode Quality Gates

In Silver Bullet's composable flows architecture, verification maps to two distinct paths:

  • FLOW 11 VERIFY — the non-skippable verification gate. Runs gsd:verify-work, gsd:add-tests (as-needed for coverage gaps), and superpowers:verification-before-completion. Produces UAT.md and VERIFICATION.md. Cannot be removed from any composition that includes FLOW 7 (EXECUTE).
  • FLOW 12 QUALITY GATE — dual-mode quality gate that appears twice in every composition: once as a design-time checklist before planning (8 core quality dimensions plus conditional gates), and once as an adversarial audit before shipping. The pre-ship instance runs after FLOW 11 VERIFY completes. Both instances must pass — all dimensions must pass in each.

The dual-mode design separates concerns: FLOW 11 VERIFY confirms functional correctness (tests pass, acceptance criteria met), while FLOW 12 QUALITY GATE pre-ship confirms the full quality posture (security, scalability, maintainability, and 6 other dimensions) before any code reaches production.

See Also

← Previous Routing Logic Back to Core Concepts