feat(code): convert navigationStore to router-derived facade

[adamleithp]

Stacks on top of #2456. Closes out the dual-source-of-truth concern raised in #2455's architect review: the Zustand navigationStore no longer holds its own view state — it's now a thin facade that derives view from the router and the React Query task cache on every render.

What changed

useNavigationStore keeps the same public API surface ((selector?), .getState(), .setState()) so the ~91 existing call sites don't change. Internally:

• No Zustand state. Hook subscribes to useRouterState + useTaskInputPrefillStore to know when to re-render. Snapshot is rebuilt from those two sources on every call.
• view.data populates from cache. getCachedTask(taskId) in @utils/queryClient walks the React Query ["tasks", "list"] queries. Consumers reading view.data?.id keep working; the value is just undefined until useTasks() resolves (same as the deep-link case in the old store).
• Actions delegate. Each navigateTo* action calls a navigationBridge function. goBack/goForward use router.history. No more syncToRouter (no state to mirror).
• Transient TaskInput prefill moves out. initialPrompt, reportAssociation, initialCloudRepository, initialModel, initialMode, folderId, taskInputRequestId now live in useTaskInputPrefillStore (introduced in feat(code): TanStack Router architectural cleanup #2456 for exactly this). navigateToTaskInput(options) writes prefill → navigates to /code. The derived view reads prefill and surfaces those fields under view.* exactly like before.
• Async side effects preserved. navigateToTask still does the workspace/folder reconciliation it always did — that logic is unchanged.
• Analytics context now fires from a router.subscribe("onResolved") listener at module init instead of from inside each action.

Persistence, the history stack, and hydrateTask are deleted. Persistence is replaced by router URL + the cold-boot localStorage restore from #2456. The history stack is replaced by router.history. hydrateTask becomes a no-op — the URL is the source of truth, no rehydration needed.

New helpers in navigationBridge

• getCurrentMatches(), getCurrentLocation() — non-React router state accessors.
• subscribeToRouterResolved(handler) — hook into route resolution from outside React.
• goForwardInHistory() — for symmetry with goBackInHistory.

These keep the store cycle-free (navigationStore never imports @renderer/router directly).

Files touched

File	Change
stores/navigationStore.ts	rewritten (~400 lines → ~200)
stores/navigationStore.test.ts	rewritten (~290 → ~200, 16 → 12 tests)
routes/code/tasks/$taskId.tsx	removed obsolete URL→store sync effect
navigationBridge.ts	added 4 helpers
utils/notifications.test.ts	mocks useNavigationStore.getState directly

What's NOT in this PR

• Settings store consumers (PR 7): the settingsDialogStore is still alive. Its consumers can move to useNavigate / <Link/> directly once this lands.
• Literal deletion of the file. navigationStore.ts still exists as a hook export. Removing the file means migrating all 91 call sites to useNavigate/useParams/useMatch. Worth doing, but the diff would dwarf the architectural change in this PR. I'd schedule it as PR 8 once the facade has run in production for a release cycle.

Test plan

Automated (passing):

• Renderer typecheck (pnpm exec tsc -p tsconfig.web.json --noEmit)
• Vitest suite — 131 files / 1594 tests pass (down from 1598: 4 deleted persistence/history tests no longer apply)
• Biome lint clean

Manual (please verify):

• All previous flows from feat(code): introduce TanStack Router file-based routing #2455 + feat(code): TanStack Router architectural cleanup #2456 still work
• Sidebar highlight tracks the active task across clicks
• view.data populates correctly in HeaderRow task section (skill buttons, diff stats badge, etc.) when viewing a task
• Cloud + local task headers still render (consumers in GlobalEventHandlers that pass view.data to handoff buttons)
• useArchiveTask still navigates away from an archived task correctly (it reads view.data to detect the current task)
• Deep link to a task that isn't in the task list yet → view.data is undefined briefly, then populates once useTasks resolves (same behavior as before, this case existed previously)
• Settings UX from feat(code): TanStack Router architectural cleanup #2456 still works
• Devtools panel shows current route correctly in dev mode

🤖 Generated with Claude Code

[greptile-apps]

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
apps/code/src/renderer/stores/navigationStore.ts:259-261
`hydrateTask` is defined as an inline arrow function inside `getSnapshot()`, which means a new function reference is created on every call. `__root.tsx` destructures `hydrateTask` from `useNavigationStore()` and places it in a `useEffect` dependency array (`[tasks, hydrateTask]`). Because the reference is never the same across renders, that effect fires on every render of `RootLayout` instead of only when `tasks` changes. The effect body is harmless today (calls a no-op), but the fire frequency is a regression from the old store where Zustand guaranteed stable function references.

```suggestion
    hydrateTask,
```

### Issue 2 of 2
apps/code/src/renderer/stores/navigationStore.ts:257-258
`canGoBack` and `canGoForward` are also inline functions, giving them the same unstable-reference problem as `hydrateTask`. They currently have no call sites, but any future consumer that puts them in a `useCallback` or `useEffect` dependency array would get unexpected re-runs. Lifting them to module-level stubs makes the snapshot fully stable and consistent with the module-level action functions.

```suggestion
    canGoBack,
    canGoForward,
```

_{Reviews (1): Last reviewed commit: "feat(code): convert navigationStore to r..." | Re-trigger Greptile}

[greptile-apps]

hydrateTask is defined as an inline arrow function inside getSnapshot(), which means a new function reference is created on every call. __root.tsx destructures hydrateTask from useNavigationStore() and places it in a useEffect dependency array ([tasks, hydrateTask]). Because the reference is never the same across renders, that effect fires on every render of RootLayout instead of only when tasks changes. The effect body is harmless today (calls a no-op), but the fire frequency is a regression from the old store where Zustand guaranteed stable function references.

Suggested change

	hydrateTask: () => {
	/* No-op: the URL is the source of truth now. */
	},
	hydrateTask,

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/stores/navigationStore.ts
Line: 259-261

Comment:
`hydrateTask` is defined as an inline arrow function inside `getSnapshot()`, which means a new function reference is created on every call. `__root.tsx` destructures `hydrateTask` from `useNavigationStore()` and places it in a `useEffect` dependency array (`[tasks, hydrateTask]`). Because the reference is never the same across renders, that effect fires on every render of `RootLayout` instead of only when `tasks` changes. The effect body is harmless today (calls a no-op), but the fire frequency is a regression from the old store where Zustand guaranteed stable function references.

```suggestion
    hydrateTask,
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

canGoBack and canGoForward are also inline functions, giving them the same unstable-reference problem as hydrateTask. They currently have no call sites, but any future consumer that puts them in a useCallback or useEffect dependency array would get unexpected re-runs. Lifting them to module-level stubs makes the snapshot fully stable and consistent with the module-level action functions.

Suggested change

	canGoBack: () => true,
	canGoForward: () => true,
	canGoBack,
	canGoForward,

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/stores/navigationStore.ts
Line: 257-258

Comment:
`canGoBack` and `canGoForward` are also inline functions, giving them the same unstable-reference problem as `hydrateTask`. They currently have no call sites, but any future consumer that puts them in a `useCallback` or `useEffect` dependency array would get unexpected re-runs. Lifting them to module-level stubs makes the snapshot fully stable and consistent with the module-level action functions.

```suggestion
    canGoBack,
    canGoForward,
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[adamleithp]

🩹 Stabilization pass (commit 45fa39692)

Shaking this branch out surfaced three independent defects from the migration, all presenting as "routes stuck loading / navigation locked". All fixed here; verified live (new-task flow, deep links, cross-route nav, mid-load navigate-away).

Fixes

1. Circular import → broken code-split chunks. router → routeTree.gen → __root → hooks → navigationBridge → router produced a TDZ (Cannot access 'rootRouteImport' before initialization) under autoCodeSplitting, leaving route chunks stuck. Added routerRef (leaf module holding the singleton); navigationBridge now reads getRouter() instead of importing the router, severing the only route-tree edge back to router.ts.

2. Infinite render storm. useAppView returned a fresh object every render (the old navigationStore.view was a stable ref). SidebarMenu's [view] effect refired forever → markViewed mutation → cache write → re-render (~50×/2s, confirmed via [ipc-rate] warnings), starving the UI thread and blocking both navigation and session start ("Starting task…" hang). Memoized useAppView on the route's primitive values + stable prefill ref; SidebarMenu reads view.taskId.

3. Blocking loader could hang the router. ensureQueryData(getTask) never resolves for optimistic/cloud-pending tasks → route stuck pending → un-navigable. Task-detail loader is now synchronous + cache-only; the cold-deep-link fetch + spinner moved into the component so a hang only affects that view. openTask seeds the detail cache so in-app opens never fetch.

Also added (per-route loading UX)

Router context: { queryClient }, createRootRouteWithContext, defaultPendingMs: 0 + defaultPendingComponent (RoutePending). Navigation commits instantly with a per-route pending slot that can later become skeletons.

---

🛣️ Follow-up roadmap (separate PRs after the stack merges)

Full architect review exists locally; condensed:

• P0 — Delete useAppView. It re-derives a view-enum the router already owns (second source of truth) and requires hand-memoization — the footgun that caused defect chore: config housekeeping #2. Replace with primitive useRouterState selectors + per-route Route.useParams(); move the prefill merge into the /code/ route. Removes the storm class permanently.
• P1 — Rip out navigationBridge. Migrate call sites to typed <Link> / useNavigate(); they read the router from React context, removing the import cycle structurally so routerRef can also go.
• P1 — Add defaultErrorComponent + defaultNotFoundComponent. Currently none — a thrown loader/render = blank screen (runtime already warned about it).
• P1 — Finish loader integration + skeletons. Shared queryOptions per data route (pattern in features/tasks/queries.ts), loaders always non-blocking, per-route pendingComponent skeletons.
• P2 — Typed search params (validateSearch) as URL state to retire settingsPageStore / taskInputPrefillStore; auth as beforeLoad guards; tune defaultPendingMs once loaders are async.
• P3 — Regression test asserting the view hook returns a stable reference across re-renders (guards the storm forever) + a lint guard for hooks returning fresh objects.

routeTree.gen.ts intentionally left untouched — local generator output differs from the committed file only by quote/semicolon style; that's a formatter-config cleanup, out of scope here.

[adamleithp]

Superseded by #2469 — the three-PR stack is collapsed into a single PR (rebased on main, conflicts resolved, CI green: typecheck + biome + 1594 unit tests). No intermediate layer was independently green, so the stack was collapsed rather than fixed three times. Closing in favor of #2469.