0x17 is loco's domain; ogar-blockly is a consumer seated at 0x1717 - #255
Merged
Conversation
The authority half of blockly-rs's hot-plug. Before this, a blockly-rs plug answered `UnknownClassid(0x1701)`: `capability_registry:: resolve_hotplug` joins a consumer's classids against `class_ids::ALL`, and the Blocks domain had zero rows there. MINTED — two SCHEMA concepts, not the opcode palette: - `block_function` (0x1701) — one function body; the classid a stored FunctionNode is addressed by, and the only Blocks concept that binds capabilities. - `block_inventory` (0x1702) — the registry row; minted and addressable but binds nothing, because a registry read never touches a body and no executor has an inventory arm. The 2026-08-04 reserve withheld the OPCODE vocabulary (256 Blockly / Scratch operation bytes) from this codebook, and that still holds: an opcode is an FnIndex byte inside a body, resolved through ogar-loco's vocabulary table, never a classid. The domain-count test is regraded 0 → 2 with that distinction spelled out, plus the tripwire: if it ever counts in the hundreds, the palette leaked into the shared codebook. blocks_actions declares five capabilities on `block_function` — every one a real blockly-abi public function (lower_script / raise_calls / render_text / parse_text / klickweg_address), because resolve_hotplug checks coverage in BOTH directions and an aspirational entry would fail the consumer's own activation rather than quietly describing work nobody did. Registered in `domain_tables()` — the step whose omission was the ogar-osm defect `geo_actions` was written to correct. ogar-blockly's `BlockConcept::concept_id()` now READS `class_ids` instead of re-declaring 0x1701/0x1702. Two constants for one id is exactly the drift the classid join exists to catch. Also bumps the OGAR half of the two-sided COUNT_FUSE (90 → 92); the lance-graph mirror half lands in the paired PR.
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_ff55fc0d-6023-4913-b0ac-9a933884c9ba) |
CI caught what my scoped test run missed: `ogar-class-view` keeps a
registry that must carry EVERY codebook concept, gated in both
directions —
every_codebook_id_appears_in_class_ids_all
-> block_function (0x1701) in class_ids::ALL but missing from
OgarClassView registry
known_class_ids_iterates_in_stable_codebook_order
-> known_class_ids drifted from codebook order (missing 5889, 5890)
Both are the reverse gate working exactly as designed: a CODEBOOK
promotion that lands in ogar-vocab without a matching registry entry is
supposed to bang here, and it did.
Registers `block_function` / `block_inventory` in
`all_canonical_classes()`. The opcode palette is deliberately still
absent — an opcode is an `FnIndex` byte inside a function body, never a
classid, so it has no ObjectView.
Process note: the previous commit was verified with
`cargo test -p ogar-vocab -p ogar-blockly -p ogar-loco -p ogar-ro` —
only the crates I edited. Minting a codebook concept has workspace-wide
obligations by construction, so the scoped run could not have caught
this. Now verified with `cargo test --workspace`: 80 test binaries, 0
failures; `cargo clippy --workspace --all-targets -- -D warnings` clean;
`cargo fmt --all` clean.
The previous commit ran `cargo fmt --all`, which reformatted six files this change never touched — ogar-encryption, ogar-obo (x4), ogar-render-askama — ~309 lines of churn unrelated to registering two Blocks concepts. Backed out here so the CI fix is the 9-line registry entry alone and the PR diff says what it means. Scope fmt to the crate under change; `--all` sweeps the workspace. (Same shape as the tesseract-rs `--all` lesson: a workspace-wide flag follows path deps and reformats things you did not touch.) Verified after the revert: `cargo test --workspace` 80 test binaries, 0 failures.
Records the distinction the blockly-rs migration blurred, and the deferred direction, so a later session does not re-derive either. `ogar-loco` is UNIVERSAL — the call ABI + shared-core discipline every sibling vocabulary rides. The Blocks codebook (0x17XX) is PARTICULAR — one frontend family's schema. What shipped mints the particular into the shared codebook, because `ogar-blockly` deps `ogar-vocab` (so ogar-vocab cannot read 0x1701 from ogar-blockly) and `resolve_hotplug` joins against `class_ids::ALL`. Operator ruling: the mint stays — two rows is tiny, NOT to be reverted. The later shape is pull-not-mint: ogar-vocab on the authority side, lance-graph-ogar on the other, plug-and-play as the trigger, with the classid travelling in the plug so the codebook is consulted rather than permanently resident. Deferred with a named tripwire: revisit when a frontend wants its FULL palette addressable, or when a second family (scratch-rs) needs the same particular mint — the reserve keeping 256 opcode bytes out of the shared codebook is the same pressure one level up.
This reverts commit a397495.
…ons table" This reverts commit f134ea8.
AdaWorldAPI
marked this pull request as ready for review
August 7, 2026 11:50
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3dd095c93d
ℹ️ 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".
Comment on lines
+145
to
+151
| What shipped: `block_function` (`0x1701`) + `block_inventory` | ||
| (`0x1702`) are minted into `class_ids::ALL` + `CODEBOOK`, because | ||
| `resolve_hotplug` joins a plugged classid against `class_ids::ALL` | ||
| and answers `UnknownClassid` otherwise. The forcing constraint is a | ||
| dependency direction: **`ogar-blockly` deps `ogar-vocab`, so | ||
| `ogar-vocab` cannot read `0x1701` from `ogar-blockly`.** A permanent | ||
| mint was the only thing that made the join resolve. |
There was a problem hiding this comment.
This claims that both concepts are now present in class_ids::ALL and CODEBOOK, but this commit changes only this knowledge file: in the reviewed tree crates/ogar-vocab/src/lib.rs still pins ALL.len() to 90 and asserts that the Blocks domain contains zero concepts, capability_registry::domain_tables() has no Blocks entry, and no blocks_actions module exists. Consequently a blockly plug using 0x1701 still receives UnknownClassid, so the advertised authority half and paired consumer activation remain broken while this migration guide incorrectly records them as shipped. Add the vocabulary/action-table implementation to this change or describe it as pending instead.
AGENTS.md reference: .claude/AGENTS.md:L141-L146
Useful? React with 👍 / 👎.
Corrects an ownership inversion: this branch previously read as though a
block frontend owned the 0x17 domain and the universal node shapes. It
does not — 0x17 belongs to the substrate.
The tell that 0x1701/0x1702 are loco's: they are described entirely in
ogar-loco's own vocabulary (FunctionBody, LaneShape, the value slab). An
elixir-shaped thinking template and an RO relation body are the SAME
shape with a different palette, which is exactly why ogar-loco is global
interest — thinking orchestration rides the same call ABI.
The 0x17 layout (operator-ruled):
0x1701 / 0x1702 loco the node shapes (body, inventory)
0x1703 - 0x1716 loco, reserved substrate headroom (uplifting,
Klickwege, whatever the ABI needs)
0x1717 + consumers one slot per frontend palette
Consumers are seated HIGH on purpose so the substrate keeps contiguous
room beneath them. A frontend that outgrows one slot gets its own domain
rather than eating that headroom — "scale = the next cascade level,
never field-widening".
- ogar-loco: new `LocoConcept` owning 0x1701 (FunctionBody) / 0x1702
(Inventory), documenting the domain layout.
- ogar-blockly: `BlockConcept` collapses from two ids to ONE —
`Palette` = 0x1717 — naming which vocabulary resolves a node's call
bytes, never the node's shape. `SoaSplit` now resolves to
`LocoConcept`, because the inventory/content split is the substrate's
for every vocabulary, not this palette's.
- Nothing is minted into the shared codebook: 0x17XX stays at ZERO rows,
which is what makes the palette plug-and-play.
Also fixes a codex P1 on the knowledge doc: the entry described a mint
as shipped that had since been reverted, so a reader would have been
told 0x1701 resolves when it does not. Rewritten to record actual state,
with both open items named as pending (the global registration of loco's
ids, and the plug-carried-classid activation path) rather than claimed.
Workspace: 80 test binaries, 0 failures; clippy -D warnings clean;
rustdoc -D warnings clean on the three touched crates.
AdaWorldAPI
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The ownership inversion this corrects
0x1701and0x1702are described entirely inogar-loco's vocabulary —FunctionBody,LaneShape, the value slab. An elixir-shaped thinking template and an RO relation body are the same shape with a different palette. That is precisely whyogar-locois global interest: thinking orchestration rides the same call ABI. A block frontend owning those ids read as a consumer owning the universal shape.The
0x17layout0x1701/0x17020x1703–0x17160x1717+ogar-blockly=0x1717)Consumers are seated high on purpose, so the substrate keeps contiguous room beneath them. A frontend that outgrows its slot gets its own domain rather than eating that headroom — the same "scale = the next cascade level, never field-widening" rule as the GUID canon.
What changes
ogar-loco— newLocoConcept:FunctionBody(0x1701) /Inventory(0x1702), plus the domain layout documented above.ogar-blockly—BlockConceptcollapses from two ids to one:Palette=0x1717. It names which vocabulary resolves a node's call bytes, never the node's shape.SoaSplitnow resolves toLocoConcept, because the inventory/content split is the substrate's for every vocabulary.0x17XXstays at zero rows — that is what keeps the palette plug-and-play, andcanonical_concept_domain(0x1717)already routes today on the reserved-domain slot alone.Why the lance-graph PR was closed
ogar_vocab::class_ids::ALLis mirrored intolance_graph_contract::ogar_codebookunder a compile-time count fuse. Anything minted there is by construction a lance-graph change — the original mint turned lance-graph red againstmainand dragged inogar-class-view,all_promoted_classes,domains_agreeand both fuse halves. Registering a frontend's codebook in lance-graph is an OGAR concern that leaked. lance-graph #905 is closed; its mirror is reverted; lance-graph is back to 90.Codex P1 — fixed
The review correctly caught that the knowledge-doc entry described a mint as shipped which had since been reverted, so a reader would be told
0x1701resolves when it does not. Rewritten to record actual state, with both open items named pending rather than claimed:0x1701/0x1702are additionally promoted into the shared codebook as the global registration — an operator decision, not taken here;ogar-locois written so nothing breaks if they never are;0x1717still receivesUnknownClassid.Verification
cargo test --workspace— 80 test binaries, 0 failurescargo clippy -p ogar-loco -p ogar-blockly -p ogar-ro --all-targets -- -D warnings— cleanRUSTDOCFLAGS="-D warnings" cargo doc— clean on the three touched crates