Roadmap
What Core does next, what is still unproven, and where the extensions stand.
What comes next — and the one proof still missing.
Ordered by dependency and honest priority, not by schedule. The source is Core's ROADMAP.md and the open issues; nothing here carries a date.
Five phases, five gates, ten ceremonies, seven agents. A constitution with /charter as the entry point, nine situational lenses, PR-mode delivery, handoff blocks, a declared QA method. Run on the author's own projects: 77 features, 429 agent runs, 377 human gate decisions — re-derivable from the committed reports.
aSPARK-guard enforces the three gate rules at the tool call and keeps a hash ledger — 142 tests, replayed over 22 real artifacts, no third-party loop yet. aSPARK-graph is on PyPI and scopes /sprint-plan, /peer-review and /demo-day. Known gap: graph still looks for review-report.md, qa-report.md and release-notes.md while Core writes review.md, qa.md and release.md — three of five artifact types are invisible to the graph until the names are reconciled.
aSPARK has never run a full loop on someone else's real project. Everything else on this page is secondary to that. The lens layer is dogfooded on aSPARK itself and on steamcore, but whether a lens fires on a stranger's website or api project only a person running the loop there can report. A field report is worth more than a patch — most of all when it went badly.
Anti-rationalization tables at every gate (#13) — deliberately after the field reports, so they list the excuses agents actually invent. An observability lens (#15) between api and security. Doubt mid-increment (#14) — only if it stays cheap and rare. Ticket import and status write-back (#19), optional and never blocking.
aSPARK-insights computes traceability metrics from the graph — standalone, not in the loop, not on PyPI. aSPARK-policy is a format and a catalog of 11 packs; the validate CLI and the /charter binding are unbuilt, and no agent picks up a policy automatically today. aSPARK-ci and aSPARK-memory are planned and not started.
Compatibility commitment: Core alone stays complete and supported. A missing extension changes nothing about the loop — no error, no warning, no mention.
Does this fit your delivery process?
Start with Core on a pilot project. The workflow, knowledge graph and policy packs are all open on GitHub.