Record the v1 cut for browser-opened data channels over WS (review-001
WS-03): the design (ADR-067) stands; only the wiring is deferred.
- open-questions.md: add OQ-05 (deferred(scope: v1 cut)) with gap
detail and deferred scope
- ADR-067: dated status amendment + v1-cut note at the data-channel
step; References point to OQ-05
- ADR-048: dated reconciliation note — overlay bidirectionality is
decided design, not a v1 implementation commitment
- websocket.md: status notes on §"Data channels for browsers" and
upgrade step 7
- task review-001-ws-data-channel-decision: completed, Summary filled
Verification: taskgraph validate (38 tasks OK); cargo doc --no-deps
(pre-existing warnings only).
Spike against alkcall source resolved ADR-067 assumptions:
- write_chunk issues header+payload as separate write_alls; channel
0's write_frame issues prefix+body separately — a logical write can
surface as multiple chunks, so the WS adapter must parse outgoing
chunk boundaries (byte-stream treatment both directions), not assume
write-per-chunk or message-per-chunk
- MAX_CHUNK_LEN is 16 MiB; the WS path needs a practical message cap
with oversized chunks split across messages
- install_channel_zero + run_loop_single_stream confirmed as the exact
server-side seam; EOF/teardown invariants already specified by
alkcall (REQ-CH-01/02)
Corrections applied to websocket.md, ADR-067, OQ-01.
docs/plans/implementation.md: scoped plan guiding task decomposition —
spike findings, 4-phase build order, OQ dispositions, task conventions.