Skip to content

R3 gate #22: int_lit_full_magnitude_consumer (T-Numeric-Construction) - #3080

Merged
briansrls merged 16 commits into
mainfrom
session/nimble-lark-725
May 14, 2026
Merged

briansrls merged 16 commits into
mainfrom
session/nimble-lark-725

Conversation

@briansrls

@briansrls briansrls commented May 14, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Promotes R3 gate #22 (int_lit_full_magnitude_consumer) from declared to passing by tying the program/audit docs to executable integer-literal magnitude receipts. Adds a focused tokenizer boundary ratchet proving values just beyond the documented full-magnitude carrier fail closed instead of narrowing through a smaller host integer.

Test plan

  • cargo fmt --check — passed
  • cargo test -p v3-compiler --test integration int_literal_full_magnitude_carrier_rejects_beyond_documented_boundary — passed on BuildBuddy
  • GitHub CI: fmt passed; ci/v3 are tracked by required PR checks

P5 receipt

This PR expands hand-written Rust only in an existing integration-test module already covered by the SG-0 census (src/v3/compiler/tests/integration/int_literal_cardinality_test.rs). The single checkable receipt for the expansion is int_literal_full_magnitude_carrier_rejects_beyond_documented_boundary, which directly exercises the R3 gate #22 boundary condition documented in src/v3/std/substrate.dag and the R3 program/audit rows.

@briansrls
briansrls marked this pull request as ready for review May 14, 2026 16:49
@briansrls

Copy link
Copy Markdown
Contributor Author

Addressed the review finding in 13b78a9 by replacing the ambiguous PR pending from nimble-lark-725 wording with PR #3080 in both docs/r3-program-plan.md and docs/r3-structure.md. I also verified no remaining PR pending from / branch-name receipt wording remains in the touched R3 docs.

@briansrls
briansrls merged commit dbe0d19 into main May 14, 2026
4 checks passed
@briansrls
briansrls deleted the session/nimble-lark-725 branch May 14, 2026 19:16

@briansrls briansrls left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review metadata

  • Provider / model: codex / unknown
  • Commit: a09e8ebf · Trigger: schedule
  • Thinking: 320s wall

BLOCKING (1)

Root Cause

  • docs/audit/r3-close-predicate-execution-2026-05-13.md audit refresh only updated the gate #22 row instead of re-deriving every PASSING delta from the §1.8 source of truth → update #19/#21 to HARNESS_NAMED and re-run the bucket counts.

⚠️ The gate #22 receipt looks directionally right, but the close predicate index is currently inconsistent with the canonical ledger.

## Status-bucket distribution after row #15 re-derivation

Derived from the `c055495c8` §1.8 status snapshot plus the 2026-05-14 row #15 delta (`DECLARED` → `CONSUMER_LANDED`, PR #3060) and the row #33 delta (`CONSUMER_LANDED` → `CONSUMER_LANDED + PASSING`, this PR) recorded in this follow-up:
Derived from the `c055495c8` §1.8 status snapshot plus the single 2026-05-14 row #15 delta (`DECLARED` → `CONSUMER_LANDED`) recorded in this follow-up:

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BLOCKING: The re-derivation claims to mirror current §1.8, but rows #19 and #21 are PASSING in docs/r3-program-plan.md while this index still marks them N/A_NOT_PASSING, violating INVARIANTS P2 boundary discipline.

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.

1 participant