[BunsDev]

Context

• Summary: Next stops re-sanitizing and re-wrapping the whole conversation on every frame, and gains Alt+G to go to the start of the transcript.
• Part of Next renders the whole transcript every frame: cost grows with transcript length #439 under [TUI v2][P0] T10: establish terminal safety, accessibility, performance, and cross-platform acceptance gates #417 and [TUI v2] Epic: a unified Coven terminal for coding, tasks, research, and memory #406. Next renders the whole transcript every frame: cost grows with transcript length #439 stays open until the test(tui-tests): add raw PTY performance baseline harness #425 harness measures this on the reference machine, which is its acceptance.
• Stacked on test(tui): hostile-output safety and layout matrix for Next, fixing six leaks (#417 slice) #438 → feat(tui): read-only Next Memory page over daemon familiar-memory reads (#415) #436 → feat(tui): read-only Next Research page over session search and fetch (#414) #434 → feat(tui): read-only Next Work page over engine-local work (T6 slice) #432 → feat(tui): engine-local tool rows and approval safety (T4 slice) #430. Retarget to main as the stack lands.
• Classic is unchanged: it never reaches these rows, and Alt+G falls through to text input there, as Alt+I and Alt+L do.

Measurements

Debug build, one developer machine, 80x24 frame. These are observations printed by next_workload.rs, not gates.

Content	Before	After
Committed answer, 1,000 lines	~1.7 ms	~1.0 ms
Committed answer, 100,000 lines	~90 ms	~1.1 ms
Streaming answer, 1,000 lines	~2.0 ms	~0.9 ms
Streaming answer, 100,000 lines	~94 ms	~1.2 ms

The first frame after a width or appearance change still builds every row once.

What still grows

The review measured these on the first commit, before the streaming change; the committed-message path they measure did not change.

• Message comparison: each frame compares every message with the source of its rows. About 4.3 ms at 50,000 messages and 3.5 ms for 50 MB in one message.
• Tool rows: built every frame, and Done and Error rows stay until /clear.
• Memory: the kept sources hold a second copy of the conversation's text, on top of the wrapped rows. The first frame's work is no longer thrown away, so this memory now stays allocated.

Design

• TranscriptRows keeps wrapped rows per message. A message is rebuilt when its displayed content, the width or the appearance changes.
• Staleness is decided by comparing content, not through App::transcript_version. App::messages is public and written from many places, some of which do not bump the counter, and a missed signal would show wrong text.
• A streaming answer keeps rows for its complete lines. Only the unfinished line is rebuilt, and rows are dropped if the text stops extending what they were built from, as in a retry. terminal_safe works one character at a time, so chunking gives the same rows; a test checks this at several chunk sizes with hostile bytes.
• jumpToStart holds the reader at the first row through resizes and new output until it scrolls down. "New activity below" still shows.

Verification

• cargo fmt --all --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace: 2944 passed, 0 failed
• tmux suite with a disposable HOME: 94/94, including Alt+G in the real terminal case
• New tests:
  • a frame after any change matches a frame drawn from scratch (replaced text of the same length, truncate, clear, rewrap, density);
  • only a changed message is rebuilt;
  • streamed rows match whole-text rows;
  • the start holds through layout changes and is released by scrolling;
  • Classic leaves Alt+G as text input.

Independent review

A fresh reviewer read 14bad5b and probed it with an out-of-tree test crate. It found no stale-row, ordering, terminal_safe, panic or Classic defects. Resolved in the second commit:

Finding	Resolution
Medium: frame cost was still linear while streaming (94 ms at 100,000 lines)	Complete lines keep their rows
Medium: Alt+G landed at the bottom when nothing was measured (inspector hiding the transcript, after Alt+L)	Explicit hold, not a measured offset
Low to medium: a resize moved the reader off the first row	Same hold
Low: the code comment and first commit message overstated what stopped being linear	Comment corrected; remaining costs listed above
Low: the Classic guard test did not press Alt+G	Added

Left as is: Alt+G on a short transcript shows "scrolled up", the same as PageUp does. A selection survives Alt+G, as with every keybinding action.

Risk and Rollback

• Risk level: medium. A bug here would show the wrong text in Next, which is why staleness is decided by comparing content and tested against fresh frames. Classic is not affected.
• Rollback plan: revert this PR. No data or format migrates. The new alt+g default binding goes with it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Nov 3, 2026 5:14am UTC