Migrate activity-bar keyboard nav onto quadraui AppShell (retire hand-rolled toolbar_selected arithmetic) — consume quadraui#386

[JDonaghy]

Context

Activity-bar keyboard navigation (the j/k selection ring + l/Enter activate + h/Esc dismiss) is being lifted out of vimcode and into quadraui's AppShell — see quadraui#386. vimcode currently owns this behavior with hand-rolled state because the AppShell API didn't exist when it was written. Once #386 lands, vimcode should consume the shared implementation so the logic lives in one place.

What vimcode hand-rolls today

• kbd_sel + manual ActivityBar primitive construction — src/tui_main/panels.rs:32, :93 (bottom Settings), :101.
• Toolbar nav state — toolbar_focused: bool, toolbar_selected: u16 in TuiSidebar (src/tui_main/mod.rs:333-335).
• The cursor arithmetic — the bespoke 0→1…→6→8…→max_ext→7(settings) up/down sequencing in src/tui_main/mod.rs:1770-1804, plus the l/Enter/Esc activate-dismiss handling at :1805-1865.

That index arithmetic (settings pinned last, extension panels spliced at 8+) is exactly the "cursor spanning top_items then bottom_items as one sequence" that quadraui#386 standardizes.

Goal

Retire vimcode's bespoke activity-bar nav state/arithmetic by delegating to AppShell's cursor from quadraui#386, while keeping vimcode's manual activity-bar rendering (vimcode is a manual-layout app — it does NOT use the ShellApp chrome renderer, so this is not a request to adopt that).

Concretely after #386:

• Replace toolbar_selected index math (mod.rs:1770-1804) with app_shell.activity_select_next() / activity_select_prev().
• Replace kbd_sel(idx) (panels.rs:32) with app_shell.activity_selected_id() when building each ActivityItem's is_keyboard_selected — vimcode still constructs the primitive, but reads the selected id from the shared cursor.
• Route the l/Enter activation through activity_activate_selected() (emits the same panel-change vimcode already handles).
• Keep toolbar_focused as the local "is the bar focused" gate, or fold into set_activity_keyboard_focused(true) if vimcode wants the backend ActivityBarEvent::KeyPressed routing too.

Open scope question

vimcode's activity bar includes dynamic extension panels (indices 8+) interleaved before Settings. quadraui#386's cursor must handle a variable panel count (top items + dynamic + bottom-pinned Settings) for vimcode to fully delegate; if #386 only covers static panels, vimcode keeps local handling for the ext-panel range. Confirm #386's cursor supports dynamic panels, or scope this migration to the static panels only.

Acceptance

• Behavior unchanged: j/k move the ring (incl. settings-last ordering and ext-panel splice), l/Enter activate, h/Esc dismiss — verified against current behavior.
• The bespoke index arithmetic in mod.rs:1770-1804 and kbd_sel are gone (or reduced to the ext-panel range only, per the scope question).
• Existing toolbar-nav tests still pass.

Blocked by

• quadraui#386 (lift activity-bar keyboard nav into AppShell). File/land that first.

---

Unblocked 2026-08-26 — quadraui#386 has LANDED

The "Blocked by" section above is stale. quadraui#386 (AppShell: keyboard-selectable
activity bar) is CLOSED. This is now a pure vimcode-side adoption — the exact
"infra landed but the adoption issue never got picked up" shape GOALS.md exists to catch.

The open scope question above still stands and is the first thing to settle in-session:
confirm whether #386s cursor handles a variable panel count (top items + dynamic
ext panels at 8+ + bottom-pinned Settings). If it only covers static panels, scope this to
the static range and say so in the PR rather than half-migrating.

