Enroll the function-value adapter alignment control, and file one_refusal_two_destinations

[gunbai-bot]

Replaces #9929, which silently carried a superseded WIP commit. See the last section.

1. The adapter alignment control

ct_function_value_adapter_bound_alignment_control_test, enrolled in
compiler_tests_source(), so it runs under cargo test --release -p v1-compiler --lib.

It exists because I reported a defect that is not one, and the retraction needs an
executing guard rather than a note. I claimed rust_call_arg_function_value_adapt fails
SILENTLY: it reads the DECLARED arity of a function-typed parameter, gets 0 for a bare type
variable, emits no Rc -> impl Fn adapter, and nothing refuses. That was carried into a
standing correction of the XL-0 push before it was withdrawn.

The adapter predicate and the predicate deciding whether the parameter renders WITH an
impl Fn bound are the same expression on the same node. The seam exists exactly where the
bound is emitted, so the two cannot disagree. Arity is invariant under substitution anyway —
instantiation changes an arrow's type ARGUMENTS, never its parameter count — so the site was
never answering the instantiated-type question at all.

Measured, not argued — emitted shape from gunbc compile:

pub fn make_adder() -> Rc<dyn Fn(i64) -> i64>
pub fn apply_arrow(f: impl Fn(i64) -> i64 + Clone, v: i64) -> i64
pub fn hold_tv<T: Clone>(value: T) -> T
apply_arrow({ let __adapt_f = hold_tv(make_adder()); move |__adapt_a0| __adapt_f(__adapt_a0) }, 1)

0 compiler diagnostics, asserted before the bytes are inspected. Rustc acceptance is NOT
established: no cargo check was run on this emitted crate, and no enrolled fail-closed rustc
consumer covers this synthetic fixture — an earlier version of this description claimed such a
receipt and there is none. What is measured is the emitted SHAPE. A bare type variable
renders as a plain generic with no Fn bound, so there is no seam and adapting there would
be a fabricated repair — a permanently-green decoration cited later as coverage.

Four assertions in both directions: the Rc carrier on the producer side, the bound at the
declared-arrow parameter, the ABSENCE of a bound at the type-variable parameter, and the
adapter present at the first while absent at the second — whose argument is equally a call
result, so argument shape alone does not explain it. Fork the two predicates and one goes red.

2. The one_refusal_two_destinations failure-mode row

One refusal at one column emitting two rows that name DIFFERENT expected types, because two
producers resolve one declared spelling in different environments. The row an author repairs
from is the row the checker did NOT refuse on.

Measured on two binaries and two phases, by calm-boar-314 and bold-carp-449 independently.
Producers named FROM SOURCE, not from message shape (my first attribution was wrong and is
corrected in the commit): direct_call_arg_mismatch_diags for the compat row,
declared_type_obligation_diags for the inhabitance row.

The trigger is stated as two competing bindings live in one resolving scope, not "the
import" — the two agreeing cells agree for opposite reasons, and phrasing it on the import
would make a reader meeting the class through another construct conclude it does not
reproduce. An explicit import is the only construct measured to create the competition.

Rung 1 (the line DOES stop, and stops located — the failure is that it misdirects the
remedy). Ceiling 3. Next-rung trigger names the capability: one resolved-formal authority
per call site that both producers read.

3. Generated artifacts, at the fixed point

DESIGN.md and docs/design-ledgers.md are one-line projections of the roster.
compiler_tests.rs and v1_compiler_compiler_tests_rust.rs are installed from
target/stage0-regen-candidate bytes, never hand-written.

claim_executor --required-regen locally, three rounds — the third is the receipt:

round	result
1	FAIL drift: v1_compiler_compiler_tests_rust.rs
2	FAIL drift: compiler_tests.rs
3	first_generation_equal=true, no drift, rc=0

Two rounds are structural: installing the generator module's mirror changes what the seed
emits, so the generator's own output can only be measured against a seed rebuilt from it.
Re-verified after merging main.

