@aventara/access 0.0.0-stage → 0.1.0-rc.0

package/CHANGELOG.md

@@ -0,0 +1,831 @@
+# @aventara/access
+
+## Unreleased
+
+- The engine warns, as a Node.js warning `ACCESS_REFERENCE_UNREADABLE`, when a role may create or update a reference
+  (a to-one relation's reference fields) to a Resource no read grant reaches for that role. Aventara holds a reference
+  a write sends to the rows the caller may read, so such a write is refused (`A4002`). It holds only references to the
+  Resources its Core Contract shows, and says which when it hosts the engine (`engine.hosted({ held })`, called by
+  `@aventara/core` `1.0.0-rc.10` or later), so the warning comes then, for those Resources only: one the app's root
+  exemptions hide is not warned about, and compiling the rules (`.contract()`, `avaccess push`) warns about nothing.
+  The warning changes nothing the engine decides. A reference the grant locks with `write: { except }` is not warned
+  about, nor is one to a foreign Resource (below).
+- The engine lists the Resources its rules read as foreign in `unheld`. No caller reads a foreign Resource, so under
+  `@aventara/core` `1.0.0-rc.10` every write of a reference to one (a chat `Room`'s `campaignId`) was refused; with
+  `unheld`, Aventara holds no written reference to them, and the write grant decides which row may be linked: a
+  `where` on a create grant, an `after` (or the `where`) on an update grant, through the relation. Reads of a foreign
+  Resource are unchanged. When Aventara hosts the engine, a role whose create or update grant may write such a
+  reference with no condition through that relation is warned about (`ACCESS_FOREIGN_REFERENCE_UNCHECKED`, a Node.js
+  warning, once per process and namespace): any row of the foreign Resource could be linked by its identifier.
+- The container image `aventara/access-server` is removed, with its `access-deps` script. Run `avaccess serve` in a
+  container you build: the README's "Running `avaccess serve`" shows a minimal Dockerfile. `avaccess serve` itself is
+  unchanged.
+- Better Auth is taken at a patch range, `~1.7.12`: `better-auth`, `@better-auth/oauth-provider` and
+  `@better-auth/cimd` are optional peers at `~1.7.12`, and `createAccess`, `aventaraAccess()` and the `mcp`/`audience`
+  checks take 1.7.12 or any later 1.7 patch. An older version, 1.8 or a prerelease is still refused with
+  `ACCESS_BETTER_AUTH_VERSION`. A plain `npm install @aventara/access better-auth @better-auth/oauth-provider` now
+  resolves; `@better-auth/core` and `@better-auth/utils` no longer need pinning by hand. Tested on 1.7.14.
+- `createAccess({ mcp: { resource } })` and `aventaraAccess({ mcp: { resource } })` make Access the authorization
+  layer of an MCP endpoint. Better Auth's own OAuth provider (`@better-auth/oauth-provider` `~1.7.12`, in Better Auth's
+  plugins with its options untouched) issues the tokens; Access issues none and serves no OAuth route.
+  `access.mcp` (and `accessOf(auth).mcp`) is the framework's `mcp.authorization`, `{ servers, verify }`, typed present
+  exactly when `mcp` is given. `verify` takes the provider's JWT access token for that endpoint alone (RFC 8707) and
+  resolves `{ sub, claims, clientId, scopes }`, the claims read from the user on every request; it refuses a session
+  token, a token for another resource, an opaque, DPoP-bound or client-credentials token, and one whose client is
+  disabled, whose user is gone or no longer consents to its scopes and its resource, whose session has ended or which
+  names none (`sid`), whose resource the provider no longer has, or which is signed with an algorithm `jwt()` does not
+  sign with. A consent stored under a reference never counts.
+- The request state reads the same token. The principal it yields is held to it before the rules: refused every
+  question under any origin but `agent`; under `agent`, `aventara:read` admits reads and `aventara:write` writes, and
+  what they admit is the user's own grants. A refusal is an audit event with the reason `deny:mcp-audience` or
+  `deny:mcp-scope`. Access's `GET /me` route answers the token `null`; `access.client.verbs.me.call` (the MCP `me`
+  tool's) answers its identity `{ sub, claims }`, which `agentOf` tells is an agent's.
+  `agentOf(me)` (`/auth`, `/better-auth`) tells app code an agent's principal, and the identity `principal` maps for
+  one: `{ clientId, scopes }`, else `null`.
+- `audience` (`createAccess` and `aventaraAccess()`) is a service's opt-in to its own token audience (RFC 8707): with
+  it, a bearer token is taken only when it is the provider's access token addressed to the service and carrying
+  `aventara:read` or `aventara:write`, held to those scopes under every origin; the one-org token `GET /token` issues
+  is refused. Off by default, with no change to the default path.
+- Under `mcp` or `audience`, Access refuses to start on a provider that would let a token's authorization fall short:
+  none or two in the plugins, a version outside `~1.7.12` (`ACCESS_BETTER_AUTH_VERSION`), `disableJwtPlugin`, a
+  resource missing from its `resources`, no `aventara:read` among its `scopes`, a `refreshTokenReuseInterval`
+  other than 0, a `validateRedirectUri`, a `requestUriResolver`, a `postLogin.consentReferenceId`, open client
+  registration (`allowUnauthenticatedClientRegistration`) unless `mcp.openRegistration: true` acknowledges it (never
+  under `audience` alone), a resource that is the provider's UserInfo URL, or the `service` profile; with `audience`,
+  `enforcePerClientResources: false`, and beside `mcp`, the audience in `clientRegistrationDefaultResources` or
+  `clientRegistrationAllowedResources` (an agent's self-registered client would get tokens that pass for the
+  service's). A `cimd()` outside `~1.7.12` is refused with `ACCESS_BETTER_AUTH_VERSION`. Every authorization request
+  must use PKCE with its SHA-256 method and carry its own parameters (no `request_uri`). Under `mcp` the issuer must be https, or http on `127.0.0.1` or `[::1]` (`localhost` is refused
+  with the address to write).
+- The plugin answers for `jwt()` in Better Auth's context (`ctx.getPlugin("jwt")`), so a plugin that looks `jwt()` up
+  by its id, as the OAuth provider does, finds the one `aventaraAccess()` carries. A provider listed before
+  `aventaraAccess()` is refused with a sentence naming the order.
+- The session verifier refuses an OAuth access token (`typ: "at+jwt"`) whatever it carries.
+- The session verifier and the access-token verifier take only the asymmetric algorithms `jwt()` signs with; a key
+  the set publishes without naming its algorithm no longer verifies a token signed with another.
+- `@better-auth/oauth-provider` and `@better-auth/cimd` are optional peers at `~1.7.12`. New `/auth` and
+  `/better-auth` names: `AccessMcpOptions`, `AccessMcpAuthorization`, `AccessAgentIdentity`, `AccessAgent`, `agentOf`.
+- `profile: { kind: "kiosk", canEnrollDevice, idleTimeout? }`: the web profile plus staff switching by PIN on enrolled
+  devices. A fresh full-credential session that `canEnrollDevice` allows enrolls a device (`POST
+  /kiosk/enroll-device`): the device gets a random credential in an HTTP-only cookie (a `__Host-` cookie on an https
+  base URL), stored as its SHA-256, and the enrolling session ends. `POST /kiosk/set-pin` sets a fresh
+  full-credential session's own PIN; your server sets anyone's with Better Auth's server-only endpoint
+  `access.api.kioskSetUserPin({ body: { userId, pin } })`. `POST /kiosk/switch-user` (`{ userId, pin }`) opens a
+  session for that user on an enrolled device and ends every session on it and every one the request carried; `POST
+  /kiosk/lock` ends the same; `POST /kiosk/revoke-device` revokes one and `GET /kiosk/list-devices` lists them, for a
+  manager. `access.kiosk` is the operator's API on the server: `listDevices()` and `revokeDevice(deviceId)`. On the
+  web and service profiles these routes answer `404`.
+- A PIN is 6 to 12 digits and is refused when it is one a guesser tries first: iOS's 6-digit passcode blocklist (as
+  Markert et al. extracted it) widened to every length, and the most common 6-digit PINs of leaked passwords. It is
+  hashed with argon2id at the `passwords` profile, whatever hashes passwords. Wrong PINs are limited per user id on one
+  device (5, then a backoff doubling from 1 minute to 1 hour, and after 100 in a row the PIN stops working there,
+  `KIOSK_PIN_DISABLED`) and per device (10 at once for any users, then one more every 90 seconds), both counted in the
+  database before the PIN is checked. The per-user count is kept for any user id, one with no PIN or no user included,
+  so no answer tells who holds a PIN; it is per device, so it slows or disables a colleague's PIN on that device only,
+  and a full sign-in (not an admin's impersonation) or a new PIN clears it. While a device is held, a user with no
+  wrong PIN on it since their last right one still gets one try.
+- Every session opened on an enrolled device (a PIN switch's, or a password sign-in's there) is bound to it: on every
+  call of Better Auth's that carries it, by cookie or by `Authorization: Bearer` (`access.state` and `GET /me`
+  included), it is ended unless the request brings the device's current credential, or when it has been idle for
+  `idleTimeout` (300 seconds by default, 60 to 3600) with no request that may change something (a read, such as a
+  page polling `/get-session`, does not count). A bound session is issued no token, and `/get-session` answers it
+  without its token; no answer on this profile carries `bearer()`'s `set-auth-token`, whatever the plugin's id. With
+  `mcp` or `audience`, a bound session is refused at the OAuth provider's grant and client- and consent-management
+  routes, and a sign-in on an enrolled device that would resume an authorization request (in its body, or in a social
+  sign-in's state begun elsewhere) opens no session. The credential is replaced at every switch, and every replaced one is kept as a hash: any of
+  them brought back revokes the device, except the one the last switch replaced within 30 seconds of it, which is
+  refused (`409 KIOSK_DEVICE_BUSY`) with the device and its cookie left as they are, a sign-in that brings it included. A PIN session reaches only
+  reading its session, signing out, `me`, the key set, the switch, the lock and the full-credential sign-ins (`403
+  KIOSK_SESSION_NOT_ALLOWED` otherwise), through `access.handler` and through the server's own `access.api` calls with
+  its cookie.
+- A switch opens a new session with the switched-to user's own claims and ends the one before; nothing of it carries
+  over. The audit log gains `kiosk-switch` (with `previousUserId` and `deviceId`), `kiosk-lock` (`lock`, `idle`,
+  `device-mismatch`), `kiosk-device` (`enrolled`, `revoked`, `token-reuse`, `stale-in-grace`) and `kiosk-pin`; a wrong PIN is a
+  `sign-in-failed` on `/kiosk/switch-user` with its `deviceId`. With `audit: true` on this profile, the `accessAudit`
+  table gains `deviceId` and `previousUserId`.
+- The kiosk adds the tables `accessKioskDevice`, `accessKioskPin`, `accessKioskLockout` and
+  `accessKioskRetiredSecret`, and `kioskDeviceId`, `kioskSeenAt` and `kioskPin` on Better Auth's `session`; the
+  credential and PIN hashes are secret columns no grant opens.
+- On the kiosk profile `access.client.verbs` publishes the kiosk's verbs (`switchUser`, `lock`, `setPin`,
+  `enrollDevice`, `revokeDevice`) after Better Auth's, as the framework's `$access` takes them.
+- The kiosk profile refuses a second kind (`kind: ["kiosk", "service"]`), its keys on another kind, Better Auth's
+  cookie cache, `secondaryStorage` without `session.storeSessionInDatabase`, `bearer()`, `multiSession()`,
+  `crossSubDomainCookies` and `SameSite=None`, a plain http: base URL off a loopback host, and a plugin with an
+  endpoint under `/kiosk/`
+  (`ACCESS_PLUGIN_DUPLICATE`). `/auth` exports `AccessProfileOptions`, `AccessKioskProfile`, `AccessKiosk` and
+  `AccessKioskDevice`.
+- `profile.insecureLan` (kiosk only): for an on-prem till network without TLS, the private IPv4 ranges on whose
+  addresses the kiosk takes a plain http: base URL, such as `http://192.168.1.10:3000` under
+  `["192.168.1.0/24"]`. A range is an IPv4 CIDR written in full (no leading zeros, host bits clear), a /16 or
+  narrower, wholly inside 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16; a hostname, IPv6, shared, link-local,
+  loopback or public range, an empty list, a repeated range or one inside another is refused (`ACCESS_OPTIONS_INVALID`), and so is the
+  key on `web` or `service` (also a type error: the type is a non-empty list of `${number}.${number}.${number}.${number}/${number}`).
+  The base URL must be an IPv4 address inside a listed range, written as the URL parser writes it (no leading zeros,
+  octal, hex or single number) and not the range's network or broadcast address, never a hostname; no `advanced` cookie setting may make
+  a cookie `Secure` or name it `__Secure-`/`__Host-` there (a browser drops it over http); the device cookie is
+  then `better-auth.kiosk_device`, HTTP-only, `SameSite=Lax`, at `/`, without `Domain`. Better Auth's logger warns at
+  startup, naming the base URL and the ranges. An https: or loopback base URL ignores the option.
+- The kiosk profile reads a dynamic `baseURL` whole: it needs `protocol: "https"` unless every allowed host is a
+  loopback host (its fallback alone was read before, so `protocol: "http"`, `"auto"` or unset served the allowed
+  hosts in the clear), and `insecureLan` takes a fixed `baseURL`.
+- The kiosk ends a session bound to no device when the request brings an enrolled device's credential (current, in
+  its grace, or retired), as it ends one of another device (`kiosk-lock`, reason `device-mismatch`). Such a session
+  was opened off the device: from a React Native till on `@better-auth/expo`, a native ID-token sign-in (its client
+  sends no cookie with it) or a sign-in in the system browser handed to the app (a magic link, social sign-in's
+  redirect). Before, it went on unbound on the till: its token answered by `/get-session` and `GET /token`, and no idle
+  lock. The README's kiosk section documents a till that is an Expo app (`expo()`, the app's scheme in
+  `trustedOrigins`, the ID-token sign-in with its cookies passed, cleartext under `insecureLan`).
+- `aventaraAccess({ registry: { enabled: true } })` makes the app that runs Better Auth the registry's hub, with no
+  Access server beside it. The block is `createAccess`'s (`enabled`, `ownership`). The registry's tables are the
+  plugin's schema (the same tables `createAccess` uses, created by Better Auth's `migrate`/`generate` through the app's
+  adapter) and its routes are the plugin's endpoints under `/access/v1`, served wherever the app mounts
+  `auth.handler`. Off by default: no tables, and `/access/v1/*` answers `404`.
+- `accessOf(auth).registry` is the operator's API when the plugin serves the registry, typed present exactly then
+  (`AccessProvider`'s fourth parameter; the plugin's `$Infer.AccessRegistryEnabled`). No route opens it.
+- `avaccess keys --server <module>` takes a module that exports `accessOf(auth)`. A module that exports only Better
+  Auth's own instance is refused with a sentence that names `accessOf(auth)`.
+- With the registry on (`createAccess` or the plugin), another Better Auth plugin with an endpoint named like one of
+  the registry's (`accessPush`, `accessHead`, …) or at a path under `/access/v1`, or with a middleware whose path can
+  match one there (`/access/v1/**`, `/access/**`, `/**`, `/*/v1/key`), is refused with `ACCESS_PLUGIN_DUPLICATE`: it
+  would answer a service's push or pull and read the key it sends. Other plugins' `onRequest` and `hooks` are inside
+  the app's trust boundary and are not checked.
+- An endpoint path is checked as Better Auth's router reads it, one leading slash and no trailing one, for the
+  registry's routes, `jwt()`'s `/jwks` and `/token`, and the `me` route: `token` or `access/v1/key` without the slash
+  was not refused before.
+- The hub keeps Better Auth's one org token (issuer and audience the base URL): a token works at every service that
+  checks the hub's key set, and at the hub, until it expires. Access adds no token endpoint; a token bound to one
+  service is an opt-in from Better Auth's OAuth provider with resource indicators.
+- `@aventara/access/better-auth` exports `AccessIdentity`, the default principal type: an app that leaves out
+  `principal` and emits declarations (`export const auth = betterAuth({...})`) failed with TS2742/TS2883 without it.
+- A token Access issues carries every declared boolean claim: one the user's field leaves unset (absent, `null` or
+  `undefined`), or `policies.claimsOf` returns as `null` or `undefined`, is `false`. A token for a user with no ban
+  now carries `banned: false`.
+- `policies.claimsOf` must return every declared boolean claim's key. An answer without one is refused with
+  `ACCESS_OPTIONS_INVALID`, naming the claim, and no token is issued. It is a type error too: `claimsOf` returns an
+  `AccessClaimsAnswer` (from `/auth`), where each declared boolean claim is required and the others stay optional, in
+  `createAccess` and in `aventaraAccess()`.
+- `policies.claims` refuses a claim named `__proto__`. A claim name is matched against the declaration and a token's
+  payload by own key only, so `toString` or `constructor` is undeclared unless declared.
+- Tokens issued before this version lack the boolean claims, so a deny such as `banned: true` refuses them until they
+  expire, within `policies.tokenTtl` (15 minutes by default). Users sign in again or fetch a new token.
+- A deny's `if` (a guardrail's too) holds on a claim the principal lacks whatever value it compares with, `true`
+  included. `banned: true` still leaves alone a user whose ban is unset, since their token carries `banned: false`,
+  and now denies a token that lacks `banned` (one from another issuer, or issued before the claim was declared): it
+  fails closed. The anonymous caller is the exception: a comparison with `true` never holds for it, so a ban does
+  not close an `anyone` grant. A generated client copies the change; run `avaccess generate` again.
+- A principal you build yourself (in tests, or from another issuer's token) must carry each boolean claim a deny
+  compares with `true`, as an issued token does, or that deny refuses it.
+- An update is held to one grant. `can({ action: "update", row, before })`, with `before` the row as it was before
+  the update, allows it only when one update grant covers both rows: its `where` the row before, its `where` and
+  `after` the row after. A row that one update grant covers before the update and only another covers after it is
+  refused. Update denies are asked about the row after only, as before. Aventara hands `can` the row before every
+  update the engine lists in `afterChecks` from `@aventara/core` `1.0.0-rc.10` on; without `before` (an older core),
+  `can` answers as it did, on the row after alone.
+- A generated client's `can` takes the same optional `before`, with the same answer; run `avaccess generate` again.
+- The engine answers `grantsOf({ principal, origin, resource, action: "update", row, exists })`: the keys of the
+  update grants whose `where` and subject's row condition hold on `row` as it is now. `@aventara/core`
+  `1.0.0-rc.10` asks it before an update `afterChecks` lists writes, and hands the answer back to `can` as
+  `beforeGrants`. With `beforeGrants`, the grant that covers the row after must be one of them. With `before` too,
+  each listed grant's `where` is still checked on `before` in memory (a key list replayed from another row or
+  principal fails closed on a scalar condition), and a relation condition on it is not asked again: it is decided
+  before anything the same request writes. A row
+  handed to someone else and tagged "shared" in the same update is refused by a grant on shared rows. Without
+  `beforeGrants`, `can` answers as it did.
+- The keys are opaque and stable for one policies file: a short hash of the file's grants, then a grant's place in
+  it and its subject's place in the grant, no rule id or condition; a list from another file covers nothing.
+  `grantsOf` answers `[]` on a row an update deny already refuses in memory. A `beforeGrants` that is not a list of strings fails closed, and a `grantsOf` question
+  about anything but an update is refused with `ACCESS_QUESTION_INVALID`. `AccessGrantsQuestion` is exported.
+- A generated client has `grantsOf`, with `GrantsQuestionOf<R>`, and its `can` takes `beforeGrants` on an update
+  question only, with the same answers as the engine; a `grantsOf` about anything but an update throws an error
+  shaped as `AccessError` (`code: "ACCESS_QUESTION_INVALID"`). Run `avaccess generate` again.
+- `access.client`: what the framework's `$access` reads from a `createAccess` instance. `url` is Better Auth's base URL
+  with its base path (the base path alone when `baseURL` is dynamic). `verbs` holds `signIn`, `signUp`, `signOut`,
+  `resetPassword` and `me`, each with its method, its path under `url`, the JSON Schema of its arguments and of its
+  result, and `call`. The arguments follow Better Auth's client; a result names the user's id and Better Auth's flags,
+  never the session token or a user field; `me` is the token identity, `{ sub, claims }`, with the declared claims.
+- A verb the instance does not serve is left out: `signIn`, `signUp` and `resetPassword` without `emailAndPassword`,
+  `signUp` with `disableSignUp`, a verb whose path is in `disabledPaths`, and `signIn` and `signUp` on the `service`
+  profile.
+- `call({ args, headers })` runs the verb in-process through Better Auth's API with the request's headers, so
+  `nextCookies()` sets the cookie from a Server Action. It is held to the route's checks: its arguments to the verb's
+  schema, Better Auth's origin check (which its router runs and a direct API call skips), the profile's refusals and the
+  audit log. Its answer is cut to the verb's result schema.
+- `call` of `signIn`, `signUp` and `resetPassword` is rate-limited, since a call to Better Auth's API skips the limit
+  its router applies. The limit is Better Auth's own `rateLimit` options (on when they turn it on, the route's rule,
+  their storage), counted by client address (read as Better Auth reads it, `trustedProxies` included, under the
+  router's key) and by target (the email or reset token named, as an HMAC). The target bucket counts failures, 10
+  each within 5 minutes of the one before, and a success clears it, so others' failures cannot keep the owner out.
+  Over either, the call throws Better Auth's `429` with `X-Retry-After`, and the audit log records a
+  `sign-in-failed` with reason `rate-limited`.
+- `call` runs every plugin's `onRequest`, as Better Auth's router does before a route, so `captcha()` and its kind
+  hold for server calls too: a refusal is thrown as Better Auth's `APIError` with the plugin's status and body.
+- `GET /api/auth/me` answers the request's identity, `{ sub, claims }`, or `null`, uncached. A plugin in
+  `betterAuth.plugins` with an endpoint at `/me` or named `accessMe` is refused with `ACCESS_PLUGIN_DUPLICATE`.
+- `@aventara/access/better-auth`: `aventaraAccess({ policies, principal?, resources?, organization?, audit? })` is Access as a
+  plugin of the Better Auth an app builds itself (`betterAuth({ plugins: [aventaraAccess(...)] })`). It carries Better
+  Auth's `jwt()`, so its tokens carry `sub` and the declared claims only, under the base URL's origin as issuer and
+  audience. It runs `createAccess`'s own checks on Better Auth's options when Better Auth starts it, and refuses what
+  `createAccess` refuses, with the same codes.
+- `accessOf(auth)` is the framework's `access` option from that instance: the engine, with Better Auth's tables closed
+  and their secrets sealed as under `createAccess`, and each request's `me` from a bearer token or the session
+  cookie. `accessOf(auth).$Infer` types the principal and the claims.
+- The organization bridge, `organization: { claim, organizationClaim, roles }`, puts a member's role in the session's
+  active organization into one claim and that organization into another, both declared strings; `roles` is an ordered
+  list of `[Better Auth role, value]`. It is read from Better Auth's store when a token is issued, so removing a member
+  removes both claims from the next token. A rule on the bridged role is held to the organization
+  (`where: { organizationId: me.org }`). The bridge refuses an organization plugin that lets any user create an
+  organization (`allowUserToCreateOrganization` must be `false` or a function), and, with dynamic access control, a
+  role that is not static. A member's roles are read as Better Auth reads them: `member, owner` gives nothing.
+- `audit` (`true` or `{ sink }`) logs in plugin mode as under `createAccess`: sign-ins, refused sign-ins, sign-outs
+  and tokens, and the decisions of `accessOf(auth).policy`.
+- One `aventaraAccess()` in two Better Auth instances whose options differ is refused (`ACCESS_PLUGIN_DUPLICATE`).
+- `aventaraAccessClient({ api })` adds `authClient.access.can([...])` to Better Auth's client: one
+  `POST {api}/_access/can` to the framework for the whole page, one boolean per question, answered as Better Auth's
+  `{ data, error }`.
+- Better Auth's advisory GHSA-fmh4-wcc4-5jm3 is unfixed as of `better-auth` 1.7.14 (the GitHub advisory database's entry
+  still says it was fixed in 1.6.11): its organization plugin lets a user whose email is not verified accept an
+  invitation sent to that email. `createAccess` with `resources: { members: true }`, and the organization bridge,
+  now refuse an `organization()` plugin without `requireEmailVerificationOnInvitation: true`
+  (`ACCESS_OPTIONS_INVALID`).
+- `aventaraAccess()` inside `createAccess`'s `betterAuth.plugins` is refused by name (`ACCESS_PLUGIN_DUPLICATE`).
+- `createAccess` hashes passwords with argon2id. Better Auth hashes with scrypt; Access now offers three ways:
+  - by default, when neither `passwords` nor `betterAuth.emailAndPassword.password` is set, argon2id at the
+    `"owasp-minimum"` profile (m=19456 KiB, t=2, p=1, the OWASP Password Storage Cheat Sheet's minimum);
+  - a named profile, `passwords: { argon2id: "owasp-minimum" | "rfc9106-low-memory" }` (the second is RFC 9106's
+    second recommended option, m=65536 KiB, t=3, p=4). A misspelled profile is a type error, and
+    `ACCESS_OPTIONS_INVALID` at runtime;
+  - the app's own `betterAuth.emailAndPassword.password` hook, which passes through untouched. Setting it and
+    `passwords` together is refused with `ACCESS_OPTIONS_INVALID`.
+- argon2id runs on Node.js's `crypto.argon2` (Node.js 24.7.0 and later), with no native dependency. On Node.js 22 it
+  runs on `@node-rs/argon2` `2.2.2`, a new exact optional peer, loaded only when `crypto.argon2` is missing; without
+  it, `createAccess` refuses with `ACCESS_OPTIONS_INVALID`. Both write the same PHC strings.
+- Hashes are PHC strings (`$argon2id$v=19$m=…,t=…,p=…$salt$hash`), checked at the parameters they name with a
+  constant-time compare, so a later profile change keeps every older hash verifying. A stored hash that costs more
+  than the largest profile is refused without being computed. A malformed or tampered hash, or a failure inside the
+  computation, fails the check instead of throwing, and is logged through Better Auth's logger. A password over Better
+  Auth's `maxPasswordLength` is never hashed (`PASSWORD_TOO_LONG`).
+- Better Auth's scrypt hashes fail the check unless `passwords.legacyScrypt` is `true`. With it, they verify through
+  Better Auth's own `verifyPassword`, and a sign-in that matches one stores the password again with argon2id. Every
+  check costs the same whatever an account holds: one argon2id computation, and with `legacyScrypt` one scrypt too.
+- A sign-in whose password matches a hash stored at other parameters than the `passwords` profile's (an older profile,
+  cheaper or costlier) stores the password again at the profile, as a scrypt hash moves under `legacyScrypt`: the
+  password is checked against the stored hash again, and the write is a compare-and-set on that hash, so a password
+  changed meanwhile is never overwritten. A hash at the profile costs one read per password sign-in and no write.
+  Kiosk PINs move the same way at the next switch.
+- `aventaraAccess()` takes the same `passwords` and hashes the same way, putting its hook in Better Auth's context when
+  Better Auth starts the plugin; an app's own `emailAndPassword.password` passes through, and setting both is refused.
+- `@aventara/access/auth` exports `AccessPasswordsOptions` and `AccessArgon2idProfile`.
+- The ownership beacon. A namespace reads another namespace's Resources in conditions (`{ foreign: "<owner>" }`)
+  only while both services run on one database, and Access now checks it. Each service writes one row in
+  `_aventara_beacon` (`namespace`, `value`, `createdAt`), a random `avb_…` value written once, through its own data
+  layer: Access takes an `AccessBeaconStore` (`read`, `create`) and writes no SQL.
+- `avaccess push <rules> --beacon <module>` sends the namespace's own beacon with its file, and the beacon of each
+  namespace the file reads, as this service's connection reads it. The registry keeps only hashes bound to their
+  namespace (`sha256` of `<namespace>:<value>`, a new `accessBeacon` table that keeps each namespace's past ones), and
+  stores a file that reads another namespace only when the push carries that namespace's beacon as pushed: otherwise
+  `ACCESS_FOREIGN_CROSS_DATABASE` (`403`), which suggests a JWT claim instead. Only a namespace's own push registers
+  or replaces its beacon; one it replaced never comes back (`ACCESS_BEACON_MISMATCH`, `409`). A push never adopts a
+  row in `_aventara_beacon` it did not write and the registry does not hold: it is refused until an operator
+  verifies or deletes it. The push body may be the file, or `{ file, beacons }`; a namespace's info
+  (`GET /access/v1/namespaces/:ns`) carries its beacon's hash.
+- `avaccess pull --foreign <owner>:<Resource>,… --beacon <module> --env <environment>` writes the owner's schema
+  entries of those Resources to `access/foreign.json` (format `aventara-access/foreign@1`, pinned in the lock as
+  `foreign`, checked by `verify`), and `avaccess schema` marks them as the owner's in the model it writes. A pull of
+  rules that read another namespace checks that namespace's beacon through `--beacon` and writes nothing on another
+  database. The new registry route `GET /access/v1/namespaces/:ns/foreign/:owner?resources=…` answers only for what
+  the namespace's current file reads as that owner's, refuses everything else with one and the same answer, and logs
+  every read.
+- Beacon pins are per environment: `avaccess pull --env <environment>` (or `AVACCESS_ENV`) writes
+  `avAccess.beacons.<environment>.json` (format `aventara-access/beacons@1`). `avAccess.lock.json` holds no beacon, so
+  one lock still holds against any registry. `avaccess verify [--env]` checks every environment's pins too.
+- An engine whose rules read another namespace, with a lock or without, decides nothing until
+  `await engine.checkBeacons(reader, pins, environment)` (`access.policy.checkBeacons` under `createAccess`) has
+  passed: the pins must be `environment`'s, and each owner's row, read through the service's own connection, must hash
+  to its pin, or every decision throws `ACCESS_BEACON_MISMATCH`. A failed check latches, and checks run one after
+  another. The generated client does the same with `access.checkBeacons(reader, pins, environment)` and throws an
+  error with that `code`; with `--orm prisma7` it adds `access.prismaBeacon(prisma)` (a store over the
+  `AventaraBeacon` Prisma model, `PrismaBeaconClient`). `avaccess schema` leaves that model out of the Resources.
+- With the registry on, an Access server whose rules name a namespace declares the `aventaraBeacon` table through
+  Better Auth's plugin schema and exposes `access.beacon`, its store over Better Auth's adapter. The auth-tables guard
+  keeps every beacon table closed and its `value` sealed: the Access server's, and any Resource named like one.
+- New exports: `AccessBeaconReader`, `AccessBeaconStore`, `AccessBeaconPins`; new codes `ACCESS_FOREIGN_CROSS_DATABASE`
+  and `ACCESS_BEACON_MISMATCH`. `aventara-access/lock@1` takes an optional `foreign` pin.
+
+## 0.1.0-rc.0
+
+The first release candidate: the policy engine, Better Auth with Access beside it (`@aventara/access/auth`), the
+policy registry and the org's guardrails, the audit log, the `avaccess` bin with its generator, and the standalone
+host (`@aventara/access/standalone`) with its container image.
+
+- `definePolicies(model)` writes role-first rules, typed from your app's schema (an Aventara discovery artifact's
+  `model`). Global roles come from the principal's claims; roles held on a row (`on`, `where`) come from your own
+  tables. `.govern()` keeps fields out of every result unless a grant names them. `.grants()` and `.denies()` take the
+  rules: nothing is allowed until a grant allows it, any deny wins, and order never matters.
+- Every name a rule uses (a Resource, field, relation, enum value, role, claim or governed field) is checked against
+  the schema: a misspelled one is a type error at its key.
+- `definePolicies(model, { namespace })` names the namespace that owns the rules' Resources. A Resource marked
+  `{ foreign: "<namespace>" }` in the schema can be read in conditions, and a grant on it is refused.
+- `.contract()` compiles the rules to a policies file in the `aventara-access/policies@1` format: plain JSON with no
+  functions in it. Unknown members are refused, and so are files in the earlier unstable format.
+- The file's parts are exported as types (`AccessGrantRule`, `AccessDenyRule`, `AccessRoleDefinition`,
+  `AccessPredicate` and the rest), so a project that emits declarations can export any part of a file or of an
+  explanation.
+- `policiesHash(file)` returns the file's canonical hash (`"sha256:…"`), the same for the same rules in any order.
+- `.engine()` and `createAccessEngine(file)` return the engine. It fits `@aventara/core`'s `AvPolicyEngine` by shape,
+  so it plugs into the framework's `policy` option or into an `access` provider. It answers `can`, `scopeOf` and
+  `fieldsOf`, and `explain` shows, in development, which rules took part in a decision.
+- The engine (`@aventara/access`) imports nothing at runtime, and the package has no dependency on the
+  framework.
+- A deny on a nullable field lets the NULL rows through in `scopeOf` too, as it does in `can`. A `policies@1` schema
+  entry lists its nullable scalar fields in an optional member, `nullable`, which `.contract()` writes from the schema
+  and the hash reads as a set; a file without it has no nullable field, and an empty list is refused. `scopeOf` writes
+  a negated comparison on one of them as `NOT (f = v) OR f IS NULL`; a field that is not nullable keeps the plain
+  `NOT`. The same holds for `ne`, `in` and `notIn`, for a deny on several fields, under `every`, for guardrail denies,
+  and in the generated client. A to-one relation is nullable when one of its reference fields is, and a negated step
+  on it adds `OR <reference> IS NULL`. The startup `paths` name the operators this adds, so an app that took one away
+  fails at startup; a create-only deny, which no scope negates, names none of them.
+- The package ships `LICENSE-ADDITIONAL-PERMISSION.md` beside `LICENSE`: PolyForm Shield 1.0.0 stays the license, and the
+  additional permission limits its Noncompete section to products that compete with Aventara Access itself.
+- `@aventara/access/auth`: `createAccess({ betterAuth, policies, principal?, profile?, registry?, audit?, resources? })`
+  builds Better Auth with Access beside it. Its options, its instance and its blocks' types are exported from
+  `/auth` too; `@aventara/access` holds the engine alone, so nothing it declares names `better-auth`, and an
+  engine-only project type-checks without it with `skipLibCheck: false`.
+  `betterAuth` takes Better Auth's own options, exactly as `betterAuth({...})` takes them, and passes them through
+  unchanged; Access installs Better Auth's `jwt()` plugin and its own. The instance mounts nothing: mount
+  `access.handler` where you would mount Better Auth's handler. `access.api` is Better Auth's server API and
+  `access.options` the options Better Auth runs with (what `npx auth generate` reads).
+- `policies.claims` declares the token's claims by type (`{ role: "string" }`). A token carries `sub` and the declared
+  claims only, read from the user's fields of the same name or from `policies.claimsOf`. A claim the rules read and
+  the declaration lacks is refused at construction, and is a type error when the rules are typed.
+- The instance fits `@aventara/core`'s `AvAccessProvider` by shape: `createFramework({ ...config, access })` takes it
+  with no `policy` and no `state`. Its `state` verifies a bearer token against Better Auth's key set (read again every
+  5 minutes), or reads the session cookie from Better Auth's store, and gives `me`: the identity `{ sub, claims }`, or
+  what `principal` maps it to. A token with an undeclared claim is refused.
+- `profile: { kind: "service" }` hands no caller a new session, and reads `me` from bearer tokens only.
+  `{ kind: "web" }` is the default.
+- `better-auth` is an optional peer, pinned to one exact version, and loaded only when `createAccess` runs: the engine
+  works without it. Another version is refused at construction (`ACCESS_BETTER_AUTH_VERSION`).
+- Refusals are `AccessError`s with a `code`: `ACCESS_BETTER_AUTH_VERSION`, `ACCESS_CLAIMS_UNDECLARED`,
+  `ACCESS_PLUGIN_DUPLICATE` (a plugin `createAccess` installs itself, also a type error at that plugin),
+  `ACCESS_OPTIONS_INVALID`, and the registry's (below).
+- Depends on `jose` for token verification.
+- Access's routes mount the way Better Auth's do, with Better Auth's own helpers: in Next.js, the route file
+  `app/api/auth/[...all]/route.ts` holds `export const { GET, POST } = toNextJsHandler(access)`
+  (`better-auth/next-js`); in Node.js, Express or NestJS, `toNodeHandler(access)` (`better-auth/node`) is mounted
+  before the body parser. In NestJS that is `app.use()` between `NestFactory.create()` and `listen()`, with a path
+  test, `request.url?.startsWith("/api/auth/") ? handler(request, response) : next()`, which works on Express and
+  Fastify alike (on Fastify, `app.use("/api/auth", …)` hands Better Auth the URL without its base path). The
+  framework's hosts mount no Access route.
+- `@aventara/access/standalone`: `serve(access, { port, hostname, maxBodyBytes })` runs Access as its own HTTP server
+  around the same handler, with `GET /health` answering `200 {"status":"ok"}`. `port` defaults to `3000`, and `0`
+  picks a free one; `hostname` defaults to `127.0.0.1`. It resolves to `{ port, url, close() }` once the server
+  listens.
+- `createAccess` loads `better-auth` through the package's own `#better-auth.require` import: Node.js's `require` under
+  the `node` condition, which a bundler building for Node.js also reads, so a Next.js server bundle (Turbopack or
+  webpack) and its standalone output carry Better Auth. Under any other condition (a browser, an edge runtime) it names
+  no Node.js API, so the engine bundles there too.
+- Requires Node.js `^22.23.4 || >=24.22.1`, the Node.js security releases of 2026-10-20 (CVE-2026-105481,
+  CVE-2026-105482, CVE-2026-105483, CVE-2026-106069, CVE-2026-106072, CVE-2026-106073, CVE-2026-106074,
+  CVE-2026-111497).
+- The policy registry: `registry: { enabled: true }`. Its tables (`accessNamespace`, `accessKey`,
+  `accessPolicyRevision`, `accessGuardrailRevision`, `accessHead`, `accessPushLog`, `accessResourceOwner`) are Better
+  Auth plugin tables:
+  Better Auth's own migration, or `npx auth generate` for an ORM's schema, creates them beside Better Auth's, and they
+  are stored through whatever database adapter `betterAuth.database` names. `access.handler` serves its routes under
+  Better Auth's base path, so every mount carries them: `GET /access/v1/namespaces/:ns`, `…/revisions`,
+  `…/revisions/:hash`, `…/head`, `…/guardrails`, and `POST …/revisions` to push. One org per server.
+- `access.registry` is the operator's API: `createNamespace(name)` issues the namespace's push key and its read-only
+  pull key (shown in that answer only; the registry keeps their SHA-256 hashes), `rotateKey(namespace, kind)`,
+  `revokeKey(namespace, kind)` and `pushGuardrails(file)`; a name that is not a namespace name, or one the registry
+  has already, is refused (`ACCESS_NAMESPACE`). A service sends its key in the `x-access-key` header. A
+  wrong, revoked or rotated-out key, a pull key that pushes, or another namespace's key is refused
+  (`ACCESS_KEY_REFUSED`).
+- A pushed file is stored once, in its canonical form, under its `policiesHash`, and is never updated: pushing a file
+  the registry has moves the namespace's head back to it. A stored revision that no longer hashes to its key is
+  never served (`ACCESS_REVISION_CHANGED`).
+- Ownership at push (`ACCESS_OWNERSHIP`): a namespace's file names as its own only Resources no other namespace owns,
+  and its grants, denies and governed fields name only those. The org's guardrails file holds no grant. A file the
+  engine would refuse is refused too (`ACCESS_POLICIES_INVALID`).
+- `registry: { enabled: false }` stays the default: no registry table, and `/access/v1/*` answers `404`.
+- The org's guardrails: `defineGuardrails({ claims })` writes deny-only rules that central Access adds on top of
+  every namespace's own. The builder has `.denies()` and no `.grants()`, its callback hands out `deny` alone, and a
+  guardrail's options are a `name` and `if: { claims, origin }`: a `grant` in it, or a row condition (`where`,
+  `after`), is a type error. `deny(actions, resources, options?)` names whole Resources: `"*"`, or by namespace,
+  `{ campaign: ["Note"] }` or `{ chat: "*" }`. `.contract()` compiles them to an `aventara-access/guardrails@1` file
+  (`format`, the `claims` they compare, `denies`), passive JSON hashed like a policies file: `guardrailsHash(file)`
+  is the same for the same guardrails in any order. A member the format does not define is refused with a sentence
+  (`grants` and a guardrail's `where` by name), and so is a file of another format.
+- An engine applies pulled guardrails and only narrows: `rules.engine({ guardrails })`,
+  `createAccessEngine(file, { guardrails })`, and in `createAccess`, `policies.guardrails`. Each guardrail becomes a
+  deny on the Resources it reaches: every one for `"*"`, and the file's own namespace's list; another namespace's
+  list is left alone. A Resource in the file's own list that the file lacks, or reads as another namespace's, is
+  refused, and so is a namespaced list when the file names no namespace. The governed fields, the paths and the
+  engine's type are the file's own. `createAccess` refuses guardrails that compare a claim `policies.claims` does not
+  declare (`ACCESS_CLAIMS_UNDECLARED`), and `policies` refuses a member it does not take.
+- `policies.tokenTtl`: how long a token lives, in whole seconds from 300 to 900 (5 to 15 minutes); 900 by default.
+  A claim that must take effect soon (`banned`, `suspended`) reaches every service with the user's next token.
+- The registry's `pushGuardrails(file)` takes the `guardrails@1` file. A `policies@1` file is refused by its format
+  (`ACCESS_POLICIES_INVALID`), a `grants` member or a guardrail with `subjects` by ownership (`ACCESS_OWNERSHIP`),
+  and a guardrail naming a namespace the registry does not have by `ACCESS_NAMESPACE`. `…/guardrails` serves the
+  file with its `guardrailsHash`. Guardrails are pushed through `access.registry` only: no namespace key can push
+  them.
+- A deny or a governed field on a `foreign` Resource is refused, by the types, the compiler and the registry: only
+  the owner narrows its Resources; another namespace's are narrowed by the org's guardrails.
+- The `avaccess` bin, the registry from a project. It keeps nothing of its own: every answer is the registry's, over
+  its HTTP routes. The registry is `--registry <url>` or `AVACCESS_REGISTRY_URL` (the Access server's URL; with no
+  path, Better Auth's `/api/auth` is added, as Better Auth's client does), and the key is `AVACCESS_KEY`, never a
+  flag. Exit codes: `0` done, `1` the check failed or the registry refused, `2` the command could not run.
+  - `avaccess push <rules>` pushes the namespace's policies file: a `.json` file, or the module that holds the rules
+    (`definePolicies(model, { namespace })…` or its `.contract()`, as the default export or `rules`), loaded with
+    jiti as written, TypeScript included. The namespace is the file's own.
+  - `avaccess pull [--namespace <ns>] [--out <dir>]` writes the namespace's current file and the org's guardrails
+    into the project (`access/<ns>.policies.json`, `access/guardrails.json`) and pins both hashes in
+    `avAccess.lock.json`: `{ format: "aventara-access/lock@1", namespace, policies: { path, hash }, guardrails:
+    { path, hash } | null }`. Commit all three. The lock pins content, not a registry. A file the registry serves is
+    hashed again before it is written.
+  - `avaccess verify` holds the pulled files to the lock, offline: no registry, no network. A file edited by hand
+    fails it with exit 1 and `ACCESS_LOCK_MISMATCH`, naming the file and both hashes. Put it first in the project's
+    `aventara:prepare` script, so the build stops before anything is generated from a changed file:
+    `"aventara:prepare": "avaccess verify && aventara-prisma7-generate … && aventara-build"` (in a Next.js app, before
+    `aventara-build` the same way).
+  - `avaccess status` says, for the namespace's file and the org's guardrails, whether the lock holds the registry's
+    current revision, and exits 1 when either is behind: run it in CI.
+  - `avaccess diff [<from> [<to>]]` names the rules that changed between two revisions (each grant and deny by its id,
+    roles, governed fields, schema entries and claims). A revision is `lock`, `head`, a hash or its first seven or
+    more hex digits; the default, `lock` to `head`, is what a pull would bring.
+  - `avaccess keys issue <ns>`, `keys rotate <ns> <push|pull>` and `keys revoke <ns> <push|pull>`, with
+    `--server <module>`: the operator's API, run in the operator's own process from the Access server's module (its
+    `createAccess({ …, registry: { enabled: true } })` instance, as the default export or `access`), never over HTTP.
+    A key is printed once, by the command that issues it, and by no other command.
+  - `avaccess generate [--orm <orm>] [--out <file>] [--tsconfig <file>]` writes the generated client of a service that does not run on
+    Aventara: two TypeScript files (default `src/generated/avAccess.ts`, and `avAccess.internal.ts` beside it; a
+    custom `--out <name>.ts` writes `<name>.internal.ts`) from the pulled files the lock pins,
+    after the same check `avaccess verify` runs (a file edited by hand is refused, exit 1, and nothing is written).
+    It holds the pulled policies file as a constant and the denies the org's guardrails add to it, a copy of Access's
+    decisions, the namespace's Resource types (`ResourceName`, `ResourceRows`, `ResourceFields`), and `access`:
+    `can`, `scopeOf` and `fieldsOf`, which answer as the engine does, in Aventara's `where`. `--orm` is optional and
+    defaults to `none` (that neutral client, naming no ORM; its banner spells `--orm none` out); `--orm prisma7`
+    adds the Prisma 7 translator's `prismaWhere(resource, scope)` (a scope as a Prisma `where`; `false` matches no row),
+    `readable(question)` (the fields a read shows on every row, as a Prisma `select`; a governed field opened on some
+    rows only is left out, and no relation is selected) and `prismaExists(prisma, resource, where)` (`can`'s `exists`
+    through the service's Prisma client). `avAccess.ts` exports `access` and the client's types only (`ResourceName`,
+    `ResourceRows`, `ResourceFields`, `QuestionOf`, `CanQuestionOf`, `ScopeQuestionOf`, `FieldsQuestionOf`,
+    `PrismaClientOf`, `PrismaSelectOf`, `PrismaWhere`, the last three with `--orm prisma7` only); the copied
+    decisions stay in `avAccess.internal.ts`, which it imports with the extension the project's `tsconfig.json`
+    asks for, by Prisma 7's `prisma-client` rules (`.js`, none, or `.ts`). The tsconfig is the nearest one above the
+    generated file (a solution-style root's referenced project that includes it), or the one `--tsconfig` names; a
+    project with none, or one that cannot be read, is refused (exit 2) and nothing is written, as the framework's
+    `avclient` refuses a JavaScript project. Neither imports
+    anything else: no `@aventara` package and no Prisma module, so the service needs no Access version at runtime. The same pulled files, translator and Access version give the
+    same bytes. Regenerate after each pull, for example in the project's `postinstall`:
+    `"avaccess verify && avaccess generate --orm prisma7"`. The scope covers only the queries it is passed to; a
+    Prisma `include` is not scoped.
+  - `avaccess schema --orm prisma7 [--schema <path>] [--out <file>]` reads the service's Prisma schema (default
+    `prisma/schema.prisma`; a folder of `.prisma` files reads as one) into the `AccessSchema` its rules are authored
+    against, written as a module (default `src/generated/avAccess.schema.ts`) exporting `model`:
+    `definePolicies(model, { namespace })`, as an Aventara app does with its discovered model. It reads the same
+    facts the framework's Prisma 7 discovery reads (fields, enums, relations with their reference pairs and inverse,
+    identifiers in order) and leaves out, and lists, what it cannot model: an `Unsupported(...)` column, a composite
+    `type`, a `view`, an `@ignore`d field or model.
+  - `--orm` names the translator, `<orm><major>`: required by `schema` (`prisma7` is the first), optional for
+    `generate` (default `none`). Drizzle follows once Drizzle ORM v1 is stable.
+  - `avaccess serve [--config <file>] [--port <port>] [--hostname <host>] [--max-body-bytes <bytes>] [--migrate]` runs
+    the standalone host, on `127.0.0.1` unless `--hostname` says otherwise, from
+    a configuration file: `access.config.ts` in the working directory (or `.mts`, `.cts`, `.js`, `.mjs`, `.cjs`), or
+    the file `--config` names, loaded with jiti the way `prisma.config.ts` is, so it needs no build step. Its default
+    export (or its `access` export) is the `createAccess({...})` instance; `serve()` serves it, with `GET /health`,
+    until SIGTERM or SIGINT, when it closes the server and exits 0. The port is `--port`, else `PORT`, else `3000`.
+    Better Auth's migration (the one `npx auth migrate` runs) runs on start only with `--migrate` or
+    `AVACCESS_MIGRATE=true` (`1` also; `false`, `0` or unset do not). Without it, a database Better Auth migrates
+    itself (a `pg` Pool, a MySQL pool, SQLite) is checked before the server listens: one that lacks a table, column
+    or index the options need is refused with exit 1 and the list of what it lacks. A database behind an ORM's
+    adapter (Prisma, Drizzle) is the ORM's to migrate (`npx auth generate`, then its migration): it is served as it
+    is, and `--migrate` refuses it with exit 2.
+- The container image of the standalone host, `aventara/access-server:<version>`, built from the package's tarball
+  (`docker/access-server/Dockerfile`; the build context holds the Dockerfile, its two scripts, its `package.json` and
+  `package-lock.json`, and the tarball, nothing else). It holds `@aventara/access` and the Better Auth version the
+  package pins, under `/srv/node_modules`, every package installed by `npm ci` from the lockfile with no install
+  script run, on Node.js 24, and runs `avaccess serve --hostname 0.0.0.0` as user `node` in `/srv/access`; arguments
+  after the image name go to `avaccess serve`. The operator mounts `access.config.ts` into `/srv/access`, read-only:
+  its default export is the `createAccess({...})` instance, and it reads its secrets from the environment
+  (`process.env.DATABASE_URL` and the like), passed with `docker run -e`. What the configuration imports beyond Access
+  and Better Auth (the database driver, a Better Auth plugin in its own package) is installed at build time, in an
+  image built `FROM` this one that copies the operator's `package.json` and `package-lock.json` into `/srv/access` and
+  runs `/srv/bin/access-deps` (`npm ci`, no install script, no peers: a plugin's `better-auth` peer is the image's).
+  A file that names `@aventara/access` or `better-auth` is refused, since the image provides them, and so is one
+  without its lockfile. Nothing is installed at start.
+
+  ```bash
+  docker run -p 3000:3000 \
+    -v ./access.config.ts:/srv/access/access.config.ts:ro \
+    -e DATABASE_URL=postgresql://... -e BETTER_AUTH_SECRET=... \
+    aventara/access-server:<version> --migrate
+  ```
+
+  `PORT` (default `3000`) sets the port, and the image's health check calls `GET /health` on it. `docker stop` drains
+  and ends it cleanly. Pass `--migrate` (or `-e AVACCESS_MIGRATE=true`) on the start that should create or update the
+  tables; without it, an empty database stops the container with exit 1 and the list of what is missing. Nothing
+  pushes the image to a registry yet.
+- `avAccess.lock.json` at start: `createAccessEngine(file, { guardrails, lock })`, `rules.engine({ guardrails, lock })`
+  and `createAccess({ policies: { …, lock } })` refuse to start (`ACCESS_LOCK_MISMATCH`) unless the guardrails hash to
+  the lock's pin and are given exactly when it pins some, and a policies file handed over (not the typed rules, which
+  are the project's own source) hashes to its own; the rules' namespace must be the lock's. Read the lock and the
+  pulled files as JSON; `AccessLock` (and `AccessLockPin`) types the lock with `format` as a string, so an imported
+  JSON file fits it.
+- Depends on `jiti`, which the bin loads only to read a project's modules, and on `get-tsconfig` (pinned exactly,
+  the version Prisma 7 and the framework's `avclient` read tsconfigs with), which `avaccess generate` loads only to
+  read the project's tsconfig.
+- The audit log: `audit: true` or `audit: { sink }` (off by default). Each event is an `AccessAuditEvent`:
+  `{ at, kind: "sign-in", userId, origin, impersonatedBy? }`,
+  `{ at, kind: "sign-in-failed", userId: null, route, reason, target?, origin, suppressed?, windowStart?, windowEnd? }`,
+  `{ at, kind: "sign-out", userId, origin, impersonatedBy? }`, `{ at, kind: "token", userId, origin, impersonatedBy? }`
+  or `{ at, kind: "decision", userId, resource, action, allowed, reason, origin, suppressed?, windowStart?,
+  windowEnd? }`.
+  - `audit: true` writes each event to the `accessAudit` table, a Better Auth plugin table: `npx auth generate` writes
+    it into an ORM's schema (Prisma: `model AccessAudit`) and `npx auth migrate` creates it, beside Better Auth's
+    tables, through the app's own Better Auth adapter. Better Auth refuses to start while the table is missing.
+  - `audit: { sink }` hands each event to the app's function instead, and the table is not declared at all.
+  - A sign-in is a session Better Auth created: a sign-in, or a sign-up that signs the user in. Its `origin` is
+    `client` through Access's routes and `application` when the server calls Better Auth's API itself.
+  - A decision is a `can` answer: a request's admission (may this caller ever do this action on this Resource?) is
+    one event, allowed or refused, however many rows the request reads or writes; a row question (the row a create
+    inserts, or an update leaves) adds an event only when the rules refuse that row. `scopeOf`, `fieldsOf` and
+    `explain` log nothing. `reason` names the deciding rule: `grant:<id>`, `deny:<id>`, or `no grant`. `userId` is
+    the `sub` of the token or session the principal came from, `null` for an anonymous caller.
+  - An event holds no token, password, cookie, key or header.
+  - The request waits for the write or the sink. A sink that throws, or a write that fails, does not fail the
+    request: Better Auth's logger warns and the request goes on.
+- Better Auth's tables as Resources of the app's rules: `resources: { users?: boolean, members?: boolean }`
+  (type `AccessResourcesOptions`). The engine runs built-in rules over every Better Auth table in the rules' schema
+  (its plugins' and Access's own included, matched by the model name Better Auth's generator writes, the app's
+  `modelName` and `fieldName` honoured). They only narrow:
+  - `users: true` opens `user`, `session` and `account`, `members: true` the organization plugin's `member` and its
+    `organization` (read only). An opened table is read as the rules grant. Every other table of Better Auth's
+    (`verification`, `jwks`, the organization plugin's `invitation`, `twoFactor`, `deviceCode`, Access's own) stays
+    closed: every action is denied, and a key that is off leaves its tables closed too.
+  - A write through Aventara skips Better Auth's hooks, its cookie cache and its secondary storage, so it is limited
+    to what those do not guard: on `user`, an update of `role`; on `member`, a create (the membership's fields), an
+    update of `role`, and a delete. Nothing else is written.
+  - Secret columns are never in an answer, whatever a grant says, so a request that selects, filters or sorts by one
+    is refused: `account.password`, `accessToken`, `refreshToken`, `idToken`; `session.token`; `verification.identifier`
+    and `value`; `jwks.privateKey`; `twoFactor.secret` and `backupCodes`; `deviceCode.deviceCode` and `userCode`;
+    `accessKey.keyHash`. Exempt them from your Contracts too, or govern them, so a read that names no field leaves
+    them out instead of being refused.
+  - Checked at startup, the first read of `access.policy` (the framework's construction): a key whose tables Better
+    Auth lacks (`members` without `organization()`), or that the rules' schema lacks (run `npx auth generate`, then
+    regenerate the model), is refused (`ACCESS_RESOURCE_MISSING`); so is a grant on a closed table, or a grant of a
+    write the table never takes (`ACCESS_OPTIONS_INVALID`). The instance itself still builds, so `npx auth generate`
+    loads the configuration before the schema has the tables.
+  - `explain` and the audit log name a built-in deny `better-auth:<Resource>` (a closed table) or
+    `better-auth:<Resource>/<actions>` (the writes an opened one never takes).
+- `access.policy` is built on its first read and, like `access.api`, is not enumerable.
+- Type the rules with the principal `createAccess` hands them: `definePolicies(model).principal<AccessIdentity<typeof
+  claims>>()`, where `claims` is the object you pass as `policies.claims` (declared `as const`). Without
+  `.principal<…>()` the rules have no principal type, so `me.sub` in a `where` and `claims` in a role are type errors.
+  With it, `createAccess` checks that every claim the rules read is declared in `policies.claims`, and `principal` is
+  optional, since `me` is then the verified identity `{ sub, claims }` itself. Rules typed with your own profile type
+  instead (`.principal<Profile>()`) make `principal` required: it maps the identity to that profile.
+
+  ```ts
+  // src/access/rules.ts
+  import { type AccessIdentity, definePolicies } from "@aventara/access";
+  import { model } from "../aventara/generated/discovery.artifact";
+
+  export const claims = { role: "string", suspended: "boolean" } as const;
+
+  export const rules = definePolicies(model, { namespace: "blog" })
+    .principal<AccessIdentity<typeof claims>>()
+    .grants(({ grant, me }) => [
+      grant("signedIn", "create", "Post", { where: { authorId: me.sub } }),
+    ]);
+  ```
+- Install Better Auth at the exact version Access is built against, so a later `npm install` cannot move it:
+  `npm i better-auth@1.7.12 --save-exact`. Another version is refused at construction (`ACCESS_BETTER_AUTH_VERSION`).
+- Hand the instance to the framework where your host takes its configuration:
+  - Next.js (`@aventara/next`): add `access` to the configuration in `src/aventara/config.ts`, which `server.ts`
+    spreads into `Aventara({ ...aventaraConfig, adapter, prebuilt })`. In `config.ts` it is what `aventara-build`
+    compiles the prebuilt Contracts with; given only in `server.ts`, the prebuilt Contracts no longer match, and the
+    framework warns `AVENTARA_PREBUILT_STALE` and compiles them at startup. `aventara-build` runs `config.ts` at build
+    time, so the module that calls `createAccess` must load there: with Prisma, the build's environment needs the
+    `DATABASE_URL` your database client reads (`aventara-build` does not read `.env`), or build the client lazily.
+
+    ```ts
+    // src/aventara/config.ts
+    import { access } from "../access/access";
+
+    export const aventaraConfig = {
+      api: "/api",
+      access,
+      // exposed, resources, diagnostics … as the scaffold wrote them
+    } as const;
+    ```
+  - NestJS (`@aventara/nest`): add `access` to the `config` your `AventaraModule.forRootAsync` factory returns, and
+    mount `access.handler` in `main.ts` with `toNodeHandler(access)`, as above.
+
+    ```ts
+    AventaraModule.forRootAsync({
+      imports: [PrismaModule],
+      inject: [PrismaService],
+      useFactory: async (prisma: PrismaService) => ({
+        config: {
+          ...aventaraConfig,
+          access,
+          adapter: await createPrismaAdapter({ ...adapter, client: prisma }),
+        },
+      }),
+    });
+    ```
+  - Anywhere else: `createFramework({ ...config, access })`.
+- The audit log's decision `userId` is set under Next.js too. Next evaluates the app's `access.ts` once per bundle, so
+  one process holds several Access instances, and `@aventara/next` shares one framework (with one bundle's
+  `access.policy`) across them, while a route's `state` comes from its own bundle's instance. The `sub` now travels on
+  the principal `state` returns (under a non-enumerable `Symbol.for` key: a spread, `JSON.stringify` or `Object.keys`
+  of `me` does not show it), so any instance's engine reads it. Each instance also keeps its own copy of Better Auth's
+  key set, read once from your database on its first token; that is expected under Next.js and costs one read per
+  bundle.
+- A pulled file imported as JSON fits as it is: `import guardrails from "../access/guardrails.json"` and a pulled
+  policies file go straight into `policies.guardrails` and `policies.rules` (and `createAccessEngine(file, {
+  guardrails })`), with no `as unknown as`. TypeScript widens a JSON import's literals, so these options take the
+  file's outline (`AccessGuardrailsJson`, `AccessPoliciesJson`) and the engine checks the rest when it is built, as
+  it checks a typed file. A policies file passed as guardrails is still a type error. `defineGuardrails(…).contract()`
+  and `.contract()` still return the strict `AccessGuardrails` and `AccessPolicies`.
+- A registry-only server leaves `policies` out: `createAccess({ betterAuth, registry: { enabled: true } })`. It has
+  no rules of its own, so its engine denies every question and its tokens carry `sub` alone. Every other instance
+  needs `policies`; leaving it out is a type error and is refused with a sentence that says what to pass.
+- `grant(…, { fields: ["Note.body"] })` on a Resource with no governed field is a type error that says what to do:
+  `no field of "Note" is governed; govern it first, .govern("Note", [<field>]), and a grant can then open it`.
+- `ACCESS_PLUGIN_DUPLICATE` and its type error name the Access plugin by what it is (plugin id `aventara-access`), not
+  by a factory this release does not export.
+- `createAccess` without `betterAuth` says the option is missing.
+- `avaccess pull` with no lock and no `--namespace` pulls the namespace the key belongs to. The registry names it at
+  `GET /access/v1/key` (with the key in `x-access-key`: `{ namespace, kind }`).
+- `fieldsOf` refuses a question it cannot answer as asked, with `ACCESS_QUESTION_INVALID`: one without
+  `access: "read"` or `access: "write"`, a read with an `action`, or a write whose `action` is not `create` or
+  `update`. Such a question was answered as a read, or with no field.
+- The README starts from `npx @aventara/cli@1.0.0-rc.9 new <app> --orm prisma7 --db postgresql`, and pins Better
+  Auth's CLI as `npx auth@1.7.12`. It shows the scaffold's `Int` user id kept with Better Auth's own
+  `advanced.database.generateId: "serial"` (and the principal's `id: Number(sub)`), sign-up and sign-in with `curl`
+  and the `Origin` header Better Auth requires, reading the audit log through the app's ORM, the `fieldsOf` question's
+  shape, that `avaccess pull` writes `access/guardrails.json` only when the registry has guardrails, and the
+  environment `avaccess keys` needs (`BETTER_AUTH_URL` with the rest).
+- Identity, tokens and sessions, hardened after the identity audit:
+  - Better Auth's tables are recognized under `usePlural` names (`Users`, `Accounts`, `Jwkss`) and hand-written ones,
+    where they were left open to every grant (see below for how).
+  - A declared claim read by the default mapping from a user field without `input: false` (one the user sets at
+    sign-up or with `/update-user`, a plugin's field included) is refused at construction (`ACCESS_OPTIONS_INVALID`).
+    A user could make themselves `role: "admin"`.
+  - The service profile matches the routes that start a session by Better Auth's endpoint path, whatever the URL's
+    spelling, `basePath` or `baseURL` (a `baseURL` with a path, `basePath: "/"`, a trailing slash let sign-up
+    through), covers the plugins' sign-in routes (`/phone-number/verify` signed a caller in), and answers `404` to any
+    request that creates a session anyway, revoking it before a cookie or token leaves.
+  - `state` reads the session cookie from Better Auth's store, never its cookie cache, so a revoked session is gone at
+    once; with `session.cookieCache` on, a token is issued only for a session the store still has.
+  - The key set is read again every 5 minutes (the last good set kept when a read fails), so a key removed from it
+    stops verifying within 5 minutes, not only when a token with an unknown key arrives.
+  - Tokens carry, and are verified against, one fixed issuer and audience: the origin of the base URL (`baseURL`,
+    `BETTER_AUTH_URL`, or a dynamic `baseURL`'s `fallback`). With none, `createAccess` refuses; an unset base URL left
+    tokens unchecked for issuer and audience. An audience list that merely includes it is refused.
+  - A token must carry `iat`, be no older than `tokenTtl` and not issued in the future (5 seconds of skew allowed).
+  - The audit log records refused sign-ins (route and reason, nothing the caller sent), sign-outs, issued tokens and
+    the admin behind an impersonated session (`impersonatedBy`). Anonymous refusals are logged once a minute per origin
+    and reason, with the repeats counted in `suppressed`. The `accessAudit` table gains `route`, `impersonatedBy` and
+    `suppressed`: run `npx auth@1.7.12 generate` (or `migrate`) again.
+  - A claim refused for its type names the type it got (`an object`), never its value.
+  - `ACCESS_PLUGIN_DUPLICATE` also refuses `jwt()` or the Access plugin under another case or spacing of its id, and a
+    plugin that defines one of `jwt()`'s endpoints (`getJwks`, `getToken`, `signJWT`, `verifyJWT`, `/jwks`, `/token`).
+  - Any `Authorization` header means `state` reads no session cookie: a header that is not a valid bearer token gives
+    `me: null` instead of the cookie's user.
+  - A `principal` that returns one object for two users is refused (`ACCESS_OPTIONS_INVALID`), so the audit cannot name
+    the wrong user.
+  - A session cookie set to `sameSite: "none"` is refused unless `trustedOrigins` is set; with it, `state` reads the
+    cookie only from a trusted `Origin` (or a request the browser does not mark cross-site).
+  - The README states what is not revoked: a bearer token outlives a sign-out or a deleted user for at most
+    `tokenTtl`. It also states the cookie's `SameSite=Lax` stance.
+- Hardened again after the re-audit of the identity fixes:
+  - Which Resource is which of Better Auth's tables is known, not guessed. On Better Auth's Prisma adapter, it is the
+    model the adapter reads (exact: a lowercase or plural model is found too). On any other adapter, the app names each
+    table in `resources.authTables` (a Resource, or `null`), required when the rules have a schema; without it,
+    `createAccess` refuses (`ACCESS_OPTIONS_INVALID`). Better Auth's tables under `@@map`'d names, and secret columns
+    under `@map`'d names, were left open to every grant. The map is held to the schema: a table's Resource must have
+    every column of it under Better Auth's `fieldName`, and a table mapped to `null` (not in this schema) must not
+    match an unnamed Resource column for column, nor have its secret column there beside another of its columns. On Prisma's adapter, a schema that differs from the adapter only in
+    case or plural is refused. An opened table whose secret column is not found under Better Auth's field name is
+    refused. The guesses by name (singular and plural, case, look-alike columns) are gone.
+  - The audit log's repeat window hides nothing: the count of an anonymous refusal's repeats is logged as a summary
+    (`suppressed`, `windowStart`, `windowEnd`) when the minute closes, on the next event of any kind or by a timer,
+    not on the next repeat. A refused sign-in carries `target`, an HMAC of the identifier keyed by Better Auth's
+    secret, of the identifier the route reads (the email, username or phone number its sign-in route looks up,
+    normalized as it is), and is counted per target; a sign-in logs its target's count first, so a guessed password
+    follows its failures. At most 10,000 windows stay open; past that, the oldest closes early, so every target keeps
+    its own rows.
+    The `accessAudit` table gains `target`, `windowStart` and `windowEnd`.
+  - `token` events are logged for `GET /token` only, not for `/get-session`'s `set-auth-jwt` header.
+  - The service profile refuses the session row itself (Better Auth's `session.create` before-hook) on a request
+    through the handler, so no session exists even while a route runs; answers `404` to a response that sets the
+    session cookie of an existing session; and `access.handler` strips any session cookie (a `multiSession()` one
+    too) from what Better Auth answers, after every plugin's `onResponse`, a route's own `Response` included.
+  - On a request that may change something, a session cookie counts only from a trusted `Origin`, or a
+    `Sec-Fetch-Site` of `same-origin` or `none`, whatever `sameSite` is (the method the client sent, Express's
+    `originalMethod` before a method override). A request with neither header is still read.
+  - The README warns that `claimsOf` is not checked for fields a user can set, and that apps sharing an origin and a
+    database accept each other's tokens.
+
+### Engine security fixes (audit of 2026-10-23)
+
+- An update is checked on the row it leaves by default. That row must still meet the `where` and the `after` of one
+  update grant, and no update deny may match it, whether or not a grant has an `after`. A grant
+  `where: { authorId: me.id }` no longer lets the author hand the row to someone else. `afterChecks` now lists every
+  Resource whose update grants read the row (a `where`, an `after`, a role held on a row) or whose update denies have
+  a `where`, so Aventara asks `can` about each changed row there, and refuses those updates where it has no
+  interactive transaction. `can({ action: "update", row })` (a generated client's too) evaluates the update grants
+  and denies on the row; it no longer answers `true` on a Resource without an `after` grant.
+- A deny that reads a `me` value the principal lacks matches, whatever `not` or `NOT` surrounds it. A deny's `if` that
+  compares a claim the principal lacks holds, except a comparison with `true`: `banned: true` leaves alone a token with
+  no `banned`, and `verified: false` denies a token with no `verified`. Grants are unchanged: a missing value or claim
+  matches no grant.
+- `can` compares by the field's type: a decimal by value (a decimal object, a string and a number alike), a datetime
+  by instant, a bigint exactly. A row value of another type is unknown: no grant matches it, and a deny matches. A
+  `policies@1` schema entry gains an optional member, `types`, which `.contract()` writes for its `bigint`,
+  `datetime` and `decimal` fields; a rule's literal is written in its field's canonical form (`toISOString()`, a
+  decimal without exponent or extra zeros, a bigint past a safe integer as its digits).
+- Only a plain object is an operator object: a `Date` literal compiles to its instant (it compiled to `true`), and
+  another object, or `{}`, is refused.
+- The engine checks every member of a policies file it is handed, as strictly as the guardrails checker: the members
+  of each rule and condition, the comparison (`eq`, `ne`, `in`, `notIn`), a list for `in` and `notIn` only (a string
+  is refused), finite literals in their field's form, a claim path of one declared claim, and a non-empty `and`.
+  `NaN` and `Infinity` are refused in policies and guardrails files, and the canonical writer throws on them, so no
+  two files share a hash.
+- A global role with no claim (`{ global: { claims: {} } }`), which every principal held, is refused.
+- `write.except` naming a relation locks its reference fields, as naming a reference field already locked its
+  relation. `.govern()` naming a relation without its reference fields, or the reverse, is refused.
+- A grant on `"*"` reaches only the file's own Resources: never one its schema does not list.
+- The engine runs from its own frozen copy of the file, taken before the lock check.
+- `requireLock: true` (`policies.requireLock`, or the engine's option) refuses to build without a lock
+  (`ACCESS_LOCK_MISMATCH`). The lock stays optional; set this in production.
+- The principal is any object, an instance of a class included; an array, a function or a primitive is anonymous.
+  An empty-string `me` value counts as missing.
+- `can` never reads a relation carried on the row (`author: { … }`, `tags: [ … ]`): a relation condition is always
+  asked through the row's identifier or reference fields and `exists`. A forged relation object no longer satisfies a
+  create, an update or a read.
+- A datetime literal must read back as written: `2020-02-30`, hour 24 and digits past the millisecond are refused,
+  and such a row value is unknown.
+- The checker refuses a Resource or field name that is no identifier (or is `__proto__`), an identifier, reference
+  field or relation target the schema does not list, a decimal over 1,000 characters, and a deny id that starts with
+  `guardrail:` or `better-auth:`. A translated `where` writes each key as an own member.
+- On an updated row, a to-one step whose reference fields the row carries is asked on the row those values name,
+  as on a created row: a generated client asking before the write no longer reads the database's old reference
+  (moving a row into another tenant was allowed).
+- A generated client compiles when a relation leads to a Resource the file does not list: that relation is typed
+  `unknown`.
+- With `requireLock`, typed rules are held to the lock's policies hash. The engine's `afterChecks` and `paths` are
+  frozen.
+- Through Aventara, a rule comparing a `datetime`, `decimal` or `bigint` field still answers `A3000` (the framework
+  validates a policy's `where` against typed values); it fails closed until the framework's seam changes.
+- Every lookup of a name from a file, a row or a principal reads own members only: `constructor` names no Resource,
+  and an inherited claim is no claim.
+- A generated client's `fieldsOf` refuses a malformed question, as the engine does.
+- The README states that string comparisons in `can` are exact, so a case- or accent-insensitive collation can make
+  `scopeOf` and `can` disagree, and that a `where` matching no row is `{ OR: [] }`.
+
+### Registry, CLI and host security fixes (audit of 2026-10-23)
+
+- The CLI follows no redirect (`redirect: "manual"`): a `3xx` from the registry stops it with exit 2, and the key and a
+  pushed file are sent to no other address.
+- The registry's URL is `https:`; `http:` is refused except on a loopback address (`localhost`, `127.0.0.0/8`,
+  `[::1]`), and so is a URL with a user name or password.
+- `avaccess pull` refuses, writing nothing, a pull that would drop the guardrails the lock pins (the registry serves
+  none), and a file of another namespace than the one asked for. A hash the registry names is checked to be one. A
+  file is held to its hash, not to who wrote it: signed revisions are a follow-up.
+- Ownership is checked and claimed in the push's own transaction, against a new table, `accessResourceOwner`, whose
+  unique Resource name refuses a second claim made at the same moment: two namespaces pushing the same new Resource
+  at once were both accepted.
+- `registry.ownership`: `"first-push"` (the default) or `"assigned"`. The operator's `access.registry.assignResource(
+  resource, namespace)` gives a Resource to a namespace, whoever named it first, and `releaseResource(resource)` takes
+  it back. With `"assigned"`, a push that names an unassigned Resource as its own is refused.
+- `serve()` caps a request body at `maxBodyBytes` (1 MiB by default; `avaccess serve --max-body-bytes`) before any of
+  it is handed on, with `413`, and checks a registry write's key before it reads the body. The registry refuses a
+  policies file over 1 MiB (`ACCESS_POLICIES_INVALID`, `413`) on every mount, and a body it cannot measure (`400`).
+- `serve()` reads the client's address from the socket. A forwarded-for header is kept only from a proxy Better
+  Auth's `advanced.ipAddress.trustedProxies` names, and replaced with the socket's address otherwise, so Better Auth's
+  rate limit counts each client on its own: a spoofed `X-Forwarded-For` bought a fresh bucket, and every client
+  shared one without it. `avaccess serve` turns Better Auth's rate limit on whatever `NODE_ENV` says, unless the
+  configuration sets `betterAuth.rateLimit.enabled`.
+- The push log writes a row only for a push made with a key the registry has; pushes with no key, or one that is not
+  the registry's, add up in one row per namespace per minute (`accessPushLog.count`).
+- A namespace has one live key of each kind, held by a unique slot (`accessKey.slot`): two rotations at the same
+  moment left two live keys.
+- Another namespace's key is refused as a namespace the registry does not have, with the same `401` and message, and
+  an ownership refusal never names the namespace that owns the Resource.
+- The CLI prints no control character a registry sends.
+- A revision's `:hash` that is not `sha256:` and 64 hex digits answers `404` (a NUL byte answered `500` on
+  PostgreSQL).
+- `close()` and `docker stop` stop accepting, let requests in flight finish for up to 10 seconds, then end the rest.
+- `serve()` and `avaccess serve` listen on `127.0.0.1` by default; the image passes `--hostname 0.0.0.0`. The README
+  says to terminate TLS in front of it.
+- A lock's paths refuse a drive letter, a backslash and a control character. `pull` and `generate` refuse a path whose
+  directory leads out of the project through a symbolic link, and create their temporary files new (`wx`). Paths and
+  the command line written into the generated client's comments cannot end a comment.
+- The image installs from a lockfile with `npm ci --ignore-scripts`; `access-deps` runs at build time, from the
+  operator's lockfile, and a container started with a `package.json` its image did not install refuses to start.
+- A registry list longer than 10,000 rows is refused, not cut short.
+- The README's registry server no longer turns on open sign-up, and says what `emailAndPassword` opens.