## Context

The current mobile experience for complex configuration and workspace pages is inadequate:

- **Tool Workshop** (desktop split-pane): List on left, detail/edit form on right. On mobile, both panels are cramped and unusable.
- **Config Profiles** (desktop split-pane): Same issue as Tool Workshop, plus it's completely inaccessible from mobile navigation.
- **Repo Workspace**: Shows file tree, editor, git toolbar, and terminal all competing for space. On mobile, nothing is usable.

Desktop layouts work well and should remain unchanged. This design focuses exclusively on mobile-first responsive alternatives.

## Goals / Non-Goals

**Goals:**
- Make Tool Workshop and Config Profiles fully usable on mobile
- Add Config Profiles to mobile navigation (grouped under "Tools")
- Redesign Repo Workspace for mobile with clear primary/secondary view hierarchy
- Maintain desktop experience exactly as-is
- Use consistent patterns across all mobile configuration pages

**Non-Goals:**
- No changes to desktop layouts or navigation
- No API or database changes
- No changes to existing components' desktop behavior
- Not a full redesign of the web app (focused on these 3 pages)

## Decisions

### 1. List→Detail Navigation Pattern
**Decision:** Use iOS Settings-style list→detail navigation for Tool Workshop and Config Profiles.  
**Rationale:** Native mobile pattern users already understand. Works well for browsing and editing items. Allows full-screen forms without cramped split-panes.  
**Alternative considered:** Bottom sheets for editing - rejected because complex forms need full-screen space.

### 2. Bottom Sheet for Tools Group
**Decision:** Tapping "Tools" in mobile nav opens a bottom sheet with "Tool Workshop" and "Config Profiles" options.  
**Rationale:** Keeps bottom nav to 5 items (standard mobile pattern). Groups related functionality logically. Bottom sheet is fast and discoverable.  
**Alternative considered:** Separate nav items - rejected because 6 items is too many for bottom nav.

### 3. Read-First Detail View
**Decision:** Detail view shows read-only information first, with an "Edit" button to enter edit mode.  
**Rationale:** Prevents accidental edits. Allows quick scanning of configuration without entering edit mode. Matches mobile app patterns (view then edit).  
**Alternative considered:** Direct edit mode - rejected because users often just want to view, not edit.

### 4. File Tree as Primary Repo Workspace View
**Decision:** Mobile Repo Workspace shows file tree first, with bottom tabs to switch to Editor, Git, or Terminal.  
**Rationale:** File tree is the natural starting point for navigation. Bottom tabs provide quick access to other views without losing context.  
**Alternative considered:** Tabbed interface at top - rejected because bottom tabs are more thumb-friendly on mobile.

### 5. Full-Screen Edit Mode
**Decision:** Edit forms open as full-screen pages with back navigation, not modals.  
**Rationale:** Complex forms with many fields need maximum screen real estate. Back navigation is a clear mental model.  
**Alternative considered:** Modal overlays - rejected because they feel cramped on mobile for long forms.

## Risks / Trade-offs

**Risk:** Users may find the list→detail pattern slower than split-pane for quick edits.  
→ **Mitigation:** Optimize for the most common flow (view first, edit only when needed). Add quick actions (delete, duplicate) directly in list view.

**Risk:** Switching between Editor, Git, and Terminal in Repo Workspace may feel disconnected.  
→ **Mitigation:** Keep the current file/repository context across tab switches. Show repository name persistently.

**Risk:** Two different UX patterns (desktop split-pane vs mobile list→detail) may confuse users who switch devices.  
→ **Mitigation:** This is standard responsive design practice. Both patterns are well-established in their respective contexts.

**Trade-off:** Mobile pages require more taps to accomplish the same tasks.  
→ **Acceptance:** This is inherent to mobile form factors. The trade-off is acceptable for improved usability.

## Migration Plan

No migration needed - this is purely additive UI work. Steps:
1. Create new mobile-specific components
2. Update page components to render mobile layouts conditionally
3. Update mobile navigation
4. Test on mobile devices

Rollback: Remove conditional mobile rendering, revert to desktop-only layouts.
