docs(12-02): complete setup-routes plan — guard + router + OIDC fallback

This commit is contained in:
Lucas Berger
2026-06-15 14:06:29 -04:00
parent 67a9d29dc1
commit 9d0aa6296a
4 changed files with 165 additions and 13 deletions
+6 -6
View File
@@ -32,10 +32,10 @@ Each requirement maps to exactly one roadmap phase (see Traceability).
### Setup — First-run configuration wizard
- [ ] **SETUP-01**: On first run (no admin/credentials configured), the operator is guided through a setup wizard to define bootstrap configuration (app/external URL, OIDC client, session secret, encryption key, VAPID keypair, MariaDB connection, first member's Fastmail app password) instead of hand-editing `.env` / `docker-compose.yml`.
- [ ] **SETUP-02**: The wizard **validates each input before completing** — DB connectivity test, VAPID private key decodes to 32 bytes and pairs with the public key, OIDC discovery resolves, and the Fastmail app password reaches CalDAV (PROPFIND).
- [x] **SETUP-01**: On first run (no admin/credentials configured), the operator is guided through a setup wizard to define bootstrap configuration (app/external URL, OIDC client, session secret, encryption key, VAPID keypair, MariaDB connection, first member's Fastmail app password) instead of hand-editing `.env` / `docker-compose.yml`.
- [x] **SETUP-02**: The wizard **validates each input before completing** — DB connectivity test, VAPID private key decodes to 32 bytes and pairs with the public key, OIDC discovery resolves, and the Fastmail app password reaches CalDAV (PROPFIND).
- [x] **SETUP-03**: The wizard generates secrets (session secret, encryption key, VAPID keypair) for the operator to copy into env; secrets are **never written to the database or returned in a response body**.
- [ ] **SETUP-04**: Once setup is complete, the setup endpoints are no longer accessible (guard checked on every invocation, not only at startup).
- [x] **SETUP-04**: Once setup is complete, the setup endpoints are no longer accessible (guard checked on every invocation, not only at startup).
### CI — Gitea continuous integration
@@ -84,9 +84,9 @@ Maps each REQ-ID to its phase. v1.1 phases continue v1.0 numbering (v1.0 ended a
| NOTIF-04 | Phase 11 (Per-Event Reminders) | Complete |
| NOTIF-05 | Phase 11 (Per-Event Reminders) | Complete |
| NOTIF-06 | Phase 11 (Per-Event Reminders) | Complete |
| SETUP-01 | Phase 12 (Initial Setup Wizard) | Pending |
| SETUP-02 | Phase 12 (Initial Setup Wizard) | Pending |
| SETUP-01 | Phase 12 (Initial Setup Wizard) | Complete |
| SETUP-02 | Phase 12 (Initial Setup Wizard) | Complete |
| SETUP-03 | Phase 12 (Initial Setup Wizard) | Complete |
| SETUP-04 | Phase 12 (Initial Setup Wizard) | Pending |
| SETUP-04 | Phase 12 (Initial Setup Wizard) | Complete |
**DB foundation note:** The v1.1 schema migration (`users.is_admin`, `calendar_events.reminder_lead_minutes`, `app_config` table) is not a standalone requirement — it is carried by **Phase 10 (Admin Role & Settings)** (which owns is_admin + app_config) and consumed by **Phase 11 (Per-Event Reminders)** (reminder_lead_minutes) and **Phase 12 (Initial Setup Wizard)** (app_config.setup_complete). Folded per ARCHITECTURE.md ordering rather than created as a migration-only phase. This makes Phase 10 the head of the admin chain (10 → 11, 10 → 12).