[AdaWorldAPI]

Connects the resident lance-graph-report::AbiBatch lanes to the merged DT64 LaneSource socket (#1967). Execution runs through the existing Quack / mask-RISC path. This is a read adapter over lanes the batch already holds, not a durable workbook backend.

What it adds

AbiLanes (new lane_source module) implements LaneSource:

• Field resolution: the ClassView basis DT64 checked, fields(view_class(class))[pos].predicate_iri, goes to Catalog, then to FieldId, then to AbiBatch::column. There is no second field table.
• Borrowing: borrow hands out the batch's own Arc lane as a LaneRef. Nothing is copied.
• Coordinates: each source has one FrameStore with revisions (SourceId, 0, generation). publish accepts only a later generation of the same source and advances the frame, so every binding sealed earlier is refused.
• Value kinds: I32 and U32 only. A U64 reference lane is unbound.
• Behaviour: DT64 admits the MethodRef and Quack runs the fold. The test methods are named test-only/fold-N; they are not F### implementations.

No new store, field registry, codebook, identity authority or BindStore. Dependency direction: lance-graph-dt64 depends on the contract only, so report → dt64 adds no cycle.

Admission scope

• Reader scope is not production-admitted. DR's Scope is a plain { id } value and nothing issues it with authority. AbiLanes therefore has no production constructor. AbiLanes::unwitnessed exists only under the test-only feature unwitnessed-scope, and there the scope is the caller's assertion. A default build cannot construct an AbiLanes.
• No writer. Value ingress, the durable writer, codebooks, exact decimal and D4/S-INGRESS all stay open.

Falsifiers (crates/lance-graph-report/tests/lane_socket.rs, 9 tests)

• Positive: the binding hands out the batch's lanes (pointer equality). Two Quack folds share one binding and both match an independent scalar oracle. Reusing the binding (check + lane + fold, 3 rounds) allocates nothing.
• Negative:
  • after a published replacement, the old binding refuses with Frame(CoordinatesChanged);
  • after a publish, a selection in the old row order refuses with CoordinateSpace;
  • a frame from another store refuses with ForeignFrame;
  • another source's frame and store passed together leave the field Unbound;
  • re-routing the position refuses with RouteChanged;
  • another population or generation refuses with CoordinateSpace;
  • an unknown name, a catalogued field with no column, and a U64 field are each Unbound;
  • a position outside the basis refuses with FieldNotInBasis;
  • a foreign reader scope refuses with Scope;
  • publish refuses a stale generation and a foreign source.
• Disable runs (each guard broken in turn, after committing): admitting U64, copying the lane, skipping the frame advance, dropping the generation from the coordinate space, allocating in lane_of, and dropping the adapter's own frame check. Each turns its test red. The last two were green at first and gained the two dedicated tests above.

RegistryClassView

class_resolver::tests::concept_half_keys_the_basis_but_not_the_registry_category: keyed by classid_concept, which is what DT64's view_class uses, the basis resolves. Keyed by the naive low half, it does not.

There is a separate defect, pinned here and not fixed: dolce_category_id and is_known read the same key as the registry's append-order entity_type_id. A registered class's DOLCE category is therefore unreachable through the concept key. This PR adds no mapping to hide that.

CI

No workflow ran the lance-graph-report tests before. rust-test.yml now runs the plain suite and the --features unwitnessed-scope --test lane_socket suite.

Verification

• cargo test (report, plain: 44 tests; lane socket: 9 tests)
• cargo test --lib class_resolver (ontology)
• cargo clippy --all-targets -D warnings for report with and without the feature
• cargo fmt --check

The board is updated (STATUS_BOARD D-LANESOCK-2 In PR, LATEST_STATE, entry, regenerated indexes). report-rs #33 is untouched.

---

Generated by Claude Code

[coderabbitai]

Important

• Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: f3a7330b-0b65-4fac-a216-cf9264a45ed6

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-06T11:26:40.320455Z	26dfc6d	Draft marked ready

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 26dfc6d050

ℹ️ 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".