Ceremony proportional to consequence per change, not per project #189

New issue

Closed

opened 2026-08-16 15:41:05 +00:00 by john · 1 comment

john commented

2026-08-16 15:41:05 +00:00

Owner

The problem

stakes is a project-level dial. One value in config.json decides the model,
the effort rung, every review gate and whether deep-verify runs, for every phase
in the project until someone edits it. A README phase and an auth phase cost the
same, and the only lever is to edit the config between phases, which nobody does.

The result is that the level is set once, high, and then every cheap phase pays
for the expensive one. That is the largest single driver of run cost, and it is
paid on work that carries no consequence.

The proposal

Cadence already computes what a change touches. risk-check run resolves eight
categories over a committed range, and route.mjs resolve already returns a
surfaces list. Let the surface set the ceremony rather than the config:

stakes becomes the FLOOR, not the level. It states the minimum a project
will accept.
The phase's own declared files, read at plan time, raise it. A phase whose
files: touch nothing on a risk surface resolves lower than the project floor
allows today.
Raising stays free; lowering below the computed floor already requires an
override naming the surface (STK-03), and that rail is untouched.

Why this is a philosophy change and not a feature

Today the axis is "what kind of project is this". The proposal is "what does
this change put at risk", which is the question the routing table claims to ask
already (v2.0.0, STK-01) but answers once per project instead of once per unit
of work.

How you would know it worked

Run the same milestone twice, once at today's fixed level and once with the
computed one, and compare per-phase tokens in trace.jsonl. The win is real
only if the cheap phases got cheaper and no phase that touched a risk surface
resolved lower than it does today.

Cost

Non-trivial. It moves the resolve from a config read to something that must read
the phase's plan, which means route.mjs gains a dependency on planning state
it does not have today. Worth arguing about before writing.

## The problem `stakes` is a project-level dial. One value in `config.json` decides the model, the effort rung, every review gate and whether deep-verify runs, for every phase in the project until someone edits it. A README phase and an auth phase cost the same, and the only lever is to edit the config between phases, which nobody does. The result is that the level is set once, high, and then every cheap phase pays for the expensive one. That is the largest single driver of run cost, and it is paid on work that carries no consequence. ## The proposal Cadence already computes what a change touches. `risk-check run` resolves eight categories over a committed range, and `route.mjs resolve` already returns a `surfaces` list. Let the surface set the ceremony rather than the config: - `stakes` becomes the FLOOR, not the level. It states the minimum a project will accept. - The phase's own declared files, read at plan time, raise it. A phase whose `files:` touch nothing on a risk surface resolves lower than the project floor allows today. - Raising stays free; lowering below the computed floor already requires an override naming the surface (STK-03), and that rail is untouched. ## Why this is a philosophy change and not a feature Today the axis is "what kind of project is this". The proposal is "what does this change put at risk", which is the question the routing table claims to ask already (`v2.0.0`, STK-01) but answers once per project instead of once per unit of work. ## How you would know it worked Run the same milestone twice, once at today's fixed level and once with the computed one, and compare per-phase `tokens` in `trace.jsonl`. The win is real only if the cheap phases got cheaper and no phase that touched a risk surface resolved lower than it does today. ## Cost Non-trivial. It moves the resolve from a config read to something that must read the phase's plan, which means `route.mjs` gains a dependency on planning state it does not have today. Worth arguing about before writing.

john added the

needs-decision

proposal

labels

2026-08-16 15:41:05 +00:00

john referenced this issue

2026-08-18 00:29:33 +00:00

Scheduled subtraction: make the minimalism pass a cycle, not a reaction #194

john commented

2026-08-18 00:29:51 +00:00

Author

Owner

Decided: keep the problem, cut the mechanism. The diagnosis holds - stakes is set once, high, and every cheap phase then pays for the most expensive one. The proposed remedy does not: a computed per-phase floor derived from the risk surfaces adds a new precedence layer on top of routing, which is already the densest surface in the project (route-table, rung files, pins, retry escalation, per-trigger gate/tier/effort). That is more complexity in exactly the place that is hardest to hold.

Reduced scope, which is what this issue now tracks: a --stakes <level> override on /cad-plan (and whatever it must thread to for /cad-execute to honour it), so ONE phase can run below the project floor without editing config.json between phases. No computation, no new layer, no change to the STK-03 override rail. It gets the cost saving the issue is actually after and leaves the philosophy alone.

The 'ceremony proportional to consequence' framing is not being adopted; if the flag turns out to be used constantly and always in the same direction, that is the evidence for computing it, and this issue can grow back.

Decided: keep the problem, cut the mechanism. The diagnosis holds - `stakes` is set once, high, and every cheap phase then pays for the most expensive one. The proposed remedy does not: a computed per-phase floor derived from the risk surfaces adds a new precedence layer on top of routing, which is already the densest surface in the project (route-table, rung files, pins, retry escalation, per-trigger gate/tier/effort). That is more complexity in exactly the place that is hardest to hold. Reduced scope, which is what this issue now tracks: a `--stakes <level>` override on `/cad-plan` (and whatever it must thread to for `/cad-execute` to honour it), so ONE phase can run below the project floor without editing config.json between phases. No computation, no new layer, no change to the STK-03 override rail. It gets the cost saving the issue is actually after and leaves the philosophy alone. The 'ceremony proportional to consequence' framing is not being adopted; if the flag turns out to be used constantly and always in the same direction, that is the evidence for computing it, and this issue can grow back.

john removed the

needs-decision

label

2026-08-18 00:30:03 +00:00

john added this to the v3.5.7 milestone

2026-08-18 10:23:31 +00:00

john referenced this issue from a pull request that will close it,

2026-08-22 11:44:24 +00:00

v3.5.7 - measured, and no lever to change it #227

john closed this issue

2026-08-22 11:45:37 +00:00