Meet slice 4 — the record

Branch slice/4-chat, 3420396..HEAD (this commit; started on main 3420396). §6 below is the Codex fix wave, which landed after the six tasks and moved the head six times more — the range stated here is the whole branch, record included, rather than the six tasks alone. Spec: docs/superpowers/specs/2026-09-07-meet-design.md, revision 9 (§15.15 and §15.16 carry this slice's two wire/behaviour rulings).

Slice 4 built chat and screen share: hub.Fanout, /signal's chat and share dispatch, the chat panel as estilo's first adoptable component, room.js's broadcast lane and screen-share transceiver, and the browser gate's chat, share and mutualshare scenarios — six tasks, each with its own review and fix rounds, kept in .superpowers/sdd/2026-09-10-meet-slice-4-chat/progress.md and the task-N-report.md files. Like slice 2's and slice 3's, that ledger is gitignored and does not survive the worktree; this file is its substance.

---

1. Rulings and decisions

From the ledger's pre-flight scan and the tasks that followed it:

• The fan-out excludes the sender; the panel echoes locally on acceptance. Ruling. Cost if wrong: a duplicate line in the sender's own panel. Written into spec §15.15.
• Chat above 2048 bytes is 413 too-large; every other malformed shape — an empty text, an extra key, a non-bool on, a to on either type — is 400 bad-request. Ruling. Cost if wrong: none observable beyond which sentence the client's status line shows. Written into spec §15.15.
• share carries only {on}; the tile's label is the sender's name from the roster and the envelope, never a track label. One sharer at a time is not enforced — §5.4 already says so. Written into spec §15.15.
• The size and UTF-8 checks run on the raw wire bytes, capped at 2048 + 32, not on the decoded field. Found the hard way: Task 2's first pass measured len(*p.Text) after decoding, which a duplicated "text" key (JSON keeps only the last) or a run of \uXXXX escapes (roughly a sixth of its raw size once decoded) both defeat while the raw bytes — exactly what Fanout forwards unread — stay large. Fixed in Task 2's fix round: len(raw) > maxChatBytes+32 before decoding, utf8.Valid(raw) on the same raw bytes rather than utf8.ValidString on the decoded string (which a scratch test proved is always valid, since encoding/json repairs an invalid byte with U+FFFD on the way into a Go string — checking the decoded value would let a genuinely invalid byte through while reporting the payload clean). Written into spec §15.15. Amended by the fix wave (§6): the raw cap and utf8.Valid still run first and still judge the incoming bytes, but those bytes are no longer what Fanout forwards — the payload is re-encoded from the value that was validated, and §4.4's 2 KB is now counted on the escaped text, which is what the wire actually carries and what the panel can count too.
• The gate drives getDisplayMedia with --auto-accept-this-tab-capture alone. Settled by a throwaway probe before a line of Task 5's scenario was written: the existing --use-fake-ui-for-media-stream flags already accept display capture in this Chromium over http://127.0.0.1 (a data: URL is not a secure context and fails for an unrelated reason), so the brief's fallback flag, --auto-select-desktop-capture-source="Entire screen", was never needed. Kept anyway, belt and braces, because it is the documented flag for the job and costs nothing.
• The polite side of a negotiation waits 300 ms before offering, once per negotiation (POLITE_YIELD). Found in Task 4's second fix round, after the prescribed fix (releasing an unassociated share transceiver before a rollback) was measured twice and shown not to touch the actual cause. Chromium rebuilds every send and receive stream on a connection — not only the m-line a rollback removes — when it rolls back an offer that added an m-line, which is exactly what two peers sharing a screen at the same instant does to the polite side; the camera's sender comes back on the same SSRC having encoded nothing, ever. An offer answered from stable needs no rollback, which is what the yield buys. Measured at each step: yield on the share path alone, 1 failure in 3; yield on every negotiation, 1 failure in 4; bounded to once per negotiation, 0 in 6, then 0 in 8 more, then 30/30 twice in the full gate. Written into spec §15.16. Amended by the fix wave (§6): "once per negotiation" was really once per connection until an offer of this side's own went out, which an earlier glare could spend for good. It is now a generation the yield checks on waking, one attempt in flight at a time, and an allowance of two handed back by any exchange this side answers — and a camera that was rebuilt anyway is now detected and repaired.
• regainShare and shareTxLost, added in Task 4's first fix round to put a screen back after a rollback, were both no-ops where they stood — found and removed in the second round. regainShare called addShareTo, which the same round had just taught to refuse anything but a stable connection, and onOffer at that point is have-remote-offer; it could never add anything. shareTxLost asked whether the transceiver was stopped or had lost the local track, which a rollback does neither — it un-associates a transceiver addTransceiver created, and the display track stays on its sender. The test that "discriminated" for the first round only proved a stub was called in the right order, never that calling it did anything. Not written into the spec: an implementation dead end, not a decision the spec has an opinion about — recorded here so the false path is not walked twice.
• classifyTrack's four-signal order — the receiving transceiver's own direction, then the camera's mid, then the camera's stream id, then the peer's other-media stream id, and only then a tiebreaker — is an implementation decision the spec has no opinion about (§5.4 says a peer's screen becomes a second tile; it does not say how a mesh peer tells a screen from a camera on the wire). Found necessary in Task 4's first fix round once the reviewer showed the blind spot the first draft's report had wrongly called unreachable: a peer with no camera (the audio-only rung of startLocal's fallback ladder) really can have its screen be the first video track its peers ever see.
• The one hole the classifier still has is documented, not closed. A peer with no camera and no microphone has sent nothing before its screen — no camera mid, no camera stream, no peer stream — and if the receiving tab also has no camera, direction says nothing either. Classification then rests entirely on the share message, which §4.3 delivers or reports as failed. Decided as acceptable rather than closed: see §3 below.
• required is dropped from the chat textarea rather than routing Enter through form.requestSubmit(). Task 3's fix round: this form never reaches a server, so required buys exactly one thing — the browser's own validation-bubble sentence on an empty click of Send, worded and toned by the browser rather than this app's copy list, and untranslatable by it. Both submit paths (Send, Enter) now return silently on an empty or whitespace-only box, which agrees with every other product's chat box and adds no string at all.

---

2. Per-task review dispositions

| Task | Built | Review | Fix rounds | Final | |---|---|---|---|---| | 1 — hub.Fanout | Fanout, ErrNotFanout; three tests covering delivery-and-exclusion, sender authority, and a standing loss mid-fanout | Needs fixes, tests only: the type guard was proven against one targeted type rather than as an allowlist; the envelope-rebuild test forged fields that were already zero rather than a fully forged input; §6's "never replayed" was proven only for an attached recipient, never through a detach-and-resume | Round 1 (fa8b40d): all three fixed and mutation-verified — a denylist-shaped guard, a patch-in-place bug, and a queue-on-detach bug were each written, run against the new tests, and shown to fail exactly the test meant to catch it | Complete. | | 2 — /signal dispatches chat/share | validateFanout, fanoutError, maxChatBytes, the dispatch arm; three new tests plus the captured-log test extended to an accepted and an oversize chat | Needs fixes: HIGH — the byte cap and UTF-8 check ran on decoded fields, not the raw bytes Fanout forwards, letting a duplicated key or an escape run through oversized; MEDIUM — the oversize refusal's log line was never proven text-free; LOW — the waiting-guest silence test had no positive control; LOW — refusal bodies (not just status codes) untested; LOW — a doc-comment gap on signalJSON's normalisation | Round 1 (012fb78): all five fixed. The HIGH fix reverted and re-tested against the pre-fix code: four of five new subtests failed with 200 instead of 413/400, confirming the bug was real | Complete. | | 3 — the chat panel | templates/partials/chat.html, static/chat.js/chat.css, render.go's partial parsing, mount(root, {name, send}) → {append, setEnabled, clear} | Needs fixes, small: no test that an app partial cannot shadow a vendored ui partial name; aria-describedby unasserted; the echo fired on any truthy send result, not strictly true; an edited draft did not clear "Could not send"; the log did not compensate scroll position when trimming for a reader scrolled up; script load order (chat.js before room.js) unasserted; inconsistent empty-send behaviour between Enter and the button; no title attribute on the timestamp; MAX_LINES/MAX_BYTES retyped rather than pinned from source; no mount() test against a fake DOM | Round 1 (43d381c): all nine items fixed; chat.test.mjs grew from 11 to 28 tests, most driven by constants read out of the shipped source rather than retyped. room.html carried no diff this round, so make browser was not re-run, per the coordinator's own condition | Complete. | | 4 — room.js: broadcast lane, screen share | The broadcast lane (chat), one sendonly transceiver per connection for share, classifyTrack, the share tile, the Share button | Needs fixes: MEDIUM — a second click while the getDisplayMedia picker was open took an un-stopped second capture; MEDIUM — a broadcast message queued during a 404 recovery that ended the session was never answered; MEDIUM — the classifier's blind spot was reachable through the audio-only fallback rung, not only theoretical; LOW-MEDIUM — mutual sharing could collide on m-line matching; LOW — a no-op mount (missing DOM hooks) still un-hid the panel; LOW — the getStats frame fallback could credit the wrong tile with two video streams; LOW — a 404 with the thirty-second budget already spent left no time to diagnose | Round 1 (a7c91d3): nine of ten items fixed outright; the mutual-share item shipped regainShare/shareTxLost, later shown to be no-ops (see §1). Re-review after round 1: nine of ten closed, item 4 (mutual sharing) not — the two functions could not do what the report claimed, the stable guard on addShareTo was untested, and the report overclaimed a discriminating test that only proved a stub was called. | Round 2 (8797ea9): root cause found (Chromium rebuilds every stream on a rollback of an offer that added an m-line); fix is POLITE_YIELD, 300 ms, once per negotiation; regainShare/shareTxLost removed; negotiate() extracted as a named, catchable function; 16 new node tests. Re-review after round 2: Clean — eight items carried to the fix wave rather than fixed on this branch; see §3. | | 5 — the browser gate: chat, share | The two scenarios; state().chat/sharing/shares; diagnose()'s per-connection reading; the --auto-accept-this-tab-capture launch flag | Needs fixes, minor: the guest-silence checks needed a positive control (guarded on counted); no-echo and no-duplicate needed pinning with exact counts, not >=; both members named "paul" made a name assertion untestable; shareCaption untested outside the browser; chatLog read an id rather than the data-attribute contract; diagnose() said nothing about the media itself (inbound-rtp, outbound-rtp, displaySurface); not every run's log was kept; the reported check tallies were wrong | Round 1 (a11ad9a): all items fixed; member B renamed to bea@rslw.com; shareCaption lifted into room-share.test.mjs; diagnose() gained inbound/outbound/displaySurface, later also mids and currentDirection on transceiver strings. The round also added mutualshare, written to decide the mutual-sharing question rather than assume it — it found the real defect and was shipped skipped, with the exact failure and every check that still passed recorded | Un-skipped as part of Task 4's second fix round (8797ea9), once the client-side cause was fixed; no assertion in the scenario was touched. Complete; the gate is 30 scenarios. | | 6 — this record and spec §15.15/§15.16 | Documentation only | — | — | This commit. |

---

3. Carried items, and where they go

• The no-media sharer hole in the classifier is documented, not closed. A peer that joined with no camera and no microphone has sent nothing before its screen — no camera mid, no camera stream, no peer stream to compare against — and if the receiving tab also has no camera, the transceiver-direction signal says nothing either. Classification then rests entirely on the share message. Destination: accepted as a known limitation, backstopped by §4.3's own delivery guarantee on share — not a bug this slice owes a fix for, and named in classifyTrack's own comment so the next reader finds it there first.
• dropShare and shareCaption, now pinned. Task 5's first report flagged both as untested by anything but the browser gate, since that task cannot mutate room.js while a reviewer reads it concurrently. shareCaption was lifted into room-share.test.mjs in Task 5's fix round (the caption text, that it carries no ASCII apostrophe, and that a name with a space goes in whole); dropShare was pinned in Task 4's second fix round (clears the label, the media and the mid; twice is the same as once; redraws the grid once, not twice; a screen announced but never arrived is still dropped). Destination: done, both closed on the branch.
• diagnose() reading inbound-rtp. Carried from Task 5's first report (mutation testing against the client was impossible, and its diagnose() said nothing about the media itself) into Task 5's fix round: per connection, inbound (ssrc, framesReceived, framesDecoded, framesDropped, pliCount, freezeCount, the track's own muted) and displaySurface, then outbound and mid-plus-direction transceiver strings added while diagnosing mutualshare itself. Destination: done — this reading is exactly what let Task 4's second fix round read the root cause off two connections' own stats rather than guess at it.
• The 300 ms polite-yield residual. Task 4's second fix round closed the mutual-share defect with a 300 ms wait, not a proof: a pair whose signalling round trip exceeds 300 ms can still collide, and on that pair the rollback still costs the polite side its camera. Nothing detects or repairs a camera that has already been rebuilt. Destination: watched, not fixed further this slice — recorded in spec §15.16 as the first thing to check if a real deployment ever reports a camera stopping after two people share at once, and the second thing to check is whether Chromium has fixed the rollback itself.
• The make browser flake rate and its logs. Across this slice's runs: Task 4's first pass, 26/27 then 27/27; Task 4's first fix round, 28/29 then 29/29; Task 5's first pass, three of four runs each lost one different scenario (senddeadline, share, icefail) to the stall before a clean 29/29; Task 5's fix round exposed the real mutualshare defect (not a flake — 3 failures in 5, always the same camera signature) and shipped it skipped, then a clean 29/1-skip; Task 4's second fix round ran clean, 30/30 twice, 447 s each. Roughly half of this slice's make browser runs lost exactly one scenario to the environment's own media stall, and every stalled scenario passed alone immediately afterward. Destination: unchanged from slice 3 — a red make browser run is worth a second run before it is worth debugging. Every run's log this slice was kept under $TMPDIR (task5-browser-run3.log … task5-fix1-three-scenarios.log, task5-mutualshare-try*.log), not committed; §5 below gives the stall's signature.
• What the Task 4 re-review named, landing clean itself. The re-review of fix round 2 (8797ea9) returned Clean — nothing on the branch itself needs another round — and carried eight items to the fix wave rather than to this branch, each to be measured against mutualshare when it is picked up: (1) entry.yielded is cleared only by this side's own successful offer, so a lost yield whose remote exchange happens to satisfy the same need leaves the polite side unprotected next time — clear it on any stable return, not only this side's own, bounded by a counter so it still cannot become a habit; (2) a detect-and-repair path for a camera already rebuilt — outbound-rtp framesEncoded static on the camera's mid while the track is live and the m-line is sending → replaceTrack(null) then replaceTrack(track), followed by requestReset; (3) evaluate reserving the screen's m-line at createPC itself (an inactive transceiver from the start; starting a share becomes a replaceTrack plus a direction change) so that starting a share never renegotiates a new m-line into existence at all; (4) settle whether the true trigger is "a rollback that added an m-line" specifically or "any rollback once media is already flowing" — two simultaneous ICE restarts with no share involved is the case that would tell them apart; (5) file the defect against Chromium itself, with the stats trace this slice captured; (6) widen the ordinary negotiation scenarios to assert frames keep moving afterwards, not only at connection; (7) two peers stopping a share at the same instant is exactly as ungated as two starting one, and untested; (8) pin POLITE_YIELD from the shipped source rather than retype it, and correct one claim already written down: the report's "the yield ends early" reads as a race that resolves on its own, when the code is an unconditional sleep gated by a state check taken after it — accurate for what ships, but the sentence describing it overstates how the two interleave. Destination: the fix wave, alongside a reviewer's own draft of a further spec note for §5.1 on the yield, which this record does not reproduce — read it in the ledger (progress.md) alongside the whole-branch review's own findings and its handoffs for the Codex round and for slices 5 and 6.
• Codex round 1, launched on this branch after this ledger entry. codex exec was launched against 8797ea9 as this record was being written; nothing from it had landed by the time this commit was made. Destination: its own entry in this file (or the next slice's), the way slice 3's Codex rounds were appended to that slice's own record after the fact — not fabricated here ahead of the result.

---

4. Deploying this slice

No schema change. Nothing in this slice touches models.go, migrations.go or migrations/ — chat and share are both delivered messages, never rows (git diff 3420396..8797ea9 -- internal/calls/migrations internal/calls/models.go is empty). Deploying this slice is an ordinary rolling deploy with no migration step to sequence around it.

Every deploy still drops every live call, exactly as slice 2's record already states (spec §15.11 — the hub is per process and dies with it) and slice 3's did not change: this slice adds nothing to the hub's own durability. A chat message in flight at deploy time is not queued or recovered; it is simply not delivered, the same as an offer would be. Members rejoin automatically; guests go back to waiting.

Chat is not stored, on this instance or any other: §6's "not stored, not replayed" holds all the way down to Fanout, which delivers to an attached subscriber or not at all. There is nothing in a database backup, a log line, or a crash dump that a deploy could lose that chat did not already lack the moment it was sent — the property a deploy dropping a call would otherwise threaten does not apply here, because there was never anything held to drop.

No test on this branch touches a real deployment window; the gates below prove the wire and the browser behaviour against fixtures and a local pair of Chromium contexts, the same shape slice 2 and slice 3 used.

---

5. The gates, and how to run them

The tallies below are the six tasks'. The fix wave's own are in §6 and in codex-wave-report.md: 194 node tests; 31 browser scenarios, 30 passing and laterolls skipped, run twice clean on the final head at 457 s and 455 s with no scenario lost to the environment stall on either; and a make browser timeout raised to 20 minutes, which the thirty-first scenario and four more media windows made necessary.

| Gate | Command | Notes | |---|---|---| | The one gate | CGO_ENABLED=0 make ci | vet, gofmt, tests, migration check — unchanged from slice 3. | | Race | CGO_ENABLED=1 go test -race ./internal/... | Run through this slice's fix rounds; green throughout. | | Node | node --test test/browser/{negotiation,chat,room-share,room-lane}.test.mjs | 164 tests by the branch head, 0 failing; every assertion added this slice was watched failing against a deliberately broken source first, except Task 5's — a reviewer reads room.js concurrently through that task, so its evidence is the runs themselves: three name assertions failed against the wrong expected value before passing against the right one, and a media stall failed exactly the frame-counting checks and none of the message-driven ones. | | Browser | make browser | 30 scenarios, three of them (chat, share, mutualshare) new this slice. Needs the sandbox off — inside the Claude Code bash sandbox Chromium gathers zero ICE candidates and getDisplayMedia produces a source with nothing crossing the connection, as slice 2's and slice 3's records already note. getDisplayMedia in headless Chromium additionally needs --auto-accept-this-tab-capture; --use-fake-ui-for-media-stream covers getUserMedia only. The run takes about 7.5 minutes — 447 s measured twice, clean, in Task 4's second fix round, against 423-424 s for the 29-30 scenarios before it; the two new message-driven scenarios (chat, share) together cost only about 5.4 s of that, since both are written entirely on until/stayed deadlines and neither sleeps. |

The one-scenario media stall, and its signature. Roughly half of this slice's make browser runs lost exactly one scenario — a different one each time, never the same twice in a row — to the environment's own known symptom, unrelated to anything this slice built (the Makefile's own comment above browser: names it, and slice 3's record already caught it against the ICE scenarios). The signature, quoted from one losing run: connection: "connected", ice: "connected", both tracks reporting "live", transceivers: ["sendrecv:audio","sendrecv:video"] — and frames: {}. The transport is up, negotiation is done, and no pixels ever move; every stalled scenario this slice hit passed alone, immediately, on a second try. This is not the stale-roster defect slice 3 fixed (whose signature was peers: []) and it is not the mutualshare defect this slice fixed (whose signature was two live video streams with one encoding zero frames) — it is the environment stall both of those records already name, reached by a third scenario each time.

make browser is still deliberately outside make ci, for the reason slice 2's record already gives. As with slice 3's residual flake, a red run here is worth a second run before it is worth debugging.

---

6. Codex round 1, and the fix wave

codex exec was launched against 8797ea9 while §2's last task was being written, and the whole-branch review of 26c022b ran alongside it. Between them they found eleven things; six were Codex's (S4-1 to S4-6), five were the review's (W4-1, W4-3 to W4-7). All eleven are closed on this branch, in six commits, each with its new tests seen failing first.

| Finding | Disposition | Commit | Test | |---|---|---|---| | S4-1 (P1) — encoding/json matches object keys to struct fields case-insensitively, and DisallowUnknownFields does not change that: {"text":"<2049 a>","Text":"x"} is 2071 raw bytes, decodes to the last match — a one-byte text — and was forwarded raw, so every recipient read the lowercase key and got 2049 bytes through a 2048-byte cap | Fixed. Keys are judged byte-exactly by exactKey, a token walk that insists on one member spelled exactly and appearing exactly once — deliberately not a map[string]json.RawMessage, which collapses a duplicate and cannot tell {"text":"a","text":"b"} from {"text":"b"} | 4bbadf3 | TestChatKeysAreExactCaseSensitiveAndUnique, ten cases; six of them returned 200 before the fix | | S4-2 (P1) — writeEvent's json.Marshal HTML-escapes <, > and & inside a json.RawMessage, so a validated 2059-byte payload of literal < left the process at 12,381 bytes — the invariant validateFanout's whole doc comment rests on, broken on the way out | Fixed at both ends: validateFanout returns the payload re-encoded from the value it validated (SetEscapeHTML(false)), and writeEvent uses an encoder with the same setting. SSE data is not HTML, and the property the escaping never bought — that a payload cannot end its own frame — comes from JSON's own \n escape | 4bbadf3 | TestChatDoesNotExpandOnTheWire, TestChatDeliversTheCanonicalValidatedPayload, TestChatCannotForgeASecondSSEFrame | | S4-3 (P2) — the textarea stays editable during a send, so input.value = '' on acceptance erased a draft typed while the earlier message was in flight | Fixed with a draft revision, bumped by every edit, captured by the submit, checked on acceptance. Clearing the box in code is not an edit, so an untouched box still empties | a3a722f | three tests in chat.test.mjs; the first failed '' !== 'second draft' | | S4-4 (P2) — a pending polite yield survived the negotiation it belonged to (a state check cannot tell uninterrupted stability from an exchange that came and went), and negotiate did not stop a second invocation while the first slept | Fixed with three per-connection parts: a negotiation generation the yield captures and re-checks, one attempt in flight at a time, and yields — a counter in place of the boolean, handed back one at a time by answeredExchange. That last also closes the Task 4 re-review's item 1 and W4-4: the allowance is no longer a budget one earlier glare can spend for good | 41deb52 | five tests in room-lane.test.mjs, three of them mutation-verified against the shipped code | | S4-5 (P2) — no recovery for a camera whose encoder was already rebuilt; the trigger survives POLITEYIELD through a slow round trip, a 429 retry or a slow offer | Fixed. pollFrames runs in every browser now, not only where rVFC is missing, and reads outbound-rtp too: two polls with no new framesEncoded on a sending m-line with a live track is replaceTrack(null)/replaceTrack(track); two more is requestReset; after that it stops asking. Closes the re-review's item 2 | 41deb52 | eight tests in room-lane.test.mjs over a fake stats sequence, mutation-verified | | S4-6 (P2) — mutualshare's later rounds read a counter dropShare deliberately preserves, so they could pass on round one's frames; every camera check compared against a pre-gesture snapshot, which frames delivered before a rollback stall satisfy | Fixed with frameGrowth: read the counter, then wait for it to rise. Every screen and camera assertion in share and mutualshare is rebuilt on it, after each transition settles and again through the observation window | d8316e8 | the gate itself — and it earned its keep immediately (below) | | W4-1 (MEDIUM) — the panel capped 2048 UTF-8 bytes of the text, the server 2080 raw JSON bytes of the payload; between them sat a draft the panel called legal and the server refused, needing only 23 quotes or newlines. W4-2 falls with it: the "413: show beside the composer, never retry" line in task-4-handoffs.md was unimplementable through a boolean send, and is now unreachable | Fixed. One rule on both sides: the JSON-escaped length of the text, ≤ 2048 bytes — exactly what the canonical payload puts on the wire. The raw cap stays as the outer guard | 6f1be79 | TestChatCapCountsTheEscapedText (a quote, a newline and a backslash at and past the boundary) and chat.test.mjs's counter test | | W4-3 (MEDIUM) — `POLITEYIELD set to 0 left all 164 node tests green: the suite injected 250 of its own | Fixed. Every constant these tests assert against is read out of the source by pin(), and one test asserts the shipped values themselves — §15.16's 300 ms among them | 41deb52 | the numbers these tests assert against are the ones room.js ships | | **W4-5 (LOW)** — the constant's comment claimed "the yield ends early because the remote offer has arrived"; the sleep is unconditional and the check is state-based | Fixed: the comment says what the code does | 41deb52 | — | | **W4-6 (LOW)** — this record named 3420396..8797ea9, one commit short of its own | Fixed at the top of this file | this commit | — | | **W4-7 (LOW)** — §13 attached "no chat while waiting" to the guest scenario; it lives in chat`, with a positive control | Fixed in the spec's own §13 sentence, which now also names the control | this commit | — |

The gate found a defect the node tests could not. The first run of S4-6's fresh-baseline checks failed mutualshare round 1: the polite side's screen announced, captioned, and never arriving — an unassociated sendonly transceiver three rounds later and one inbound stream where there should have been two. S4-4's serializer had done it. The polite side adds its screen, sleeps in its yield, and answers the other side's offer while asleep; that exchange fires negotiationneeded for the polite side's own screen, which the serializer dropped because an attempt was in flight, and then the attempt woke, saw the generation had moved, and abandoned its offer. Nobody was left to offer the screen. Fixed in f982bdf: an ask that arrives mid-attempt is remembered on the connection and an attempt that abandons its offer goes round again for it, bounded by NEGOTIATE_ROUNDS. Two node tests, the first mutation-verified. Worth recording as a shape, not just an incident: the counter-based checks the old gate could not make are what made the client defect visible at all, which is the same lesson mutualshare itself taught in Task 5.

And then it found a second one, in the counter itself (3ecebb6, 2eadfd2). laterolls reported a camera that had stopped arriving on a tile that was playing perfectly — readyState 4, not paused, its clock advancing, 453 frames decoded and rising. What had stopped was watchFrames. Setting srcObject resets a media element and discards its pending requestVideoFrameCallback, and the chain was keyed on a WeakSet of elements, so a tile handed new media was refused a new chain and its count stood still for the rest of the call — which every frames assertion in the gate, and state().frames itself, reads as dead media. Keying on the stream was not enough either, and the gate said so on the next run: Chromium hands a rebuilt camera back inside the same MediaStream on a new track. It is keyed on tile, stream and track now, with a backstop for whatever else can drop a callback — a chain that has counted nothing for two seconds while the element's own clock moved on is re-armed, and pollFrames asks once a second, so a lost callback costs a second rather than a call. Eight tests, two mutation-verified. The counter the whole browser gate stands on could die quietly, and nothing but a real browser was ever going to say so.

And then a third, which was not the counter at all (fee4eb4). With the counter repaired, laterolls still failed on the same tile — and this time the count was telling the truth. The polite side's tile for the other camera sat at currentTime 0.1 for the rest of the scenario, readyState 4 and not paused, on a connection that was stable, connected, and decoding four hundred inbound frames nobody could see. The element was rendering a track that had ended. This is the receiving half of the same rollback damage §15.16 describes: Chromium rebuilds receive streams too, so the far side's camera arrives again as a new track — sometimes with no stream of its own, sometimes inside the very stream that still holds the old, ended one — and onRemoteTrack added the new one and left the old one in place, where a media element goes on rendering it. adoptTrack takes an ended track of its kind out before putting the new one in, and tile() now follows the stream's video track as well as the stream object. Four tests, mutation-verified.

Three defects, then, and the shape they share is worth naming: every one of them was invisible to the whole node suite and visible in the first browser run that asked the right question. The right question in each case was "is this media moving now", asked from a baseline taken now — which is exactly what S4-6 was about.

A thirty-first scenario, laterolls. §15.16's residual said a pair whose signalling round trip exceeds 300 ms still collides, and that nothing detected or repaired the camera afterwards. Half of that is now fixed (S4-5) and the other half is now forced rather than waited for: laterolls holds one context's own offer POSTs for four times the yield, so the collision is late by construction, and then asserts the camera is encoding again inside the repair budget. It asserts the recovery and never the failure — a Chromium that no longer rebuilds the streams passes it exactly as a repaired one does — and records whether the stall happened as a line rather than a check.

Said plainly: the delay is forced, the camera loss is not, and the scenario ships skipped. The delay is real — the scenario proves an offer was held (1 held). The encoder loss §15.16 describes did not reproduce: every run prints "the polite side's camera never stalled through the late offer", so what the run exercises is the late collision rather than the repair, and the repair itself is gated by the node tests over a fake stats sequence. A scenario that could only pass by breaking first would fail whenever the browser improves, which is why it asserts recovery and never failure.

What it does reproduce, deterministically, is one step further in than anything this wave fixed: after the late collision the receiving tile stops rendering. The connection is stable and connected, all four transceivers are right, every track is live, both inbound video streams decode (452 and 446 frames, unmuted, one PLI each), the far side's outbound camera rises throughout, and the screen tile plays perfectly — while the camera tile sits at readyState 4, not paused, currentTime 1.5 s, for the thirty seconds the check waits. Media arrives, the decoder decodes it, the element renders none of it. No other scenario reproduces it, and mutualshare renegotiates the same connection six times over with both cameras rendering throughout, which puts it closer to the environment's own media stall (§5) than to anything in room.js. Destination: laterolls is in skipped with the exact failure and the first two things to check — whether the receiving track for that m-line is a new track object that never reached onRemoteTrack, and whether startPlaying needs to re-play an element whose media was rebuilt under it — on the same terms mutualshare was shipped skipped in Task 5.

What the fix wave did not take on. The Task 4 re-review's items 3 to 7 stand where §3 left them: reserving the screen m-line at createPC (the fix that removes the trigger rather than racing it), settling whether the trigger is "a rollback that added an m-line" or "any rollback once media flows", filing the Chromium bug, widening the ordinary negotiation scenarios to assert frames afterwards, and two peers stopping at once. Item 3 is still the real fix and still wants its own task; what changed is that the failure it prevents is now detected and repaired when it happens, so it is an improvement rather than a gap.

One ordering worth writing down, from the whole-branch review's §3: leave() and terminal() both set state.stopped before calling stopSharing(), so the share {on:false} those paths trigger short-circuits in broadcast and no POST goes out after the leave. That is the right order, it is not obvious from reading stopSharing alone, and no test would notice if a later edit inverted it.

---

7. Codex round 2

Judged at 55f5681. S4-1, S4-2 and S4-3 closed; S4-4, S4-5 and S4-6 half-closed, each with the half that was missing named; five new findings. All of them are closed on this branch, and the receiving-side failure §6 left standing is closed with them.

| Finding | Disposition | Commit | Test | |---|---|---|---| | S4-9 (P2) — adoptTrack pruned only ended tracks, so a camera rebuilt on the known camera mid with its predecessor still live left the stream holding [old, new] and the tile showing the old one | Fixed. Each role — camera, screen — keeps a stream of this file's own; adoptTrack makes the arriving track the track of its kind in it, whatever the predecessor's readyState; renderTiles names the track each tile is meant to show and tile() binds to that, never to an array position | 560c9d2 | Four, all seen failing against the shipped source first; the same-mid replacement reproduced Codex's cameraTracks: [old, new], shownTrack: old exactly | | S4-8 (P2) — exhausting NEGOTIATE_ROUNDS cleared renegotiate in the finally, discarding an outstanding negotiation (waits 4, offers 0) | Fixed. The bound limits how long one attempt goes round, not whether outstanding work matters: the ask stays on the connection and keepNegotiation gives it the connection's next return to stable, or a timer where nothing else will announce one. One retry at a time; a connection that goes away keeps none | 5546a8d | Three, two mutation-verified; the first reproduces Codex's trace and asserts the ask survives it | | S4-7 (P2) — Go escapes U+2028/U+2029 unconditionally, JSON.stringify leaves them literal, so 2045 a's and one U+2028 counted 2048 in the composer and 2051 at the server | Fixed. chatBytes escapes them the way Go does. The pattern is written as escapes because both characters are line terminators in JavaScript source — which is most of why the gap existed | bb97a15 | Client test seen failing first (6 !== 3); five matching server cases, sent as themselves the way a paste arrives | | S4-10 (P3) — a decreasing framesEncoded counter read as "encoding recovered" and replenished the repair allowance | Fixed. The baseline moves either way, because the old number means nothing after a restart; the budget is forgiven only by frames that actually arrived | 716e0f6 | Two; the first seen failing first, the second holds the other side | | S4-11 (P3) — every case in the canonicalisation regression sent an already-canonical payload | Fixed. Two cases now send real JSON escapes and require the decoded letters on the wire — verified by putting the raw bytes back, where those two fail and nothing else does — and share has output coverage at last | 716e0f6 | Seven cases, two of them discriminating | | The S4-6 gap — frameGrowth returns on the first increase, so its timeout is a deadline and not an observation | Fixed. sustained requires growth in two successive intervals, and checkMedia asks it of everything a side should be receiving at once. Applied after every settled transition in share and mutualshare, including after the simultaneous stops and after the asymmetric stop's own five-second wait, which every media check used to precede | 00029e8 | The scenarios themselves; the round-two suppression mutation stays the gate on the baseline half |

§15.16 no longer runs three facts together. It now records separately: the historical encoder-loss observation from Task 4 (which stands as evidence of what a rollback costs, and is not the diagnosis of anything still failing), what the yield does about it (prevents the rollback; a duration, not a guarantee), and what is repaired when it happens anyway (two bounded watches, both ending in a reset). The sentence saying there is no detection or repair, and the one promising recovery three paragraphs later, are both gone.

The tile that would not paint — what the identities showed

S4-9 was a real defect. It was not this one. With the tile bound to the role's own track, laterolls failed in the same place, and the identity reading added for the purpose — meet.media(), which compares the objects inside the page because identity does not survive an evaluate() — settled what the failure is not:

wanted   ce46729b-…aef7
bound    ce46729b-…aef7
element  ["ce46729b-…aef7:live"]
receiver mid 1, sendrecv, live, muted:false, isCamera:true
agrees   true            currentTime 1.452

Three answers, one object, on both sides. The element held exactly the track the connection was receiving the camera on, live and unmuted, and the decoder went on delivering frames it never painted. Everything upstream of the element was right and the picture was stopped downstream of it — which is the branch Codex named for exactly this result.

So a second watch, on the same one-second getStats walk and in the same shape as the encoder one: framesDecoded per tile, and three polls of "the decoder is delivering, the track is playable, the clock has not moved" is a rendering stall. The repair is the stream taken off the element and given back, and play() asked for again; two of those, then a reset, then it stops asking. A tile receiving nothing is idle rather than stalled, which is what reading the decode count alongside the clock is for.

Measured either side of it, from the scenario's own 500 ms series of rendered-frame totals: [25,26,26,26,26,26] — stopped, and stopped for the twenty seconds the check waited — before, and [25,25,25,25,25,26] after: frozen for the three polls it takes to notice, then moving again. laterolls is out of skipped and passing, and the deterministic camera failure §6 recorded as a deploy blocker is closed.

laterolls also proves its own premise now, which it did not: it counts remote offers applied over this side's own outstanding offer — the rollback, seen from outside — and fails if there was none to recover from. One was seen on every run.

Three red runs, and what each of them was right about

The render watch did not land clean, and the gate was right every time.

1. playfallback, twice. §5 offers a Play control when the browser's autoplay policy refuses a remote video, and it stopped appearing. Guarding the watch on paused was not enough: the tile binds more than once now — audio arrives, then the camera — and the second bind called play() again behind the refusal and hid a question nobody had answered. shouldPlay is the rule that came out of it, and it is a product rule rather than a watch rule: while the Play control is showing, the gesture is the person's to give.
2. laterolls, on a stutter. The tile painted one frame every few seconds — [22,23,23,23,23,25] across three seconds — and any advance at all counted as health, so the watch's budget reset for ever and the connection never earned the reset that would rebuild it. A second of video is a second of clock; a frame is thirty milliseconds. RENDER_MOVED is 0.25 s now, a clock that goes backwards is the watch's own repair landing rather than a stall to judge, and the replay hands the element a new MediaStream over the same tracks rather than the object it was already holding.

Measured on the run that had been failing: [25,25,25,25,25,25] — stopped dead — and then 21 → 26 across two successive intervals once the watch escalated. The stall is the browser's; what is claimed here is a bounded recovery from it, and nothing more.

The gate on the final head: make browser twice, 31 of 31 both times, 484 s and 485 s, with laterolls in it and skipped empty — the first time this branch's gate has carried no skipped scenario since Task 5 put mutualshare in it. 206 node tests, make ci, -race and go vet -tags browser green.

---

8. Codex round 3

Judged at a4d1ec1. S4-7, S4-9, S4-10 and S4-11 closed; S4-8 and S4-6 half-closed, each with the half that was missing named as a new finding; three more beside them. All five are closed on this branch.

| Finding | Disposition | Commit | Test | |---|---|---|---| | S4-12 (P2) — the retry timer spent the ask it was meant to protect: it fired mid-exchange, negotiate cleared the flag, slept, woke to a connection still not stable and walked away (pending false, timers none, offers none) | Fixed. An attempt that settles nothing owes the ask back: politeYield answers with the reason rather than a bare no, a busy wake and an offer that never went out both hand renegotiate back, and the timer defers instead of consuming, bounded by NEGOTIATE_DEFERS | ad13608 | Five, both halves mutation-verified; the harness runs the timer callback now, which is what the round-2 tests never did | | S4-13 (P2) — the render repair handed the element a fresh stream and left the role writing to the old one, so a microphone arriving or being replaced afterwards went where nothing was showing: authoritative [video, new mic], element [video, old mic] | Fixed. freshStream puts the new object back where the role keeps it, which restores the rule the file has about tiles: the element holds the role's stream, and every track adopted later reaches it | 5a0be1e | Three replay tests, mutation-verified against the element-only version | | S4-15 (P2) — a screen replaced on its own mid ends afterwards, and its ended listener checked only the connection, so the dead screen took the live replacement's tile with it | Fixed. The share is dropped only if the ending track is still the one being shown | 5a0be1e | One test, mutation-verified; the screen that is showing still ends its tile | | S4-14 (P2) — sustained was two early-return waits: 0, 1, 2, 3 then frozen for ever passed with a twenty-second argument, and streams were walked one after another | Fixed. observe requires growth in every one of three windows of 1.5 s, watchMedia reads every stream on both pages in one pass, and each caller names the keys it expects rather than asking the page what it is showing | 85e0a61 | Ten node tests in a new media.test.mjs, Codex's burst-then-freeze reproduction among them | | S4-16 (P3) — §15.16 called the yield unconditional, listed slow stuttering as exempt when the watch repairs it, and claimed a recovery resting on those windows | Fixed in the spec: the yield is conditional on its allowance, stall criteria and exemptions are two separate lists, and the recovery claim is now "bounded and timed", with what is still not established said plainly | this commit | — |

What the new windows found on their first run, which is the whole argument for them: laterolls went red with 28->28->28->28 on one camera. Two of that was mine — the scenario's own pre-check was "the counter is above zero", which a counter left over from before the collision answers by itself, and the settle check ran before the recovery rather than after it, so a pair mid-rebuild read as a pair that never settled. Fixed in the same commit: growth from a fresh baseline for the arrival of recovery, then settling, then the windows. It passes with the stall really happening first — rendered frames [25,25,25,25,25,25], recovery at 26 → 28, and 273->296->320->351 through the windows.

The reproduction, kept for an upstream report

This is the material for a Chromium bug, and it is written down here because it is the thing this slice learned that nobody else has.

Setup. Two peers on one connection, both sharing a screen at the same moment, with one side's own offer requests held back four times POLITE_YIELD (1200 ms) so the remote offer lands after the yield and the polite side rolls back. The gate's laterolls scenario does exactly this and counts the rollback (setRemoteDescription of an offer while in have-local-offer) rather than assuming it.

*What is observed on the receiving side afterwards*, from meet.media(), which compares the objects inside the page because identity does not survive an evaluate():

cameraMid  1
wanted     ce46729b-…aef7      (the track onRemoteTrack recorded)
bound      ce46729b-…aef7      (the track the tile is bound to)
element    ["ce46729b-…aef7:live"]   (the tracks in video.srcObject)
receivers  mid 1, sendrecv, live, muted:false, isCamera:true
agrees     true
currentTime 1.452               (and it does not move again)

with getStats on the same connection reporting framesDecoded rising throughout for that mid, and the far side's framesEncoded rising too. So: the sender encodes, the receiver decodes, the element holds exactly the receiver's own live, unmuted track — and paints nothing. Everything upstream of the element is right and the picture is stopped downstream of it.

The workaround that has an effect, and it is a workaround: taking the element's srcObject away and giving it a new MediaStream over the same tracks. Re-assigning the same object does not do it — that was measured, and it bought a frame or two. Rendered-frame totals every 500 ms, before and after the watch that does this: [25,26,26,26,26,26] and [25,25,25,25,25,26]; a later run [25,25,25,25,25,25] then recovery.

What is not established. Why a new stream object unblocks the element; whether the decoder pipeline is rebuilt or merely re-attached; and whether the rollback is the cause or only the trigger. Nothing here identifies the Chromium defect — it locates it, downstream of decode and upstream of paint, with a reproduction that runs in a headless Chromium in under a minute.

Destination: file it upstream, with this scenario and these readings. Until it is understood, §15.16 claims a bounded, timed recovery and nothing more.

The gate on the final head: make browser twice, 31 of 31 both times, 523 s and 522 s, nothing skipped, with the timed windows in every media check. 232 node tests — the five files plus the new media.test.mjs — and make ci, -race and go vet -tags browser green.