sl0ppi.git/pi-ext/NOTES.md, branch main

slop-tool-boxes: stop full-redraw flicker on tall, top-clipped active boxes

2026-08-12T17:34:35Z

An in-flight tool box taller than the viewport (top scrolled off-screen) flickered violently the whole time it was active. Cause: the working spinner (and pi's default spinner) drive ui.requestRender() at ~10-16fps, and the active call slot recomputed a wall-clock pulse color every render, recoloring the TOP border. tui.js falls back to a full-screen redraw when the first changed line is above the viewport (firstChanged < prevViewportTop), so every spinner tick = one full clear+repaint. Fix: once the result slot is streaming (box can be tall), freeze the call slot pulse color, caching built lines per (width, inner). The header/command is static, so the top border is byte-identical between render ticks and never triggers an above-viewport change. The pre-output phase (box still fully visible) keeps the live pulse + ticking runtime; the result slot still pulses its in-viewport bottom border. NOTES.md documents this as flicker #4. Confirmed by repro: massive flicker with the fix reverted, calm with it in.

slop-tool-boxes: dotted gray rails in-flight, solidify on finalize

2026-08-12T17:34:35Z

Bring back body side rails with an active/settled distinction: - in-flight: gray dotted (┊) rails + pulsing top/bottom borders - finalized: solid status-colored (│) rails + solid borders Rails are a STATIC per-render color (never carry the pulse), so streaming output can't recolor existing body lines -> stays flicker-safe.

slop-tool-boxes: remove animation timer; time-based pulse (fix streaming flicker)

2026-08-12T17:34:35Z

Third flicker bug: a taller-than-screen bash box flickered because the 10fps timer forced a full updateDisplay() repaint on top of the stream's own re-renders. Root fix: NEVER force a repaint. - Pulse color is now a pure function of wall-clock time (Date.now() % CYCLE_MS); no tick counter, no setInterval. Any render shows the current color. - The pulse advances only on renders that already happen: streaming output ('the stream hydrates the pulse', irregular cadence) or start/end nudges. - Silent long-running tools hold a static active color (flicker-free) rather than animating. - Also drop body side rails entirely (open-sided box); only top/bottom pulse. Self-test: restored rows never pulse, active top border advances with time, settles solid on end.

slop-tool-boxes: fix startup render storm + streaming flicker

2026-08-12T17:34:35Z

Two bugs from the pending-tool border pulse: 1. Streaming flicker: pulsing the side rails recolored every body line each frame, forcing a full-box repaint per streamed token. Now only top/bottom borders pulse; rails/body use a static status color. 2. Startup render storm (pi -c never accepts input): 'pending' was inferred from the render-time default status, so every RESTORED tool row rendered as pending -> all added to the 10fps animation set -> unbounded invalidate loop. Animation is now driven strictly by live tool_execution_start/end events keyed by toolCallId; restored rows fire no start event so they never animate. Self-test covers: restored rows don't pulse, live rows pulse only between start/end, rails static during a run.

Add .gitignore (audit/subagent artifacts) + NOTES.md flicker safety bug

2026-08-12T17:34:35Z

Record the redraw-flicker-during-write report as a tracked safety issue. Prime suspect: the 10fps pending-tool border pulse (slop-tool-boxes d3454b8) driving full-frame repaints ~10Hz (photosensitive-seizure risk band).