Note the TUI has since moved onto run_with_shell (#634), so the line references below
point into the pre-cutover layout — re-locate toolbar_selected / kbd_sel in the current
src/tui_main/shell_app.rs + panels.rs rather than trusting the old mod.rs:1770-1804.

Files

• src/tui_main/shell_app.rs
• src/tui_main/panels.rs
• src/tui_main/mod.rs

Out of scope

• Adopting the ShellApp chrome renderer for the activity bar. vimcode still constructs
  the primitive itself; this issue moves only the nav state/arithmetic.

[JDonaghy]

Driver-tier acceptance criterion (+ the scope question answered, + two stale symbols)

vimcode's CLAUDE.md now states a black-box acceptance bar ("Testing (CRITICAL)", 2563873 /
aed1ca8), and it is enforced at review time via reviews.repo_overrides.vimcode. This issue
predates that and its acceptance section is regression-only ("Existing toolbar-nav tests still
pass"), which is not sufficient here. Adding the missing criterion.

1. This is a behaviour-preserving refactor — so the "observed RED" clause does not apply

Read the new rule carefully before applying it here. It requires a behaviour-changing PR to state
its new test was seen red against unfixed develop. That clause is meaningless for this issue:
there is no bug and no fix, and the entire success condition is that nothing user-visible changes.

Do the inverse instead, and say so in the PR:

1. Write the driver test first, against unmigrated develop.
2. Confirm it passes before the migration — that is what makes it a characterisation test
   rather than a restatement of whatever the new code happens to do.
3. Perform the migration.
4. Confirm it still passes, unmodified. If you have to edit the test to make it pass, the
   migration changed behaviour — stop and say so in the PR rather than adjusting the assertion.

Writing the test after the migration proves nothing; it just pins the new behaviour, including any
regression you introduced.

2. The existing test cannot catch the most likely regression

handle_key_pressed_activity_bar_focused_moves_and_activates
(src/tui_main/shell_app.rs:6272) is the "existing toolbar-nav test" this issue's acceptance
section leans on. It asserts on:

assert!(engine.activity_bar_focused, "still toolbar-focused after j");
assert_eq!(engine.activity_bar_selected, 1);

— engine state only. It never renders a frame. So it stays green for a migration that correctly
drives AppShell's cursor but breaks the is_keyboard_selected flag that feeds the painted
ActivityItem (kbd_sel, src/tui_main/panels.rs:32) — i.e. the selection ring stops moving on
screen while every assertion still passes. Given that swapping kbd_sel for
activity_selected_id() is literally step 2 of this issue's Goal section, that is not a
hypothetical failure mode; it is the single most likely way this migration goes wrong.

This is the same class of defect as #587/#592 (state populated, nothing painted) and #553 (tests
stayed green with the bug reinstated).

3. The criterion

Add a TuiDriver test built with quadraui::tui::testing::driver_with_shell(TuiShellApp, ...),
in-crate in src/tui_main/shell_app.rs under #[cfg(test)] — reuse the local
app_with_sidebar_open() (:4068) / app_with_ext_panel() (:4456) fixtures and follow the
driver_paints_a_registered_extension_panels_activity_bar_icon (:4475) and
driver_click_on_search_icon_switches_and_toggles_sidebar (:4394) patterns.

It must assert on the rendered activity bar — locate items with find / screen_contains,
never hardcoded coordinates — across the full behaviour this issue promises to preserve:

• j / k move the selection ring, including the settings-last ordering and the ext-panel
  splice (use app_with_ext_panel so the dynamic range is actually exercised — the static-only
  path is the easy half and is not where this breaks);
• l / Enter activate the selected panel and the sidebar visibly switches to it;
• h / Esc dismiss.

Keep the existing engine-state test — it is fine as a unit test. It is just not the acceptance
evidence.

4. The open scope question is answered: the cursor is dynamic

The "Open scope question" section asks whether quadraui#386's cursor handles a variable panel
count. It does — verified in quadraui/src/compose/app_shell.rs:

pub fn activity_select_next(&mut self) {
    let total = self.panels.len() + self.bottom_items.len();   // recomputed every call
    ...
}

activity_selected_id() (:305) indexes the live panels / bottom_items lists, so extension
panels registered into panels are covered automatically, and Settings as a bottom_item is
pinned last by construction — matching vimcode's existing …→max_ext→settings ordering. So this
is a full migration; no static-only carve-out is needed.

