core: verify full WireTree composition across carrier access and disposition legacy gaps

[jm9e]

Outcome

Complete the runtime side of bitwire #29 under #2 using accepted decision 0012. The production core already provides full WireTree = DeixisNode<Wire>; this packet establishes its carrier/profile composition evidence and explicitly disposes the historical declared-access gap ledger.

Fixed distinction and design gate

Wire sends addresslessly. WireTree supplies own, complete exact-byte-keyed children, partial selection, decomposition and reconstruction. AddressedWire supplies opaque pathful access; it never gains structural guarantees through naming or prefix binding.

The old 39 declared-access cases include 19 gaps in released child-only Mount. For each, map the intended observation to a lawful full-tree constructor/adapter or retain it as a historical addressed limitation. bitwire owns acceptance of that mapping. Do not add a competing opaque composition API solely to make a ledger disappear, and do not silently edit historical expectations.

Deliverables and acceptance

• A reviewed matrix links all legacy observations to current structural/profile cases, unsupported mappings and their reasons; PR52 remains honest about its separate addressed and structural families.
• Public core construction/selection/reconstruction preserves own capability identity, complete finite children, exact binary/empty keys, shared primitive state, and missing structure versus present refusal.
• Full-tree to AddressedWire bridges specify their exact UTF-8 image and refuse unmappable keys without normalization. Opaque remote access cannot be decomposed into a fabricated tree.
• Local and real WebSocket tests show direct, selected, reconstructed and forwarded behavior, replies, cancellation, ownership and delayed work across rebinds in Go/TS pairings.
• Binding/access teardown preserves borrowed child usability; no receiver attachment/closure authority is implied by structural selection.
• Independent bitwire cases run against exact public releases and a downstream tree consumer; reports separate structural, profile and carrier evidence.

Use core/go, core/ts and conformance component/two-letter language paths. No generic-service implementation, application-specific space mapping, or protocol redesign. Closure needs the accepted #29 disposition and released evidence, not merely the existing 14 structural cases.

Named structural consumers

bitsystem3 #11 owns space-to-tree mapping; bittree #53 owns its model/access transition. Their application mappings remain outside this runtime packet. The separately gated deixis-svc #2 design may consume these structural/profile guarantees, but its same-service/two-backend acceptance is not established by this library/carrier suite.

[jm9e]

Independent full-tree evidence against v0.2.0, and three deficiencies

bitwire PR #57 (commit d88db33) adds conformance/wiretree: 26 independently authored cases and a disposition of the 39 historical declared cases and 19 gaps (bitwire#29). It runs against the released artifacts, github.com/Bitspark/bitruntime v0.2.0 and @bitspark/bitruntime 0.2.0, in Go (with the race detector) and in TypeScript.

What v0.2.0 already satisfies. Through Compose/compose, Select/select, Send/send and AsAddressed/asAddressed, all 19 structural and bridge cases pass in both languages:

• own capability identity;
• exact empty, binary, slash and both-Unicode-spelling keys;
• complete children;
• missing versus a present node whose own refuses;
• both reconstruction directions and complete cuts;
• retained and reset state;
• refusal of duplicate keys, missing children and cycles;
• the exact UTF-8 bridge, refusing ill-formed segments before any primitive.

All 7 carrier cases also pass on the local pair and on WebSocket in both directions, using your pairs, peers, dispatcher, Forward, Mount and At. The historical addressed gap ledger in this repository keeps its meaning: Mount is child-only routing, not tree construction. bitwire#29 disposes those 19 entries.

The carrier results depend on two adapters the drivers write themselves. v0.2.0 has no public facility for either. These are the deficiencies for this packet.

1. No addressless Wire bound to an AddressedWire path

A tree whose own values live across a carrier needs, at every node:

const bind = (access: AddressedWire, path: Path): Wire => ({ send: m => access.send(path, m) });

Every consumer hand-writes this, including bitsystem3#11's browser trees.

Expected observations are bitwire's carrier cases:

• bind(a, p).send(m) admits exactly as a.send(p, m), with the message and return capability unchanged;
• the path is copied at binding;
• it grants no receive, close or structure.

The contract also requires the following, and the cases show it: a carrier path names a position, not a node. A near tree must bind each position, because addressed access cannot reveal that two far positions share one node.

2. No facility serves a WireTree on an endpoint while keeping captured cancellation

The obvious composition routes every delivery through asAddressed(currentTree). That retargets captured cancellation after the admitting node is replaced. Reproduction, using public v0.2.0 API only:

