Roadmap¶

Current state¶

Phase 1A — Internet Research: Complete (2026-08-01)
Phase 1B — Local Investigation: Complete (2026-08-02 — findings in Findings/, verified facts in Knowledge-Base.md, data flow in Architecture.md)
Phase 2 — Architecture: Complete (2026-08-02 — approved architecture in Architecture.md, decisions in Decisions.md ADR-0004–0008, verification in Findings/)
Phase 3 — Design: Complete (2026-08-02 — approved in Decisions.md ADR-0009; deliverables in Statusline/Design/)
Phase 4 — Implementation: Complete (2026-08-03 — committed 5c0973b; the then-29-test contract suite passed; deployed live to ~/.claude/statusline/)
Phase 5 — Validation: Complete (2026-08-03 — report in Findings/2026-08-03 - Phase 5 - Validation Report.md; 6/7 scenarios validated; OmniRoute-unavailable recorded as opportunistic)
Phase 6 — Documentation and maintenance: Complete (2026-08-05 — README and repository map, Origin-Story.md, dual licensing, CI, maintenance notes, and the v2.0.0 first public release; see Phase 6 below)

Phase 1A — Internet research¶

Objective¶

Collect relevant external research before inspecting or changing the local environment.

Research areas¶

Claude Code statusline behavior and input contract.
OmniRoute routing behavior and model/provider metadata.
Existing statusline implementations and community patterns.
OmniRoute source-code structure and observability surfaces, where publicly available.
Candidate endpoints, logs, events, and integration points.

Deliverables¶

Raw Perplexity responses in Research/.
Source URLs and provenance in References/.
Historical prompts in Prompts/, if they are available.
A clear separation between external claims, hypotheses, and verified facts.

Gate¶

Complete when the relevant external research has been pasted verbatim into the research templates and every response has a date, topic, and source/provenance note.

Phase 1B — Local investigation¶

Objective¶

Verify the system's actual local behavior without implementing the statusline.

Investigation areas¶

Claude Code's statusline invocation and stdin payload.
Fields present in the runtime payload and their stability across cases.
Local OmniRoute configuration, process boundaries, and request flow.
Logs, diagnostics, and available local APIs.
How an automatic route is resolved to a provider/model.
Whether the resolved provider/model is exposed to the statusline through a reliable interface.
Failure behavior when metadata is unavailable or stale.

Deliverables¶

Investigation reports in Findings/.
Evidence excerpts or references to local logs and captures.
Updated open questions in Knowledge-Base.md.
A verified data-flow update in Architecture.md.

Gate¶

Complete when the major fields and integration points are traced, the source of any generic model label is explained or explicitly unresolved, and no material implementation assumption remains undocumented.

Phase 2 — Architecture¶

Objective¶

Turn verified observations into an approved system architecture.

Deliverables¶

Logical and physical data-flow diagrams.
Component responsibilities and trust boundaries.
Candidate integration options and tradeoffs.
Failure and fallback behavior.
Architecture decision records for material choices.

Gate¶

Architecture is approved only after the data source for each displayed value is identified and the design does not depend on unverified behavior.

Phase 3 — Design¶

Objective¶

Define the statusline's behavior and implementation contract.

Deliverables¶

Display requirements.
Input/output contract.
Provider/model naming rules.
Caching and timeout policy, if needed.
Security and privacy considerations.
Test cases and acceptance criteria.

Gate¶

The design is approved before code is written.

Phase 4 — Implementation¶

Objective¶

Implement the smallest production-quality solution consistent with the approved design.

Deliverables¶

Statusline implementation in Statusline/.
Supporting utilities in Scripts/ only where justified.
Unit or contract tests.
Usage and configuration documentation.

Gate¶

Implementation is complete only when the defined tests pass and failure behavior is deliberate.

Phase 5 — Validation¶

Objective¶

Validate the solution against real and failure scenarios.

Scenarios¶

Direct model selection.
Automatic routing.
Provider/model changes during a session.
Missing, malformed, or delayed metadata.
OmniRoute unavailable.
Slow or failing statusline execution.
Different terminal widths and display environments.

Deliverables¶

Validation report.
Captured evidence for important scenarios.
Known limitations and follow-up work.

Phase 6 — Documentation and maintenance¶

Objective¶

Make the result understandable and maintainable after the initial investigation.

Deliverables¶

Updated README and project map.
Final architecture and decision records.
Operational notes and troubleshooting.
Research provenance and links.
A short maintenance plan.

Immediate next actions¶

Done:

Pasted each Perplexity response verbatim into the matching Research/ template. (2026-08-01)
Added the links used by the research to References/Bibliography.md. (2026-08-01)
Committed the repository as the pre-Claude baseline. (2026-08-01)
Started Claude Code with discovery-only scope. (2026-08-01)
Reviewed and approved the Phase 1B local investigation plan before local inspection. (2026-08-02; recorded in Decisions.md, ADR-0003)
Executed Phase 1B: traced the statusline stdin payload and the OmniRoute request flow locally; observations in Findings/, verified facts in Knowledge-Base.md, data flow in Architecture.md. (2026-08-02)
Executed Phase 2: approved plan; ran the read-only verification (latency, stability, transcript reliability, freshness, provider inference) in Findings/2026-08-02 - Phase 2 - Read-only Verification.md; synthesized the approved architecture in Architecture.md; recorded decisions in Decisions.md (ADR-0004–0008) and updated Knowledge-Base.md. (2026-08-02)
Completed the Phase 2 completion review: the architecture was approved and ADR-0005–0008 were accepted (2026-08-02; recorded in Decisions.md), closing the Phase 2 gate. Phase 3 (Design) is now in progress; design deliverables are being written in Statusline/Design/.
Completed the Phase 3 completion review: the design was approved (2026-08-02; recorded in Decisions.md, ADR-0009) with one change request — the transcript tail read is required to be bounded at the architecture level, and the concrete window size is an implementation constant (currently 256 KB), not an architectural invariant. The Phase 3 gate is closed; Phase 4 (Implementation) is ready to begin in a new session.
Executed Phase 4: implemented the modular statusline (Statusline/lib/*, Statusline/statusline.js), the 29-test contract suite (29/29 pass), and the supporting scripts (Scripts/update-model-provider-mapping.js, Scripts/deploy-statusline.js); committed as 5c0973b and deployed live to ~/.claude/statusline/; plan recorded in Findings/2026-08-02 - Phase 4 Implementation Plan.md (no ADR — implementation of the approved architecture). (2026-08-03)
Completed the Phase 5 validation: live smoke resolved opencode/big-pickle; a request-weight-dependent model switch was confirmed (light session → opencode/mimo-v2.5-free, heavy session → opencode/big-pickle); narrow-terminal resize passed; the [stale]-clears-at-processing-start behavior was confirmed correct. Evidence and the validation report are in Findings/. OmniRoute-unavailable was accepted as an opportunistic observation, not a required induced failure. The Phase 5 gate is closed; Phase 6 (Documentation and maintenance) is ready to begin. (2026-08-03)
Executed Phase 6: completed the documentation and maintenance deliverables — README and repository map, Origin-Story.md, dual licensing (LICENSE/LICENSE.docs/LICENSING.md), CI (contract tests + markdown link check), issue/PR templates, and maintenance notes. The V2 statusline work (real context window from model_capabilities, provider-hue styling, worktree and branch-state labels) grew the contract suite to 68 tests. Released as the annotated tag v2.0.0 (2026-08-05), the first public release.