mforce · Aug 20, 2026 · Aug 19, 2026 · Aug 19, 2026 · Aug 19, 2026 · Aug 19, 2026
diff --git a/docs/architecture.md b/docs/architecture.md
@@ -25,7 +25,8 @@ flowchart TD
     EDGE["forwarded headers · security headers · cache defaults<br/>HSTS <i>(not in Development)</i> · exception handler<br/>HTTPS redirect · static files · request logging"]
     EDGE --> LIMITS["rate limiter · per-endpoint body caps"]
     LIMITS --> AUTHN["UseAuthentication<br/><i>JWT → HttpContext.User</i>"]
-    AUTHN --> TENANT["TenantResolutionMiddleware<br/><i>account_id claim → TenantContext</i>"]
+    AUTHN --> AMBIENT["AmbientPrincipalMiddleware<br/><i>blanks the ambient principal for endpoints that must ignore a bearer</i>"]
+    AMBIENT --> TENANT["TenantResolutionMiddleware<br/><i>account_id claim → TenantContext</i>"]
     TENANT --> EPOCH["CredentialEpochMiddleware<br/><i>fresh DB read, every request</i>"]
     EPOCH --> MCP["MustChangePasswordMiddleware<br/><i>403s everything but change-password + logout</i>"]
     MCP --> AUTHZ["UseAuthorization"]

