kayg/infraternal

Watch

Fork 0

J394: two tracer specs fail on dev (terminal.spec.ts:5 prediction, predictive-echo.spec.ts:530) #438

New issue

Open

opened 2026-11-08 20:27:49 +00:00 by kayg · 7 comments

kayg commented

2026-11-08 20:27:49 +00:00

Owner

J394: two tracer specs fail on dev (terminal.spec.ts:5 prediction, predictive-echo.spec.ts:530)

Background: J374 (#430) fixed the RTT readout and found two more failures on unmodified dev that it did not investigate:

apps/tracer/test/terminal.spec.ts:5 fails in terminal-scenario.ts (waitForPendingText): the predicted "p" never appears.
apps/tracer/test/predictive-echo.spec.ts:530 ("captures pending and confirmed glyphs across production viewports and themes") fails; J374 saw a proxy "socket hang up".

Questions: is production affected (prod f6f62a875, test server same client)? Is the product or the spec wrong? Plan: bisect each over dev merges with a production build (compute01, build-slot), red test first if product bug, measure prediction latency before/after, atomic commits on fix-predictive-echo-specs (base origin/dev 753fcd657). No merge, no deploy.

Estimate: ~3 h (bisects are minutes per step; queue waits dominate).

J394: two tracer specs fail on dev (terminal.spec.ts:5 prediction, predictive-echo.spec.ts:530) Background: J374 (#430) fixed the RTT readout and found two more failures on unmodified dev that it did not investigate: 1. `apps/tracer/test/terminal.spec.ts:5` fails in `terminal-scenario.ts` (waitForPendingText): the predicted `"p"` never appears. 2. `apps/tracer/test/predictive-echo.spec.ts:530` ("captures pending and confirmed glyphs across production viewports and themes") fails; J374 saw a proxy "socket hang up". Questions: is production affected (prod f6f62a875, test server same client)? Is the product or the spec wrong? Plan: bisect each over dev merges with a production build (compute01, build-slot), red test first if product bug, measure prediction latency before/after, atomic commits on `fix-predictive-echo-specs` (base origin/dev 753fcd657). No merge, no deploy. Estimate: ~3 h (bisects are minutes per step; queue waits dominate).

kayg commented

2026-11-08 20:27:55 +00:00

Author

Owner

Start. Branch fix-predictive-echo-specs, base origin/dev 753fcd657. Plan: (1) run both specs on compute01 at dev head and at prod f6f62a875 to see if they fail there; (2) bisect each; (3) decide product vs spec; red test first if product. ETA ~3 h.

Start. Branch `fix-predictive-echo-specs`, base origin/dev 753fcd657. Plan: (1) run both specs on compute01 at dev head and at prod f6f62a875 to see if they fail there; (2) bisect each; (3) decide product vs spec; red test first if product. ETA ~3 h.

kayg commented

2026-11-08 21:33:50 +00:00

Author

Owner

Finding 1 (dev head 753fcd657, both specs reproduce; log ~/j394-evidence/dev-two.log on compute01): terminal.spec: at the no-echo step the predicted "p" is not drawn because the prediction state has no round trip. Diagnostic: before the key reason=rtt-low, round trip undefined; after the key rtt-unmeasured. So after the drop-ack/resume the round trip is blanked (TerminalClient.startPings on attach) and not refilled in time. Finding is the symptom; cause (does the probe fail to go out, or is the answer dropped?) in progress, with an RTT timeline.
Finding 2 (hypothesis, to be proven): predictive-echo.spec:530 "socket hang up" is the first context.request.get(/__mock/state) on a kept-alive connection through the 300 ms test proxy; the mock server is a node:http server with the default 5 s keep-alive timeout, so a request issued ~5 s after the previous one races the server closing the idle socket.

Finding 1 (dev head 753fcd657, both specs reproduce; log ~/j394-evidence/dev-two.log on compute01): terminal.spec: at the no-echo step the predicted "p" is not drawn because the prediction state has no round trip. Diagnostic: before the key `reason=rtt-low`, round trip undefined; after the key `rtt-unmeasured`. So after the drop-ack/resume the round trip is blanked (TerminalClient.startPings on attach) and not refilled in time. Finding is the symptom; cause (does the probe fail to go out, or is the answer dropped?) in progress, with an RTT timeline. Finding 2 (hypothesis, to be proven): predictive-echo.spec:530 "socket hang up" is the first context.request.get(/__mock/state) on a kept-alive connection through the 300 ms test proxy; the mock server is a node:http server with the default 5 s keep-alive timeout, so a request issued ~5 s after the previous one races the server closing the idle socket.

kayg commented

2026-11-08 21:51:37 +00:00

Author

Owner

Finding 2 proven (no product code involved). predictive-echo.spec.ts:530 "socket hang up" = HTTP keep-alive race in the test double.

Evidence A (spec run, diag2.log): the failing call is context.request.get("/__mock/state") issued 5757 ms after the previous request of the same context (/__mock/open-terminal); the only other calls were reset/open-terminal.
Evidence B (standalone repro, ~/j394-evidence/repro2/, scan result in scan.txt): a plain node:http server (default keep-alive timeout) behind scripts/latency_proxy.py at the spec's 300 ms RTT, driven by Playwright's own APIRequestContext (node and bun runtimes): gap 5.0/5.2/5.4/5.6 s ok, 5.7 s and 5.8 s -> socket hang up (ECONNRESET), 6.0/6.2 ok. With the server's keepAliveTimeout = 0 all gaps pass.
Why now: the capture loop's first poll happens ~5.7 s after the last request; any timing shift (#317 on-demand probes, the #430 RTT fix) moves it into the window. The spec and the product are not at fault; the mock server closes idle sockets while the delayed link still has requests in flight.
Fix planned: mock-server.ts sets keepAliveTimeout = 0 (it is a per-run test double), plus a spec that requests, waits 5.8 s and requests again (red before, green after).

Finding 1 (update, diag2.log): the RTT timeline around the failure is 100ms: rtt 302.8, connected then 200ms: rtt undefined, DISCONNECTED for the rest of the window. The mock closes the socket (code 4001) when it sees the dropped-ack key, the page's isConnected() poll happened to see the old socket still open for ~100 ms, so the scenario goes on while the client is reconnecting; the reattach blanks the round trip (startPings), and "p" is typed while it is unmeasured (rtt-unmeasured), so it is not predicted. Still to establish: how long after a real reconnect the first key is predicted again (production effect) and which commit moved the timing. Bisect batch queued next.

Finding 2 proven (no product code involved). `predictive-echo.spec.ts:530` "socket hang up" = HTTP keep-alive race in the test double. - Evidence A (spec run, diag2.log): the failing call is `context.request.get("/__mock/state")` issued 5757 ms after the previous request of the same context (`/__mock/open-terminal`); the only other calls were reset/open-terminal. - Evidence B (standalone repro, ~/j394-evidence/repro2/, scan result in scan.txt): a plain `node:http` server (default keep-alive timeout) behind scripts/latency_proxy.py at the spec's 300 ms RTT, driven by Playwright's own APIRequestContext (node and bun runtimes): gap 5.0/5.2/5.4/5.6 s ok, **5.7 s and 5.8 s -> `socket hang up (ECONNRESET)`**, 6.0/6.2 ok. With the server's `keepAliveTimeout = 0` all gaps pass. - Why now: the capture loop's first poll happens ~5.7 s after the last request; any timing shift (#317 on-demand probes, the #430 RTT fix) moves it into the window. The spec and the product are not at fault; the mock server closes idle sockets while the delayed link still has requests in flight. - Fix planned: mock-server.ts sets `keepAliveTimeout = 0` (it is a per-run test double), plus a spec that requests, waits 5.8 s and requests again (red before, green after). Finding 1 (update, diag2.log): the RTT timeline around the failure is `100ms: rtt 302.8, connected` then `200ms: rtt undefined, DISCONNECTED` for the rest of the window. The mock closes the socket (code 4001) when it sees the dropped-ack key, the page's `isConnected()` poll happened to see the old socket still open for ~100 ms, so the scenario goes on while the client is reconnecting; the reattach blanks the round trip (startPings), and "p" is typed while it is unmeasured (`rtt-unmeasured`), so it is not predicted. Still to establish: how long after a real reconnect the first key is predicted again (production effect) and which commit moved the timing. Bisect batch queued next.

kayg commented

2026-11-08 22:41:47 +00:00

Author

Owner

Bisect + production exposure (logs ~/j394-evidence/bis-<sha>.log, table bisect-results-1.txt on compute01; each commit built as production, #430's two-line source fix applied on top because without it the RTT-readout step masks later steps):

commit (dev first-parent merge)	terminal.spec:5	predictive-echo.spec:530
`3cc63cb09` (11-03 15:46)	pass	pass
`fa7ec56f6` (11-03 20:39)	fail at "p"	pass
`1633ffeea` (11-04)	fail at "p"	pass
`a6d0223bf` (11-04 19:31)	fail at "p"	fail: socket hang up
`eb0684cbf`, `442ac0f99`, `9630c2bd9`, `af033d0b4`, `5d34c133a`	fail at "p"	pass
`753fcd657` (head)	fail at "p"	fail: socket hang up

predictive-echo.spec:530 flips between pass and "socket hang up" from commit to commit (a6d0223bf, head) without any change to the prediction code: the request lands in the 5.65-5.8 s reset window or not, depending on how long the earlier steps took. That is the keep-alive race from finding 2, so a commit bisect cannot name a culprit. Fix is committed (8f0ae27db, red test cfb258b4c).
terminal.spec:5 first fails in the range 3cc63cb09..fa7ec56f6 (merges e81eb5bb4 #327, 5ed27aa0e j150, fa7ec56f6 #330). Narrowing now.

Production exposure: the live bundles at https://ssh.kayg.org/main.js and https://test.ssh.kayg.org/main.js contain exactly one gate for prediction: ce=c.get("predict")==="1" and predictiveEcho:ce. Predictive local echo is off for every user unless the page URL has ?predict=1; nothing turns it on from the measured round trip (D130 says it should switch on automatically above ~60 ms; that wiring does not exist yet). So the failing specs describe an opt-in path and cannot affect users today. Question for kayg (not blocking, no change made): is the ?predict=1-only state intended until the D130 auto-switch is built?

Bisect + production exposure (logs `~/j394-evidence/bis-<sha>.log`, table `bisect-results-1.txt` on compute01; each commit built as production, #430's two-line source fix applied on top because without it the RTT-readout step masks later steps): | commit (dev first-parent merge) | terminal.spec:5 | predictive-echo.spec:530 | |---|---|---| | 3cc63cb09 (11-03 15:46) | pass | pass | | fa7ec56f6 (11-03 20:39) | fail at "p" | pass | | 1633ffeea (11-04) | fail at "p" | pass | | a6d0223bf (11-04 19:31) | fail at "p" | **fail: socket hang up** | | eb0684cbf, 442ac0f99, 9630c2bd9, af033d0b4, 5d34c133a | fail at "p" | pass | | 753fcd657 (head) | fail at "p" | **fail: socket hang up** | - predictive-echo.spec:530 flips between pass and "socket hang up" from commit to commit (a6d0223bf, head) without any change to the prediction code: the request lands in the 5.65-5.8 s reset window or not, depending on how long the earlier steps took. That is the keep-alive race from finding 2, so a commit bisect cannot name a culprit. Fix is committed (`8f0ae27db`, red test `cfb258b4c`). - terminal.spec:5 first fails in the range 3cc63cb09..fa7ec56f6 (merges e81eb5bb4 #327, 5ed27aa0e j150, fa7ec56f6 #330). Narrowing now. **Production exposure:** the live bundles at https://ssh.kayg.org/main.js and https://test.ssh.kayg.org/main.js contain exactly one gate for prediction: `ce=c.get("predict")==="1"` and `predictiveEcho:ce`. Predictive local echo is off for every user unless the page URL has `?predict=1`; nothing turns it on from the measured round trip (D130 says it should switch on automatically above ~60 ms; that wiring does not exist yet). So the failing specs describe an opt-in path and cannot affect users today. Question for kayg (not blocking, no change made): is the `?predict=1`-only state intended until the D130 auto-switch is built?

kayg commented

2026-11-08 23:06:01 +00:00

Author

Owner

Finding 1 cause (terminal.spec.ts:5, "p" never predicted): a spec race, not a prediction bug. Evidence: ~/j394-evidence/run3-diag.log (page-side timeline, 100 ms samples, round trip : connected : prediction reason):

100:-:d:rtt-low ... 600:-:d:rtt-unmeasured   disconnected, round trip cleared
700:-:C:rtt-low 800:-:C 900:-:C              reconnected, round trip not yet measured
1000:290:C:ready ...                         one RTT after the reattach prediction is on again and stays on for the next 14 s

The scenario types p at about 100-500 ms, inside the reconnect, so the key correctly gets no prediction (rtt-unmeasured) and the poll for pendingText === "p" can never succeed. The mock closes the socket (4001) while accepting b; the scenario waited for "ab" at the double and isConnected(), but isConnected() is still true for the old socket until the close arrives one link delay later, so it moved on early.
Bisect (bisect-results-1.txt, bisect-results.txt): first-parent merges 3cc63cb09 pass; e81eb5bb4 (#327), 5ed27aa0e, fa7ec56f6 and everything after fail at "p". e81eb5bb4 changes nothing in terminal.ts, connection.ts, mock-server.ts or terminal-scenario.ts (only the rootless refusal toast and the real-server harness), so it moved the timing; it did not break prediction.
Product vs spec: spec. Prediction needs a measured round trip and a reattach discards the old one on purpose (TerminalClient.startPings); after a resume the first key is unpredicted for about one round trip (here 300 ms), then prediction is back. That is by design, no change made. Fix: commit 62a775aa4 makes the scenario wait for the double's attach_count to go up (the resume happened) before it types again.
Branch so far (fix-predictive-echo-specs): bf6b7502c (red keep-alive spec), 8251033e8 (mock-server keepAliveTimeout=0), 62a775aa4 (scenario waits for the resume). Gate batch (red, 3x both specs, sibling specs) is queued.

Finding 1 cause (terminal.spec.ts:5, "p" never predicted): a spec race, not a prediction bug. Evidence: `~/j394-evidence/run3-diag.log` (page-side timeline, 100 ms samples, round trip : connected : prediction reason): ``` 100:-:d:rtt-low ... 600:-:d:rtt-unmeasured disconnected, round trip cleared 700:-:C:rtt-low 800:-:C 900:-:C reconnected, round trip not yet measured 1000:290:C:ready ... one RTT after the reattach prediction is on again and stays on for the next 14 s ``` The scenario types `p` at about 100-500 ms, inside the reconnect, so the key correctly gets no prediction (`rtt-unmeasured`) and the poll for `pendingText === "p"` can never succeed. The mock closes the socket (4001) while accepting `b`; the scenario waited for "ab" at the double and `isConnected()`, but `isConnected()` is still true for the old socket until the close arrives one link delay later, so it moved on early. Bisect (`bisect-results-1.txt`, `bisect-results.txt`): first-parent merges 3cc63cb09 pass; e81eb5bb4 (#327), 5ed27aa0e, fa7ec56f6 and everything after fail at "p". e81eb5bb4 changes nothing in terminal.ts, connection.ts, mock-server.ts or terminal-scenario.ts (only the rootless refusal toast and the real-server harness), so it moved the timing; it did not break prediction. Product vs spec: spec. Prediction needs a measured round trip and a reattach discards the old one on purpose (TerminalClient.startPings); after a resume the first key is unpredicted for about one round trip (here 300 ms), then prediction is back. That is by design, no change made. Fix: commit `62a775aa4` makes the scenario wait for the double's `attach_count` to go up (the resume happened) before it types again. Branch so far (`fix-predictive-echo-specs`): bf6b7502c (red keep-alive spec), 8251033e8 (mock-server keepAliveTimeout=0), 62a775aa4 (scenario waits for the resume). Gate batch (red, 3x both specs, sibling specs) is queued.

kayg commented

2026-11-08 23:28:13 +00:00

Author

Owner

Gate evidence on compute01 (production tracer build, test double behind the 300 ms link). Logs: ~/j394-evidence/run4-*.log.

--- run4-red.log (bf6b7502c, spec only, unfixed double)
  ✘  1 test/mock-keepalive.spec.ts:21:1 › a request after an idle pause is answered, not reset (6.8s)
  1 failed
exit=1
--- run4-green3.log (62a775aa4, --repeat-each=3)
  ✓  1 test/mock-keepalive.spec.ts:21:1 › a request after an idle pause is answered, not reset (7.1s)
  ✓  2 test/predictive-echo.spec.ts:530:1 › predictive echo captures pending and confirmed glyphs across production viewports and themes (31.0s)
  ✓  3 test/terminal.spec.ts:5:1 › first run, passkey login, terminal resume, and the latency probe (1.5m)
  ✓  4 test/mock-keepalive.spec.ts:21:1 › a request after an idle pause is answered, not reset (6.8s)
  ✓  5 test/predictive-echo.spec.ts:530:1 › predictive echo captures pending and confirmed glyphs across production viewports and themes (28.7s)
  ✓  6 test/terminal.spec.ts:5:1 › first run, passkey login, terminal resume, and the latency probe (1.4m)
  ✓  7 test/mock-keepalive.spec.ts:21:1 › a request after an idle pause is answered, not reset (6.6s)
  ✓  8 test/predictive-echo.spec.ts:530:1 › predictive echo captures pending and confirmed glyphs across production viewports and themes (26.8s)
  ✓  9 test/terminal.spec.ts:5:1 › first run, passkey login, terminal resume, and the latency probe (1.4m)
  9 passed (6.2m)
exit=0
--- run4-siblings.log
  ✘  21 test/terminal-links.spec.ts:476:1 › a plain tooltip keeps its wrapped layout after a link tooltip (10.0s)
  1 failed
  66 passed (14.6m)
exit=1

Sibling run = predictive-echo, predictive-backspace, terminal, terminal-* (links, query-replay, query-viewers, states, theme, cell-position), snapshot-resume, transient-session-input: 66 passed, 1 failed (terminal-links.spec.ts:476, a sub-pixel tooltip width 306.78 vs 308.00; no relation to this change). Checking that it also fails on unmodified origin/dev, and running scripts/verify quick, in the next slot run.

Gate evidence on compute01 (production tracer build, test double behind the 300 ms link). Logs: `~/j394-evidence/run4-*.log`. ``` --- run4-red.log (bf6b7502c, spec only, unfixed double) ✘ 1 test/mock-keepalive.spec.ts:21:1 › a request after an idle pause is answered, not reset (6.8s) 1 failed exit=1 --- run4-green3.log (62a775aa4, --repeat-each=3) ✓ 1 test/mock-keepalive.spec.ts:21:1 › a request after an idle pause is answered, not reset (7.1s) ✓ 2 test/predictive-echo.spec.ts:530:1 › predictive echo captures pending and confirmed glyphs across production viewports and themes (31.0s) ✓ 3 test/terminal.spec.ts:5:1 › first run, passkey login, terminal resume, and the latency probe (1.5m) ✓ 4 test/mock-keepalive.spec.ts:21:1 › a request after an idle pause is answered, not reset (6.8s) ✓ 5 test/predictive-echo.spec.ts:530:1 › predictive echo captures pending and confirmed glyphs across production viewports and themes (28.7s) ✓ 6 test/terminal.spec.ts:5:1 › first run, passkey login, terminal resume, and the latency probe (1.4m) ✓ 7 test/mock-keepalive.spec.ts:21:1 › a request after an idle pause is answered, not reset (6.6s) ✓ 8 test/predictive-echo.spec.ts:530:1 › predictive echo captures pending and confirmed glyphs across production viewports and themes (26.8s) ✓ 9 test/terminal.spec.ts:5:1 › first run, passkey login, terminal resume, and the latency probe (1.4m) 9 passed (6.2m) exit=0 --- run4-siblings.log ✘ 21 test/terminal-links.spec.ts:476:1 › a plain tooltip keeps its wrapped layout after a link tooltip (10.0s) 1 failed 66 passed (14.6m) exit=1 ``` Sibling run = predictive-echo, predictive-backspace, terminal, terminal-* (links, query-replay, query-viewers, states, theme, cell-position), snapshot-resume, transient-session-input: 66 passed, 1 failed (terminal-links.spec.ts:476, a sub-pixel tooltip width 306.78 vs 308.00; no relation to this change). Checking that it also fails on unmodified origin/dev, and running `scripts/verify quick`, in the next slot run.

kayg commented

2026-11-09 00:25:37 +00:00

Author

Owner

Finish (J394). Branch fix-predictive-echo-specs, head 16ca32dc67e3a4b8e98bd31530e4fd888f494e87, base origin/dev 753fcd657. Pushed; not merged, not deployed.

Commits:

6e53ad7c6 test(tracer): failing spec for a request after an idle pause on the test double (red: run4-red.log, 13 staggered pauses, fails on the unfixed double)
96ea2ac9c test(tracer): the test double keeps idle connections open (server.keepAliveTimeout = 0 in test/mock-server.ts)
16ca32dc6 test(tracer): the terminal scenario waits for the resume before it types again (waits for the double's attach_count; doc comment on terminalScenario)

Causes:

predictive-echo.spec.ts:530: keep-alive race in the test double (default 5 s idle limit behind the 300 ms link): a request 5.65-5.8 s after the previous one is reset. Reproduced without product code. It flips between pass and fail from commit to commit (e.g. a6d0223bf and head fail, the rest pass), so a bisect names no culprit. Spec and product were right.
terminal.spec.ts:5: spec race. The scenario typed p during the reconnect the double forces (the reattach clears the round trip by design; it is measured again about one RTT later), so p was correctly unpredicted. Bisect: green 3cc63cb09, red from e81eb5bb4 on, which changes none of the terminal, connection, mock or scenario code, so it only moved the timing.

Production: not affected. Predictive local echo is only enabled by ?predict=1 in the page URL (live bundles of ssh.kayg.org and test.ssh.kayg.org contain that one gate); no user has it by default, and the D130 automatic switch-on from the measured round trip is not wired. No prediction latency number changed because no product code changed. Question for kayg (not blocking): is ?predict=1-only intended until the D130 auto-switch exists?

Gates (compute01, production build, all logs in ~/j394-evidence/):

both specs x3, plus the new spec x3, on the head: run7-green3.log: 9 passed (6.2m).
scripts/verify quick on the head (run7-quick.log): all rows PASS (scope guard, migration names, Nix vendoring, fmt, doc coverage, shape lints, doc comments on diff, fixed test waits, ui literals, tracer typecheck), QUICK_EXIT=0. verify fast was not run (the task asked for quick).
sibling specs (predictive-echo, predictive-backspace, terminal, terminal-*, snapshot-resume, transient-session-input), run7-siblings.log: 65 passed, 2 failed, both unrelated to this change:
- terminal-links.spec.ts:476 (tooltip width 306.78 vs 308.00): also fails 2 of 2 on unmodified origin/dev (run5-links-dev.log) and in the first sibling run on the branch.
- terminal-theme.spec.ts:206 (one 96 ms long task under load): passed in the first sibling run (run4-siblings.log, 66 passed) and 4 of 4 on both dev and head (run8-theme-*.log).

Real-environment proof: not applicable to a test-only change (no user-visible or root-only path touched); the production claim was checked against the live bundles instead. Cleanup: my VM worktrees and cargo target removed.

**Finish (J394).** Branch `fix-predictive-echo-specs`, head `16ca32dc67e3a4b8e98bd31530e4fd888f494e87`, base origin/dev `753fcd657`. Pushed; not merged, not deployed. Commits: 1. `6e53ad7c6` test(tracer): failing spec for a request after an idle pause on the test double (red: `run4-red.log`, 13 staggered pauses, fails on the unfixed double) 2. `96ea2ac9c` test(tracer): the test double keeps idle connections open (`server.keepAliveTimeout = 0` in test/mock-server.ts) 3. `16ca32dc6` test(tracer): the terminal scenario waits for the resume before it types again (waits for the double's `attach_count`; doc comment on `terminalScenario`) Causes: - **predictive-echo.spec.ts:530:** keep-alive race in the test double (default 5 s idle limit behind the 300 ms link): a request 5.65-5.8 s after the previous one is reset. Reproduced without product code. It flips between pass and fail from commit to commit (e.g. a6d0223bf and head fail, the rest pass), so a bisect names no culprit. Spec and product were right. - **terminal.spec.ts:5:** spec race. The scenario typed `p` during the reconnect the double forces (the reattach clears the round trip by design; it is measured again about one RTT later), so `p` was correctly unpredicted. Bisect: green 3cc63cb09, red from e81eb5bb4 on, which changes none of the terminal, connection, mock or scenario code, so it only moved the timing. Production: not affected. Predictive local echo is only enabled by `?predict=1` in the page URL (live bundles of ssh.kayg.org and test.ssh.kayg.org contain that one gate); no user has it by default, and the D130 automatic switch-on from the measured round trip is not wired. No prediction latency number changed because no product code changed. Question for kayg (not blocking): is `?predict=1`-only intended until the D130 auto-switch exists? Gates (compute01, production build, all logs in `~/j394-evidence/`): - both specs x3, plus the new spec x3, on the head: `run7-green3.log`: **9 passed (6.2m)**. - `scripts/verify quick` on the head (`run7-quick.log`): all rows PASS (scope guard, migration names, Nix vendoring, fmt, doc coverage, shape lints, doc comments on diff, fixed test waits, ui literals, tracer typecheck), `QUICK_EXIT=0`. `verify fast` was not run (the task asked for quick). - sibling specs (predictive-echo, predictive-backspace, terminal, terminal-*, snapshot-resume, transient-session-input), `run7-siblings.log`: 65 passed, 2 failed, both unrelated to this change: - `terminal-links.spec.ts:476` (tooltip width 306.78 vs 308.00): also fails 2 of 2 on unmodified origin/dev (`run5-links-dev.log`) and in the first sibling run on the branch. - `terminal-theme.spec.ts:206` (one 96 ms long task under load): passed in the first sibling run (`run4-siblings.log`, 66 passed) and 4 of 4 on both dev and head (`run8-theme-*.log`). Real-environment proof: not applicable to a test-only change (no user-visible or root-only path touched); the production claim was checked against the live bundles instead. Cleanup: my VM worktrees and cargo target removed.

kayg referenced this issue

2026-11-09 00:29:15 +00:00

J400: enable predictive local echo automatically from measured RTT (D130) #441

kayg referenced this issue

2026-11-09 00:45:35 +00:00

libghostty-vt 1.0 upgrade #419

kayg referenced this issue

2026-11-09 15:13:58 +00:00

J386: tracer browser baseline is red on compute01 #434