docs(03): capture phase context

This commit is contained in:
2026-03-26 14:30:40 +01:00
parent e17419bfd0
commit dc8aa85dcd
@@ -0,0 +1,90 @@
# Phase 3: Wizard UI - Context
**Gathered:** 2026-03-26
**Status:** Ready for planning
<domain>
## Phase Boundary
Multi-step wizard UI from backend selection through deployment options. Delivers the full navigation shell (Backend → Remote Config → Deployment) with all form fields, state wiring to the existing store, and step-to-step navigation. Review/download is Phase 4.
</domain>
<decisions>
## Implementation Decisions
### Backend Selection Layout
- Clickable card grid — 3 cards for Azure Blob, Amazon S3, S3-Compatible
- Clicking a card auto-advances to the config step (no explicit Next button on step 1)
- Remote name field (WIZD-04) appears at the TOP of step 1, before the backend cards
- Name field validated: alphanumeric, dashes, underscores only — inline error shown after first Next attempt
### Azure Credential Toggle
- Segmented control / radio toggle to switch between "SAS URL" and "Access Key" auth methods
- Default auth method: SAS URL (pre-selected on first load)
- Switching auth method PRESERVES both fields in state (inactive field hidden but value kept) — generator must strip the inactive field at config generation time
- All password-type fields (access key, SAS URL, S3 secret) have a show/hide eye toggle
### Step Progress Indicator
- Labeled breadcrumb: **1. Backend 2. Remote Config 3. Deployment**
- Completed steps show checkmark + muted text (e.g., "✓ Backend") and are clickable to jump back
- Current step shown as bold/active
- Clicking a completed step navigates directly to it (not just Back button)
### Forward Navigation Validation
- Required fields: Next button blocked if required fields are empty/invalid
- Error display: errors shown ONLY after first Next click, then update live as user fixes them (no errors while initially filling)
- Inline error messages below each invalid field
- Backend change (via breadcrumb click-back): clears `remote.params` since fields differ per backend; deployment options preserved
- Remote name validation shows inline error below the field after first Next attempt
### Claude's Discretion
- Exact Tailwind styling, card visual design, color palette
- Loading/transition animations between steps
- S3 and S3-Compatible config form layout (they share most fields)
- Deployment options step layout (fields are already defined in store: includeInstall, configPath, scriptTargets)
</decisions>
<code_context>
## Existing Code Insights
### Reusable Assets
- `useWizard()` hook (src/store/context.tsx): provides `state` and `dispatch` — all wizard components use this
- `wizardReducer` actions: `SET_STEP`, `SET_BACKEND_TYPE`, `SET_REMOTE_NAME`, `SET_REMOTE_PARAMS`, `SET_DEPLOYMENT`, `RESET` — all needed actions already exist
- `BACKEND_REGISTRY` (src/schemas/registry.ts): drives config form rendering — field definitions (key, label, inputType, required, options) per backend type
- `INITIAL_STATE.deployment.scriptTargets` defaults to `['intune', 'rmm']` — users deselect rather than discover
### Established Patterns
- Tailwind v4 via `@tailwindcss/vite` plugin — no config file, utility-first
- `WizardProvider` wraps `App` — wizard state always available in all components
- `remote.params: Record<string, string>` — flat key/value map, keys must match rclone config keys from registry
- Azure has two mutually exclusive auth fields: `key` and `sas_url` — both stored in `remote.params`, only active one used by generator
### Integration Points
- `src/App.tsx`: currently a placeholder shell — wizard step routing goes here
- `src/store/reducer.ts`: `SET_BACKEND_TYPE` already resets nothing — Phase 3 must handle params reset via `SET_REMOTE_PARAMS` when backend changes
- `src/schemas/index.ts`: `BACKEND_SCHEMAS` for Zod validation — forms use these schemas for react-hook-form validation
</code_context>
<specifics>
## Specific Ideas
- Backend cards should follow WIZD-01 ordering: Azure Blob and S3 appear first
- The toggle between SAS URL and Access Key is a UI-level concern — registry has both fields; generator (Phase 2 complete) already handles which field is present
- Step 3 (Deployment Options) maps directly to `state.deployment``includeInstall` toggle, `configPath` radio, `scriptTargets` checkboxes
</specifics>
<deferred>
## Deferred Ideas
None — discussion stayed within phase scope.
</deferred>
---
*Phase: 03-wizard-ui*
*Context gathered: 2026-03-26*