aSPARK v0.18.0: ein leichter Pfad, günstigere Rollen, und was Graph und Guard dazu liefern

Heute erscheinen drei Releases zusammen: aSPARK Core v0.18.0, aspark-graph 0.8.0 und aSPARK-guard 0.3.0. Sie hängen inhaltlich zusammen, aber keines braucht die anderen. Core läuft allein. Graph und Guard sind Ergänzungen, die Sie einzeln dazunehmen können.

Der Anlass für alle drei war eine Messung. Ich habe den vollen Loop auf einem echten Repository gegen eine einzelne Session ohne Prozess laufen lassen. Der volle Loop kostete das 25- bis 42-Fache an Output-Tokens. Auf zwei von drei Aufgaben kam die einzelne Session zum selben Ergebnis. Sessions schrieben Code in den ersten 15 bis 25 Sekunden, bevor ein Plan existierte. Und die Zusammenfassung am Ende stimmte meistens nicht mit den Dateien überein. Die drei Releases sind die Antwort darauf.

Was wovon abhängt

Die Richtung ist eindeutig. Guard und Graph lesen, was Core schreibt. Core liest keines der beiden, sondern fragt in /sprint-plan, /peer-review und /demo-day nach, ob der Graph da ist. Fehlt er, schweigt das Gate dazu und arbeitet wie vorher.

Zwei Verträge halten die drei zusammen:

• Das Template-Format. Graph und Guard parsen die Artefakte, die Core aus seinen Templates erzeugt (aspark-template: aspark/0.1.0). v0.18.0 fügt der Spec eine optionale Zeile Path hinzu und ändert sonst nichts an der Form. Graph 0.8.0 und Guard 0.3.0 lesen die neuen Artefakte ohne Anpassung.
• Die Status-Werte. Guard entscheidet an approved und passed, die Core in die Kopfzeilen schreibt. Die neue Guard-Regel liest den Status von plan.md. Den setzt Core auch auf dem leichten Pfad, weil auch dort ein Plan freigegeben wird.

Wenn Sie Graph und Guard noch nicht installiert haben, bietet Core sie Ihnen nach dem Update einmal an. Das passiert in /charter oder beim ersten /spark und nur, wenn Sie nicht schon beide als installiert eingetragen haben.

Neu in aSPARK Core v0.18.0

Ein leichter Pfad für kleine Änderungen. Bisher lief jede Änderung durch alle fünf Phasen. Jetzt prüft /story-time am Spec-Gate sechs Bedingungen:

1. eine Story mit höchstens vier Akzeptanzkriterien
2. keine offene oder unbestätigte Annahme
3. kein Design-Review nötig
4. nichts an Auth, Berechtigungen, Zahlung oder personenbezogenen Daten, kein Datenformat, keine Migration, nichts, worauf Aufrufer außerhalb des Repos bauen
5. keine andere Akte nennt dieselben Dateipfade
6. die Konstitution schaltet den leichten Pfad nicht ab

Nur wenn alle sechs halten, bietet es den leichten Pfad an, und Sie entscheiden. Die Spec bleibt Pflicht, weil dort die Entscheidungen fallen. Danach schreibt /spark einen kurzen Plan mit höchstens fünf Aufgaben, den Sie freigeben. Es folgen die Umsetzung mit /increment, ein Review und /go-live. /demo-day entfällt. Das Feature geht zurück in den vollen Loop, sobald eine Designfrage auftaucht, eine sechste Aufgabe nötig wird, eine Datei außerhalb des Plans geändert wird, die Spec eine Frage nicht beantwortet oder nach dem Review ein Blocker oder Major offen ist. Es sagt dabei, warum. Abschalten können Sie den Pfad mit Light path: off in §11 der Konstitution.

sonnet als Standard für alle Rollen. Bis v0.17.0 liefen Engineering Manager und Reviewer fest auf opus. Auf diese beiden entfielen in der Messung knapp 60 Prozent der Tokens. Ab jetzt läuft jede Rolle auf sonnet. Der neue Abschnitt §11 Models & Limits in der Konstitution erlaubt eine Ausnahme pro Rolle. Wer das alte Verhalten will, schreibt reviewer: opus und engineering-manager: opus hinein. Das senkt die Kosten und kann die Tiefe eines Reviews verändern. Prüfen Sie das an Ihrem eigenen Projekt.

Zwei Review-Runden als Obergrenze, auf dem leichten Pfad eine. Was danach offen ist, legt Ihnen /peer-review zur Entscheidung vor, statt eine weitere Runde zu drehen. Die Zahl stellen Sie in §11 mit Reviewer rounds ein.

