fail-closed-verification

What this skill does

# 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