ℹ️ About Codex in GitHub

\\n
\\n\\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\\n- Open a pull request for review\\n- Mark a draft as ready\\n- Comment \\\"@codex review\\\".\\n\\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\\n\\n\\n\\n\\nCodex can also answer questions or update the PR. Try commenting \\\"@codex address that feedback\\\".\\n \\n

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Keep the epoch migration additive-only**\\n\\nDuring the documented migrate-before-serve rolling rollout, pre-epoch replicas may still handle refresh traffic while this statement marks every legacy token revoked. If a forgotten tab then presents one of those tokens to an old replica, the pre-change `IdentityProvider.RefreshAsync` treats it as replay and performs user-wide revocation, potentially destroying the epoch-1 family the user just obtained from a new replica. Leave legacy rows active but inert through `IssuedEpoch = 0`, and defer physical revocation until every old process is drained.\\n\\nAGENTS.md reference: [AGENTS.md:L50-L50](https://github.com/mforce/cluckwork/blob/f6d30de994d42064adc102aadde3db29f9622263/AGENTS.md#L50-L50)\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/Cluckwork.Infrastructure/Persistence/Migrations/20260802223122_CredentialEpoch.cs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Fold these columns into InitialCreate**\\n\\nAdding `CredentialEpoch` as a second migration violates the repository's explicit single-squashed-migration contract for this pre-production, virgin-database state. Fold the new columns into `InitialCreate` and update its designer/snapshot while preserving its hand-written indexes and reference-data SQL, rather than extending the migration history and weakening the tests around that invariant.\\n\\nAGENTS.md reference: [AGENTS.md:L45-L45](https://github.com/mforce/cluckwork/blob/f6d30de994d42064adc102aadde3db29f9622263/AGENTS.md#L45-L45)\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/Cluckwork.Infrastructure/Persistence/Migrations/20260802223122_CredentialEpoch.cs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Reviewed the security core directly. The epoch mechanism itself is **correct**:\\n\\n- `CredentialEpoch` defaults to `1` in **both** the C# property and `HasDefaultValue(1)`, and the migration's `AddColumn` default is `1`. A missing/malformed `credential_epoch` claim maps to `0`, which therefore can never equal a live user's epoch. Epoch 0 is genuinely retired, as intended.\\n- `IssuedEpoch` defaults to `0` on `refresh_tokens` while users start at `1`, so a pre-epoch token row is inert by construction — belt *and* braces with the `UPDATE … SET RevokedAt = now()` in the same migration.\\n- All **three** password paths bump the epoch: `SetUserPasswordAsync` and `BreakGlassResetAsync` both route through `ResetPasswordAndRevokeAsync` (one bump at the shared core), and `ChangeOwnPasswordAsync` bumps its own. No path was missed.\\n- The user/epoch lookup correctly moved **ahead** of the #176 replay branch, and `RevokeAllActiveForUserAsync` now scopes revocation to the presented epoch so a retired token can't take down a later epoch's family. `SingleOrDefaultAsync` returning `null` produces `null != tokenEpoch` → 401, so an unknown user fails closed.\\n\\nTwo things to fix before merge.\\n\\n---\\n\\n### 1. The change falsifies four \\\"no server-side denylist\\\" claims, and none were swept\\n\\nThis PR's entire point is that an access token **is** now revocable server-side. These still assert the opposite as a design property:\\n\\n- `src/Cluckwork.Application/Common/IIdentityProvider.cs:48` — *\\\"Bounded by the access-token lifetime: an already-issued JWT stays valid until it expires (~15 min) — there is no server-side denylist.\\\"* On the declaration of `SetUserPasswordAsync`, which now bumps the epoch. Flatly false.\\n- `src/Cluckwork.Infrastructure/Identity/IdentityProvider.cs:369` — *\\\"An already-issued access token stays valid until it expires (~15 min) — no denylist.\\\"* On `ResetPasswordAndRevokeAsync`, i.e. the method containing the new `user.CredentialEpoch++`. The comment and the line it sits above now contradict each other.\\n- `specs/product/GLOSSARY.md:580` — *\\\"an already-issued access token keeps working until it expires (~15 min), because tokens are stateless and there is no server-side denylist.\\\"*\\n- `docs/runbooks/break-glass-account-recovery.md:28` — *\\\"An access token already issued stays valid until it expires (~15 min) — there is no server-side denylist.\\\"* An operator running break-glass during an incident reads this to decide whether they still have an exposure window. They no longer do.\\n\\nBe careful **not** to sweep these two — they remain accurate, because no password reset occurs and the epoch does not move:\\n\\n- `src/Cluckwork.Infrastructure/Identity/StepUpGrantService.cs:16` (theft threat model)\\n- `specs/product/GLOSSARY.md:586` (#308's rationale)\\n\\nBut GLOSSARY:586 says *\\\"no server-side denylist — **see Password change above**\\\"*, cross-referencing a passage that has to change. Reword the pointer so the step-up rationale doesn't inherit a claim that is no longer general.\\n\\n### 2. No `AGENTS.md` bullet\\n\\nEvery comparable security posture has one — #283 first-run provisioning, #265 break-glass, #308 step-up, #269 retry boundaries. #364 introduces two invariants a future change will silently break:\\n\\n- **epoch `0` is permanently retired**; an absent or malformed `credential_epoch` claim is a *mismatch*, never an exemption. Someone \\\"tidying\\\" the parse into `?? currentEpoch` reopens the hole with no test necessarily failing.\\n- the middleware sits **after** `TenantResolutionMiddleware` and **before** `MustChangePasswordMiddleware`, and `/api/v1/auth/logout` is deliberately exempt so a superseded token can still end its own session.\\n\\nIt should also state its relationship to #283 / #265 / #308 the way those bullets state theirs — these are four distinct credential concepts and the file already warns against conflating them.\\n\\n---\\n\\n### Notes, not blockers\\n\\n- **A DB round-trip per authenticated request.** `db.Users.AsNoTracking()…SingleOrDefaultAsync` runs on every authenticated call with no caching. Correct and fail-closed, and fine at farm scale — but it should be a *stated* trade-off in the AGENTS.md bullet rather than an accident, since it is the obvious thing a later optimisation would cache and thereby defeat.\\n- **`DisabledAt` / `DisabledBy` ship as dead schema** — three readers (`LoginAsync`, `RefreshAsync`, `StepUpGrantService`), zero writers. `ApplicationUser.cs` documents this as groundwork for #356, which is a reasonable call, but the columns land in a production migration ahead of the feature.\\n- **`LoginAsync` gaining `if (user.DisabledAt is not null)`** is a behaviour change that can't fire yet (no writer). Worth stating in the PR body that it's inert-by-construction today, so it isn't read as a fix for a live hole.\\n- **Logout exemption** uses `PathString` equality, so it is case-insensitive but *not* trailing-slash tolerant: `/api/v1/auth/logout/` would take the epoch check and 401 instead of logging out. Almost certainly unreachable from the SPA; noting it only because the exemption is a security-relevant carve-out.\\n- The PR body's *\\\"Simulation Playwright/mutation preflight cannot reach `/health/ready`\\\"* — per the #370 rule the sim harness is nobody's CI responsibility, so this needs a human run before merge. `openssl` is available on the dev box; the agent's environment lacked it.\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Agreed — and I verified the fold is safe to do, because the thing that makes it risky is real: `InitialCreate` carries two hand-carried, un-regenerable pieces (the four `lower(\\\"Name\\\")` expression unique indexes, and the 21-row `WHERE NOT EXISTS`-guarded reference-data SQL) that a `dotnet ef migrations add` regeneration silently drops.\\n\\nSo: **hand-edit `InitialCreate`, never regenerate it.** The concrete shape that works:\\n\\n- `AspNetUsers.CredentialEpoch` — `integer`, NOT NULL, **default 1**\\n- `AspNetUsers.DisabledAt` — `timestamp with time zone`, nullable\\n- `AspNetUsers.DisabledBy` — `uuid`, nullable\\n- `refresh_tokens.IssuedEpoch` — `integer`, NOT NULL, **default 0**\\n\\nThen update `InitialCreate.Designer.cs`. **`AppDbContextModelSnapshot.cs` needs no change** — diff it against `20260802223122_CredentialEpoch.Designer.cs` before deleting that file and you will find them byte-identical apart from class-declaration boilerplate, because the snapshot already carries the target model.\\n\\nThose two defaults are load-bearing security properties, not cosmetics: users start at 1 and refresh tokens at 0 precisely so that a missing or malformed `credential_epoch` claim — which the middleware maps to `0` — can never equal a live user's epoch. Change either and the revocation check opens silently.\\n\\nOn the tests: `MigrationSecurityReviewTests`'s `InitialCreateMigration()`/`InitialCreateSqlOperations()` helpers exist only to route around a second migration, so they revert to `AllSqlOperations()`, and `CredentialEpochMigration_SafelyRetiresLegacyRefreshSessions` goes away with the backfill it pins. Worth adding what is currently missing entirely: an `ExactlyOneMigrationExists_AndItIsInitialCreate` fence. The repo documents that contract but nothing enforced it, which is how a second migration got this far without a red build.\",\"path\":\"src/Cluckwork.Infrastructure/Persistence/Migrations/20260802223122_CredentialEpoch.cs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Agreed the statement should go, though for a stronger reason than the rollout hazard you describe.\\n\\nThe rolling-rollout scenario — a pre-epoch replica still serving refresh traffic while this marks legacy tokens revoked — **cannot occur**, because this application has never been deployed. There is no old fleet, no forgotten tab, and no legacy row.\\n\\nWhich is exactly why the statement is wrong: `UPDATE refresh_tokens SET \\\"RevokedAt\\\" = now() WHERE \\\"RevokedAt\\\" IS NULL` touches **zero rows, always**. That is precisely the anti-pattern the #245 squash was performed to eliminate — the repo's own words for the 34 migrations it replaced were \\\"12 of them carrying raw SQL written for mid-history data states — backfills that touch 0 rows on an empty database but still execute.\\\"\\n\\nSo the fix is not to defer the revocation until the fleet drains; it is to delete the statement, and the `SET LOCAL lock_timeout = '5s'` guard with it, since that too only manages contention against traffic that does not exist. `IssuedEpoch = 0` against a user default of `1` already makes any hypothetical legacy row inert by construction, which is the belt your comment is asking for and the braces are unnecessary.\\n\\nThat lands the same place as the sibling finding: fold the columns into `InitialCreate` and carry no data statement at all.\",\"path\":\"src/Cluckwork.Infrastructure/Persistence/Migrations/20260802223122_CredentialEpoch.cs\",\"side\":\"RIGHT\",\"line\":null}","text_elements",[],{"_434":923,"_413":414,"_436":420},{"_437":924,"_439":-5,"_45":-5,"_441":925,"_443":-5,"_100":330,"_96":445},[926],{"_446":420},{"_49":919,"_96":491},{"_434":928,"_413":414,"_436":420},{"_437":929,"_439":-5,"_45":-5,"_441":930,"_443":-5,"_100":330,"_96":445},[931,932],{"_446":420},{"_49":934,"_96":491},{"_49":933,"_96":491},"\n /workspace/cluckwork\n bash\n 2026-08-03\n Etc/UTC\n /workspace/cluckwork\n","# AGENTS.md instructions for /workspace/cluckwork\n\n\n# AGENTS.md — Cluckwork\n\nPoultry egg-farm management system. Backend: **.NET 10** (C#), layered DDD. Frontend: **React 19 + Vite** SPA in `web/`. Postgres via EF Core.\n\nThis file is the shared brief for any coding agent (Claude Code, Codex, etc.).\n\n## Layout\n\n```\nsrc/\n Cluckwork.Domain aggregates, value objects, domain events (no deps)\n Cluckwork.Application feature handlers, repository interfaces, validators\n Cluckwork.Infrastructure EF Core, Identity/JWT, repositories, seeding, jobs\n Cluckwork.Api minimal-API endpoints, middleware, Program.cs\nweb/ React/Vite SPA (see web/README.md)\ndeploy/ docker-compose (.yml prod, .dev.yml dev DB), .env.example\nspecs/ product + technical specs, wireframes\ntests/ Domain.Tests, Application.Tests, Api.IntegrationTests\n```\n\nDependencies point inward: Api → Application/Infrastructure → Domain. Domain depends on nothing.\n\n## Build / test / run\n\n```bash\ndotnet build Cluckwork.sln # warnings are errors — keep it clean\ndotnet test Cluckwork.sln # 688 tests as of 2026-07; integration needs Docker\n```\n\n- **Integration tests** spin up a real Postgres via Testcontainers (`docker` required). No SQLite — EF SQL semantics differ.\n- **Run full stack (prod-like):** `docker compose -f deploy/docker-compose.yml up --build` → SPA + API on http://localhost:8080 (single container; API serves the built SPA from `wwwroot`).\n- **Run frontend dev:** `cd web && npm run dev` → http://localhost:5173 (proxies `/api` → :8080).\n- **Debug API (no docker stack):** `docker compose -f deploy/docker-compose.dev.yml up -d` (Postgres on :5432), then run/debug `Cluckwork.Api` (Development env). Dev secrets live in **user-secrets**, not files.\n\n## Conventions (follow these)\n\n- **Result pattern:** domain/handlers return `Result` / `Result` (see `Domain/Common`). Don't throw for expected failures; throw only for invariant violations (e.g. `Flock.Create` guards).\n- **Every aggregate mutation must bump `Version`.** `Version` is an EF concurrency token (`IsConcurrencyToken`) — EF puts the *original* value in the UPDATE's WHERE but never auto-increments it. A mutation without `Version++` silently loses concurrent races (both writers match `WHERE Version = N`) instead of 409ing. This bug shipped three times (`RecordProduction` was correct; `Submit`/`Lock` and `SalesOrder.AddItem` weren't) — each now has a parallel-race integration test; add one for any new mutation.\n- **Handler per feature**, invoked directly from endpoints — **no MediatR**. Register handlers/validators/repos in `Program.cs`.\n- **Validation:** FluentValidation validators (`*Validator`), one per command; endpoints call `ValidateAsync` and return `ValidationProblem`.\n- **Endpoints:** minimal APIs grouped under `/api/v1/...` via `MapEndpoints`; writes require auth + an `Idempotency-Key` (middleware).\n- **Multi-tenancy:** every tenant-owned entity has `AccountId`; enforced by an EF **global query filter** + a **`TenantStampInterceptor`** (stamps on insert). `TenantContext` is resolved per-request from the JWT `account_id` claim. At startup it's unresolved → use `IgnoreQueryFilters()` in seeders.\n- **Auth:** asymmetric JWT + rotating refresh tokens. PEM keys come from config with escaped `\\n`; normalize via `PemKey.Normalize` before `ImportFromPem`. Integration tests generate an ephemeral RSA pair at test-process startup (`TestJwtKeys` in `CluckworkWebApplicationFactory.cs`) — no real key material is ever committed to source (`deploy/.env.example` carries PEM armor with a `replace-me` body, not a usable key).\n- **Migrations + base provisioning (#283):** EF migrations auto-apply on startup (`Database:MigrateOnStartup`, default true — but **Production sets it `false`**; the `migrate` command runs DDL out-of-band, see the #263 bullet below). The default account, the four assignable roles (`Roles.Assignable`), the default egg grades, and the default packed-unit conversions are **static reference data baked into the migrations themselves** — deterministic and multi-instance-safe by construction, **no runtime seeder, no `Seed:*` config**. They ship as **hand-written `migrationBuilder.Sql` with `WHERE NOT EXISTS` guards, deliberately NOT EF's `HasData`/`InsertData`** — `HasData` keys on the PRIMARY KEY, which assumes a virgin schema, but every install that ever booted pre-#283 already has these rows under *different* ids (the old `DatabaseSeeder` minted roles/grades/conversions with `Guid.NewGuid()`), so `InsertData` either collides on `PK_Accounts` or silently violates the real natural-key unique indexes. The #245 squash retires *that* particular reason (a virgin database is now the only starting state), but **do not \"regenerate\" these into `HasData`**: `HasData` rows become part of the **model**, and every one of these tables is user-mutable through the app (Settings renames the account, `PUT /api/v1/egg-grades/{id}` renames a grade, `EggUnitConversion.Update` retunes `EggsPerUnit`), so a later model-diff would emit `UpdateData`/`DeleteData` that silently reverts the farm's own edits. Raw SQL seeds once and then leaves the rows alone forever. The guard's scope differs per batch, and the rule is *whether the user can change the natural key or remove a set member*: the **egg grades** batch is gated on the account's grade catalog being **entirely empty** (whole-set), because grades are user-managed — `PUT /api/v1/egg-grades/{id}` renames one, and a per-name guard cannot see a `Small` the farm renamed to `Pullet`, so it would resurrect an active, saleable duplicate (the old seeder skipped the whole set for exactly this reason); **roles, unit conversions, and the default account** stay **per-key**, because their keys are not user-mutable (no role CRUD exists at all; `EggUnitConversion.Update` cannot change `UnitCode` and there is no create/delete; the account's key is a fixed id), and per-key additionally lets a later-added role or unit code back-fill into an older install. `MigrationSecurityReviewTests` pins the SQL shape (12 INSERT statements, 21 rows, every one `WHERE NOT EXISTS`-guarded, the grades guard blind to `\"Name\"`) and `BaseReferenceDataMigrationTests` pins the result against a real virgin Postgres. `MigrationSecurityReviewTests` also asserts no migration ever inserts a credential-shaped row (`AspNetUsers`, `PasswordHash`, `SecurityStamp`, …) — the schema itself is never a place a credential can hide. The first admin is a **separate, deliberately NOT migration-baked** concern — see the #283 bullet below.\n- **One migration, squashed (#245):** `Persistence/Migrations/` holds exactly **one** migration, `InitialCreate`, generated from the current model on 2026-08-01. It replaced the 34 that had accumulated since 2026-06-27 (12 of them carrying raw SQL written for mid-history data states — backfills that touch 0 rows on an empty database but still execute). Done once, before the first production deploy, precisely because no `__EFMigrationsHistory` anywhere needed baselining; **it cannot be repeated after go-live**. Any database still carrying the old history (a dev DB from `deploy/docker-compose.dev.yml`, an old demo/sim instance) can no longer migrate forward — **drop and recreate**: `docker compose -f deploy/docker-compose.dev.yml down -v && docker compose -f deploy/docker-compose.dev.yml up -d`. Two things in that migration are **hand-carried and un-regenerable** — a plain `dotnet ef migrations add` drops both on the floor, so never regenerate `InitialCreate` without re-adding them: (1) the four **`lower(\"Name\")` expression unique indexes** (`IX_EggGrades_AccountId_FarmId_LowerName`, `IX_ExpenseCategories_NameCi`, `UX_InventoryItems_Account_Farm_LowerName`, `IX_Products_AccountId_LowerName`) — EF cannot model a functional index, and losing them loses four uniqueness constraints; (2) the **static base reference data** raw SQL (see the bullet above). `MigrationSecurityReviewTests` and `BaseReferenceDataMigrationTests` fail if either goes missing.\n- **Seed command (#280, #284):** demo sample data is NOT boot-seeded — there is no `Seed__Demo` flag anymore. Run it explicitly, against a database that has **already been booted once** so the base seed above exists (default account, `Admin` role, default egg grades — the demo seed needs all three and fails fast with a clear message if they're missing): `ASPNETCORE_ENVIRONMENT=Development dotnet Cluckwork.Api.dll seed --profile demo` (an unset `ASPNETCORE_ENVIRONMENT` defaults to Production, which the guard below blocks — always set it for a local/dev/CI run). The command migrates the schema, runs `DemoDataSeeder`, then exits (Kestrel never starts); it is **authoritative** (seeds regardless of any config) and **fail-loud** (a real exit code: `0` only when data was actually seeded or was already present, non-zero with an stderr message otherwise — never a silent no-op). `DemoDataSeeder` is registered only when `!IsProduction()` (defense-in-depth): running the command against a Production-env process fails with a clear message instead of writing fake data. Intended flow: the serving process for a real farm stays Production; a non-Production process (dev box, CI, or a sim/load-test harness) runs `seed --profile demo` against its own already-base-seeded database. The **`simulation` profile** (#279) sits in the same `switch` with the same authoritative + fail-loud + Production-guarded contract (`SimulationDataSeeder`); it additionally records its date anchor + a completion marker in a durable `SimulationSeedState` row (anchor written before the first fixture mutation; completion stamped only after the manifest succeeds). A clean re-run — even one straddling a UTC-midnight rollover — reuses that anchor and converges to `AlreadySeeded` with an unchanged manifest fingerprint instead of writing a shifted duplicate set; `AlreadySeeded` is reported only when the counts are unchanged, so a `SimulationOptions` change that adds fixtures re-runs as `Seeded`. The durable anchor can't be poisoned by a mid-seed crash or by foreign daily entries a load test writes into the account (a data-derived anchor could); but a polluted account still fails the exact count validation **closed** (`Failed`) rather than certifying a fixture that no longer matches the definition.\n- **Break-glass recovery (#265):** `recover-admin` is a second one-off CLI verb on the same binary, same run-then-exit shape as `seed` — but deliberately **NOT** environment-gated (it must work against a real Production database): `dotnet Cluckwork.Api.dll recover-admin --email [--account ] [--reason ]`. For a locked-out account (the sole-Owner-lost-password case, no email/SMTP reset path) it, in one transaction, resets to a **freshly generated** temporary password (never one passed on the command line), rotates the security stamp, revokes every refresh token, and writes a conspicuous `User.BreakGlassReset` audit row carrying `--reason`. The temp password is printed to **stdout only** (never the logger/OTLP) and exit `0`; failures go to stderr with exit `1` and change nothing. `AdminRecoveryService` orchestrates; `IdentityProvider.BreakGlassResetAsync` shares the reset/revoke core with `SetUserPasswordAsync`. Full procedure + verification drill: `docs/runbooks/break-glass-account-recovery.md`.\n- **First-run admin provisioning (#283):** `bootstrap-admin` is a fourth one-off CLI verb, same run-then-exit shape as `seed`/`migrate`, always available in Production (same posture as `recover-admin`): `dotnet Cluckwork.Api.dll bootstrap-admin --email `. It migrates the schema (idempotent, like the other verbs), then — **only if the default account has no Owner yet** — creates one with a **freshly generated** password and `ApplicationUser.MustChangePassword = true`, printed to **stdout only** (never the logger/OTLP, identical rule to `recover-admin`). A re-run against an already-provisioned account is a silent no-op: no second Owner, no password reprinted. `FirstRunAdminService` orchestrates (mirrors `AdminRecoveryService`'s CLI-wrapper-calls-a-service shape); `IIdentityProvider.CreateUserAsync` gained an optional `mustChangePassword` parameter (default `false` — an ordinary Users-page-created user is never gated) that this is the only caller to pass `true`. While the flag is set: the JWT carries a `must_change_password` claim (`JwtTokenService`), `MustChangePasswordMiddleware` refuses **every** endpoint except `auth/change-password` and `auth/logout` with 403 (placed before `UseAuthorization`, so it applies uniformly regardless of an endpoint's `AuthPolicies` tier, and before the idempotency middleware, so a blocked write burns no key), and the SPA's `ProtectedRoute` renders a **\"Set your password\"** screen (`SetPasswordPage`, reusing `/auth/change-password` — the operator already knows the printed password as their \"current\" one) instead of the app shell, on every route. Any successful password reset (self-service change, an Owner's `SetUserPasswordAsync`, or break-glass) clears the flag — a single invariant in `IdentityProvider`, not re-derived per path. **Deliberately a separate credential type** from `recover-admin`'s temp password and from #308's browser step-up re-confirmation grant — different audience (pre-auth shell access vs. an authenticated Owner), different lifetime, never conflated; do not treat any of #283/#265/#308 as covering another.\n- **Farm timezone + tzdata/ICU image constraint (#264):** the default account (a fixed `\"UTC\"` migration literal since #283 — see the bullet above) is provisioned once; a real farm sets its actual IANA zone via **Settings → timezone** after first login (`Account.UpdateSettings`), not at provisioning time (the `Seed:TimeZoneId` config lever from before #283 is retired along with the runtime seeder it fed). The farm clock resolves IANA zones via `TimeZoneInfo.FindSystemTimeZoneById` for every safety-sensitive local-day decision and **fails closed**, so the runtime **image MUST carry tzdata + ICU** (the Ubuntu 24.04 (Noble) `aspnet:10.0` base does; **never** an Alpine/chiseled base without tzdata, and **never** `InvariantGlobalization=true`). `Program.cs` still asserts a representative IANA canary resolves at boot (`TimeZoneAvailability.EnsureResolvable`) — a bad image fails the boot loudly instead of surfacing later as a per-request `FarmTimeZoneException`.\n- **Migrate command + prod migration split (#263):** `dotnet Cluckwork.Api.dll migrate` is a third run-then-exit CLI verb (same shape as `seed`) that applies EF migrations then exits — the **pre-deploy-job entrypoint**. In **Production** (`appsettings.Production.json`, loaded because the container leaves `ASPNETCORE_ENVIRONMENT` unset → Production; setting it to Development silently re-enables boot-migration) **`Database:MigrateOnStartup=false`**, so the request-serving process never runs schema DDL. The **actual guarantee is ordering** — migrate runs *before* serve: `deploy/docker-compose.yml` runs a one-shot `migrate` service first and `app` waits on `service_completed_successfully` (any other orchestrator runs the `migrate` job as a pre-deploy step). `DatabaseReadyHealthCheck` is the **backstop**: `/health/ready` returns **503 while any migration is pending**, so an orchestrator's readiness gate won't route traffic to a stale schema. This is the app-side of #263's privilege separation. The **remaining host-specific deploy step**: create a least-privilege runtime role (`GRANT USAGE ON SCHEMA public` + DML/sequence privileges, **no DDL**; plus **`ALTER DEFAULT PRIVILEGES`** for the migrator role so objects future migrations create are auto-granted to the runtime role) and point the migrate job at a separate owner/migrator credential. This PR **does not** close #263 on its own — it references it; the role split closes it.\n- **Proxy-trust boot guard (#260):** behind a reverse proxy/edge, HSTS (#144) and the per-IP login limiter (#143) only work if the app trusts the proxy's `X-Forwarded-*`, which it does **only** for networks in `RateLimiting:TrustedProxies`. An **empty list in Production fails the boot** (a serving-process guard placed *after* the CLI dispatch, so `migrate`/`seed`/`recover-admin` are unaffected) rather than silently running with inert HSTS + a one-bucket limiter. Opt out with `RateLimiting:AllowNoTrustedProxies=true` only for a rare direct-TLS deploy with no fronting proxy. The concrete edge CIDR is deploy config (in the separate deployment/ops repo).\n- **Production Postgres TLS floor (#261/#262):** `ConnectionStrings:Default` accepts libpq URI form (`postgresql://…`, translated to Npgsql key-value; a param Npgsql supports under a different spelling — `channel_binding`, `target_session_attrs`, `gssencmode` — is **mapped**, and only a genuinely unsupported one — `sslcompression` — skips-with-warning; **`ContainsKey(\"\") == false` does NOT mean Npgsql lacks the setting** — it usually means the keyword is spelled differently (`keepalives` → `Tcp Keepalive`, `client_encoding` → `Client Encoding`, `gssencmode` → `GSS Encryption Mode`), so search the keyword list for the concept before concluding a param is unmappable; that exact false negative is what shipped #332, and the first fix for it re-made the same mistake with `keepalives`. Still unmapped and worth a follow-up: the `keepalives*` family and `client_encoding` — `keepalives` needs a *value* translation (`1` → a bool keyword), not just a keyword map) as well as key-value. In **Production** the effective `sslmode` is validated once at boot as a fail-closed **allow-list**: `VerifyCA`/`VerifyFull` silent, `Require` warns (prefer VerifyFull), and **everything else — `Disable`/`Allow`/`Prefer`, unset (Npgsql defaults to `Prefer`), or any undefined `SslMode` — fails the boot**. Never auto-injected. `Database:AllowInsecureConnection=true` is the explicit opt-out for the co-located plaintext compose stack (set on both `app` and `migrate`; a real deploy never sets it). The `VerifyFull` CA + per-host `sslmode` are deploy config (in the separate deployment/ops repo). Integration tests opt out of this **and** the #260 guard in `CluckworkWebApplicationFactory` (plaintext Testcontainers, no proxy) — a Production-env test that skips those opt-outs will fail the boot.\n- **GSS/Kerberos negotiation off by default (#332):** Npgsql's `GssEncryptionMode` defaults to `Prefer`, so every connector probes the GSSAPI stack before authenticating. The runtime image carries no `libgssapi-krb5-2` (#267 keeps it minimal), so that probe made .NET's native security shim print two **unstructured, pre-Serilog** lines to stderr per connecting process (`Cannot load library libgssapi_krb5.so.2`) — non-fatal but it reads like a failure during deploys and lands badly in an OTLP sink. `PostgresConnectionString` now appends `GSS Encryption Mode=Disable` **unless the operator specified it**, detected by **presence, not value** (`prefer` is Npgsql's own default, so a value comparison would silently override an operator who asked for it) — via the *base* `DbConnectionStringBuilder`, since `NpgsqlConnectionStringBuilder.ContainsKey` returns true for every keyword it knows, defaults included. Appended **textually** after the TLS floor runs: a round-trip through the Npgsql builder would reorder/requote the operator's own string and throw on any keyword this Npgsql version doesn't know. Orthogonal to `sslmode` (#262 untouched) and to GSS *authentication* (a separate Npgsql path). Fixing the image instead was rejected — it adds package surface to a Trivy-gated image. **Verified by loader trace** (`LD_DEBUG=libs` against a scram-sha-256 Postgres): `Prefer` dlopens `libgssapi_krb5.so.2`/`libkrb5.so.3`/`libkrb5support.so.0` even though the server never offers GSS; `Disable` produces **zero** gssapi/krb5 loader activity and connects identically — so under password auth there is no residual GSS-*auth* probing either. End-to-end confirmation on the managed cluster (deploy repo) is the only step left.\n- **Design-time migration connection fail-closed (#318):** `AppDbContextDesignTimeFactory` (used by `dotnet ef migrations add`/`database update`, never by the `migrate` verb, which uses the built host's own config) has **no default connection** — an unset/blank `CLUCKWORK_MIGRATIONS_CONNECTION` throws immediately, naming the variable, rather than falling back to a predictable `Host=localhost;...;Username=postgres;Password=postgres`. Every target is held to the **same allow-list TLS floor as a Production boot** (#261/#262, reused via `PostgresConnectionString.NormalizeAndValidate` — no second validator), except an explicitly acknowledged **loopback** development target: `CLUCKWORK_MIGRATIONS_ALLOW_INSECURE_LOOPBACK=true` permits plaintext, but only when the connection's host is `localhost`/`127.0.0.1`/`::1` (checked via `IPAddress.IsLoopback`) — set against any other host, it fails rather than silently widening scope.\n- **Container image hardening (#267):** the runtime stage runs **non-root** (`USER $APP_UID`, uid 1654 — the base image's built-in `app` account); all three base images are **digest-pinned** (`@sha256:…`, kept current by Dependabot's `docker` ecosystem); a CI job builds the image and **Trivy** fails the build on a *fixable* HIGH/CRITICAL. `aquasecurity/trivy-action` is **SHA-pinned** — the action was compromised in the 2026-03 supply-chain incident, so pin the immutable commit, not the re-pointable tag (this is the standing rule for third-party actions). Keep the full glibc base (tzdata + ICU per #264); never chiseled/Alpine.\n- **Container health probe (#266):** the runtime image **and** the compose `app` service carry a `HEALTHCHECK` that runs `dotnet Cluckwork.Api.dll healthcheck` — a **fourth run-then-exit CLI verb**, but **dispatched *before* host build** (`Program.cs`, `args is [HealthCheckCliCommand.Verb, ..]`), not via `CliDispatcher`: unlike `migrate`/`seed`/`recover-admin` — which operate on the built host — this one needs no host/DI/DB/config, so a 30s probe must not re-run the whole app startup or re-log boot warnings on every tick. The hardened image ships **no curl/wget** (#267), so the probe is **in-process**: it GETs `/health/ready` over loopback (port derived from `ASPNETCORE_URLS`, default `8080`) and exits `0` on a 2xx, `1` on any other status **or** an unreachable server (refused/timeout) — never a false green. So an instance whose `/health/ready` is 503 (DB down, migrations pending per #263) reports **unhealthy** and compose/an orchestrator stops routing to it. Its `ProbeAsync`/`DefaultReadyUrl` are unit-tested directly (no Docker). The CI `image` job (#267) now also **boots** the built image against a throwaway Postgres and asserts `/health/ready` goes green + the verb exits `0`, so an unbootable image fails CI instead of at deploy time — this is the **app-side of #266**. Deploy-side (the host's readiness path, wait-for-CI gate, post-deploy smoke) lives in the separate deployment/ops repo.\n- **Transient-DB retry, and where it stops (#269):** `EnableRetryOnFailure` (`Database:Resilience:*`, bounded — never infinite) makes a managed-Postgres failover or a dropped pooled connection retry instead of 500ing. It applies to everything EF runs as a **self-contained unit**: every read, and every `SaveChanges` outside a user-initiated transaction. It deliberately does **NOT** apply to a transaction that spans work which is not replayable, because a transaction cannot be *resumed* after a connection loss, only replayed from the start. **Four** such regions exist and all run through **`SingleAttemptExecution`** — inside the execution strategy (EF requires that to open the transaction at all) but **executed exactly once**: `IdempotencyMiddleware`'s request-wide transaction, which covers `next(context)` (replaying the pipeline re-consumes the single-use in-memory #308 step-up grant, and makes a state transition answer 422 for a request that already succeeded); `AmbientTransaction`'s **owned** path (a failed attempt's entities stay tracked as `Added` — EF never detaches them — so a replay flushes duplicate users/audit rows/refresh tokens); and **`FirstRunAdminService`'s whole lock → check → create region** (#350 review). That last one is the subtle case, and the reason \"the write is single-attempt\" is *not* sufficient on its own: `bootstrap-admin` guards \"exactly one first-run Owner\" with a **session-scoped** `pg_advisory_lock`, but the Owner/conflict **reads** that decide whether to create were ordinary EF units, so the strategy retried *them*, and a retry **reconnects** — dropping the lock and walking into the create unguarded (two invocations with different emails could each mint an Owner). Wrapping the whole region makes it one non-replayed attempt; on top of that the create is gated on **proving** ownership — `pg_locks … AND pid = pg_backend_pid()` — because EF also silently *replaces* a connection it finds no longer usable, with no exception and no retry to intercept. That proof is asked **twice**, and the second one is the load-bearing one (#350 review round 3): a check that merely precedes the write still returns before `AmbientTransaction` establishes the create transaction, and a connection replaced in *that* gap leaves the `INSERT` running on a backend that never took the lock while the check's `true` describes a backend that no longer exists. So `FirstRunAdminService` **owns the create transaction itself** and re-proves ownership as the first statement *inside* it — same backend as the `INSERT` by construction, and from there a connection loss aborts the transaction instead of reconnecting invisibly; `IdentityProvider.CreateUserAsync` simply **joins** it (`AmbientTransaction`'s ambient path, exactly as under #307's request-wide transaction), so the lock check is never imposed on the Users page or the seeders that share that method. The pre-transaction check is kept in front as one cheap round trip that refuses before a password is even generated. All **fail closed** (`Bootstrap.LockLost`, exit 1): a refused `bootstrap-admin` is re-runnable and idempotent, a second farm Owner is not undoable. Never widen a session-scoped lock's region without all three parts, and never let a *comment* claim continuity a point-in-time check cannot deliver — that overstatement is exactly how the write-side gap survived two review rounds. The **fourth** region is `AccountLockout`'s `AccessFailedAsync` **save** (#350 review round 4) and it is the one that shows \"unreplayable\" is not a synonym for \"transactional\": there is no transaction here at all, just a plain `SaveChanges` — textbook self-contained unit. What disqualifies it is the CALLER. Neither password oracle is idempotency-wrapped (login is anonymous so the tenant gate skips it; `/auth/step-up` is on `ResponseNotCacheable`), so the strategy replays that save; on the ambiguous commit the replay re-issues the `UPDATE` under the stale Identity `ConcurrencyStamp`, matches 0 rows, and returns `IdentityResult.Failed` — which the reload loop (correctly present, for genuine parallel writers) reads as \"lost a race\", reloading the **already-incremented** user and incrementing it **again**. One wrong password would then cost two failed accesses and lock at roughly half the #128 threshold — the same consequence that shipped once already on a different path in #336. Wrap the **save** only; the reload is an ordinary replayable read and keeps its retry. The test to write for this shape is not \"does it retry\" but **\"does one input produce exactly one effect\"**. What recovers a write instead is the **client retrying with the same `Idempotency-Key`**, which #307 already makes exactly-once — plus, for the narrow ambiguous commit (Postgres committed, the ack was lost), the middleware probes its own claim and **replays the response it published** rather than reporting a failure. Never fix a symptom of this by re-widening the retry, and never by a blanket `db.ChangeTracker.Clear()` on a context a longer-lived caller may share (that regression dropped `SimulationDataSeeder`'s pending writes). **But refusing to replay is not the answer to every instance of this shape** (#350 review round 5, found by sweeping for it rather than by report). The general hazard is *an automatic replay sitting above a **stateful detector*** — a monotonic counter, a CAS stamp, a single-use claim — where the detector cannot tell \"this request racing itself\" from the real signal it exists to detect. `SingleAttemptExecution` is the right cure only when **the replay itself is observable**, as with `AccessFailedAsync`'s second durable increment. The three auth-token sites are the other kind: EF wraps their statements in one transaction, so a replay after a lost commit ack writes **nothing** and a replay after a rolled-back attempt simply succeeds — the defect was the **catch misreading** the replay's failure, not the replay. There the fix is to **ask the database whether this attempt's own work is durable**, keyed on evidence nobody else could have produced (the hash of a 256-bit token the attempt minted and has not yet handed out): `IdentityProvider.RefreshAsync` (rotation — the severe one: it is *unrecoverable by retrying*, because the rotation is durable so the caller's cookie holds a revoked token while its live replacement was delivered to nobody), `LoginAsync`'s token `INSERT`, and — a replay damaging a *later* statement rather than its own — `AccountLockout.ResetFailedAccessCountAsync`, where Identity swallows the concurrency loss into a discarded `IdentityResult` and leaves the user tracked under a superseded stamp, which the refresh-token `INSERT` sharing that `DbContext` then re-flushed (a **correct** password answered 409 and issued no token). Ask the database first and classify second: which exception EF raises depends on statement ordering inside the batch, so branching on the exception type reads a coin flip. All three fail **closed** — the probe proves durability or the original error stands, so a session is never invented — and #176's anti-fork guarantee is untouched, because a competing consumer mints its *own* random token and can never write our hash. Measured, and pinned from both sides in `RetryBoundaryTests`: wrapping the rotation in `SingleAttemptExecution` fixes the reported bug **and regresses** the ordinary fail-before blip from 200 to 409. One instrument note that cost a review round: `TransientCommandFaultInterceptor(afterExecution: true)` is the ambiguous commit **only for a single-statement save** (no auto transaction to roll back); for a multi-statement one it is a fail-*before*, and using it there yields a green test with the defect fully present — reach for `TransientCommitFaultInterceptor`.\n- **A new Production boot guard must be taught to the sim harness (#370).** Every guard that fails the boot on missing/invalid config (#260 trusted proxies, #261/#262 the TLS floor, #316 the OTLP endpoint, #319 `AllowedHosts`, and whatever comes next) applies to `tools/simulation/` too — its `app` container runs **Production config on purpose**. That harness is **deliberately not in CI** (dev tooling; a GitHub job per push is out of proportion to 5 seconds of work), so **nothing will tell you when you break it**: every path into it is human-started — `reset.sh` directly, or `run-baseline.sh`, which calls `reset.sh` once per rep — and by 2026-08 four guards had landed without it and it could no longer boot `main` at all. **When you add or change a boot guard, or add/rename/retire a config key, update `tools/simulation/bootstrap.sh` + `docker-compose.sim.yml` in the same PR** and add the check to `tools/simulation/verify-harness.sh` — a ~0.1s self-check that `reset.sh` runs automatically before it wipes the volume, so a config defect fails in a tenth of a second instead of five minutes later at `/health/ready`. Treat a boot-guard PR that leaves the harness behind like a missing test. Note the harness satisfies guards **properly** (a concrete `AllowedHosts`, the documented plaintext opt-outs for its co-located sidecar) — never by disabling one.\n- **SPA E2E lives in `tools/simulation/ui/` (#277/#385), not in `web/`.** Playwright drives the real built SPA against the **same** `seed --profile simulation` fixture k6 uses, so screens are populated rather than empty; `web/` stays Vitest + Testing Library. Three rules it exists to enforce, all of which have already caught something: **\n",{"_434":936,"_413":414,"_436":420},{"_437":937,"_439":-5,"_45":-5,"_441":938,"_443":-5,"_100":939,"_96":445},[940],{"_446":420},"developer",{"_49":941,"_96":491},"Do not spawn sub-agents unless the user or applicable AGENTS.md/skill instructions explicitly ask for sub-agents, delegation, or parallel agent work.",{"_434":943,"_413":414,"_436":420},{"_437":944,"_439":-5,"_45":-5,"_441":945,"_443":-5,"_100":939,"_96":445},[946],{"_446":420},{"_49":947,"_96":491},"You are `/root`, the primary agent in a team of agents collaborating to fulfill the user's goals.\n\nAt the start of your turn, you are the active agent.\nYou can spawn sub-agents to handle subtasks, and those sub-agents can spawn their own sub-agents.\nAll agents in the team, including the agents that you can assign tasks to, are equally intelligent and capable, and have access to the same set of tools.\n\nYou can use `spawn_agent` to create a new agent, `followup_task` to give an existing agent a new task and trigger a turn, and `send_message` to pass a message to a running agent without triggering a turn.\nChild agents can also spawn their own sub-agents.\nYou can decide how much context you want to propagate to your sub-agents with the `fork_turns` parameter.\n\nYou will receive messages in the analysis channel in the form:\n```\nMessage Type: MESSAGE | FINAL_ANSWER\nTask name: \nSender: \nPayload:\n\n```\nThey may be addressed as to=/root\n\nNote that collaboration tools cannot be called from inside `functions.exec`. Call `spawn_agent`, `send_message`, `followup_task`, `wait_agent`, `interrupt_agent`, and `list_agents` only as direct tool calls using the recipient shown in their tool definitions, such as `to=functions.collaboration.spawn_agent`, since they are intentionally absent from the `functions.exec` `tools.*` namespace. Available tools in `functions.exec` are explicitly described with a `tools` namespace in the developer message.\n\nAll agents share the same directory. In detail:\n- All agents have access to the same container and filesystem as you.\n- All agents use the same current working directory.\n- As a result, edits made by one agent are immediately visible to all other agents.\n\nThere are 4 available concurrency slots, meaning that up to 4 agents can be active at once, including you.",{"_434":949,"_413":414,"_436":420},{"_437":950,"_439":-5,"_45":-5,"_441":951,"_443":-5,"_100":939,"_96":445},[952,953],{"_446":420},{"_49":955,"_96":491},{"_49":954,"_96":491},"\n## Skills\nA skill is a set of instructions provided through a `SKILL.md` source. Below is the list of skills that can be used. Each entry includes a name, description, and source locator. `file` locators are on the host filesystem, `environment resource` locators are owned by an execution environment, `orchestrator resource` locators are opaque non-filesystem resources, and `custom resource` locators use their provider's access mechanism.\n### Available skills\n- imagegen: Generate or edit raster images when the task benefits from AI-created bitmap visuals such as photos, illustrations, textures, sprites, mockups, or transparent-background cutouts. Use when Codex should create a brand-new image, transform an existing image, or derive visual variants from references, and the output should be a bitmap asset rather than repo-native code or vector. Do not use when the task is better handled by editing existing SVG/vector/code-native assets, extending an established icon or logo system, or building the visual directly in HTML/CSS/canvas. (file: /opt/codex/skills/.system/imagegen/SKILL.md)\n- openai-docs: Use when the user asks how to build with OpenAI products or APIs, asks about Codex itself or choosing Codex surfaces, needs up-to-date official documentation with citations, help choosing the latest model for a use case, or model upgrade and prompt-upgrade guidance; use OpenAI docs MCP tools for non-Codex docs questions, use the Codex manual helper first for broad Codex self-knowledge, and restrict fallback browsing to official OpenAI domains. (file: /opt/codex/skills/.system/openai-docs/SKILL.md)\n- plugin-creator: Create and scaffold plugin directories for Codex with a required `.codex-plugin/plugin.json`, optional plugin folders/files, valid manifest defaults, and personal-marketplace entries by default. Use when Codex needs to create a new personal plugin, add optional plugin structure, generate or update marketplace entries for plugin ordering and availability metadata, or update an existing local plugin during development with the CLI-driven cachebuster and reinstall flow. (file: /opt/codex/skills/.system/plugin-creator/SKILL.md)\n- skill-creator: Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Codex's capabilities with specialized knowledge, workflows, or tool integrations. (file: /opt/codex/skills/.system/skill-creator/SKILL.md)\n- skill-installer: Install Codex skills into $CODEX_HOME/skills from a curated list or a GitHub repo path. Use when a user asks to list installable skills, install a curated skill, or install a skill from another repo (including private repos). (file: /opt/codex/skills/.system/skill-installer/SKILL.md)\n","\nFilesystem sandboxing defines which files can be read or written. `sandbox_mode` is `danger-full-access`: No filesystem sandboxing - all commands are permitted. Network access is enabled.\nApproval policy is currently never. Do not provide the `sandbox_permissions` for any reason, commands will be rejected.\n","turn/started",{"_413":414,"_91":958},{"_107":-5,"_45":420,"_421":959,"_423":424,"_425":426,"_427":960},[],"inProgress",{"_427":962,"_413":414},{"_963":964,"_96":965},"activeFlags",[],"active","thread/started",{"_968":969},"thread",{"_970":-5,"_971":-5,"_972":973,"_974":426,"_465":466,"_975":18,"_976":-5,"_977":-5,"_978":-5,"_979":980,"_45":414,"_981":982,"_185":-5,"_983":-5,"_165":984,"_985":203,"_986":426,"_987":414,"_472":988,"_427":989,"_990":-5,"_81":991,"_992":426},"agentNickname","agentRole","cliVersion","0.144.0-alpha.4","createdAt","ephemeral","extra","forkedFromId","gitInfo","historyMode","legacy","modelProvider","openai","parentThreadId","/opt/codex/sessions/2026/08/03/rollout-2026-08-03T00-51-48-019fc51a-ffff-7491-8184-18a6a2328ba4.jsonl","preview","recencyAt","sessionId","vscode",{"_96":431},"threadSource",[],"updatedAt",[],"messages",[996],{"_45":997,"_998":999,"_1000":1001,"_1002":1001,"_437":1003,"_427":1004,"_439":-5,"_1005":35,"_1006":1007,"_1008":1009,"_1010":-5},"b94f475d-2a2a-4b2d-9c81-a21678377ff0","author",{"_100":330,"_185":-5,"_1006":1019},"create_time",1785718307.602189,"update_time",{"_1015":49,"_1016":1017},"finished_successfully","weight","metadata",{"_1011":1012},"recipient","all","channel","l1239dk1",{"_1013":1014},"inline_comments",[],"content_type","parts",[1018],"@codex Summary of what this PR still needs, consolidated. The epoch mechanism itself is correct and reviewed — the defaults, the three password paths, the replay-branch ordering, and the fail-closed unknown-user case all check out. Details in my earlier review.\n\n**1. Fold the migration into `InitialCreate` and drop the data statement.** Both of your P1s land here; see my replies on those two threads for the exact column shapes, why `AppDbContextModelSnapshot.cs` needs no change, and the `MigrationSecurityReviewTests` adjustments. The short version: hand-edit `InitialCreate` (never regenerate — it carries four un-regenerable `lower(\"Name\")` expression indexes and 21 rows of guarded reference-data SQL), keep `CredentialEpoch` default **1** and `IssuedEpoch` default **0**, delete both the `UPDATE refresh_tokens` backfill and the `SET LOCAL lock_timeout` guard. Worth adding an `ExactlyOneMigrationExists_AndItIsInitialCreate` fence while you are in there — the repo documents that contract but nothing enforced it, which is how a second migration got this far green.\n\n**2. Sweep the claims this change falsified.** #364's whole point is that an access token *is* now revocable server-side. Six live statements say the opposite:\n\n| location | claim |\n|---|---|\n| `Cluckwork.Application/Common/IIdentityProvider.cs:48` | \"an already-issued JWT stays valid until it expires (~15 min) — there is no server-side denylist\" (on `SetUserPasswordAsync`, which now bumps the epoch) |\n| `Cluckwork.Infrastructure/Identity/IdentityProvider.cs:369` | \"no denylist\" — the comment sits directly above the new `CredentialEpoch++` |\n| `Cluckwork.Infrastructure/Identity/JwtTokenService.cs:45-49` | the window is \"bounded only by ~15 min, same as every other credential rotation\" |\n| `specs/product/GLOSSARY.md` (Password change) | \"keeps working until it expires (~15 min), because tokens are stateless and there is no server-side denylist\" |\n| `docs/runbooks/break-glass-account-recovery.md:28` | same claim — **this is the one that matters most**, because an operator reads it mid-incident to decide whether an exposure window remains |\n| `tests/Cluckwork.Api.IntegrationTests/StepUpAuthTests.cs:255-258` | its path is `change-password`, which *does* bump the epoch |\n\nTwo that look similar and must be **left alone** — no password reset occurs on those paths, so the epoch does not move: `StepUpGrantService.cs:16` (theft threat model) and GLOSSARY's Step-up substantive claim. The `StepUpAuthTests` logout-scenario comments are also fine — `RevokeRefreshTokenAsync`/`RecordLogoutAsync` never touch `CredentialEpoch`. But GLOSSARY's Step-up entry cross-references \"see **Password change** above\" for the no-denylist claim, so repoint it once that passage changes, or #308's rationale inherits a claim that is no longer general.\n\n**3. An `AGENTS.md` bullet.** Every comparable posture has one — #283, #265, #308, #269. Two invariants here will be broken silently otherwise: **epoch `0` is permanently retired** (an absent or malformed claim is a *mismatch*, never an exemption — someone \"tidying\" the parse into `?? currentEpoch` reopens the hole), and the middleware's placement after `TenantResolutionMiddleware`, before `MustChangePasswordMiddleware`, with `/api/v1/auth/logout` deliberately exempt. State the per-request DB read as a deliberate trade-off too, since it is the obvious thing a later optimisation would cache and thereby defeat. Say how this relates to #283/#265/#308 — the file already warns against conflating those four credential concepts.\n\n**4. Two things for the PR body rather than the code.** `LoginAsync`'s new `DisabledAt` check cannot fire — nothing writes that column (`ApplicationUser.cs` documents it as groundwork for #356), so it is inert by construction today and should not read as a fix for a live hole. And the sim-harness step your body lists as environment-blocked still needs a real run before merge; `openssl` is available on the dev box even though it was missing where the work was done.\nCredential epoch: per-request revocation checks\n\nCloses #364\n\n## Summary\n\n- bind access and refresh tokens to a per-user credential epoch, with immediate access-token invalidation after password resets and disabled-account enforcement\n- keep epoch `0` permanently retired, including refresh-grace replacements written by a pre-epoch replica\n- fold the schema into the sole pre-production `InitialCreate` migration and fence the one-migration contract\n- scope replay revocation to the checked epoch and pin the cross-epoch race with a deterministic barrier test\n- pass protected-request 401 reasons through the SPA login screen and document forward rollout plus fail-closed rollback ordering\n- repair the simulation harness's Node 26 ESM boundary and seeded-draft Worker setup found by the required end-to-end verification\n\n## Verification\n\n- `dotnet build Cluckwork.sln`: 0 warnings, 0 errors\n- `dotnet test Cluckwork.sln --no-build`: Domain 283, Application 114, Integration 769; all passed\n- focused credential/migration/re-execution suite: 26 passed\n- `cd web && npm run typecheck && npm test`: 67 files / 1,275 tests passed\n- `bash tools/simulation/reset.sh`: image built; virgin schema migrated; health, bootstrap-admin rotation, simulation seed, and manifest checks passed\n- `cd tools/simulation/ui && npm run typecheck`: passed\n- `cd tools/simulation/ui && npm test`: 28 passed, 1 intentional 15-minute test skipped\n- `cd tools/simulation/ui && npm run mutation`: baseline green, 9 real mutants killed, 1 known false kill classified separately, 0 survivors, restore green\n\n## Mutation checks added in this revision\n\n- removing epoch scoping from replay-family revocation makes the barrier-controlled test fail because the fresh family is revoked\n- removing the exception-handler re-execution guard replaces the original 500 with a credential 401\n- moving credential-epoch enforcement after idempotency makes a stale keyless write return 400 instead of the required 401\n\n@codex review\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `f6d30de994`\n \n\n

ℹ️ About Codex in GitHub

\n
\n\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\n- Open a pull request for review\n- Mark a draft as ready\n- Comment \"@codex review\".\n\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\n\n\n\n\nCodex can also answer questions or update the PR. Try commenting \"@codex address that feedback\".\n \n