Decision Ledger
The decision ledger tracks accepted decisions and the reasons they should remain visible.
Summary
Section titled “Summary”Decision records should include status, phase, scope, source, reasons, risks, and carry-forward targets.
Why This Matters
Section titled “Why This Matters”Decisions shape later implementation. Without a ledger, future work can accidentally reverse accepted constraints.
Evidence Sources
Section titled “Evidence Sources”- Generated decisions
- Source task records
- Review history
- Automation plan
- Harness docs
What Happened
Section titled “What Happened”Phase 1 accepted several durable decisions: gift-first product identity, provider isolation, controlled beta posture, board repo separation, read-only source checkout, and NotebookLM analysis-only exports.
Decision / Lesson / Pattern
Section titled “Decision / Lesson / Pattern”Accepted decisions should be treated as active until replaced by a newer accepted record.
What To Preserve
Section titled “What To Preserve”- Product decisions: gift-first experience, recipient-facing care, free beta before paid expansion
- Architecture decisions: provider isolation, async queue before production paid flows
- Provider decisions: Mureka-first MVP with replaceable provider boundary
- Workflow decisions: review gates, source clean checks, bounded tasks
- Automation decisions: board-side sync, read-only source checkout, generated exports
What To Recheck
Section titled “What To Recheck”- Provider fit after real usage
- Queue architecture before production
- Whether a decision has become deprecated
- Whether a future project should adapt instead of copy the decision
Carry Forward
Section titled “Carry Forward”Use docs/history-templates/decision-record.template.md for individual decision records.