What happened?

The installed app can enter a shell-stuck state where core navigation no longer works: clicking an existing session, New session, or Settings does not change the visible page.

This is not just one broken button. The same user-visible failure can come from several shell-level state paths: route state, visible session state, interaction locks, and blocker recovery. Recent local fixes such as #415 hardened route helpers and resize locks, but the current recurrence shows the shell still lacks a durable architecture boundary for global navigation and interaction state.

Observed in PawWork 2026.5.4:

• clicking an existing session did not switch the visible session
• clicking New session did not open the new-session view
• clicking Settings did not open settings
• keyboard activation of New session also did not complete navigation
• renderer diagnostics showed route/session state moving toward a new-session view while the DOM still displayed the previous session
• database state did not show a matching unresolved running tool part, so this should not be treated as only a stale tool-part bug

This blocks normal use of the app and should be treated as a P0 shell reliability bug. The likely fix is not another point patch. The shell needs a focused refactor so navigation, interaction locks, blocker recovery, and visible route state have clear owners and testable invariants.

Area: App flow or product behavior; UI or design system

Impact: Blocks me from using PawWork

Steps to reproduce

Observed in the installed app once in the current session:

1. Open PawWork 2026.5.4 on macOS.
2. Use a long-running or recently interrupted session that has exercised tool calls, question blockers, worktree/session state, and sidebar navigation.
3. Click another session in the sidebar.
4. Click New session.
5. Click Settings.
6. Observe that the visible page remains on the previous session even though controls can receive focus.

This may require a race or stale shell state and is not yet reduced to a deterministic minimal repro.

What did you expect to happen?

Global shell actions should be reliable and recoverable:

• New session should open the new-session view.
• Existing session rows should switch the visible session.
• Settings should open settings.
• If navigation cannot commit, the UI should show a visible recovery or failure state instead of silently staying on stale content.
• Question or permission blockers should always produce a visible composer blocker or recovery state when assistant progress is waiting on user action.

PawWork version

2026.5.4

OS version

macOS 26.3.1

Can you reproduce it again?

Only once so far

Diagnostics

Current hotspot:

• packages/app/src/pages/layout.tsx
  • currently about 2,229 lines / 76 KB
  • owns too many unrelated shell responsibilities: navigation, settings, sidebar state, workspace state, resize/drag interaction state, deep links, dialogs, and session prefetching

Related areas:

• packages/app/src/pages/layout/helpers.ts
• packages/app/src/pages/session/session-view-controller.ts
• packages/app/src/pages/session/blockers/use-session-blockers.ts
• packages/app/src/pages/session/blockers/question-fallback.ts
• packages/ui/src/components/resize-handle.tsx
• docs/design/STANDARDS.md
• docs/DESIGN.md

Design/source notes:

• docs/design/STANDARDS.md contains locked design standards and can be used as the confirmed standard reference.
• docs/design/ prototypes and assets are reference material only unless separately locked. They should not be treated as fully accepted product direction by this issue.

Related issues / PRs:

• fix: harden interaction locks and session routes #415 hardened route helpers and resize interaction locks, but only as a local fix.
• [Bug] Question tool can block a session without showing the question UI #419 tracks invisible question UI when a question tool blocks the assistant flow.
• [Feature] foundation: PawWork-native UI primitives to stop the CSS override tax #210 tracks PawWork-native UI primitives to reduce CSS override tax, but is not a full frontend rewrite.

Architecture direction for the fix:

• Split shell-level responsibilities from packages/app/src/pages/layout.tsx into focused modules, likely including:
  • shell navigation: new session, open session, open project, open settings
  • shell interaction state: resize, modal, drag, global lock ownership and release
  • sidebar/session list state: sorting, pinning, grouping, current selection
  • workspace actions: rename, close, reset, drag order
  • settings open/close and tab state
  • session prefetch/cache warming
• Establish durable invariants for route intent, visible session state, blocker recovery, and global interaction locks.
• Add targeted regression coverage for shell invariants before or alongside refactoring.

Suggested verification:

• Unit tests for shell navigation state transitions:
  • new session
  • open existing session
  • open settings
  • route intent committed versus failed/recovered
• Tests for interaction lock acquire/release:
  • resize ends by mouseup/pointerup/cancel/blur/timeout
  • stale locks cannot block shell navigation indefinitely
• Regression coverage for blocker recovery:
  • a pending/running question or permission must produce a visible composer blocker or recovery state
  • missed events must be recoverable from durable session/tool/question state
• E2E coverage for the user path:
  • after resize or blocker recovery, the user can still click New session, switch sessions, and open Settings
• Confirm layout.tsx is reduced to composition/orchestration only, with new behavior landing in focused files that stay small enough to read in one pass.

Execution mode: agent should investigate and propose a plan first.