# Project Retrospective

*A living document updated after each milestone. Lessons feed forward into future planning.*

## Milestone: v1.0 — MVP

**Shipped:** 2026-03-27
**Phases:** 4 | **Plans:** 18 | **Timeline:** 2 days

### What Was Built
- Backend Schema Registry as single source of truth driving form rendering, Zod validation, and config generation for 3 backends
- 4 pure generator functions (rclone.conf, Intune install/detection, RMM script) with 61 tests and strict PowerShell encoding/path requirements
- 4-step multi-step wizard (backend selection → config → deployment options → review/download) with full back-navigation
- Review and download layer: live preview, security gate, individual file downloads, ZIP bundle, clipboard copy

### What Worked
- **Inside-out build order** (foundation → generators → wizard UI → download layer): front-loaded high-risk correctness work (PowerShell encoding, SYSTEM-context paths, credential handling) before any UI existed — each phase was independently verifiable
- **Wave 0 TDD with `expect.fail` stubs**: defining the API contract in RED before implementation forced explicit interface design and caught integration issues upfront; named failure messages made debugging fast
- **BACKEND_REGISTRY as single source of truth**: zero field-name duplication between form rendering, Zod schemas, and config generation — no drift possible across phases
- **useReducer + Context API with no external state lib**: sufficient for a 4-step wizard, kept bundle lean

### What Was Inefficient
- **scriptTargets collected but never consumed**: `DeploymentStep` dispatches `scriptTargets` but `ReviewStep` ignores it — all output blocks render unconditionally. This was knowable at Phase 2 design time but deferred to v1.1 as tech debt
- **BACKENDS constant hardcoded in BackendSelectionStep**: adding to BACKEND_REGISTRY does not surface in UI — a maintainability gap that was an obvious fix but left unaddressed
- **ReviewStep missing Back button**: UX inconsistency with all other steps — a trivial add that was missed

### Patterns Established
- Wave 0 TDD pattern: stub all requirement behaviors RED before any implementation — use `expect.fail('not yet implemented')` not import errors
- Embed requirement IDs in test describe blocks (WIZD-01, BACK-02, etc.) for direct test-to-requirement traceability
- Generator functions self-contained: `buildRcloneConfContent` duplicated inline in rmm-script.ts to avoid circular dependency risk
- INITIAL_STATE defaults to both targets selected — users deselect rather than discover

### Key Lessons
1. **Define data flow end-to-end before implementing any step**: the `scriptTargets` disconnect would have been caught if the full data flow (DeploymentStep → state → ReviewStep) had been traced before Phase 4 started
2. **Registry-driven UI is strictly better than hardcoded lists**: the BACKEND_REGISTRY pattern proved its value — extending it for the UI selector should have been done at the same time
3. **Inside-out build order works well for correctness-heavy tools**: generator correctness (PowerShell encoding edge cases) was much easier to verify without UI noise

### Cost Observations
- Sessions: ~6 (4 execution phases + planning + verification)
- Notable: Pure frontend with no external API calls kept the scope tight — all phases parallelized within themselves

---

## Cross-Milestone Trends

### Process Evolution

| Milestone | Phases | Plans | Key Change |
|-----------|--------|-------|------------|
| v1.0 | 4 | 18 | Wave 0 TDD pattern established; inside-out build order validated |

### Cumulative Quality

| Milestone | Tests | Notes |
|-----------|-------|-------|
| v1.0 | 98 (12 files) | 24/24 requirements satisfied, 5/5 E2E flows |

### Top Lessons (Verified Across Milestones)

1. Single source of truth (BACKEND_REGISTRY) eliminates entire classes of drift bugs
2. Wave 0 TDD stubs are worth the upfront cost — they define the contract and make RED→GREEN progress visible