Roadmap
Was Core als Nächstes tut, was noch unbewiesen ist, und wo die Erweiterungen stehen.
Was als Nächstes kommt — und der eine Beweis, der noch fehlt.
Reihenfolge nach Abhängigkeit und ehrlicher Priorität, nicht nach Zeitplan. Quelle ist Cores ROADMAP.md und die offenen Issues; nichts hier trägt ein Datum.
Fünf Phasen, fünf Gates, zehn Ceremonies, sieben Agenten. Constitution mit /charter als Einstieg, neun situative Lenses, PR-Modus-Delivery, Handoff-Blöcke, deklarierte QA-Methode, Ticket-Import und experimentelle Kampagnen, gestartet mit /campaign. Im echten Einsatz, kein Experiment: auf den Projekten des Autors und in einer wachsenden Zahl weiterer, überwiegend nicht öffentlicher Projekte. In den zwei Wochen bis 29.09.2026 von 484 verschiedenen Quellen geklont. Gemessen auf drei Maschinen: 77 Features, 429 Agent-Läufe, 377 menschliche Gate-Entscheidungen — nachrechenbar aus den committeten Reports.
aSPARK-guard setzt die drei Gate-Regeln am Tool-Aufruf durch und führt ein Hash-Ledger — 142 Tests, über 22 reale Artefakte nachgespielt, noch kein öffentlicher Bericht aus einem fremden Projekt. aSPARK-graph liegt auf PyPI und grenzt /sprint-plan, /peer-review und /demo-day ein. Bekannte Lücke: graph sucht noch review-report.md, qa-report.md und release-notes.md, Core schreibt review.md, qa.md und release.md — drei von fünf Artefakttypen sind für den Graph bis zum Abgleich unsichtbar.
aSPARK ist weit über die Projekte des Autors hinaus im Einsatz. Das meiste davon ist nicht öffentlich, deshalb fehlen noch Belege, die jeder nachprüfen kann. Die Serie aSPARK liest lässt es auf bekanntem Open-Source-Code laufen und veröffentlicht jede Quelle; Field Reports aus Ihren eigenen Projekten ergänzen den Rest. Ob eine Lens auf einem website- oder api-Projekt feuert, zeigt genau so ein Bericht. Ein Field Report ist mehr wert als ein Patch — am wertvollsten, wenn es schiefging.
Strengere Urteilsregeln für Review und QA (#13) — geplant, nicht gebaut: eine Suche in den eigenen Trails fand einen umgangenen Gate, zu wenig, um schon Regeln dagegen zu schreiben. Eine Observability-Lens (#15) zwischen api und security. Zweifel mitten im Increment (#14) — nur wenn es billig und selten bleibt.
aSPARK-insights rechnet Traceability-Kennzahlen aus dem Graph — eigenständig, nicht im Loop, nicht auf PyPI. aSPARK-policy ist ein Format, ein Katalog mit 11 Packs und seit v0.3.0 eine resolve/validate-CLI; die /charter-Bindung ist ungebaut, kein Agent zieht eine Policy heute automatisch heran. aSPARK-ci und aSPARK-memory sind geplant und nicht begonnen.
Kompatibilitäts-Zusage: Core allein bleibt vollständig und unterstützt. Eine Erweiterung, die fehlt, ändert am Loop nichts — kein Fehler, keine Warnung, keine Erwähnung.
Passt das zu Ihrem Lieferprozess?
Beginnen Sie mit Core auf einem Pilotprojekt. Workflow, Wissensgraph und Policy-Packs liegen offen auf GitHub.