[quickbeard]

What was wrong

#289 was my change, and it did not deliver what it claimed. It reordered the @ menu's groups so files rank ahead of agents and references — but on a bare @ the menu contained no files to reorder:

if (!query.trim()) return [...fixed, ...recent]   // never searches

The resolver answered an empty query from the fixed entries (references, agents, MCP resources) plus open editor tabs, without ever calling searchContextFiles. With no tabs open there were no files at all — exactly what the screenshot shows: @ offering only @explore and @general.

This is the same empty-query gap #56 fixed for the TUI and the codev run footer. I ported that PR's ordering to the V2 composer and missed its fetch, so the reorder was invisible.

Fix

Search on every query, empty included. Verified the backend already answers a bare query — the default fff-backed search returns its top-ranked entries for an empty needle:

EMPTY: [package.json,src/index.ts,tsconfig.json,test/brand.test.ts]

Plus one thing that empty queries exposed: fff ranks the worktree root itself into an empty-query result, so / — a mention naming no file — would have led every list. The ripgrep fallback never emits it, so fffLayer now drops it and both layers answer the same way. That fixes the TUI's bare @ too.

Verification

I did not want to hand you another "it should work now", so this one is verified in a real browser.

• New e2e (prompt-at-menu-files.spec.ts): drives Chromium, types @, asserts the empty query reaches the search backend and that src/index.ts appears before the agents. Passes with the fix, fails without it (confirmed by reinstating the short-circuit and re-running).
• New unit tests (test-browser/prompt-at-menu.test.ts): the resolver searches on a bare @, and open tabs still lead without being listed twice. Also confirmed failing against the old behavior.
• Writing the e2e caught a genuine mistake in my own test setup — the app's file search goes through the v1 SDK (/find/file, plain string paths), not the v2 /api/fs/find route returning Entry objects. My first mock returned entries and crashed the app with input.startsWith is not a function. Corrected; no production code was involved.
• bun run test:unit 690 pass, test:browser 117 pass, typecheck clean in app, core, session-ui; core search suite 7 pass.

Mock-server change: an agents config field (defaulting to today's single primary agent) so a spec can supply subagents — the @ menu hides primary agents, so the default list left nothing to rank files against.

DIVERGENCES: the #289 row amended to record the empty-query fetch (its ordering claim alone was incomplete), plus a new row for the root-entry filter and the mock field. CHANGELOG entry under Desktop / Web UI.

🤖 Generated with Claude Code