Build · Create · Engineering
Blameless post-incident review register
A root-cause register where each incident carries a why-chain, a stated root cause, and owned, dated corrective actions, so the same incident does not recur.
You receive: A structured RCA register (JSON) that passes the why-depth, root-cause, severity, and owned-dated-action checks.
Part of Keep App Running
Example
A sample of what this play produces. Your result is generated for your inputs.
- Team
- STUD.com platform (founder-operated)
- Period
- 2026-07-01 to 2026-08-17
Production 500s after a deploy shipped a schema.ts edit with no generated migration
- Incident Id
- INC-2026-273
- Severity
- critical
- Detected On
- 2026-07-09
- Why Chain
- Why did play pages return 500 in production? The app queried a column the production database did not have.
- Why was the column missing? The deploy shipped a schema.ts edit without its generated migration file, so the migrate step was a no-op.
- Why did the deploy proceed without the migration? Nothing in the gate compared the committed schema against the committed migration set.
- Why was there no such comparison? The deploy pipeline assumed authors always run drizzle-kit generate after a schema edit, a manual step with no enforcement.
- Why did the pipeline rest on a manual step? The migration workflow was adopted before the gate existed, and the gate was never extended to cover it.
- Root Cause
- The deploy pipeline relied on an unenforced manual convention (generate a migration with every schema edit) instead of a machine check, so a schema-only commit could reach production with a stale database.
- Corrective Actions
Action Owner Role Due Date Status Add check-schema-drift.mjs to the required gate so a schema.ts edit without a matching generated migration fails CI before merge. founder-operator 2026-07-10 done Run deploy-migrate.mts (migrate, then seed, then sync) as the first step of every production build so schema applies before new code serves. founder-operator 2026-07-12 done - Prevents Recurrence
- true
139 of 181 committed sample deliverables authored on the wrong model tier
- Incident Id
- INC-2026-0813-MODEL-POLICY
- Severity
- high
- Detected On
- 2026-08-13
- Why Chain
- Why were committed samples off-policy? The wave-harness producer agents ran on Sonnet instead of the Fable 5 authoring tier.
- Why did the producers run on Sonnet? The harness README that dispatched them named Sonnet as the producer model, and dispatchers followed it.
- Why did the README name the wrong model? It was drafted before MODEL-POLICY.md locked the authoring tier and was never reconciled against it.
- Why was the conflict not caught at dispatch? The fan-out prompt buried the tier choice inside a batch instead of stating model and effort up front for review.
- Why could a buried tier choice pass review? No result field recorded the producing model, so nothing downstream could flag the mismatch.
- Root Cause
- A harness document that contradicted the locked model policy stayed authoritative because dispatch prompts did not surface the tier choice and results did not record the producing model, leaving no point where the mismatch could be caught.
- Corrective Actions
Action Owner Role Due Date Status Pin the producer agent definition to Fable 5 at low effort so a dispatcher cannot override the authoring tier per batch. founder-operator 2026-08-14 done Require every result JSON to stamp production.model and production.effort, and reject results stamped off-tier at assembly. harness orchestrator 2026-08-15 done Re-author the mis-authored samples in policy-compliant waves and replace them in dev-deliverables.ts. founder-operator 2026-08-24 in-progress - Prevents Recurrence
- true
Parallel gate:local runs crashed vitest and reported RED with no failing test
- Incident Id
- INC-2026-GATE-CONCURRENCY
- Severity
- medium
- Detected On
- 2026-08-02
- Why Chain
- Why did the gate report RED? The vitest step exited nonzero without printing any failing test.
- Why did vitest exit nonzero? Two gate:local runs executed concurrently and contended for the same build and cache directories.
- Why were two runs concurrent? Multiple sessions operate on one clone, and nothing serialized the heavy gate across them.
- Why was there no serialization? The gate was designed for a single operator loop, and the multi-session working pattern arrived later without revisiting that assumption.
- Root Cause
- The gate assumed a single concurrent invocation per clone, an assumption the multi-session working pattern silently broke, so concurrent runs corrupted shared state and produced spurious REDs.
- Corrective Actions
Action Owner Role Due Date Status Document the serialize-heavy-gates rule (one gate:local at a time per clone; a RED with no named FAIL means re-run solo) in project memory and the gate runbook. founder-operator 2026-08-03 done Add a lockfile guard to gate:local that refuses to start while another gate run holds the lock. platform engineer 2026-08-28 open - Prevents Recurrence
- false
Opens soon
STUD opens runs for everyone soon, on every play at once.
Scope of the check
What's verified: STUD verifies the submitted register (JSON) is structurally complete: your minimum number of incidents, each with a unique id, a why-chain of at least the required depth, a stated root cause, a severity in your set, and the minimum owned, ISO-dated, status-tracked corrective actions. STUD does NOT judge whether the stated root cause is correct or whether the corrective actions will actually prevent recurrence; it checks the register's completeness.
Get early access to STUD the day it goes live.