wire: coordinate protocol, carrier, evidence and independent runtime acceptance

[jm9e]

Current work packets — 2026-09-26

This issue owns bitwire's contract/conformance share of decisions 0007–0012. Production implementation remains in bitruntime. Current v0.3.0 provides addressless Wire, full WireTree, and AddressedWire carrier access; it does not include a redesigned received-context field.

Deliverable	Owner / closure evidence
Package/runtime independence	Delivered by PR38/PR44 and the published-package import check; preserve it.
Immutable bitwire/1 specification and hash manifest	#53
Carrier close/refusal/publication guarantees and bitwire-stream/1 vectors	#54
Interaction/profile ownership and received-context design	#55; future explicit native/profile version disposition, never retroactive v0.3.0 claims
Independent acceptance of released runtime	PR52, as specified below

Independent acceptance packet

Runtime v0.2.0 is published from PR9. PR52 was prepared against a candidate; its remaining work is:

• Pin actual public released Go and TypeScript artifacts, including checksum/version identity. No local replacements/private checkout builds.
• Add TypeScript drivers and run local pairs and real WebSockets in both roles in each applicable language/profile matrix.
• Keep independently authored expectations withheld from drivers; fail missing/extra/duplicate observations and deliberately unlawful implementations.
• Report contract, protocol, suite hash, implementation release, carriers and toolchains separately.
• Preserve historical addressed gap ledgers. Current structural-tree conformance and historical declared-access evidence are distinct; #29/runtime #15 own their eventual disposition.
• Link green exact-artifact evidence back to runtime #1 and bitsystem3 #7.

Use conformance/runtime/go and conformance/runtime/ts or the documented component-first two-letter layout. Published bitwire packages cannot depend on runtime. Candidate tests are useful but not a release gate substitute.

Ordering / closure

The existing-profile runtime release and bitsystem3 transport migration do not wait for every later contract redesign. The later contract children gate only implementations that consume their new guarantees. This issue closes after #53/#54/#55 and released independent acceptance have their own evidence/dispositions, without automatically closing runtime adoption.

Related: #47, #42, runtime #2, family index. The preserved earlier plan below includes superseded version wording and is historical only.

Historical issue record (preserved; current execution instructions are above)

Decision 0007: using Bitwire never requires Nightseam. Decision 0010 then decided where the pieces live. Bitwire keeps the contract, the protocol and carrier specifications, and conformance. A new public repository, bitruntime, implements them in Go and TypeScript. This issue now tracks Bitwire's share only. The implementation steps live in bitruntime.

Bitwire's steps