const [near, far] = pair();
const dispatcher = createDispatcher(far);
let tree = compose(handler('old'), []);
dispatcher.registerPrefix(['t'], { message: (path, m) => asAddressed(tree).send(path.slice(1), m) });
const original = { wire: { send() {} } };
near.send(['t'], { frame: { version: 1, kind: 'request', id: 'c:1', params: null }, return: original });
// … once delivered:
tree = compose(handler('new'), []);            // replace the node that admitted c:1
near.send(['t'], { frame: { version: 1, kind: 'cancel', id: 'c:1' }, return: original });
// observed: ["old:request","new:cancel"]    expected: the cancel reaches "old"

bitwire's carrier-cancel-across-replacement expects the cancel to reach the admitting node. It passes only with the lawful composition in the drivers (serve in conformance/runtime/{go,ts}):

• one exact dispatcher route per node whose keys are all UTF-8;
• each route bound to that node's own Wire;
• re-registration after the tree changes.

The dispatcher's captured traversal then keeps the cancel with the admitting node. The suite runs the retargeting version as a deliberately unlawful realization, and three cases reject it.

A production facility would own several things the drivers currently do by hand:

• the nonempty prefix, since bitwire/1 refuses a request at a peer root's empty path;
• what happens to non-UTF-8 keys: unreachable, never decoded or normalized;
• re-serving after a change.

In Go it also owns answering a refused request: Receiver.Message returns nothing, so the adapter must call core.Respond(m, nil, err), which yields internal.

3. A missing own Wire is accepted at construction (smaller)

core.Compose(nil, …) and compose(undefined, …) both construct a node. Sending there then gives ErrInvalidWire in Go and a TypeError in TypeScript. Decision 0012 says every node has an own capability. The generic Compose[T] cannot reject every zero value, but a WireTree constructor could refuse a missing Wire, as it refuses a missing child. bitwire has no case for this yet. Say if you want one.

Cross-links

• Consumer mapping: bitsystem3#11. It needs 1 and 2 for browser and child access.
• Contract questions stay with bitwire:
  • carrier refusal and closure: bitwire#54;
  • received context: bitwire#55;
  • lifecycle retirement: bitwire#20.

[jm9e]

Update: the bitwire suite this issue's deficiencies cite is merged as e8cc923 (bitwire#57, reviewed). It now has 27 cases, all green against v0.2.0 in Go and TypeScript. Two changes matter here.

• A far node's refusal is observed at the primitive itself.
• A deliberately retargeting server is required to fail carrier-cancel-across-replacement.

When public bind and serve facilities exist, the drivers will swap their test-only adapters for yours and pin that release. Deficiencies 1 to 3 above stand as written.

[jm9e]

Downstream consumer evidence from bitsystem3 #11 (released bitruntime v0.2.0 and bitwire v0.3.0, no overrides)

bitsystem3 now builds its spaces as WireTree values using Compose/compose under an application profile, bitsystem3.space-tree/1. It is in PRs Bitspark/bitsystem3#16 (server and Go) and Bitspark/bitsystem3#17 (browser).

• Server side: every operation's own Wire forwards the whole Message into a local pair at a fixed non-empty path, where a Dispatcher runs the handler.
• Client side: clients build their trees from complete snapshots, with own Wires sending on the connection.

What crossed which carrier in our tests:

Obligation	In-memory	Local pair	WebSocket (Go server)
Selection and enumeration, own/child identity, decompose/recompose, key copy (a law checker over app trees)	Go, TS	—	Go client, TS client (Playwright)
Own value invoked under a non-empty prefix; a refusing present node; a missing path	Go, TS	Go	Go client, TS client
Replies through selected or remounted nodes	Go, TS	Go	Go client, TS client
Capabilities dying with their connection	—	—	Go client, TS client

We found no runtime defect. Things application authors must handle themselves, all consistent with the docs:

• MissingPathError/ErrMissingPath is not a PublicError, so it crosses a peer as internal unless it is mapped. We map it to our own path_not_found.
• A peer's root refuses the empty path, so a tree's root own value is reachable only under a prefix.
• In TypeScript, Dispatcher.register is exact-match and prefixes need registerPrefix.

Our consultation flagged one point for this issue (bitsystem3 research 0002, R25): the v0.2.0 release notes mention trees alongside the local-pair and WebSocket suites. From that wording, it cannot be determined which structural obligation crossed which carrier. The per-case matrix this issue already lists (case, language, carrier, fixture, observation, pinned artifact) would settle it. bitsystem3 does not depend on it and is not blocked.