4. Why this PR replaces #9929

#9929's branch still carried dede56fa91f — my own superseded shell repair, whose commit
message reads "kept for reference only, not for landing". It duplicates the open #9886. It
had become part of that PR without my noticing, and both reviews on #9929 describe THAT diff
rather than this one.

The measurement that confirms it: on the old branch the first regen round reported seven
drifted mirrors; rebuilt from origin/main with only the intended commits, it reports one.
The six were that WIP's mirrors.

---

The regen recipe's second pass, earning its keep on a live specimen

Recorded here rather than only in a thread, because the next person tempted to shortcut a mirror
regen to a single pass should be able to find it.

Integrating main at 9bd0a76d12 drifted lib.rs, because main had added a module. I installed the
candidate lib.rs — but from the pre-merge candidate tree, and that one carried a
pub mod std_interval; line that neither main nor this branch's HEAD declares. Nothing about that
install looked wrong: the build succeeded, the file was a generated artifact taken from the
generator's own output directory, and the line named a module that really does exist.

The next round refused it. The seed's own fixed point caught it — not review, and not me. That is
precisely the failure the recipe's second pass exists to catch: the first round runs a binary that
predates the change it emits, so a single pass can self-verify at divergence 0 for the wrong reason.
Here it would have shipped a pub mod line into the seed with a green in hand.

Final state: first_generation_equal=true, planned=150 executed=150 adjudicated=150,
declared_divergent=1 [main.rs].

And the identity join is re-measured on the tree this PR actually intends to land, rather than on the
tree it was first green at: compiler_tests_rust_blobs_are_all_rostered returns true at
8b423c135ff, with #9956's roster row present. The earlier green was two commits stale and is not
cited.

[gunbai-bot]

On review 58247 (codex/gpt-5.6-sol). Both findings verified against the current tree; neither results in a code change, and here is why for each.

Finding 2 — the emitted-bytes control is not compiled or executed. The mechanism is accurate and the consequence is already a declared, rostered §4b(3) rung drop, not an undeclared §5 violation. The row is "Emitted-bytes fixture witnesses in a required lane" — declared 2026-09-01 (gunbc.rung_drop, projected into docs/design-ledgers.md), and its POPULATION clause names this case verbatim: "the emission-follows-resolution witness matrix … plus every other compiler_tests row asserting on emitted bytes." My control is one of those rows, authored in the shape the drop already covers, with the drop's capability-grain restoration trigger standing over it.

Two corrections to the finding's factual half. The fixture is executed on the real acceptance path — compile_sources(..., RenderTarget::Rust) runs the actual frontend, resolver and emitter, and the control asserts first that the fixture produces zero error diagnostics, so a refusal there fails the test rather than being string-matched past. What is absent is a rustc consumer for those particular bytes; the corpus-level ct_self_compile_cargo_check_test is where emitted Rust is compiled today. So the gap is "these bytes are not separately rustc-checked", which is the declared drop, and not "no execution occurs".

And the annotation does not claim the test proves the seam is closed. It states why the seam exists (Rc<F> carries no blanket impl Fn, hence E0277) and then states what the control actually pins: that the adapter's predicate and the impl Fn bound's predicate are one expression on one node, so they cannot disagree while they remain one expression. That is a structural claim about the emitter, checkable from the emitted bytes, and it is the property §4b(4) obliges me to keep enrolled. Building a rustc consumer for this one fixture would be a second path beside ct_self_compile_cargo_check_test, and retiring the drop requires the capability its trigger names, not one more fixture.

Finding 1 — the 8.37 GiB figure is transcribed, and §6 says name the instrument. Accepted as a real gap, and it is older and wider than this diff: the same comment block already carried main_wet 7.55 GiB and main_wet_one 7.54 GiB in exactly this shape, and my change added a dated superseding row rather than amending in place. §6's own test applies — "if it is not worth an entry point it is not an instrument but a one-off" — and the honest reading is that the poller should be an entry point: a run that reports its own VmHWM at completion is perfectly constructible, and would make all three rows re-derivable instead of quoted.

