[yaacovcorcos]

What Changed

readerScrolling.browser.test.tsx, "manual scrolling cancels limited answer following without rearming it": the streamed answer now runs on a thread marked working (isWorking: true), with a comment saying why. No app code changes.

Why

This test has been failing now and then in the non-required "Test Web layout" job on unrelated PRs (#587, #590). Both times the reader was carried down: 1928px and 2443px.

The test streamed an answer on a thread marked idle, which the app doesn't do. On an idle thread, idle end keeping (keepReadingEndInView in readerScrolling.ts) holds a reader at the end while they're within its last three lines. Whether the test's 80px scroll left the reader inside that allowance depended on how far the follow had moved first. On a slow runner it sometimes did, and end keeping then pinned the growing answer. The follow's cancel, which is what the test is about, worked every time.

While an answer streams, its run is working and end keeping is off. The test now uses that state, so it checks only the follow.

Documentation Impact

Documentation impact: None (test only).

UI Changes

None.

Verification

Local, Windows 11, Chromium layout harness, with the CPU slowed 6× through CDP to match CI:

• Reproduced: an instrumented copy of the test failed 9 of 25 runs. Every scroll write that moved the reader came from keepReadingEndInView (readerScrolling.ts:295, via the bookkeeping frame at :328).
• After the change: 25 of 25 pass.
• Test still catches its bug: with the follow's cancel disabled in useBoundedAnswerFollow.ts (reverted), 6 of 6 runs fail, and the writer is the follow's own tick.
• Full files: readerScrolling.browser.test.tsx and responseFollow.browser.test.tsx pass, 40 tests at normal speed.
• Static: vp fmt --check and git diff --check pass.

Implemented through the Claude Code harness (Scient) using claude-opus-5-5.

🤖 Generated with Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.6 KiB	5.6 KiB	0 B (0.0%)	6.8 KiB	✅
Codex	Thread snapshot wire	4.3 KiB	4.3 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.3 KiB	1.3 KiB	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	26.2 KiB	26.2 KiB	0 B (0.0%)	29.3 KiB	✅
Codex	Live turn messages	2	2	0 (0.0%)	8	✅
Claude	Total thread wire	5.6 KiB	5.6 KiB	+36 B (+0.6%)	6.8 KiB	✅
Claude	Thread snapshot wire	4.3 KiB	4.3 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.3 KiB	1.3 KiB	+36 B (+2.7%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	26.5 KiB	26.6 KiB	+41 B (+0.2%)	29.3 KiB	✅
Claude	Live turn messages	1	2	+1 (+100.0%)	8	✅

Baseline: a8a3cae · PR result: 64d946c · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Full compact HTTP snapshot with live cursor.

• Codex decoded thread snapshot: 133.1 KiB
• Claude decoded thread snapshot: 133.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.