StartConceptsWorkflowsReferenceTroubleshoot

Verification And Completion Audit

Why Silver Bullet enforces silver:verify and silver:completion-audit as non-skippable gates — mapped to catalog atoms AF-VERIFY and AF-COMPLETION-AUDIT — what they check, and when they fire.

Overview

Silver Bullet enforces silver:verify 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 silver:verify, and prohibit accepting a completion claim from any skill without passing the SB completion audit. The completion audit hook enforces this mechanically — it blocks git commits and pushes if verification has not run.

What Verification Means

silver:verify performs goal-backward verification: it checks the actual outcome against the requirements and acceptance criteria defined in the SB 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 SB 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 silver:secure 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 after review and before security, final quality, and ship boundaries for every workflow that produces code changes:

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

Workflows where it is exempt or embedded

  • silver:fast — exempt from the full verification chain. Bounded fast-path work uses lightweight SB verification appropriate to its scope, and scope expansion escalates to the full workflow.
  • silver:deep-research — no code changes are produced; verification is replaced by the research synthesis and recommendation review step.
  • silver:release — silver:verify evidence is checked 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. After the review triad completes, silver:verify 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. Security 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 silver:verify 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. silver:review, framed by silver:review-request, checks code quality, security, and maintainability. Both must complete before ship — they cover different concerns and neither replaces the other.

Verify and Dual-Mode Quality Gates (AF-VERIFY / AF-QUALITY-GATE)

In Silver Bullet's APO composable-flow architecture, verification and quality posture map to two distinct catalog atoms:

  • AF-VERIFY (Verify) — the non-skippable verification gate. Runs silver:verify, SB test gap handling as-needed, and the SB completion audit. Produces UAT.md and VERIFICATION.md. Cannot be removed from any composition that includes AF-EXECUTE (Execute).
  • AF-QUALITY-GATE (Quality Gate) — dual-mode quality gate that appears twice in delivery workflows: 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 AF-VERIFY completes inside WF-POST-EXEC-GATES. Both instances must pass — all dimensions must pass in each.

The dual-mode design separates concerns: AF-VERIFY confirms functional correctness (tests pass, acceptance criteria met), while pre-ship AF-QUALITY-GATE confirms the full quality posture (security, scalability, maintainability, and six other dimensions) before any code reaches production. Legacy docs may label these as FLOW 12 and FLOW 13; use catalog IDs for new work.

See Also

← Previous Routing Logic Back to Core Concepts