Unbreak main: escape the literal braces in the LocalRead admission reason

[gunbai-bot]

What

One escape. main has been red on the fleet job since #8148 landed:

dag/gunbc/explicit_witness_admission.dag:192:181: error: undefined variable 'LocalRead'

The admission row's reason prose contains Classified{LocalRead}. In .dag, {ident opens a string interpolation, so the compiler read LocalRead as a variable and refused an undefined name. The brace is literal, and a literal brace is \{ — the escape the language already provides. DESIGN's 2026-07-24 ruling is explicit that the escape is the fix and respelling the prose to dodge the parser is the workaround; this takes the escape. It is the only such site in the file.

Evidence — both directions

A fix that only ever shows green proves nothing about this error, so the control was run in reverse too:

	undefined variable 'LocalRead'	compile stages
brace unescaped (RED control)	1	reconcile + analyses complete, then refuse
brace escaped (fixed)	0	reconcile + analyses complete

The fixed run still exits 1, on scoped run function 'explicit_witness_admission_rows' has no unique runtime-selected declaration identity — an artifact of probing a row-producer as a run entry, unrelated to resolution of this file. Resolution succeeding is what the fleet job needs.

The fleet step itself (live_deploy/apply.dag live_deploy_apply_srv1_wet) was not run locally: it is wet and mutates srv1. The error is a resolution error reached from any entry whose closure includes the file, so the file was compiled directly instead.

The part this PR does not fix

#8148's own per-PR CI passed with this defect present (run 31528769968), and on the failing main run the ci job is green on the same commit the fleet job refuses. So a parse-level defect survives a full green PR run and only detonates post-merge, on the deploy path.

That is the more valuable finding and it needs its own change. I have a hypothesis for the mechanism — an entrypoint divergence where the witness executor tolerates what gunbc run refuses — but I have not measured it, so I am not asserting it here. Note the shape regardless: the file whose purpose is registering expected-red probes sits in a blind spot where the per-PR path never compiles it strictly.

Provenance

#8148 is mine. The break is mine, and I was the one who merged it unchanged.

[gunbai-bot]

Measured: the per-PR gap is an entrypoint divergence, not a selection miss

The PR body said I had a hypothesis and had not measured it. I have now, and it is confirmed — posting the receipt rather than leaving an unsupported cause in the description.

Discriminating pair, identical broken bytes, both binaries freshly built:

entrypoint	verdict
gunbc run (what the fleet deploy step executes)	refuses — 192:181: error: undefined variable 'LocalRead'
claim_batch on exact_witness_admission_witness_test, which imports the file	exit 0, PASS, 0 LocalRead errors, 0 resolve failures

So it is not that the file went unselected — the witness resolves it and greens anyway. That is why #8148's CI passed (run 31528769968, a genuine pass; the merge commit has no run of its own) while the fleet job refuses the same commit the ci job calls green.

Mechanism, stated as the hypothesis it still is: the witness never demands that data row, so the interpolation is plausibly never forced under the witness path while gunbc run resolves strictly. What is measured is the divergence; lazy-vs-strict is not, and I am not upgrading it.

Method note, since it took three attempts. My first two runs of this experiment were vacuous: a stale claim_batch (pre-#8162, missing dependency_resolution_facts) died on an unrelated resolve error before reaching the file, and reported 0 errors — zero found because zero looked. The run above gates on a binary-freshness receipt (mtime Aug 11 06:19 → Aug 12 02:59, size changed) and counts resolve failed separately, so "no error" and "never got there" cannot be confused.

Not fixed here, deliberately. This is a distinct cause from the escape, and a real one: the same divergence is already recorded for §4c annotation grain, so this is the second class, and how far it extends is still unmapped. A gate that answers does this tree admit through a different code path than the one that later executes it hands out verdicts that do not transfer. Worth its own change.

— sent from gentle-dove-143

[gunbai-bot]

Correction to my previous comment — and to its terminology

Two fixes to what I wrote above. Both were raised in review; I verified each myself before accepting it.

1. "#8148's merge commit has no run of its own" is FALSE. It had one, and it was cancelled:

run 31536191630
  head  = 2b5ed94b09b098e6ef1551ab74b3f5aed8271b19   (#8148 merge SHA)
  event = push
  conclusion = CANCELLED   2026-08-11T21:05:15Z

The accurate statement separates introduction from first terminal observation:

#8148 introduced the broken bytes. 49402500b65d… was the first SHA with a terminal red receipt (ci SUCCESS, fleet FAILURE). The intervening exact-main runs were cancelled or otherwise nonterminal.

Worth naming how I got it wrong, because the instrument is load-bearing and quietly bad: gh run list --commit <sha> returns empty for this SHA even at full 40 characters, while gh run view 31536191630 resolves it immediately. I read that silence as absence. It is the same failure shape as the three vacuous verifications in this PR's history — a query that never found anything reported as a subject that never existed — and it does not change the diagnosis, only the history.

2. "Parse-level defect" is imprecise. Parsing succeeded: the tokenizer correctly recognized {LocalRead} as an interpolation, and resolution then rejected LocalRead as an undefined name. The accurate term is a strict resolution/interpolation defect. This matters for the follow-up, because it locates the divergence at resolution strictness rather than at the grammar.

Neither correction touches the diff. No further code edits to this PR.

— sent from gentle-dove-143