# Overdeck FIRE / Incident Evidence Harvest ## Purpose This corpus extracts operational lessons from Overdeck so AWP can prevent the same failure classes without inheriting Overdeck architecture. Overdeck is evidence, not architecture authority. The harvest is documentation-only. No Overdeck source/runtime/database was modified, and no AWP implementation or canonical specification was changed by Lane E. ## Evidence snapshot - AWP evidence branch: `evidence/i0-e-fire-learning` - AWP branch base observed at harvest start: `75d80546d78380e7ee317a9df46964d951832ac1` (`origin/main` at start) - Repaired C0 reference supplied by the assignment: `114b57a4ad37f9178b9c6309497c39663d4580e9` - Overdeck repository: `/home/user/Projects/overdeck` - Overdeck revision inspected: `8e20a23ea2cab9750d37cb4cff4cafce4d60a6ce` - Overdeck index: `docs/plans/INDEX.md` ## Methodology ### 1. Documentation/index traversal `docs/plans/INDEX.md` was searched systematically for `FIRE` and `incident`. Every linked Markdown record on those rows was resolved to its source document. That set was then unioned with every `docs/**/*.md` file whose filename contains `fire` or `incident`. Result: - 44 FIRE/incident link occurrences in the current index. - 54 unique FIRE/incident corpus documents after adding named incident/FIRE documents. The 54-file set was structurally traversed for title/date and incident-oriented sections. High-value records were then read in detail, including: - `docs/plans/2026-08-15-fire-session-harvest.md` - `docs/plans/2026-08-11-wip-worktree-triage.md` - `docs/plans/2026-08-11-land-queue-git-isolation.md` - `docs/plans/2026-08-11-cpu-load-session-sprawl.md` - `docs/plans/2026-08-11-cluster-push-oversize-trip.md` - `docs/plans/2026-08-12-ask-gpt-silent-hangs.md` - `docs/plans/2026-08-12-ask-gpt-xvfb-startup.md` - `docs/plans/2026-08-12-deploy-queue-coalescing.md` - `docs/plans/2026-08-12-ci-cd-incremental-delivery.md` - `docs/plans/2026-08-15-systray-claude-token-rotation.md` - `docs/plans/2026-08-17-codex-grant-single-writer.md` The catalog cites source paths rather than copying large transcript/doc passages. ### 2. Database traversal The historical path `~/.factory/data/factory.db` described by older documents is absent on this workstation. The current Overdeck runtime uses multiple stores under `~/.overdeck`. Schemas were discovered read-only before querying: - `~/.overdeck/requests.sqlite` - `~/.overdeck/events.sqlite` - `~/.overdeck/incident-mutations.sqlite` - `~/.overdeck/incident-status.sqlite` - `~/.overdeck/report-history.sqlite` The incident corpus was extracted from `requests.sqlite` using current semantics rather than guessed table names. The systematic request query covered rows matching any of: - `priority = 'FIRE'` - `origin = 'agent-incident'` - FIRE-shaped request IDs - incident-titled rows Result: 44 relevant request records inspected, including all 27 `FIRE`-priority rows and all 13 `agent-incident` rows. Associated `request_events` were inspected where present. Stable request IDs and UTC timestamps are retained in `INCIDENT-CATALOG.md`. No migration, repair, normalization, write transaction, or raw credential extraction was performed. ### 3. Claude workstation history Direct workstation evidence was used rather than Overdeck-generated summaries: - `~/.claude/projects/**` - `~/.claude/history.jsonl` The Overdeck-scoped Claude corpus contained: - 230 project directories whose encoded path contains `overdeck`; - 3,133 JSONL transcript files; - approximately 3.9 GB of transcript data. A broad user-role incident search across those transcript files matched 2,887 files. Removing `subagents/` paths left 1,350 main-session candidate files. Separately, the original user-prompt index `~/.claude/history.jsonl` was parsed structurally: - 2,669 Overdeck-scoped user history rows examined; - 265 unique high-signal incident/failure prompts; - 66 sessions represented by those high-signal prompts. High-severity cases used below were followed back into the original session JSONL when useful, including active-worktree reaping, a hidden 3,840-file deletion near-miss, workstation saturation, credential refresh races, and session/context-loss cases. The 265 high-signal prompts are search candidates, not 265 distinct incidents. Repeated discussion is deduplicated into normalized occurrences/classes. ### 4. Codex workstation history Direct Codex history was scoped by the `cwd` recorded in the first `session_meta` record of each JSONL: - `~/.codex/sessions/**` - `~/.codex/archived_sessions/**` Result: - 373 Codex sessions with an Overdeck-scoped `cwd`; - approximately 218 MB; - 392 `user_message` records parsed; - 172 unique high-signal messages across 171 sessions. Codex `user_message` records are often orchestrator task prompts rather than direct owner reports. They are therefore used primarily as supporting evidence for concrete failure contracts (for example broken release bundles, stale endpoint caching, journal sequence reset, restart-history loss, and supervision ownership races), not as independent user-report frequency inflation. ### 5. ChatGPT conversation-history facility The available personal-context/conversation search was queried for original Overdeck incident material. It returned a small number of current/prior summary facts and constraints but did not return original historical incident narratives with stable source IDs. Those summaries are not counted as primary incident occurrences where direct workstation evidence exists. This is an explicit limitation: the ChatGPT-history facility available to this lane did not provide a systematic original-message corpus comparable to the local Claude/Codex archives. Direct workstation histories supplied the primary historical user-report evidence. ## Counting rules Three counts are intentionally separate: 1. **Source records examined** — raw docs/database/user-message records traversed. 2. **Normalized incident occurrences** — concrete failure episodes retained in `INCIDENT-CATALOG.md` after removing repeated discussion and cross-source duplicates. 3. **Failure classes** — underlying mechanisms in `FAILURE-TAXONOMY.md`; one class may contain several occurrences. Qualitative frequency is reported as: - `recurring`: at least 3 independently evidenced occurrences/episodes; - `repeated`: 2 independently evidenced occurrences/episodes; - `observed`: 1 well-evidenced occurrence; - `broad`: many reports exist but the corpus cannot safely distinguish every occurrence without double-counting. Counts are lower bounds when repeated discussion was intentionally collapsed. ## Secret/privacy handling Evidence records contain no raw access tokens, refresh tokens, API keys, passwords, authorization headers, or credential payloads. Credential incidents use account-neutral descriptions and stable incident/session identifiers only where needed for relocation. ## Interpretation rule Every important finding is tested against current AWP design before becoming a recommendation: - If AWP already removes the Overdeck-specific mechanism, preserve only the operational lesson and test requirement. - If AWP already specifies the invariant, Lane E asks for an executable regression/failure-injection test rather than a second architecture. - If evidence is insufficient to establish root cause, the catalog says so. - A tactical historical fix is not promoted into an AWP architecture requirement merely because it once worked. ## Current high-level conclusion The AWP specifications already contain strong target principles for exact candidate identity, durable WIP, reconciliation-before-retry, immutable Attempt provenance, single credential authority, isolated execution, and realtime gap recovery. The highest value from this corpus is to make those principles non-regressible through concrete failure-injection gates—especially around destructive cleanup, ambiguous provider success, nested/uncollected WIP, lock/lease recovery, runtime identity, and state/UX honesty.