docs(12-02): complete setup-routes plan — guard + router + OIDC fallback
This commit is contained in:
@@ -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).
|
||||
|
||||
Reference in New Issue
Block a user