Skip to content

Remove ogar-blockly: a palette belongs to its consumer, not the substrate - #260

Merged
AdaWorldAPI merged 1 commit into
mainfrom
claude/rust-scratch-abi-soa-gsamge
Aug 7, 2026
Merged

Remove ogar-blockly: a palette belongs to its consumer, not the substrate#260
AdaWorldAPI merged 1 commit into
mainfrom
claude/rust-scratch-abi-soa-gsamge

Conversation

@AdaWorldAPI

Copy link
Copy Markdown
Owner

Removes ogar-blockly. blockly-rs declares its own palette at 0x1717 and plugs it into ogar_loco::registry::VocabularyRegistry at boot (blockly-rs b7ee0a4), so the OGAR-side crate had nothing left to own — a concept id, an empty Vocabulary impl, and a plug helper the consumer can write itself.

Why healthcare is the deciding comparison

medcare-rs is a private consumer, yet its concepts (0x09XX) are minted in the canon codebook and healthcare_actions registers unconditionally in domain_tables(). Activation is Cargo presence of the consumer (lance-graph-ogar's rule), never a feature that switches the codebook on. That works because those concepts are shared: RBAC and ontology both key on the canon half, and the consumer pulls addresses it does not own.

A palette is the opposite shape. Which bytes above ogar-loco's shared floor mean what is one frontend's private reading of a stored body — not ontology, not RBAC-relevant, nothing another consumer resolves against. It routes through VocabularyRegistry, keyed by a consumer-declared slot, with ConceptTaken as the uniqueness enforcement.

So there are two shapes, and the blocks Cargo feature was a third mechanism invented for a case the second already served — while making the substrate name a consumer crate in another repository (BLOCKS_EXPECTED_EXECUTORS = ["blockly-abi"]).

shape seam example
shared concept domain canon mint + unconditional DomainTable + resolve_hotplug healthcare (0x09XX, medcare-rs)
palette (reading of a body) consumer-declared slot + VocabularyRegistry::plug Blockly (0x1717, blockly-rs)

Removed

  • crates/ogar-blockly/ and ogar-vocab/src/blocks_actions.rs
  • the blocks Cargo feature and its activated-concept seam: activated_concepts, activated_concept_id, the or_else arm in derive_action_rows, resolve_concept_row's second lookup, the feature-gated DomainTable

What replaces the OFF-half gate

Two always-compiled tests: the canon carries no 0x17XX row (the count the lance-graph fuse pins stays 90), and a palette classid does not resolve as a hot-plug in any build — while canonical_concept_domain(0x1717) still routes on the reserved byte. Both run under cargo test --workspace, so the CI step that forced --no-default-features to reach a cfg-gated module is gone with the feature it guarded.

ogar-ro's cross-crate test no longer borrows a frontend's vocabulary — it plugs a local StubPalette at 0x1718. ogar-loco / ogar-ro docs name blockly-rs where they named the deleted crate.

Verification

cargo test --workspace — 78 test targets, 0 failures. cargo clippy --workspace --all-targets clean. cargo fmt scoped per-crate.


Generated by Claude Code

…rate

blockly-rs now declares its own palette at 0x1717 and plugs it into
ogar_loco::registry::VocabularyRegistry at boot (blockly-rs b7ee0a4), so the
OGAR-side crate had nothing left to own: a concept id, an empty Vocabulary
impl, and a plug helper the consumer can write itself.

Healthcare is the precedent that settles what stays. medcare-rs is a private
consumer, yet its concepts (0x09XX) are minted in the canon codebook and
healthcare_actions registers unconditionally in domain_tables() -- activation
is Cargo presence of the consumer, never a feature that switches the codebook
on. That works because those concepts are SHARED: RBAC and ontology both key
on the canon half, and the consumer pulls addresses it does not own.

A palette is the opposite shape. Which bytes above ogar-loco's shared floor
mean what is one frontend's private reading of a stored body -- not ontology,
not RBAC-relevant, nothing another consumer resolves against. It routes
through VocabularyRegistry, keyed by a consumer-declared slot, with
ConceptTaken as the uniqueness enforcement.

So the `blocks` Cargo feature and its activated-concept seam
(activated_concepts / activated_concept_id / the or_else arm in
derive_action_rows / resolve_concept_row's second lookup) were a second
activation mechanism built for a case the registry already served -- and it
made the substrate name a consumer crate in another repository
(BLOCKS_EXPECTED_EXECUTORS = ["blockly-abi"]). Removed entirely; there is one
codebook and no feature adds to it.

What replaces the OFF-half gate: two always-compiled tests asserting the canon
carries no 0x17XX row (the count the lance-graph fuse pins stays 90) and that a
palette classid does not resolve as a hot-plug in any build, while
canonical_concept_domain(0x1717) still routes on the reserved byte. Both run
under `cargo test --workspace`, so the CI step that forced
`--no-default-features` to reach a cfg-gated module is gone with the feature.

ogar-ro's cross-crate test no longer borrows a frontend's vocabulary -- it
plugs a local StubPalette at 0x1718 -- and the ogar-loco / ogar-ro docs name
blockly-rs where they named the deleted crate.

cargo test --workspace: 78 test targets, 0 failures. clippy clean.
@cursor

cursor Bot commented Aug 7, 2026

Copy link
Copy Markdown

Bugbot couldn't run - usage limit reached

Bugbot 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_bd79662e-0c44-4bd1-8a1c-9d63026568a3)

@AdaWorldAPI
AdaWorldAPI marked this pull request as ready for review August 7, 2026 20:01
@AdaWorldAPI
AdaWorldAPI merged commit d9c7fc1 into main Aug 7, 2026
2 checks passed
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.

2 participants