fail-closed-verification

Fail-Closed Verification

Before claiming any non-trivial work is complete, run structured verification that defaults to "not done" until proven otherwise. Narrative confidence ("I believe this works") is not evidence. Commands must be run, output must be checked, and findings must be explicit.

When to Use

• Before telling the user that implementation is complete
• Before creating a commit or PR for a feature/fix
• After a remediation cycle resolves findings
• Any time you are about to say "done" or "all tests pass"

Protocol

Step 1 — Run Tests

Execute the project's test suite (or the relevant subset). Record:

• The exact command run
• The full output (pass/fail counts, any failures)
• Whether coverage changed

If there are no tests, state that explicitly. Do not claim "tests pass" when no tests exist.

Step 2 — Parallel Verification (for non-trivial changes)

For changes touching 3+ files or involving logic changes, dispatch two agents in parallel:

Agent A — Code Reviewer (read-only):

Review the changes for correctness, edge cases, and consistency
with existing patterns. For each finding, provide:
- file:line reference
- severity (CRITICAL/HIGH/MEDIUM/LOW)
- specific concern (not vague)

If everything looks correct, state PASS with what you verified.

Agent B — Silent Failure Scanner (read-only):

Scan the changed files for silent failure patterns:
- Swallowed exceptions (empty catch blocks, bare except:pass)
- Missing error returns (function can fail but caller doesn't check)
- Unchecked null/undefined access
- Missing validation at system boundaries
- Race conditions or state mutation without synchronization

For each finding, provide file:line and the specific pattern.
If the code is clean, state PASS with what you scanned.

Step 3 — Evaluate

Result	Action
Both PASS with evidence	Work is verified. Proceed to completion.
Findings at HIGH+	Invoke resilient-flows:remediation-loop to fix, then re-verify
Findings at MEDIUM/LOW only	Note them for the user, proceed to completion
Either agent fails to provide evidence	Fail closed. Re-run or investigate.

Step 4 — Completion Statement

When reporting completion to the user, include:

• What tests were run and their results
• What verification agents found (PASS or specific findings)
• Any known limitations or deferred items

What "Fail Closed" Means

• If you can't run tests → do not claim they pass
• If a reviewer returns no evidence → do not assume PASS
• If you're uncertain whether a fix works → run it, don't reason about it
• If verification is skipped for any reason → explicitly state that to the user

The default state is "unverified." Evidence moves it to "verified." Nothing else does.

When to Skip

• Single-line typo fixes
• Documentation-only changes
• Changes the user explicitly says don't need verification
• Exploratory/research tasks with no deliverable