chore: archive v1.1 milestone — 3 phases, 11 plans, 11/11 requirements shipped
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,105 @@
|
||||
# Milestone v1.1: Backlog & Tech Debt
|
||||
|
||||
**Status:** ✅ SHIPPED 2026-03-31
|
||||
**Phases:** 5–7
|
||||
**Total Plans:** 11
|
||||
|
||||
## Overview
|
||||
|
||||
Ship all deferred tech debt and backlog features from v1.0 — scriptTargets filtering, UX consistency fixes, registry-driven backend list, 4 new backends, field validation, and contextual tooltips.
|
||||
|
||||
## Phases
|
||||
|
||||
### Phase 5: Tech Debt
|
||||
|
||||
**Goal**: The wizard behaves consistently and the codebase is clean — no visual noise from deselected script targets, ReviewStep has a Back button, BackendSelectionStep is driven by the registry, and dead code is removed
|
||||
**Depends on**: Phase 4 (v1.0 complete)
|
||||
**Requirements**: TECH-01, TECH-02, TECH-03, TECH-04, TECH-05
|
||||
**Plans**: 4 plans
|
||||
|
||||
Plans:
|
||||
- [x] 05-00: Wave 0 TDD stubs — ReviewStep filtering + Back button failing tests, registry.test.ts .fields prep
|
||||
- [x] 05-01: Registry enrichment (TECH-03) + consumers update + dead export removal (TECH-04)
|
||||
- [x] 05-02: ReviewStep scriptTargets filtering + Back button (TECH-01, TECH-02)
|
||||
- [x] 05-03: act() warnings fix — userEvent migration + vi.useFakeTimers (TECH-05)
|
||||
|
||||
**Success Criteria** (what must be TRUE):
|
||||
1. User who deselected RMM in DeploymentStep sees only the Intune output block in ReviewStep (and vice versa)
|
||||
2. User can click a Back button on ReviewStep to return to DeploymentStep without losing any form data
|
||||
3. Adding a new entry to BACKEND_REGISTRY automatically surfaces that backend in the BackendSelectionStep UI with no other code changes
|
||||
4. BackendSelectionStep test suite runs with zero `act()` warnings in the Vitest output
|
||||
5. `BackendFormValues<T>` export is absent from `src/schemas/index.ts` and no TypeScript errors arise
|
||||
|
||||
### Phase 6: New Backends
|
||||
|
||||
**Goal**: IT pros can configure OneDrive, SFTP, Google Cloud Storage, and Backblaze B2 remotes through the same wizard flow, with appropriate guidance for OAuth-based and key-based auth methods
|
||||
**Depends on**: Phase 5
|
||||
**Requirements**: BACK-01, BACK-02, BACK-03, BACK-04
|
||||
**Plans**: 4 plans
|
||||
|
||||
Plans:
|
||||
- [x] 06-00: Wave 0 TDD stubs — failing tests for all four new backends across registry, rclone-conf, and RemoteConfigStep
|
||||
- [x] 06-01: Registry + schema + RCLONE_TYPE_MAP for OneDrive, GCS, Backblaze B2
|
||||
- [x] 06-02: Registry + schema + RCLONE_TYPE_MAP for SFTP + SftpAuthToggle component
|
||||
- [x] 06-03: Wire all four backends into RemoteConfigStep + human verification
|
||||
|
||||
**Success Criteria** (what must be TRUE):
|
||||
1. User can select OneDrive as a backend, paste a pre-obtained rclone OAuth token, and generate a valid rclone.conf containing `[type = onedrive]` with the token field
|
||||
2. User can select SFTP as a backend, choose between password and private-key authentication, fill the appropriate fields, and generate a valid rclone.conf
|
||||
3. User can select Google Cloud Storage as a backend, fill in the required fields, and generate a valid rclone.conf containing `[type = google cloud storage]`
|
||||
4. User can select Backblaze B2 as a backend, enter their application key credentials, and generate a valid rclone.conf containing `[type = b2]`
|
||||
5. All four new backends appear in the BackendSelectionStep list and each produces a downloadable config+scripts bundle
|
||||
|
||||
### Phase 7: Validation & UX Polish
|
||||
|
||||
**Goal**: Users receive immediate inline feedback when they enter incorrectly formatted values, and can access plain-language explanations on confusing credential fields without leaving the wizard
|
||||
**Depends on**: Phase 6
|
||||
**Requirements**: VALID-01, UX-01
|
||||
**Plans**: 3 plans
|
||||
|
||||
Plans:
|
||||
- [x] 07-00: Wave 0 TDD stubs — failing tests for VALID-01 regex rejection/acceptance and UX-01 tooltip toggle
|
||||
- [x] 07-01: VALID-01 — FieldDef validate extension + buildZodSchema regex chaining for 3 fields
|
||||
- [x] 07-02: UX-01 — tooltipText in registry + FieldRenderer/PasswordField ⓘ toggle + AzureAuthToggle/SftpAuthToggle wiring + human verification
|
||||
|
||||
**Success Criteria** (what must be TRUE):
|
||||
1. User who enters an Azure storage account name shorter than 3 characters or containing uppercase letters sees an inline error message before they can advance
|
||||
2. User who enters an S3 region in an invalid format (e.g., spaces or uppercase) sees an inline error message
|
||||
3. User can hover or click a tooltip icon on sensitive fields (SAS token, access key, SFTP auth method, OneDrive token) and read a plain-language explanation without navigating away
|
||||
4. Tooltip content accurately distinguishes SAS token from storage account key in the Azure backend form
|
||||
|
||||
---
|
||||
|
||||
## Milestone Summary
|
||||
|
||||
**Key Decisions:**
|
||||
- BACKEND_REGISTRY shape enriched to `{ displayName, description, fields }` — single source of truth for display AND field data
|
||||
- WizardConsumerSetup pattern: in-test React component dispatches SET_DEPLOYMENT via useEffect (no production code changes)
|
||||
- Unmount OutputBlocks entirely (conditional render) not CSS hidden — avoids stale component state
|
||||
- GCS rclone type = 'google cloud storage' (with spaces) not 'gcs'
|
||||
- SftpAuthToggle follows AzureAuthToggle CSS-hidden pattern for auth method switching
|
||||
- OneDrive/GCS use paste-based token input (stateless browser-paste pattern)
|
||||
- Three-branch ternary in RemoteConfigStep (azureblob/sftp/else) — custom logic minimal; most backends render via registry loop
|
||||
- FieldDef extended with `validate` and `tooltipText` — additive, non-breaking to existing backends
|
||||
- ⓘ button placed as sibling outside label element (avoids label text contamination)
|
||||
- SFTP auth-method tooltip is section-level (above segmented control), not field-level
|
||||
|
||||
**Issues Resolved:**
|
||||
- scriptTargets disconnect in ReviewStep (TECH-01)
|
||||
- Missing Back button on ReviewStep (TECH-02)
|
||||
- Hardcoded backend list in BackendSelectionStep (TECH-03)
|
||||
- Dead `BackendFormValues<T>` export (TECH-04)
|
||||
- `act()` warnings in tests (TECH-05)
|
||||
|
||||
**Issues Deferred:**
|
||||
- 7 browser UI verifications still pending (inline validation error placement, tooltip toggle UX) — confirmatory, not discovery
|
||||
- FieldRenderer aria inconsistency between text-branch (sr-only span) and select-branch (direct aria-label) — cosmetic
|
||||
|
||||
**Technical Debt Incurred:**
|
||||
- Phase 7 VALIDATION.md has `nyquist_compliant: false` (phases 5 and 6 are compliant)
|
||||
- 07-01-SUMMARY.md missing `requirements-completed` field for VALID-01 (doc gap only — code verified)
|
||||
- Stale RED-state comments in RemoteConfigStep.test.tsx (features now implemented)
|
||||
|
||||
---
|
||||
|
||||
_For current project status, see .planning/ROADMAP.md_
|
||||
Reference in New Issue
Block a user