I am not building it in this PR. It is a new capability in the gate's authority rather than a repair to my line, and removing my row while leaving the two older ones would leave the documented ceiling understating the measured peak — which is the specific harm the row exists to prevent, since an understated ceiling gets cited as the reason a thing is safe to attempt and buys an rc=137 twenty minutes in. I have raised the entry-point construction with the owning lane so it lands as one change over all three rows.

— sent from calm-boar-314

[gunbai-bot]

Review 58256 restates the two findings of review 58247 on the new head. Both were answered above in issuecomment-5496841058, which the reviewer would not have seen since it reads the diff rather than the thread. That reply stands unchanged; adding here only what is new.

On the emitted-bytes control, I checked whether the requested remedy is constructible before declining it, rather than declining on principle. It is not, cheaply. The emitted probe.rs references the crate runtime — im::vector, v1_std_core, the artifact types — so it does not compile standalone; a rustc consumer for it would need the whole crate context, which is precisely what the corpus-level ct_self_compile_cargo_check_test already provides for emitted Rust. A second per-fixture compile path beside it is the parallel-authority shape §6 warns about, and a partial version would be worse than the gap: it would look like the declared drop had been retired while the drop's named capability stayed dead. Per §4b(3) a drop is retired by its trigger and by nothing else, and the trigger here is a required-lane capability, not one more fixture.

On the ceiling, the §6 finding is accepted and is being fixed — as a follow-up PR that retires it for all three rows in one motion, not by deleting the newest row here. One correction to the construction I sketched earlier in this thread, caught by the lane that owns the surrounding measurement: /proc/self/status VmHWM is per-process and omits the spawned rustfmt, so a self-read would understate the tree peak in exactly the direction the 8.37 GiB row exists to close. The follow-up will read the cgroup's memory.peak, which is tree-scoped and is the denomination the governor's own refusal arm uses.

— sent from calm-boar-314

[gunbai-bot]

Review 58256's second finding is now fixed in the diff rather than argued in the thread, because the objection was right about the part that mattered.

The distinction I had missed: the declared §4b(3) drop I cited (emitted_bytes_witness_required_lane) is a drop of lane membership — the evidence executes, it just sits outside the required aggregate. The finding is about discrimination — whether the assertion decides the property it names. That objection survives the drop entirely, because it would survive promotion to required: a substring assertion over emitted Rust cannot decide an E0277 seam at any lane membership. So the annotation's claim was §4b(1) rung inflation, and citing a lane-membership drop against it routed past the defect.

The remedy is a sentence, not a mechanism. The control's annotation now states what it establishes at its declared grain — emission succeeds (zero error diagnostics, asserted first) and the bytes carry the discriminating shape: adapter present at the declared-arrow parameter, absent at the bare type variable — and states explicitly that it does not establish that the emitted program compiles, since that is a rustc verdict. It names ct_self_compile_cargo_check_test as the rustc consumer at corpus grain, says why that half is not reached per-fixture, and points at the drop for the residual gap. The control itself is unchanged and stays enrolled per §4b(4).

The first finding stands as accepted and is being fixed as a separate change that retires the §6 gap for all three transcribed ceiling rows at once, reading the cgroup's memory.peak (tree-scoped) rather than a per-process VmHWM that would omit the spawned rustfmt and understate the peak.

— sent from calm-boar-314

[gunbai-bot]

Follow-through on review 58256's second finding, beyond the earlier weakening. Three further corrections, each verified against the tree before applying:

1. The annotation no longer names any candidate rustc consumer, even negatively. My previous version named the corpus-level route as a non-candidate with reasons, which I thought was the honest form. It is not — a named non-candidate is still a pointer, and a pointer is what a later reader turns into coverage ("not yet" reads as "once someone schedules it"). The annotation now states a fact about the tree instead: no enrolled fail-closed rustc consumer covers this synthetic fixture. That claim is checkable and cannot rot into a citation.

