Drei gestrandete Linien landen — und die vierte bleibt draußen, weil sie angehalten wurde - #982
Conversation
Operator-directed audit, written BEFORE any replacement code. No code in this commit by design -- the brief said stop and audit first, and what the audit found changes the deliverable rather than refining it. THE CLAIM THAT WAS WRONG #973 measured (correctly) that domain+S+P+O = 4x u16 = 16 nibbles = NiblePath::MAX_DEPTH, then concluded (incorrectly) that the exact literal therefore cannot live in HHTL and identity must sit outside it. That promoted a limit of ONE sequential representation into a limit of the addressing substrate. Rejected. THE EVIDENCE, AND IT WAS CLOSER THAN THE BRIEF ASSUMED The brief named repo precedents. The sharpest item is nearer than that: - rail_geometry.rs:55, in the SAME crate #973 edited, declares RAIL_MAX_DEPTH = 2 * RAIL_SLAB_LEVELS = 24, "a slab register plus its continuation", with RailCarving::AxisSlab { reg, cont: Option<usize> }. #973 read NiblePath::MAX_DEPTH from a different module and never consulted the type that owns the question. - THIS SESSION had already measured and published the continuation, the day before, in its own words: "read() does exactly the concatenation -- p[..12] from the slab, p[12..] from the continuation slab. So the logical DN across base+continuation already exists and is already assembled." Tasks "Zipper/DN precedent archaeology" and "Phase 1: logical DN across base+continuation", both completed, depths 16-18, parent() = truncation, ancestor() = prefix containment. #973 then asserted the opposite. That is not a forgotten precedent; it is a contradiction of an in-session measurement. - facet.rs already codes the canonical tenant: FacetTier{lo,hi} + FacetCascade{facet_classid: u32, tiers: [FacetTier;6]} = 4+12 = 16 B, size-asserted, "ALWAYS 8:8; only the CONSUMER projects meaning". CascadeShape::{G6D2,G4D3,G3D4} is the re-carving algebra, byte-for-byte the same 12 units; G4D3 is the 4x24 reading. - The primitive layer was declared complete in session: hi_chain/ lo_chain, shared_prefix_tiles, row_match_mask, distance/group helpers -- "no missing HHTL operation and no reason to invent"; the split is already a no-op 2x 6x2x8bit cast. - E-WORDNET-MAKES-THE-4-ARY-ADDRESS-SEMANTIC-1 (#875): a real taxonomy used AS the address, with W4 measuring 2.47 hops of structure the 16-ary router is blind to. #876 is the paired caution about reporting an intake limit as a property of the address. - OSM/WebMercator and Bible Rosetta: coordinate-plus-facets, shipped. MedCare-rs runs FMA anatomy (70k nodes, ~4M vertices) as HHTL at 4x24 -- exactly the case a 16-nibble ceiling would have called impossible. MORTON: THE SAME MISTAKE, MADE AGAIN INSIDE THE CORRECTION An earlier draft of this audit reached for a Morton interleave as the S3.0 locality view. The brief mentioned Morton ONLY to deny the premise "Morton implies lossy". Turning a denied premise into a component to build is a second instance of the failure being documented. Removed, and recorded as such, with the rulings pinned: no SoA uses Morton for identity, no NARS resides in Morton. WHAT S3.0 BECOMES Nothing needs minting. The exact literal (D,S,P,O) is a READING over the canonical 6x2x8 facet tenant, using primitives that already exist, with base+continuation for depth. A parallel 4x u16 container would have been the ruling-E anti-pattern in a new costume. Deliberately unanswered: which rails carry D/S/P/O. The canon assigns tiers HEEL:HIP / TWIG:LEAF / family:identity and le-contract names L1 part_of:is_a, L2 memberof:members, L3 mereology:taxonomy, L4 palette256:palette256. Choosing a projection unilaterally is the exact creative completion this audit exists to stop. Recorded as E-A-LOCAL-DERIVATION-CANNOT-OVERRULE-A-MEASURED-COUNTEREXAMPLE-1; E-THE-LITERAL-CANNOT-LIVE-IN-THE-PATH-IT-ROOTS-1 is retracted (it never merged -- #973 closed unmerged -- so no board entry on main needs editing).
A read-only audit measured both rows weaker than I wrote them. OSM: the note said the Cartesian->HHTL mapping was exact "in a shipped domain". It is not shipped. MERCATOR-HHTL-HELIX-MAP.md:5 legend: [G] = in code, [H] = design MERCATOR-HHTL-HELIX-MAP.md:17 section 1 is graded [H] MERCATOR-HHTL-HELIX-MAP.md:94 its round-trip falsifier is unrun ogar-osm/src/lib.rs:212-296 a byte-position table; zero mercator math cesium/src/esri_crs.rs:285 inverse_mercator = unimplemented!(scaffold) cesium/src/osm_pbf.rs:12 "this file is D-OSM-1 -- the stub" OGAR docs/DISCOVERY-MAP.md:222 D-OSM graded H / IDEA / queued Rosetta: the plan's own status line is PROPOSED (doc-only), the verse row is deliverable D-RCC-2, and no verse-identity type exists in crates/. Both rows still refute the closed PR's inference -- nothing anywhere treats the address plane as unable to hold a Cartesian point -- but they are DESIGN precedents, not shipped ones, and I strengthened receipts to fit the argument. That is the same reflex that produced the closed PR, committed inside the document written to record it. Marked in place. The Rosetta correction also states the book row the way the operator put it: the address exists, the concept field does not. A book is a horizontal stream of addressed sentences; concepts are the vertical axis and are not materialized as SoA at HEEL/HIP. Reasoning hydrates them.
…SS-INTO-IT-1 VarnodeFacet's 12-byte payload is 3x32-bit contiguous = le-contract §3a's G3 wide-quad, the axis-less grace carving. Legal today only because PROVISIONAL_R2IL_VARNODE = 0x0000 keeps every varnode in the dormant default class. The 0xC4 BinaryLifting mint that ogar_codebook.rs:112-117 already names for the ruff PR3 arc converts it into a real addressed class -- and §3a:104 says new classes must not be born into G1-G3. Three resolutions recorded, none prescribed; the identity_quad named exception is the precedent if the carving is permanent. Also records: the SPO intake arms correctly do not use R2IL (two-arm split); ruff_spo_address's zero in-ruff dependents is not dead code (consumed cross-repo by ogar-from-ruff); a storno of this session's own wrong claim that PR3's home was still an open slot-vs-crate call; and the V4 naming collision -- the density insight is right, the label collides with the plan's ratified 'no V4', with the dialectic engine's existing V4 slice, and with V3 being a layout canon rather than a density claim. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AGVLyRZNEKKBSfBDJfbY3V
Two gates blocked in two repos by two sessions are the same failure on two axes: an address derived from the accident of layout (VarnodeFacet's flat 3x32 G3 register, no byte axis, no rail) or from the accident of schedule (a landing key minted from completion order, measured as two publication hashes for the same work). The tell that it is convergence rather than an imposed frame: the two docs were written independently, neither cites the other, and both name their exit with the same word-family -- cosine-REPLACEMENT and identity-DERIVED. Graded SYNTHESIS/CONJECTURE, not a ruling: it decides neither gate, it explicitly does not license re-carving VarnodeFacet (64-bit offset plus size does not fit 6x(8:8), and the identity_quad precedent exists for exactly this case), and it does not prescribe F-ORD's fix. Carries its own falsifier: a gate cleared by a fix that keeps the address derived from layout or schedule scopes this entry down or ends it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AGVLyRZNEKKBSfBDJfbY3V
Operator ruled: V4 is for R2IL 100% coverage and other special needs; V3 stays as before. V4 is a SIBLING tier, not a successor. Stornos my own entry from earlier today: of the three grounds I gave for rejecting the V4 label, one is superseded (a session verdict does not outrank an operator ruling), one is downgraded to a naming-hygiene item (the dialectic-engine V4 slice still collides), and one was simply wrong -- 'implies V3-superseded' rested on an assumption the operator did not share, and 'V3 wie bisher' denies it directly. Reframes the G3 question: section 3a governs V3, so if R2IL is a V4 tenant the carving trilemma was posed in the wrong frame -- the density is the REASON for V4, not a violation needing an exception. Flagged as my inference, not the operator's words. Partially triggers the ADDRESS-FROM-THE-THING falsifier: the spatial instance is suspended pending V4's layout, not refuted; the temporal F-ORD instance is untouched. Names five open questions the ruling does not answer -- V4's layout, its home, the full special-needs set, V3-vs-V4 routing, and whether the 0xC4 mint is V3 or V4 -- rather than inventing answers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AGVLyRZNEKKBSfBDJfbY3V
…e plan steps The V4 ruling entry downgraded "V4 already denotes the dialectic-engine V4 field-search slice" to a hygiene item with a disambiguation owed. That was mistaken about the source: dialectic-engine-v1.md section 4 is headed "Build order" and its V0 through V5 are integration-plan steps, the same kind of ordinal as its own S1 through S11 section labels. V4 there is one stage of six, not a version of anything. A step ordinal and a substrate tier are independent counters over different kinds, so there is no shared namespace and nothing to rename. The storno says so explicitly, because the entry as written would have sent a later session to rewrite a correct plan. All three objections to the V4 label are now retracted: two superseded by the ruling, this one simply wrong about the document. The G3 reframing and the open questions did not rest on it and are unchanged.
…Haelfte Zwei Dinge, beide aus dem D-ACR-7-Nachlauf. Erstens die Board-Korrektur. Nach #981 sah D-ACR-3 wie das eine Deliverable aus, dessen Gate gefallen ist — es hing an D-ACR-1, und D-ACR-1 ist geshipped. Gemessen hat es aber einen zweiten Blocker, den niemand notiert hatte: der Schreibpfad, den es bewachen soll, existiert nicht. SoaEnvelope hat EINEN produktiven Implementor (NodeRowPacket, canonical_node.rs:1540; die anderen zwei sind Testtypen), und mailbox_owner() hat null Aufrufer ausserhalb seines eigenen Moduls. Es gibt keinen ontologie-eigenen Write, zu dem hin verfolgt werden koennte, und keinen session-getaggten Read, von dem her. Ein Test darauf wuerde etwas behaupten, das kein Code verletzen kann — genau die Form, die die Falsifizierbarkeits-Regel verbietet ("what input would make this fail? If none exists, delete or rewrite it"). Dieselbe Befundform wie D-ACR-0s EXISTS-UNCALLED, nur eine Ebene weiter. Zweitens der Follow-up, den der #981-Body als "filed, not owned here" gefuehrt hat. from_v1 kopiert den v2-Tail (w_slot/truth/spare) roh und BEHAUPTET damit, dass ein Produzent ihn absichtlich gestempelt hat. Unter dem v1-Layout ist das beweisbar harmlos, weil truth_raw und spare dort dokumentierte Null-Stubs sind. Unter v2 lesen sie echte Bits, und die Signatur sagt nicht, ob die gemeint waren oder Rueckstand sind. from_v1_tail_unstated ist die ehrliche Gegenhaelfte auf der Schreibseite: ein Lift, der den Tail nicht beansprucht, sondern auf 0 setzt. Ein Konsument liest dann den Zero-Fallback (Trust, Band Absent) statt eines plausiblen falschen Ordinals — dieselbe Haltung, die band_reading auf der Leseseite ratifiziert hat, wo unstated Unknown heisst und Unknown Verweigerung. from_v1 bleibt byte-identisch; nichts an den 17 Aufrufstellen aendert sich. Neu ist nur die Wahl, die es vorher nicht gab, plus ein Querverweis in beiden Doc-Kommentaren. Zwei Tests, beide Haelften. Auf einem Tail ungleich null lassen sich die Lifts unterscheiden (der eine bewahrt Ordinal fuer Ordinal, der andere nullt), und es unterscheiden sich AUSSCHLIESSLICH die Bytes 8 und 9 — 0..8 und 10.. sind identisch. Auf einem bereits-null-Tail sind beide byte-gleich: der Konstruktor ist eine Aussage ueber Provenienz, keine unbedingte Mutation. Ohne die zweite Haelfte waere er ein Waechter, der auf alles anschlaegt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KCGhDYoQBXs3poaR7sFuqp
…claude/d-acr-fortsetzung
…8d' into claude/d-acr-fortsetzung
…provenance' into claude/d-acr-fortsetzung
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 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 |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_e0a0c481-b098-440d-b31d-7b6df1aabe6c) |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ff0f0b06f1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| /// Every other field is lifted exactly as [`Self::from_v1`] lifts it. | ||
| /// Note that [`Self::rehydrate`] on the result is therefore **not** a | ||
| /// bit-exact round trip of the source: the tail was deliberately dropped. | ||
| pub fn from_v1_tail_unstated(e: CausalEdge64, target: u16) -> Self { |
There was a problem hiding this comment.
Return Unknown provenance with unstated-tail lifts
When this result is passed through the normal V3 projection path with EdgeProvenance::V3Register, project_truth and project_band accept the zeroed ordinals as valid, yielding Crystalline/Direct and Surface rather than UnknownProvenance; BandPresence::Absent is a separate class declaration and is not encoded by byte 9 being zero. Because this constructor returns only Self and stores no provenance marker, it does not actually carry its “unstated means refuse” assertion to the consumer and can silently convert unknown data into plausible facts. Return the register together with EdgeProvenance::Unknown (or otherwise preserve that metadata) so callers cannot treat this lift as a clean V3 register.
Useful? React with 👍 / 👎.
This PR lands two falsifiers in `crates/causal-edge/src/edge_v3.rs`, and #981 landed a `#[test]` there before it. Neither could ever have failed in CI: no workflow names `causal-edge`. Its own PR body records the symptom without naming it — "standalone, `--manifest-path` — es steht unter `exclude`" — which is the same "green on a developer machine" shape `rust-test.yml` already describes when it closed this hole for deepnsm, supervisor and bgz-tensor. `causal-edge` is workspace-EXCLUDED but a path-dep of `lance-graph`, `lance-graph-planner`, `cognitive-shader-driver` and `sigma-tier-router`, so its LIB does compile inside gated builds. It is the TESTS that were unarmed — including this PR's. Added, both measured on the pinned 1.97.1 toolchain before landing: - `rust-test.yml`: `cargo test --manifest-path crates/causal-edge/Cargo.toml` — 75 passed, 0 failed. - `style.yml`: `cargo fmt --manifest-path crates/causal-edge/Cargo.toml -- --check` — clean today; the step keeps it that way. NOT added: a clippy gate. `clippy --all-targets -- -D warnings` returns 7 errors on this crate, every one of them pre-existing and NONE in the `edge_v3.rs` this PR touches (they sit in `edge.rs` ×7 lines, `tables.rs:37`, `v2_layout_tests.rs:20`). Gating them here would fail this PR for defects it did not introduce, so they are recorded as ISSUES ISS-CAUSAL-EDGE-CARRIES-SEVEN-PRE-EXISTING-CLIPPY-FINDINGS with their exact locations, and the crate is left with a test gate and a format gate but no lint gate — an asymmetry that is deliberate and written down rather than left to be rediscovered. The wider measurement this came out of: no workflow in this repo runs `--workspace` or `--all`, so every gate is a hand-maintained allowlist and adding a crate to `[workspace] members` adds it to nothing. Nine members plus this excluded crate were reached by no job. That is EPIPHANIES E-THE-GATE-IS-A-HAND-MAINTAINED-ALLOWLIST-NOT-THE-WORKSPACE-1 and ISSUES ISS-CI-GATE-IS-AN-ALLOWLIST-NINE-MEMBERS-UNGATED, both on the claude/hydrate-from-zip branch; the remaining eight are one operator decision (a single --workspace job, or a recorded rationale per omission), not a blind eight-job addition.
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_612c7077-a7d0-4ef5-aac5-4abbf2cea2f3) |
Nach #981 lagen vier Branches unmerged. Drei sind fertige Arbeit, die nie einen PR bekam; die vierte ist etwas anderes, und der Unterschied ist der eigentliche Inhalt dieses PRs.
Was landet
s3-0-exact-literaldocs/architecture/S3-0-EXACT-LITERAL-AUDIT.md) — ausdrücklich geschrieben, damit der Fehlschlag sichtbar bleibt „rather than being smoothed into 'an earlier design iteration'" — plus die Selbstkorrektur der eigenen OSM- und Rosetta-Überclaimsruff-r2il-lancegraph-3tdt8dE-R2IL-VARNODEFACET-IS-A-G3-CARVING-…,E-ADDRESS-FROM-THE-THING-NOT-THE-ACCIDENT-1, das Operator-RulingE-V4-IS-THE-100-PERCENT-TIER-V3-UNCHANGED-1, und ein Storno der V4-Namenskollisions-Einwendungd-acr-3-gate-and-from-v1-provenancefrom_v1_tail_unstatedAlle drei mergen konfliktfrei auf
main. Geprüft, nicht angenommen: die Audit-Datei fehlt aufmain, die drei Epiphanie-Ids haben dort null Treffer,from_v1_tail_unstatedexistiert nicht.Der D-ACR-3-Befund, weil er die Leiter bewegt
Nach #981 sah D-ACR-3 wie das eine Deliverable aus, dessen Gate gefallen ist — es hing an D-ACR-1, und D-ACR-1 ist geshipped. Gemessen hat es einen zweiten Blocker, den niemand notiert hatte: der Schreibpfad, den es bewachen soll, existiert nicht.
SoaEnvelopehat EINEN produktiven Implementor (NodeRowPacket,canonical_node.rs:1540; die anderen zwei sind Testtypen), undmailbox_owner()hat null Aufrufer außerhalb seines Moduls.Es gibt also keinen ontologie-eigenen Write, zu dem hin verfolgt werden könnte, und keinen session-getaggten Read, von dem her. Ein Test darauf würde etwas behaupten, das kein Code verletzen kann — genau die Form, die die Falsifizierbarkeits-Regel verbietet. Dieselbe Befundform wie D-ACR-0s
EXISTS-UNCALLED, eine Ebene weiter.from_v1_tail_unstatedist der zugehörige Follow-up:from_v1kopiert den v2-Tail roh und behauptet damit, ein Produzent habe ihn absichtlich gestempelt. Der neue Lift beansprucht ihn nicht, sondern nullt ihn — dieselbe Haltung, dieband_readingauf der Leseseite ratifiziert hat, wo unstated Unknown heißt und Unknown Verweigerung.from_v1bleibt byte-identisch; die 17 Aufrufstellen ändern sich nicht.Was NICHT drin ist, und warum
claude/s3-0-causal-literal(20.08., +719 über 5 Dateien, davon ein 552-Zeilen-Modulcausal_literal.rs) bleibt draußen. Es ist nicht gestrandet, sondern angehalten — mains eigenesSTATUS_BOARDsagt es („S3.0 closed as NOT-NEEDED … stopped before merge by the operator"), undE-A-LOCAL-DERIVATION-CANNOT-OVERRULE-A-MEASURED-COUNTEREXAMPLE-1benennt es als Instanz 2:Es zu mergen hätte genau das wiedereingeführt, was ausgeschlossen wurde. Das steht hier, damit die nächste Sitzung diese Branch nicht für vergessen hält und sie nicht zum zweiten Mal aufsammelt.
Verifikation
causal-edge(standalone,--manifest-path— es steht unterexclude): 75 grün.lance-graph-contract: 1207 grün. Die zwei neuen Provenienz-Tests sind zweiseitig und beide laufen:from_v1_tail_unstated_drops_what_from_v1_claims(kann feuern — auf einem Tail ≠ 0 unterscheiden sich die Lifts, und zwar ausschließlich in Byte 8 und 9) undon_a_zero_tail_the_two_lifts_agree(kann schweigen — der Konstruktor ist eine Aussage über Provenienz, keine unbedingte Mutation). Gebaut mit allen fünf Profil-Variablen.Stand der Leiter danach
D-ACR-0 ✅ · D-ACR-1 ✅ (
attention_facet.rs) · D-ACR-7 ✅ (band_reading.rs, #981) · D-ACR-3 ⛔ zweiter Blocker gemessen → nächstes lauffähiges Deliverable ist D-ACR-8 (Rubicon-Zeuge), das nur an D-ACR-1 hängt.Generated by Claude Code