# Roadmap: AITP Runtime And Knowledge Foundations

## Milestones

- ✅ **v1.6 Runtime Front-Door Parity Hardening** — Phases 25-29 (shipped
  2026-04-05)
- ✅ **v1.5 L2 Knowledge Compiler And Hygiene** — Phases 20-24 (shipped
  2026-04-05)
- ✅ **v1.4 Runtime Simplification And Reuse Foundations** — Phases 15-19
  (shipped 2026-04-04)
- ✅ **v1.3 Multi-Topic Parallel Execution** — Phases 10-14 (shipped
  2026-04-04)
- ✅ **v1.2 Projection-First Formal-Theory Seed** — Phases 06-09 (shipped
  2026-04-01)
- ✅ **v1.1 L2 Topic-Skill Projection** — retrospective ship capture in commit
  `6445c59` (shipped 2026-04-01)
- ✅ **v1.0 Runtime Hardening** — Phases 1-5 (shipped 2026-03-31)

## Overview

`v1.6` is now shipped.

It made runtime support honest and diagnosable instead of leaving parity claims
scattered across docs and fallback notes:

1. define a first-class runtime/front-door support matrix,
2. expose that matrix through `aitp doctor`,
3. harden Claude Code bootstrap verification,
4. harden OpenCode bootstrap verification,
5. align migration/install flows with explicit multi-runtime convergence,
6. close with docs and regression coverage that do not overclaim symmetry.

No post-`v1.6` milestone is active yet. The explicit future-horizon item
remains `L5 Publication Factory`.

## Phases

- [x] **Phase 25: Runtime Matrix Contract And Doctor Parity Seed** - Define the
  runtime/front-door matrix and expose the first doctor-visible parity read.
- [x] **Phase 26: Claude Code Bootstrap Verification Hardening** - Make Claude
  bootstrap health more explicit than a single coarse hook-surface check.
- [x] **Phase 27: OpenCode Plugin Verification Hardening** - Make OpenCode
  plugin/config health more explicit than a single enabled flag.
- [x] **Phase 28: Multi-Runtime Convergence And Migration Repair** - Align
  migration/install flows with explicit front-door convergence expectations.
- [x] **Phase 29: Runtime Matrix Docs And Regression Closure** - Close the
  milestone with honest docs, support-matrix publication, and regression
  coverage.

## Phase Details

### Phase 25: Runtime Matrix Contract And Doctor Parity Seed
**Goal**: Add one explicit runtime/front-door matrix and make `aitp doctor`
report it instead of leaving runtime maturity implicit.
**Depends on**: `v1.5` shipped baseline
**Requirements**: [RTP-01, RTP-02]
**Success Criteria** (what must be TRUE):
  1. `aitp doctor` exposes a first-class runtime/front-door matrix.
  2. The matrix distinguishes Codex baseline readiness from Claude/OpenCode
     parity-hardening status and OpenClaw specialization.
  3. The first implementation improves diagnosis without overclaiming deeper
     execution parity.
  4. The implementation stays focused and does not add more giant branching
     logic into the main service file than necessary.
**Plans**: 1 plan

Plans:
- [x] 25-01: Add the first doctor-visible runtime support matrix plus focused
  regression coverage.

### Phase 26: Claude Code Bootstrap Verification Hardening
**Goal**: Make Claude Code bootstrap readiness and drift easier to diagnose and
repair.
**Depends on**: Phase 25
**Requirements**: [RTP-03]
**Success Criteria** (what must be TRUE):
  1. Claude bootstrap diagnosis names which surfaces are missing, stale, or
     mismatched.
  2. The result helps a user repair Claude Code bootstrap without guessing.
  3. Compatibility install and preferred bootstrap paths stay clearly
     distinguished.
**Plans**: 1 plan

Plans:
- [x] 26-01: Extend Claude bootstrap diagnostics to detect missing, stale, and
  miswired SessionStart surfaces.

### Phase 27: OpenCode Plugin Verification Hardening
**Goal**: Make OpenCode plugin/config readiness and drift easier to diagnose
and repair.
**Depends on**: Phase 25
**Requirements**: [RTP-04]
**Success Criteria** (what must be TRUE):
  1. OpenCode diagnosis names whether plugin registration, config, or skill
     injection is missing or stale.
  2. The result helps a user repair OpenCode bootstrap without guessing.
  3. The docs keep plugin-first routing explicit without implying marketplace
     polish already exists.
**Plans**: 1 plan

Plans:
- [x] 27-01: Extend OpenCode diagnosis across preferred config and
  compatibility workspace surfaces.

### Phase 28: Multi-Runtime Convergence And Migration Repair
**Goal**: Make migration and install flows converge all supported front doors
more explicitly.
**Depends on**: Phase 26 / Phase 27
**Requirements**: [RTP-05]
**Success Criteria** (what must be TRUE):
  1. Migration/install flows report whether Codex, Claude Code, and OpenCode
     are each converged.
  2. The repair path no longer implies Codex success is enough.
  3. Mixed-install diagnostics remain durable and honest.
**Plans**: 1 plan

Plans:
- [x] 28-01: Add before/after runtime convergence summaries to migration
  output.

### Phase 29: Runtime Matrix Docs And Regression Closure
**Goal**: Close the milestone with docs and tests that publish current runtime
support honestly.
**Depends on**: Phase 28
**Requirements**: [RTP-02, DOC-05]
**Success Criteria** (what must be TRUE):
  1. Public docs show the runtime/front-door support matrix clearly.
  2. The docs keep Codex as the current baseline and Claude/OpenCode as
     parity-hardening targets.
  3. Regression coverage locks the runtime-matrix language and doctor outputs
     so later work cannot silently overclaim parity.
**Plans**: 1 plan

Plans:
- [x] 29-01: Publish the final runtime support matrix in docs and lock it with
  regression tests, then close `v1.6`.

## Progress

| Phase | Plans Complete | Status | Completed |
|-------|----------------|--------|-----------|
| 25. Runtime Matrix Contract And Doctor Parity Seed | 1/1 | Complete | 2026-04-05 |
| 26. Claude Code Bootstrap Verification Hardening | 1/1 | Complete | 2026-04-05 |
| 27. OpenCode Plugin Verification Hardening | 1/1 | Complete | 2026-04-05 |
| 28. Multi-Runtime Convergence And Migration Repair | 1/1 | Complete | 2026-04-05 |
| 29. Runtime Matrix Docs And Regression Closure | 1/1 | Complete | 2026-04-05 |

## Backlog

### Phase 999.1: L5 Publication Factory (BACKLOG)
**Goal:** Add a final `L5` publication/output layer that turns a completed
topic into a paper-grade writing package without changing scientific truth.
**Requirements:** [PUB-01, PUB-02, PUB-03]
**Plans:** 0 plans

Plans:
- [ ] TBD (promote only when explicitly selected as a new milestone)
