The bare-reference channel's outcome instrument over the four fixtures (rung stays 1)

[gunbai-bot]

What this is

gunbc.recurring_failure_mode.bare_reference_channel_declines_a_pull_in_silence (gunbc#11943) shipped four hermetic fixture entries and recorded them as a declared frontier: a set a reader re-runs, with its named consumer -- an instrument target -- deferred behind the loader-side decline carrier. That deferral was one step too strong. The carrier is needed to say why a name was declined; it is not needed to say what both gates decided. This is that instrument, and the row's rung line moved with it.

The instrument

gunbc test //gunbc/instruments:bare-reference-channel-outcome, one row on the existing seam (gunbc.target_binding BareReferenceChannelOutcomeProducer, gunbc.instrument_targets label/binding/expectations/classifier, one arm in target_invocation_host.rs) -- not a new route and not a flag.

It reads, per entry, the two values the loader already computes on BothClosureEdgeIndex: did the bare half RUN for that file (bare_scan_eligible, gate one) and which modules did it PULL (bare_out, gate two). v1_compiler.cli_run bare_reference_channel_readings is the reading; module paths in and out, never file paths. Eligibility stays a separate field from the pull set, because "the channel never ran" and "every arm of pullable declined" both end with an empty set and are the two different gates the fixtures exist to tell apart. Set comparison is at identity grain, never a count.

Subject is fixtures/bare_reference_channel, the instrument's own fact rather than a CLI option, so a corpus-wide change cannot move the reading.

The RED, authored before the green

Three builds of gunbc, one dispatch, each perturbing exactly one gate in v1_compiler.cli_run and then reverting.

A -- gate one removed (source_declares_import_lines returns false):

entries=4 unmet=1
UNMET probe.brc.imported_record_consumer (the row-one reference plus ONE unrelated import line -- gate one turns the channel off):
  expected channel=DISABLED pulled=[], observed channel=RUNS pulled=[probe.brc.record_home]
EXIT=1

B -- gate two widened (pullable returns true):

entries=4 unmet=1
UNMET probe.brc.bare_alias_consumer (no imports; bare reference to a nullary type alias -- every arm of pullable declines):
  expected channel=RUNS pulled=[], observed channel=RUNS pulled=[probe.brc.alias_home]
EXIT=1

Control -- unperturbed: entries=4 unmet=0, EXIT=0, with the four readings
bare_record_consumer RUNS [record_home] / bare_alias_consumer RUNS [] /
imported_record_consumer DISABLED [] / transitive_alias_consumer RUNS [alias_home, passenger_home].

Each perturbation flips exactly the entry that isolates the gate it moved, and no other. The passenger row confirms the reading gunbc#11943 derived: a bare CALL pulls its callee and the callee's import closure carries the alias home in.

The row

• Rung stays at 1. The brief asked for 1 -> 2; review 69538 called that inflation and was right (4b rung 2 is exposes AND BLOCKS; an instrument on no required lane exposes only), and the brief's author ruled to revert. The row now records why it stayed at 1 through the change that built the instrument, and carries a rung-1 trigger at capability grain: rung 2 is reached when a gate change BLOCKS A LANDING -- the outcome discrimination executing on the required acceptance path -- deliberately not "enrol the instrument", which is artifact grain. A lane was declined: it is a standing claim on a paid runner on every PR, and the roster is closed to growth.
• The row says in its own words that the instrument exists and is hand-invocable and that this is not the rung, so a later reader does not re-file the climb believing it unbuilt.
• An independent amendment: The rule that decides whether the loader's bare-reference channel pulls a module #11943's frontier receipt named the decline carrier as the instrument's trigger; that was stronger than an outcome-grained wall needs, since eligibility and the pull set are already values on BothClosureEdgeIndex. The carrier is still required for the reason a name was declined, which is the ceiling's subject. The two grains are now separated.
• Ceiling unchanged (3, structurally guaranteed, not reachable) and its trigger unchanged (the loader-side decline carrier, at capability grain, consumed by both downstream reporters) -- now labelled apart from the rung-1 trigger, since satisfying either leaves the other standing.
• DESIGN section 4b(4) recorded: the fixtures, the instrument and its claims stay enrolled at rung 1, because they are what makes the eventual climb checkable and evidence does not retire.

Base

Merges session/nimble-cat-13 (gunbc#11943), which owns the fixtures and the row. Land that first or together.

One thing found and NOT fixed here

test.claim.target_invocation_witness_test the_instrument_target_and_its_binding_are_the_same_identity asserts (instrument_targets() |> count) == 8. On origin/main that roster has 14 rows (15 with this change), so the literal is already false, and the module's prefix is not in v2.workflow.required_floor required_gate_prefixes -- it is off the required gate, which is why nobody has seen it red. Updating the literal to 15 would be exactly the change detector DESIGN section 5 forbids (measure() == measure()), so this PR does not touch it. Reported rather than papered over.

Evidence and its limits

cargo clippy --all-targets -- -D warnings is clean on the remote runner. The instrument runs and the perturbation matrix above was produced by a gunbc built from this branch there. A whole-corpus --entry compile of the two edited .dag modules against dag + src/v2 was attempted and OOM-killed (exit 137) after normalize on the 7 GiB remote runner -- the same standing property gunbc#11943 recorded, not a verdict on these files. Their typecheck is therefore delegated to the required lanes on this PR rather than claimed here.

Review 69529 (REQUEST_CHANGES) — addressed

Two findings, both correct, both fixed in this PR:

• The .dag half was dangling (§3c). Five claims added to test.claim.target_invocation_witness over bare_reference_channel_holds / bare_reference_channel_termination / bare_channel_reading_rendered / the registry row, on the same pattern as the two siblings on this seam. All five PASS by execution under claim_batch (eval_steps 1828 / 1404 / 1480 / 68 / 3522, exit 0). The first run failed on a real defect — the registry claim used TargetInvocationRouteRefused { refusal: _ } where the field is cause — which the compiler lane had passed over, because it compiles a different subject.
• No SeedGrowthJustification for the new seed Rust (§7). gunbc.bare_reference_channel_outcome_seed_growth added and enrolled in the gunbc.seed_growth_admission roster, enumerating all eight new host declarations, with the decline carrier as its trigger.

A standing CI condition found while verifying, NOT caused by this PR

The floor required check reports pass over a refusal — REQUIRED-FLOOR REFUSAL cause=ArmSetConsumerPlanningUnavailable, lane=witnesses phases_run=2 phases_failed=2, job conclusion success. Identical on this branch's pre-review-fix head, so it predates these commits. While it stands no witness in that lane executes, so a green tick there is not evidence about witness health — which is why the claims above are cited from a direct run rather than from CI. Looks like the fail-open gunbc#11829 binds; flagged, not fixed here.

[gunbai-bot]

Both findings in review 69529 are correct and are fixed. Evidence below, plus one thing the review process itself could not have caught and a standing CI condition I found while verifying.

Finding 1 — the .dag half was dangling (DESIGN §3c)

Fixed by five claims in test.claim.target_invocation_witness, on the same pattern as the two siblings the review named:

• a_moved_bare_channel_gate_does_not_hold — one red per gate. The pullable-widened arm (the alias entry acquires a pull) and the gate-one-removed arm (the imported entry's channel starts running) are separate conjuncts, so an implementation comparing only pull sets fails the second.
• the_bare_channel_join_is_at_identity_grain_and_total — a pull that moved to a different module is not a satisfied row (what a count equality would admit), and a missing entry is not one either.
• an_absent_bare_channel_fixture_root_is_not_a_moved_gate — SubjectUnreached/2 kept apart from ObservationDidNotHold/1 and ObservationHeld/0.
• the_bare_channel_rendering_names_the_channel_and_the_pull_set — the rendering carries both gates' answers.
• the_bare_channel_instrument_is_a_real_row_on_the_shared_registry — canonical label, and invoke_target routes it to BareReferenceChannelOutcomeProducer.

Readings are supplied rather than computed, per DESIGN §3's one-interface rule — the subject is the classifier. The pairing obligation is discharged by the real producer: gunbc test //gunbc/instruments:bare-reference-channel-outcome runs bare_reference_channel_readings against the live loader, so inhabitance of that shape is established by execution, not by this file.

Executed, not merely compiled — claim_batch over the witness entry:

PASS a_moved_bare_channel_gate_does_not_hold                        eval_steps=1828
PASS the_bare_channel_join_is_at_identity_grain_and_total           eval_steps=1404
PASS an_absent_bare_channel_fixture_root_is_not_a_moved_gate        eval_steps=1480
PASS the_bare_channel_rendering_names_the_channel_and_the_pull_set  eval_steps=68
PASS the_bare_channel_instrument_is_a_real_row_on_the_shared_registry eval_steps=3522
exit 0

The first run of that command failed, and the failure is worth recording: the registry claim was written as TargetInvocationRouteRefused { refusal: _ } when the field is cause. The compiler lane had already passed over it — that lane compiles a different subject — so only resolving the witness's own closure caught it. A claim added to answer a dangling-code finding, which itself did not resolve, would have been the same defect one layer down.

Finding 2 — no SeedGrowthJustification

Fixed by gunbc.bare_reference_channel_outcome_seed_growth, enrolled in the gunbc.seed_growth_admission roster (the fold that reads the siblings the review cited, so the row is consumed rather than filed). It enumerates all eight new host declarations at declaration grain — BareReferenceChannelEntryReading, bare_reference_channel_readings, and the six in target_invocation_host. The TargetProducer variant and the instrument_registry row are stated as roster extensions rather than netted, as the sibling rows do; the host-side expectation mirror is enrolled, because an unenrolled mirror of a .dag authority is exactly the silent escape hatch §7 forbids. Its trigger is the same loader-side decline carrier the failure-mode row names, with a sentence on why a narrower trigger would be satisfied while this mirror stayed alive.

A standing CI condition, not caused by this PR

While looking for execution evidence I found the floor required check reports pass over a refusal:

required-ci: floor refused: REQUIRED-FLOOR REFUSAL cause=ArmSetConsumerPlanningUnavailable ...
required-ci: lane=witnesses phases_run=2 phases_failed=2

— job conclusion success. It is identical on this branch's pre-review-fix head, so it is not introduced here. The consequence matters for anyone reading a green tick on this PR or any other: no witness in that lane executed, so the lane's green is not evidence about witness health. That is why the claims above were run directly rather than cited from CI. This looks like the fail-open gunbc#11829 binds; flagging rather than fixing, as it is outside this PR's scope.

— sent from witty-lark-232

[gunbai-bot]

Review 69538's two findings are both correct and both are fixed.

Finding 1 — rung inflation. You were right; the rung is back to 1.

Escalated to the brief's author, because the work item's explicit deliverable was moving this row 1→2. Decision: revert. Their words: "My brief's premise was wrong and you were right to stop rather than satisfy it — 4b rung 2 is exposes AND BLOCKS, and an instrument on no required lane exposes only… an inflated class never ranks for climbing, which is the harm. Do not treat the brief as authority over DESIGN." A lane was explicitly declined — not on cost grounds, but because a lane is a standing claim on a paid runner on every PR and every queued landing, the roster is closed to growth by operator ruling, and it will not be spent to make a rung sentence true. If this class earns a lane later it will be argued on its own merits at witness_floor_lane_jobs.

The row now carries:

• RUNG FOUND AT: 1, with the original reason kept, plus why it stayed at 1 through the change that built the instrument — quoting the same §4b clauses this review did, and recording the ruling.
• A rung-1 trigger at capability grain: rung 2 is reached when a behaviour change in either gate blocks a landing — the outcome discrimination executing on the required acceptance path and its red refusing the merge. Stated deliberately not as "enrol the instrument", which is artifact grain and satisfiable by enrolling something that does not block — the §4b(3) mismatch.
• That trigger explicitly distinguished from the ceiling trigger (rung 3, the decline carrier), with the note that satisfying either leaves the other standing. Two triggers in one row is a meaning fork waiting to happen, so they are labelled apart.
• In its own words: the instrument exists, is hand-invocable, and that is not a rung — so the next reader does not rediscover it and re-file the same climb believing it unbuilt.
• §4b(4): the fixtures, instrument and claims stay enrolled at rung 1, because they are what makes the eventual climb checkable and evidence does not retire.

One amendment recorded independently of the rung line: gunbc#11943's frontier receipt named the loader-side decline carrier as the instrument's trigger. That sentence was stronger than an outcome-grained wall needs — eligibility and the pull set are already values on BothClosureEdgeIndex, so the decision's outcome is observable with no carrier at all. The carrier is still required for the reason a name was declined, which is the ceiling's subject. The two grains were conflated; they are separated now.

Finding 2 — the lossy projection as a comparison basis

Fixed. bare_channel_reading_agrees now compares expected.eligibility == observed.eligibility directly. bare_channel_eligibility_runs is marked rendering-only, with the reason on both sides: equivalent today at two arms, wrong the moment the carrier gains a third — which is what the ceiling receipt anticipates when the decline carrier lands — at which point this authority would have silently started disagreeing with its own host mirror.

Re-verified by execution after both edits:

PASS a_moved_bare_channel_gate_does_not_hold
PASS the_bare_channel_join_is_at_identity_grain_and_total
PASS an_absent_bare_channel_fixture_root_is_not_a_moved_gate
PASS the_bare_channel_rendering_names_the_channel_and_the_pull_set
PASS the_bare_channel_instrument_is_a_real_row_on_the_shared_registry
exit 0

Note these are run directly rather than cited from CI, because the floor lane currently reports pass over REQUIRED-FLOOR REFUSAL cause=ArmSetConsumerPlanningUnavailable … phases_failed=2 — see the previous comment; not introduced by this PR, but it means no witness in that lane executes.

— sent from witty-lark-232

[gunbai-bot]

Review 69547's finding is correct and is fixed by adding the renderer rather than dropping the function — an unreached subject is worth rendering, and the review also caught that the arms discarded their payloads.

• bare_channel_subject_cause_rendered now binds root / module_path / detail. Matching without binding them was the defect behind the defect: a located cause rendering as an unlocated sentence.
• bare_reference_channel_standing_rendered added as its consumer, on the sibling's shape (heads_reading_differential_standing_rendered). The unreached arm deliberately prints no counts — unmet=0 for a run that observed nothing would read as a clean result, which is the conflation the three exit statuses exist to prevent. The read arm derives its unmet from the same fold the verdict uses, so the rendering cannot disagree with the termination.
• Two claims exercise it, as asked: the_bare_channel_standing_rendering_locates_an_unreached_subject (all three located causes, plus the absence of any count) and the_bare_channel_standing_rendering_reports_the_read_populations.

I then ran your check across every declaration this diff adds, and it found one more of the same kind. bare_reference_channel_source_roots had no .dag call site either — the same latent shape as its sibling heads_reading_differential_source_roots, which is likewise named only in a seed-growth row. It is now consumed by the registry claim, asserting the fact that makes it load-bearing: the subject is the fixture root and nothing else, which is what keeps this instrument's reading stable under corpus churn, so a moved reading means a moved gate rather than a moved corpus.

All seven claims pass by execution:

PASS a_moved_bare_channel_gate_does_not_hold
PASS the_bare_channel_join_is_at_identity_grain_and_total
PASS an_absent_bare_channel_fixture_root_is_not_a_moved_gate
PASS the_bare_channel_rendering_names_the_channel_and_the_pull_set
PASS the_bare_channel_instrument_is_a_real_row_on_the_shared_registry
PASS the_bare_channel_standing_rendering_locates_an_unreached_subject
PASS the_bare_channel_standing_rendering_reports_the_read_populations
exit 0

The stale PR title is fixed too — thank you for catching it; it still said "Rung 2" after the row reverted to 1.

— sent from witty-lark-232

[gunbai-bot]

Both findings in review 69550 are correct and fixed.

The rung fork on the carrier

You are right on both counts — it was a leftover from the revert, and it sat on the carrier a reader meets first. The annotation on BareChannelEligibility now states no rung at all, and says why: the class's rung has exactly one home, the ledger row, so an annotation naming a rung anywhere else is the §3 fork even when it is currently true, because the two drift on the next ruling. It also records that the old sentence was wrong on the merits — "exposes AND blocks" is rung 2's definition and this instrument blocks nothing.

While there I grepped my own diff for every occurrence of rung outside the row and found no others, and caught one more staleness of the same family the review did not flag: the row said "five claims" after two more were added. Replaced with a pointer to the module rather than a fresh number — a transcribed count rots on the next claim, which is §6's name-the-instrument rule applied to prose.

The Bool projection in the rendering

Fixed as you describe, and the Bool projection is now gone entirely rather than kept for rendering. bare_channel_eligibility_rendered(e) -> String matches each arm to its own spelling, so when the carrier gains its third arm — which the sibling comment says to expect when the decline carrier lands — it fails to compile here instead of rendering a new, distinct state as DISABLED. That is the construction that makes the misrender unwritable rather than unlikely, and it is what the host mirror was already doing.

Verified by execution after both edits — the seven claims and the instrument itself, since I changed its rendering path:

PASS a_moved_bare_channel_gate_does_not_hold
PASS the_bare_channel_join_is_at_identity_grain_and_total
PASS an_absent_bare_channel_fixture_root_is_not_a_moved_gate
PASS the_bare_channel_rendering_names_the_channel_and_the_pull_set
PASS the_bare_channel_instrument_is_a_real_row_on_the_shared_registry
PASS the_bare_channel_standing_rendering_locates_an_unreached_subject
PASS the_bare_channel_standing_rendering_reports_the_read_populations
exit 0

bare-reference-channel-outcome: entries=4 unmet=0   (exit 0)

— sent from witty-lark-232