# Meet slice 3 — the record Branch `slice/3-relay`, `0690a7a..67f2292` (started on main `2215f26`). Spec: `docs/superpowers/specs/2026-09-07-meet-design.md`, revision 9 (§15.13 and §15.14 carry this slice's two wire/behaviour rulings). Slice 3 built the platform relay: `CARLOS_RELAY` parsing and minting against the platform's own vector, `GET /m/{sqid}/ice`, and the browser client's renewal before the credential's deadline — six tasks, each with its own review and fix rounds, kept in `.superpowers/sdd/2026-09-10-meet-slice-3-relay/progress.md` and the `task-N-report.md` files. Like slice 2'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: - **`/ice` carries the peer as `?peer=`**, the way the stream's own resume already does, not a body. **Ruling.** A native client needs no body on a GET, and `/ice` has nothing else a body would carry. Cost if wrong: none observable. Written into spec §15.13. - **A member's `/ice` re-derives standing and, when it is gone, ends the participation** — mutating, exactly like `/signal`'s own §15.12 correction — while a guest never consults standing at all (ruling 14). Cost if wrong: one extra standing read per `/ice` call, which is rare — once per two and a half hours per call, on the client's own schedule. Written into spec §15.13. - **The client's fetch-failure retry stays at one minute.** The gate proves the warning appears and the call stays connected on a failed fetch; it does not prove the one-minute recovery, which would cost the gate roughly seventy seconds per scenario for no more assurance. - **The relay is enabled on the app after the edge deploy**, verified by `carlos relay status` and the instance's own startup line; no test in this branch touches a real relay (§13, and §4 below). - **The renewal schedule is the earlier of a ratio estimate and a clock estimate**, never the server's `renewAt` read as a bare instant: `(expiresAt − renewAt) × 5` survives clock skew because it is built from two of the server's own instants, while `renewAt − fetchedAt` catches the truncation the ratio reading can mishandle at short lives. Found during Task 4's fix round 2, after round 1's schedule amplified the server's own second-truncation at short test lives; written into spec §15.14. - **`memberStandingGone` returns `(bool, error)`**, not the brief's bare `error` — `hub.Authorize` mirrors `Relay`'s own `gone, err := …; if err != nil { return err }; if gone { return ErrNotYours }` shape. An implementation decision the spec has no opinion about (Task 3). - **The development header's TTL test uses 12s/10s, not the brief's 2s example** — at two seconds, `life*5/6`'s fractional remainder can round to the same whole second as `life` once both are truncated by `.Unix()`, intermittently making `renewAt == expiresAt`. Any TTL that is a multiple of six seconds keeps the margin clear of that rounding (Task 3; the same fact governs the browser gate's own TTL choice, §4 below). - **`icerenewal` uses an 18-second TTL, not the brief's 12s** — twelve leaves two seconds between the renewal starting and the deadline that prints the expired sentence, which this scenario asserts stays away; eighteen leaves three, and the run measures the margin directly so a change to either end is caught (Task 5). `icefail` keeps 12s, where the deadline arriving *is* the point. - **Recovery from a failed `/ice` fetch is left unproved in the browser gate**, exactly as the ledger's own ruling allows: `ICE_RETRY` is a fixed minute by design, and watching it clear costs roughly seventy seconds for no more assurance than the warning appearing already gives. The rest of each task's own decisions — the suffix validation regexes, the JSON golden-shape pins, `atomic.Value`'s nil-but-typed slice, the `--host-resolver-rules` Chromium flag that keeps the platform's relay hostname off the network entirely — are in the task reports themselves and are not repeated here; §2 gives each task's disposition, not its full diff. --- ## 2. Per-task review dispositions | Task | Built | Review | Fix rounds | Final | |---|---|---|---|---| | 1 — `internal/calls/relay` | `Parse`, `Region`, `Mint`, `Credential`, `ICEServer`; the platform vector test | Needs fixes: HIGH — `Parse` echoed the raw region field in its errors; MEDIUM — no redacting `String()` on `Region`; MEDIUM — the no-echo test didn't prove its own name; six LOW items (`[]`/`null` unification, an empty URL reaching `RTCIceServer`, an undocumented expiry precondition, unpinned no-mutation/JSON-shape/suffix-regex/base64-alphabet/TURN-case-insensitivity behaviour) | Round 1 `991352e` (combined with Task 2): all ten fixed. Re-review: three test-only pins remained, folded into Task 3's fix round. | Complete; pins verified in Task 3's fix round (`b5c29b3`, items 9–12). | | 2 — `Config.Relay`, `resolve`, the atomic floor read | `app.relay atomic.Value`, `relayRegions()`/`relayConfigured()`, `TestHandle.SetRelay`, the room-page `Floor` value wired to it | Needs fixes (production code judged right): the Task-1-inherited echo at `config.go:146/148`; a test that printed the key on failure; the with-relay build path and its one INFO line untested; the floor sentence's "relay configured ⇒ absent" direction untested (a hardcoded `Floor` was passing `make ci`); the refusal test satisfied by `relay.Parse`'s text rather than `config.go`'s own phrase; a false doc comment on the since-deleted `RelayConfigured` field; `SetRelay` unproven before Task 3 became its first caller; malformed cases exercising only the outer error | Round 1 `62853ed` (combined with Task 1): all eight fixed, including deleting the dead field once `grep` confirmed nothing else read it. | Complete. | | 3 — `GET /m/{sqid}/ice`, `hub.Authorize` | The wire shape, the §2.5 authority check, the development TTL header | Needs fixes: MEDIUM — `/ice` read the store before authority and was unlimited (no `LiveForSession` gate, no limiter); MEDIUM — the logging test passed even with a credential logged on success; MEDIUM — the dev header had no ceiling; several test gaps (ended-meeting refusal, `validPeerID`/`validSqid` load-bearing against a newline, byte-equality against a real `/signal` 404, a malformed sqid); five LOW items (the 500 arm's `path`, an overstated doc comment, log level, an unlogged meeting refusal, a duplicated test helper, an unpinned JSON entry); the guest half of the standing test not discriminating | Round 1 `b5c29b3`: all fixed except four items carried forward — see §3. Re-review: clean. | Complete. Carried: the sqid guard on `/ice` (unproved); the shared-bucket pin; the log-test comment; the family-wide `path` nit. `N4` (`Retry-After` on `/ice` 429) was folded into Task 4's fix round instead of carried. | | 4 — `room.js`, the ICE list and renewal | `fetchIce`, `scheduleRenewal`, `renewAll`/`renewOne`, `proveRenewed`, the must-succeed-by watchdog, the `data-relay` floor sentence | Needs fixes: HIGH — the watchdog's exemption compared against the wrong stamp and was unreachable; HIGH — a stale selected pair could answer for a fresh one in Chromium; MEDIUM — manual Retry erased the note and did nothing on a failed fetch; MEDIUM — the warning showed even on the floor, with no relay to fail; MEDIUM — the schedule trusted the client's clock, not a duration; six LOW items | Round 1 `9fed86c`: nine of eleven items fixed outright, two (the 429 loop, the schedule) added or partly addressed. Re-review after round 1: two half-closed — MEDIUM A, the ratio/clock amplification of the server's second-truncation at short lives (a 2s life could silently never renew; a 10s life landed the deadline 2s late); LOW B, `failedSince` stamped once per outage rather than per attempt, letting a visibility catch-up jump the retry queue — plus three nits. | Round 2 `67f2292`: A and B fixed (earlier-of-ratio-and-clock scheduling per spec §15.14; `lastTryAt` stamped every attempt); the nits fixed; and, not asked for but needed, the stale-roster-after-await defect Task 5 traced (see below) and an `adoptServers` guard against restarting a negotiation already in flight. Still owed: a Go tripwire pinning `iceRenewAfter == iceLife*5/6` against the client's own ratio arithmetic drifting from it silently, and the residual gate flake's diagnostics — see §3. | | 5 — the browser gate: `ice`, `icerenewal`, `icefail` | The three scenarios, `state().ice`/`state().renewals`, the credential-never-in-console check, the Chromium flag keeping the relay hostname off the network | No separate review pass: the task's own result was 23 passed, 3 skipped, with the skip's cause fully diagnosed and reproduced rather than papered over — `applyRoster` reconciled the roster it captured *before* awaiting `/ice`, so a `peer` event landing during that fetch was closed by the stale roster and its §4.6 counters dropped, discarding the answer that followed as an already-seen replay. The same defect, reached through a different door, explained slice 2's `staletarget` flake. | Fixed as part of Task 4's fix round 2 (`67f2292`), which also fixed a second door onto the same symptom (a superseded roster applied at all) and reordered `accept`'s generation check ahead of its cursor check. | Complete; the three scenarios un-skipped, `make browser` 26/26. | | 6 — this record and spec §15.13/§15.14 | Documentation only | — | — | This commit. | --- ## 3. Carried items, and where they go - **The sqid guard on `/ice` is unproved.** Task 3's own peer-newline test (`TestIceNeverLogsAMalformedPeerVerbatim`) has no sqid equivalent: nothing proves an oversized or newline-bearing sqid never reaches the limiter key or the log the way an oversized peer is proven not to. **Destination: the next fix wave**, alongside whatever review of the whole branch runs next — mirror the peer test with a sqid-shaped input. - **`/signal` and `/ice` sharing one rate-limiter bucket is implemented but not pinned.** `TestIceRateLimitsOneSessionsBurst` proves `/ice` alone is rate-limited; nothing spends the budget on one endpoint and shows the other refused because of it. **Destination: the next fix wave** — a test that exhausts the bucket through `/signal` and then gets 429 from `/ice` in the same session and room, or the reverse. - **The log-test comment says authority where the arm is unbound.** `ice.go`'s refusal logging distinguishes an `outcome=unbound` refusal (no live participation at all, checked first, before the store or the limiter) from an `outcome=authority` refusal (`hub.Authorize`'s own four sentinel errors, checked last); a comment near the log-content test names the wrong one. **Destination: the next fix wave** — a one-line comment fix, found while writing this record and not worth a separate commit on its own. - **The family-wide `path` nit.** Every no-session-subject 500 across the handler family (`auth.go`, `stream.go`, `signal.go`, `ice.go`, `handlers_room.go`'s four arms) logs `r.URL.Path` on an arm that should be unreachable if the framework's own session middleware is doing its job — an unbounded, attacker-shaped value on a path that exists only for a bug elsewhere. Not `/ice`-specific; carried under its own name because fixing it in `/ice` alone would leave six other call sites inconsistent. **Destination: a family-wide pass**, not this slice's fix wave — touching all seven call sites at once is a different-shaped commit from anything slice 3 built. - **The Go tripwire `iceRenewAfter == iceLife*5/6`.** Task 4's fix round 2 moved the client's own schedule to the earlier of a ratio and a clock estimate (spec §15.14) specifically so the client's arithmetic stays correct even if the server's numbers drift — but nothing on the Go side pins that `ice.go`'s `iceRenewAfter` constant is still five sixths of `iceLife`, which is the assumption the ratio's own "renewal at five sixths of the life" shape depends on. Named as owed in Task 4's own fix-round-2 report. **Done** in fix round 3: `TestIceRenewAtIsFiveSixthsOfTheLife` in `internal/callstest/ice_test.go` (not `internal/calls` — the constants are unexported, so the tripwire reads the ratio off the wire, which is the form the client actually depends on). Verified against a deliberately moved constant. - **A margin too small to schedule on. Decided, not carried.** A development-only `X-Meet-Test-Ice-TTL` under about six seconds leaves a renew-to-expiry margin below a second, and the client's own one-second floor under the renewal delay would then turn that list into a fetch roughly once a second for as long as the tab stayed open — a client that can be made to hammer its own server, even if only a developer can ask it to. The choice was between clamping the client and recording a gate rule that no scenario may use such a TTL; the Codex fix wave **clamped the client**, because a rule that lives only in a document is a rule the next scenario breaks. `schedulable()` is false below a one-second margin: nothing is timed, and `state().ice.schedulable` says so rather than the client looking idle for no reason. Node-tested (W3-12). - **The residual gate flake, `connectionState: "new"`.** Roughly one full `make browser` run in three loses one scenario — a different one each time — always at the first pairing, always with the same signature on both browsers: descriptions exchanged and `stable`, but `connectionState: "new"` — no ICE transport ever left the new state, meaning gathering and checking never started. This is not the stale-roster defect (whose signature was `peers: []`); it matches the Makefile's own documented environment symptom, hitting one scenario at a time rather than every scenario in the run. Three things were tried against it in Task 4's fix round 2 and none moved it: the `accept`-ordering fix (kept regardless — it closes a real hole), a negotiation nudge for a lost `negotiationneeded` event (reverted — no evidence it was the cause), and re-running affected scenarios in isolation, where all of them pass every time. The reviewer's reading of that signature, which the fix-round-3 diagnostic was written to settle: `stable` with `connectionState: "new"` does not mean "negotiated and could not gather" — it is also what a connection that *never negotiated at all* looks like, because a peer connection is born `stable` and `new`. The decisive value is `localDescription`: null says nothing was ever offered, so nothing was ever gathered, and the fault is upstream of ICE entirely. Fix round 3 prints it. `diagnose()` in `call.mjs` now carries a `pcState` array for every connection the page still holds — `signaling`, `connection`, `ice`, `gathering`, `local`, `remote`, `senders`, `transceivers` as `direction:kind`, and `tracks` as `kind:readyState` — collected through the construct trap that scenario already used for its own `getStats` walk, now installed on every context. It changes no assertion. **What the fix-round-3 diagnostic then showed** (whole-branch review W3-7, from a lost `playfallback` run and confirmed by a lost `staletarget` one): negotiation is *not* where it stops. Both sides report a local offer and a remote answer applied, `signalingState` stable, two `sendrecv` transceivers, and live tracks on the senders — and `iceConnectionState: "new"` all the same, with `iceGatheringState` `complete` on one side and still `gathering` on the other. So the fault is inside ICE, after a negotiation that finished properly, and the reading in the paragraph above — "nothing was ever offered" — is wrong for these runs. The Codex fix wave adds the next four numbers, per peer, to `state()` and to `diagnose()`: candidates gathered (`onicecandidate`), candidates posted (`send` of type `candidate`), candidates received, candidates added (`addIceCandidate`), and the pending buffer's length. Counts only — an address is not something the client publishes. Between them they say which of the four ways ICE can stall this is, in one losing run. Round 3 also closed the likeliest client-side cause the *earlier* reading admitted: `createPC` registered the connection before attaching its listeners (so a `negotiationneeded` fired by `addTrack` could be lost outright, leaving exactly a `stable`/`new` connection that never offers), and its recvonly fallback was all-or-nothing, so a browser that came down `startLocal`'s ladder to audio alone offered no video m-line and the peer's tile could never get a frame. Whether either was the flake is unproved; both were real, and W3-7's reading now says neither was it. **Settled, in the Codex fix wave itself.** The counts were read from three losing runs — `ice`, `icerenewal` and `staletarget`, on separate gate runs — and all three say the same thing: | side | gathered | delivered | received | added | pending | gatheringState | | --- | --- | --- | --- | --- | --- | --- | | A | 4 | 4 | 0 | 0 | 0 | complete | | B | 0 | 0 | 4 | 4 | 0 | **gathering** | (`delivered` was `posted` when these were captured; Codex round 2 moved the count to where the hub accepts a candidate rather than where one is handed to a queue, and the readings are unchanged.) One browser gathers **no ICE candidate at all** and never leaves `gathering`. The other gathers, posts every one it gathers, and the first adds every one it receives. There is nothing for the client to do differently: it sends what the browser gives it and applies what arrives. The stall is inside one Chromium's own candidate gathering, which is the Makefile's documented environment symptom — "Chromium gathers zero ICE candidates and every call fails with frames stuck at 0" — reaching one context at a time instead of all of them. It correlates with load: every losing run of this wave took 560-590 s against a healthy 318-420 s, one hit `go test`'s own ten-minute timeout, and the wave ran while a whole-branch reviewer was working the same tree. **No further client change is owed.** What is owed, if anyone wants it gone: run the gate where nothing else is running, and give `assertPair` a failure message that names `gathered: 0` for what it is, so the next person spends a minute on it rather than a fix round. --- ## 4. Deploying this slice Enabling the relay is not free the way slice 2's ordinary deploys are. **`carlos relay enable --app meet` re-renders the app's config and restarts the instance**, which drops every live call exactly as an ordinary deploy does (spec §15.11 — the hub is per process and dies with it). So: **enable the relay in the same deploy window as the edge deploy**, not as a separate step days later that catches a room full of people by surprise a second time. Verification is two commands, not one: `carlos relay status --app meet` confirms the platform's own side, and the instance's own startup line — `meet: relay configured regions=N` — confirms the app actually parsed what the platform handed it, at the region count expected. Both matter; the platform reporting a relay attached and the app logging zero regions would be the config having reached the process malformed, caught only outside development (§15.13's startup refusal) or silently accepted as no relay if the value were simply empty. **No test on this branch touches a real relay.** Every gate — `relay`'s own vector test, the config tests, `/ice`'s tests, and the three browser scenarios — proves the contract against fixtures and a fake `/ice`. The platform relay itself is verified only by the two commands above, after the deploy that enables it. --- ## 5. The gates, and how to run them | Gate | Command | Notes | |---|---|---| | The one gate | `CGO_ENABLED=0 make ci` | vet, gofmt, tests, migration check — unchanged from slice 2. | | Race | `CGO_ENABLED=1 go test -race ./internal/...` | Run repeatedly through this slice's fix rounds; green throughout. | | Browser | `make browser` | 26 scenarios, three of them (`ice`, `icerenewal`, `icefail`) new this slice. **Needs the sandbox off** — inside the Claude Code bash sandbox Chromium gathers zero ICE candidates and every call fails, as slice 2's record already noted. **A development TTL header must be a multiple of six seconds** — `X-Meet-Test-Ice-TTL`'s life is split `renewAt = life*5/6`, `.Unix()`-truncated on both ends, and only a multiple of six keeps the margin clear of that truncation (a twelve-second life reads exactly 10 and 12; a ten-second life reads 8 and 10, where the same arithmetic renews at the very moment the credential dies). **The run takes about 5.5 minutes** — 317.95 s measured over ten full runs in Task 4's fix round 2, five of the ten and the last two clean at that mark, against 287 s in Task 5's own run with the three ICE scenarios skipped. | `make browser` is still deliberately outside `make ci`, for the reason slice 2's record already gives. The residual flake in §3 above is why a red run here is worth a second run before it is worth debugging, exactly as slice 2's `rosterpair` flake was. ## Codex round 1 `codex exec` read the branch at `6b316cc` and asked for changes: no P1, five P2 and two P3. The whole-branch reviewer read the same tree concurrently and numbered its own findings W3-1..W3-12, of which W3-1..W3-6 are the same defects. One commit answered all of them. | Finding | What it was | Disposition | Test that would have caught it | | --- | --- | --- | --- | | S3-1 / W3-1 (P2) | `expireUnrenewed` exempted any connection with `renewed=true`, and nothing ever cleared that flag: one successful renewal exempted a connection from every later deadline, so a second credential could expire in silence | Fixed. The watchdog reads `entry.listAt` — the stamp of the list a connection is actually on, which moves only on proof — and exempts only a connection on a list newer than the expiring one | `a renewal in an earlier cycle does not exempt a connection from a later one` | | S3-2 / W3-2 (P2) | `retryRenewal` fetched for the whole call and renewed only its own tile, while resetting the shared timers: every other connection stayed on a credential about to die | Fixed. `renewOutdated(expiring)` hands a list that has just arrived to every connection still on an older one, and both the scheduled renewal and a tile's Retry go through it | `a Retry on one tile renews every connection the fetch re-credentialed` | | S3-3 / W3-3 (P2) | With no baseline fragment — including after a rejected `getStats` — any succeeded selected pair counted as proof, and `''` passed a `!== null` check; a connection could be stamped onto a credential it had never gathered on | Fixed. No baseline is no proof, and `''` is not evidence. The poller takes its own baseline from the first reading after the restart and then requires a different one; if none can be read the restart stays unproven | `nothing recorded before the restart is not proof of anything`, `a connection that never moves is unproven, whatever it started with` | | S3-4 / W3-4 (P2) | A successful fetch followed by one failed restart near the old deadline reported "expired" after one attempt of three, with a replacement credential in hand | Fixed. `renewOne` no longer takes a deadline: with a fresh credential it spends all three restarts and its verdict is always `stuck`. `expired` belongs to the watchdog, the only place that knows the other case | `a fresh credential buys three restarts and the verdict is stuck, never expired`, and the `icestuck` scenario | | S3-5 / W3-5, W3-6 (P2) | The gate asserted the client's cached list length, not that any connection received it: `ice` would pass with `iceServers: []` in every constructor, and `icerenewal` with `setConfiguration` deleted | Fixed. The connection trap records every configuration installed — count, credentialed count, and an FNV-1a digest, never a credential — and the two scenarios assert that a real connection got the two-entry list and that the renewal installed a *different* one. The §13 successful-fetch/failed-restart ending gets its own scenario, `icestuck` | `ice`, `icerenewal`, `icestuck` | | S3-6 (P3) | The startup-logging test matched substrings, so duplicate lines, a WARN, or an extra decoded attribute would all have passed | Fixed. A recording `slog.Handler` keeps whole records; the test asserts exactly one INFO record with exactly one attribute, `regions=1` | `TestBuildLogsOneINFOLineWithTheRegionCountAndNotTheKey`, verified against a WARN and against an extra attribute | | S3-7 (P3) | The burst test exercised `/ice` alone, so a limiter of its own would have passed it; the malformed-room case passed with `validSqid` removed, because the liveness gate refuses that room a step later | Fixed. One test exhausts the budget entirely through `POST /signal` and then asks `/ice`; another sends an oversized room id and asserts the log names it `invalid` and that no bucket was minted | `TestIceSpendsTheSignalEndpointsOwnBucket`, `TestIceNeverLogsAMalformedRoomOrMintsABucketForOne`, both verified against the guards removed | | W3-7 | The residual flake's `pcState` showed negotiation complete and ICE at `new`, so the fault is in ICE | Instrumented, then **settled** — see the flake entry above. Per-peer candidate counts (gathered, posted, received, added, pending) in `state()` and `diagnose()`; three losing runs then showed one browser gathering zero candidates | no assertion changed | | W3-12 | A sub-six-second development TTL leaves a margin under a second, which the delay floor would turn into a 1 Hz fetch loop | Fixed, not carried: `schedulable()` declines below a one-second margin and `state().ice.schedulable` says so | `a margin under a second is not a schedule` | Commit: `6b316cc..c3e2318`. ## Codex round 2 `codex exec` read the branch again at `d62e93b`. S3-3, S3-4 and S3-7 closed; the other four were half-closed, each for a reason that had survived under the fix rather than because the fix was wrong. Five new findings, one commit. | Finding | What it was | Disposition | Test | | --- | --- | --- | --- | | S3-8 (P2) | S3-1's other half: the watchdog compared generations correctly and then called `markTrouble`, which returned early on `record.renewed`. A connection that renewed once was never told its *current* credential had expired — and the round-1 test passed a spy for the marking function, so it proved nothing about the path that swallowed it | Fixed. `markTrouble(id, kind, upTo)` compares `entry.listAt` with the list the verdict is about; the boolean is gone from the decision entirely. The watchdog test now runs the real marking functions and reads the sentence `tileNote` would render | `a renewal in an earlier cycle does not exempt a connection from a later one`, `a connection already proven onto a newer list is left alone by the deadline` | | S3-9 (P2) | S3-2's other half: a restart installs list B, another tile's Retry fetches C, `renewOutdated` skips the running restart — and B's proof then stamped the connection with C, a credential it had never been given, whose schedule then governed it | Fixed. Each attempt captures the list it installs and stamps only that generation on proof; when a newer list arrived during the attempt, `followUp` renews onto it once the attempt settles. The follow-up is bounded by the list that run had to work with, so a connection that simply cannot renew does not restart itself for ever | `a proof stamps the list it installed, not one that arrived while it was proving`, `a Retry reaches a connection whose own restart was already running` | | S3-10 (P3) | The trap recorded `setConfiguration` before calling it, so a throw counted as an installation, and the counts were global, so one connection's second update could stand in for another left on the empty list | Fixed. Recorded after the real call returns, keyed by the connection's index; the assertions fold the log to each *live* connection's last configuration | `ice`, `icerenewal` | | S3-11 (P3) | The recording handler put attributes in a map (collapsing duplicate keys) and gave every derived handler its own store, so a logger reached through `WithAttrs` wrote where nobody read and its bound attributes were invisible | Fixed. One shared store, bound attributes and groups replayed onto each record, and the assertion reads an ordered slice with a typed value | `TestBuildLogsOneINFOLineWithTheRegionCountAndNotTheKey`, plus `TestTheRecordingHandlerSeesWhatALoggerCarries` — a test of the test | | S3-12 (P3) | `posted` counted candidates before the stale-target return and before the queue, so it counted ones that never reached the wire | Fixed. Renamed `delivered` and counted where the hub answers 200 | the flake captures above, unchanged in shape | Two test claims were tightened rather than added: the three-restarts test passes an old deadline that the current code ignores, so restoring the removed optional-deadline branch fails it; and the Retry test gains a connection whose own restart is already running, with the extra assertion that it *restarted again* rather than merely acquiring the new stamp — without which the S3-9 bug satisfied it. One behaviour changed that no finding asked for, and it is worth naming: `renewals[peer].attempts` accumulates across runs now instead of starting again at 1 with each one. A follow-up renewal reset it to 1 within milliseconds of the first verdict, which made `icestuck`'s "it spent the whole budget" assertion race, and a count that starts again says nothing a gate can wait on. Commit: `d62e93b..15b2f38`. ## Codex round 3 Read at `9bb0994`. S3-8, S3-10, S3-11 and S3-12 closed; S3-9 half-closed through one remaining door, S3-13. One P3 on a test claim. One commit. | Finding | What it was | Disposition | Test | | --- | --- | --- | --- | | S3-13 (P2) | The last door onto S3-9: `installedAt` was recorded before `setConfiguration`, and a throw from it was swallowed. The restart that followed re-gathered on the *previous* servers, and a new fragment then read as proof and stamped the connection onto a list it had never taken — `listAt` moved, `renewed` went true, no trouble was shown | Fixed. The stamp moves only after `setConfiguration` returns. A refused configuration restarts nothing, proves nothing and stamps nothing: it asks for a fresh generation, whose rebuilt connection takes `ice.servers` at construction and keeps §4.6's counters, and the run ends `stuck` | `a configuration the browser refuses is not a credential the connection has` | | S3-14 (P3) | `icestuck` asserted `attempts >= 3` against a lifetime counter, which cannot say how many restarts *this* verdict followed — a later run raises it while the first verdict is still on the screen | Fixed. `renewals[peer].lastRun = {attempts, verdict}` is captured with the verdict itself; the scenario asserts that run spent three and ended `stuck`, and keeps the cumulative count as a second, weaker line | `a run records the budget it spent, alongside the lifetime count`, `a proven run says so, and says what it cost`, and `icestuck` | `markRenewalStuck` is gone: every verdict now goes through one function that records what the run spent and then says it on the tile, so the two cannot drift. Commit: `9bb0994..8448bee`.