TUI: migrate to quadraui ShellApp + run_with_shell (mirrors #493's GTK migration)

[JDonaghy]

EPIC — parent/tracking issue

Milestone: #9 TUI ShellApp Migration (TUI counterpart to #8 GTK ShellApp Event Dispatch; carved out of #7 Platform-Neutral to keep it bounded).

This is the single largest remaining architectural divergence between the two backends. tui_main::run() (src/tui_main/mod.rs:635) hand-rolls raw-mode/alt-screen bootstrap, ratatui::Terminal construction, and frame timing, then calls one event_loop() (:787, ~2,100 lines) with 32 dispatch sites fused into a single loop { }. None of it goes through quadraui::tui::run / run_with_shell. This epic migrates it onto quadraui::ShellApp + tui::shell_runner::run_with_shell, mirroring GTK's landed #493 migration, so quadraui owns the loop and App only implements setup/render_content/handle/tick. Per GOALS.md, cross-backend divergence is the direct cause of most GTK:/TUI: bug pairs — deleting event_loop() (Stage 6) is the payoff.

Scoping (Stage 0) found this is GTK-B.5-scale, not a quick pick — GTK's equivalent took 9 (B.5) + 13 (B.5b) stages. The three structural gaps and the full staged plan are recorded in PLAN.md ("Staged plan") and the src/tui_main/shell_app.rs module doc.

Migration status

Stage	Issue	Scope	Status
0	(this issue)	Dormant TuiShellApp scaffold — setup/tick fully ported, handle partial (accelerators + menu intercept), render_content stubbed; not wired to live entry point	✅ landed 2026-07-23 (branch issue-595-tui-migrate-to-quadraui-shellapp-run-wit)
1	#600	Paint centralization — route rasteriser calls through Backend::draw_*, collapse enter_frame_scope	✅ landed
2	#601	render_content paints for real through &mut dyn Backend — editor windows + tab bars/breadcrumbs into main_content_bounds	⬜ pending (after #600)
2a	#607	render_content: paint sidebar panel content (explorer/git/search/debug/settings/ext/AI panels) into sidebar_content_bounds	⬜ pending (after #601)
2b	#608	render_content: paint quickfix + bottom panel (terminal/debug output)	⬜ pending (after #601)
2c	#609	render_content: window/group dividers, tab-drag overlay, tab-hover tooltip	⬜ pending (after #601)
3	#602	Wire handle mouse dispatch — consume quadraui#467 (DragState/ModalStack accessor)	⬜ pending (after #600/#601)
4	#603	Wire remaining handle key dispatch (dialog/palette/completion/context-menu + #318 Alt-reveal shim)	⬜ pending (after #600/#601)
5	#604	Apply editor cursor placement — consume quadraui#466	⛔ blocked on quadraui#466 (after #601)
6	#605	Cutover main.rs/tui_bin.rs to run_with_shell; delete event_loop()	⬜ pending (after #602-#604, #607-#609)

Stages 2a/2b/2c were split out while scoping #601: render_content genuinely
cannot reach a raw ratatui::Frame/Buffer (confirmed via TuiBackend's
frame-scope internals — no public accessor exists), so #601 only wires the
subset already reachable through &mut dyn quadraui::Backend trait calls
(editor + tab/breadcrumb bars) and leaves sidebar content, quickfix/bottom
panel, and divider/drag/tooltip painting as explicit follow-ons. All three
block #605 — cutover can't delete event_loop() while those stay unpainted
without violating this epic's own "no change to what gets rendered" non-goal.

Supply-side (quadraui) dependencies

• quadraui#466 — no consumer applies Backend::draw_editor's EditorPaintResult::cursor_position in the TUI ShellApp path. Hard-blocks Stage 5, and thus the Stage 6 cutover (live TUI would lose its cursor).
• quadraui#467 — Backend trait has no DragState/ModalStack accessor; handle_mouse needs TuiBackend::drag_and_modal_mut(), which isn't on the trait. Preferred path for Stage 3 (a consumer-side rewrite onto dispatch_mouse_down/drag/up is the fallback).
• Not blocked on quadraui#465 (macOS ShellApp) — TUI already runs everywhere via crossterm.
• Stages 2a/2b/2c (#595 Stage 2a — render_content: paint sidebar panel content #607/#595 Stage 2b — render_content: paint quickfix + bottom panel (terminal/debug output) #608/#595 Stage 2c — render_content: window/group dividers, tab-drag overlay, tab-hover tooltip #609) are not currently believed to need new quadraui infra — see each issue's own "Scope / known gap" section for the specific primitive each should try first before concluding otherwise.

Non-goals

• No change to what gets rendered or how panels look — pure event-loop/entry-point restructuring.
• Not waiting on macOS support to start.

References

• src/tui_main/mod.rs:635 (run()), :787 (event_loop()); src/tui_main/shell_app.rs (Stage 0 scaffold + module-doc gap analysis)
• src/gtk/mod.rs impl ShellApp for App (Full GTK run_with_shell migration: collapse 14 DAs to 1, strip Relm4 #493), Migrate GTK event dispatch to ShellApp::handle(UiEvent) #448 (GTK event-dispatch epic — the precedent this mirrors)
• PLAN.md "Staged plan for follow-up sessions"

Dispatch note (2026-08-05)

• quadraui#466 and quadraui#467 are both now CLOSED. Stage 5 (#595 Stage 5 — apply editor cursor placement on the TUI ShellApp path (consume quadraui#466) #604)'s "blocked" label was stale as of this note and has been removed — both #595 Stage 3 — wire TuiShellApp::handle mouse dispatch (consume quadraui#467 DragState/ModalStack accessor) #602 (Stage 3, preferred path) and #595 Stage 5 — apply editor cursor placement on the TUI ShellApp path (consume quadraui#466) #604 (Stage 5) are fully unblocked. The Migration-status table row for Stage 5 above still shows the old blocked state pending its next content update; treat the issue trackers (#595 Stage 3 — wire TuiShellApp::handle mouse dispatch (consume quadraui#467 DragState/ModalStack accessor) #602/#595 Stage 5 — apply editor cursor placement on the TUI ShellApp path (consume quadraui#466) #604 labels) as the current source of truth over that row.
• Operator decision: driving #595 Stage 3 — wire TuiShellApp::handle mouse dispatch (consume quadraui#467 DragState/ModalStack accessor) #602/#595 Stage 4 — wire remaining TuiShellApp::handle key dispatch (dialog/palette/completion/context-menu + #318 Alt-reveal shim) #603/#595 Stage 5 — apply editor cursor placement on the TUI ShellApp path (consume quadraui#466) #604/#595 Stage 2a — render_content: paint sidebar panel content #607/#595 Stage 2b — render_content: paint quickfix + bottom panel (terminal/debug output) #608/#595 Stage 2c — render_content: window/group dividers, tab-drag overlay, tab-hover tooltip #609 by hand, not via coord drive/queue automation. Rationale: all six are simultaneously dispatchable per the Work-order DAG (each depends only on #595 Stage 2 — TuiShellApp::render_content paints for real through &mut dyn Backend #601), but vimcode has no automated gate that actually verifies TUI screen/behavior state today — the only Test-stage automation is a rerun of the existing unit suite (cargo test --no-default-features), which can't catch painting/mouse/cursor regressions. All six also touch src/tui_main/shell_app.rs concurrently (the painting three likely also render_impl.rs/panels.rs), and that file isn't in coordinator.yml's exclusive_files — real conflict risk if dispatched in parallel. See vimcode#622 (mini oracle-loop pilot, itself blocked on this epic) for the follow-up that would eventually make unattended driving of TUI work trustworthy.

Work order

• #595 Stage 1 — TUI paint centralization: route rasteriser calls through Backend::draw_*, collapse enter_frame_scope #600 {group: A}
• #595 Stage 2 — TuiShellApp::render_content paints for real through &mut dyn Backend #601 {after: 600}
• #595 Stage 3 — wire TuiShellApp::handle mouse dispatch (consume quadraui#467 DragState/ModalStack accessor) #602 {after: 601}
• #595 Stage 4 — wire remaining TuiShellApp::handle key dispatch (dialog/palette/completion/context-menu + #318 Alt-reveal shim) #603 {after: 601}
• #595 Stage 5 — apply editor cursor placement on the TUI ShellApp path (consume quadraui#466) #604 {after: 601}
• #595 Stage 2a — render_content: paint sidebar panel content #607 {after: 601}
• #595 Stage 2b — render_content: paint quickfix + bottom panel (terminal/debug output) #608 {after: 601}
• #595 Stage 2c — render_content: window/group dividers, tab-drag overlay, tab-hover tooltip #609 {after: 601}
• #595 Stage 6a — render_content parity sweep + scoped cutover blocker survey #605 {after: 602,603,604,607,608,609}
• #595 Stage 6b — cutover prerequisites: consume quadraui#532/#533, port the raw-Buffer holdouts, live ShellConfig, run() responsibilities #635 {after: 605}
• #595 Stage 6 — cutover TUI entry point to run_with_shell; delete event_loop() #634 {after: 635}

Sub-issues

• #595 Stage 1 — TUI paint centralization: route rasteriser calls through Backend::draw_*, collapse enter_frame_scope #600 {group: A}
• #595 Stage 2 — TuiShellApp::render_content paints for real through &mut dyn Backend #601 {after: #595 Stage 1 — TUI paint centralization: route rasteriser calls through Backend::draw_*, collapse enter_frame_scope #600}
• #595 Stage 3 — wire TuiShellApp::handle mouse dispatch (consume quadraui#467 DragState/ModalStack accessor) #602 {after: #595 Stage 2 — TuiShellApp::render_content paints for real through &mut dyn Backend #601}
• #595 Stage 4 — wire remaining TuiShellApp::handle key dispatch (dialog/palette/completion/context-menu + #318 Alt-reveal shim) #603 {after: #595 Stage 2 — TuiShellApp::render_content paints for real through &mut dyn Backend #601}
• #595 Stage 5 — apply editor cursor placement on the TUI ShellApp path (consume quadraui#466) #604 {after: #595 Stage 2 — TuiShellApp::render_content paints for real through &mut dyn Backend #601}
• #595 Stage 6a — render_content parity sweep + scoped cutover blocker survey #605 {after: #595 Stage 3 — wire TuiShellApp::handle mouse dispatch (consume quadraui#467 DragState/ModalStack accessor) #602,#595 Stage 4 — wire remaining TuiShellApp::handle key dispatch (dialog/palette/completion/context-menu + #318 Alt-reveal shim) #603,#595 Stage 5 — apply editor cursor placement on the TUI ShellApp path (consume quadraui#466) #604,#595 Stage 2a — render_content: paint sidebar panel content #607,#595 Stage 2b — render_content: paint quickfix + bottom panel (terminal/debug output) #608,#595 Stage 2c — render_content: window/group dividers, tab-drag overlay, tab-hover tooltip #609}
• #595 Stage 2a — render_content: paint sidebar panel content #607 {after: #595 Stage 2 — TuiShellApp::render_content paints for real through &mut dyn Backend #601}
• #595 Stage 2b — render_content: paint quickfix + bottom panel (terminal/debug output) #608 {after: #595 Stage 2 — TuiShellApp::render_content paints for real through &mut dyn Backend #601}
• #595 Stage 2c — render_content: window/group dividers, tab-drag overlay, tab-hover tooltip #609 {after: #595 Stage 2 — TuiShellApp::render_content paints for real through &mut dyn Backend #601}
• #595 Stage 6b — cutover prerequisites: consume quadraui#532/#533, port the raw-Buffer holdouts, live ShellConfig, run() responsibilities #635 {after: #595 Stage 6a — render_content parity sweep + scoped cutover blocker survey #605}

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Landed Stage 0 of vimcode#595 (TUI ShellApp migration): new src/tui_main/shell_app.rs with TuiShellApp implementing quadraui::ShellApp, setup()/tick() fully ported from event_loop(), handle() partially (accelerators+menu intercept), render_content() stubbed pending Stage 1. Dormant scaffold, not wired to live entry point. Discovered the migration is far larger than scoped (GTK-B.5-scale, not a quick pick): 3 concrete gaps found and pinned to coord context (paint-layer frame-scope coupling across ~30 sites in render_impl.rs/panels.rs, mouse.rs's DragState/ModalStack coupling, a quadraui-side editor-cursor-placement gap). PLAN.md rewritten with a full Stage 1-6 plan mirroring GTK's actual B.5/B.5b staging. Build/clippy/fmt/full test suite all clean (both feature sets), 4 new tests, 0 regressions. Pushed branch, no PR opened per instructions.

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Bug: dispatch_panel_accelerator_sizeless passes screen width where terminal_target_maximize_rows_tui expects height (ACC_TERMINAL_TOGGLE_MAX arm), untested; plus minor doc gap on Alt-reveal-menu shim

Verdict: request-changes

Review findings

Review: vimcode#595 Stage 0 — TuiShellApp dormant scaffold

Branch: issue-595-tui-migrate-to-quadraui-shellapp-run-wit (commits 0103f83, 42f5c50)

Summary

Verified against the actual quadraui checkout (~/src/quadraui, 197d630): the
ShellApp trait signature, PanelDefinition/ShellConfig::new, Reaction,
driver_with_shell, and the TuiBackend::drag_and_modal_mut() concrete-only-method
claim all match what's implemented — this is not a stale-quadraui-checkout situation,
and the "gap 2" (mouse) and "gap 3" (cursor placement, quadraui#466) claims check out.
Line-count claims in the module doc / PLAN.md (render_impl.rs 2427, panels.rs 1570,
mouse.rs 4124, ~30 enter_frame_scope call sites) were spot-checked against the actual
files and are accurate. TuiShellApp is confirmed dormant — no reference to it exists
anywhere else in mod.rs, so this cannot regress the live TUI path. Scope matches the
issue's suggested incremental-landing approach exactly (Stage 0 of the issue's own
staged plan). No security issues, no platform-neutrality violation (this is the
sanctioned per-backend ShellApp impl the issue asks for, mirroring GTK's App).

One concrete bug found in the new logic, plus a smaller documentation-completeness gap.

Findings

1. (Blocking) Wrong dimension passed to terminal_target_maximize_rows_tui in the new accelerator wrapper — src/tui_main/shell_app.rs:543

dispatch_panel_accelerator_sizeless (shell_app.rs:469-556) is a new function, a
near-verbatim copy of dispatch_panel_accelerator (mod.rs:153-:280) with the
terminal: &Terminal<...> parameter replaced by a single screen_w: u16. The doc
comment justifies this: "every call site in the original only used terminal for
.size()" (shell_app.rs:463-464).

That's true, but .size() returns both width and height, and the original
ACC_TERMINAL_TOGGLE_MAX arm used both — screen_w for terminal_cols and
size.height for terminal_max_rows (mod.rs:224-:239):

let size = terminal.size().ok();
let screen_w = size.map(|s| s.width).unwrap_or(80);
let ctx = crate::core::engine::UiEventContext {
    terminal_cols: terminal_panel_cols(engine, screen_w, sidebar_width),
    terminal_max_rows: terminal_target_maximize_rows_tui(
        engine,
        size.map(|s| s.height).unwrap_or(24),   // <-- height
    ),
};

The new wrapper only takes screen_w (no height parameter at all), so the ported
arm silently passes the width into the height slot (shell_app.rs:540-545):

ACC_TERMINAL_TOGGLE_MAX => {
    let ctx = crate::core::engine::UiEventContext {
        terminal_cols: terminal_panel_cols(engine, screen_w, sidebar_width),
        terminal_max_rows: terminal_target_maximize_rows_tui(engine, screen_w), // BUG: should be screen_h
    };

terminal_target_maximize_rows_tui(engine: &Engine, screen_h: u16) (mod.rs:107)
explicitly names its parameter screen_h and forwards it as the height to
render::compute_editor_layout(engine, screen_h as f64, 1.0, true). Feeding it the
terminal's column count instead of its row count will compute a bogus
terminal_max_target_rows (typically 80-200 instead of ~24-50) once this path is
wired live — the exact "same underlying function either way" claim the module doc
makes for the paint-layer sweep doesn't hold here because a parameter was dropped,
not just re-routed.

Call site confirming only width is threaded through: handle() passes
viewport.width as u16 and nothing else (shell_app.rs:279-282); there is no height
available to dispatch_panel_accelerator_sizeless at all.

This is currently unreachable (dormant scaffold, not wired to any live entry point),
so it has zero user-facing impact today. It's flagged as blocking because: (a) it's
new code, not a straight port, despite being presented as one — future Stage 3/4/6
sessions are told (correctly, per the pinned coordinator context) to trust this
scaffold's logic and build on top of it without re-deriving it; (b) it's exactly the
kind of latent GTK/TUI-parity bug this whole migration exists to eliminate per
GOALS.md; (c) it's a pure function — trivial to unit-test and to fix (thread
screen_h through, or read it from a second viewport().height param at the one
call site).

Suggested fix: add a screen_h: u16 parameter to dispatch_panel_accelerator_sizeless
(or pass the full Viewport/(u16,u16) pair), wire backend.viewport().height as u16
through the handle() call site, and use it (not screen_w) in the
ACC_TERMINAL_TOGGLE_MAX arm. Add a unit test exercising that arm directly (the
function is a free function in the same module — easy to call with fixture
Engine/TuiSidebar values and assert on the resulting UiEventContext/engine
state) so this class of bug can't silently reappear when Stage 6 actually wires
handle()'s key/mouse dispatch.

2. (Non-blocking / doc nit) Alt+letter "reveal menu bar" shim silently dropped from the ported dispatch, not called out as a gap — src/tui_main/shell_app.rs:264-:293

Between the accelerator-dispatch block and the "MenuSystem intercept" block, the
original event_loop() has a small but load-bearing shim (mod.rs:1273-:1290,
the "#318" fix): when the menu bar is hidden, an Alt+<menu-letter> keypress first
sets engine.menu_bar_visible = true, then falls through into the same iteration's
menu-intercept block so the same keystroke both reveals and activates the menu.

The new handle()'s comment says the "two dispatch layers" it ports are "panel-key
accelerators and the MenuSystem intercept" and labels the MenuSystem block "mirrors
mod.rs:1296-:1304" — but that mirrors only the back half; the :1273-:1290
Alt-reveal shim in between isn't mentioned anywhere, either as ported or as a listed
gap. Functionally this is harmless today since the whole KeyPressed arm is already
a // TODO(#595) stub returning Reaction::Continue, so no behavior is silently
half-implemented — but the module doc's three numbered "what's NOT yet ported" gaps
don't mention this piece, so a future session skimming the doc could reasonably
believe menu-key handling is more complete than it is. Suggest adding one line to the
module doc / the KeyPressed TODO noting the Alt-reveal shim still needs porting
alongside the rest of key dispatch.

Checklist

• Tests added/updated: yes for setup/tick/construction/driver_with_shell smoke;
  no test covers the new dispatch_panel_accelerator_sizeless function at all
  (see finding 1) despite it being new, easily-unit-testable logic.
• Stayed within issue scope: yes — matches the issue's own suggested Stage-0 landing
  exactly, non-goals (no render/behavior change) respected, dormant/unwired as claimed.
• Security (command injection, path traversal, etc.): none found.
• Follows existing patterns: yes (Cell/RefCell render-time-cache pattern mirrors
  Engine/GTK App; test placement matches CLAUDE.md's #[cfg(test)] mod tests
  convention).
• Platform-neutrality: not a violation — this is the sanctioned per-backend ShellApp
  impl the issue itself calls for, mirroring GTK's landed impl ShellApp for App (Full GTK run_with_shell migration: collapse 14 DAs to 1, strip Relm4 #493).

Verdict

Request changes: fix the screen_w/screen_h mix-up in
dispatch_panel_accelerator_sizeless's ACC_TERMINAL_TOGGLE_MAX arm (finding 1) and
add a unit test for that function before merging. The doc nit (finding 2) is optional
but cheap to fix in the same pass.

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Fixed review finding 1 (blocking): dispatch_panel_accelerator_sizeless's ACC_TERMINAL_TOGGLE_MAX arm was passing screen_w into terminal_target_maximize_rows_tui instead of screen_h. Added a screen_h: u16 param, threaded it from handle()'s backend.viewport().height, fixed the arm, and added a regression test (terminal_toggle_max_uses_screen_height_not_width) that reproduces the terminal-open-not-maximized precondition under which the bug is observable. Also addressed finding 2 (doc nit): documented the still-unported '#318' Alt+menu-letter reveal shim both in the module doc and inline at the handle() call site. cargo build, cargo clippy -- -D warnings, and cargo test --no-default-features all pass clean (0 warnings in changed file, 0 test failures). Commit 1728158 pushed to issue-595-tui-migrate-to-quadraui-shellapp-run-wit.

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Smoke PASSED (363083a6b1cb): #595 Stage-0 TuiShellApp scaffold is dormant/additive-only vs origin/develop (shell_app.rs + mod decl only); version/ldd/help/interactive TUI launch-quit all clean. Note: coord pull-artifact failed for both 68afabc91caf and 363083a6b1cb (artifact stuck on dellserver, unreachable from this host) -- built locally in a sibling scratch worktree instead; may want to check dellserver artifact sync.

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Fix correctly threads screen_h through ACC_TERMINAL_TOGGLE_MAX arm; regression test verified sound; approved

Verdict: approve

Review findings

Re-review iteration 1 — vimcode#595 (TUI ShellApp Stage 0)

Scope: only the fix commits pushed since round 1
(git log origin/develop...origin/issue-595-...):

• 1728158 fix(TUI: migrate to quadraui ShellApp + run_with_shell (mirrors #493's GTK migration) #595): pass screen_h (not screen_w) to terminal_target_maximize_rows_tui
• 42f5c50 docs(TUI: migrate to quadraui ShellApp + run_with_shell (mirrors #493's GTK migration) #595): link filed quadraui#466 for the editor-cursor gap (pure doc change, no code)
• 0103f83 feat(TUI: migrate to quadraui ShellApp + run_with_shell (mirrors #493's GTK migration) #595): TUI ShellApp Stage 0 scaffold (already reviewed in round 0)

Verified: the requested fix was made correctly

Round 1 flagged that dispatch_panel_accelerator_sizeless's ACC_TERMINAL_TOGGLE_MAX arm
(src/tui_main/shell_app.rs) fed screen_w into terminal_target_maximize_rows_tui, whose
parameter is named/documented screen_h in the original dispatch_panel_accelerator
(src/tui_main/mod.rs:104-106, confirmed: terminal_target_maximize_rows_tui(engine, screen_h)
delegates to compute_editor_layout(engine, screen_h as f64, ...)).

Commit 1728158 fixes this correctly:

• Adds a screen_h: u16 parameter to dispatch_panel_accelerator_sizeless
  (shell_app.rs:499-502).
• Threads it from handle()'s call site via backend.viewport().height as u16
  (shell_app.rs:302), alongside the pre-existing viewport.width as u16 for screen_w.
• Uses screen_h (not screen_w) in the ACC_TERMINAL_TOGGLE_MAX arm
  (shell_app.rs:571), matching the original dispatch_panel_accelerator's behavior at
  mod.rs:229-232 (size.map(|s| s.height) feeds terminal_target_maximize_rows_tui,
  while screen_w only feeds terminal_panel_cols). I diffed both dispatch functions
  side-by-side — the sizeless wrapper is now behaviorally equivalent to the original for
  this arm.
• Adds a regression test (terminal_toggle_max_uses_screen_height_not_width,
  shell_app.rs:696-754) that pre-seeds engine.terminal_open = true (needed because the
  bug is only observable once the terminal panel is already open — the arm's ctx is built
  before Engine::handle_ui_event flips terminal_open), picks a screen far wider than
  tall so swapping the args would produce a detectably different row count, and asserts the
  spawned terminal's rows derive from screen_h. Confirmed effective_terminal_panel_rows,
  terminal_maximized, and terminal_panes are real public Engine members
  (src/core/engine/terminal_ops.rs:410, src/core/engine/mod.rs:3106/:3073) — the test
  should compile and actually exercise the fixed code path.
• Only one call site of dispatch_panel_accelerator_sizeless exists (shell_app.rs:296),
  so there's nothing else that needed updating for the new parameter.
• Bonus: documents the not-yet-ported "TUI: default Alt+letter keybindings clash with menu bar shortcuts #318" Alt+menu-letter reveal shim (both in the module
  doc and inline at the handle() call site) referencing mod.rs:1275-:1294 — I checked
  those line numbers against the actual file and they're accurate.

The 42f5c50 doc commit (linking the filed quadraui#466 issue) is a trivial, correct
docs-only change — no code impact.

Platform-neutrality / scope check

The fix stays inside src/tui_main/shell_app.rs, a TUI-only file mirroring existing
TUI-only logic (dispatch_panel_accelerator in mod.rs) — not new backend-specific
business logic, just correcting a parameter mix-up in a straight port. No quadraui-gap
workaround was introduced; the module doc continues to correctly flag the three real
structural gaps (paint/mouse/cursor) as blocked on quadraui-side work per the
Platform-Neutrality Rule.

Verdict

Fix is correct, narrowly scoped, and tested. No regressions found. Approving.