Roadmap

Roadmap

kstrl evolves in named cycles, each governed by a durable tracker checked into docs/. Roadmaps are formal documents, not wish lists: every item has a sizing (diff scope, not duration), explicit dependencies, and a measurable "Done when" gate.

How roadmaps are governed

Conventions shared by every tracker:

• Status legend: [ ] pending, [~] in progress, [x] done, [-] skipped.
• Sizing: S (small diff, under ~100 lines), M (one PR), L (multi-PR workstream).
• "User decisions required" and "user-run measurements required" are listed up front and block the items that need them.
• Process rules bind every cycle: no self-review (H1), calibration re-run on any prompt change (H2), prompt version and snapshot move together (H3), every done claim states what was tested vs assumed (H4).
• R8 added: no assumed thresholds - every numeric gate is a placeholder until replayed against historical run data.

Cycle 1: Adversarial hardening (A-H) - complete

Tracker: docs/adversarial-roadmap.md

The 42-item cycle that built the adversarial factory itself: the 8-role taxonomy, mechanical verification, hard-mode review gates, contract testing, knowledge distillation, calibration suite, evolution journal, and the process rules (H1-H4) that still bind all work. One deliberate skip: multi-model rotation (E1) was accepted as a known limitation - correlated failure across same-family roles is real and is being addressed differently (cross-family review at high autonomy, R8.5).

Cycle 2: A+ remediation (R0-R7) - substantially complete

Tracker: docs/remediation-roadmap.md

Fixed every finding from a full-system review and raised each dimension to A+: timeout enforcement everywhere (R0.1), worktree/lock lifecycle (R0.5), budget caps and cost metering (R3.1), structured failure parsing, fixtures oracle (R7.2), unified scheduling (R7.3), Linear one-way mirror (R7.4), no-progress breaker and sandbox pass-through (R7.5), and the opt-in claude-sdk adapter (R7.6). This cycle also carried the Ralph -> kstrl rename and the Textual TUI rewrite (events substrate, home shell, ks dash).

Still open in this tracker: user-run calibration baseline captures (R5.x), the same-family vs cross-family reviewer delta (R7.1), and two real factory runs. These are not bookkeeping - they are the authorization evidence the R8 autonomy ladder requires for L2+ entry.

Cycle 3: R8 Dark Factory - current

Tracker: docs/dark-factory-roadmap.md (landed via PR #157) - milestone - tracking issue #156

Provenance: a gap analysis diffed kstrl against a 15-pillar software-factory reference model (Cusumano's Japanese factories, Greenfield/Short, SEI product lines, DoD DevSecOps/cATO, lights-out manufacturing). The verification core met the bar; four structural gaps did not: continuous intake, a release stage, runtime feedback, and an explicit earned-autonomy model. See Vision and Philosophy for the frame.

The eight items, in four dependency-ordered waves:

Wave	Item	Issue	One line
1 - governance core	R8.1 Policy envelope	#148	Declarative [policy] block enforced mechanically on diffs and lockfiles
1	R8.4 Health trending	#151	EWMA + Western Electric rules over run metrics; evidence for demotion
1	R8.2 Autonomy ladder	#149	L1-L4 levels: earned by evidence + human ack, demoted automatically
1	R8.3 Exception inbox	#150	One surface for everything awaiting a human decision; ntfy push
2 - adequacy	R8.5 Test adequacy gate	#152	Oracle linting, patch coverage, diff-scoped mutation, fixtures at L3+
3 - operation	R8.6 Continuous intake	#153	.kstrl/queue/ substrate, ks serve, GitHub Issues label polling
4 - release + loop	R8.7 Release stage	#154	Phase 4: deploy drivers, SHA-stamped verification ladder, rollback doctrine
4	R8.8 Runtime feedback	#155	Error/health signals polled into the queue; reproducing-test rule

Explicit non-goals for R8: 100% dark operation, two-machine queues, per-platform deploy adapters, webhook infrastructure, and building queue/monitoring/policy engines in-house.

Where to watch progress

• The R8 milestone shows live item status; #156 is the sequenced checklist.
• Merged work always updates the tracker doc in the same PR (audit-trail doctrine), so docs/dark-factory-roadmap.md on main is authoritative.