Read ../_house-style/house-style.md, ../_house-style/finding-contract.md, and ../_house-style/active-testing.md before starting.
Boundary
Own failure handling, degradation, recovery, capacity safety, and operational detection. Use /paranoid-review for broad code correctness, /postmortem after an incident, /migration-review for transition safety, and /platform-ship for provider release evidence.
Remain read-only unless the user explicitly requests fixes. Do not generate load, interrupt dependencies, drain queues, or exercise failover against shared or production systems without exact authorization.
Review procedure
- Lock the target, revision, environment, traffic assumptions, and service-level objective if one exists.
- Trace the request, job, or event lifecycle across dependencies and stored state.
- Identify bounded and unbounded work, timeouts, retries, concurrency, queue growth, fan-out, and resource ceilings.
- Model dependency slowdown, outage, malformed response, duplicate delivery, restart, partial success, and recovery.
- Verify degradation behavior, idempotency, backpressure, reconciliation, and operator controls.
- Check whether telemetry detects user impact, cause, scope, and recovery—not merely component activity.
- Separate measured behavior from source-backed expectations and untested hypotheses.
Required failure analysis
- Most likely failure mode
- Most expensive failure mode
- Silent failure mode
For each, state trigger, propagation, detection, containment, recovery, and residual risk. Do not invent traffic, latency, capacity, or incident frequency.
Output
Operational path
Dependencies, state, queues, timeouts, retries, control points, and observability.
Findings
Use the shared finding contract. Prioritize corruption, silent loss, cascading failure, retry amplification, unbounded work, and unrehearsed recovery.
Degradation and recovery
Expected degraded mode, kill switch, in-flight behavior, reconciliation, recovery proof, and responsible role when known.
Evidence gaps
Name unmeasured runtime behavior and the smallest contained test that would establish it.
Verdict
- OPERATIONALLY SOUND — material failure paths are bounded, detectable, and recoverable with evidence
- NEEDS RESILIENCE WORK — the design is viable but required controls are incomplete
- INCIDENT RISK — a confirmed material failure path is unbounded, silent, or unrecoverable
- INDETERMINATE — required runtime or operational evidence is unavailable
End with What I did not verify.
1---2name: reliability-review3description: Evidence-backed reliability and operability review for services, distributed workflows, queues, scheduled jobs, integrations, and critical user paths. Use when evaluating timeouts, retries, backpressure, partial failure, degradation, alerting, recovery, capacity limits, or silent data and processing failures under real production conditions.4---56Read `../_house-style/house-style.md`, `../_house-style/finding-contract.md`, and `../_house-style/active-testing.md` before starting.78## Boundary910Own failure handling, degradation, recovery, capacity safety, and operational detection. Use `/paranoid-review` for broad code correctness, `/postmortem` after an incident, `/migration-review` for transition safety, and `/platform-ship` for provider release evidence.1112Remain read-only unless the user explicitly requests fixes. Do not generate load, interrupt dependencies, drain queues, or exercise failover against shared or production systems without exact authorization.1314## Review procedure15161. Lock the target, revision, environment, traffic assumptions, and service-level objective if one exists.172. Trace the request, job, or event lifecycle across dependencies and stored state.183. Identify bounded and unbounded work, timeouts, retries, concurrency, queue growth, fan-out, and resource ceilings.194. Model dependency slowdown, outage, malformed response, duplicate delivery, restart, partial success, and recovery.205. Verify degradation behavior, idempotency, backpressure, reconciliation, and operator controls.216. Check whether telemetry detects user impact, cause, scope, and recovery—not merely component activity.227. Separate measured behavior from source-backed expectations and untested hypotheses.2324## Required failure analysis2526- Most likely failure mode27- Most expensive failure mode28- Silent failure mode2930For each, state trigger, propagation, detection, containment, recovery, and residual risk. Do not invent traffic, latency, capacity, or incident frequency.3132## Output3334### Operational path3536Dependencies, state, queues, timeouts, retries, control points, and observability.3738### Findings3940Use the shared finding contract. Prioritize corruption, silent loss, cascading failure, retry amplification, unbounded work, and unrehearsed recovery.4142### Degradation and recovery4344Expected degraded mode, kill switch, in-flight behavior, reconciliation, recovery proof, and responsible role when known.4546### Evidence gaps4748Name unmeasured runtime behavior and the smallest contained test that would establish it.4950### Verdict5152- **OPERATIONALLY SOUND** — material failure paths are bounded, detectable, and recoverable with evidence53- **NEEDS RESILIENCE WORK** — the design is viable but required controls are incomplete54- **INCIDENT RISK** — a confirmed material failure path is unbounded, silent, or unrecoverable55- **INDETERMINATE** — required runtime or operational evidence is unavailable5657End with `What I did not verify`.
blakeox