Implementation Plans

Plans describe concrete Tosumu implementation work: scope, ownership, incremental slices, validation, risks, and completion criteria.

Plans do not create architectural authority. When implementation evidence changes an accepted boundary, open an Architectural Review and update or supersede the relevant ADR.

Copy TEMPLATE.md when opening a plan. Remove sections that are genuinely irrelevant, but keep per-slice deliverables, acceptance criteria, validation, and exit states.

Current And Retained Plans

• Main Feature Roadmap -- canonical implementation status tracker; Active. MVP 0-8 and the MVP+9 baseline are complete; MVP+10 is the next planning gate.
• Initial SQL Layer -- MVP+9 baseline complete; retained as Completed baseline implementation history and a source for deferred SQL work.
• Tosumu Command Language -- proposed sliced implementation; Proposed. Ownership remains under AR-0001.
• Tokimu Reciprocal Website Evidence -- Proposed cross-project website evidence using versioned public observations and independently deployable MkDocs sites.
• Tosumu Inspection Island And UI Providers -- Proposed provider-neutral inspection observations and commands shared by native Ratatui and TypeScript website-island providers.
• Public Website And Repository Records -- Proposed public information architecture, publication policy, indexed navigation, and GitHub engineering-record boundary.
• Documentation Lifecycle And Design Decomposition -- Active normalization of document status and the current/future design boundary.

Plan Requirements

A useful plan should include:

• motivating evidence and current state;
• goals and explicit non-goals;
• ownership and dependency boundaries;
• small compiling implementation slices;
• acceptance criteria for each slice;
• tests, fuzzing, fixtures, or consumer evidence;
• risks, unsupported cases, and diagnostics;
• completion, graduation, or parking criteria;
• links to related specifications, ADRs, reviews, CRs, and code.