Die Abschlusstabelle kommt aus dem Trail. /spark liest am Ende die Status-Zeilen von spec.md, plan.md, review.md, qa.md und release.md von der Platte. Was die Session über sich selbst glaubt, zählt dort nicht mehr.

Visuelle QA. Bei Features mit Oberfläche hält der QA-Tester für jeden Zustand einen Screenshot auf breitem Desktop und auf Telefon fest, jeweils mit einer Beobachtung. Eine Abweichung von einer verbindlichen Designvorgabe ist mindestens Major. Die ux-Lens prüft, ob die Anwendung einen werfenden Storage, einen Reload mitten in der Arbeit und ein Resize übersteht.

Neu in aspark-graph 0.8.0

impact --brief. Die volle Antwort von impact war in echten Läufen 63 bis 98 KB groß. Das passte nicht in ein Werkzeugergebnis, und meist wurde sie nicht gelesen. Die kurze Form (MCP: brief=true) gruppiert dieselben Treffer: ein Eintrag pro Story, nach Feature sortiert, mit Konfidenz, Akzeptanzkriterien und den geänderten Dateien, die zur Story führen. Mit --feature stehen die Stories anderer Features vorn. Die Antwort ist nach Anzahl begrenzt und sagt, wenn sie gekürzt hat. Die volle Form bleibt Byte für Byte gleich.

C# als sechste Sprache. .cs-Dateien ergeben File-, Class- und Function-Knoten. using-Direktiven werden auf Namespaces im Repo aufgelöst, nach bestem Bemühen. Partielle Klassen über mehrere Dateien, Generics über den Namen hinaus und Razor-Dateien sind nicht abgedeckt.

Ein Repository ohne .cs-Dateien bekommt einen Graphen, der Byte für Byte dem von 0.7.3 entspricht. Das habe ich gegen den alten Code geprüft, nicht nur gegen einen zweiten Build mit dem neuen.

Neu in aSPARK-guard 0.3.0

Code wartet auf einen freigegebenen Plan. Die neue Regel code-requires-approved-plan lehnt ein Write oder Edit außerhalb von .spark/ ab, solange die Session eine Spec oder einen Plan geschrieben hat und keines dieser Features einen approved-Plan hat. Sessions, die nie einen Trail anfassen, hält sie nicht auf. Das ist die Antwort auf „Code vor Plan“: Core konnte nur darum bitten, Guard setzt es durch.

Für Projekte, in denen alle Arbeit durch aSPARK läuft, gibt es "plan_first_scope": "always" in .spark/guard.json. Dann ist jeder Code-Schreibvorgang gesperrt, solange kein Feature einen freigegebenen, noch nicht releasten Plan hat. Das fängt auch Code ab, der vor jeder Spec entsteht. Mit "plan_first_exempt" nehmen Sie Pfade aus, die die Regel nie halten soll. Die Regel ist standardmäßig an (block) und lässt sich unter "rules" auf "warn" oder "off" stellen.

So aktualisieren Sie

• Core: Der Marketplace aktualisiert sich selbst. Von Hand geht es mit /plugin marketplace update aspark, danach Claude Code neu starten.
• Guard: wie Core, über denselben Marketplace.
• Graph: pip install --upgrade aspark-graph. Mit uvx läuft die neueste Version ohne eigenen Schritt. Bauen Sie den Graphen danach einmal neu.

Wer einen Prüfer auf opus behalten will, trägt das vor dem nächsten Lauf in §11 ein.

Was noch nicht belegt ist

• Die Ersparnis des leichten Pfads habe ich nicht gemessen. Es gibt Probeläufe pro Fall, aber noch keinen vollen leichten Durchlauf bis zum Release.
• Der leichte Pfad, das sonnet-Standardmodell und die Begrenzung der Runden haben keine eigene Review- und QA-Akte. Ihre Belege stehen in evidence.md der jeweiligen Features.
• Ob Agenten impact --brief häufiger lesen als die volle Form, ist nicht gemessen.
• Die neue Guard-Regel ist nicht über echte Projekthistorie nachgespielt worden, anders als die ersten drei. Schreibvorgänge über Bash sieht sie nicht, wie keine Guard-Regel.
• Alle Regeln in Core sind Prompt-Material. Sie machen ein Verhalten wahrscheinlich, nicht sicher. Was sicher sein muss, gehört in den Guard.

Die vollständigen Changelogs stehen in den Releases: Core v0.18.0, aspark-graph v0.8.0, aSPARK-guard v0.3.0.