ADR-015 — Codira Development Roadmap¶
Date: 14/04/2026 Status: Accepted
Context¶
This roadmap is derived from the current issue set and reflects:
- strong emphasis on deterministic behavior
- ongoing architectural stabilization (#7, #8, #9, #10)
- transition toward a plugin ecosystem
- expansion into multi-language and multi-repo contexts
The roadmap prioritizes:
- architectural correctness first
- capability expansion second
- ecosystem and tooling third
Decision¶
Adopt a phased roadmap with explicit release gates tied to architectural maturity.
Phase 0 — Stabilization (pre-1.2.x → 1.30.0)¶
Status Ph 0¶
This phase is completed
Scope Ph 0¶
-
2 — Remove temporary Ruff fixes¶
-
7 — Capability contract¶
-
8 — Backend decoupling¶
-
9 — In-memory backend (contract validation)¶
Rationale Ph 0¶
- These issues define core invariants
- Without them, all future extensions risk:
- hidden coupling
- non-determinism
- unstable plugin surface
Outcome Ph 0¶
- codira becomes:
- explicitly defined
- backend-agnostic
- testable across implementations
Release policy Ph 0¶
- No major public positioning yet
- Patch/minor releases acceptable
Phase 1 — Production-readiness (→ 1.40.0)¶
Scope Ph 1¶
Rationale Ph 1¶
- Transition from:
- “works locally”
-
to “production-grade system”
-
Introduce:
- backend diversity
- architectural enforcement
- correct coverage semantics
Outcome Ph 1¶
- codira becomes:
- robust
- extensible
- guarded against regressions
Release policy Ph 1¶
- First stable minor release suitable for external users
- Recommended tag: 1.40.0
Phase 2 — Core capability expansion (→ 1.50.0)¶
Scope Ph 2¶
-
1 — Optional fallback analyzers¶
-
3 — Documentation channel¶
-
5 — Makefile analyzer¶
-
11 — C++ analyzer¶
-
12 — Lua analyzer¶
Rationale Ph 2¶
- Expand real-world repository coverage
- Target high-impact ecosystems:
- C/C++
- build systems
- Lua-based systems
Key principle Ph 2¶
prioritize analyzers that unlock large classes of repositories
Outcome Ph 2¶
- codira becomes:
- multi-language
- context-rich
- useful beyond Python
Release policy Ph 2¶
- First release suitable for broad adoption
- Recommended tag: 1.50.0
Phase 3 — Ecosystem structuring (→ 1.60.0)¶
Scope Ph 3¶
-
17 — Install-time configuration¶
-
18 — Plugin extraction readiness checklist¶
-
4 — Documentation audit plugin system¶
Rationale Ph 3¶
- Transition from:
- internal architecture
-
to external ecosystem
-
Enable:
- third-party plugins
- configurable environments
- consistent plugin quality
Outcome Ph 3¶
- codira becomes:
- platform-ready
- plugin-friendly
- configurable
Release policy Ph 3¶
- First release suitable for plugin ecosystem growth
- Recommended tag: 1.60.0
Phase 4 — System-level capabilities (→ 1.70.0+)¶
Scope Ph 4¶
Rationale Ph 4¶
- Move from:
- repository-level understanding
-
to system-level understanding
-
Address:
- multi-repo architectures
- domain-specific ecosystems
Outcome Ph 4¶
- codira becomes:
- system analysis tool
- not just repository tool
Release policy Ph 4¶
- Major feature release
- Recommended tag: 1.70.0+
Cross-cutting track — Tooling and workflow¶
Status¶
This phase is completed
Scope¶
-
16 — Hyperfine integration¶
Position¶
- Can be introduced early (Phase 0–1)
- Matured progressively
Role¶
- Performance regression detection
- Release validation support
Release Strategy Summary¶
| Phase | Version | Purpose |
|---|---|---|
| Phase 0 | ≤1.30.x | Architectural stabilization |
| Phase 1 | 1.40.0 | Production-ready core |
| Phase 2 | 1.50.0 | Broad usability |
| Phase 3 | 1.60.0 | Ecosystem readiness |
| Phase 4 | 1.70.0+ | System-level capabilities |
Key Architectural Principles¶
- Determinism over convenience
- Explicit contracts over implicit behavior
- Plugins over core bloat
- Structure first, semantics later
- Ecosystem after stability
Final Statement¶
This roadmap enforces a strict progression:
architecture → capability → ecosystem → scale
Deviating from this order risks:
- instability
- plugin breakage
- architectural drift