aSPARK Core
Der deterministische Lieferprozess: fünf Phasen, fünf Gates, ein Team aus spezialisierten Rollen — und ein Ticket-Trail, der mit dem Code versioniert wird.
Der SPARK-Loop: fünf Phasen, fünf Gates.
Jedes Feature durchläuft fünf Phasen — und darf nur vorrücken, wenn das Gate der Vorphase grün ist. Jede Phase liest das Artefakt der Vorphase und verweigert den Start, wenn das Gate nicht erfüllt ist.
Eine Person plus aSPARK arbeitet wie ein ganzes Team. Jede Rolle ist ein Subagent — stateless, mit eigenem Mindset, Standards und erlaubten Tools.
Zwei Ceremonies gehören keiner einzelnen Rolle: /spark fährt den kompletten Loop am Stück — mit Halt an jedem Gate und Wiederaufnahme danach. /next-steps schlägt aus dem aktuellen Projektstand das nächste Feature vor, wenn die Frage lautet „womit weiter?".
Alle Entscheidungen bleiben im Projekt
Pro Feature entsteht ein Arbeitsverzeichnis — ein transparenter, reviewbarer Ticket-Trail, versioniert mit dem Code.
Stabile IDs über den ganzen Zyklus
Anforderungen tragen stabile IDs — US-, AC-, NFR- — von der Spec bis zum Release. Der Plan benennt, welche AC ein Task abdeckt; das Review verfolgt jede Muss-AC bis zum Code; QA verifiziert sie unter derselben ID. Nichts fällt still aus der Kette.
Situative Lenses schalten sich je nach Projekttyp zu — seo · ux · api · cli · library · security · i18n · data · accessibility — und geben dem bestehenden Team zusätzliche Checks, nur dort wo sie greifen.
Optionaler Graph-Anschluss: Liegt aspark-graph im Projekt, nutzen /sprint-plan, /peer-review und /demo-day es still zur Eingrenzung — welche Dateien ein Task berührt, was ein Review zuerst liest, welche Stories QA am härtesten prüft. Fehlt es, ändert sich nichts. Eine Graph-Antwort ist eine Karte, nie ein Gate-Urteil; die Ceremonies bauen den Graphen nie selbst.
Ehrlicher Status: aSPARK Core ist mit v0.11.0 im produktiven Eigeneinsatz — der komplette SPARK-Loop (10 Skills, 7 Agenten, 6 Templates), PR-Modus-Delivery (handed-off) und ein Handoff-Block, der jeden Report auf eine feste, ≤12-zeilige Adresse verdichtet. Danach zwei Runden Right-Sizing: Reports, die ihren zweiten Durchgang überstehen — ein erneutes Review oder ein Re-Test aktualisiert Findings, Verdict und Summary an Ort und Stelle, statt eine weitere Runden-Sektion obendrauf zu stapeln (v0.7.0) — und eine einmal in der Constitution deklarierte QA-Methode, damit ein Projekt ohne browser-sichtbare Oberfläche nicht bei jedem Feature dieselbe Ausnahme neu verhandelt (v0.8.0) — dazu eine neunte Lens, accessibility (v0.9.0). Seitdem wird jede Lens, die ein Projekt einschaltet, aus einer Registry verteilt und läuft damit in jeder Phase, die sie beansprucht (v0.10.0), und /charter ist der Einstieg geworden: ein Kickoff-Interview auf einem leeren Repo, ein Discovery-Durchgang auf einem bestehenden und ein gemeinsamer Project Context, den Product Owner und Engineering Manager zitieren, statt ihn neu herzuleiten (v0.11.0). Was noch offen ist: der Situational-Lenses-Layer ist dogfooded, aber noch nicht auf einem fremden Projekt live erprobt, und die QA-Deklaration lief in diesem Repository und in steamcore, einer mit aSPARK von null gebauten ESP32-Konsole. Cores Gates sind außerdem prompt- und nicht code-durchgesetzt — genau diese Lücke schließt das Companion-Plugin aSPARK-guard. Jeder Claim hier ist live nachgewiesen, nie behauptet — die vollständige Beweiskette steht in docs/status.md.
Jedes Produkt hat eine Verantwortung und stabile Schnittstellen. Eine Schwäche in einem darf nie Änderungen in einem anderen erzwingen.
Passt das zu Ihrem Lieferprozess?
Beginnen Sie mit Core auf einem Pilotprojekt. Workflow, Wissensgraph und Policy-Packs liegen offen auf GitHub.