Retire four vimcode duplicates of logic quadraui already ships (tab scroll, measure, hit shim, split tree)

[JDonaghy]

What

Retire four pieces of vimcode that duplicate logic quadraui already ships. No behaviour change
in any of them.

Why now

These predate the current tab/split work — quadraui grew the generic version and vimcode was never
migrated. They surfaced while auditing what coord-tui should and should not copy from vimcode
(2026-08-15), and the audit's conclusion is worth recording: coord-tui will consume the quadraui
versions, so every day vimcode keeps its own is a day the two apps can diverge on identical
functionality.

Two of these are load-bearing rather than cosmetic. fit_active_scroll_offset's own doc comment
says backends MUST use it instead of the engine algorithm, because a per-tab width estimate that
mismatches actual rendering leaves the active tab off-screen — exactly the class of bug quadraui
#554 was.

Design

Duplicate	quadraui replacement
Engine::ensure_active_tab_visible (engine/windows.rs:1817)	TabBar::fit_active_scroll_offset (primitives/tab_bar.rs:180)
tab_display_width / tabs_fitting_from	TabMeasure + TabBar::layout
TabBarHitRegion / TabBarClickTarget (engine/mod.rs:1182-1209)	TabBarLayout.hit_regions + TabBarHit
core/window.rs's split tree — its own SplitDirection, ratio, set_ratio_at_index, divider geometry	quadraui::SplitTree

The third is already labelled as temporary in vimcode's own source
(src/render.rs:494): the shim exists "Until TUI / GTK / Win-GUI migrate to consume TabBarLayout
directly". This issue is that migration.

⚠ SplitDirection is inverted between the two crates. vimcode's Horizontal means split
top/bottom (core/window.rs:9-13); quadraui's Horizontal means panes side-by-side, first =
left (primitives/split.rs:40-49). A mechanical swap will silently rotate every split by 90°, and
it compiles. Convert deliberately, and assert orientation on a rendered grid rather than on the
enum name.

Sequence them as four separate commits — or four separate PRs — so a regression is bisectable to
one replacement.

Acceptance criteria

• None of the four duplicates remain in src/.
• The active tab is still scrolled into view after switching to an off-screen tab.
• Wide-glyph tab labels (CJK / emoji) still measure correctly — the quadraui #448-G: GTK scroll wheel scrolls editor text in the wrong (inverted) direction #554 case.
• Splits open in the same orientation as before, proven by a screen assertion, not by the enum.
• Divider drag still resizes in the same direction and clamps the same way.
• cargo build && cargo test EXIT=0 after each step.

Files

• src/core/engine/windows.rs
• src/core/engine/mod.rs
• src/core/window.rs
• src/render.rs
• src/tui_main/render_impl.rs
• src/gtk/click.rs

Out of scope

• Any behaviour change.
• The preview-tier and harness migrations, filed separately.

[JDonaghy]

Coordinator Assignment

Machine: precision
Repo: vimcode
Files: (unspecified)
Do not touch: (nothing else in flight)

Briefing

Issue #660: Retire four vimcode duplicates of logic quadraui already ships (tab scroll, measure, hit shim, split tree)

What

Retire four pieces of vimcode that duplicate logic quadraui already ships. No behaviour change
in any of them.

Why now

These predate the current tab/split work — quadraui grew the generic version and vimcode was never
migrated. They surfaced while auditing what coord-tui should and should not copy from vimcode
(2026-08-15), and the audit's conclusion is worth recording: coord-tui will consume the quadraui
versions, so every day vimcode keeps its own is a day the two apps can diverge on identical
functionality.

Two of these are load-bearing rather than cosmetic. fit_active_scroll_offset's own doc comment
says backends MUST use it instead of the engine algorithm, because a per-tab width estimate that
mismatches actual rendering leaves the active tab off-screen — exactly the class of bug quadraui
#554 was.

Design

Duplicate	quadraui replacement
Engine::ensure_active_tab_visible (engine/windows.rs:1817)	TabBar::fit_active_scroll_offset (primitives/tab_bar.rs:180)
tab_display_width / tabs_fitting_from	TabMeasure + TabBar::layout
TabBarHitRegion / TabBarClickTarget (engine/mod.rs:1182-1209)	TabBarLayout.hit_regions + TabBarHit
core/window.rs's split tree — its own SplitDirection, ratio, set_ratio_at_index, divider geometry	quadraui::SplitTree

The third is already labelled as temporary in vimcode's own source
(src/render.rs:494): the shim exists "Until TUI / GTK / Win-GUI migrate to consume TabBarLayout
directly". This issue is that migration.

