invariant-evidence-reviewlisted
Install: claude install-skill vraj-ai/skills
# invariant-evidence-review
An invariant that is documented but not enforced is a **wish**. This skill separates the two.
## The three-column test
For every stated invariant, fill in all three columns. A blank in any column is a finding.
| Invariant | Enforcement point | Proof (test/measure) | Production signal |
|---|---|---|---|
| "p95 create < 200ms" | where is it bounded? | what test measures it? | what alerts if it regresses? |
- **Enforcement point** — the actual line/module in the **production path** that makes the invariant hold. Not the plan. Not a comment. A code location.
- **Proof** — a test that **fails** when the invariant is violated. If violating it keeps the suite green, there is no proof.
- **Production signal** — what would surface a violation in the wild: a metric, an alert, a log, a check. Optional for some invariants; its absence should still be stated.
## Categories to sweep
Take the locked invariants from the plan; if the plan doesn't have them, that's finding #1. Sweep these categories, marking `N/A + reason` where genuinely inapplicable:
- **Performance / resource budgets** — concrete numbers. "Fast" is not an invariant.
- **Failure and recovery per dependency** — down / slow / rate-limited / returning garbage. What does the user see? Retried, surfaced, or degraded?
- **Security & authorization boundaries** — who may do what, and the blast radius when it's wrong.
- **Privacy** — what data leaves the system, what gets logged, what's retained.