# Decisions Register

<!-- Append-only. Never edit or remove existing rows.
     To reverse a decision, add a new row that supersedes it.
     Read this file at the start of any planning or research phase. -->

| # | When | Scope | Decision | Choice | Rationale | Revisable? | Made By |
|---|---|------|----------|--------|-----------|------------|--------|
| D001 | M001-3hf5k0/S01 | architecture | Recover from the most recent valid backup rather than attempting raw SQLite page repair | Copy `.sf/backups/db/sf.db.2026-05-10T02-42-23-822Z` to `.sf/sf.db`, clear WAL/SHM files | The WAL file is 0 bytes (empty), meaning all committed transactions are in the main DB file. The corruption is in the main DB pages, not the WAL. The backup at 02:42 is ~3 hours old and contains the full planning state (M001-6377a4 with 5 slices, M002-f6fabd). Recovery from backup is faster and more reliable than page-level repair. | Yes — if a newer backup becomes available or if the page-repair approach proves more complete | agent |
| D002 | M001-3hf5k0/S01 | pattern | Keep the M001-3hf5k0 directory created by the autonomous bootstrap session as the working directory for this recovery milestone | Use M001-3hf5k0/ for M001-3hf5k0 milestone files; use M001-6377a4/ for recovered milestone files | The autonomous session created the M001-3hf5k0 directory structure at 05:56. Using it avoids creating duplicate directory entries. After DB recovery, M001-6377a4 becomes the active milestone from the DB and its roadmap files can be created in M001-6377a4/. The DB is authoritative for milestone identity. | Yes — if the M001-6377a4/ directory creation conflicts with other tooling | agent |
