-
Notifications
You must be signed in to change notification settings - Fork 0
Migrate Jim rope byte coordinates off GraphQL Int narrowing #285
Copy link
Copy link
Open
Labels
causal-ropeCausal rope text authority roadmapCausal rope text authority roadmapenhancementNew feature or requestNew feature or requestsliceImplementable roadmap sliceImplementable roadmap slicetext-authorityText authority and storage invariantsText authority and storage invariantswork-in-progressCycle or PR is intentionally in progress and not ready to mergeCycle or PR is intentionally in progress and not ready to merge
Description
Metadata
Metadata
Assignees
Labels
causal-ropeCausal rope text authority roadmapCausal rope text authority roadmapenhancementNew feature or requestNew feature or requestsliceImplementable roadmap sliceImplementable roadmap slicetext-authorityText authority and storage invariantsText authority and storage invariantswork-in-progressCycle or PR is intentionally in progress and not ready to mergeCycle or PR is intentionally in progress and not ready to merge
Classification
Width-preservation debt at the transitional GraphQL/Wesley boundary.
Problem
Jim's authoritative rope facts use non-negative
u64byte lengths and coordinates. The GraphQL corridor mapsIntto signed Rusti32, so PR #282 correctly added a pre-admission obstruction when a checkpoint basis exceedsi32::MAX.That obstruction preserves truth, but it leaves an artificial ~2 GiB capability ceiling and repeats narrowing seams anywhere rope byte coordinates cross the generated contract.
Evidence
IntInt→i32mappingWhy it matters
Byte positions are authoritative coordinates, not presentation integers. A lossy or artificially narrow ABI either rejects valid rope states or tempts callers to cast, truncate, or create a side channel.
Constraints
Acceptance criteria
Intat those authority boundaries with an explicitly width-preserving non-negative type.i32::MAX,i32::MAX + 1, andu64::MAXor the declared maximum.Related