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, ticket import, and experimental campaigns started with /campaign. In real use, not an experiment: on the author's projects and on a growing number of others, most of them closed source. Cloned from 484 unique sources in the two weeks to 29 Sep 2026. Measured across three machines: 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 public third-party report 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 is in real use well beyond the author's projects. Most of that use is closed source, so what's still missing is evidence anyone can verify. The series aSPARK reads runs it on well-known open-source code and publishes every source; field reports from your own projects add the rest. Whether a lens fires on a website or api project is exactly what such a report shows. A field report is worth more than a patch — most of all when it went badly.
aSPARK-insights computes traceability metrics from the graph — standalone, not in the loop, not on PyPI. aSPARK-policy is a format, a catalog of 11 packs and, since v0.3.0, a resolve/validate CLI; the /charter binding is 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.