• Decision and independence check (PR docs: decide that using Bitwire never requires Nightseam. #38). Since PR docs: decide that Bitwire holds the contract and bitruntime implements it. #44, node scripts/check.mjs fails if any published package depends on or imports Nightseam or bitruntime.
• The protocol as bitwire/1.
  • Revision 1 is the behavior of the v0.6.0 baseline, published with a manifest of hashes of its specification files (decision 0008).
  • The conformance runner protocol (DRIVER.md), tables and scenarios move with it. Each implementation builds its own test drivers.
  • Wire-only vocabularies (the envelope, tunnels) are specified here; the identity exchange belongs to Bitlink.
• The carrier contract, from the draft:
  • one classification of closed errors;
  • close codes split into those that may be sent and those that may only be observed;
  • the framing format bitwire-stream/1 and its portable test vectors (decision 0009).
• Received-context evidence: an unforgeable context field delivered beside each message, changed in all eight languages (contract 0.3.0). It is designed together with bitruntime's engine hooks.
• Conformance against bitruntime. Bitwire's cases run against bitruntime as an external implementation, from a test-only module, as they do against Nightseam today.

Moved to bitruntime (bitruntime#1 is the first milestone)

• Go and TypeScript operators: selection, mounting, forwarding, declared composition, the invocation lifecycle, the in-process pair.
• Transports: the transport interface, the in-memory pipe, WebSocket, and bitwire-stream/1 over stdio, TCP and Unix sockets.
• The protocol engine, dispatch and request/response helpers, with public hooks for context, observation and tracing.
• The live-reference mechanism and tunnels, depending on stated capabilities rather than the peer.

The first migration gate is bitsystem3. It needs the path that hand-written adapters use: carriers, dispatch, helpers, selection and connection setup.

Acceptance for Bitwire's steps

• Expected observations are written from the specification, never recorded from an implementation.
• Every conformance report names the specification revision, the suite revision and the implementation version.
• Deliberately unlawful implementations check that the cases reject violations.

[jm9e]

Hold: don't start steps 2, 3, 5 or 7 in Bitwire yet. Research 0002 recommends keeping Bitwire the normative contract and conformance repository, and putting the Go and TypeScript implementations (operators, transports, protocol engine, invocation lifecycle, tunnels) in a separate runtime repository. That would supersede decision 0007's implementation home. Step 4 (the protocol specification and carrier contract) stays in Bitwire either way. This issue will be updated when the maintainer decides.

[jm9e]

Hold lifted. Decision 0010 (PR #44) settles the split. Bitwire's steps above can start. The implementation steps move to bitruntime once that repository exists.

[jm9e]

Carrier-contract findings from bitruntime's implementation

bitruntime has ported the path that hand-written adapters use from Nightseam
v0.6.0 (5cc9723): transports, pair, dispatch, the bitwire/1 engine and
WebSocket setup. The work is on the branch feat/runtime-transports
(bitruntime#1).

These findings bear on this issue's open carrier contract. In each case, what
bitruntime does is an implementation choice until this repository specifies
the rule.

1. What the sender of an over-limit frame observes. The draft says a frame
over the receiver's limit "is not delivered, and the connection ends with
1009".

• The receiver does send 1009.
• On TCP WebSocket, the sender can lose the close frame to the socket
  teardown and observe 1006 instead. coder/websocket also leaves the
  receiving socket half closed until it is ended explicitly.
• bitruntime ends it promptly. Its transport suite requires the sender to
  observe the end with 1009 or 1006, and the pipe gives 1009 on both sides.
• Suggestion: the contract promises the receiver's code and a prompt end
  for the sender. It should promise the sender's observed code only where the
  transport can carry it.

2. Observe-only codes are refused, not transmitted (R27).

• transports.Sendable rejects 1004, 1005, 1006, 1015 and anything outside
  1000–1014 and 3000–4999. Conn.Close with such a code returns
  ErrUnsendableCode and sends nothing.
• A peer asked to close with one aborts, which is what the far side would
  observe anyway.
• Suggestion: the contract names the sendable set and says that a
  non-sendable close is refused at the transport.

3. One closed classification (R26).

• Every ended carrier, operator and helper reports an error satisfying
  errors.Is(err, transports.ErrClosed) that keeps its cause (backpressure,
  a remote close, a context end).
• Forwarding answers such a refusal as the public code disconnected, never
  internal.
• Two v0.6.0 defects surfaced here:
  • a call through the peer's root that the peer's end cut off was answered
    cancelled, because its context derived from the peer's;
  • cancelling the reader before closing let a WebSocket peer's chosen code
    arrive as 1006.
• Both are fixed with tests. Neither changes a frame.

4. Research decision 4 (does a synchronous refusal prove nothing was
published?).

• bitruntime's own carriers mark every synchronous refusal as
  UnpublishedError.
• bitsystem3 depends on this: it retries a request that a closed pair
  refused, never one that pair admitted.
• Whether this becomes an obligation on every AddressedWire remains this
  repository's decision.

5. Research decision 5 (when a message becomes immutable). The pair, the
root and the call helper now copy a message and validate the copy (row 28).
v0.6.0's Go code validated first. TypeScript already copied first.

6. Research decision 6 (closing).

• When a local pair or a peer's root ends, it answers:
  • every refusal still queued, with that refusal (nightseam#722);
  • every admitted, unanswered request, with disconnected.
• There is no graceful drain.
• bitsystem3's overload test shows the difference:
  • under v0.6.0, 3–56 of 512 refused requests wait out their deadline, on
    every run;
  • under bitruntime, none do.
• A full root queue still ends the connection, as bitwire/1 requires.
• Proposal: "a closing carrier answers every request it admitted or queued"
  becomes an independent case once decision 6 is taken.

7. bitwire/1 is unchanged.

• A raw recorder replays fixed envelopes. The bitruntime Go server's
  transcript is byte-identical to Nightseam v0.6.0 Go's, masking only random
  span identifiers. The script covers:
  • responses, errors with data and events;
  • a reverse request with a child trace;
  • cancellation;
  • a raw non-path method;
  • 4011 on a reserved meta key.
• bitruntime Go interoperates with Nightseam v0.6.0 Go and TypeScript in
  both roles (scripts/interop.mjs, nine pairings).
• These tables and scenarios are Nightseam's v0.6.0 artifacts, vendored with
  their provenance. This issue's step 4 remains the place to publish
  bitwire/1 and its manifest.

8. Received context.

• Go keeps it private to bitruntime through an internal package, which
  0.3.0 allows.
• In TypeScript, true privacy across components needs a single package with
  subpath exports. Separately published packages could share it only through
  an exported, and so forgeable, API.
• That tension goes away when the evidence field arrives in a later contract
  revision.

Conformance against bitruntime is draft PR #52. It runs this repository's
existing cases, unedited, against bitruntime's Go candidate 9c93bb7:

Family	Result
Lifecycle	5/5
Composition groups	6/6 on each of three carriers
Declared, reference realization	39/39 on each carrier
Declared, production Mount	20 conform; the other 19 are exactly the gaps Nightseam v0.6.0 records
Trees	14/14

The draft moves to the release pin before merge, and TypeScript drivers follow
bitruntime's TypeScript package.

---

Posted by Claude Code (bitruntime session) on the maintainer's instruction to
report the implementation's findings to Bitwire.