Merge remote-tracking branch 'origin/main' into fix/v1434-illness-symptoms

docs/api/openapi.yaml

@@ -1,7 +1,7 @@
 openapi: 3.1.0
 info:
   title: HealthLog API
-  version: 1.43.2
+  version: 1.43.3
   description: >-
     Self-hosted personal-health-tracking PWA — public API surface for the iOS native client and external ingest.
 
@@ -2333,7 +2333,11 @@ paths:
         /api/mcp/tokens, POST /api/tokens/measurements, POST /api/tokens/workouts, POST /api/tokens/documents, and the
         admin backup download, upload and restore, the admin data wipe and the admin password reset. Those answer 401
         `auth.reproof.required` with `meta.methods` (the proofs this account can give) when the session signed in or
-        re-proved more than five minutes ago.
+        re-proved more than five minutes ago. A `totp`, `webauthn` or `passkey` proof here also clears the routes that
+        ask for a fresh second factor (the managed-profile acts, the second-factor and passkey changes, the password
+        change, account deletion, the data wipe and key rotation): on a browser session those answer 401
+        `auth.stepup.required` with `meta.methods` naming the possession proofs the account holds, and the web re-proves
+        here and retries.
 
 
         The body takes the same shapes as POST /api/auth/step-up. On an account with a second factor only `totp`,
@@ -21681,10 +21685,12 @@ paths:
               schema:
                 $ref: "#/components/schemas/ManagedProfileEnvelope"
         "401":
-          description: "No fresh second-factor proof (`meta.errorCode: auth.stepup.required`), or none enrolled at all
-            (`meta.errorCode: auth.stepup.mfa_not_enrolled`) — this gate is unconditional, so an account without a
-            second factor cannot create a managed profile until it enrols one. The ordinary unauthenticated 401 arrives
-            here too, including for a Bearer caller, whose transport this gate does not read."
+          description: "No fresh second-factor proof (`meta.errorCode: auth.stepup.required`, with `meta.methods` naming the
+            proofs that clear it at POST /api/auth/reproof), or none enrolled at all (`meta.errorCode:
+            auth.stepup.mfa_not_enrolled`) — this gate is unconditional, so an account with neither a second factor nor
+            a passkey cannot create a managed profile until it enrols one. A passkey counts: an account whose only
+            strong credential is a passkey is offered `passkey` in `meta.methods`. The ordinary unauthenticated 401
+            arrives here too, including for a Bearer caller, whose transport this gate does not read."
           content:
             application/json:
               schema:
@@ -34613,8 +34619,9 @@ components:
         Guardian reading it: they decide how the profile's own reminders are worded and when its day starts. Strict — an
         unexpected field is a 422 rather than an ignored key. Cookie transport only and step-up gated
         (`requireFreshMfa`, unconditional): a Bearer caller cannot mint a credential-less person and a permanent
-        management relationship, and an account with no second factor enrolled is refused rather than waved through.
-        Rate-limited to ten an hour per caller."
+        management relationship, and an account with no second factor enrolled is refused rather than waved through. A
+        primary passkey counts as that factor here: a passkey sign-in or a passkey re-proof at POST /api/auth/reproof
+        stamps the session. Rate-limited to ten an hour per caller."
     UpdateManagedProfileRequest:
       type: object
       properties:

docs/ops/encryption-key-rotation.md

@@ -43,12 +43,12 @@ under `v1` (the synthetic id assigned to the existing `ENCRYPTION_KEY`).
    retained.
 3. **Re-encrypt the stored data under the new key.** Open **Admin →
    Encryption** and press **Rotate now**. The button needs an admin account
-   with a second factor, confirmed recently; it queues one background run
+   with a second factor or a passkey, confirmed recently; it queues one background run
    (`POST /api/admin/encryption/rotate`) on the app's own worker, so it
    works on the published image with nothing else installed. The same page
    shows the per-column counts and the result of the last run.
 
-   Without a second factor on any admin account, run the rotation script
+   Without a second factor or a passkey on any admin account, run the rotation script
    instead. It imports the application code and the generated database
    client, so it runs from a source checkout of the same release, not
    inside the production container (the image has no package manager and

docs/self-hosting/account-sharing.md

@@ -189,9 +189,11 @@ no password, no passkey and no e-mail address, and it is never presented
 as something to log in as.
 
 - It is created from **Settings → Shared access**, under a fresh second
-  factor. An account with no second factor enrolled is refused rather than
-  waved through, because the act creates a permanent management
-  relationship over a person who cannot object to it.
+  factor. A passkey counts as one: a guardian who signs in with a passkey,
+  or confirms it in the dialog the app opens, gets through. An account with
+  neither a second factor nor a passkey is refused rather than waved
+  through, because the act creates a permanent management relationship
+  over a person who cannot object to it.
 - Creation takes a display name, optionally a real date of birth, and the
   language and timezone the record's own days and reminders are measured
   in. A year on its own is never turned into the first of January. The
@@ -356,10 +358,11 @@ Four operational notes:
   and no address to look it up by.
 - **The second-factor requirement is not the same on both features, and
   the difference is deliberate.** Creating a managed profile, deleting
-  one and inviting a second guardian require a second factor
-  unconditionally: an account with none enrolled is refused and told to
-  set one up, because those acts create or end a permanent relationship
-  over somebody who cannot object. Offering manage access on an ordinary
-  invitation asks for a fresh factor only from an account that has one, so
+  one, handing it over and inviting a second guardian require a second
+  factor unconditionally, and a passkey counts as one there: an account
+  with neither is refused and told to set one up, because those acts
+  create or end a permanent relationship over somebody who cannot object.
+  Offering manage access on an ordinary invitation asks for a fresh factor
+  only from an account with TOTP or a security key, so
   an instance where nobody has enrolled a factor can still use every level
   of ordinary sharing. All of them are browser-only either way.