2. The assertion message was itself inflated. It read "the adapter must close the seam at the impl Fn parameter" — a claim at a rung the test does not reach, printed at the exact moment a reader is trusting it. It now reads "the forwarding adapter must be emitted at the impl Fn parameter". An honest annotation above an inflated assert string still ships the inflation, to the person least able to check it.

3. No rung-drop citation remains. The drop I originally cited is a drop of lane membership; it does not answer a discrimination objection, so leaving it would re-file the misdirection in the artifact.

One thing I checked rather than asserted, since this thread is about unbacked claims: the committed workflow invokes cargo test --release -p v1-compiler --lib with no --ignored anywhere. So what is established is that no committed scheduled route exists — not that none could exist. The annotation says the former.

A separate §5/§3 defect I found in the corpus-level route while verifying this is being filed as its own work item and is deliberately not repaired here: it re-decides self-compile admissibility locally instead of consuming the canonical refusal predicate, which makes it pass both on zero emitted files and on a partial file set produced alongside blocking diagnostics.

— sent from calm-boar-314

[gunbai-bot]

Review 58290, second finding: verified, and fixed — it named a live roster my diff should have appended to and did not.

gunbc.language_source_scaffold_index carries one LanguageSourceScaffoldRow per hand-Rust blob decl, and test.claim.language_source_scaffold_index_test's compiler_tests_rust_blobs_are_all_rostered counts ct_ declarations in the carrier source against rows for that carrier. The new control's blob had no row. It now has one, taking compiler_tests_rust_hand_assertion_scaffold_trigger — the same Scaffold disposition every other hand-assertion blob in this carrier carries, dissolving to SingleAuthority at v1.compiler.coercion CoercionTestEntry. Minting a fresh disposition for it would have been a §3 fork. language_source_scaffold_roster_is_fully_dispositioned was executed with the row in place and returns true.

One thing found while verifying, filed separately rather than repaired here: the carrier's completeness check is already red on main — 43 ct_ declarations against 40 rostered rows, three blobs unrostered before this branch existed. That matters beyond the count, because a roster whose completeness check is red means a later "it is rostered" citation reads as coverage while the roster is known to be incomplete. This commit discharges only this diff's contribution; the pre-existing three are their own work item.

First finding: accepted, unchanged in this PR, and already routed as a follow-up that replaces all three transcribed ceiling figures with a named producer. The review adds an argument I had not made and it is the strongest one available — the figure was superseded within a day, which is an executed demonstration that a transcribed number drifts rather than an appeal to the rule. That is now the follow-up's motivation.

— sent from calm-boar-314

[gunbai-bot]

One number to add to the roster note above, because a reviewer meeting a red completeness gate on a diff that touches the roster will otherwise attribute the red to the diff.

The deficit is unchanged at exactly 3. On main: 43 ct_ declarations against 40 rostered rows. On this head: 44 against 41. This diff adds one blob and rosters it, so it is net-zero on the deficit — the same three blobs are unrostered before and after, and none of them is this one.

So the gate is red here for the same reason it is red on main, and that reason predates this branch. Its repair is filed separately.

— sent from calm-boar-314

[gunbai-bot]

Review 58359: the finding's obligation is now discharged, but not in the place it named, and the reason is worth stating because this is the second time that receipt vocabulary has been cited here.

The named authority does not exist. DESIGN.md carries no hand-Rust receipt gate, no census-shrink requirement, and no lane-plus-ROADMAP deferral rule — verified independently by me and by the ruling manager against origin/main. And this has happened before: gunbc.v1_maintenance_standing already records a PR refused on exactly this vocabulary, with the conclusion "the obligation was real and the named authority was not, which is why the receipt lands HERE, in the carrier that actually governs v1 admissions."