Two behavioural details to verify rather than assume, because they are exactly what a
characterisation test written first will catch:

• quadraui's cursor saturates, it does not wrap (activity_select_next uses
  .min(total - 1), activity_select_prev uses saturating_sub(1)). Confirm vimcode's bespoke
  arithmetic also saturates. If it wraps, that is a user-visible behaviour change and this issue
  says behaviour is unchanged — raise it rather than silently adopting saturation.
• activity_cursor is a bare index into a live list. vimcode re-syncs extension panels via
  sync_ext_activity_panels (shell_app.rs:1169); if panels are added or removed while the bar is
  focused, the cursor can silently come to rest on a different item than before. Worth one test.

5. Two symbols in the issue body no longer exist

The "What vimcode hand-rolls today" section names toolbar_focused and toolbar_selected in
TuiSidebar. Both are 0 occurrences in src/ today — they are now engine.activity_bar_focused
(31 occurrences) and engine.activity_bar_selected (20). kbd_sel does still exist (5
occurrences, panels.rs:32).

The "Unblocked" note already warns that the mod.rs:1770-1804 line numbers are pre-#634; the
symbol names drifted too. Re-locate by symbol in the current shell_app.rs / panels.rs, and
do not go looking for toolbar_selected.

All five quadraui#386 methods this issue names — activity_select_next / _prev,
activity_selected_id, activity_activate_selected, set_activity_keyboard_focused — exist and
are public (app_shell.rs:270-325), so the API side is ready.

[JDonaghy]

Coordinator Assignment

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

Briefing

Issue #536: Migrate activity-bar keyboard nav onto quadraui AppShell (retire hand-rolled toolbar_selected arithmetic) — consume quadraui#386

Context

Activity-bar keyboard navigation (the j/k selection ring + l/Enter activate + h/Esc dismiss) is being lifted out of vimcode and into quadraui's AppShell — see quadraui#386. vimcode currently owns this behavior with hand-rolled state because the AppShell API didn't exist when it was written. Once #386 lands, vimcode should consume the shared implementation so the logic lives in one place.

What vimcode hand-rolls today

• kbd_sel + manual ActivityBar primitive construction — src/tui_main/panels.rs:32, :93 (bottom Settings), :101.
• Toolbar nav state — toolbar_focused: bool, toolbar_selected: u16 in TuiSidebar (src/tui_main/mod.rs:333-335).
• The cursor arithmetic — the bespoke 0→1…→6→8…→max_ext→7(settings) up/down sequencing in src/tui_main/mod.rs:1770-1804, plus the l/Enter/Esc activate-dismiss handling at :1805-1865.

That index arithmetic (settings pinned last, extension panels spliced at 8+) is exactly the "cursor spanning top_items then bottom_items as one sequence" that quadraui#386 standardizes.

Goal

Retire vimcode's bespoke activity-bar nav state/arithmetic by delegating to AppShell's cursor from quadraui#386, while keeping vimcode's manual activity-bar rendering (vimcode is a manual-layout app — it does NOT use the ShellApp chrome renderer, so this is not a request to adopt that).

Concretely after #386:

• Replace toolbar_selected index math (mod.rs:1770-1804) with app_shell.activity_select_next() / activity_select_prev().
• Replace kbd_sel(idx) (panels.rs:32) with app_shell.activity_selected_id() when building each ActivityItem's is_keyboard_selected — vimcode still constructs the primitive, but reads the selected id from the shared cursor.
• Route the l/Enter activation through activity_activate_selected() (emits the same panel-change vimcode already handles).
• Keep toolbar_focused as the local "is the bar focused" gate, or fold into set_activity_keyboard_focused(true) if vimcode wants the backend ActivityBarEvent::KeyPressed routing too.

Open scope question

vimcode's activity bar includes dynamic extension panels (indices 8+) interleaved before Settings. quadraui#386's cursor must handle a variable panel count (top items + dynamic + bottom-pinned Settings) for vimcode to fully delegate; if #386 only covers static panels, vimcode keeps local handling for the ext-panel range. Confirm #386's cursor supports dynamic panels, or scope this migration to the static panels only.

