Restructure docs/development-plan.md into a status-tracked, item-based living roadmap, replacing prose narrative that required full rewrites

Context

development-plan.md had grown into an 11-section prose narrative that mixed forward-looking planning with retrospective explanation, requiring in-place prose rewrites every time an item's status changed -- the user flagged this as an unsustainable pattern (arbitrary rewrites, adding/deleting task lists, risk of losing historical context) and asked for a permanent, scalable structure before any further edits, requiring researched precedent from mature open-source projects and engineering organizations rather than an invented scheme.

Options considered

Reorganize into the three phases originally proposed (Foundation & Core Engine Architecture, CI/CD & Deployment Pipeline, Multi-Game Expansion Trigger) as prose sections, keeping the existing narrative-rewrite-in-place editing model — rejected

Would not have solved the actual root cause -- prose narrative has no field to flip when status changes, which is why full rewrites kept being necessary. The user explicitly paused this exact approach mid-request to ask for researched precedent first.

Invent a bespoke status-tracking scheme specific to this project rather than following external precedent — rejected

Cross-referenced four independent, real precedents directly (not summaries): Michael Nygard's original Architecture Decision Record pattern and the MADR template's explicit status field (proposed/rejected/accepted/deprecated/superseded-by), Kubernetes Enhancement Proposals' seven-state lifecycle (provisional/implementable/implemented/deferred/rejected/withdrawn/replaced), Python PEPs' independently-arrived-at near-identical vocabulary, and the Rust RFC process's structural insight of separating an immutable proposal document from a separately-updated tracking issue. All four converge on the same underlying discipline: an item is written once and never rewritten in place, only its status field changes, following a small fixed vocabulary -- adopted directly rather than reinvented.

Fold the new roadmap content into docs/decisions.jsonl or docs/technical-architecture.md instead of keeping development-plan.md as a separate document — rejected

Would collapse three genuinely different documentation types (Diataxis framework, cross-referenced) into one: decisions.jsonl is the immutable, append-only record of why a decision was made (already correctly structured, already following the ADR pattern without knowing it -- it already has a status field and supersedes/superseded_by pointers); technical-architecture.md is the current-state policy reference; development-plan.md's actual, distinct job is the forward-looking, status-tracked index of planned/in-progress/resolved work -- the KEP/PEP layer this project was missing. Keeping it separate but cross-referenced from both directions matches the RFC/tracking-issue split rather than merging concerns that are better kept apart.

Decision

Rewrote docs/development-plan.md as a permanent, item-based roadmap: every entry is a discrete, numbered item (RM-001 onward) that is never deleted or rewritten in place once written -- only a controlled status field (Planned / In Progress / Completed / Deferred / Superseded) changes, dated and appended, mirroring the MADR/KEP/PEP status-field pattern sized down to this project's actual scale. Completed items carry a mandatory cross-reference to the decisions.jsonl entry or technical-architecture.md section recording how they were resolved; the roadmap item states what was planned and its current state, the decision log remains the sole place why lives, matching the Rust RFC/tracking-issue separation. Items are grouped into four phases by subject area (orthogonal to status, so an item's phase never changes as its status does): Phase 1 Foundation & Core Engine Architecture (genre-agnostic engine work, including the new GameEvent decoupling and save-schema-versioning policy items from decision 0042), Phase 2 Reference Game: Suika-Style Merge Puzzler (genre-specific feature work, split out as its own phase rather than folded into Phase 1, directly mirroring technical-architecture.md §2.2's own genre-agnostic/genre-specific separation), Phase 3 CI/CD & Deployment Pipeline (glemy-website's build/deploy pipeline plus the open content-hashing and stable/edge-channel items), and Phase 4 Multi-Game Expansion Trigger (the not-yet-met engine-extraction condition, recorded so it's defined in advance rather than decided under pressure). All 42 existing decisions' worth of historical content was preserved and mapped into this structure, not discarded. Stale section-number cross-references (§4, §8, "Phase 8") in game.gleam, pe.gleam, and tools/browser_check.ts, which pointed into the old document's numbering scheme, were updated to the new RM-xxx item IDs.

Verification

gleam test and gleam test --target javascript both pass unchanged (164 Erlang / 187 JavaScript) -- this is a documentation-only change, confirmed by the test counts being identical to before. deno task check-warnings passes (49/49 matching baseline), confirming the doc-comment edits introduced no new warnings. A repo-wide grep for every remaining development-plan.md cross-reference confirmed no stale section-number pointer was left unresolved.

Consequences

development-plan.md no longer needs a rewrite when a single item's status changes -- future updates are a status-field edit plus a dated note, not prose surgery. The three-way separation (decisions.jsonl = why/history, technical-architecture.md = current-state policy, development-plan.md = what's planned/in-progress/resolved) is now explicit and cross-referenced from all three documents, closing the gap technical-architecture.md's own §2.2/§3.3/§3.4/§4.4 policies had already created (those items existed as prose in the architecture document with no corresponding tracked roadmap entry until this change).

References

• docs/development-plan.md
• docs/technical-architecture.md
• docs/decisions.jsonl