kawaandClaude Sonnet 4.6
ef0cd94eb7
4 phases, 18 plans, 24/24 requirements, 98 tests GREEN. Archived ROADMAP + REQUIREMENTS to milestones/. ROADMAP collapsed. PROJECT.md evolved with validated requirements and key decisions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
3.9 KiB
3.9 KiB
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.failstubs: 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:
DeploymentStepdispatchesscriptTargetsbutReviewStepignores 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:
buildRcloneConfContentduplicated inline in rmm-script.ts to avoid circular dependency risk - INITIAL_STATE defaults to both targets selected — users deselect rather than discover
Key Lessons
- Define data flow end-to-end before implementing any step: the
scriptTargetsdisconnect would have been caught if the full data flow (DeploymentStep → state → ReviewStep) had been traced before Phase 4 started - 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
- 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)
- Single source of truth (BACKEND_REGISTRY) eliminates entire classes of drift bugs
- Wave 0 TDD stubs are worth the upfront cost — they define the contract and make RED→GREEN progress visible