Render streaming assistant rows outside virtualizer

[imanolmzd-svg]

Why

We have recently changed the virtualization strategy to go from "per turn" to "per row" in #11094 and this caused the row being streamed to be virtualized too - Causing display issues as shown in the "Before" video below

Implementation

Replace the keepMounted index-based approach with a direct rendering suffix for active assistant turns. Rows belonging to the streaming turn are partitioned out of the virtualizer and rendered as plain DOM elements, eliminating measurement instability caused by rapidly growing content while preserving virtualized history for completed turns.

Screenshots / Video

Before

before-row-virt.mov

After

after-row-virt.mov

Testing

• Manual testing as shown above
• Unit tests
• Typecheck

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Incremental Review

Reviewed changes since 8c3fb65594bcecaaca2483c20be213e98b92de49 → 358c312be3fa4e940f1a8eafd49616b9c9e7156d.

New commit: refactor(transcript-rows): restrict direct partition to only the latest visible turn

The refactored partitionRows logic correctly prevents older streaming turns from being rendered in the direct (non-virtualised) suffix when a newer visible turn exists. Using visible.at(-1)?.turn to identify the candidate turn, then gating on direct.has(turn), is clean and well-scoped. The boundary scan at line 192 still requires row.type === "assistant", so a last-visible turn that has no assistant output safely falls back to fully virtual — confirmed by the existing "skips a held turn without assistant output" test.

The updated test ("does not retain an older turn after a newer visible turn") precisely captures the new invariant and the expected partition output is correct.

Files Reviewed (2 files, incremental)

• packages/kilo-vscode/webview-ui/src/context/transcript-rows.ts — logic change is correct; edge cases handled
• packages/kilo-vscode/tests/unit/transcript-rows.test.ts — test rename and updated expectations match the new behaviour

---

_{Reviewed by claude-4.6-sonnet-20260217 · 242,250 tokens}

_{Review guidance: REVIEW.md from base branch main}

[imanolmzd-svg]

Benchmark results

I benchmarked this PR at 358c312b against base 68fd8ccc in fresh isolated VS Code profiles

The scenario used a long active turn with auto-scroll paused, followed by a queued successor turn. This specifically exercised the handoff where the completed older turn should return to the virtualizer and only the latest assistant turn should render directly.

Metric	Base	PR	Change
Layout-shift events	209	147	-29.7%
Total layout-shift score	2.126	1.846	-13.1%
Unexpected shift score	1.305	1.148	-12.0%
Visible-anchor movement	852 px	717 px	-15.8%
Maximum anchor jump	95 px	103 px	+8.4%
Script time per mutation	0.159 ms	0.167 ms	+5.0%
Task time per mutation	0.665 ms	0.731 ms	+9.9%
Long tasks	0	0	unchanged

The partition behavior matched the intended design:

• While the successor was queued, the active turn remained directly rendered.
• At handoff, data-direct-count dropped to 0, returning the completed turn to virtualization.
• Once the new assistant output appeared, data-direct-count became 1 and contained only the latest turn.
• No older turn remained directly rendered after the newer turn became visible.

Overall, the PR substantially reduced layout-shift frequency, cumulative shift score, and visible-anchor movement. There was a modest scripting/task-time increase, but no long tasks or observable responsiveness regression.