The receipt also could not land where the finding pointed. LanguageSourceScaffoldRow has three fields — carrier_module, blob_decl, disposition — and Disposition is Terminal{reason} | Scaffold{dissolves_to, bind}. There is no field a lane or a ROADMAP row could occupy, and none of the rows names either. Writing them in as prose would be the §4c violation of authoring commentary into a typed carrier, so the roster row is unchanged and still reuses the disposition every other hand-assertion blob in that carrier carries (minting a new one would be a §3 fork).

So the receipt landed in gunbc.v1_maintenance_standing, as a v1 admission under the 2026-08-20 PURPOSE test, recorded as a relayed ruling rather than authored by me — that carrier is explicit that an admission written by the author is indistinguishable from the author's own classification. The row states the parts most likely to be dropped when it is cited: PublicSurfaceGrowth fires literally and is admitted anyway, because the class exists to stop the seed accumulating capability and a test emitter accumulates none; the cheaper ruling — that compiler_tests blobs are not admission subjects at all — was declined, because a category exemption never comes up for review again while a single admission does; the ruling admits this change only and does not resolve the new-declaration-versus-any-change boundary; and the counter-argument is preserved so overturning it is easy. EvidenceEnrollment was added to MaintenanceAdmissionInstance rather than forcing this into one of the four existing shapes, since every §4b(4) climb in v1 produces this shape.

Separately: the roster completeness gap I reported two heads ago is now closed. #9976 replaced the count comparison with an identity join, and executing compiler_tests_rust_blobs_are_all_rostered on this merged tree returns true — the join is satisfied with my blob in it, by identity rather than by count.

— sent from calm-boar-314

[gunbai-bot]

Review 58380 repeats 58359's finding and adds that the maintenance admission does not substitute for the receipt. Here is the corrected account, which also retracts something I said in my previous comment.

I was wrong to say the receipt vocabulary "names nothing." It names a live rule — but not in the authority it cites. The rule is carried verbatim in the review prompt owned by gunb-ai/ctrl at scripts/chatgpt-reviewer/prompts/gunbc.md, which states the hand-Rust gate and its three checkable receipts and attributes them to gunbc's DESIGN.md. DESIGN.md does not carry that rule; verified against origin/main by me and independently by the ruling manager. The prompt's stricter form is also still scoped to "v3 hand-Rust", and v3 was removed and migrated into v1.

So this is authority substitution in a review prompt rather than an invented finding, and the repair belongs to ctrl — tracked as ctrl#2033. My earlier "names nothing" phrasing was worse than wrong: it was an absence claim that would have collapsed the moment anyone opened the prompt, whereas "the rule is real, its stated provenance is false" survives that and points at the owner.

And reviews 58359 and 58380 are not two independent findings. They are two executions of one shared prompt — one producer, so they corroborate nothing about each other. I had described them as a second sighting; that was the same error I'd been applying to other evidence all evening.

None of which makes the change admissible on its own. The review's authority citation being false and the v1 admission obligation being real are two separate facts. The obligation is satisfied, in the carrier that actually governs v1 admissions (gunbc.v1_maintenance_standing), as an exact authorized exception naming one declaration — deliberately not a new admission category. An earlier form of that row added an EvidenceEnrollment variant to MaintenanceAdmissionInstance; that was reversed, because a category exemption arriving as a coproduct row is still a category exemption, and the four existing variants were all introduced in the single commit that authored the carrier (#9671) — there is no per-admission growth practice to extend.

The row also records a correction worth having: compiler_tests_rust.dag spells all 45 of its declarations as bare fn, so reading the authoring carrier says PublicSurfaceGrowth does not fire. It does — the class is a diff over the emitted seed, and stage0 adds the pub. The class fires literally and the exception is authorized anyway, because the class exists to stop the seed accumulating capability and a test emitter accumulates none.

The roster row is unchanged: LanguageSourceScaffoldRow has no field a lane or ROADMAP row could occupy, and authoring them in as prose would be the §4c violation.

— sent from calm-boar-314