mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 12:32:43 +00:00
Twenty-eight more verbs that exist, are called, and said nothing in the contract: registration, password rotation, the profile patch, the SSO entry point, passkey enrolment, the Codex device-auth flow, the device list and its revocation cascade, four per-user preference scalars, the email channel and the four channel self-tests, the record wipe, the privacy facts, the update check, and the Web Push transport. Four of them needed more care than the rest. `GET /api/auth/oidc/login` is documented as the two-armed route it is. The browser arm redirects to the provider; the native arm takes `client=native` plus a mandatory S256 challenge and returns to a compile-time scheme with a one-time code — or an MFA ticket when the account has a second factor. The two PKCE exchanges in play are named apart, because confusing them is the way to get this wrong. `POST /api/auth/register` is the only genuinely anonymous surface in the set, and its refusals are stated exactly: the SSO-only block, the 5-per-15-minutes bucket that collapses rather than falls open, the invite that is consumed whenever it is sent, the zero-user bootstrap that mints the first admin under a lock, and the one 409 that covers a taken email and a taken username so it cannot be used to enumerate accounts. `POST /api/auth/password` is a change behind authentication, not a reset, so it is described as one. `DELETE /api/settings/data` names what it takes and what it leaves: ninety-nine models hard-deleted, the account's own personal columns reset, credentials and interface preferences kept, one transaction, and a confirmation string that is deliberately not the one account deletion wants. Two collisions surfaced while wiring this up and are resolved rather than worked around. `PUT /api/auth/profile` and `PATCH /api/user/profile` are two doors onto one handler, so they now share one published request component instead of two descriptions of one validator. Their RESPONSES differ, though — one carries id and role, the other the display preferences, and neither is a superset — so they are named apart and the older description no longer claims to cover both. The four Web Push and APNs surfaces land in their own route module rather than beside the notification preferences: that module answers what gets sent and whether it arrived, this one the plumbing a client sets up and then verifies. Both self-tests report failure inside a 200, which the contract says plainly, because a client reading only the status will tell someone their notifications work when they do not. The generated YAML is left out; it is regenerated once the remaining groups land.