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. Auf den eigenen Projekten des Autors durchgelaufen: 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 fremder Loop. 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 noch nie durch einen vollständigen Loop auf dem echten Projekt einer anderen Person gelaufen. Alles andere auf dieser Seite ist dem nachgeordnet. Die Lens-Schicht ist auf aSPARK selbst und steamcore dogfooded, aber ob eine Lens auf einem fremden website- oder api-Projekt feuert, kann nur ein Mensch berichten, der den Loop dort fährt. Ein Field Report ist mehr wert als ein Patch — am wertvollsten, wenn es schiefging.
Anti-Rationalisierungs-Tabellen an jedem Gate (#13) — bewusst nach den Field Reports, damit sie die Ausreden listen, die Agenten wirklich erfinden. Eine Observability-Lens (#15) zwischen api und security. Zweifel mitten im Increment (#14) — nur wenn es billig und selten bleibt. Ticket-Import und Status-Rückschreibung (#19), optional und nie blockierend.
aSPARK-insights rechnet Traceability-Kennzahlen aus dem Graph — eigenständig, nicht im Loop, nicht auf PyPI. aSPARK-policy ist ein Format und ein Katalog mit 11 Packs; validate-CLI und /charter-Bindung sind 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.