Repository navigation
D-QR-CAP: ClassView/WideFieldMask relational ISA and four-domain QR64/256 roadmap - #1663
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Warning Billing warning: we have not been able to collect payment for this subscription for more than 72 hours. Please update the payment method or pay any pending invoices in Billing to avoid service interruption. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
D-QR-CAP: five-PR architecture / experimental roadmap (docs only)
Capstone mapping choice: existing
lance_graph_contract::class_view::{ClassView,FieldMask,WideFieldMask}becomes the candidate structural field-mapping basis adjacent to Quack's bind-once numeric boundary. This does not make a field-presence bit an edge, permission, or identity witness. The capstone seeks fewer handrolled edges by expressing a typed relationship once and lowering it onto borrowed ordinal lanes and optional Boolean QR tiles.Documents
Four independently reviewable companion draft PRs
Capstone board: EXO-121. Coordination: EXO-50.
Geometry and gates
FieldMask: existing 64-bit structural presence.WideFieldMask: zero-alloc low 64 bits, wider 64-bit word chunks for up to 256u8-indexed field positions. ExistingClassView::projectstill takesFieldMask; no silent trait-widening claim.off/posmapping, sidecar and numeric values.Method8×Slot8unary palette geometry is NOTSource8×Target8adjacency. GF(2) XOR, Boolean OR/AND and NNUE wrapping/saturating int math have separate laws.Acceptance
Each topic must supply independently checked correctness, negative/refusal/mutation tests, evidence that zero-copy survives, no invented schema/permission, separate cold/hot/materialization costs, and ADOPT / KEEP_DIRECT / REJECT / DEFER. A negative ROI on QR staging is an acceptable result. Graph edge generation is unnecessary where it can be derived from an admitted law and witnessed inputs.
Horizontal ISA/PART_OF ↔ proposed vertical HHTL16 zipper extension (operator hypothesis)
Additional capstone appendix: D-QR-ABI-0 detailed rails/ABI mapping. It cross-checks existing
FacetCascade16-bytefacet_classid(4) + 6×(hi8:lo8)against two distinct proposed 16×8-bit ISA / PART_OF logical vertical zipper views. The present HHTLNiblePath16-nibble router uses 4-bit steps, and must not be mislabeled as an already-persisted HHTL16 16×8 representation. Localu8rail positions require witnessed codebook/identity mapping; a 6×2×8-bit address does not replace the QR256 8-KiB Boolean truth plane. This is a testable mapping hypothesis, not an adopted format.The four consumer plans now contain their own explicit typed-rail negative oracles. Board decisions and unresolved implementation handoff remain EXO-121, EXO-119, EXO-120, and EXO-50.
Additional capstone rail mapping note
The capstone branch also contains D-QR-ABI-0: ClassView/WideFieldMask and ISA/PART_OF horizontal rails, a separate additional documentation commit present when the branch was verified (
d66cb0b1). It maps existing 6×(hi:u8, lo:u8)FacetCascaderails and proposes future ISA/PART_OF HHTL16 zipper views without claiming they are already ABI-compatible or physically stored. The mapping and all rail laws remain experimental; no new persistent encoding or hardware ISA is approved. There are three docs in this capstone branch, no source-code changes.