docs: propose decision 0011, Bitwire as Deixis over Ends.

[jm9e]

Superseded on 2026-09-26 by accepted decision 0012, delivered in PR #50. The current names are addressless Wire, full WireTree = DeixisNode<Wire>, and the explicitly named AddressedWire carrier bridge, symmetric with Data and DataTree = DeixisNode<Data>. This draft was not accepted or merged. The historical proposal below does not describe the current contract; unrelated open message/profile and lifecycle questions remain separately tracked in issue #42.

---

Draft: proposed, not accepted. This is the design deliverable for #42. It gets reviewed here with deixis#49, bitstore-svc#13 and deixis-svc#1, and tested by bitruntime's experiments, before it is accepted.

• Naming (decided): Bitwire = Deixis[End]. End is the addressless primitive; bitwire.Wire stays the addressed interface.
• Three layers: transport (frames, decision 0009), End (addressless send), and Wire (addressed, Deixis over Ends). The bitwire/1 protocol is the vocabulary of the messages Ends carry. Its path-in-method field is addressing serialized for the crossing.
• Two laws define every Wire, opaque ones included: origin(w).send(x) = w.send([], x) and w.send(p, x) ≃ origin(at(w, p)).send(x). origin is derived, so it keeps the view's guards.
• Declared composites type their origin as End. Leaves become exact by construction, and children may be opaque Wires.
• Transition: Bitwire 0.3.0 adds End in all eight languages, and everything else is unchanged. bitwire/1 stays byte for byte. Consumers stay source-compatible, except code that builds composites with a Wire-typed origin.
• Deixis dependency: none in Bitwire. Deixis is private, so public repositories cannot depend on it yet.
• Open for the maintainer: End's message type; the shape of return capabilities; End-level receiving; making Deixis public; research 0001's decisions 4–6.