Skip to content

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 complete and MVP+11 contract reconciliation is current.
  • MVP+10 Multiple Readers And Coordination -- Proposed; baseline recorded for current handle, visibility, writer, and checkpoint behavior under AR-0009.
  • MVP+10 Secondary Indexes -- implements the ADR-0008 SQL-owned ordered index representation after reader visibility and conditional writes.
  • MVP+10 VACUUM -- implementation closure recorded for the ADR-0009 offline verified rebuild; native macOS arm64 CI confirms the Unix publication path.
  • MVP+10 Benchmark Closure -- Complete reader scaling, writer-overlap, and SQLite comparison evidence.
  • MVP+11 Mobile Embedding -- Proposed; Slice 0 baseline complete callback-free C ownership, independent language callers, target qualification, and real platform-protector gates under AR-0017.
  • 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.
  • Core Source Unit Decomposition -- Complete behavior-preserving test and private-module decomposition triggered by ADR-0003's initial core inventory.
  • Cluster Fault Tolerance And Replication -- Proposed; architectural admission required long-term claim ladder and gated path from single-authority K3s recovery through async standby, fenced automatic authority transfer, and conditional synchronous consensus.
  • High-Assurance Engineering And Evidence Export -- Proposed; assurance claims not yet admitted cross-cutting levels for dependency/source provenance, reproducible artifacts, bounded evidence export, platform qualification, key/privilege boundaries, and independent profile review.
  • Cryptographic Provider Seam And Suite Agility -- Gates C1-C2 complete; later architecture unadmitted private byte-preserving format seam plus independent oracle evidence, with opaque key ownership, suite identity, migration, and reviewed profiles still gated.

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.