Adopt quadraui FolderPickerController — 3.5-month-old adoption, and IRREDUCIBLE_SURFACE.md has since recorded the gap as a constraint

[JDonaghy]

Problem — a 3.5-month-old adoption that was never done, and has since been recorded as a constraint

quadraui/src/compose/folder_picker.rs (FolderPickerController) landed 2026-05-25 (6946fcf, quadraui#166). Its module doc says exactly what was supposed to happen next:

"Extracted verbatim from vimcode's TUI-local FolderPickerState (src/tui_main/mod.rs, ~285 lines). After the quadraui PR lands, vimcode removes the TUI-local code and rewires both TUI and GTK."

vimcode today:

• struct FolderPickerState still at src/tui_main/mod.rs:251 (to ~343)
• src/render.rs:3702 route_folder_picker_key
• src/tui_main/render_impl.rs:502, src/tui_main/shell_app.rs:3948, FrameOp::FolderPicker
• 94 references across 7 files. Zero references to FolderPickerController. No vimcode issue has ever mentioned it.

It got worse than "not done". docs/IRREDUCIBLE_SURFACE.md:24 now records the TUI-only folder picker as Irreducible — one of only three verdicts in that document — on the grounds that GTK uses a native GtkFileChooser. A shipped, 3.5-month-old cross-backend controller contradicts that verdict. The gap was canonised as a constraint, which is worse than leaving it open, because planning now routes around it.

Fix

1. Adopt quadraui::compose::FolderPickerController on the TUI; delete FolderPickerState and its 94 references.
2. Wire GTK to the same controller so the folder picker is one implementation. PlatformServices (quadraui/src/backend.rs:2136) exposes file open/save but not directory select — if the controller needs a native-select escape hatch on GTK, use it there, but the picker UI and key routing must be shared.
3. Correct docs/IRREDUCIBLE_SURFACE.md: strike the folder-picker row from the irreducible list and record why the verdict was wrong (the aggregation post-dated the controller by 3 months and did not check upstream). This is the point of the document — a wrong entry there misdirects every future planning pass.

If adoption turns out to be genuinely blocked by a controller gap, file the quadraui issue and leave this open behind it — do not close it. See GOALS.md's milestone-discipline rule; #47 is the cautionary example.

Acceptance

• Black-box tests required, both backends. TUI via quadraui::tui::testing::driver_with_shell; GTK via GtkDriver. Assert on rendered output — locate targets with find/screen_contains, never hardcode coordinates.
• State in the PR that the new tests fail against unfixed develop.
• cargo test, cargo clippy -- -D warnings, cargo fmt pass.

[JDonaghy]

Before you start: re-verify the citations, do not trust them

Every file:line in this issue was measured on develop @ ee26268 (2026-09-04) by an audit, not by reading the tree you will check out.

They will have drifted by the time you pick this up. This issue sits in a serialised chain, and several entries ahead of it move code on purpose — #812 deletes ~1,300 lines from src/render.rs, #813 retypes fields in src/app.rs, #785 and #814 delete whole functions. Anything filed after those shifts.

So:

• Locate by symbol, not by line. grep -n "fn build_screen_layout_with_breadcrumb_row" src/render.rs, not "go to line 12886". GOALS.md already carries this rule for the same reason — it cites no line numbers on purpose.
• Re-measure any count before you use it. Line totals here came from python3 scripts/prod_lines.py and scripts/native_lines.py at a named revision. Re-run them rather than quoting the number in this issue. GOALS.md: "regenerate them with the script rather than trusting the table."
• Size the branch from what you find, not from the figure here. The counts are evidence that a problem is large, not estimates of a diff.

If a finding does not reproduce, say so — that is a useful result

This issue was generated from an automated audit. Some of its claims are wrong. Today alone, two confident findings in the same audit chain did not survive checking: a "1,671 byte-identical lines" figure measured out at ~85, and a "zero commits of pin lag" reading was taken against a stale local ref and was actually 42.

If the problem described here is already fixed, was never real, or is real but different from the description: comment with what you actually found and stop. Do not implement around a bad premise to make the issue closeable. A correction is worth more than a merged PR built on a wrong claim.

[JDonaghy]

Coordinator Assignment

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

Briefing

Issue #815: Adopt quadraui FolderPickerController — 3.5-month-old adoption, and IRREDUCIBLE_SURFACE.md has since recorded the gap as a constraint

Problem — a 3.5-month-old adoption that was never done, and has since been recorded as a constraint

quadraui/src/compose/folder_picker.rs (FolderPickerController) landed 2026-05-25 (6946fcf, quadraui#166). Its module doc says exactly what was supposed to happen next:

"Extracted verbatim from vimcode's TUI-local FolderPickerState (src/tui_main/mod.rs, ~285 lines). After the quadraui PR lands, vimcode removes the TUI-local code and rewires both TUI and GTK."

vimcode today:

• struct FolderPickerState still at src/tui_main/mod.rs:251 (to ~343)
• src/render.rs:3702 route_folder_picker_key
• src/tui_main/render_impl.rs:502, src/tui_main/shell_app.rs:3948, FrameOp::FolderPicker
• 94 references across 7 files. Zero references to FolderPickerController. No vimcode issue has ever mentioned it.

It got worse than "not done". docs/IRREDUCIBLE_SURFACE.md:24 now records the TUI-only folder picker as Irreducible — one of only three verdicts in that document — on the grounds that GTK uses a native GtkFileChooser. A shipped, 3.5-month-old cross-backend controller contradicts that verdict. The gap was canonised as a constraint, which is worse than leaving it open, because planning now routes around it.

Fix

1. Adopt quadraui::compose::FolderPickerController on the TUI; delete FolderPickerState and its 94 references.
2. Wire GTK to the same controller so the folder picker is one implementation. PlatformServices (quadraui/src/backend.rs:2136) exposes file open/save but not directory select — if the controller needs a native-select escape hatch on GTK, use it there, but the picker UI and key routing must be shared.
3. Correct docs/IRREDUCIBLE_SURFACE.md: strike the folder-picker row from the irreducible list and record why the verdict was wrong (the aggregation post-dated the controller by 3 months and did not check upstream). This is the point of the document — a wrong entry there misdirects every future planning pass.

If adoption turns out to be genuinely blocked by a controller gap, file the quadraui issue and leave this open behind it — do not close it. See GOALS.md's milestone-discipline rule; #47 is the cautionary example.

Acceptance

• Black-box tests required, both backends. TUI via quadraui::tui::testing::driver_with_shell; GTK via GtkDriver. Assert on rendered output — locate targets with find/screen_contains, never hardcode coordinates.
• State in the PR that the new tests fail against unfixed develop.
• cargo test, cargo clippy -- -D warnings, cargo fmt pass.

[JDonaghy]

Coordinator: Assignment Complete

Machine: dell64
Status: done
Exit code: 0
Duration: 32m 32s
Log: /home/john/.coord/logs/59c7359282c1.log

[JDonaghy]

Coordinator: Assignment Complete

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

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Verdict: approve

Review findings

Blocking findings

None.

Non-blocking concerns

• SUMMARIES/tui_modules.md was not updated even though this PR deletes the code it describes: it still lists folder_picker_to_palette as a render_impl.rs function and FolderPickerState / FolderPickerMode as tui_main/mod.rs types (lines ~47, ~59), both of which this PR removes entirely. Per docs/DOC_MAINTENANCE.md ("When to update: After modifying any source file that has a summary, update the corresponding summary"), this is a mandatory-but-skipped update — and given issue Adopt quadraui FolderPickerController — 3.5-month-old adoption, and IRREDUCIBLE_SURFACE.md has since recorded the gap as a constraint #815 exists specifically because stale docs misdirect future planning, this is a mildly ironic gap to leave behind. Worth a quick follow-up edit, not worth blocking on.
• Click-routing precedence for the folder picker differs slightly between backends. In src/app.rs::handle_mouse_click_msg, the folder_picker.is_some() check is the very first thing in the function — before reconcile_editor_hover_modal() and the modal-overlay rung. In TUI's mouse.rs::handle_mouse, the equivalent check sits near the end, after the hover-popup/context-menu/modal-stack reconciliation and route_modal_overlay_click. In practice these states look mutually exclusive (the picker is only opened after a preceding modal, e.g. the command palette, has already closed), so I don't think this causes an observable bug, but it's an asymmetry worth a comment if it was deliberate, since the rest of the PR is careful to keep both backends' rungs in the same relative order.

Nits

• docs/BACKEND_SETUP_AUDIT.md's "File dialogs" row ("GTK uses gtk4::FileDialog natively") still reads as if GTK's folder-open path is native; it's arguably still accurate as written (it's really describing the PlatformServices::show_file_open_dialog/show_file_save_dialog trait methods, which are unaffected by this PR), but it's the kind of sentence a future reader skimming for "does GTK still open folders natively" could misread post-Adopt quadraui FolderPickerController — 3.5-month-old adoption, and IRREDUCIBLE_SURFACE.md has since recorded the gap as a constraint #815. Not asking for a change, just flagging for awareness.

Review notes (for context, not findings)

Verified against the merge-base diff (6af7ee1..f279c38, the two omitted files src/tui_main/render_impl.rs and src/tui_main/shell_app.rs pulled directly via git diff/git show since the tool output truncated them):

• All 94 references to the old TUI-local FolderPickerState/FolderPickerMode and its collect_dir_entries/filter_dir_entries/dir_fuzzy_score helpers, plus render::FolderPickerKeyRoute/route_folder_picker_key, are deleted. git grep at the PR head confirms zero remaining code references (only doc-comment mentions of the old name for historical context).
• GTK's open_folder_dialog no longer opens gtk4::FileDialog; both App (GTK) and TuiShellApp now hold Option<quadraui::FolderPickerController>, wired through shared render.rs helpers (folder_picker_popup_rect, folder_picker_visible_rows, route_folder_picker_click, set_folder_picker_selected) — this is exactly the "thin per-backend wiring calling shared render.rs code" shape CLAUDE.md's Platform-Neutrality Rule asks for, not per-backend reimplementation.
• Checked the actual pinned quadraui rev (4ff2a64, already the pin on develop before this PR — no Cargo.toml/Cargo.lock change needed) via the local ~/.cargo/git/checkouts clone: FolderPickerController, FolderPickerEvent, PALETTE_CHROME_ROWS are exported from quadraui::compose exactly as the PR uses them, method signatures (new, handle, render, filtered, scroll_top, selected, move_up/move_down, sync_scroll) all match call sites in app.rs/shell_app.rs/mouse.rs/render.rs. Key dispatch semantics (Escape/Enter/-/k/j/Backspace/printable, ctrl-gated) are verified identical to the deleted vimcode-local code.
• docs/IRREDUCIBLE_SURFACE.md §1b and its §6 action-item list are corrected to record the adoption as done, with an explanation of why the earlier verdict was wrong (checked upstream late) rather than just re-flipping the checkbox — matches what the issue asked for. GOALS.md gets a matching one-paragraph closure note.
• Black-box tests exist for both backends and assert on painted content (screen_contains), not state fields: TUI via driver_with_shell (paint+filter+dismiss, and a separate confirm-opens-folder test asserting engine.cwd), GTK via the in-crate GtkDriver/harness() (command-palette → picker → navigate → confirm, asserting engine.cwd round-trips). The commit message states the RED reasoning for all three (TUI: compile failure against the old FolderPickerState field type; GTK: first screen_contains("Open Folder") assertion would fail since the pre-Adopt quadraui FolderPickerController — 3.5-month-old adoption, and IRREDUCIBLE_SURFACE.md has since recorded the gap as a constraint #815 code opened a native dialog the headless harness can't paint) — satisfies the "state it fails against unfixed develop" acceptance bar.
• No changes to CLAUDE.md. Scope stayed within the issue: adoption + GTK wiring + doc correction, nothing extraneous.
• Traced unit consistency (pixels on GTK vs cells on TUI) through folder_picker_popup_rect/folder_picker_visible_rows/the painted-rect caches (folder_picker_popup_rect field) — click/key handling reads the last-painted rect rather than re-deriving geometry, consistent with the existing picker_popup_rect/dialog_layout pattern and the Split-pane divider drag is broken in both TUI and GTK (falls through to text-selection) #582/Adopt quadraui's GtkDriver — vimcode has zero GTK black-box tests though the harness shipped in quadraui#301 #646 rule cited in the comments.
• No security concerns — filesystem walk logic is an unmodified port from the deleted vimcode code (depth-capped, skips heavy dirs), no new path-traversal surface.

[JDonaghy]

Review Complete — ✅ Approved

Reviewer findings could not be posted directly to PR #842 (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

• SUMMARIES/tui_modules.md was not updated even though this PR deletes the code it describes: it still lists folder_picker_to_palette as a render_impl.rs function and FolderPickerState / FolderPickerMode as tui_main/mod.rs types (lines ~47, ~59), both of which this PR removes entirely. Per docs/DOC_MAINTENANCE.md ("When to update: After modifying any source file that has a summary, update the corresponding summary"), this is a mandatory-but-skipped update — and given issue Adopt quadraui FolderPickerController — 3.5-month-old adoption, and IRREDUCIBLE_SURFACE.md has since recorded the gap as a constraint #815 exists specifically because stale docs misdirect future planning, this is a mildly ironic gap to leave behind. Worth a quick follow-up edit, not worth blocking on.
• Click-routing precedence for the folder picker differs slightly between backends. In src/app.rs::handle_mouse_click_msg, the folder_picker.is_some() check is the very first thing in the function — before reconcile_editor_hover_modal() and the modal-overlay rung. In TUI's mouse.rs::handle_mouse, the equivalent check sits near the end, after the hover-popup/context-menu/modal-stack reconciliation and route_modal_overlay_click. In practice these states look mutually exclusive (the picker is only opened after a preceding modal, e.g. the command palette, has already closed), so I don't think this causes an observable bug, but it's an asymmetry worth a comment if it was deliberate, since the rest of the PR is careful to keep both backends' rungs in the same relative order.

Nits

• docs/BACKEND_SETUP_AUDIT.md's "File dialogs" row ("GTK uses gtk4::FileDialog natively") still reads as if GTK's folder-open path is native; it's arguably still accurate as written (it's really describing the PlatformServices::show_file_open_dialog/show_file_save_dialog trait methods, which are unaffected by this PR), but it's the kind of sentence a future reader skimming for "does GTK still open folders natively" could misread post-Adopt quadraui FolderPickerController — 3.5-month-old adoption, and IRREDUCIBLE_SURFACE.md has since recorded the gap as a constraint #815. Not asking for a change, just flagging for awareness.

Review notes (for context, not findings)

Verified against the merge-base diff (6af7ee1..f279c38, the two omitted files src/tui_main/render_impl.rs and src/tui_main/shell_app.rs pulled directly via git diff/git show since the tool output truncated them):

• All 94 references to the old TUI-local FolderPickerState/FolderPickerMode and its collect_dir_entries/filter_dir_entries/dir_fuzzy_score helpers, plus render::FolderPickerKeyRoute/route_folder_picker_key, are deleted. git grep at the PR head confirms zero remaining code references (only doc-comment mentions of the old name for historical context).
• GTK's open_folder_dialog no longer opens gtk4::FileDialog; both App (GTK) and TuiShellApp now hold Option<quadraui::FolderPickerController>, wired through shared render.rs helpers (folder_picker_popup_rect, folder_picker_visible_rows, route_folder_picker_click, set_folder_picker_selected) — exactly the "thin per-backend wiring calling shared render.rs code" shape CLAUDE.md's Platform-Neutrality Rule asks for, not per-backend reimplementation.
• Checked the actual pinned quadraui rev (4ff2a64, already the pin on develop before this PR — no Cargo.toml/Cargo.lock change needed) via the local ~/.cargo/git/checkouts clone: FolderPickerController, FolderPickerEvent, PALETTE_CHROME_ROWS are exported from quadraui::compose exactly as the PR uses them, method signatures all match call sites. Key dispatch semantics (Escape/Enter/-/k/j/Backspace/printable, ctrl-gated) verified identical to the deleted vimcode-local code.
• docs/IRREDUCIBLE_SURFACE.md §1b and its §6 action-item list are corrected to record the adoption as done, with an explanation of why the earlier verdict was wrong, not just a re-flipped checkbox — matches what the issue asked for. GOALS.md gets a matching closure note.
• Black-box tests exist for both backends and assert on painted content (screen_contains), not state fields: TUI via driver_with_shell (paint+filter+dismiss, and a confirm-opens-folder test asserting engine.cwd), GTK via the in-crate GtkDriver/harness() (command-palette → picker → navigate → confirm). The commit message states RED-against-unfixed-develop reasoning for all three tests, satisfying that acceptance bar.
• No changes to CLAUDE.md. Scope stayed within the issue: adoption + GTK wiring + doc correction, nothing extraneous.
• Traced unit consistency (pixels on GTK vs cells on TUI) through the popup-rect helpers and the painted-rect caches — click/key handling reads the last-painted rect rather than re-deriving geometry, consistent with the existing pattern.
• No security concerns — filesystem walk logic is an unmodified port from the deleted vimcode code (depth-capped, skips heavy dirs), no new path-traversal surface.