Skip to content

XL-0N-RC: prove the victim is in the measured closure — it is, and the Rc<i64> span-stamping arm is not live on main - #9842

Merged
gunbai-bot[bot] merged 2 commits into
mainfrom
session/crisp-owl-751
Aug 31, 2026
Merged

gunbai-bot[bot] merged 2 commits into
mainfrom
session/crisp-owl-751

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Aug 31, 2026 •

Copy link
Copy Markdown
Contributor

What this is

The XL-0N-RC lane deliverable, in the ordering the brief fixed: positive control before any interpretation. A predecessor lane reported the `Rc` span-stamping defect REFUTED off an A/B over `00_compile.dag`, then retracted it — the victim (`std_checked_arithmetic.rs`) was never in that closure, so both arms agreed at zero for want of a subject.

What was measured (all on current main eced9d2 merged)

  1. Subject reached: the import chain `v2.std.integer → std.integer → std.induction → std.checked_arithmetic` puts the victim in the census closure of `src/v2/compiler/03_normalize.dag` (80 emitted files, both Nat authorities present).
  2. Instrument discriminates: with `decl_file_realizes_natively` forced false (compiler-side perturbation, reverted), the same probe reds with 2 errors inside the victim and `Nat` rendered structurally. The green arm's zero is a real zero.
  3. Key B (decl_file via ident_span on the alias): hits — measured both directions.
  4. Key A (bare vs qualified spelling): a two-spelling fixture emits byte-identical code; the un-peeled `authored_name_at` in `field_access_field_is_boxed` is real but has no authorable RED at field grain (`needs_box_wrapping` peels and boxes only recursive carriers), so per DESIGN §4b no check or repair ships against it — the family stays on its existing carrier (`rust_carrier_realizes_as_machine_scalar` note, rung Mitigatable, ceiling: resolved-declaration-identity keying).

Changes

  • `docs/plans/self-host-cargo-refusal-root-partition.md`: new §23 recording the subject-present measurement with named instruments (per §6, commands not transcribed numbers where re-derivable), replacing the retracted verdict so the hypothesis is re-read rather than re-run.
  • Same doc: the stale citation of `nat_max_two_nat_authorities_note` (deleted by XL-0N residue: refusals carry the BinOp coproduct, the Nat fork gets a stall row, prose leaves the data plane #9794) now cites its true referent, the stall row `gunbc.guarantee_rung_drop two_nat_authorities_stall`. The doc is a `HandAuthoredDocBind` in `doc_graph_roots.dag`, not a main_wet projection — verified before hand-editing.

No compiler, emitter, or resolver code changes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VdQphfzTtHwuDqdNyuQQTC

Amendment (same day): the "no authorable RED" verdict is RETRACTED — wrong boundary

The manager's review question ("which boundary is the unauthorable-RED measured against — fixture or corpus?") was decided by execution against the first reading: the RED is authorable as fixture source. A recursive carrier that merely shares the bare spelling Nat, placed in the closure beside a std.nat.Nat field consumer, is accepted by gunbc and refused by cargo with the verbatim claimed diagnostic expected i64, found Rc<i64> — the numeric guard hits while the recursive/shared layer sets are keyed on the bare string and get polluted by the unrelated declaration. The first §23 sentence had measured corpus occupancy, not fixture reachability (reachability_read_as_occupancy). §23 now records the retraction, the executed two-module reproducer, and states the #9813 non-reproduction explanation as a hypothesis with its discriminator rather than an attribution (the whole-corpus attribution boundary has not published). Enrolling the reproducer as an expected-red row and the identity-keyed repair of the layer sets are deliberately follow-up increments, not part of this PR.

gunbc-ci-auto-heal and others added 2 commits August 31, 2026 21:05
…verdict; stale two-Nat citation repaired

Positive control first, as the brief ordered: std.checked_arithmetic IS inside
the measured census closure (v2.std.integer -> std.integer -> std.induction ->
std.checked_arithmetic), both Nat authorities present, and the instrument
discriminates -- disabling decl_file_realizes_natively reds the victim itself.
On current main no arm reproduces the claimed expected-Rc<i64>-found-i64: the
decl_file key hits through the alias, and the un-peeled authored_name_at in
field_access_field_is_boxed has no authorable RED at field grain because
needs_box_wrapping peels and boxes only recursive carriers. Recorded as
section 23 of the shared coordination surface; no emitter edit ships without a
discriminating red.

Also repairs the doc's citation of nat_max_two_nat_authorities_note (deleted
by #9794) to the stall row gunbc.guarantee_rung_drop two_nat_authorities_stall.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VdQphfzTtHwuDqdNyuQQTC
…y, not reachability — the fixture boundary reds with the exact claimed diagnostic

A two-module fixture (recursive carrier sharing the bare spelling Nat +
a std.nat consumer) is accepted by gunbc and refuses in cargo with
expected-i64-found-Rc<i64>: the numeric guard hits while the bare-string-keyed
layer sets are polluted by the unrelated recursive declaration. Section 23
now records the retraction, the executed reproducer, and restates the #9813
attribution as a hypothesis with its discriminator, since the whole-corpus
attribution boundary has not published.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VdQphfzTtHwuDqdNyuQQTC
@gunbai-bot
gunbai-bot Bot force-pushed the session/crisp-owl-751 branch 2 times, most recently from 5a0323a to aa53e1b Compare August 31, 2026 22:22
@gunbai-bot
gunbai-bot Bot merged commit 034d0f0 into main Aug 31, 2026
10 of 15 checks passed
@gunbai-bot
gunbai-bot Bot deleted the session/crisp-owl-751 branch August 31, 2026 22:50
@briansrls
briansrls restored the session/crisp-owl-751 branch August 31, 2026 23:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants