Incident Ledger
The incident ledger tracks problems and near-misses that should influence future planning.
Summary
Section titled “Summary”Incidents should identify what happened, severity, whether it was resolved, and what to recheck later.
Why This Matters
Section titled “Why This Matters”Near-misses are useful only if they remain visible. This ledger prevents safety and workflow risks from disappearing after a task completes.
Evidence Sources
Section titled “Evidence Sources”- Generated lessons
- Review history
- Harness docs
- Automation plan
What Happened
Section titled “What Happened”Known incidents and near-misses include CRLF test issues, STATE_SYNC self-reference, timeout misunderstanding, context loss, and source repo safety risks.
Decision / Lesson / Pattern
Section titled “Decision / Lesson / Pattern”Incidents should be retained even when resolved. The goal is not blame; the goal is future avoidance.
What To Preserve
Section titled “What To Preserve”- CRLF issues: normalize line endings when they are not behavior under test.
- STATE_SYNC self-reference: generated output must not become its own source.
- Timeout misunderstanding: synchronous proof routes are not production async architecture.
- Context loss: board history must supplement chat memory.
- Source repo safety risks: board automation must never write to
foryoutune-dev.
What To Recheck
Section titled “What To Recheck”- Whether resolved incidents have tests or process checks.
- Whether Phase 2 introduces new safety risks.
- Whether automation still preserves source boundaries.
Carry Forward
Section titled “Carry Forward”Use docs/history-templates/incident-record.template.md for individual incident records.