chore: archive v1.1 phase directories to milestones/v1.1-phases/
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 4.8
parent
a2890d1542
commit
c7955a46b9
@@ -0,0 +1,62 @@
|
||||
---
|
||||
status: complete
|
||||
phase: 12-initial-setup-wizard
|
||||
source: [12-VERIFICATION.md, 12-05-SUMMARY.md, 12-06-SUMMARY.md, 12-07-SUMMARY.md]
|
||||
started: 2026-06-16T19:41:30Z
|
||||
updated: 2026-06-16T20:05:00Z
|
||||
note: Fresh re-verification after gap-closure (gaps 1-6). Prior diagnosed run archived as 12-UAT.diagnosed.md. Dev env reset to fresh-install + API rebuilt so fixes are live.
|
||||
---
|
||||
|
||||
## Current Test
|
||||
|
||||
[testing complete — 6 passed, 1 blocked-by-environment (verified via tests); all 6 gaps confirmed closed]
|
||||
|
||||
## Tests
|
||||
|
||||
### 1. Wizard appears at root (redirect gate)
|
||||
expected: Browse to the app root. You are redirected to /setup and the wizard Instance step appears (clean env — setup is not complete).
|
||||
result: pass
|
||||
|
||||
### 2. Instance step copy + read-only DB-name field (gaps 1, 3)
|
||||
expected: On the Instance step, the intro copy does NOT contain the "These are written to the database — not your environment file" aside. A read-only / greyed-out field showing the DB name ("familysync") appears directly under the APP URL field, giving the "database connection verified" row an on-screen referent.
|
||||
result: pass
|
||||
|
||||
### 3. Back navigation preserves Instance config (gap 4)
|
||||
expected: Fill in the Instance fields, advance to the next step, then click Back. Your previously entered Instance values are still there (not blanked out).
|
||||
result: pass
|
||||
note: Not hand-tested (user completed wizard before reaching it). Verified via green PWA suite — SetupPage.test.tsx 'Back navigation preserves Instance fields (gap 4)': restores all four Instance values after Back from Calendar step, and does NOT persist the Fastmail password (T-12-15).
|
||||
|
||||
### 4. Invalid VAPID key fails validation (gap 2)
|
||||
expected: On the Instance step, enter a clearly-wrong VAPID public key (e.g. "BH123") and run Save & Validate. The VAPID row FAILS (does not go green) and Continue stays disabled. Replacing it with the correct VAPID_PUBLIC_KEY makes the VAPID row pass.
|
||||
result: pass
|
||||
note: Not hand-tested in isolation (user completed wizard with the correct key, which the green path required). Verified via tests — apps/api setup.test.ts asserts validate/vapid rejects a public key != env VAPID_PUBLIC_KEY; SetupPage.test.tsx 'does NOT show Continue when VAPID validation fails' + 'shows Continue only when db, oidc, AND vapid all pass'. The completed run also proves the positive case (real key stored, setup_complete).
|
||||
|
||||
### 5. Complete the wizard end-to-end (happy path)
|
||||
expected: With Authelia reachable and correct VAPID env, the Instance step's DB + OIDC + VAPID rows all go green. The Calendar step validates a real Fastmail app password via a live CalDAV PROPFIND. POST /api/setup/complete returns 200 and the "Setup complete" terminal screen appears.
|
||||
result: pass
|
||||
note: Confirmed by user + DB evidence (setup_complete=true, credential me@lucasberger.ca stored against unclaimed wizard user id=6).
|
||||
|
||||
### 6. /setup locks after completion (gap 5)
|
||||
expected: After completing setup, manually navigate to /setup. You see the "setup already complete" surface — NOT the wizard re-mounted.
|
||||
result: pass
|
||||
|
||||
### 7. Calendar banner clears after wizard (gap 6)
|
||||
expected: After finishing the wizard and landing on /calendar, the "Set up your calendar / Set up now" banner does NOT show (the wizard-stored Fastmail credential is linked to your operator identity, so needsProviderSetup is false).
|
||||
result: blocked
|
||||
blocked_by: third-party
|
||||
reason: "Not exercisable under DEV_AUTH_BYPASS — the bypass injects a static DEV_USER (id=1) and /me short-circuits, so upsertUser's first-login-claim never runs. Banner-clear (and the wizard→operator admin claim) require the real Authelia/OIDC login path, which this dev box lacks. Verified instead by the green test suite: SetupBanner.test.tsx / App.test.tsx (gap 6) + user.test.ts D-08 first-login-claims (claims unclaimed wizard user, preserves is_admin)."
|
||||
|
||||
## Summary
|
||||
|
||||
total: 7
|
||||
passed: 6
|
||||
issues: 0
|
||||
pending: 0
|
||||
skipped: 0
|
||||
blocked: 1
|
||||
gaps: 0
|
||||
note: All 6 diagnosed gaps (1-6) confirmed closed. Tests 1,2,5,6 hand-verified; 3,4 verified via green PWA/API suites; 7 (gap 6 banner-clear) blocked-by-environment under DEV_AUTH_BYPASS (no Authelia) but verified via SetupBanner/App/user.test.ts. No new code issues.
|
||||
|
||||
## Gaps
|
||||
|
||||
[none yet]
|
||||
Reference in New Issue
Block a user