Skip to content

contract: delete the write-only scope-kind registry static (stacked on #994) - #996

Draft
MattJackson wants to merge 2 commits into
predevfrom
lane-cabi-scope-kinds-static
Draft

MattJackson wants to merge 2 commits into
predevfrom
lane-cabi-scope-kinds-static

Conversation

@MattJackson

Copy link
Copy Markdown
Collaborator

CONTRACT-ABI lane, item 3 (contract statics, part 2). STACKED on #994 because both strike adjacent rows of qa/contract-stateless.toml. It stays DRAFT until #994 lands (rule 19).

THE DESIGN A.8 "Statelessness" (docs/design/BUSBAR-1.6.0.md l.3701) and C.2 (l.3893: Contract statics (codec.rs, records.rs:94, ids.rs:330): deleted). This PR deletes the records.rs:94 static.

busbar_contract::records::scope_kinds::REGISTERED was write-only state. Since 1.6.0 SDK-SCOPEKINDS the VirtualKey wire serializes every scope kind under its own allowed_{kind}s field whether or not it is registered, because a dropped-in store's copy of the static was always empty. On predev the only reader of is_registered is the contract's own test precondition (tests/records_tests.rs:314). The writers are the kernel's plane fold (plane/registry.rs:331-340) and the store conformance fold (conformance/store.rs:838-839), and they wrote for nobody.

  • records.rs: REGISTERED, scope_kinds::{register, is_registered}, BUILTIN_POOL_KIND and register_scope_kind are deleted. wire_field_for/kind_for_wire_field, the wire convention, stay, and the module doc says the wire is a carrier with no process state. The plane-noun counts in the file are unchanged (mcp 14, A2A 2, agent 4).
  • busbar-kernel/src/plane/registry.rs: the scope-kind registration loop is deleted.
  • plugin-loader/src/conformance/store.rs: the two registrations are deleted. The scope-kind round trip still runs over the key's own data.
  • busbar-contract/src/tests/records_tests.rs: the register_scope_kind calls and the is_registered precondition are removed. The three wire tests (round trip, additive fields, unregistered kind verbatim) still pin the wire.
  • qa/contract-stateless.toml strikes the records.rs REGISTERED row: 41 → 40 on top of kernel: the word interner (Registration) moves out of busbar-contract #994.

RED: the drain-only contract-stateless ledger no longer forgives records.rs, so a reintroduced registry is a finding with no row. No behaviour moves: nothing read the registry.

Not in this PR (reported to the coordinator):

No dependency change.

…oves out of busbar-contract

THE DESIGN A.8 "Statelessness" (BUSBAR-1.6.0.md l.3701) and C.2 (l.3893: "Contract statics
(codec.rs, records.rs:94, ids.rs:330): deleted, with host tables used instead"). The image's one
vocabulary is process state, so it is the host's: busbar_kernel::vocabulary holds
Registration, MAX_VOCABULARY, VOCABULARY and FROZEN, moved verbatim but for the docs that
reasoned about a plugin reaching the interner (a plugin's closure is the contract, which now
holds none of it). Callers in the composition root and busbar-llm name busbar_kernel::Registration;
plane crates' docs name the host's interner in prose. qa/contract-stateless.toml strikes the
three ids.rs rows (LazyLock, FROZEN, VOCABULARY) this drains.

RED: the vocabulary tests move with it (busbar-kernel tests/vocabulary_{cap,freeze,resolve,intern}.rs),
naming busbar_kernel::Registration; the contract-stateless ledger no longer forgives ids.rs.
…ire carries every kind as data

THE DESIGN A.8 "Statelessness" (BUSBAR-1.6.0.md l.3701) and C.2 (l.3893, "records.rs:94 ...
deleted"). records::scope_kinds::REGISTERED was write-only: since 1.6.0 SDK-SCOPEKINDS the wire
serializes every kind (registered or not) under its own allowed_{kind}s field, and nothing in the
workspace read is_registered but its own test. The registry, register/is_registered and
register_scope_kind go; the kernel's plane fold stops registering scope kinds; the store
conformance fold's scope-kind round trip runs as before over the key's own data.
qa/contract-stateless.toml strikes the records.rs REGISTERED row this drains.

This branch has not been deployed

No deployments
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.

1 participant