aSPARK v0.18.0: a light path, cheaper roles, and what graph and guard add

Three releases ship together today: aSPARK Core v0.18.0, aspark-graph 0.8.0 and aSPARK-guard 0.3.0. They belong together in substance, but none of them needs the others. Core runs on its own. Graph and guard are additions you can pick up one at a time.

All three came out of a measurement. I ran the full loop on a real repository against a single session with no process. The full loop cost 25 to 42 times the output tokens. On two of three tasks the single session reached the same result. Sessions wrote code in the first 15 to 25 seconds, before a plan existed. And the closing summary mostly did not match the files on disk. These three releases are the answer.

What depends on what

The direction is one way. Guard and graph read what Core writes. Core reads neither; /sprint-plan, /peer-review and /demo-day check whether the graph is there. If it is missing, the gate says nothing about it and works as before.

Two contracts hold the three together:

• The template format. Graph and guard parse the artifacts Core produces from its templates (aspark-template: aspark/0.1.0). v0.18.0 adds one optional Path row to the spec and changes nothing else about the shape. Graph 0.8.0 and guard 0.3.0 read the new artifacts unchanged.
• The status values. Guard decides on approved and passed, which Core writes into the header rows. The new guard rule reads the status of plan.md. Core sets it on the light path too, because a plan is approved there as well.

If you have not installed graph and guard yet, Core offers them once after the update, in /charter or on the first /spark, and only if you have not already recorded both as installed.

New in aSPARK Core v0.18.0

A light path for small changes. Until now every change went through all five phases. Now /story-time checks six conditions at the spec gate:

1. one story with at most four acceptance criteria
2. no open or unconfirmed assumption
3. no design review needed
4. nothing touching auth, permissions, payment or personal data, no data format, no migration, nothing callers outside the repo rely on
5. no other feature's record names the same file paths
6. the constitution does not switch the light path off

Only when all six hold does it offer the light path, and you decide. The spec stays mandatory, because that is where the decisions are made. Then /spark writes a short plan of at most five tasks for you to approve. Implementation with /increment, one review and /go-live follow. /demo-day is skipped. The feature returns to the full loop as soon as a design question comes up, a sixth task is needed, a file outside the plan changes, the spec does not answer a question, or a Blocker or Major is still open after review. It says why. Turn the path off with Light path: off in constitution §11.

sonnet is the default for every role. Up to v0.17.0 the Engineering Manager and the Reviewer were pinned to opus. In the measurement those two took close to 60 percent of the tokens. From now on every role runs on sonnet. The new §11 Models & Limits in the constitution allows an override per role. For the old behaviour, add reviewer: opus and engineering-manager: opus. This lowers cost and may change review depth. Check it on your own project.

Two review rounds as the cap, one on the light path. Whatever is still open after that, /peer-review puts to you for a decision instead of running another round. Set the number with Reviewer rounds in §11.

The closing table comes from the trail. At the end /spark reads the Status rows of spec.md, plan.md, review.md, qa.md and release.md from disk. What the session believes about itself no longer counts there.

Visual QA. For features with a UI the QA Tester records one screenshot per state at wide desktop and phone width, each with an observation. A deviation from a binding design direction is at least Major. The ux lens checks that the app survives a throwing storage, a reload mid-use and a resize.

New in aspark-graph 0.8.0

impact --brief. On real runs the full impact answer was 63 to 98 KB. That did not fit in a tool result, and it mostly went unread. The brief form (MCP: brief=true) groups the same hits: one entry per story, by feature, with confidence, acceptance criteria and the changed files that reach the story. With --feature, other features' stories come first. The answer is bounded by counts and says when it was cut. The full form stays byte for byte the same.

C# as the sixth language. .cs files yield File, Class and Function nodes. using directives resolve to namespaces in the repo, best effort. Partial classes across files, generics beyond the name and Razor files are not covered.

A repository with no .cs files gets a graph that is byte for byte identical to 0.7.3's. I checked that against the old code, not just against a second build with the new one.

New in aSPARK-guard 0.3.0

Code waits for an approved plan. The new rule code-requires-approved-plan denies a Write or Edit outside .spark/ while the session has written a spec or a plan and none of those features has an approved plan. Sessions that never touch a trail are not held. This is the answer to "code before plan": Core could only ask, guard enforces it.

For projects where all work goes through aSPARK there is "plan_first_scope": "always" in .spark/guard.json. Then every code write is denied while no feature has an approved, unreleased plan. That also catches code written before any spec exists. "plan_first_exempt" lists paths the rule never holds. The rule is on (block) by default and can be set to "warn" or "off" under "rules".

How to update

• Core: the marketplace updates itself. By hand: /plugin marketplace update aspark, then restart Claude Code.
• Guard: like Core, through the same marketplace.
• Graph: pip install --upgrade aspark-graph. With uvx the latest version runs without a separate step. Rebuild the graph once afterwards.

If you want to keep a reviewer on opus, add it to §11 before your next run.

What is not proven yet

• I have not measured the light path's saving. There are dry runs per case, but no full light run through to a release yet.
• The light path, the sonnet default and the round cap have no review or QA record of their own. Their evidence is in each feature's evidence.md.
• Whether agents read impact --brief more often than the full form is not measured.
• Unlike the first three, the new guard rule was not replayed over real project history. It does not see writes through Bash, like every guard rule.
• Every rule in Core is prompt material. It makes a behaviour likely, not certain. What must be certain belongs in guard.

The full changelogs are in the releases: Core v0.18.0, aspark-graph v0.8.0, aSPARK-guard v0.3.0.