diff --git a/docs/runbooks/break-glass-account-recovery.md b/docs/runbooks/break-glass-account-recovery.md
@@ -67,6 +67,13 @@ dotnet Cluckwork.Api.dll recover-admin \
 dotnet Cluckwork.Api.dll recover-admin --email owner@thefarm.example --account <account-guid> --reason "..."
 ```
 
+> **Ambiguous emails are now expected, not hypothetical (#532).** Since login is
+> farm-scoped, one address can legitimately exist in several farms, and
+> `recover-admin` looks across accounts. An ambiguous email is **refused**
+> (`Recovery.Ambiguous`) — it never picks — so pass `--account <id>` to
+> disambiguate. Find ids with the `list-accounts` command. The code already
+> behaves this way; this note is documentation only.
+
 The database connection comes from the same configuration the serving process
 uses (`ConnectionStrings__Default` / `Database__Provider`, plus the `Jwt__*`
 values the host reads at startup). In a container deployment, exec into the app

diff --git a/docs/schema/README.md b/docs/schema/README.md
diff --git a/docs/schema/public.Accounts.md b/docs/schema/public.Accounts.md
diff --git a/docs/schema/public.AspNetUserClaims.md b/docs/schema/public.AspNetUserClaims.md
diff --git a/docs/schema/public.AspNetUserLogins.md b/docs/schema/public.AspNetUserLogins.md
diff --git a/docs/schema/public.AspNetUserRoles.md b/docs/schema/public.AspNetUserRoles.md
diff --git a/docs/schema/public.AspNetUserTokens.md b/docs/schema/public.AspNetUserTokens.md
diff --git a/docs/schema/public.AspNetUsers.md b/docs/schema/public.AspNetUsers.md
diff --git a/specs/product/GLOSSARY.md b/specs/product/GLOSSARY.md
@@ -592,16 +592,20 @@ total — clients never sum pages.
 isolation with EF global query filters. Single-farm login today, multi-tenant
 infrastructure dormant.
 
-**Farm code (account slug, #531)** — a short, stable, URL-safe identifier for an
-account: lowercase letters, digits and hyphens, 3–32 characters, no leading or
-trailing hyphen. Unlike the account's internal id (a GUID), it is meant to be
-typed and read aloud. It is chosen once and **immutable** — a provisioning typo
-has no in-app fix this phase — and a handful of words are reserved (`api`,
-`admin`, `www`, `health`, `app`, `login`, `auth`, and similar). The default
-farm's code is `default-farm`. Operators discover the codes with the
-`list-accounts` command. The farm code becomes the way to disambiguate login
-across farms in a later phase (#532); today it is recorded and discoverable but
-not yet used at sign-in, and there is no SPA surface for it yet.
+**Farm code (account slug, #531)** — the per-farm login identifier: a short,
+stable, URL-safe slug (`Account.Slug`) for an account — lowercase letters,
+digits and hyphens, 3–32 characters, no leading or trailing hyphen. Unlike the
+account's internal id (a GUID), it is meant to be typed and read aloud. It is
+chosen once and **immutable** — a provisioning typo has no in-app fix this
+phase — and a handful of words are reserved (`api`, `admin`, `www`, `health`,
+`app`, `login`, `auth`, and similar). The default farm's code is
+`default-farm`. Operators discover the codes with the `list-accounts` command.
+The farm code is the way to disambiguate login across farms (#532): the sign-in
+form requires it before the email, because one email address can now exist in
+several farms and only the farm code says which one is meant, and a wrong or
+unrecognised one is refused with its own message. (Written earlier, before
+#532 shipped: it was recorded and discoverable but not yet used at sign-in, and
+there was no SPA surface for it.)
 
 **Account status — active / suspended (#531)** — an account is *active* by
 default. **Suspending** it takes the farm offline; **reactivating** brings it
@@ -753,15 +757,24 @@ it is never written to `localStorage`/`sessionStorage`, so an XSS payload has no
 durable credential to steal and the 15-minute lifetime bounds any exposure. The
 durable **refresh token** is an `HttpOnly; Secure; SameSite=Strict` cookie
 path-scoped to `/api/v1/auth` — the browser attaches it automatically and JS
-cannot read it. A page reload (memory cleared) silently refreshes against the
-cookie to restore the session; an expired/absent cookie lands cleanly on login.
+cannot read it. Its name includes the farm account ID (#532), so one browser can
+hold independent sessions for several farms without one farm's login, refresh,
+password change, or logout overwriting another's cookie. The SPA keeps the
+non-secret farm ID in per-tab `sessionStorage`, while the access token remains
+memory-only, so a reload names and silently restores that tab's farm even when
+the browser holds several farm cookies. A fresh tab with several cookies and no
+remembered farm still makes the server refuse to guess
+(`Auth.FarmSelectionRequired`) and sends the user to login to choose a farm; it
+rotates or clears none of them. Explicit logout removes the tab binding, and
+closing the tab discards it with the rest of `sessionStorage`. An expired/absent
+cookie lands cleanly on login.
 CSRF is covered by SameSite=Strict plus a custom header (`X-Cluckwork-Auth`) that
 a cross-site request cannot set. Rotation + theft-detection (single-use, revoke
 the whole family on replay) are unchanged — this moved the storage, not the
 hygiene. Deploying #145 forces one re-login (the old localStorage token is
-purged on first load). Because the refresh token now lives only in the shared
-cookie, two tabs refreshing at once would each present the same value and the
-second would trip theft-detection, logging both out; refresh is therefore
+purged on first load). Tabs on the same farm still share that farm's cookie, so
+two same-farm tabs refreshing at once would each present the same value and the
+second could trip theft-detection, logging both out; refresh is therefore
 **serialised across tabs** via the browser Web Locks API (#169) so only one tab
 refreshes at a time and the next presents the freshly-rotated cookie. Server
 theft-detection stays strict; browsers without the API fall back to per-tab
@@ -779,18 +792,14 @@ replays can never fork one token into two live sessions.
 
 **Superseded-flight cookie revocation (#393)** — a refresh (or sign-in, or
 password change) that goes stale mid-flight — superseded by a newer sign-in
-before its own response lands — still rotates the shared refresh cookie the
+before its own response lands — still rotates its farm's refresh cookie the
 instant the browser receives that response, before the app's own bookkeeping
-ever runs. The stale flight's cookie is therefore always revoked, even when
-the newer sign-in already has a token in hand: which of the two responses'
-cookies the browser actually kept is real network timing, not something the
-app can observe or infer from "is someone currently signed in." User-visible
-consequence, narrow and rare: switching to a different sign-in in one browser
-tab while another tab of the same browser is mid-refresh can occasionally
-revoke the credential behind the *newer* sign-in too, surfacing as an
-unexpected "please sign in again" shortly after. No work is lost — it is
-exactly the same experience as any other session timeout, just sooner than
-expected. See the Help page's "Signing in" section.
+ever runs. The stale flight's cookie is therefore always revoked. Which of two
+responses for the **same farm** the browser kept is real network timing, so a
+same-farm account switch during an in-flight refresh can still surface as an
+unexpected "please sign in again." A different farm's cookie is a different
+name and cannot be touched by that race (#532). No work is lost; see the Help
+page's "Signing in" section.
 
 **Credential epoch (#364)** — a monotonically increasing per-user number carried
 in every access token and stamped onto every refresh token. A request is valid