review: the same silent config drop as #64 in two more places (triggers.<t>.tier, decision-review report_cost) #78

Open
opened 2026-07-28 19:22:57 +00:00 by crenshawdev · 1 comment
crenshawdev commented 2026-07-28 19:22:57 +00:00 (Migrated from github.com)

Surfaced while fixing #64 and deliberately left out of it, so the fix stayed scoped. Same defect shape in two more places: a config value that is read, resolved, and then dropped on the claude-subagent path with nothing said.

#64 established the principle: "Either the configured value reaches the backend, or the key does not claim it does. A key that is read, resolved, and then dropped with no warning is the worst of the three."

1. review.triggers.<t>.tier

Identical shape to the effort defect. On the claude-subagent path the model comes from route.mjs, not from this key, so a configured tier does nothing.

It is slightly less bad than the effort case, which is why #64 left it: the vocabulary (flagship / balanced / cheap) at least self-identifies as provider vocabulary, so a reader has a hint that it belongs to the cross-model arm. That is a weak defence, not a good one.

Sequencing question that should be settled before anyone writes code here. #75 proposes routing every role to opus and keeping model as an escape hatch. If that lands, the model axis collapses and this key's meaning may collapse with it, in which case the honest fix is deletion rather than scoping. Decide #75 first; this may resolve itself into a smaller change or none at all.

2. decision-review.md's report_cost step

cadence-core/workflows/decision-review.md has a claude-subagent arm carrying the same dead effort. #64 scoped the schema purpose for review.decision_review.effort, so the key now tells the truth at the point of setting, but the workflow prose was left untouched.

The specific problem: report_cost still lists "the resolved .tier and .effort" unconditionally, which reads to a user as though both applied to the run they just paid for. So the schema now says the value is cross-model only, and the workflow still reports it as though it were honoured. Those two now disagree.

This one has a blocker of its own. decision-review.md sits at exactly 9436 bytes against a 9436 budget, verified. Zero headroom. So the fix cannot simply add a clarifying clause; it needs either a budget increase justified on its merits or an equivalent trim elsewhere in the file. That is why #64 stopped here rather than doing half of it.

What the fix looks like

Same as #64: scope the key where it is set, and name the degradation where it fires. No new mechanism, and explicitly not a half-built version of #63's rung files.

  • #64, which fixed the first instance and established the pattern.
  • #75, which may make item 1 moot.
  • #63, which is the only thing that makes any of these keys actually work rather than merely honest.
Surfaced while fixing #64 and deliberately left out of it, so the fix stayed scoped. Same defect shape in two more places: a config value that is read, resolved, and then dropped on the `claude-subagent` path with nothing said. #64 established the principle: *"Either the configured value reaches the backend, or the key does not claim it does. A key that is read, resolved, and then dropped with no warning is the worst of the three."* ## 1. `review.triggers.<t>.tier` Identical shape to the effort defect. On the `claude-subagent` path the model comes from `route.mjs`, not from this key, so a configured `tier` does nothing. It is slightly less bad than the effort case, which is why #64 left it: the vocabulary (`flagship` / `balanced` / `cheap`) at least self-identifies as provider vocabulary, so a reader has a hint that it belongs to the cross-model arm. That is a weak defence, not a good one. **Sequencing question that should be settled before anyone writes code here.** #75 proposes routing every role to opus and keeping `model` as an escape hatch. If that lands, the model axis collapses and this key's meaning may collapse with it, in which case the honest fix is deletion rather than scoping. Decide #75 first; this may resolve itself into a smaller change or none at all. ## 2. `decision-review.md`'s `report_cost` step `cadence-core/workflows/decision-review.md` has a `claude-subagent` arm carrying the same dead `effort`. #64 scoped the schema purpose for `review.decision_review.effort`, so the key now tells the truth at the point of setting, but the workflow prose was left untouched. The specific problem: `report_cost` still lists "the resolved `.tier` and `.effort`" unconditionally, which reads to a user as though both applied to the run they just paid for. So the schema now says the value is cross-model only, and the workflow still reports it as though it were honoured. Those two now disagree. **This one has a blocker of its own.** `decision-review.md` sits at exactly 9436 bytes against a 9436 budget, verified. Zero headroom. So the fix cannot simply add a clarifying clause; it needs either a budget increase justified on its merits or an equivalent trim elsewhere in the file. That is why #64 stopped here rather than doing half of it. ## What the fix looks like Same as #64: scope the key where it is set, and name the degradation where it fires. No new mechanism, and explicitly **not** a half-built version of #63's rung files. ## Related - #64, which fixed the first instance and established the pattern. - #75, which may make item 1 moot. - #63, which is the only thing that makes any of these keys actually work rather than merely honest.
crenshawdev commented 2026-07-28 19:51:31 +00:00 (Migrated from github.com)

Overlap with #81: item 1 may resolve there rather than here

#81 proposes replacing the routing axis question (spend → stakes) and, with it, the flagship/balanced/cheap tier vocabulary that item 1 of this issue is about.

That changes what the right fix is. Item 1 currently reads as "scope review.triggers.<t>.tier so it stops claiming to apply on the claude-subagent path." If #81 lands, the key's vocabulary is replaced wholesale and the honest fix is deletion or redefinition rather than scoping. Doing the scoping work first means doing it twice.

So item 1 should wait on #81's disposition. Not blocked on it landing, blocked on the decision: if #81 is accepted, fold item 1 into it; if #81 is rejected or substantially altered, item 1 comes back here and gets scoped as originally written.

Item 2 is unaffected and can proceed independently. decision-review.md's report_cost step listing "the resolved .tier and .effort" unconditionally is a straightforward disagreement between the workflow prose and the schema purpose that #64 already corrected. That is true regardless of what the tier vocabulary becomes. Its blocker is unchanged and unrelated: the file sits at exactly 9436 bytes against a 9436 budget, verified, so the fix needs a justified budget increase or an equivalent trim.

Relabeling this issue as effectively single-item until #81 is settled.

## Overlap with #81: item 1 may resolve there rather than here #81 proposes replacing the routing axis question (spend → stakes) and, with it, the `flagship`/`balanced`/`cheap` tier vocabulary that **item 1 of this issue** is about. That changes what the right fix is. Item 1 currently reads as "scope `review.triggers.<t>.tier` so it stops claiming to apply on the `claude-subagent` path." If #81 lands, the key's vocabulary is replaced wholesale and the honest fix is deletion or redefinition rather than scoping. Doing the scoping work first means doing it twice. **So item 1 should wait on #81's disposition.** Not blocked on it landing, blocked on the decision: if #81 is accepted, fold item 1 into it; if #81 is rejected or substantially altered, item 1 comes back here and gets scoped as originally written. **Item 2 is unaffected and can proceed independently.** `decision-review.md`'s `report_cost` step listing "the resolved `.tier` and `.effort`" unconditionally is a straightforward disagreement between the workflow prose and the schema purpose that #64 already corrected. That is true regardless of what the tier vocabulary becomes. Its blocker is unchanged and unrelated: the file sits at exactly 9436 bytes against a 9436 budget, verified, so the fix needs a justified budget increase or an equivalent trim. Relabeling this issue as effectively single-item until #81 is settled.
Sign in to join this conversation.
No description provided.