⚠ SplitDirection is inverted between the two crates. vimcode's Horizontal means split
top/bottom (core/window.rs:9-13); quadraui's Horizontal means panes side-by-side, first =
left (primitives/split.rs:40-49). A mechanical swap will silently rotate every split by 90°, and
it compiles. Convert deliberately, and assert orientation on a rendered grid rather than on the
enum name.

Sequence them as four separate commits — or four separate PRs — so a regression is bisectable to
one replacement.

Acceptance criteria

• None of the four duplicates remain in src/.
• The active tab is still scrolled into view after switching to an off-screen tab.
• Wide-glyph tab labels (CJK / emoji) still measure correctly — the quadraui #448-G: GTK scroll wheel scrolls editor text in the wrong (inverted) direction #554 case.
• Splits open in the same orientation as before, proven by a screen assertion, not by the enum.
• Divider drag still resizes in the same direction and clamps the same way.
• cargo build && cargo test EXIT=0 after each step.

Files

• src/core/engine/windows.rs
• src/core/engine/mod.rs
• src/core/window.rs
• src/render.rs
• src/tui_main/render_impl.rs
• src/gtk/click.rs

Out of scope

• Any behaviour change.
• The preview-tier and harness migrations, filed separately.

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: 6m 23s
Log: /home/john/.coord/logs/fef482930593.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: 3m 16s
Log: /home/john/.coord/logs/c61bc243ebf9.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: —

Summary

Verdict: approve

Review findings

Blocking findings

None.

Non-blocking concerns

• src/core/engine/windows.rs:2043-2048 (new doc comment on ensure_active_tab_visible) states as present fact that "GTK/Win-GUI compute their own pixel-accurate offset via the same quadraui helper and write it back through set_tab_scroll_offset instead of relying on this method." I checked the rest of the tree at this commit: set_tab_scroll_offset (defined at windows.rs:2103) has exactly one caller in the whole repo, and it's a unit test (src/tui_main/render_impl.rs:2462) — no GTK or TUI backend code path actually calls it. GTK's tab bar does use pixel-accurate hit regions from Backend::tab_bar_layout for click hit-testing, but nothing persists a corrected offset back into engine state; render.rs still reads g.tab_scroll_offset (the char-cell value this method computes) directly for painting. The comment describes an aspirational/target architecture (matching quadraui's own module doc for fit_active_scroll_offset) as if it's already wired up in vimcode today. Worth a follow-up tweak so a future reader doesn't assume the pixel-accurate correction loop already exists — relevant since the next duplicate to retire (TabBarHitRegion/TabBarClickTarget) touches exactly this area.

Nits

• Behavioral micro-difference (harmless, arguably a fix): the old inlined algorithm would index group.tabs[active] unconditionally in the backwards walk, so calling ensure_active_tab_visible on a group with 0 tabs and active == 0 would panic on tab_display_width's &group.tabs[i]. quadraui::TabBar::fit_active_scroll_offset explicitly guards tab_count == 0 || active >= tab_count and returns 0 without invoking the measurer, so this same call is now panic-safe. Not a regression, not exercised by the existing test suite either way, and not worth blocking on — just noting it since the commit message frames this as strictly "no behaviour change."

Summary

Small, well-scoped diff: Engine::ensure_active_tab_visible now delegates to quadraui::TabBar::fit_active_scroll_offset (confirmed identical algorithm and matching signature by reading ~/src/quadraui/quadraui/src/primitives/tab_bar.rs:180-217, checked out at the pinned commit 6a8a959 per quadraui-pin.txt), and the now-dead tabs_fitting_from is removed with no other references left in the tree. tab_display_width is correctly kept (vimcode-specific label formatting, not quadraui logic). Borrow pattern (immutable group ref used inside the closure alongside self.tab_display_width) mirrors the pre-existing code and compiles by the same reasoning. This is explicitly staged as 1-of-4 duplicates per the issue's own "sequence as separate commits/PRs" instruction, so the other three legitimately being out of scope here is correct, not a scope violation. Per CLAUDE.md, pure refactors with no behaviour change are exempt from the black-box driver-test requirement provided the PR says so — both the issue text ("No behaviour change in any of them") and the commit message say so explicitly, and the change is covered by pre-existing unmodified unit tests (test_tab_scroll_offset_initial, test_tab_scroll_offset_ensure_active_visible, test_tab_scroll_offset_scrolls_back_on_prev, etc. in src/core/engine/tests.rs) that exercise this exact method. I did not run cargo build/cargo test myself (out of scope for this review per instructions) but found no reason to doubt the commit's claim that all 11 relevant tests pass unmodified. No security concerns, no platform-neutrality violations — if anything this change reduces vimcode-side duplication per the repo's stated north-star goal.