# Research: Bottom Navigation with Chat Entry

## Decision: Bottom navigation pattern
- **Chosen**: Use GoRouter shell route with Riverpod-owned tab state to keep the bottom bar persistent and preserve per-tab navigation stacks.
- **Rationale**: Aligns with NAVIGATION_GUIDE and Constitution (GoRouter + Riverpod ownership); keeps state per tab, enables deep links, and avoids manual state loss on tab switch.
- **Alternatives considered**: 
  - Manual `IndexedStack` without router integration—rejected because deep links and guard handling become brittle.  
  - Custom TabController without shell routing—rejected due to duplicated routing logic and harder guard enforcement.

## Decision: Store selection/resilience
- **Chosen**: Reuse existing store context provider and store list endpoint via `api_client.dart`; show current store on the tab; confirm switch with warning on unsaved work; surface offline/empty/error states with retry.
- **Rationale**: Matches Constitution contract fidelity (single HTTP entry point), keeps UX consistent, and protects users from losing work during store changes.
- **Alternatives considered**:
  - Silent switch without confirmation—rejected because it risks data loss on in-progress forms.  
  - Duplicating store fetch logic per screen—rejected to avoid drift and duplicate API calls.

## Decision: Chat entry placeholder
- **Chosen**: Expose a Chat tab that opens a chat container with clear availability messaging (“coming soon”/offline) and allows immediate return to other tabs.
- **Rationale**: Builds user familiarity with the chat location while deferring backend integration; keeps navigation responsive even offline.
- **Alternatives considered**:
  - Hiding the chat tab until backend is live—rejected because it delays user education and future rollout complexity.  
  - Opening an external link/modal—rejected to maintain consistent in-app navigation and guard behavior.