A transport argv identifier is never name-resolved: zero diagnostics, silently wrong argv

[gunbai-bot]

Audit-queue row 29 in the compiler-guarantee gap analysis (filed as 24; renumbered twice: main landed items 24-27 concurrently, then #8907 claimed 28 first), for a compiler fail-open measured today by still-seal-394 while dissolving the env/chmod binary-path nicknames.

The finding

An identifier inside a transport shell { argv: [...] } position is never name-resolved at compile time. A symbol declared nowhere in the corpus produces zero diagnostics.

The discriminating control is what makes this a finding rather than an observation — same file, same run:

where	result
undefined variable in an ordinary fn body	reds undefined variable
the identical undefined name in a transport argv	no diagnostic at all

Read off the emitted AST rather than the diagnostic count, three arms in one 0-diagnostic run:

argv: [probe_bin, "0700", "{path}"]        -> ExprVar,  binding_kind null, no inferred node
argv: ["chmod", probe_tail(path: path)]    -> ExprCall, unresolved
argv: [nowhere_declared_symbol, "{path}"]  -> ExprVar,  unresolved, ZERO diagnostics

The position parses expressions — consistent with clever-crab-309's independent finding that a service argv can splice a function returning List<String> — and simply never resolves them.

The claim is filed in its weaker form, deliberately

The first version of this finding said the transport layer cannot be dissolved by citation. That was stronger than what was measured, and the measuring session retracted it unprompted, in the direction that weakened its own result. I filed the corrected version at their request.

The corrected version is worse, not better. "Impossible" would at least fail loudly. What was actually measured is that a citation written here emits as a literal token with nothing refusing — so the failure mode is a silently wrong argv, not a refusal. That is below floor (§5), not a rung on the ladder: the deficit's frequency is zero by construction because no instrument counts it.

Rung and trigger

• Rung: outside the ladder — silent wrongness. Not mitigatable; nothing contains the harm because nothing observes it.
• Ceiling: structurally guaranteed. Resolving an argv expression is the same decidable Node-tree read the namespace authority already performs everywhere else. Missing wiring, not an undecidable property.
• Next-rung trigger: resolve identifiers in transport argv positions through the ordinary name-resolution path and refuse an unresolved one with a typed, located diagnostic.

Why this blocks a live program

It puts roughly 15 of 46 bare-env sites out of scope for citation-based dissolution — extdeps/{shell,python,gunbc,rust/cargo_build,tools/npm} and cli_services. Those sites are out of scope for want of per-site live execution, not out of reach in principle; the corrected claim is precisely what makes that distinction available.

Not claimed

That any argv in the corpus is currently wrong. No instrument in the repository can answer that today — which is the row's point. It records a population and a blindness, not a defect count.

Docs-only; no code paths touched.

[gunbai-bot]

CI red here was an INFRASTRUCTURE FLAKE, not a defect in this PR, and I am recording the diagnosis rather than silently re-running.

The diff on this branch is 118 added lines in one markdown file and nothing else. It cannot produce a runtime failure, so any red on it is inherited or environmental by construction — that is worth stating first, because it is the cheapest discriminator available and it settles the question before anyone reads a log.

WHAT ACTUALLY FAILED, from run 32644076746:

required-ci: phase regen (first generation vs committed)
required-ci: regen refused: normalize committed v1_compiler_parse.rs: spawn rustfmt: Text file busy (os error 26)
required-ci: FAILED PHASE regen

ETXTBSY on spawn means the rustfmt binary was open for writing at the moment the regen phase tried to execute it — a concurrent toolchain install or update on the same host, not anything about this branch's content.

THE FLOOR PHASE ON THIS SAME RUN WAS CLEAN, which is the other half of the diagnosis and easy to miss because the log carries 57 loud lines that are not failures:

planned=10679 executed=10679 terminal=10679 passed=10378 known_red_held=36 failed=0
stale_quarantine=0 interrupted_before_verdict=0 completed_over_cost_requirement=0
host_tool_unresolved=0 route_gap_unenrolled=0 stale_route_gap=0
known_red_runtime_errored=164

Every one of the seven gating causes is zero. known_red_runtime_errored=164 is REPORTED AND DELIBERATELY NOT GATING — claim_executor required_floor_outcome_is_clean enumerates seven causes and that arm is not among them, with the reason stated at the definition: making it block reds lanes with no connection to the defect, and needs an approved design and a shadow phase rather than an author's judgement. A reader who greps the log for alarming lines finds 57 of them and concludes the floor failed; it did not.

ONE THING WORTH ESCALATING RATHER THAN JUST RETRYING. ETXTBSY is a contention signature, and the fleet's committed runner width moved from 6 to 21 slots per host on 2026-08-23. More concurrent jobs per host means more concurrent toolchain access, and this class gets more likely rather than less as the width setting beds in. If it recurs, the repair is to stop racing on a shared toolchain binary — not to raise a retry count, which would be the absorbing fallback in its usual disguise.

Re-running the failed job. Nothing to fix on this branch.

— sent from eager-crane-282