RESTORE WAVE B (measurement): un-quarantine the 12 modules / 130 rows whose costs were CENSORED at the 1552ms deadline ('cost at least 1553ms' — a lower bound, never observed). #8491 paid the shared MultiEntryIndex in preparation and main's slowest row is now 978ms, so restoration IS the measurement

[gunbai-bot]

THIS PR IS RED ON PURPOSE. DO NOT FIX THE FAILING WITNESSES. 12 BLOCKED, 0 ACTIONABLE, TWO UNRELATED ROOTS.

12 failing rows split 11 + 1, and BOTH groups are blocked on work external to this branch — neither is actionable here, and the two blockers are unrelated to each other. Do not conflate them, do not chase either to green, do not re-quarantine anything.

Root A — 11 where_refinement_enforcement_witness rows, blocked on the stale stage0 mirror. These are correct and are the only executing evidence that #8513's merged wall fix is absent from the stage0 seed (expr_is_any_literal is present in src/v1/*.dag, ABSENT from src/v1/stage0/src/*.rs) — the running compiler currently accepts an Int literal into a String-derived refined field. This PR REVEALS this fail-open, it does not introduce it: on main the witness file lives under dag/test/claim/long/where_refinement_enforcement_witness_test.dag, so it never enters per-PR discovery and main reads green (five consecutive clean witness runs) while the wall sits off underneath it. Un-quarantining the file — Wave B's whole purpose — is what makes the fail-open observable. They go green with no witness edit once (1) tidy-ram-195's refinement-coercion fix (#8608) lands, then (2) the stage0 mirror is repaired, in that required order and no other. A fleet-wide hold currently blocks every regen-derived measurement on top of main until step 1 lands, so there is no route to green here before then, and none through this branch.

Root B — 1 gauntlet_lane_enrollment_witness.witness_rehomed_rows_are_cadence_enrolled row, blocked on a deleted executor, unrelated to Root A. 3 of the 7 identities this witness checks have no CommitCheckEnrollment row in commit_gate_roster at all — only a 2026-07-25 prose note promising a move to the falsifier cadence that was never actuated. Authoring that missing roster row would not fix this: it would enrol those identities onto FalsifierCadenceJob, whose only executor (falsifier.yml) was deleted in the 2026-08-15 floor cut, producing enrolment with no coverage — a row that reads as closed while remaining exactly as uncovered as today. This blocker has no scheduled resolution and, as far as this branch knows, no current owner; it does not share Root A's mirror-repair ETA and should not be assumed to resolve alongside it.

root_d_checkpoint_scalar_declared_arity_witness_holds (completed_over_cost_requirement, not a FAIL) is separately dispositioned as Class 3 below — a genuine cost finding plus a safety-deadline enforcement gap, also not actionable on this branch.

This PR is parked on external work it cannot push forward. It stays open and red as the accurate record of what Wave B's restoration revealed.

Worker attestation

• Title describes the change (not the session id or branch).
• PR body summarises what and why.
• Tests run: named below.
• No commits on this branch are surprises.
• No secrets / credentials / large binaries staged.

Summary

Wave B (measurement restoration): un-quarantine 12 modules / 128 identities that were held under long/-prefix quarantine homes purely because their measured cost was CENSORED at the prior 1552ms deadline (required_floor_claim_cost_line_ms) — a lower bound that was never an observed number. #8491 paid the shared MultiEntryIndex/module-path-index preparation these rows draw on, and main's slowest row is now 978ms, so the restoration itself is the measurement: run these 12 modules on the required floor and read what actually happens.

transport_script_wall_compile_red_test.dag (13th candidate) is held back per parent direction — a measured compile_dag_rust_emit_check first-toucher attribution specimen (1394ms -> 48963ms, 35x, same content, different execution order), dispatched as its own lane rather than restored here.

Result of running it: three red classes, none of them a Wave B rename defect. This PR stays red and is not being repaired, re-quarantined, or enrolled to make a number move — each class below is a real, independently-verified finding, and remediation is not this branch's to perform.

Class 1 — where_refinement_enforcement_witness (11 failures): the wall is genuinely down, not a stale witness

Verified BY CONSTRUCTION, not by reading the witness: hand-wrote two independent red fixtures (a base-kind Int-into-branded-String mismatch through a refined-alias chain, and a base-kind String-into-Nat-refined mismatch) and compiled them directly with the actual running compiler binary. Both were ACCEPTED with only advisory diagnostics and 0 blocking errors — full Rust emission succeeded in both cases.

Root cause (confirmed against source): #8513 ("Fix refinement wall: base-type mismatch through refined-alias chains composes, arbitrary depth"), merged to main as 66dbdb1143, lands its fix (expr_is_any_literal and the routing it drives) only in src/v1/00_core.dag / src/v1/04_infer.dag — the .dag substrate authority. It touches zero .rs files; its own commit message says the stage0 Rust regen is "excluded from this commit pending a clean regen against merged main." expr_is_any_literal is present in the .dag sources and absent from src/v1/stage0/src/*.rs. The running compiler is built from that stale seed, so the merged fix has no path to execution. The 11 failing witnesses are correct: they are the only executing evidence in the tree that a merged safety fix is currently inert. Remedy is a stage0 regen — parent has taken this over; not touched further on this branch.

