fix(tui): whole frames, and stop repainting for a phrase nobody can see

[plombeer31]

"On win10, 0.4.1 UI is shaking and some line broken."

The shaking is frame tearing

Ink paints by writing a whole frame to stdout — cursor home, every line, the trailing clear. On a terminal that renders as bytes arrive, the interval between the first line and the last is an interval where the screen holds half the old frame and half the new.

This is not a Windows bug. macOS terminals coalesce hard enough to hide it, which is how a cross-platform behaviour arrived as a Windows report.

DEC private mode 2026 ("synchronized output") is the fix the terminal side already implemented: CSI ? 2026 h holds rendering until CSI ? 2026 l, so a frame appears whole or not at all. Windows Terminal has supported it since 1.15.

Every frame is now bracketed in one write — one, not three, because three would put the stream's own chunking between a marker and the frame it is meant to bracket, which is precisely what this exists to prevent.

Why unconditional is safe. An unrecognised DEC private mode is ignored — that is what "private" buys, and it is why terminals without 2026 (including conhost) have taken these bytes from other TUIs for years. There is no probe here for the same reason alt-screen.ts has none: asking costs a round trip on a stdin something else is reading, and the fallback is exactly today's behaviour. ATOMIC_AGENT_NO_SYNC_OUTPUT=1 opts out.

Why patch stdout.write rather than wrap the stream. Ink reads columns, rows and the resize event off that same object. A proxy would have to forward all of it correctly, and getting it subtly wrong breaks resize handling in a way much harder to spot than tearing. alt-screen.ts and mouse-tracking.ts already own the terminal this way.

And a repaint that was going nowhere

useRotatingPlaceholder ran its interval unconditionally — but the phrase is only drawn while the composer is empty:

const effectivePlaceholder = value.length === 0 ? (rotated ?? placeholder ?? "") : "";

So from the first character typed, the timer kept firing every four seconds — a setState at the root of the tree, a full Ink frame, to advance a string nobody could see — for the rest of the session. On a terminal that tears, that is a visible flicker every four seconds while you type, which matches the report closely.

Now gated on visibility, the same way useSpinner and useAtomField already were. The cheapest frame is the one never painted; on a tearing terminal it is also the one that cannot flicker.

The broken line is not this

That is glyph width under a non-UTF-8 Windows console code page, and #236 (fix(cli): switch Windows console to UTF-8 on startup) addresses it directly. Deliberately left alone here so the two don't collide — they're complementary.

Verification — and its limit

I do not have a Windows 10 machine. The tearing fix is reasoned and unit-tested, not observed. What the tests pin is the exact bytes reaching the terminal:

• a frame is emitted as BSU + frame + ESU in a single write
• a bare mode toggle (ESC[?25l) is left alone — no markers spent rendering nothing
• non-TTY streams are untouched, so pipes, CI and the test renderer see no markers
• the opt-out works; restore() puts the original write back, emits a closing ESU as insurance against a crash mid-update, is safe to call twice, and does not clobber a patch installed after ours

Plus, for the placeholder: nothing is scheduled while inactive, the timer stops and restarts across the transition, and the parameter defaults to active so existing callers are unchanged.

npm run lint    clean
npm test        576 passed | 2 failed (578 files)
                5971 passed | 3 skipped | 2 failed (5976 tests)

Both failures are pre-existing on main in this sandbox and unrelated (fs-glob-real, and an EACCES spawning a stub llama-server).

Someone on Windows needs to run this branch to confirm the shaking is gone. If it isn't, the next thing I'd look at is the 250 ms elapsed-clock tick in thinking-indicator.tsx, which repaints during a turn.