Two payload promises contradict their own data: a "Permanent" hint beside a fixable reason code, and a count that is not in the reply #140

New issue

Closed

opened 2026-09-05 10:07:34 +02:00 by buildagent · 0 comments

buildagent commented

2026-09-05 10:07:34 +02:00

Member

Two findings from #51's requested-but-unavailable-package question. Filed together because they are one failure mode on one surface: the prose an agent reads first says something the structured data beside it contradicts.

1. `index_coverage` calls a fixable refusal permanent

For a path claimed only by a package the repository requests but has not installed, index_coverage returns:

verdict:          "never"
reason:           "ineligible_extension"
coverage_reasons: ["package_requested_not_installed"]
hint:             "Permanent, at any size, for this project's plugin set.
                   Use shell for this path."

The reason code is correct and present. The hint is false: this is not permanent, it is one plugin install away. And the hint is the part an agent reads first, and the part it will act on — by falling back to shell forever for a path that a single operator action would make indexable.

coverage_reasons is the only thing separating "never indexable" from "not installed yet", and it sits beside a sentence that flatly denies the distinction.

#80 S37's own doc predicted this shape, which is the useful part: the design anticipated a hint outrunning its code, and it happened anyway because the two are written in different places and nothing compares them.

The fix: the hint must be derived from the reason codes rather than written alongside them. A refusal whose coverage_reasons names an operator-actionable cause may not say "permanent", and the mutation is exactly that — assert the pairing, and make a hint that contradicts its own code go red. That is the same inversion refusal_stage_registry.rs (#72) already performs for terminal-versus-automatic convergence, so the machinery and the idiom both exist.

2. `symbol_blind_extensions` promises a count the reply does not carry

states_not_derived says, of requested_plugin_not_installed:

"the COUNT of such packages rides beside this block as packages_requested_not_installed"

It does not. That field is not in project_overview's reply.

A reader following that sentence looks for a field, finds nothing, and has to decide whether the count is zero or the promise is stale — which is precisely the absent-versus-zero ambiguity the three-state discipline exists to remove, created here by documentation rather than by code.

The fix is either direction, but it must be one of them: emit the count (subject to the budget note below), or correct the sentence to name where the information actually is. Then gate the pairing — a states_not_derived entry that names a field must name one the payload can carry.

The budget constraint on both

project_overview is at 4293 of 4300 tokens. Deriving the hint costs nothing (it replaces prose with prose). Adding packages_requested_not_installed does not fit without a trim, so the honest options are to correct the sentence, or to put the count where #100 put the store inventory — on the resource rather than the tool reply. Trim rather than raise, as the payload tests argue themselves.

#51 (found here), #72 (the registry idiom that would catch #1 generically), #124 and #136 (the same family: a refusal the surface fails to communicate), #100 (the tool/resource split that solved the same budget problem).

Two findings from #51's requested-but-unavailable-package question. Filed together because they are one failure mode on one surface: **the prose an agent reads first says something the structured data beside it contradicts.** ## 1. `index_coverage` calls a fixable refusal permanent For a path claimed only by a package the repository **requests but has not installed**, `index_coverage` returns: ``` verdict: "never" reason: "ineligible_extension" coverage_reasons: ["package_requested_not_installed"] hint: "Permanent, at any size, for this project's plugin set. Use shell for this path." ``` The reason code is **correct and present**. The hint is **false**: this is not permanent, it is one `plugin install` away. And the hint is the part an agent reads first, and the part it will act on — by falling back to shell forever for a path that a single operator action would make indexable. `coverage_reasons` is the *only* thing separating "never indexable" from "not installed yet", and it sits beside a sentence that flatly denies the distinction. **#80 S37's own doc predicted this shape**, which is the useful part: the design anticipated a hint outrunning its code, and it happened anyway because the two are written in different places and nothing compares them. **The fix**: the hint must be derived from the reason codes rather than written alongside them. A refusal whose `coverage_reasons` names an *operator-actionable* cause may not say "permanent", and the mutation is exactly that — assert the pairing, and make a hint that contradicts its own code go red. That is the same inversion `refusal_stage_registry.rs` (#72) already performs for terminal-versus-automatic convergence, so the machinery and the idiom both exist. ## 2. `symbol_blind_extensions` promises a count the reply does not carry `states_not_derived` says, of `requested_plugin_not_installed`: > *"the COUNT of such packages rides beside this block as `packages_requested_not_installed`"* It does not. That field is not in `project_overview`'s reply. A reader following that sentence looks for a field, finds nothing, and has to decide whether the count is zero or the promise is stale — which is precisely the absent-versus-zero ambiguity the three-state discipline exists to remove, created here by documentation rather than by code. **The fix** is either direction, but it must be one of them: emit the count (subject to the budget note below), or correct the sentence to name where the information actually is. Then gate the pairing — a `states_not_derived` entry that names a field must name one the payload can carry. ## The budget constraint on both `project_overview` is at **4293 of 4300 tokens**. Deriving the hint costs nothing (it replaces prose with prose). Adding `packages_requested_not_installed` does not fit without a trim, so the honest options are to correct the sentence, or to put the count where #100 put the store inventory — on the resource rather than the tool reply. **Trim rather than raise**, as the payload tests argue themselves. ## Related #51 (found here), #72 (the registry idiom that would catch #1 generically), #124 and #136 (the same family: a refusal the surface fails to communicate), #100 (the tool/resource split that solved the same budget problem).