Class 2 — gauntlet_lane_enrollment_witness.witness_rehomed_rows_are_cadence_enrolled (1 failure): pre-existing gap, out of scope for this branch

The witness checks pure roster enrolment (list membership over commit_gate_roster / falsifier_substrate_long_lane_rows), never execution — confirmed structurally, both backing predicates are any(list, e => e.function == f) with no receipt/timestamp read.

It fails for the first time here because the witness file itself is one of Wave B's 12 restored modules (moved out of its long/ quarantine home) — this is its first-ever per-PR execution, not a change in what it observes. What it finds on first run: 3 of its 7 named identities (lens_affected_set_provenance_producer_rejects_malformed_ingest_holds, _rejects_beyond_surface_ingest_holds, _coverage_receipt_holds) have no roster row at all in commit_gate_roster. A 2026-07-25 prose note (commit_workflow.dag provenance_wall_cadence_rehome_risk) declares an "ACCEPTED RISK" moving these three from per-PR to the falsifier cadence — the note was written and the roster row implementing the move never was. Specification without execution, one level up: the intent lives in a String, not a construction.

Worse than it looks: even if the missing roster row were authored today, it would enrol these identities onto FalsifierCadenceJob, whose only executor (falsifier.yml) was deleted in the 2026-08-15 floor cut — FalsifierSubstrateLongLane/FalsifierCadenceJob is DeclaredCadenceUnrealized. Authoring the row now would produce enrolment with no coverage, which reads as closed while remaining exactly as uncovered as today. The correct fix is a decision (return the three identities to per-PR enrolment, or declare the gap honestly with the cadence's absence named) — not an edit, and not this branch's to make. Parent is routing it.

Class 3 — root_d_checkpoint_scalar_declared_arity_witness_holds (1 completed_over_cost_requirement): genuine cost, plus a safety-deadline enforcement gap it exposed

Cost is intrinsic, not inherited: the corpus-wide shared fills this row draws on (module_path_index etc.) all completed during strict-preparation, ~11 minutes before this witness's own timed claim window opened, so none of its cost is first-toucher attribution riding another row's fault (unlike transport_script). The witness makes two back-to-back compile_dag_rust_emit_check calls, each a full frontend->normalize->reconcile->analyses->emit pass on its own distinct fixture, with no duplicate call site found elsewhere in the corpus for either fixture's exact content.

What the numbers exposed, unrelated to whether this witness should be renamed: both of the 2026-08-19 budget-policy cut's independent safety deadlines were crossed on this single completed claim — CPU 60317ms against required_floor_claim_cpu_safety_limit_ms() = 5000ms, and wall 60487ms against required_floor_claim_wall_safety_limit_ms() = 10000ms — yet the claim reached a normal COMPLETED verdict (completed_over_cost_requirement), not interrupted_before_verdict/SafetyInterrupted. required_floor.dag's own comment states "crossing either blocks" and "the occurrence is a SafetyInterrupted claim" — that did not happen here. Likely cause (not yet confirmed further, not remediated): the deadlines are documented as cooperative, and compile_dag_rust_emit_check is a single opaque blocking host call with no cooperative checkpoint inside it — a cooperative deadline can only fire where running code checks in, so an ~30s single call can blow through both limits invisibly and only get measured once it already returned a verdict. This is a rung-honesty gap in the safety-deadline mechanism itself (advertised as "blocks", observed to "measure"), reported to parent for routing — not fixed on this branch.

Variance datum, recorded rather than reconciled: on a re-run after the merge (job 96241142840), this same witness completed at CPU 54757ms, against 60317ms in the pinned adjudication run — a 9% spread on an exact completed CPU figure, same subject, untouched between runs. This is not a discrepancy to explain away; it is another instance of the measurement noise pattern that retired the old 1552ms cost-line deadline in the first place (that deadline's own calibration runs read 1792 / 1928 / 1579ms on an untouched witness). Treat both numbers as data points from the same distribution, not as two claims to reconcile.

Test plan

• CI required-floor run (32301212975 / job 96223916265) on this branch: planned/executed include the 12 restored modules; tail summary reports failed=12 (the 11 Class 1 identities + the 1 Class 2 identity) and completed_over_cost_requirement=1 (Class 3). Reconciled against the tool's own authoritative tail-block summary, not the raw per-line grep (which overcounts via the 306 enrolled known_red_held rows that also print FAILED in ...ns as their designed outcome).
• Class 1: direct construction — built two independent red fixtures by hand, compiled with the actual gunbc binary (CTRL_BUILD_MODE=local cargo build -p v1-compiler --bin gunbc, small targeted build) via gunbc compile; both fixtures were incorrectly accepted (0 blocking errors), confirming the wall is live-down rather than the witness being stale.
• Class 2 / Class 3: read-only source/log investigation, no compiles required beyond the Class 1 constructions above.
• No repair, re-quarantine, or roster edit performed on any of the three classes.

Adjudication receipt is pinned to commit d984c357da3

The numbers above (planned=9814, failed=12, completed_over_cost_requirement=1, the 128-identity delta, the eleven where_refinement rows) are a fact about commit d984c357da3 — CI run 32301212975 / job 96223916265 — and about that commit specifically, not about "this branch" in general.

This branch has since taken one merge commit (5219c6d8e65, merging origin/main at e0c5e254445) to keep it current and mergeable. That merge does not re-open or refresh the measurement. The required floor was not re-run as part of it; the merge was resolved textually, and the one real conflict (on the loudness witness's quarantine note) is a citation relocation, not a content or rename change — see below. Any future merge commits on this branch carry the same rule: they integrate main, they do not re-measure Wave B.

The one conflict, and how it was resolved: main had independently landed #8566 (e0c5e254445), which appended a DECIDED ATTRIBUTION-3 verdict to the pre-Wave-B, long/-prefixed loudness witness file. Wave B's own split (this branch, pre-merge) had already moved the identity that verdict is about (red_seed_runner_failure_detail_projects_located_receipt) out of that file and into extdeps_scope_placement_gate_seed_runner_loudness_witness_test.dag. The two notes were not competing conclusions — both true, about different files, colliding only because main had not seen the split yet. Resolved per parent's explicit direction: kept this branch's rename and split note on the loudness file untouched, and relocated main's DECIDED note verbatim onto the seed_runner file that now actually holds the identity it is about, with a short provenance preface explaining the relocation. No rename, module declaration, live_tree_disposition, or witness assertion was altered by this resolution.

One thing noted but intentionally not acted on here: #8566's verdict is prose inside a data ... String note. It is expected to be re-expressed in the typed SharedFillDisposition carrier (#8455) by a separate lane already tasked with that migration — this PR relocates the note as-is and does not perform that typing.

[gunbai-bot]

Queue hold — authority-touching PRs (operator ruling, 2026-08-20)

This PR modifies .dag authority files under src/v1/ or dag/, so it is held from merging until the stage0 regen repair lands. It is one of 32 open PRs in that set.

This is a queue hold, not a judgement on the change. Nothing here is wrong and nothing is being asked of you. The operator is merging manually, so the hold is enforced at the merge hand — you do not need to do anything to comply, and this comment is a courtesy so you are not surprised by a merge that does not come.

Why the hold exists. A regeneration repair's entire content is "the derived files match the authorities as of now." Its correctness is indexed to a moment, so any authority merge landing while it is in flight invalidates part of it — silently, without touching a line its author wrote. Against a moving queue it cannot converge, because the target moves faster than build → regen → push → CI. The remedy has to be a queue policy rather than more effort from the repair author.

Expected duration: short. The repair (session/valiant-pike-161-regen-repair, gunbc#8677) is pushed and under verification by execution — cargo check --all-targets --workspace, remote, with a control run proving the remote compiler was actually reached. A clean check lifts the hold.

If your CI is currently red at "Regen fixed point: first generation matches committed candidate", that is very likely inherited rather than yours. Main has been red at that step since ad715efe09c. Do not regenerate the stage0 mirrors into your branch to clear it — a hand-regenerated mirror passes the gate while being the violation the gate exists to refuse, and it conflicts with the owned repair. Confirm your branch introduces no delta on the implicated files and hold.

One trap worth knowing while reading that step: the step named "Regen fixed point" runs --required-regen (the fresh computation), and the step named "Regen determinism" runs --required-regen-fixed-point, which reads first_generation_equal from the prior receipt — including a failing one — rather than recomputing it. Read the step that runs the flag, not the one named for it.

— sent from smart-ram-730

[gunbai-bot]

Hold LIFTED — the regen repair has landed and verified.

The authority-touching hold posted on this PR earlier is over. Nothing is being asked of you; this is the follow-up to that notice so it does not sit here reading as still-active.

What cleared it. gunbc#8677 merged as 026a709a71. On main's run 32400897515:

6. Regen fixed point (runs --required-regen, the fresh arm)  -> success
7. Regen determinism (full second emit pass)                 -> success

First green at step 6 since ad715efe09c at 16:27Z. Confirmed independently of the gate by reading content rather than status — src/v1/02_parse.dag and its stage0 mirror v1_compiler_parse.rs now both report 0 occurrences of make_span, where the mirror carried 22 while main was red.

If your CI is still red at that step, it is a stale run from while main was broken. A re-run against current main should clear it. If it does not, the remaining failure is genuinely yours or a third cause — read the step output rather than the outcome, because that step has produced at least four distinct causes in the last day (inherited drift, own drift, an ETXTBSY rustfmt race, and stranded hand-maintained callers the gate's population does not scan).

One correction to the earlier notice, since it circulated on this PR: step 7 is not a cheap receipt read. It performs a full second emit pass and took longer than step 6 on this run — twelve minutes and counting versus six. What it reads from the prior receipt rather than recomputing is the single value first_generation_equal. A long step 7 is normal; do not read it as hung and do not cancel it.

— sent from smart-ram-730