@aventara/core 1.0.0-rc.1 → 1.0.0-rc.10

package/CHANGELOG.md

@@ -1,5 +1,923 @@
 # @aventara/core
 
+## 1.0.0-rc.10
+
+### Security
+
+- A nested to-one relink could bypass a policy's update scope. In rc.9 and earlier, a to-one `$update` or `$upsert`
+  beside `$connect`, `$connectOrCreate`, `$create`, `$set` or `$disconnect` on the same relation ran the relink first
+  and then wrote the newly linked row, while the update scope, field grants, `grantsOf` and the after check had been
+  asked about the row linked before the call. A caller whose read scope reached a row its update scope did not could
+  change that row (`Post.update.unique({ data: { author: { $connect: { id }, $update: { data } } } })`). rc.10 refuses
+  the combination for every caller (`A2004`, one `V1012` issue at the relation) before anything runs, and the argument
+  types reject it. Upgrade if a policy engine guards updates through to-one relations; to relink and update, use two
+  writes. Details under Patch Changes below.
+
+### Patch Changes
+
+- 587dd01: With `access` configured, the protocol serves `POST {api}/_access/can`: a page asks the policy engine about all of its
+  buttons in one request and gets one boolean per question, in order.
+
+  ```http
+  POST /api/_access/can
+  { "questions": [
+    { "resource": "Order", "action": "update", "where": { "id": 41 } },
+    { "resource": "Refund", "action": "create" }
+  ] }
+  ```
+
+  ```json
+  200 { "code": "A1000", "data": [true, false], "cause": null }
+  ```
+
+  - Each answer is what the call the question stands for would do before any data is sent, under the principal
+    `ctx.$state.me` (seeded by the provider's `state`) and the origin `client`:
+    - an operation the Client Contract does not offer (with `where`, the action's unique variant) answers `false`;
+    - a question without `where` is the operation-level `policy.can`;
+    - a question with `where` (the Resource's unique where) is that unique call's policy admission (`can` without a
+      row, then every field it names against `fieldsOf`), then one `exists` for the row within its scopes: the read
+      scope, and for an update or delete the action's scope too. A row out of scope answers `false` exactly as a
+      missing row does, and no value of the row is read or handed to the engine;
+    - an update question answers `false` where the real update is refused before it runs: an update the engine lists
+      in `afterChecks` on a database without interactive transactions;
+    - an `AvError` the engine throws with a refusal code and a well-formed cause answers `false` for its question;
+      anything else it throws is `500 A3000`.
+  - The answer is about the row and the action, not about what a page reads of the row: it is the call selecting the
+    Resource's identifier. A page's own call that selects a field readable on some rows only is checked on its own.
+  - The answer only shapes a UI: the real call is still checked, and the route never answers `403`. It refuses malformed
+    input only, with codes the other routes already use: `404 A2002` (`V1006` at `["questions"]`) without `access`,
+    `405 A2012`, `400 A2000`, `409 A2005`, `400 A2006`, `404 A2001` for an unknown or client-hidden Resource,
+    `422 A2004` with each issue at `["questions", i, …]` (a `create` question with `where` included), `422 A2009`
+    (`V1014`) for more questions than the Client Contract's `maxListLimit`, and `500 A3000` when the engine fails
+    (`A3001` when the adapter fails under it). Questions are answered at most eight at a time, and
+    `questions: []` answers `200` with `[]`.
+  - `AvProtocol.bind(framework).handleCan(request, { state })` answers it, and `protocol.surface()` lists it as
+    `{ kind: "can", method: "POST", path: "/_access/can" }`, last, exactly when the route exists. An agent binding has
+    no `can` route.
+  - The Client Contract carries an `access` section exactly when `access` is configured (`{}` for now), so the
+    Contract hash changes only for apps that configure `access`. `validateClientContractStructure` accepts it.
+  - A failure while answering reaches the `diagnostics` sink as a new kind, `AvCanDiagnostic`
+    (`{ kind: "can", error, code, origin: "client", requestId }`). When one question met it, it also names that
+    question's index (`question`), `resource` and `action`; a failure of the whole request (the state seed, say) names
+    none.
+  - New main-entry types: `AvAccessQuestion` (one question, generic over the Resource names and their unique where),
+    `AvContractClientAccess` (the section) and `AvCanDiagnostic`.
+
+- d7e7369: `$access` on `framework.serverClient`, and the access provider's optional `client`.
+
+  - `AvAccessProvider.client?: { url, verbs }` states where the app mounted Aventara Access and the verbs it offers:
+    `signIn`, `signUp`, `signOut`, `resetPassword` and `me`, each optional (a `service` profile has no `signIn` or
+    `signUp`). Each verb is `{ method, path, args?, result, call }`: its route, the JSON Schema of its arguments and
+    result, and `call`, the verb run in process with `{ args, headers, request?, response? }`. `url` must be an
+    absolute `http(s)` URL or a root-relative path; each verb is checked at startup (`access.client.*`).
+  - The Client Contract's `access` section carries `url` and the stated verbs, each `call` dropped, its schemas checked
+    against the `json` field subset. Apps without `access`, or whose provider states no `client`, keep their hash. The
+    prebuilt fingerprint reads the `client`'s data, never its `call`.
+  - `framework.serverClient.$access` exists exactly when `access` is configured (a type error otherwise): `can(questions,
+options?)` is answered in process by the `/_access/can` route's own answerer, under the call's `state`, a
+    question's `where` read in the application forms; `me()` and the other verbs the provider offers run its `call`
+    with the `headers` you pass (a Web `Headers` or a Node request's `headers`) and, when given, the host's `request`
+    and `response` (Access sets a sign-in's cookie on the response under Nest). `me()` resolves the token identity, or
+    `null`. A provider without `client` offers `can` alone.
+  - New main-entry type `AvAccessVerbs`: `$access`'s type on every client.
+  - `validateClientContractStructure` holds the section's `url` (absolute `http(s)` or root-relative, never `//host`) and
+    each verb's `path` (one leading `/`) to the same rule the configuration is held to, so a consumer refuses a served
+    ClientContract that points elsewhere.
+  - `serverClient.$access.can` called with `headers` and no `state` is answered under the state the provider seeds from
+    those headers; with neither, anonymously.
+
+- 7ee547b: `AvAccessProvider.client.verbs` takes Aventara Access's `kiosk` profile verbs too: `switchUser`, `lock`, `setPin`,
+  `enrollDevice` and `revokeDevice`, each optional and shaped as the other verbs (`{ method, path, args?, result, call }`); any
+  other name is still refused at startup. They reach the Client Contract's `access` section only when the provider
+  states them, so an app without them keeps its hash. `framework.serverClient.$access` runs each through its `call` in
+  process, with the headers, request and response you pass (Access sets the rotated device cookie on the response under
+  Nest): `switchUser(args)` and `enrollDevice(args)` resolve Access's answer; `lock()`, `setPin(args)` and
+  `revokeDevice(args)` resolve nothing. `AvAccessVerbs` gains the five members, and its `Args` names `switchUser`,
+  `setPin`, `enrollDevice` and `revokeDevice`. The MCP agent surface offers none of them.
+
+  The `access` section's `url` and each verb's `path` now also refuse U+0000–U+0020 and DEL, `.`/`..` segments
+  (percent-encoded too) and a bare `"/"` url, in the configuration and in every ClientContract read: a URL parser drops
+  tab, LF and CR, so `"/\t/evil.example"` resolved to another host. `serverClient.$access` now projects every verb's
+  answer (and `me`'s identity) onto its result schema, as the generated client and MCP `me` do; an answer the schema
+  cannot describe throws.
+
+- f52c499: A model whose table another service owns can be marked at the root: `resources.<R>.managedElsewhere: true`. Aventara
+  reads it and joins through it, and no standard operation writes it.
+
+  ```ts
+  createFramework({
+    api: "/api",
+    adapter,
+    resources: { Account: { managedElsewhere: true } },
+  });
+  ```
+
+  - No `create`, `update`, `delete` or `upsert` on it in any layer, and no field write. A call is a type error, and an
+    untyped one is `A2002`.
+  - A relation into it keeps only `$connect`/`$disconnect`, and only where the source holds the key; a nested
+    `$create`/`$update`/`$upsert` into it is a type error and `A2004` (`V1006`).
+  - The client and agent Contracts leave it out, with every relation into it. `framework.application` reads and joins it.
+  - A stage on one of its write families is refused at startup (`COMPILER_UNAVAILABLE_OPERATION`); the key in an overlay
+    is `CONFIG_FORBIDDEN_IN_OVERLAY`.
+  - The Core Contract marks it `managedElsewhere: true` and states each Resource's database `schema` when the adapter
+    does (`AvCoreResource.schema`, `AvCoreResource.managedElsewhere`; the adapter states it as `AvAdapterResource.schema`).
+    No other Contract carries them, so no Client Contract hash moves.
+  - A delete whose referential action would write it (`cascade`, `setNull`, `setDefault`, directly or through other
+    cascades) is refused at startup (`CONFIG_INVALID_VALUE` at `resources.<R>.managedElsewhere`), and a create that only
+    the hidden relation could satisfy is `COMPILER_HIDDEN_REQUIRED_FIELD`.
+  - Not covered: key updates follow the owner's foreign key (core has no `onUpdate` facts), and `ctx.$sql` or a stage
+    calling the ORM can still write it.
+
+- 2907484: `mcp.authorization.servers` accepts an http authorization server on this machine, so an MCP setup on a laptop needs no
+  TLS: `http://127.0.0.1:4000` or `http://[::1]:4000`, with any port and path.
+
+  - `localhost` (any case) is refused with the address to use: `… is an http loopback URL; write it as
+http://127.0.0.1:4000, the spelling every client reads as this machine`. A name is looked up, and `localhost` can
+    resolve somewhere else (RFC 8252 §8.3).
+
+  - Any other http URL is refused as before (`mcp.authorization.servers[0] must be an absolute https URL`). That covers
+    `0.0.0.0`, `[::]`, other `127.x` addresses, IPv4-mapped addresses, names such as `auth.localhost` or
+    `localhost.example.com`, and URLs with credentials.
+  - The host is read the way the WHATWG URL parser reads it, and the URL must be written the way that parser writes it
+    back. `http://127.1:4000`, `http://2130706433:4000` and `http://127.0.0.1:4000\@example.com` are refused with the
+    spelling to use (`… is an http loopback URL; write it as http://127.0.0.1:4000, the spelling every client reads as
+this machine`), so no client can read a different host from the URL your metadata advertises.
+  - Every server, https included, is refused when its path has an empty segment (`//`) or it names port 0. A client
+    builds its discovery URLs from the path, and a path starting `//` is protocol-relative: `http://127.0.0.1//evil.com`
+    would send the client to `evil.com` for its metadata. A loopback http server also takes no query or fragment.
+  - An http authorization server is for local development only; deploy with https.
+
+- a6bbdf0: For an update the engine lists in `afterChecks`, the after check now also hands the engine the changed row as it was
+  before the update: `can({ action: "update", row, before })`. Core reads it inside the update's transaction, ahead of
+  the write, with the fields `row` carries, so an engine can require that one grant covers a row both before and after
+  the update and stop an update moving a row from one grant's rows to another's. `before` is optional and present only
+  for a listed update; an unlisted update gets none and runs exactly the statements it ran before. A listed root
+  `update.unique`, `update.many` or `update.count` runs one read more (a nested write reuses the read it already makes).
+
+  The listed update is held to the rows as that read saw them (their values ANDed into the write's selector), so a row
+  changed concurrently is missed instead of checked against a stale `before`. A listed update that writes several rows
+  and cannot pair a changed row with its `before`, or of a Resource offering no `find.many`, is refused (`A4002`).
+
+  Fixed: an update whose rows are checked after it without being returned (a nested `$update`, a linked row, an
+  `update.count` that reads its rows first) skipped the after check for a row whose identifier it changed. It is now
+  refused (`A4002`) and rolled back.
+
+- 3e26549: A policy engine may answer a new optional question, `grantsOf({ principal, origin, resource, action: "update", row,
+exists })`, with a list of strings: its own keys for the grants that cover `row`. For an update the engine lists in
+  `afterChecks`, core asks it about each row as it was before the update, right after reading that row and before any
+  interceptor, hook or the write itself, inside the update's transaction, so the rule's `exists` lookups see nothing the
+  request writes. The after check of the same row then states the answer, unchanged, as `beforeGrants` beside `before`.
+  An engine that requires one grant to cover a row both before and after its update can require the grant covering
+  `row` to be one of `beforeGrants`, so a nested write in the same request (a membership created alongside the update)
+  can no longer make `before` appear to meet a relation-based grant it did not meet.
+
+  Additive: an engine without `grantsOf`, and an update `afterChecks` does not list, are asked exactly what they were
+  before. An answer that is not a list of strings answers `A3000` and nothing is written; a `grantsOf` that is present
+  and not a function fails construction (`CONFIG_INVALID_TYPE`).
+
+- a6bbdf0: A policy engine may state a typed literal in a fragment it answers (a `scopeOf` scope, a `fieldsOf` per-row grant, an
+  `exists` question) in its wire form as well as its application form: `"2026-01-01T00:00:00.000Z"` or a `Date`,
+  `"0.3"` or an `AvDecimal`, `"9007199254740993"` or a `bigint`. Both reach the adapter as the runtime value and select
+  the same rows. Before, a wire form answered `A3000`, so an engine whose rules are data (read from JSON) could not
+  compare a `datetime`, `decimal` or `bigint` field. A value in neither form is still the server's `A3000`.
+- 6f3f6f6: **Security.** A to-one `$update` or `$upsert` next to `$connect`, `$connectOrCreate`, `$create`, `$set` or
+  `$disconnect` on the same relation is now refused for every caller: `A2004` with one `V1012` issue at the relation,
+  before anything runs. The argument types now reject the combination too. Before this fix (rc.9 and earlier), the ORM ran
+  the relink first and the update then wrote the newly linked row. But a policy's update scope, its field grants,
+  `grantsOf` and the after check had all been asked about the row linked before the call. So a caller whose read scope
+  reached a row that its update scope did not could still change that row, for example with
+  `Post.update.unique({ data: { author: { $connect: { id }, $update: { data } } } })`. To do both, relink in one write and
+  update the linked row in another. A to-many operand may still combine them, because each entry names its own rows.
+
+  A `grantsOf` answer that is a sparse list (one with a hole) is now the server's defect (`A3000`), as any other answer
+  that is not a list of strings already was. Before, the hole reached `can` as an `undefined` grant.
+
+- 04bb39a: `engines.node` is now `^22.23.4 || >=24.22.1`, the Node 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 bins refuse an older Node in one sentence naming that range.
+- 3fb3333: `@aventara/mcp` pins `@modelcontextprotocol/sdk` 1.32.2 (was 1.30.1) and `zod` `^4.6.7` (was `^4.6.5`); `@aventara/core`
+  also takes `zod` `^4.6.7`. This clears the advisories against those versions:
+
+  | Advisory                              | Severity | Package             | What it was                                                                                              |
+  | ------------------------------------- | -------- | ------------------- | -------------------------------------------------------------------------------------------------------- |
+  | GHSA-46jr-4wx8-v453 (CVE-2026-111768) | high     | sdk < 1.32.0        | One HTTP request within the default size limit could exhaust server memory during validation             |
+  | GHSA-22jm-h49p-29qw (CVE-2026-111767) | high     | sdk 1.24.0 – 1.31.x | Experimental tasks were not tied to the session that created them                                        |
+  | GHSA-6qxp-vccf-f47h (CVE-2026-104850) | high     | sdk 1.12.0 – 1.30.x | The OAuth client could send credentials to an authorization server chosen by the MCP server              |
+  | GHSA-mrhx-c7xc-m3w5                   | high     | zod ≤ 4.6.5         | Validating an oversized unconstrained array could exhaust memory                                         |
+  | GHSA-rvq5-wwqv-78pq (CVE-2026-111771) | moderate | sdk 1.6.0 – 1.31.x  | Server bearer authentication accepted tokens issued for another service                                  |
+  | GHSA-6prh-2h8m-c8cw (CVE-2026-111769) | moderate | sdk < 1.32.0        | HTTP client transports and OAuth requests followed cross-origin redirects with custom headers and bodies |
+
+  Aventara's MCP server was already outside most of these: it uses the low-level `Server` (no `taskStore`, no
+  `requireBearerAuth`, no SDK OAuth client), and its transport's `maxRequestBodySize` is the agent layer's
+  `limits.maxRequestBytes`. No API of `@aventara/mcp` changes.
+- 827ccb6: A listed update (`afterChecks`) no longer refuses an unchanged row on PostgreSQL. The compare-and-swap that holds the
+  write to the rows as they were read compares each field by `equals`, and the adapter's `equals` now matches every row
+  that reads as the value:
+
+  - a scalar list a create left out, which Prisma stores as `NULL` and reads as `[]`: an operator object that holds for
+    `[]` (`equals: []`, `isEmpty: true`, `hasEvery: []`) holds for that row too, in every filter;
+  - a timestamp finer than a millisecond (a `@db.Timestamptz(6)` the database writes), which Prisma reads truncated:
+    equality with an instant also holds the instants inside its millisecond.
+
+  On a `Bytes[]` column, `equals`, `hasEvery` and `hasSome` are no longer offered: Prisma 7.10.1 binds their operand's
+  members as base64 text, so they matched other rows than they named. `has` and `isEmpty` remain. Such a column is not
+  part of the compare-and-swap.
+
+  The compare-and-swap takes its fields from what the adapter compares, so an exemption that hides `equals` from callers
+  no longer takes a field out of it.
+- 7f5abc3: An editor's hover over a provider written `satisfies AvAccessProvider`, and the declarations a consumer emits for one,
+  no longer name `AccessRequestHeaders`, a module-local alias no entry exports. `state`'s `headers` is written inline
+  again, and each verb's `call` reads the same type from `state` (`Parameters<AvAccessProvider["state"]>[0]["headers"]`),
+  so both print as the part of a Web `Headers` they are. A test now holds what a provider's hover names to the
+  entry's exports and TypeScript's library.
+- 88263a1: Startup checks, tightened:
+
+  - An `mcp.authorization.servers` entry with a query or a fragment is refused for https URLs too, not only for loopback
+    http ones: an authorization server's issuer has neither (RFC 8414).
+  - A `client.resources` or `agent.resources` entry for a Resource managed elsewhere is refused (`COMPILER_UNKNOWN_RESOURCE`):
+    those layers never have the Resource, so nothing configured there would run. Configure it at the root or in
+    `application`.
+
+- 10341d5: Policy checks, tightened:
+
+  - Writing a reference field itself (`authorId: "u2"`) is held to the target's read scope, as `$connect` is: the row it
+    names must be one the caller may read, or the write is refused (`A4002`). Creates, updates, both branches of an
+    upsert and the records of nested writes are all checked. The reference is handed to the adapter as a `$connect` that
+    carries the read scope, so the write itself refuses a row outside it, with no extra query; a row that is not there is
+    refused the same way. Where Prisma's input takes no relation (`createMany`, `updateMany`, a to-many nested
+    `$update`), and where a create writes a reference `null` (left out, the column's default would fill it), one count
+    per target Resource asks before the write whether every row named is there and readable. Nothing is asked where that
+    Resource is read by everyone, and a `null` reference is not asked about. A record written this way writes its other
+    references as links too, so a missing row there answers `A2003` rather than `A2008`.
+  - A row a write names to link that is not there is refused (`A4002`) like a row the caller cannot read, wherever the
+    target has a scope: a reference field, and a `$connect`, `$set` or `$disconnect` selector. Before, a missing row
+    answered the store's `A2008` or `A2003`, which told a caller which rows it cannot read exist. Without a scope, the
+    codes are unchanged.
+  - An update the engine lists in `afterChecks` now holds a to-one nested `$update` to its row as it was read. A row a
+    concurrent write changed in between refuses the write (`A4002`) and rolls it back, with no extra query.
+  - A listed `update.many` or `update.count` that changes fewer rows than it read (a concurrent write changed one in
+    between) is refused (`A4002`) and rolled back, rather than answering a partial success.
+  - The client and agent Contracts leave out an enum that only a Resource managed elsewhere uses. The ClientContract hash
+    of an app with such an enum changes.
+  - Seven public types write their members out in an editor's hover instead of naming a type no entry exports (`ctx.$sql`,
+    a compute stage's context, a pipe's return, `defineResource`'s overlays, a family's variants, the `access` and
+    `policy` check, `AvConfigComputedFields.agentExtends`).
+
+- 8129844: A policy engine may take the optional `hosted({ held })`. Core calls it once, when a Framework is built on the engine
+  and every construction check has passed, with the Resources a written reference is held to the read scope of: every
+  Resource of the Core Contract, so none the root's exemptions hide. An engine can check its rules against that list and
+  warn about a write its rules allow that the hold would always refuse. It changes no answer. A `hosted` that is not a
+  function fails construction (`CONFIG_INVALID_TYPE`), as `grantsOf` does.
+- 88263a1: Policy checks, tightened:
+
+  - The rows a write returns are checked against the database as the write left it. An `exists` answer asked before the
+    write (by `grantsOf`, say) is no longer reused for the same question after it.
+  - A `fieldsOf` answer whose `always` is a sparse list is the server's defect (`A3000`), as a sparse `grantsOf` answer
+    is.
+  - An access provider's verbs are its own enumerable `client.verbs` keys. A verb `verbs` only inherits, or holds
+    non-enumerable, is no verb: never offered on `$access` and never compiled into the Client Contract.
+
+- 3020b5c: A policy engine may list `unheld`: the Resources its rules read in conditions and decide no read of, such as one another
+  service owns. A reference a write sends to a row of one, and a `$connect` or `$set` that links one by the reference's
+  own values where the writing row holds the reference, is no longer held to the caller's read scope, which is `false` for every caller there and refused
+  every such write (`A4002`). The write's own grant decides which row may be linked (`can`, and the after check). Reads of
+  those Resources are decided by `scopeOf` as before, and `hosted({ held })` leaves them out. A value that is no list of
+  strings fails construction (`CONFIG_INVALID_TYPE`), and so does a name the data source's model does not have
+  (`CONFIG_INVALID_VALUE`).
+- 88263a1: Documentation: `$access.can([])` answers `[]`, not a refusal; the MCP README states the query and fragment rule for
+  every authorization server.
+- 88263a1: A value projected onto an `access` verb's result schema is refused with the projector's own `TypeError` when the schema
+  is outside the forms a Client Contract states (a free-form object or list, a tuple read past its length), whatever the
+  value, an empty one included. A Client Contract that passed its structure check never holds such a schema.
+
+## 1.0.0-rc.9
+
+### Patch Changes
+
+- 205a379: `createFramework` takes `access`, an access provider: the policy engine and the request state from one object.
+  `AvAccessProvider` is the new main-entry type it is written against, with two members:
+
+  - `policy`: the engine every client and agent request is checked against, as `policy.engine` takes it.
+  - `state({ headers, request })`: seeds each request's `ctx.$state`. Its `me` is the principal the engine is asked
+    about, `null` for an anonymous caller.
+
+  Aventara Access provides one, and a hand-written provider works the same way (a till's PIN sign-in, say: see the
+  README). The host calls `state` once per request; server code that calls the Framework directly passes the state
+  itself. A governed field of the provider's engine is left out of the default projection's type, as with `policy`.
+  `access` together with `policy` is refused at startup (`CONFIG_INVALID_VALUE` at `policy`) and is a type error at
+  `policy`. A provider whose `policy` is no engine or whose `state` is no function is refused at startup, member by
+  member, and the engine's `governed`, `paths` and `afterChecks` are checked against the Core Contract under
+  `access.policy`. A prebuilt Contracts file counts the provider by its engine's governed set alone.
+
+- a0bb05e: A Framework's `diagnostics` sink receives every report when the process holds more than one copy of `@aventara/core`
+  (Next.js giving each layer its own copy, a duplicate install, a monorepo). A protocol failure such as a result with no
+  wire form (`500 A3003`), or an MCP endpoint failure, raised through another copy than the one that built the Framework
+  now reaches the sink instead of being silently dropped. Copies of one major version share the sinks; nothing in the
+  public API or its types changed.
+- 86ab319: Values and errors from `@aventara/core` are recognized across duplicate copies of the package in one process. A
+  bundler that gives each layer its own copy (Next.js instrumentation, route handlers and pages), a duplicate install, a
+  monorepo, Vite SSR, per-function bundles and test runners' module isolation all load core more than once.
+
+  - A decimal made by one copy is an `AvDecimal` to every other: `value instanceof AvDecimal` is `true`, the protocol
+    encodes it (a `find.many` selecting a decimal no longer answers `500 A3003` "Result serialization failed"), and a
+    Framework accepts it in arguments, `$sql` values and Adapter results.
+  - `AvError` and its subclasses (`AvValidationError`, `AvNotFoundError`, `AvConflictError`, `AvAuthError`,
+    `AvInternalError`, `AvProtocolError`, `AvContractMismatchError`), `AvConstructionError`,
+    `AvTransactionIntegrityError` and `AvTransactionSlotPathError` pass `instanceof` across copies, with the same
+    subclass rules: every one is an `AvError`, and each is only its own subclass. An `AvError` a pipeline throws with
+    another copy's class is answered as the outcome it names. A subclass you declare yourself is checked as before.
+  - Copies recognize each other within one major version only. Nothing in the public API or its types changed.
+
+- fdf52e6: `framework.serverClient` and `framework.serverClientTx`: the client layer for server code, called with application
+  values, such as a Next.js Server Component's.
+
+  - `framework.serverClient.<Resource>.<family>.<variant>(args, options?)` is typed from the Client Contract's view, as
+    `framework.client` is: what the client layer hides is absent. Its arguments are the application forms (`Date`,
+    `bigint`, `AvDecimal`, `Uint8Array`), the ones `framework.application` takes, and their wire strings are type errors.
+    Its results are `framework.client`'s. At runtime a value already in its wire form is accepted too, as
+    `framework.client` reads it.
+  - Each call copies its arguments, encodes the copy into the wire forms against the Client Contract, and runs the request
+    `framework.client` would run for those wire forms: the same client pipelines, validation, exposure and policy, the
+    same answers and the same `AvError` classes. `framework.client` itself is unchanged and keeps the wire forms.
+  - `framework.serverClientTx` builds client-origin transaction handles from application values. One
+    `framework.transaction([...])` may hold them beside `clientTx` handles, never beside `appTx` ones.
+  - New main-entry type names: `AvServerClientFacade`, `AvServerClientResourceFacade`, `AvServerClientFamilyFacade`,
+    `AvServerClientProjectingCall`, `AvServerClientPlainCall`, `AvServerClientTxFacade`,
+    `AvServerClientTxResourceFacade`, `AvServerClientTxFamilyFacade`, `AvServerClientTxProjectingCall`,
+    `AvServerClientTxPlainCall`.
+
+## 1.0.0-rc.8
+
+1.0.0-rc.5, rc.6 and rc.7 were tagged but never published; 1.0.0-rc.8 contains everything listed under them and the changes below.
+
+### Patch Changes
+
+- 1c8e4ee: Helpers typed off the façades compile again in projects that emit declarations. In 1.0.0-rc.7 a function that took
+  `Parameters<AppFramework["application"]["Post"]["find"]["many"]>[0]` and returned its `where` (or built a new one
+  from it, `{ AND: [args.where ?? {}, { published: { equals: true } }] }`) without a return type failed `nest build`
+  (and `tsc` with `"declaration": true`) with `TS4023: ... has or is using name 'ScalarFilterOperands' ... but cannot be
+named`, usually beside `TS7056`. A nested write's data could fail the same way, or name `NO_ADVERTISED_MEMBER`, and a
+  nested `$update`'s `where` was written into the `.d.ts` as `any`. The declaration now names the argument types
+  `@aventara/core` exports (`AvWhereInput`, `AvUpdateDataInput`, `AvCreateDataInput`, ...), and these new exports cover
+  the rest:
+
+  - `AvScalarFilterOperands`: one field's filter operators, which a filter's `not` holds again.
+  - `AvScalarWhereInput`: the `where` of a nested `$update` or `$delete` that only takes plain fields.
+  - `AvNoAdvertisedMember`: a write member that advertises nothing; it takes `{}` and refuses every key.
+  - `AvSqlStatementBuilder` and `AvSqlStatementValue`: the type of `framework.appTx.$sql` and the values it binds.
+    A method returning `framework.appTx.$sql` failed with `TS2883`/`TS2742` before.
+
+  `framework.execute` and `framework.executeTransaction` take request types that `@aventara/core` exports:
+  `AvOperationRequest` (`AvApplicationOperationRequest`, `AvClientOperationRequest`, `AvAgentOperationRequest`),
+  `AvTransactionRequest` (`AvApplicationTransactionRequest`, `AvClientTransactionRequest`,
+  `AvAgentTransactionRequest`) and `AvRequestProtocol` (a remote request's `protocol`). They were named from
+  `@aventara/core/internal` (`FrameworkOperationRequest`, `FrameworkTransactionRequest`, ...), so a declaration that
+  spelled them reached into the package's internal entry. Those names are gone from `@aventara/core/internal`.
+
+  An adapter's `referentialActions` edges name the fields that hold the reference `referenceFields`, as a relation of
+  the Core Contract does. They were called `references`, which the Core Contract uses for the target's fields.
+
+  Reading a projecting variant's argument type (`Parameters<…["find"]["many"]>[0]`) also type-checks faster: about
+  6,000 type instantiations over a three-field model, where rc.7 took about 29,000. The part of the argument other than
+  `select`/`include` is now marked `NoInfer` in the call's parameter, so an editor shows that parameter as
+  `NoInfer<Omit<…>> & …`. What it accepts is unchanged.
+
+  A create's `data` type now states each required field once, as a required member (`Readonly<{ title: string; } & {
+body?: ... }>` in an editor's expanded hover). Before, a required field appeared as an optional member beside a
+  separate `{ readonly title: WrittenValue }`, and a declaration file wrote both. What a create accepts and refuses is
+  unchanged.
+
+- Operation results read as their value types in an editor and in emitted declarations. A result field that is nullable,
+  an enum or a `boolean` (such as a `Boolean @default(false)` column) was shown as `AvScalarValueType<…>`, with the
+  whole Contract view as its argument, and a project with `"declaration": true` wrote that view into its `.d.ts` once
+  per such field: a Nest service of five methods with no return types came out at 524 lines. Those fields now read
+  `body: string | null`, `published: boolean`, `publishedAt: Date | null`, and that service's declaration is 44 lines.
+  A result, and a relation included in it, is shown as its fields rather than as `ProjectedFields<…>`. This covers
+  `framework.application` and `framework.client` results, the same fields in a write's `data`, and clients generated
+  by `avclient`. What each type accepts is unchanged.
+
+## 1.0.0-rc.7
+
+1.0.0-rc.5 and 1.0.0-rc.6 were tagged but never published; 1.0.0-rc.7 contains everything listed under them and the changes below.
+
+### Patch Changes
+
+- f917c1c: A helper that reads `framework.contracts.core` compiles again in projects that emit declarations. In 1.0.0-rc.6 a
+  function returning a Resource or a field of the Core Contract without a return type, such as
+  `core.resources[resource]?.fields[relation]`, failed `nest build` (and `tsc` with `"declaration": true`, which Nest's
+  `tsconfig.json` sets) with `TS2883: The inferred type of 'relationOf' cannot be named without a reference to
+'AvCoreField'` under TypeScript 6 (`TS2742` under 5.9), or with `TS4058`/`TS4023` naming `AvCoreResource`.
+  `@aventara/core` now exports the three types the Core Contract is written with: `AvCoreResource` (a Resource),
+  `AvCoreField` (one of its fields) and `AvCoreRelationField` (a relation field, with the target fields its reference
+  names in `references`).
+
+  A policy's startup check states the path once: `CONFIG_INVALID_VALUE at policy.engine.governed.Nope: "Nope" is no
+Resource of the Core Contract`, where rc.6 repeated `policy.engine.governed.Nope:` inside the message. Each
+  diagnostic's `message` no longer starts with its `path`; read the path from `path`.
+
+## 1.0.0-rc.6
+
+1.0.0-rc.5 was tagged but never published. 1.0.0-rc.6 contains everything listed under 1.0.0-rc.5 and the fix below.
+
+### Patch Changes
+
+- 1cf72e0: Typed policy engines compile again in projects that emit declarations. In 1.0.0-rc.5 an engine written
+  `as const satisfies AvPolicyEngine` failed `nest build` (and `tsc` with `"declaration": true`, which Nest's
+  `tsconfig.json` sets) with `TS2883: The inferred type of 'policyEngine' cannot be named without a reference to
+'PolicyFieldsAccess'` under TypeScript 6, or `TS2742` under 5.9, and so did the configuration and the framework holding
+  it. `fieldsOf`'s question is now written out in full in `AvPolicyEngine`, so a declaration can spell it.
+
+  A read question's `action` is now typed `undefined`, so an engine can destructure it from either question:
+  `fieldsOf({ resource, access, action })`. A write question's `action` is `"create"` or `"update"`, as before.
+
+## 1.0.0-rc.5
+
+### Patch Changes
+
+- 4795ff1: Two additions for policy engines. A Framework without a policy, and every Contract a caller is served, are unchanged.
+
+  - A policy engine can check a create whose row reaches another Resource through a relation. Discovery now states, on the end of a relation that holds the reference, which of the target's fields its reference fields name, pair by pair (`Note.campaign`: `referenceFields: ["campaignId"]`, `references: ["id"]`). An engine reads them from the model it is built from (a Prisma discovery artifact's `model`) or from `framework.contracts.core`, and asks one `exists` about the row they name: "a player creates a note only in a campaign they play in". Only the adapter's model and the Core Contract carry them. The Application, Client and Agent Contracts, `/_contract`, the MCP tools and every ClientContract hash are unchanged. The discovery artifact's model hash, and so a prebuilt Contracts file's fingerprint, change: regenerate the artifact and rebuild the prebuilt file.
+  - `fieldsOf({ access: "write" })` also names the action that writes the record, `action: "create" | "update"` (an upsert's branches each their own, a nested record its directive's), so an engine can lock a field on update and still let a create write it. A read question names none. An engine that ignores it keeps working.
+
+- 9e178ca: Fixes for applications that check requests with a policy engine. A Framework without a policy behaves as before.
+
+  - A cursor on a row the caller cannot read is answered exactly as a cursor on a row that does not exist, at the root and in a to-many relation, whatever values the caller sends beside the identifier. Before, the page started at the hidden row, so it told that the row exists and where its values sort. The Prisma adapter reads the cursor's row under the read scope first: one statement more for a cursor on a readable row, and only that read for one on a row the caller cannot read.
+  - A unique update with a nested write (`$create`, `$connect`, …) on a row the caller can read but not change answers `A4002`, as the same update without one does. It answered `A2003`. A row the caller cannot read still answers `A2003`.
+  - The `exists` questions a policy asks select the Resource's primary identifier, never another unique field such as a governed `email`.
+  - `policy.principal` may answer with a promise. A synchronous principal works as before; a rejection answers `A3000`, as a throw does.
+  - `AvConstructionError.message` names the first problem and how many more there are, for example `Aventara framework configuration validation failed: CONFIG_INVALID_TYPE at adapter.execute: adapter.execute must be a function (+2 more)`. `stage` and `diagnostics` are unchanged.
+
+## 1.0.0-rc.4
+
+### Patch Changes
+
+- e3d03a7: The error catalog says more about policies. `A2003` now names the cases a policy adds: a unique read of a row outside the
+  caller's read scope, and a single-row update or delete of a row the caller cannot read, are misses, while a row the
+  caller can read but not change answers `A4002`. `CONFIG_REQUIRED`, `CONFIG_UNKNOWN_PROPERTY` and `CONFIG_INVALID_VALUE`
+  name the `policy` key's rules: `policy.engine` and `policy.principal` are required, `policy` and `prebuilt` are root-only,
+  and the engine's `governed`, `paths` and `afterChecks` lists must name what the Core Contract has. Wording only; no
+  behaviour changes.
+- d10639a: Faster reads. The read-only copies stages are told cost about half what they did: a read with a computed field
+  copies each row in one pass, a row with several computed fields shares its nested objects between the stages'
+  copies, and after hooks share one frozen copy of the result. A row whose computed field returns a value at once no
+  longer waits a turn per row. The MCP endpoint builds its JSON Schema validator once instead of on every request.
+  What stages are told, the order they run in and what a request answers are unchanged.
+- f67e68c: A service method can return any façade node or variant without a return type. Under `declaration: true` (a Nest
+  build) the declaration file now writes a short reference, under half a kilobyte per method at any schema size, where it
+  wrote the whole Contract view (about 440 KB per method over 50 Resources). A method returning a variant
+  (`this.framework.application.Post.find.many`) no longer needs an annotation to compile, and one returning a transaction
+  variant (`this.framework.appTx.Post.create.one`) no longer runs the compiler out of memory.
+
+  New type names, exported from `@aventara/core` so a declaration can write them (you never need to write them yourself):
+
+  - `AvContractView`, the Contract view the façades are typed over;
+  - one call type per surface and shape: `AvApplicationProjectingCall`, `AvApplicationPlainCall`,
+    `AvClientProjectingCall`, `AvClientPlainCall`, `AvAppTxProjectingCall`, `AvAppTxPlainCall`,
+    `AvClientTxProjectingCall`, `AvClientTxPlainCall`.
+
+  A configuration with `fields` entries still writes those entries after each reference; annotate the method if that
+  matters (see the README's "Returning a façade from a method").
+
+- 708556c: Policy engines check nested writes. A create, update or upsert whose data writes a relation through a directive
+  (`$create`, `$connect`, `$connectOrCreate`, `$update`, `$upsert`, `$delete`, `$disconnect`, `$set`) now runs under a
+  policy, where before it was refused. It runs as one adapter call inside the write's interactive transaction, and one
+  failed check rolls the whole write back with `403 A4002`.
+
+  - Every row the nested write creates is read back as stored (its parent's reference filled, database defaults
+    present) and asked `can({ action: "create", row })`, its `exists` lookups seeing the rows the same call wrote. A
+    create whose own data holds a nested write is asked about its row the same way, after the insert.
+  - A row a directive links or unlinks is held to the scope of the row that changes: a linked row that holds the
+    reference (a to-many relation's rows, the back end of a one-to-one, a many-to-many relation's rows) must be in its
+    update scope, one whose parent holds the reference (a to-one relation's target) in its read scope. One `exists`
+    per Resource answers it, inside the transaction. A linked row that changes is an update: after the call it gets
+    the after check (`can({ action: "update", row })`) and the move-out re-read. Linking a new row to a one-to-one's
+    back end unlinks the old one, which is held the same way.
+  - A to-many nested `$update` or `$delete` acts only on the rows within the update (or delete) scope, as
+    `update.many` and `delete.many` do: core reads those rows' identifiers inside the transaction and hands the
+    adapter `where: { id: { in: [...] } }`. A to-one one refuses the write when its row is outside the scope. A nested
+    `$update`'s changed rows get the after check and the move-out re-read after the call.
+  - The fields a nested record sends are held to its Resource's `fieldsOf({ access: "write" })`, and a relation written
+    through a directive to the parent's grant, its reference fields with it.
+  - Where the operation's `transactionsStyle` is `"none"`, a nested write under a policy is refused before it runs.
+
+- 3a0dfca: A write the policy checks costs fewer database round trips. What each check decides and refuses is unchanged.
+
+  - A single-row update or delete carries the caller's scopes inside its own `where` and runs as one statement, with no
+    read of its row before it. One that matches nothing still answers `A4002` when the caller can read the row and
+    `A2003` when it cannot, with one lookup on that miss only. The Prisma adapter sends it as
+    `update({ where: { id, AND: [scope] } })`.
+  - A create asks `can({ action: "create", row })` and its `exists` lookups before the insert, without a transaction. A
+    transaction around them never closed the race between the lookup and the insert at the database's default
+    isolation, and cost a BEGIN and a COMMIT.
+  - A transaction opens only when a check after the write may roll it back: an update's after check or move-out, a
+    created row held to a write grant, a nested write, or returned rows checked by `exists`. A plain checked create or
+    delete is one statement, its interceptors and hooks outside any transaction.
+  - The after check asks `can` about the row the update returned, so it reads nothing again. Only a move-out reads the
+    changed rows again. An `update.count` runs as the returning `update.many` when the Contract offers it.
+
+  Round trips per request on PostgreSQL: `create.one` 3 → 1, `delete.unique` 4 → 1, `update.unique` 5 → 3,
+  `update.many` 4 → 3, `update.count` 5 → 3. Reads, and a Framework without a policy, are unchanged.
+
+- 99169d2: Policy engines, reads first. `createFramework` takes an optional root `policy: { engine, principal }`: an engine that
+  answers three questions (`can`, `scopeOf`, `fieldsOf`, each now or as a promise), and a function that derives a
+  request's principal from its `ctx.$state`. Core never imports an engine; one satisfies `AvPolicyEngine` by its shape,
+  and a scope or grant is a fragment of Aventara's own `where` (`AvPolicyWhere`).
+
+  - Client and agent requests are checked (an MCP tool call is an agent request). An application call is checked only
+    when it names a principal: `framework.application.Note.find.many(args, { as: user })`. A call a stage makes through
+    `ctx` never is.
+  - Before any guard, `can` and the fields the request names or receives (`fieldsOf`); a refusal is `403 A4002`. At the
+    adapter call, after every developer stage, the read scope is ANDed into the root `where`, every to-many include and
+    its `$count`, and every relation filter, at every level. A to-one include of a row out of scope refuses the request;
+    it is never nulled.
+  - Governed fields (the engine's `governed` list) are left out of every default projection and carry `governed: true`
+    in the Contracts. Name one to get it: `select: ["$defaults", "email"]`, where `$defaults` is the level's default
+    projection. It is refused where a returned row does not grant it, and a filter or sort by it is checked before the
+    query runs, so it cannot reveal values the caller may not read.
+  - The engine's `governed` and `paths` lists are checked against the Core Contract at startup. A rule's paths are lists
+    of segments, as other paths in core are: `["Note", "campaign", "members", "some", "userId", "equals"]`.
+  - Writes are checked as well; see the policy writes entry.
+
+  Without `policy`, nothing changes: the Contracts and their hashes are the same bytes.
+
+- 0fd2608: A write the policy checks costs less CPU after the round-trip changes. The operation core hands its adapter no longer
+  carries the request's policy session, so an adapter that keeps its operations no longer keeps each request's session
+  with them. The fields a write returns only for the after check are dropped as soon as the check has read them, so a
+  read compute stage is told the row the request asked for, not every scalar field. What each check decides, the
+  fields `can` is asked about, and the database round trips are unchanged.
+- 154e440: Policy engines check writes. Every create, update, delete and upsert a client or agent makes (or an application call
+  made `{ as }` a principal) is now checked by the configuration's `policy`, where before it was refused.
+
+  - The fields a write sends are held to `fieldsOf({ access: "write" })` before any guard; a field outside it answers
+    `403 A4002`. A field writable on some rows only is checked against every row an update reaches, and against the
+    row a create inserts, after the insert and inside its transaction.
+  - A create asks `can({ action: "create", row })` about each new row on its final data. Its rules can look rows up
+    through `exists`, which runs inside the write's transaction, so a plan that creates a campaign and then its first
+    note sees the campaign.
+  - An update or delete acts only on rows the caller may both change (`scopeOf` for the action) and read. A single-row
+    one that matches nothing answers `A4002` when the caller can read the row, and `A2003` when it cannot, so the
+    answer does not reveal that the row exists. A `many` or `count` one answers for the caller's rows only.
+  - An update that moves a row out of what the caller reads is rolled back with `A4002`. So is one that fails an `after`
+    condition: inside the transaction core asks `can({ action: "update", row })` about each changed row of every
+    checked update. The engine's new `afterChecks` member (`{ Note: ["update"] }`) names the updates whose grants carry
+    such a condition, which are the ones refused where there is no interactive transaction.
+  - Where the operation's `transactionsStyle` is `"interactive"`, a checked write runs in a transaction of its own. Where
+    it is `"none"` (Cloudflare D1), a write that can only be checked after it runs is refused before it runs; every other
+    write runs, a create looking up before it inserts, and an unlisted update without the after check.
+  - Nested writes (a relation directive in a write's data) are refused under a policy for now.
+
+  `afterChecks` is checked against the Core Contract at startup and changes no Contract and no prebuilt fingerprint.
+
+- 2fcffdb: Prebuilt Contracts. `createFramework` takes an optional `prebuilt` key: the four Contracts compiled ahead of time (type
+  `AvPrebuiltContracts`), so a serverless or edge cold start loads them instead of compiling them. A file is used only
+  when this core compiled it, for this protocol, from the same configuration and adapter model; its Contracts, hashes
+  and `/_contract` bytes are then the ones compiling would give. Any other file is ignored whole: the framework compiles
+  at startup exactly as without one and warns once (`AVENTARA_PREBUILT_STALE`), naming the Resources whose configuration
+  or model changed, or the version that differs. Without `prebuilt`, nothing changes. The build step that writes the
+  file arrives with `@aventara/build`.
+
+## 1.0.0-rc.3
+
+### Patch Changes
+
+- b38034d: An issue inside one entry of a to-many relation directive's array names that entry's index:
+  `["arguments", "data", "posts", "$update", 1, "data", "category"]`, where it read `[…, "$update", "data", "category"]`.
+  This holds for `$create`, `$connect`, `$connectOrCreate`, `$update`, `$delete`, `$upsert`, `$set` and `$disconnect`,
+  as the runtime's own nested-write paths already did. A directive given one object, not an array, keeps its issue at the
+  directive.
+- b38034d: An empty boolean node in the `where` of a write is refused, as an `undefined` there is, and nothing runs. In
+  `update.many`, `update.count`, `update.first`, `delete.many`, `delete.count`, `delete.first` and a to-many `$update`
+  or `$delete`, an empty `NOT: {}`, `AND: {}` or `[]`, `OR: []` or `AND`/`OR` entry `{}`, at any depth, answers
+  `422 A2004` with a `V1001` issue at the node:
+  `A boolean node must hold a condition here: an empty one matches every row, and the write would reach more rows.`
+  The ORM reads these as no condition, so `delete.count({ where: { NOT: {} } })` deleted every row, and `delete.first`
+  with one deleted an arbitrary row. A `where` that is `{}` itself still means every row, and reads pass empty nodes through as before. Field filters are unchanged: a scalar's `{}` and a
+  to-many relation's `{}` were already refused, and a to-one relation's `{}` matches the rows that have a related row.
+- b38034d: The error catalog (`AvErrorCatalog`, `ERRORS.md`) catches up with the code: `A2004` says a value the database refused
+  may stand at the value itself where the adapter can place it (a bigint its driver cannot bind) and may be too long for
+  its index; `V1001` lists an `undefined` in a filter, selector or cursor and an empty boolean node in a bulk write's
+  `where`; `V1004` lists a value the database refused as too long or out of range, a bigint a driver cannot bind among
+  them.
+- b38034d: A value write compute writes to a field the caller's layer hides is judged by that field's validators and Json shape
+  (the Core Contract's), and a value they refuse is the server's error: `500 A3000`, the issues to the `diagnostics` sink
+  on an `AvComputedValueError`, with nothing of the hidden field in the answer. Before, a shaped Json field hidden from
+  the layer was not judged at all, and a hidden field's own validators answered the caller `A2004` with an issue at the
+  hidden field's path. A layer that shows the field still answers `A2004` at it.
+- b38034d: On PostgreSQL, a `@unique` value too long for its index (an index row past the B-tree's limit of about 2704 bytes, SQLSTATE
+  `54000`) is answered `422 A2004`, not `500 A3001`: one `V1004` issue at `["arguments"]`, as a value too long for its
+  column already was. The adapter reads the SQLSTATE, never the message. The issue's message for a value too long now
+  reads `The database refused this value: it is longer than the database can hold for its column.`
+  (it said `longer than its column can hold`, which an index refusal is not).
+- b38034d: A Pick layer's list entry that names what its parent hid is refused with the sentence written inline too. Inline in
+  `createFramework` or `AventaraModule.forRoot`, the error is at the key and reads:
+
+  ```text
+  Type '["select"]' is not assignable to type '…'.
+    …
+      Property '"Error: client cannot expose 'Post.internalNote': hidden by root"' is missing in type '["select"]' but required in type '{ readonly "Error: client cannot expose 'Post.internalNote': hidden by root": true; }'.
+  ```
+
+  where it ended at `Type 'string' is not assignable to type 'never'.` at the list's element. A list entry is now typed as
+  an object keyed by the sentence, which no list has, so a configuration that is not inline (an `aventaraConfig()` handed
+  to `AventaraModule.forRootAsync`) ends at the same `Property '"Error: …"' is missing` line, where it ended at
+  `Type '"select"' is not assignable to type '"Error: …"'`. An entry written `true` or as an object is unchanged.
+
+## 1.0.0-rc.2
+
+### Patch Changes
+
+- A pipe may move a transaction step's `$ref`. A pipe sees a `$ref` as the reference it is, unresolved, and a
+  scoping pipe moves it: `({ args }) => ({ ...args, where: { AND: [args.where ?? {}, { published: true }] } })` puts
+  the caller's `where: { categoryId: cat.$ref("id") }` at `where.AND.0.categoryId`. The reference is now resolved
+  wherever the pipe put it: in an `AND`, an `OR` or a `NOT`, in a relation filter, under any operator, or copied from a
+  data value into another field or into a `$connect` key. Before, only a reference still standing where the caller
+  wrote it was resolved, and the step failed inside the transaction with `500 A3004` ("A server pipeline produced
+  invalid arguments."), the `diagnostics` sink naming the moved `$ref` (`V1006: Filter operator "$ref" is not
+available on field "categoryId"`, or `V1001` under `gte`). A moved reference is held to the rules a reference the
+  caller writes at that place is held to (where a `$ref` may stand, its source step, and its source field's type
+  against its new place): one that breaks them, such as a `$ref` moved into an `orderBy` or onto a field of another
+  type, is still the server's `A3004`, and an operation pipe's is now answered before the transaction opens. A
+  transaction pipe that moves a `$ref` is held to the same rules at its step. A literal a pipe writes where the caller
+  had a `$ref` now goes through that field's pipes, as any other value does.
+- A relation the request writes together with its reference field (`{ authorId: 1, author: { $connect: { id: 1 } } }`)
+  is refused by the framework validation, before any guard, pipe or compute stage runs and, in a plan, before the
+  transaction opens: `A2004`, `V1012` at the relation, as before. In rc.1 it was judged only after the guards, pipes
+  and write compute, so the developer's stages ran on the request first, and a plan opened its transaction and ran the
+  steps before it.
+- The field validators run after write compute. The order of a call is now the framework validation, the guards, the
+  pipes and field pipes, write compute, then the re-check: Aventara's own checks again on what the pipes and compute
+  produced, then the field validators (a Json field's shape among them) on every value the adapter will be handed,
+  then the interceptors and hooks. So a validator judges what is stored: a value a `compute.create` or
+  `compute.update` stage replaces is judged as computed, not as the caller sent it. In rc.1 the validators ran after
+  the pipes and before write compute, and a computed value was not judged by them. A plan step and a forced call still
+  judge before the transaction opens the literal values no write compute stage of their phase changes, so a caller's
+  refusal there opens nothing; the rest is judged at the step, and a refusal rolls the transaction back.
+- A computed write value its field's validators or Json shape refuse is answered `A2004` at the field, as any validator
+  refusal is (`{ code: "V1003", path: ["arguments", "data", "slug"], check: "string_format", … }`), at the top level,
+  in nested writes and in both branches of an upsert. In rc.1 such a value was not judged at all. A computed value of
+  the wrong type is still the server's error: `A3000`, its issues to the `diagnostics` sink on an
+  `AvComputedValueError`. `compute.read` values are output and are not judged.
+- A field computed on read with no `dependsOn` (the function form, `read: () => "stamped"`) has the Resource's
+  identifier read for it, the adapter's first one (with Prisma, the primary key when the model declares it first), so
+  each row comes back whatever else is selected; a `dependsOn` field is read as before. The answer holds exactly what
+  was selected: `{ select: ["stamp"] }` answers `[{ stamp: "stamped" }]` on every reading variant and in a write's
+  `select`, and inside a relation projection (`{ select: [{ category: { select: ["stamp"] } }] }`) the relation's row
+  is read and computed. In rc.1 a select of only such fields handed the adapter an empty projection, which Prisma
+  cannot express: `500 A3001` at the top level, and inside a relation the row was not read (`500 A3000`).
+- Every stage told a frozen view gets its own copy of a `Date` or a `Uint8Array`, which freezing cannot reach: a guard,
+  a field write guard, a pipe (its input and its `ctx.$args`), a field pipe, write compute (`data`, `value`,
+  `ctx.$args`), an interceptor, a before hook, each after hook (the result and `ctx.$args`), a filter and a Resource
+  transaction stage. Changing one in place changes only that stage's copy, never what a later stage is told, what is
+  written or what the caller receives; data changes only by returning it. In rc.1 every stage after write compute
+  shared one copy, so an after hook was told the `Date` a before hook had changed in place, and a guard or a pipe was
+  told the framework's own value. Arguments holding no such value are handed on as they are, at no cost per stage; a
+  copy is made only along the path to one (about 3 µs per stage for a record with a `Date` and a 64-byte
+  `Uint8Array`).
+- A `compute.read` stage is told the row as its own deep-frozen copy, a `Date` or a `Uint8Array` in it copied, like
+  every stage above; its field's `value` too. It returns its field's value: writing into `record` throws a
+  `TypeError`, answered `A3000` when the stage lets it through, as a pipe's write into its arguments is. The answer is
+  built from the row as read. In rc.1 the stage was told a mutable copy of the row and the answer was built from it,
+  so `record.title = "x"` changed the title every surface answered. The copy costs about 1.3 µs per row and stage
+  (1.8 µs with a `Date` and 64 bytes): a 100-row read with one computed field took 0.33 ms instead of 0.19 ms.
+- A record written through a relation cannot write that relation back. Inside a post created in `author.posts`,
+  `author` and `authorId` are what the write the post sits in supplies; inside a category created in a post's
+  `category`, `posts` is (`{ posts: { $create: { category: { $create: { posts: { $create: … } } } } } }`). The
+  framework validation refuses such a write before any guard, pipe or adapter work: `A2004` with one `V1012` issue at
+  the field (`["arguments", "data", "posts", "$create", "category", "$create", "posts"]`), message `Relation "posts"
+is the relation this Category is written through, from its other end ("Post.category"): the write it sits in
+supplies it.`, under every directive that carries a record (`$create`, `$connectOrCreate`, `$update`, `$upsert`),
+  to-one and to-many, and in a plan step. Only the edge walked is refused: a self-relation's other edge to the same
+  Resource stays writable. It is a type error on the façades, the builders and the generated client. In rc.1 the
+  Contract admitted these writes and the Prisma adapter answered `500 A3001`.
+- The Contract states each relation's other end, `inverse` on a relation field (`User.posts` has `inverse: "author"`),
+  as the adapter pairs them, and only where the layer shows that other end. The write axis has a third position,
+  `"loopback"`: that other end inside a record written through the relation. An adapter states whether a relation is
+  writable there as it states the other two positions (an arm that lists `"loopback"`, or an unqualified arm). A
+  Contract whose adapter states a pairing has a new hash; one that states none is unchanged, and so is an arm that
+  lists every position. `AvAdapterRelationField.inverse` is how an adapter states the pairing.
+- The Contract states which scalar fields hold each relation's reference: `referenceFields` on a relation field
+  (`Post.category` has `referenceFields: ["categoryId"]`; a composite reference lists every field, in the order the
+  data source pairs them with the target's key), on an optional relation as on a required one. It is absent on the
+  end that holds no reference (`Category.posts`), never an empty list. A layer keeps the fields it shows, in the
+  adapter's order, and leaves the property out when it shows none. The argument types now leave a loopback edge's
+  reference fields out for an optional relation too: `categoryId` in a post created in `Category.posts` is a type
+  error on the façades, the builders and the generated client, as the framework validation refuses it (`V1012`). In
+  rc.1 only a required relation's reference fields were left out, read off `createRequirements`.
+  `AvAdapterRelationField.referenceFields` is how an adapter states them. A Contract whose adapter states them has a
+  new hash.
+- A computed value is held to every named `format` its field declares, not only `uuid`: a `compute.read`,
+  `compute.create` or `compute.update` value that breaks `email`, `url`, `ipv4` or any other of zod's named formats
+  is the server's error, `A3000`, its `V1003` issue to the `diagnostics` sink on an `AvComputedValueError`, as a value
+  of the wrong type is. Each entry of a list field is judged. In rc.1 only `uuid` was checked and any other format
+  reached the caller unchecked. A relative path is no URL: compute an absolute one into a `format: "url"` field
+  (`` `https://example.com/p/${record.slug}` ``), or leave `format` out. A caller's own value is still held only to
+  `uuid` (a format describes the value; a rule on caller input is a validator, `AvZ.url()`).
+- `AvErrorCatalog` (and `ERRORS.md`): `A2004` and `V1012` list a record written through a relation that writes that
+  relation, or a field holding its reference, back. An adapter that meets one core cannot see (the layer hides the
+  relation's other end, so its Contract states no pairing) answers it with the new `V1012` sentence `The data source
+refused this nested write: a record written through a relation cannot write that relation or its reference fields
+back.`, which the response boundary keeps as it keeps a database refusal's.
+- A nested `$update` on a to-many relation is a bulk write: its one `data` applies to every related row its `where`
+  matches, so it takes what `update.many`'s `data` takes. A relation the adapter does not offer in a bulk write is
+  refused before the adapter with `A2004` and `V1006` at the member
+  (`["arguments", "data", "posts", "$update", "data", "category"]`, `Relation "category" is not writable during
+update.`), and is a type error on the façades, the builders and the generated client. A to-one `$update` is
+  unchanged. In rc.1 the Contract admitted it and the Prisma adapter refused it as `500 A3001`.
+- `AvErrorCatalog` (and `ERRORS.md`): `A3002` lists a transaction that expired or was closed under a step among its
+  causes, and `V1006` a relation write in a to-many `$update`'s `data`.
+- A relation a pipe or a compute stage writes together with its reference field is the server's error: the caller
+  gets `A3004` with the generic pipe-output message, and the `diagnostics` sink gets an `AvPipeOutputError` holding the
+  `V1012` issue and its path. In rc.1 the caller got `A2004`/`V1012`, as if it had sent both. A pipe's output that
+  breaks a field validator or a Json field's shape is still the caller's `A2004`: those are the developer's rules for
+  what may be stored, not Aventara's.
+- In a transaction plan, a `$ref` holding no object (`{ payload: { $ref: "x" } }`, `{ $ref: null }`) is answered as a
+  single call answers it: `A2004` with `V1006` at the `$ref` key (`Mutation directive "$ref" is not available on field
+"payload".`), at `["operations", i, "args", …, "$ref"]`. In rc.1 a plan read it as a malformed reference:
+  `A2007` with `V1016` at `…, "$ref", "operation"`. A `$ref` holding an object is still a reference, and a broken one
+  still `A2007`.
+- `AvJsonValue` admits a key holding `undefined`, so an object with optional properties
+  (`{ readonly note?: string }`) is assignable to a `json` field; the key is left out at runtime. In rc.1 the type
+  refused it. An array element holding `undefined` is still a type error (at runtime it is `null`).
+- `AvErrorCatalog` (and `ERRORS.md`): `V1001` lists two directives in one scalar action object among its causes,
+  `A2004` a computed value the validators refuse, `A3000` a computed value of the wrong type, and `A3004` a reference
+  a pipe or write compute wrote together with its relation.
+- A scalar action object holds one directive. `{ score: { $increment: 1, $decrement: 2 } }` is refused before the
+  adapter with `A2004` and `V1001` at the field (`Scalar mutation action objects may contain only one directive.`),
+  and is a type error on the façades, the builders and the generated client. In rc.1 it passed validation and the
+  ORM refused it: `500 A3001`. A directive the field does not offer is still `V1006` at the directive.
+- An `undefined` inside a `json` value is what JSON makes of it, on every surface: a key holding it is left out and an
+  array element holding it (or a hole) is `null`, as `JSON.stringify` writes them, so
+  `{ meta: { a: undefined, b: [undefined] } }` stores `{"b":[null]}` through `framework.application`,
+  `framework.client`, `framework.execute`, the ctx executor and a plan step, as it does through the generated client
+  and over HTTP. The same holds in a `json` filter operand, and an operation's fingerprint is computed from the value
+  as JSON carries it. In rc.1 the in-process surfaces refused the key with `A2004`/`V1001`, and a hole in an array
+  inside a `json` value was dropped, moving the elements after it down one index.
+- `DATABASE_REFUSALS` has two more sentences an adapter answers a refused value with, both `V1004`:
+  `The database refused this value: it divides by zero.` and `The database refused this value: the write computes no
+value for a column that requires one, as a division by zero does.`
+- `AvErrorCatalog`'s `A2004` entry (and `ERRORS.md`) covers a value the database refused: an adapter answers it with
+  one issue at `["arguments"]`, `V1004` for a length or range, `V1001` otherwise, and the issue's message says what
+  the database refused (`The database refused this value: its text cannot contain the NUL character (U+0000).`).
+  The response boundary keeps such a message only when it is core's own sentence for that refusal under its own
+  code; every other adapter issue message is still replaced by the code's published text.
+- An `appTx` or `clientTx` builder no longer runs a getter inside an object carrying `$ref` when it copies a step's
+  arguments: it mirrors the object as `framework.executeTransaction` does, and the run refuses it the same way
+  (`A2004`, `V1001` at the extra key). In rc.1 the builder ran the getter at the call.
+- `AvProtocol.bind(framework).handleOperation` copies a `{ kind: "parsed" }` body at the call, before it awaits the
+  state seed, so a host that changes its parsed object after the call changes nothing, and a body that cannot be
+  copied is refused at the call (`A2004`, `V1001` at its path). In rc.1 the copy was taken after the first await.
+- `AvProtocol.bind(framework).handleTransaction` takes a `{ kind: "parsed" }` plan at the call, before it awaits the
+  state seed, as `framework.executeTransaction` takes one: the plan's structure is mirrored by its property
+  descriptors, so no getter the plan validator refuses runs, and each step's arguments are copied, its `$ref` control
+  objects mirrored. A host that changes the plan after the call changes nothing, and a step whose arguments cannot be
+  copied is answered at its turn (`A2004`, `V1001` at its path). In rc.1 the plan was read after the first await, so a
+  step changed after the call failed its fingerprint (`A2007`, `V1017`) or ran as changed.
+- `framework.appTx.$sql` mirrors a `$ref` control object among its values as the builders mirror one in a step's
+  arguments: no getter inside it runs, and a malformed one is refused as `framework.executeTransaction` refuses it
+  (`A2004`, `V1001` at its extra key). A well-formed hand-written `{ $ref: { operation, fingerprint, path } }` is read
+  as a reference to that step's field, held to the same checks as one in an operation step. In rc.1 the value was
+  copied by value at the call, which ran its getters, and bound as JSON text.
+- An `orderBy` value that is no order says what is wrong with it. A `$ref` there is refused with `A transaction
+reference cannot stand in orderBy: order "email" by "asc", "desc" or { sort, nulls }.`, and a malformed null-order
+  object with `Null ordering for "email" must be exactly { sort: "asc" | "desc", nulls: "first" | "last" }.`. The
+  code (`V1001`) and path are unchanged; rc.1 answered both with `Extended null ordering for "email" must contain sort
+and nulls.`
+- Each filter operator object stands alone: a `mode` or `path` qualifies only the operators written beside it, and an
+  object under `not` has its own. A `mode` or `path` with no comparing operator beside it is refused with `A2004` and
+  `V1001` at that key, before the adapter, with the message `mode on field "title" qualifies no operator: write it next
+to the operator it applies to (inside "not" to apply to a negated one).`. That covers `{ mode: "insensitive", not: {
+contains: "x" } }` (write `{ not: { contains: "x", mode: "insensitive" } }`), `{ path: ["label"], not: { … } }`
+  (write the `path` inside the `not`), and a `mode` or `path` alone, such as `{ title: { mode: "default" } }`, which
+  reached the adapter as no condition and matched every row. A value under `not` (`{ path: ["label"], not: "x" }`)
+  compares at its own level and is accepted. The typed calls refuse the same objects at compile time.
+- An error catalog: `AvErrorCatalog`, exported from `@aventara/core`, maps every outcome code (`A1000` to `A4002`),
+  validation code (`V1000` to `V1021`) and startup code (`CONFIG_…`, `DISCOVERY_…`, `COMPILER_…`) to its `kind`,
+  `message`, `cause`, `fix` and `docs` URL, the code's entry on the error-codes page
+  (`https://aventara-framework.vercel.app/docs/error-codes#a2004`: the code in lower case). The package also ships the
+  catalog as `ERRORS.md`, one table per kind. New names: `AvErrorCatalog` (a value and its type),
+  `AvErrorCatalogEntry`, `AvErrorCatalogCode`, `AvErrorKind`.
+- A startup diagnostic links to its documentation: every entry of `AvConstructionError`'s `diagnostics` is now
+  `{ code, path, message, docs }`, where `docs` is `AvErrorCatalog[code].docs`. Codes, paths and messages are
+  unchanged. A test that compares a whole diagnostic with `toEqual` now sees the `docs` key.
+- A spread of the arguments compiles on a Resource with a `json` field. A variant pipe returning
+  `{ ...args, data: { ...args.data, slug } }`, or a guard spreading `ctx.$args.data`, was TS2589 ("Type instantiation
+  is excessively deep and possibly infinite"), inline and in `defineResource`: the deep read-only typing re-entered
+  `AvJsonValue` through its array member without end. `AvDeepReadonly` now maps an array through its own
+  `readonly …[]` branch (a tuple keeps its positions); the types a stage is told are unchanged, and a wrong value in a
+  pipe's return is still a compile error.
+- An explicit `undefined` in write data means the key was not sent, as Prisma reads its data. In a create's or
+  update's `data`, an upsert's `create` and `update`, each record of a bulk create and every nested create or update,
+  `{ name: undefined }` is now `{}`: on a create an optional field takes what leaving it out gives it and a required one
+  is missing (`A2004` with `V1000` at its path); an update leaves the field untouched. Before, it was refused as
+  `A2004`/`V1001` "Value must be a string.". The same holds for the in-process façades, ctx calls, `appTx` plans and
+  the arguments a pipe or a transaction pipe returns: an optional field a pipe sets to `undefined` is omitted, a
+  required one is a dropped field (`A3004`). Filters and unique selectors are unchanged: `where: { id: undefined }` is
+  still refused (`V1001`), so an `update.many` or `delete.many` never widens to every row. The refusal says why, in the
+  generated client's words where they apply in process: `Value must not be undefined: it would be left out, and the
+request would reach more rows.` (it said what the value is not, such as `Value must be a string.`). This holds at
+  any depth of a filter, a unique selector or a cursor: an operator's operand, an `in` entry, an `AND` entry, a `NOT`,
+  a relation filter, a relation's `where` under `select` or `include`, and a nested write's `$connect`, `$disconnect`,
+  `$set` and `$update` selectors. Code and path are unchanged.
+- An `undefined` `mode`, `isEmpty` or `path` in a filter is refused (`A2004` with `V1001` at the operand), as every
+  other operator's `undefined` already was. These three are passed to the adapter as given, so
+  `{ tags: { isEmpty: undefined } }` reached it as no condition and matched every row.
+- A filter operand of the wrong type is refused (`A2004` with `V1001` at the operand) before the adapter is called:
+  `mode` takes `"default"`, `"sensitive"` or `"insensitive"`, `isEmpty` a boolean, `path` an array of strings (a wrong
+  entry is named at its index) and a `json` field's `stringContains`, `stringStartsWith` and `stringEndsWith` a string.
+  Before, a value such as `mode: "loud"`, `isEmpty: 3`, `path: "a.b"` or `stringContains: 3` from an HTTP or MCP caller
+  reached the adapter, and the ORM refused it as `A3001`. The typed calls and the generated client type these operands
+  the same way: `mode`, `isEmpty` and `path` were `unknown`, and a `json` `string*` operand accepted any non-null JSON
+  value.
+- Filter modes are advertised per field. `mode` has three values: `"default"` is the database's own comparison and
+  every field that offers `mode` takes it; `"sensitive"` and `"insensitive"` are an explicit promise, taken only where
+  the field's new `capabilities.filterModes` lists them (and, on a `json` field that offers `path`,
+  `capabilities.pathFilterModes` when the filter names a `path`). The Contract and the ClientContract carry both lists,
+  configuration never names them, and a layer that hides `mode` or `path` drops them. A mode the field does not offer is
+  refused like an unadvertised operator: `A2004` with `V1006` at the `mode`, `Filter mode "insensitive" is not available
+on field "email".`; the typed calls offer only the field's modes, and on a `json` field the list that applies: an
+  operator object with `path` takes `pathFilterModes`, one without it `filterModes`. On Postgres
+  `where: { meta: { stringContains: "x", mode: "insensitive" } }` is a compile error (`Property 'path' is missing`),
+  and the same filter with `path: ["label"]` compiles. Contract hashes change for every field that offers `mode`:
+  regenerate the client.
+- A `where`, `limit`, `offset` or `cursor` argument set to `undefined` is refused with a message that says what to
+  write: `where must not be undefined: leave the key out to mean no filter.` (and the same for `limit`, `offset` and
+  `cursor`), at the top level and in a relation under `select` or `include`. The code and path are unchanged
+  (`A2004` with `V1001` at the key; `V1009` for `cursor`). A wrong value keeps its message, such as
+  `where must be an object.` or `limit must be a non-negative integer.`.
+- 9366e16: MCP endpoint polish:
+
+  - A request with no bearer credentials (no `Authorization` header, or another scheme such as `Basic`) is answered
+    `401` with `WWW-Authenticate: Bearer resource_metadata="…"` and no error code, as RFC 6750 §3.1 asks; its body no
+    longer says "Missing Authorization header". A bad bearer token keeps `error="invalid_token"`.
+  - A `mcp.authorization.verify` that throws is still answered `401`, and is now reported to the `diagnostics` sink as
+    an `AvMcpDiagnostic` holding the error.
+  - With `mcp` configured and `@aventara/mcp` missing, the startup error names the command that installs it at the
+    installed `@aventara/core`'s exact version: `npm install --save-exact @aventara/mcp@<version>`.
+
+- 9366e16: A variant's guards, pipes and filters may leave out of a create exactly the fields your configuration's
+  `compute.create` stages fill. Write compute runs after those stages, so a field it fills may still be missing when
+  they run, and a pipe may return a create without it: in a pipe, `args.data.slug` is `string | undefined` when
+  `slug` has a `compute.create`, and every other required field stays required. A stage's type cannot read the
+  configuration it is written in, so the adapter's generate step reads the configuration's type (`aventara:prepare`
+  passes `--config src/aventara.config.ts`) and writes which fields each layer computes into the model's type. A
+  stage counts the layers whose compute runs for its requests: a root stage the root's, the application's, the
+  client's and the agent's; an `application` or `client` stage the root's and its own (and the agent's, when the agent
+  extends it); an `agent` stage the root's, its own and its parent's. This holds inline in `createFramework`, in
+  `AventaraModule`'s `config`, and in `defineResource` blocks and their overlays, for a create's `data`, an upsert's
+  `create` and a nested create. Values are still typed. Hooks and interceptors run after compute and keep every
+  requirement. A model generated without a configuration lifts every create requirement in those stages, as before.
+- Breaking: a create missing a required field is refused before any pipeline stage runs. The framework's own
+  validation (types, unknown fields, structure) now also checks that every create position holds the fields its
+  layer requires (`A2004`/`V1000` at the field), before the guards, where it ran after the pipes and compute. A field a
+  `compute.create` stage fills is not required there and stays optional until compute. So a guard or a pipe is always
+  told a create that holds every other required field, which is what their types say, and a pipe can no longer fill a
+  required field the caller left out: give that field a `compute.create` stage or a database default. This holds for
+  a create's `data`, every bulk record, an upsert's `create` branch and nested creates, and for each step of a
+  transaction before it opens (a `$ref` counts as a value). Which fields are required is already public in the client
+  contract, so the earlier answer reveals nothing new.
+- A required create field the caller sent and a pipe then dropped is now the server's error: the caller gets `A3004`
+  with the generic pipe-output message, and the `diagnostics` sink gets an `AvPipeOutputError` holding the `V1000`
+  issue. Until now the caller got `A2004`/`V1000`, as if it had left the field out.
+- New: `AvConfigComputedFields`, the shape of that statement: per layer (`root`, `application`, `client`, `agent`),
+  per Resource, the fields with a `compute.create` and a `compute.update` stage, and the layer the agent extends. The
+  adapter hands it to the framework as `AvAdapter.computedFields`, and the framework compares it with the
+  configuration it starts with. When they differ (you changed a compute stage and did not run `aventara:prepare`),
+  startup emits one warning, `AVENTARA_STALE_GENERATED_TYPES`, naming each difference:
+
+  ```text
+  (node:1234) [AVENTARA_STALE_GENERATED_TYPES] AventaraWarning: generated types are stale: run aventara:prepare. The computed fields the pre-compute stages are typed with differ from the configuration's:
+    - computed in the configuration, not in the types: root User.handle (update)
+  ```
+
+  It is a warning and changes nothing at runtime: the statement only types the stages.
+
+- A `compute.create` stage that returns `undefined` for a field a create cannot do without (not nullable, no default,
+  not generated) and that the caller did not send now fails as the server's error: the caller gets `A3000`, and the
+  `diagnostics` sink gets an `AvComputedValueError` whose message is
+  `compute.create on <Resource>.<field> returned undefined for a required field`. The field left the create
+  requirements because the stage fills it; until now the create reached the database without it, and the
+  database's refusal answered `A3001`. This holds for a create's `data`, every record of a bulk create, an upsert's `create`
+  branch and a nested create. A reference field counts as missing only when the record writes neither its relation nor
+  every reference field, and a nested create's field the parent supplies is never missing. Updates are not checked:
+  nothing is required of an update.
+- 9366e16: A Pick layer (`exposed: false`) that names what its parent hid now says why in the type error. A Resource, field,
+  family, variant or capability the root (or, for the agent, the layer it extends) hid is typed as
+  `readonly ["Error: client cannot expose 'Post.internalNote': hidden by root"]`, so the error TypeScript reports through
+  the scaffold's `aventaraConfig()` and `AventaraModule.forRootAsync` ends at:
+
+  ```text
+  The types of 'client.exemptions.resources.Post.fields.internalNote' are incompatible between these types.
+    Type 'readonly ["select"]' is not assignable to type 'readonly ["Error: client cannot expose 'Post.internalNote': hidden by root"]'.
+      Type '"select"' is not assignable to type '"Error: client cannot expose 'Post.internalNote': hidden by root"'.
+  ```
+
+  where it ended at `Type 'readonly ["select"]' is not assignable to type 'never'.` An entry written `true` names it
+  the same way (`Type 'boolean' is not assignable to type 'readonly ["Error: client cannot expose 'Comment': hidden by
+root"]'.`), where it ended at `Type 'true' is not assignable to type 'never'.`. Written inline in `createFramework`
+  or `AventaraModule.forRoot`, the error at a `true` entry starts with the sentence:
+  `Type 'true' is not assignable to type 'true & (readonly ["Error: client cannot expose 'Comment': hidden by root"] & …)'`.
+  An inline literal's list still reads `not assignable to type 'never'` at the key.
+
 ## 1.0.0-rc.1
 
 ### Patch Changes
@@ -445,7 +1363,6 @@
               nullable: false,
               list: false,
               lifecycle: ["VIRTUAL"],
-              format: "url",
             },
             pipelines: {
               compute: {
@@ -943,15 +1860,15 @@
   does: they resolve the data and throw every failure as the `AvError` subclass of its code's class. The subclasses
   are new exports of `@aventara/core`, chosen by one code→class table the generated client reads too:
 
-  | Class                     | Codes                                       |
-  | ------------------------- | ------------------------------------------- |
-  | `AvProtocolError`         | A2000, A2001, A2002, A2006, A2010–A2012     |
-  | `AvNotFoundError`         | A2003                                       |
-  | `AvValidationError`       | A2004, A2007, A2009                         |
-  | `AvContractMismatchError` | A2005                                       |
-  | `AvConflictError`         | A2008, A2013, A2014                         |
-  | `AvInternalError`         | A3000–A3004                                 |
-  | `AvAuthError`             | A4000–A4002                                 |
+  | Class                     | Codes                                   |
+  | ------------------------- | --------------------------------------- |
+  | `AvProtocolError`         | A2000, A2001, A2002, A2006, A2010–A2012 |
+  | `AvNotFoundError`         | A2003                                   |
+  | `AvValidationError`       | A2004, A2007, A2009                     |
+  | `AvContractMismatchError` | A2005                                   |
+  | `AvConflictError`         | A2008, A2013, A2014                     |
+  | `AvInternalError`         | A3000–A3004                             |
+  | `AvAuthError`             | A4000–A4002                             |
 
   `instanceof` works, and `error.code` and `error.cause` are what the envelope carried (a transaction's
   `cause.operation` names the failing step). A stage's ctx calls throw the same subclasses. `framework.execute`,
@@ -959,7 +1876,10 @@
 
   ```ts
   // Before
-  const res = await framework.application.Post.find.unique({ where: { id }, select: ["id", "title"] });
+  const res = await framework.application.Post.find.unique({
+    where: { id },
+    select: ["id", "title"],
+  });
   if (res.code !== "A1000") return null;
   return res.data;
   const result = await framework.transaction([user, post]);
@@ -967,7 +1887,10 @@
 
   // After
   try {
-    return await framework.application.Post.find.unique({ where: { id }, select: ["id", "title"] });
+    return await framework.application.Post.find.unique({
+      where: { id },
+      select: ["id", "title"],
+    });
   } catch (error) {
     if (error instanceof AvNotFoundError) return null;
     throw error;
@@ -978,7 +1901,7 @@
   The façades' result types follow: a call resolves the operation's slot (`T`, or `T | null` for a `first`), and
   `framework.transaction` resolves its results tuple. `AvOperationCall` loses its `Settlement` parameter (every direct
   call settles to data), and `AvError` takes its code as a type parameter (`AvError<"A2003">`); `new AvError(code,
-  cause)` is unchanged.
+cause)` is unchanged.
 
   New: a stage registered at a variant (`resources.<R>.operations.<family>.<variant>.pipelines`) gets its operation's
   arguments typed. `ctx.$args` is that operation's arguments, deep read-only, so a write is a type error and the editor
@@ -1017,8 +1940,12 @@
   relation neither way or both ways:
 
   ```ts
-  await framework.application.Post.create.one({ data: { title: "Hi", authorId } }); // ok
-  await framework.application.Post.create.one({ data: { title: "Hi", author: { $connect: { id } } } }); // ok
+  await framework.application.Post.create.one({
+    data: { title: "Hi", authorId },
+  }); // ok
+  await framework.application.Post.create.one({
+    data: { title: "Hi", author: { $connect: { id } } },
+  }); // ok
   await framework.application.Post.create.one({ data: { title: "Hi" } }); // type error: `author` or `authorId`
   await framework.application.Post.create.one({ data: { authorId } }); // type error: `title`
   ```
@@ -1340,7 +2267,7 @@
   `framework.transaction`, `framework.executeTransaction` and `POST /_transactions` alike. A single call is unchanged
   (`["arguments", …]`). If your code reads `issue.path` from a transaction's answer, drop the `"operations", i, "args"`
   prefix to get the path inside that step's arguments. `@aventara/testing`'s protocol corpus row "a client-hidden
-  field — /_transactions" and `fixtures/protocol-v1.json` carry the new path.
+  field — /\_transactions" and `fixtures/protocol-v1.json` carry the new path.
 - d43d1cc: **Types:** `diagnostic.deliberate` now type-checks on any `FrameworkDiagnostic`, without checking
   `diagnostic.kind` first, so a `diagnostics` sink can log it for every report. It is `true` only on an `"operation"`
   diagnostic for a `FrameworkError` you threw on purpose with an `A3xxx` code, and always absent on a `"transaction"`