verify-completion

name	verify-completion
description	Verifies implementations and fixes actually work by executing commands and observing real results. Never trusts claims. Use as the final quality check after implementation, after a bug fix, or when the user asks "is it done", "does it work", "verify this", or "confirm the fix".
version	1.0.0
modes	["fix","build","architect"]

Verify Completion

Run the code. Run the tests. Observe the results. Don't trust claims.

Core Principle: An implementation is not done when the agent says "done." It's done when evidence proves it works. Evidence means command output, test results, and observable behavior — not descriptions of what should happen.

When to Use

As the final gate (Gate 5) after spec compliance, constitution compliance, code quality, and hallucination checks have all passed. Also after any bug fix, before declaring the fix complete.

Process

Step 1: Run All Tests

Execute the full test suite. Not "I believe the tests pass" — actually run them.

Capture: exact command executed
Capture: complete output including pass/fail counts
Capture: any warnings or skipped tests

ALL tests must pass. If any test fails, the verification FAILS — even if the failing test is unrelated to the current change (you may have introduced a regression).

Step 2: Run Specific Acceptance Criteria

For each acceptance criterion in the spec:

• Execute the verification command or scenario
• Capture the actual output
• Compare against expected output

If the spec says "API returns 200 with user.id in body," actually call the API and inspect the response. Don't just read the code and conclude it would work.

Step 3: Verify Edge Cases

For FIX mode:

• Reproduce the original bug scenario. It must NOT reproduce.
• Verify the fix doesn't break related functionality.

For BUILD mode:

• Test the happy path AND at least one error path.
• Verify the feature works end-to-end, not just in isolation.

Step 4: Produce Result

GATE: verification
RESULT: PASS | FAIL

EVIDENCE:
  Test suite: [X] passed, [Y] failed, [Z] skipped
  Command: [exact command run]
  Output: [relevant output excerpt]

ACCEPTANCE CRITERIA:
  ✓ [criterion 1] — Verified: [evidence]
  ✓ [criterion 2] — Verified: [evidence]
  ✗ [criterion 3] — FAILED: expected [X], got [Y]

ACTION: none | fix-and-retry | escalate-to-human

Rules

• NEVER say "tests should pass" — run them and report what happened.
• NEVER say "I verified it works" without showing the command and output.
• NEVER skip verification because "it's a small change." Small changes cause outages.
• NEVER mark verification PASS if any test fails, even "unrelated" ones.
• If you can't run the verification (missing tool, environment issue), report it as BLOCKED, not PASS.

Failure Modes

• Tests pass but feature doesn't work: Tests are incomplete. Write a new test that captures the actual failure, then fix.
• Can't run tests (environment issue): Report BLOCKED with details. Do NOT skip verification. Help resolve the environment issue first.
• Flaky test fails: Not acceptable. Flaky tests are bugs. Investigate with systematic-debug skill. Don't re-run and hope.