Acceptance

• Behavior unchanged: j/k move the ring (incl. settings-last ordering and ext-panel splice), l/Enter activate, h/Esc dismiss — verified against current behavior.
• The bespoke index arithmetic in mod.rs:1770-1804 and kbd_sel are gone (or reduced to the ext-panel range only, per the scope question).
• Existing toolbar-nav tests still pass.

Blocked by

• quadraui#386 (lift activity-bar keyboard nav into AppShell). File/land that first.

---

Unblocked 2026-08-26 — quadraui#386 has LANDED

The "Blocked by" section above is stale. quadraui#386 (AppShell: keyboard-selectable
activity bar) is CLOSED. This is now a pure vimcode-side adoption — the exact
"infra landed but the adoption issue never got picked up" shape GOALS.md exists to catch.

The open scope question above still stands and is the first thing to settle in-session:
confirm whether #386s cursor handles a variable panel count (top items + dynamic
ext panels at 8+ + bottom-pinned Settings). If it only covers static panels, scope this to
the static range and say so in the PR rather than half-migrating.

Note the TUI has since moved onto run_with_shell (#634), so the line references below
point into the pre-cutover layout — re-locate toolbar_selected / kbd_sel in the current
src/tui_main/shell_app.rs + panels.rs rather than trusting the old mod.rs:1770-1804.

Files

• src/tui_main/shell_app.rs
• src/tui_main/panels.rs
• src/tui_main/mod.rs

Out of scope

• Adopting the ShellApp chrome renderer for the activity bar. vimcode still constructs
  the primitive itself; this issue moves only the nav state/arithmetic.

[JDonaghy]

Coordinator: Assignment Failed

Machine: dellserver
Status: failed
Exit code: —
Duration: —
Log: /home/john/.coord/logs/78378baad41e.log

Error

pull failed for quadraui: git pull --ff-only failed: You are not currently on a branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

git pull <remote> <branch>

[JDonaghy]

Coordinator: Assignment Complete

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

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: 2m 41s
Log: /home/john/.coord/logs/339ad945dd0a.log

[JDonaghy]

Coordinator Assignment

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

Briefing

You are fixing a failed smoke test for issue #536: [retry] Migrate activity-bar keyboard nav onto quadraui AppShell (retire hand-rolled toolbar_selected arithmetic) — consume quadraui#386

The previous worker created branch issue-536-migrate-activity-bar-keyboard-nav-onto-q. You are already on that branch.
Do NOT start over — work from the existing code.

What was done

The previous worker's changes are already committed on this branch.
Run git fetch origin && git log --oneline origin/develop..HEAD to see what was done.
Run git diff origin/develop...HEAD to see the full diff.

Test failure

…(truncated)…
4003/build-script-build` (exit status: 101)
--- stdout
OUT_DIR = Some(/home/john/.coord/confirm-worktrees/vimcode-issue-536-migrate-activity-bar-keyboard-nav-onto-q/target/debug/build/vimcode-e5fe5ce32734b9d7/out)
OPT_LEVEL = Some(0)
TARGET = Some(x86_64-unknown-linux-gnu)
CARGO_ENCODED_RUSTFLAGS = Some()
HOST = Some(x86_64-unknown-linux-gnu)
cargo:rerun-if-env-changed=CC_x86_64-unknown-linux-gnu
CC_x86_64-unknown-linux-gnu = None
cargo:rerun-if-env-changed=CC_x86_64_unknown_linux_gnu
CC_x86_64_unknown_linux_gnu = None
cargo:rerun-if-env-changed=HOST_CC
HOST_CC = None
cargo:rerun-if-env-changed=CC
CC = None
cargo:rerun-if-env-changed=CC_ENABLE_DEBUG_OUTPUT
RUSTC_WRAPPER = None
cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some(true)
CARGO_CFG_TARGET_FEATURE = Some(fxsr,sse,sse2)
cargo:rerun-if-env-changed=CFLAGS
CFLAGS = None
cargo:rerun-if-env-changed=HOST_CFLAGS
HOST_CFLAGS = None
cargo:rerun-if-env-changed=CFLAGS_x86_64_unknown_linux_gnu
CFLAGS_x86_64_unknown_linux_gnu = None
cargo:rerun-if-env-changed=CFLAGS_x86_64-unknown-linux-gnu
CFLAGS_x86_64-unknown-linux-gnu = None
cargo:rerun-if-env-changed=AR_x86_64-unknown-linux-gnu
AR_x86_64-unknown-linux-gnu = None
cargo:rerun-if-env-changed=AR_x86_64_unknown_linux_gnu
AR_x86_64_unknown_linux_gnu = None
cargo:rerun-if-env-changed=HOST_AR
HOST_AR = None
cargo:rerun-if-env-changed=AR
AR = None
cargo:rerun-if-env-changed=ARFLAGS
ARFLAGS = None
cargo:rerun-if-env-changed=HOST_ARFLAGS
HOST_ARFLAGS = None
cargo:rerun-if-env-changed=ARFLAGS_x86_64_unknown_linux_gnu
ARFLAGS_x86_64_unknown_linux_gnu = None
cargo:rerun-if-env-changed=ARFLAGS_x86_64-unknown-linux-gnu
ARFLAGS_x86_64-unknown-linux-gnu = None
cargo:rustc-link-lib=static=tree_sitter_latex
cargo:rustc-link-search=native=/home/john/.coord/confirm-worktrees/vimcode-issue-536-migrate-activity-bar-keyboard-nav-onto-q/target/debug/build/vimcode-e5fe5ce32734b9d7/out
cargo:rerun-if-changed=/home/john/.coord/confirm-worktrees/vimcode-issue-536-migrate-activity-bar-keyboard-nav-onto-q/quadraui-pin.txt
cargo:rerun-if-env-changed=VIMCODE_QUADRAUI_UNPINNED
cargo:rustc-env=VIMCODE_QUADRAUI_PINNED_REV=f6d27c239203e28525ac1798d07a31a9dbe9729a
cargo:rerun-if-changed=/home/john/src/quadraui/.git/HEAD
cargo:rerun-if-changed=/home/john/src/quadraui/.git/packed-refs
cargo:rerun-if-changed=/home/john/src/quadraui/.git/refs/heads/develop
cargo:rustc-env=VIMCODE_QUADRAUI_REV=5a418cac9f9a5cb5a8470a6bf011c4358a7f1704

--- stderr

thread 'main' (1612511) panicked at build.rs:227:5:

┌─ QUADRAUI PIN MISMATCH (issue #638) ───────────────────────────────
│ vimcode is pinned to a specific quadraui commit, but the sibling
│ checkout is on a different one. quadraui is a path dependency, so
│ Cargo.lock cannot pin it and this difference would otherwise change
│ vimcode's behaviour with no vimcode commit to explain it (#625).
│
│ pinned (quadraui-pin.txt): f6d27c239203e28525ac1798d07a31a9dbe9729a
│ checkout HEAD: 5a418cac9f9a5cb5a8470a6bf011c4358a7f1704
│ checkout path: /home/john/src/quadraui/quadraui
│
│ Pick one:
│
│ 1. Build against the pin (normal case):
│ git -C ../quadraui fetch origin
│ git -C ../quadraui checkout f6d27c239203e28525ac1798d07a31a9dbe9729a
│
│ 2. Bump the pin deliberately, then run the tests so any rendering
│ change lands as a reviewable, attributable commit:
│ # put the new sha in quadraui-pin.txt
│ cargo test
│
│ 3. Co-developing quadraui? Opt out for this build only:
│ VIMCODE_QUADRAUI_UNPINNED=1 cargo build
│ (Uncommitted edits at the pinned rev need no opt-out.)
└────────────────────────────────────────────────────────────────────

note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

Guidance

Fix the failing tests and push.

Rules

• Do NOT start over or rewrite from scratch
• Fix the specific test failures
• Commit your fixes and push with git push origin HEAD

[JDonaghy]

Coordinator: Assignment Complete

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