Minimap is one strip for the active pane only (migrates on focus change, reflowing both panes) and its width is a fixed 12 char cells, not a fraction of the view

[JDonaghy]

Problem

Two defects in vimcode's minimap geometry, both in the same ~70 lines of
build_screen_layout (src/render.rs:6762–6842), so they land together.

A. One minimap for the whole screen, not one per editor pane

#35 specified "a minimap on the right edge of each editor pane". What shipped is
singular and gated on the active window — twice:

// src/render.rs:6768-6772  — width reclaim
let minimap_w = window_rects.iter()
    .find(|(id, _)| *id == active_window_id)          // <-- only the active pane
    .map(|(_, r)| minimap_reserved_width(engine, r.width, char_width))
    .unwrap_or(0.0);

// src/render.rs:6783-6788  — applied to that pane alone
if is_active { (rect.width - minimap_w).max(0.0) } else { rect.width }

// src/render.rs:6819-6823  — and only that pane gets a strip built
let minimap = if minimap_w > 0.0 {
    window_rects.iter().find(|(id, _)| *id == active_window_id)

and the type is singular too — ScreenLayout.minimap: Option<RenderedMinimap>
(src/render.rs:4344), documented as "for the active editor window".

Consequences, both observed in a split:

• Only one pane has a minimap; the other has none.
• The minimap migrates as you change focus, and because the width reclaim is gated on the
  same is_active flag, both panes reflow their text every time you switch panes. That is
  a worse symptom than the missing strip.

Fix: ScreenLayout.minimap becomes a collection (per WindowId), the reclaim applies to
every window rect, and the build maps over window_rects instead of find-ing the active
one. draw_minimap_strip / minimap_click_line / apply_minimap_click then iterate; the
WidgetId is already per-window (format!("minimap:{}", window_id.0)), so quadraui needs
nothing new for this part.

B. Width is a fixed character-cell count, so it is not a consistent fraction of the view

// src/render.rs:4352
pub const MINIMAP_COLS: usize = 12;

multiplied by char_width. That ties the minimap's width to the editor font size and
leaves it constant as the window grows:

• Widen the window → the strip stays 12 chars → the minimap becomes a smaller and smaller
  fraction of the view.
• Bump the editor font → the minimap gets wider, which is backwards.
• Split the window → each pane is narrower but the strip is the same absolute width, so it
  eats a much larger share of a split pane.

VS Code keeps the minimap at a consistent fraction of the editor regardless of font size or
window width.

Fix: derive the reserved width from a proportion of the pane's width, clamped to a
sensible min/max in pixels, and stop multiplying by char_width. Keep MINIMAP_MIN_TEXT_COLS
as the suppression floor — that part is right.

The exact target fraction should be measured against VS Code rather than guessed; match
what VS Code actually renders at a couple of window widths and font sizes and pin it in a
test. Note VS Code's own minimap width is independent of the editor font, which is the
property that matters most here.

Ordering

minimap_reserved_width is the single source of truth both backends and
build_screen_layout read (that was the point of #35's design), so B is a change to that one
function plus the constant — do not reintroduce a second width computation in a backend.

Acceptance

• In a :vsplit, both panes show their own minimap over their own buffer.
• Switching focus between panes does not change either pane's text width — assert the
  window rects are identical across a focus change with the minimap on.
• The reserved width is unchanged when the editor font size changes, and scales with pane
  width — both asserted, not eyeballed.
• :set nominimap still reclaims exactly the reserved width in every pane
  (nominimap_widens_the_editor_by_exactly_the_reserved_width at src/render.rs:16305
  extended to the split case).
• The #35 platform-neutrality gate still holds: grep -rn 'minimap' src/gtk/ src/tui_main/
  returns only call sites and rect plumbing.

Related

• Minimap (code overview) — GTK font scaling, TUI braille, quadraui-owned logic, on/off setting #35 — parent; this is scope it specified (each editor pane) but did not deliver.
• quadraui minimap pitch/clipping issue (filed alongside) — different defect, and it is what
  makes the overflow in a split so visible. That fix needs a pin bump to reach vimcode;
  bump past it as part of this work rather than leaving it merged-but-unreachable, the way
  quadraui#656 was.

[JDonaghy]

Coordinator Assignment

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

Briefing

Issue #722: Minimap is one strip for the active pane only (migrates on focus change, reflowing both panes) and its width is a fixed 12 char cells, not a fraction of the view

Problem

Two defects in vimcode's minimap geometry, both in the same ~70 lines of
build_screen_layout (src/render.rs:6762–6842), so they land together.

A. One minimap for the whole screen, not one per editor pane

#35 specified "a minimap on the right edge of each editor pane". What shipped is
singular and gated on the active window — twice:

// src/render.rs:6768-6772  — width reclaim
let minimap_w = window_rects.iter()
    .find(|(id, _)| *id == active_window_id)          // <-- only the active pane
    .map(|(_, r)| minimap_reserved_width(engine, r.width, char_width))
    .unwrap_or(0.0);

// src/render.rs:6783-6788  — applied to that pane alone
if is_active { (rect.width - minimap_w).max(0.0) } else { rect.width }

// src/render.rs:6819-6823  — and only that pane gets a strip built
let minimap = if minimap_w > 0.0 {
    window_rects.iter().find(|(id, _)| *id == active_window_id)

and the type is singular too — ScreenLayout.minimap: Option<RenderedMinimap>
(src/render.rs:4344), documented as "for the active editor window".

Consequences, both observed in a split:

• Only one pane has a minimap; the other has none.
• The minimap migrates as you change focus, and because the width reclaim is gated on the
  same is_active flag, both panes reflow their text every time you switch panes. That is
  a worse symptom than the missing strip.

Fix: ScreenLayout.minimap becomes a collection (per WindowId), the reclaim applies to
every window rect, and the build maps over window_rects instead of find-ing the active
one. draw_minimap_strip / minimap_click_line / apply_minimap_click then iterate; the
WidgetId is already per-window (format!("minimap:{}", window_id.0)), so quadraui needs
nothing new for this part.

B. Width is a fixed character-cell count, so it is not a consistent fraction of the view

// src/render.rs:4352
pub const MINIMAP_COLS: usize = 12;

multiplied by char_width. That ties the minimap's width to the editor font size and
leaves it constant as the window grows:

• Widen the window → the strip stays 12 chars → the minimap becomes a smaller and smaller
  fraction of the view.
• Bump the editor font → the minimap gets wider, which is backwards.
• Split the window → each pane is narrower but the strip is the same absolute width, so it
  eats a much larger share of a split pane.

VS Code keeps the minimap at a consistent fraction of the editor regardless of font size or
window width.

Fix: derive the reserved width from a proportion of the pane's width, clamped to a
sensible min/max in pixels, and stop multiplying by char_width. Keep MINIMAP_MIN_TEXT_COLS
as the suppression floor — that part is right.

The exact target fraction should be measured against VS Code rather than guessed; match
what VS Code actually renders at a couple of window widths and font sizes and pin it in a
test. Note VS Code's own minimap width is independent of the editor font, which is the
property that matters most here.

Ordering

minimap_reserved_width is the single source of truth both backends and
build_screen_layout read (that was the point of #35's design), so B is a change to that one
function plus the constant — do not reintroduce a second width computation in a backend.

Acceptance

• In a :vsplit, both panes show their own minimap over their own buffer.
• Switching focus between panes does not change either pane's text width — assert the
  window rects are identical across a focus change with the minimap on.
• The reserved width is unchanged when the editor font size changes, and scales with pane
  width — both asserted, not eyeballed.
• :set nominimap still reclaims exactly the reserved width in every pane
  (nominimap_widens_the_editor_by_exactly_the_reserved_width at src/render.rs:16305
  extended to the split case).
• The #35 platform-neutrality gate still holds: grep -rn 'minimap' src/gtk/ src/tui_main/
  returns only call sites and rect plumbing.

Related

• Minimap (code overview) — GTK font scaling, TUI braille, quadraui-owned logic, on/off setting #35 — parent; this is scope it specified (each editor pane) but did not deliver.
• quadraui minimap pitch/clipping issue (filed alongside) — different defect, and it is what
  makes the overflow in a split so visible. That fix needs a pin bump to reach vimcode;
  bump past it as part of this work rather than leaving it merged-but-unreachable, the way
  quadraui#656 was.

[JDonaghy]

Coordinator: Assignment Complete

Machine: dell64
Status: done
Exit code: 0
Duration: 23m 56s
Log: /home/john/.coord/logs/2c118923a2d0.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: dell64
Status: done
Exit code: 0
Duration: 2m 35s
Log: /home/john/.coord/logs/0aa5e88a984d.log

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Verdict: request-changes

Review findings

Blocking findings

• src/render.rs (minimap_reserved_width, the new MINIMAP_MIN_COLS/MINIMAP_MAX_COLS constants around line 4415-4426): the clamp bounds are still expressed as MINIMAP_MIN_COLS * cw / MINIMAP_MAX_COLS * cw, i.e. multiplied by char_width, even though the un-clamped want = rect_width * MINIMAP_WIDTH_FRACTION term was correctly made font-invariant. Once a pane is narrow (or wide) enough to actually hit the clamp — exactly the "split window" scenario this issue is about — the result becomes font-dependent again, reintroducing defect B ("bump the editor font → the minimap gets wider, which is backwards") inside the clamped range. Concrete failure: a ~300px-wide split pane gives want = 300*0.15 = 45px; at char_width=8px, min_w = 6*8 = 48px → clamped up to 48px; at char_width=16px, min_w = 6*16 = 96px → clamped up to 96px. Doubling the font doubles the minimap width in this (very plausible, narrow-split) regime — precisely the backwards behaviour the issue says must not happen, and precisely the regime a multi-pane split pushes panes into. The two new tests that are supposed to pin this (minimap_reserved_width_is_unchanged_by_font_size, minimap_reserved_width_scales_with_pane_width) both deliberately choose a pane width that stays inside the unclamped middle of the band — their own comments say so ("chosen so the fraction-derived want sits inside the clamp band... so the clamp itself can't be the reason") — so this regression is not caught by the new coverage. Fix: make the floor/ceiling font-invariant (e.g. raw pixel constants for GTK, not COLS * char_width), and add a test that exercises the clamped region across two font sizes.

• No driver-tier (TuiDriver/GtkDriver) black-box test asserts on painted output for the core split-pane symptoms this issue is about, contrary to this repo's CLAUDE.md Testing section ("MANDATORY... reject a black-box test that asserts a ScreenLayout field is populated... The assertion must read painted content — screen text, screen_contains, or pixels"). All the new tests for defect A — split_gives_every_pane_its_own_minimap_over_its_own_buffer, focus_change_does_not_move_either_panes_text_width, nominimap_widens_every_pane_in_a_split_by_exactly_its_reserved_width — live in src/render.rs's pure build_screen_layout unit-test module (render_engine(), no paint step) and only assert on ScreenLayout struct fields (.minimap.len(), .total_buffer_lines, .rect.width, .text_viewport_cols). That is exactly the anti-pattern CLAUDE.md calls out by name (the ScreenLayout.picker story: layout populated correctly on GTK for months while nothing painted it). The one GTK driver test that does paint pixels and check them (minimap_paints_a_strip_whose_width_matches_reserved_width in src/gtk/testing.rs) only exercises a single, unsplit window — it was updated for the Vec API shape but not extended to a split. No test paints a :vsplit with two minimaps and checks pixels/screen_contains for both strips, and none paints across a focus change and diffs the two frames — the "migrates on focus change, reflowing both panes" symptom (called out in the issue as "a worse symptom than the missing strip") has zero painted-content coverage. (The pre-existing snapshot_split_panes TUI insta snapshot incidentally changed to show braille dots in both panes now, which is welcome corroborating evidence, but it predates this PR, wasn't written for this defect, doesn't cover the focus-change symptom, and isn't called out in the diff as the RED-first-verified black-box test the repo's testing policy asks for.)

Non-blocking concerns

• src/gtk/click.rs: clicking an inactive pane's minimap now correctly resolves and scrolls/repositions the cursor of that (unfocused) window (apply_minimap_click picks the right window_id), but nothing consumes the window_id in the returned ClickTarget::Minimap(window_id, line) to actually shift engine focus to that pane (grepped — no match site destructures ClickTarget::Minimap anywhere). The result: a click on a background pane's minimap moves that pane's scroll/cursor without ever focusing it, which will feel odd once users can reach a non-active pane's minimap at all (previously impossible, since only the active pane had one). Not required by the issue's acceptance criteria, but likely a near-term follow-up.
• MINIMAP_WIDTH_FRACTION = 0.15 is justified only by a code comment claiming "its ~120px strip over a ~800px editor pane at default settings is ~15%" — no methodology or citation, and the new tests (minimap_reserved_width_scales_with_pane_width, _is_unchanged_by_font_size) only check the formula's internal self-consistency (e.g. narrow == 60.0 * MINIMAP_WIDTH_FRACTION), not that 0.15 matches an actual observed VS Code measurement. The issue explicitly asked for the fraction to be "measured against VS Code rather than guessed... and pin it in a test" — as shipped, the pin is on the formula, not on a verified real-world number.

Nits

• The doc comments at all three backend call sites of draw_minimap_strip — src/gtk/mod.rs:8461, src/tui_main/render_impl.rs:554, src/tui_main/shell_app.rs:1472 — still read "minimap strip on the active window's right edge". They're stale after Minimap is one strip for the active pane only (migrates on focus change, reflowing both panes) and its width is a fixed 12 char cells, not a fraction of the view #722 (it's now every window's edge) and none were touched by this diff, even though this PR is exactly what invalidated them.
• Several TUI snapshot diffs are unrelated to minimap geometry (e.g. "Spaces: 4" → "LF Spaces: 4" in command_line.snap, insert_mode.snap, line_numbers.snap, normal_mode.snap, visual_selection.snap, split_panes.snap) and ride along with the quadraui pin bump. Plausibly legitimate upstream changes pulled in by the rev bump (per the issue's own instruction to bump past the quadraui minimap fix), but worth a sentence in the PR description confirming they were reviewed/expected rather than an accidental side effect, since they touch UI outside the minimap.

[JDonaghy]

Review Complete — ⚠️ Changes Requested

Reviewer findings could not be posted directly to PR #725 (gh pr review was rejected — likely a self-review restriction). Findings are reproduced here.

Note: a completion comment was posted earlier but findings could not be extracted at that time. These are the retroactive findings.

Blocking findings

• src/render.rs (minimap_reserved_width, the new MINIMAP_MIN_COLS/MINIMAP_MAX_COLS constants around line 4415-4426): the clamp bounds are still expressed as MINIMAP_MIN_COLS * cw / MINIMAP_MAX_COLS * cw, i.e. multiplied by char_width, even though the un-clamped want = rect_width * MINIMAP_WIDTH_FRACTION term was correctly made font-invariant. Once a pane is narrow (or wide) enough to actually hit the clamp — exactly the "split window" scenario this issue is about — the result becomes font-dependent again, reintroducing defect B ("bump the editor font → the minimap gets wider, which is backwards") inside the clamped range. Concrete failure: a ~300px-wide split pane gives want = 300*0.15 = 45px; at char_width=8px, min_w = 6*8 = 48px → clamped up to 48px; at char_width=16px, min_w = 6*16 = 96px → clamped up to 96px. Doubling the font doubles the minimap width in this (very plausible, narrow-split) regime — precisely the backwards behaviour the issue says must not happen, and precisely the regime a multi-pane split pushes panes into. The two new tests that are supposed to pin this (minimap_reserved_width_is_unchanged_by_font_size, minimap_reserved_width_scales_with_pane_width) both deliberately choose a pane width that stays inside the unclamped middle of the band — their own comments say so ("chosen so the fraction-derived want sits inside the clamp band... so the clamp itself can't be the reason") — so this regression is not caught by the new coverage. Fix: make the floor/ceiling font-invariant (e.g. raw pixel constants for GTK, not COLS * char_width), and add a test that exercises the clamped region across two font sizes.
• No driver-tier (TuiDriver/GtkDriver) black-box test asserts on painted output for the core split-pane symptoms this issue is about, contrary to this repo's CLAUDE.md Testing section ("MANDATORY... reject a black-box test that asserts a ScreenLayout field is populated... The assertion must read painted content — screen text, screen_contains, or pixels"). All the new tests for defect A — split_gives_every_pane_its_own_minimap_over_its_own_buffer, focus_change_does_not_move_either_panes_text_width, nominimap_widens_every_pane_in_a_split_by_exactly_its_reserved_width — live in src/render.rs's pure build_screen_layout unit-test module (render_engine(), no paint step) and only assert on ScreenLayout struct fields (.minimap.len(), .total_buffer_lines, .rect.width, .text_viewport_cols). That is exactly the anti-pattern CLAUDE.md calls out by name (the ScreenLayout.picker story: layout populated correctly on GTK for months while nothing painted it). The one GTK driver test that does paint pixels and check them (minimap_paints_a_strip_whose_width_matches_reserved_width in src/gtk/testing.rs) only exercises a single, unsplit window — it was updated for the Vec API shape but not extended to a split. No test paints a :vsplit with two minimaps and checks pixels/screen_contains for both strips, and none paints across a focus change and diffs the two frames — the "migrates on focus change, reflowing both panes" symptom (called out in the issue as "a worse symptom than the missing strip") has zero painted-content coverage. (The pre-existing snapshot_split_panes TUI insta snapshot incidentally changed to show braille dots in both panes now, which is welcome corroborating evidence, but it predates this PR, wasn't written for this defect, doesn't cover the focus-change symptom, and isn't called out in the diff as the RED-first-verified black-box test the repo's testing policy asks for.)

Non-blocking concerns

• src/gtk/click.rs: clicking an inactive pane's minimap now correctly resolves and scrolls/repositions the cursor of that (unfocused) window (apply_minimap_click picks the right window_id), but nothing consumes the window_id in the returned ClickTarget::Minimap(window_id, line) to actually shift engine focus to that pane (grepped — no match site destructures ClickTarget::Minimap anywhere). The result: a click on a background pane's minimap moves that pane's scroll/cursor without ever focusing it, which will feel odd once users can reach a non-active pane's minimap at all (previously impossible, since only the active pane had one). Not required by the issue's acceptance criteria, but likely a near-term follow-up.
• MINIMAP_WIDTH_FRACTION = 0.15 is justified only by a code comment claiming "its ~120px strip over a ~800px editor pane at default settings is ~15%" — no methodology or citation, and the new tests (minimap_reserved_width_scales_with_pane_width, _is_unchanged_by_font_size) only check the formula's internal self-consistency (e.g. narrow == 60.0 * MINIMAP_WIDTH_FRACTION), not that 0.15 matches an actual observed VS Code measurement. The issue explicitly asked for the fraction to be "measured against VS Code rather than guessed... and pin it in a test" — as shipped, the pin is on the formula, not on a verified real-world number.

Nits

• The doc comments at all three backend call sites of draw_minimap_strip — src/gtk/mod.rs:8461, src/tui_main/render_impl.rs:554, src/tui_main/shell_app.rs:1472 — still read "minimap strip on the active window's right edge". They're stale after Minimap is one strip for the active pane only (migrates on focus change, reflowing both panes) and its width is a fixed 12 char cells, not a fraction of the view #722 (it's now every window's edge) and none were touched by this diff, even though this PR is exactly what invalidated them.
• Several TUI snapshot diffs are unrelated to minimap geometry (e.g. "Spaces: 4" → "LF Spaces: 4" in command_line.snap, insert_mode.snap, line_numbers.snap, normal_mode.snap, visual_selection.snap, split_panes.snap) and ride along with the quadraui pin bump. Plausibly legitimate upstream changes pulled in by the rev bump (per the issue's own instruction to bump past the quadraui minimap fix), but worth a sentence in the PR description confirming they were reviewed/expected rather than an accidental side effect, since they touch UI outside the minimap.

[JDonaghy]

Coordinator: Assignment Complete

Machine: dell64
Status: done
Exit code: 0
Duration: 25m 46s
Log: /home/john/.coord/logs/c12505cfac8f.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: dell64
Status: done
Exit code: 0
Duration: 5m 22s
Log: /home/john/.coord/logs/7ad829c56d3b.log

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Verdict: approve

Review findings

Blocking findings

None.

Non-blocking concerns

• src/gtk/testing.rs (focus_change_does_not_move_either_panes_text, the painted_rects helper): despite the name and the doc comment's "diffs the two painted window rects", the helper reads h.screen_layout.borrow()...windows[].rect — a ScreenLayout struct field computed during layout, not sampled from the painted Cairo surface. It does call h.driver.render() first (a real repaint happens), but the assertion itself is still state, not painted content, which is the exact anti-pattern this repo's CLAUDE.md "Testing (CRITICAL)" section singles out ("never on state being populated... must read painted content — screen text, screen_contains, or pixels"). That said, I'm not blocking on this: the same defect-B acceptance criterion ("focus change must not move either pane's text") is also covered by a genuinely painted-content test on the TUI side in this same commit — focus_change_does_not_move_either_panes_text_via_shell_app reads driver.screen() text and the cursor's painted background colour via driver.style_at, with an explicit vacuous-pass guard (asserts the cursor cell actually relocated). And defect A (two independent strips) is covered with real pixel sampling on both backends (split_paints_two_independent_minimap_strips via h.driver.pixel(x, y) on GTK, braille-in-driver.screen() on TUI). So the previously-blocking gap — zero driver-tier tests reading painted output — is resolved; this GTK test is just weaker than its own doc comment claims. Worth tightening in a follow-up (e.g. diff a sampled pixel column near each pane's text start, mirroring the sibling pixel test) but not worth another fix round.

Nits

None beyond the above.

---

Verified against the two previously-blocking findings:

1. Font-dependent clamp bounds (defect B inside the clamp band). Fixed correctly. minimap_reserved_width now branches on the existing char_width > 1.0 GTK-vs-TUI convention already used elsewhere in render.rs (e.g. the bar_width conversion): GTK gets fixed-pixel MINIMAP_MIN_PX/MINIMAP_MAX_PX (48px/240px) that do not scale with char_width at all; TUI's MINIMAP_MIN_COLS/MINIMAP_MAX_COLS are unaffected and were already font-invariant since TUI always passes char_width == 1.0. I hand-checked the arithmetic from the review finding's own repro (300px pane, 6px vs 8px chars): pre-fix this diverges (45 vs 48), post-fix both clamp to the fixed 48px floor. Same check on the ceiling side (2000px pane, 8px vs 16px chars: pre-fix 240 vs 300, post-fix both 240px). The two new tests (minimap_reserved_width_clamp_floor_is_font_invariant, minimap_reserved_width_clamp_ceiling_is_font_invariant) pin exactly this regime and their own sanity assertions confirm they're actually hitting the clamp (not the unclamped middle the round-1 tests stuck to). Commit message states RED-first verification against the reintroduced bug.

2. No driver-tier black-box test reading painted output for the split-pane symptoms. Resolved. Four new tests were added across both backends: GTK's split_paints_two_independent_minimap_strips (real Cairo pixel sampling, h.driver.pixel), TUI's split_paints_two_independent_minimap_strips_via_shell_app (braille glyphs located in driver.screen() text, split left/right by the buffer's own "line " text columns), TUI's focus_change_does_not_move_either_panes_text_via_shell_app (painted text column + cursor-cell background colour via driver.style_at, with a non-vacuous-pass guard), and GTK's focus_change_does_not_move_either_panes_text (see the non-blocking note above re: state vs. pixels). Commit message and doc comments state RED-first verification by hand-reverting the fix.

Also checked:

• Platform-neutrality gate: grep -rn 'minimap' src/gtk/ src/tui_main/ still returns only call sites, test assertions on results, and rect plumbing — no width/clamp arithmetic duplicated into a backend file.
• No CLAUDE.md changes in this diff (coordinator-owned doc rule N/A here).
• The quadraui pin bump (bcf3d3b → 69fd9cd) and the per-pane Vec<RenderedMinimap> / apply_minimap_click focus-follows-click behaviour were already reviewed/addressed in the prior round (a478421) and are unchanged by this round's commit (3cb7281), which touches only src/gtk/mod.rs, src/gtk/testing.rs, src/render.rs, src/tui_main/render_impl.rs, src/tui_main/shell_app.rs — confirmed via git show 3cb7281 --stat.

Approving.

[JDonaghy]

Review Complete — ✅ Approved

Reviewer findings could not be posted directly to PR #725 (gh pr review was rejected — likely a self-review restriction). Findings are reproduced here.

Note: a completion comment was posted earlier but findings could not be extracted at that time. These are the retroactive findings.

Blocking findings

None.

Non-blocking concerns

• src/gtk/testing.rs (focus_change_does_not_move_either_panes_text, the painted_rects helper): despite the name and the doc comment's "diffs the two painted window rects", the helper reads h.screen_layout.borrow()...windows[].rect — a ScreenLayout struct field computed during layout, not sampled from the painted Cairo surface. It does call h.driver.render() first (a real repaint happens), but the assertion itself is still state, not painted content, which is the exact anti-pattern this repo's CLAUDE.md "Testing (CRITICAL)" section singles out ("never on state being populated... must read painted content — screen text, screen_contains, or pixels"). That said, I'm not blocking on this: the same defect-B acceptance criterion ("focus change must not move either pane's text") is also covered by a genuinely painted-content test on the TUI side in this same commit — focus_change_does_not_move_either_panes_text_via_shell_app reads driver.screen() text and the cursor's painted background colour via driver.style_at, with an explicit vacuous-pass guard (asserts the cursor cell actually relocated). And defect A (two independent strips) is covered with real pixel sampling on both backends (split_paints_two_independent_minimap_strips via h.driver.pixel(x, y) on GTK, braille-in-driver.screen() on TUI). So the previously-blocking gap — zero driver-tier tests reading painted output — is resolved; this GTK test is just weaker than its own doc comment claims. Worth tightening in a follow-up (e.g. diff a sampled pixel column near each pane's text start, mirroring the sibling pixel test) but not worth another fix round.

Nits

None beyond the above.

---

Verified against the two previously-blocking findings:

1. Font-dependent clamp bounds (defect B inside the clamp band). Fixed correctly. minimap_reserved_width now branches on the existing char_width > 1.0 GTK-vs-TUI convention already used elsewhere in render.rs (e.g. the bar_width conversion): GTK gets fixed-pixel MINIMAP_MIN_PX/MINIMAP_MAX_PX (48px/240px) that do not scale with char_width at all; TUI's MINIMAP_MIN_COLS/MINIMAP_MAX_COLS are unaffected and were already font-invariant since TUI always passes char_width == 1.0. I hand-checked the arithmetic from the review finding's own repro (300px pane, 6px vs 8px chars): pre-fix this diverges (45 vs 48), post-fix both clamp to the fixed 48px floor. Same check on the ceiling side (2000px pane, 8px vs 16px chars: pre-fix 240 vs 300, post-fix both 240px). The two new tests (minimap_reserved_width_clamp_floor_is_font_invariant, minimap_reserved_width_clamp_ceiling_is_font_invariant) pin exactly this regime and their own sanity assertions confirm they're actually hitting the clamp (not the unclamped middle the round-1 tests stuck to). Commit message states RED-first verification against the reintroduced bug.

2. No driver-tier black-box test reading painted output for the split-pane symptoms. Resolved. Four new tests were added across both backends: GTK's split_paints_two_independent_minimap_strips (real Cairo pixel sampling, h.driver.pixel), TUI's split_paints_two_independent_minimap_strips_via_shell_app (braille glyphs located in driver.screen() text, split left/right by the buffer's own "line " text columns), TUI's focus_change_does_not_move_either_panes_text_via_shell_app (painted text column + cursor-cell background colour via driver.style_at, with a non-vacuous-pass guard), and GTK's focus_change_does_not_move_either_panes_text (see the non-blocking note above re: state vs. pixels). Commit message and doc comments state RED-first verification by hand-reverting the fix.

Also checked:

• Platform-neutrality gate: grep -rn 'minimap' src/gtk/ src/tui_main/ still returns only call sites, test assertions on results, and rect plumbing — no width/clamp arithmetic duplicated into a backend file.
• No CLAUDE.md changes in this diff (coordinator-owned doc rule N/A here).
• The quadraui pin bump (bcf3d3b → 69fd9cd) and the per-pane Vec<RenderedMinimap> / apply_minimap_click focus-follows-click behaviour were already reviewed/addressed in the prior round (a478421) and are unchanged by this round's commit (3cb7281), which touches only src/gtk/mod.rs, src/gtk/testing.rs, src/render.rs, src/tui_main/render_impl.rs, src/tui_main/shell_app.rs — confirmed via git show 3cb7281 --stat.

Approving.