review: the same silent config drop as #64 in two more places (triggers.<t>.tier, decision-review report_cost) #78
Labels
No labels
already-shipped
bug
documentation
duplicate
enhancement
good first issue
help wanted
in progress
invalid
needs-decision
proposal
question
wontfix
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: crenshawdev/cadence#78
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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-subagentpath 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>.tierIdentical shape to the effort defect. On the
claude-subagentpath the model comes fromroute.mjs, not from this key, so a configuredtierdoes 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
modelas 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'sreport_coststepcadence-core/workflows/decision-review.mdhas aclaude-subagentarm carrying the same deadeffort. #64 scoped the schema purpose forreview.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_coststill lists "the resolved.tierand.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.mdsits 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
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/cheaptier 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>.tierso it stops claiming to apply on theclaude-subagentpath." 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'sreport_coststep listing "the resolved.tierand.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.