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

package/CHANGELOG.md

@@ -1,5 +1,2071 @@
 # @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
+
+- 800123b: New: `framework.appTx.$sql`, a developer SQL step in an application transaction. Write it as a tagged template,
+  `` framework.appTx.$sql<Row>`select pgmq.send('jobs', jsonb_build_object('postId', ${post.$ref("id")}))`  ``, and put it in
+  `framework.transaction([...])` beside the other steps. Every interpolated value is a bound parameter, never SQL text:
+  strings, numbers, booleans, `bigint`, `null`, `Date`, `Decimal`, bytes, JSON values (bound as JSON text, so cast them
+  with `::jsonb`), and a `$ref` to an earlier step's field, read after that step ran. The statement runs in order in the
+  same database transaction, so a failure anywhere rolls everything back, and its rows are that step's entry in the
+  result, typed `Row[]` (or `unknown[]`). A plain-string call is refused, a later step cannot `$ref` a SQL step's rows,
+  and no pipeline runs around it.
+
+  It is server-side only: `clientTx` has no `$sql`, the ClientContract and its hash are unchanged, and `/_transactions`
+  cannot carry one.
+
+  The Prisma 7 adapter runs it with `$queryRaw` in its tagged form on the transaction client. A raw query's failure is
+  `P2010` on Prisma 7.10.0: a uniqueness or foreign-key violation answers `A2008`, anything else `A3001`. The rule is now
+  that Aventara never writes raw SQL itself, and developer SQL only goes through this bound template.
+
+  Adapter authors: an adapter declares `sqlStatements: true`, has an `executeSql` of its own (a plain statement, outside
+  any transaction: a stage's `ctx.$sql` there) and gives its transaction executor one too (`AvAdapter.executeSql`,
+  `AvAdapterTransactionExecutor`, `AvAdapterSqlStatement` in `@aventara/core/internal`). Without the declaration, a plan
+  with a SQL step is refused with `A2002`. The Prisma 7 adapter runs a statement outside a transaction with `$queryRaw`
+  on the base client, and declares `sqlStatements` with every driver.
+
+- 8bb1d6a: Breaking: public type and class names take the `Av` prefix. Every public type and class is now `Av` plus what
+  it is, with a namespace only where the bare name would be ambiguous: configuration types are `AvConfig…`
+  (`AvConfig`, `AvConfigLayer`, `AvConfigResource`, …) and the three Contracts are `AvContract…` (`AvContractCore`,
+  `AvContractApplication`, `AvContractClient`). Functions keep their names (`createFramework`, `createFakeAdapter`,
+  `createPrismaAdapter`, `defineClientConfig`, `env`), and so do the names that already started with `Av`,
+  `AventaraModule`, `AventaraModuleOptions` and `AventaraModuleAsyncOptions`. There are no
+  aliases: replace each old name with the new one.
+
+  Three names merged or left:
+
+  - `PipelineContext` and `ComputeContext` (which was the same type) are one name, `AvContext`. A compute stage
+    now gets its own read-only ctx, `AvComputeContext` (see the ctx entry below).
+  - `ComputedRead` is `AvComputeRead`, the one name of a read compute stage: a function, or `{ compute, dependsOn }`.
+    `ComputeOnRead`, the bare function type, is no longer exported; `AvComputeRead` accepts the function as it is.
+  - `defineFields` and `FrameworkFieldsShape` are removed; `defineResource` replaces them (below).
+
+  `defineResource` replaces `defineFields`. A Resource's configuration, its root block and its overlay blocks, can
+  live in its own module and be spread into each layer's `resources` tree:
+
+  ```ts
+  export const submission = defineResource<Model>()(
+    "Submission",
+    {
+      pipelines: { guards: [signedIn] },
+      fields: { title: { pipelines: { pipes: [trim] } } },
+    },
+    { client: { fields: { title: { pipelines: { validators: [AvZ.maxLength(80)] } } } } },
+  );
+
+  // aventara.config.ts
+  resources: { ...submission.root, ...payment.root },
+  client: { resources: { ...submission.client } },
+  ```
+
+  It returns `{ root, application?, client? }`, each `{ Submission: block }`; a layer given no block is left out. The
+  root block is typed exactly as `resources.Submission` is typed in place: field definitions are checked against what
+  the adapter discovered, stages are typed for the Resource, and a key no level admits is a type error at the key.
+  Each overlay block is typed as `application.resources.Submission` or `client.resources.Submission` is in place,
+  against the root block: it may name a field the root block defines, and a `definition` in it is a type error (and
+  `CONFIG_FORBIDDEN_IN_OVERLAY` at startup). Spread, the configuration is the inline one: the same Contracts and
+  ClientContract hash. A field `definition` that `defineFields` returned now sits at
+  `fields.<field>.definition` inside the block.
+
+  The generated client's names follow the same rule. Regenerate with `avclient generate`; then rename the
+  imports from `AvClient.ts`:
+
+  | Before                  | After                     |
+  | ----------------------- | ------------------------- |
+  | `AuthError`             | `AvAuthError`             |
+  | `CallOptions`           | `AvCallOptions`           |
+  | `Cause`                 | `AvCause`                 |
+  | `ConflictError`         | `AvConflictError`         |
+  | `ContractMismatchError` | `AvContractMismatchError` |
+  | `Decimal`               | `AvDecimal`               |
+  | `Fetch`                 | `AvFetch`                 |
+  | `FrameworkError`        | `AvError`                 |
+  | `InternalError`         | `AvInternalError`         |
+  | `NotFoundError`         | `AvNotFoundError`         |
+  | `Operation<T>`          | `AvOperation<T>`          |
+  | `OperationCode`         | `AvOperationCode`         |
+  | `ProtocolError`         | `AvProtocolError`         |
+  | `TransportError`        | `AvTransportError`        |
+  | `ValidationCode`        | `AvValidationCode`        |
+  | `ValidationError`       | `AvValidationError`       |
+  | `ValidationIssue`       | `AvValidationIssue`       |
+
+  An enum whose name is one of these now walks the rename ladder (`AvDecimal` → `AvDecimalEnum`); an enum named
+  `Decimal` is emitted as `Decimal`.
+
+  `@aventara/core`, every renamed export:
+
+  | Before                                | After                              |
+  | ------------------------------------- | ---------------------------------- |
+  | `Adapter`                             | `AvAdapter`                        |
+  | `AdapterDiscoveryDiagnostic`          | `AvAdapterDiscoveryDiagnostic`     |
+  | `AdapterDiscoveryDiagnosticCode`      | `AvAdapterDiscoveryDiagnosticCode` |
+  | `AdapterModel`                        | `AvAdapterModel`                   |
+  | `AddedFieldDefinition`                | `AvConfigAddedFieldDefinition`     |
+  | `AfterHook`                           | `AvAfterHook`                      |
+  | `AnyFrameworkConfig`                  | `AvConfigAny`                      |
+  | `AnyLayerConfig`                      | `AvConfigLayerAny`                 |
+  | `AnyResourcesBlock`                   | `AvConfigResourcesAny`             |
+  | `ApplicationContract`                 | `AvContractApplication`            |
+  | `ApplicationScalarForms`              | `AvApplicationScalarForms`         |
+  | `BeforeHook`                          | `AvBeforeHook`                     |
+  | `BuiltInScalar`                       | `AvBuiltInScalar`                  |
+  | `Cause`                               | `AvCause`                          |
+  | `ClientContract`                      | `AvContractClient`                 |
+  | `ClientContractProtocol`              | `AvContractClientProtocol`         |
+  | `ComputedRead`                        | `AvComputeRead`                    |
+  | `ComputeOnCreate`                     | `AvComputeCreate`                  |
+  | `ComputeOnUpdate`                     | `AvComputeUpdate`                  |
+  | `ConfigDiagnostic`                    | `AvConfigDiagnostic`               |
+  | `ConfigDiagnosticCode`                | `AvConfigDiagnosticCode`           |
+  | `ConfigFieldKey`                      | `AvConfigFieldKey`                 |
+  | `ConfigLayer`                         | `AvConfigLayerName`                |
+  | `Contract`                            | `AvContract`                       |
+  | `ContractCompilerDiagnostic`          | `AvContractCompilerDiagnostic`     |
+  | `ContractCompilerDiagnosticCode`      | `AvContractCompilerDiagnosticCode` |
+  | `ContractHash`                        | `AvContractHash`                   |
+  | `ContractLimits`                      | `AvContractLimits`                 |
+  | `ContractProtocol`                    | `AvContractProtocol`               |
+  | `CoreContract`                        | `AvContractCore`                   |
+  | `CreateDataInput`                     | `AvCreateDataInput`                |
+  | `CursorInput`                         | `AvCursorInput`                    |
+  | `Decimal`                             | `AvDecimal`                        |
+  | `DeferredOperationCall`               | `AvDeferredOperationCall`          |
+  | `EffectiveFieldKey`                   | `AvEffectiveFieldKey`              |
+  | `EnumDefinition`                      | `AvEnumDefinition`                 |
+  | `ExactFrameworkConfig`                | `AvConfigExact`                    |
+  | `ExecutionOptions`                    | `AvExecutionOptions`               |
+  | `Field`                               | `AvField`                          |
+  | `FieldComputeConfig`                  | `AvFieldCompute`                   |
+  | `FieldKey`                            | `AvFieldKey`                       |
+  | `FieldPipe`                           | `AvFieldPipe`                      |
+  | `FieldWriteGuard`                     | `AvFieldGuard`                     |
+  | `Filter`                              | `AvFilter`                         |
+  | `Framework`                           | `AvFramework`                      |
+  | `FrameworkConfig`                     | `AvConfig`                         |
+  | `FrameworkConstructionDiagnostic`     | `AvConstructionDiagnostic`         |
+  | `FrameworkConstructionError`          | `AvConstructionError`              |
+  | `FrameworkConstructionStage`          | `AvConstructionStage`              |
+  | `FrameworkContracts`                  | `AvContracts`                      |
+  | `FrameworkDiagnostic`                 | `AvDiagnostic`                     |
+  | `FrameworkDiagnosticsSink`            | `AvDiagnosticsSink`                |
+  | `FrameworkError`                      | `AvError`                          |
+  | `FrameworkExemptionsConfig`           | `AvConfigExemptions`               |
+  | `FrameworkFamilyConfig`               | `AvConfigFamily`                   |
+  | `FrameworkFieldDefinition`            | `AvConfigFieldDefinition`          |
+  | `FrameworkFieldLifecycleTrait`        | `AvConfigFieldLifecycleTrait`      |
+  | `FrameworkLayerConfig`                | `AvConfigLayer`                    |
+  | `FrameworkLayerKind`                  | `AvConfigLayerKind`                |
+  | `FrameworkLimitsConfig`               | `AvConfigLimits`                   |
+  | `FrameworkMisuseEvent`                | `AvMisuseEvent`                    |
+  | `FrameworkMisuseSink`                 | `AvMisuseSink`                     |
+  | `FrameworkOperationsConfig`           | `AvConfigOperations`               |
+  | `FrameworkOperationsExemption`        | `AvConfigOperationsExemption`      |
+  | `FrameworkOverlayFieldConfig`         | `AvConfigOverlayField`             |
+  | `FrameworkRelationFieldExemption`     | `AvConfigRelationFieldExemption`   |
+  | `FrameworkResourceConfig`             | `AvConfigResource`                 |
+  | `FrameworkResourceExemption`          | `AvConfigResourceExemption`        |
+  | `FrameworkResourceFieldsConfig`       | `AvConfigResourceFields`           |
+  | `FrameworkResourceKey`                | `AvConfigResourceKey`              |
+  | `FrameworkResourcesConfig`            | `AvConfigResources`                |
+  | `FrameworkResourceTransactionsConfig` | `AvConfigResourceTransactions`     |
+  | `FrameworkRootFieldConfig`            | `AvConfigRootField`                |
+  | `FrameworkScalarFieldExemption`       | `AvConfigScalarFieldExemption`     |
+  | `FrameworkScalarTypeRef`              | `AvConfigScalarTypeRef`            |
+  | `FrameworkVariantConfig`              | `AvConfigVariant`                  |
+  | `Guard`                               | `AvGuard`                          |
+  | `Identifier`                          | `AvIdentifier`                     |
+  | `IncludeInput`                        | `AvIncludeInput`                   |
+  | `Interceptor`                         | `AvInterceptor`                    |
+  | `JsonValue`                           | `AvJsonValue`                      |
+  | `KnownFieldDefinition`                | `AvConfigKnownFieldDefinition`     |
+  | `LifecycleTrait`                      | `AvLifecycleTrait`                 |
+  | `NullsOrder`                          | `AvNullsOrder`                     |
+  | `Operation`                           | `AvOperation`                      |
+  | `OperationArgumentMap`                | `AvOperationArgumentMap`           |
+  | `OperationArgumentsFor`               | `AvOperationArgumentsFor`          |
+  | `OperationAvailability`               | `AvOperationAvailability`          |
+  | `OperationCall`                       | `AvOperationCall`                  |
+  | `OperationCode`                       | `AvOperationCode`                  |
+  | `OperationDiagnostic`                 | `AvOperationDiagnostic`            |
+  | `OperationErrorCode`                  | `AvOperationErrorCode`             |
+  | `OperationFailureResponse`            | `AvOperationFailureResponse`       |
+  | `OperationFamily`                     | `AvOperationFamily`                |
+  | `OperationGrammar`                    | `AvOperationGrammar`               |
+  | `OperationIdentity`                   | `AvOperationIdentity`              |
+  | `OperationNoMatchResponse`            | `AvOperationNoMatchResponse`       |
+  | `OperationReferenceSurface`           | `AvOperationReferenceSurface`      |
+  | `OperationResponse`                   | `AvOperationResponse`              |
+  | `OperationResultFor`                  | `AvOperationResultFor`             |
+  | `OperationSlot`                       | `AvOperationSlot`                  |
+  | `OperationSuccessCode`                | `AvOperationSuccessCode`           |
+  | `OperationSuccessDataCode`            | `AvOperationSuccessDataCode`       |
+  | `OperationSuccessResponse`            | `AvOperationSuccessResponse`       |
+  | `OperationVariant`                    | `AvOperationVariant`               |
+  | `OperationVariantScopes`              | `AvOperationVariantScopes`         |
+  | `OrderByEntry`                        | `AvOrderByEntry`                   |
+  | `OrderByInput`                        | `AvOrderByInput`                   |
+  | `PaginationCapability`                | `AvPaginationCapability`           |
+  | `Pipe`                                | `AvPipe`                           |
+  | `PipelineConfig`                      | `AvPipeline`                       |
+  | `PipelineContext`                     | `AvContext`                        |
+  | `PipelineTransportContext`            | `AvTransportContext`               |
+  | `ProjectionEntry`                     | `AvProjectionEntry`                |
+  | `ProjectionScope`                     | `AvProjectionScope`                |
+  | `ProjectionScopes`                    | `AvProjectionScopes`               |
+  | `ReferenceableField`                  | `AvReferenceableField`             |
+  | `ReferenceBuilder`                    | `AvReferenceBuilder`               |
+  | `RelationField`                       | `AvRelationField`                  |
+  | `RelationFieldCapabilities`           | `AvRelationFieldCapabilities`      |
+  | `RelationFieldCapabilityName`         | `AvRelationFieldCapabilityName`    |
+  | `RelationFieldPipelineConfig`         | `AvRelationFieldPipeline`          |
+  | `RelationFilterCapability`            | `AvRelationFilterCapability`       |
+  | `RelationMutationCapability`          | `AvRelationMutationCapability`     |
+  | `RelationMutationDirective`           | `AvRelationMutationDirective`      |
+  | `RelationProjectionCapability`        | `AvRelationProjectionCapability`   |
+  | `RelationProjectionInput`             | `AvRelationProjectionInput`        |
+  | `RelationReducer`                     | `AvRelationReducer`                |
+  | `RelationReducerCapability`           | `AvRelationReducerCapability`      |
+  | `RequestOrigin`                       | `AvRequestOrigin`                  |
+  | `Resource`                            | `AvResource`                       |
+  | `ResourceFieldMap`                    | `AvResourceFieldMap`               |
+  | `ResourceKey`                         | `AvResourceKey`                    |
+  | `ResourceOperations`                  | `AvResourceOperations`             |
+  | `ScalarDefinition`                    | `AvScalarDefinition`               |
+  | `ScalarField`                         | `AvScalarField`                    |
+  | `ScalarFieldCapabilities`             | `AvScalarFieldCapabilities`        |
+  | `ScalarFieldCapabilityName`           | `AvScalarFieldCapabilityName`      |
+  | `ScalarFieldKey`                      | `AvScalarFieldKey`                 |
+  | `ScalarFieldPipelineConfig`           | `AvScalarFieldPipeline`            |
+  | `ScalarFilterOperator`                | `AvScalarFilterOperator`           |
+  | `ScalarFormat`                        | `AvScalarFormat`                   |
+  | `ScalarMutationDirective`             | `AvScalarMutationDirective`        |
+  | `ScalarOrderInput`                    | `AvScalarOrderInput`               |
+  | `ScalarRegistry`                      | `AvScalarRegistry`                 |
+  | `ScalarValueType`                     | `AvScalarValueType`                |
+  | `ScopedRelationMutations`             | `AvScopedRelationMutations`        |
+  | `ScopedRelationReducers`              | `AvScopedRelationReducers`         |
+  | `SelectInput`                         | `AvSelectInput`                    |
+  | `SingleRowResult`                     | `AvSingleRowResult`                |
+  | `SortDirection`                       | `AvSortDirection`                  |
+  | `TransactionAfterHook`                | `AvTransactionAfterHook`           |
+  | `TransactionBeforeHook`               | `AvTransactionBeforeHook`          |
+  | `TransactionCapability`               | `AvTransactionCapability`          |
+  | `TransactionCommittedResponse`        | `AvTransactionCommittedResponse`   |
+  | `TransactionDiagnostic`               | `AvTransactionDiagnostic`          |
+  | `TransactionFilter`                   | `AvTransactionFilter`              |
+  | `TransactionGuard`                    | `AvTransactionGuard`               |
+  | `TransactionIntegrityError`           | `AvTransactionIntegrityError`      |
+  | `TransactionIntegrityViolation`       | `AvTransactionIntegrityViolation`  |
+  | `TransactionInterceptor`              | `AvTransactionInterceptor`         |
+  | `TransactionPipe`                     | `AvTransactionPipe`                |
+  | `TransactionPipelineConfig`           | `AvTransactionPipeline`            |
+  | `TransactionPipelineContext`          | `AvTransactionContext`             |
+  | `TransactionReference`                | `AvTransactionReference`           |
+  | `TransactionResponse`                 | `AvTransactionResponse`            |
+  | `TransactionResults`                  | `AvTransactionResults`             |
+  | `TransactionRunner`                   | `AvTransactionRunner`              |
+  | `TransactionSlotPathError`            | `AvTransactionSlotPathError`       |
+  | `TransactionSlotPathViolation`        | `AvTransactionSlotPathViolation`   |
+  | `UniqueWhereInput`                    | `AvUniqueWhereInput`               |
+  | `UpdateDataInput`                     | `AvUpdateDataInput`                |
+  | `ValidationCode`                      | `AvValidationCode`                 |
+  | `ValidationIssue`                     | `AvValidationIssue`                |
+  | `WhereInput`                          | `AvWhereInput`                     |
+  | `WireScalarForms`                     | `AvWireScalarForms`                |
+  | `WriteScope`                          | `AvWriteScope`                     |
+  | `WriteScopes`                         | `AvWriteScopes`                    |
+
+  Error classes whose `name` a log or a test may read:
+
+  | Before                   | After                      |
+  | ------------------------ | -------------------------- |
+  | `CallerDataError`        | `AvCallerDataError`        |
+  | `ClientConfigError`      | `AvClientConfigError`      |
+  | `ComputedValueError`     | `AvComputedValueError`     |
+  | `ContractProtocolError`  | `AvContractProtocolError`  |
+  | `ContractTransportError` | `AvContractTransportError` |
+  | `EnvFileError`           | `AvEnvFileError`           |
+  | `OutputValidationError`  | `AvOutputValidationError`  |
+  | `OutputWriteError`       | `AvOutputWriteError`       |
+  | `PipeOutputError`        | `AvPipeOutputError`        |
+  | `UnmountedRouteError`    | `AvUnmountedRouteError`    |
+
+  `@aventara/testing`:
+
+  | Before                   | After                      |
+  | ------------------------ | -------------------------- |
+  | `AdapterFactory`         | `AvAdapterFactory`         |
+  | `FakeAdapter`            | `AvFakeAdapter`            |
+  | `FakeAdapterExecute`     | `AvFakeAdapterExecute`     |
+  | `FakeAdapterOptions`     | `AvFakeAdapterOptions`     |
+  | `FakeAdapterRollback`    | `AvFakeAdapterRollback`    |
+  | `FakeTransactionOutcome` | `AvFakeTransactionOutcome` |
+  | `FakeTransactionTrace`   | `AvFakeTransactionTrace`   |
+
+  `@aventara/client` (the `framework.client.ts` config types):
+
+  | Before              | After                 |
+  | ------------------- | --------------------- |
+  | `ClientConfigInput` | `AvClientConfigInput` |
+  | `ConfigValue`       | `AvClientConfigValue` |
+  | `EnvReference`      | `AvEnvReference`      |
+
+  `@aventara/prisma7-adapter`: its public types and error classes (`createPrismaAdapter` keeps its name):
+
+  | Before                             | After                                |
+  | ---------------------------------- | ------------------------------------ |
+  | `PrismaAdapterModel`               | `AvPrismaAdapterModel`               |
+  | `PrismaAdapterOptions`             | `AvPrismaAdapterOptions`             |
+  | `PrismaDelegate`                   | `AvPrismaDelegate`                   |
+  | `PrismaDelegateHost`               | `AvPrismaDelegateHost`               |
+  | `PrismaDelegateIndex`              | `AvPrismaDelegateIndex`              |
+  | `PrismaDiscoveryArtifact`          | `AvPrismaDiscoveryArtifact`          |
+  | `PrismaDriver`                     | `AvPrismaDriver`                     |
+  | `PrismaIsolationLevel`             | `AvPrismaIsolationLevel`             |
+  | `PrismaProvider`                   | `AvPrismaProvider`                   |
+  | `PrismaProviderProfile`            | `AvPrismaProviderProfile`            |
+  | `PrismaReferentialAction`          | `AvPrismaReferentialAction`          |
+  | `PrismaReferentialActionTable`     | `AvPrismaReferentialActionTable`     |
+  | `PrismaReferentialEdge`            | `AvPrismaReferentialEdge`            |
+  | `PrismaResourceReferentialActions` | `AvPrismaResourceReferentialActions` |
+  | `PrismaTransactionOptions`         | `AvPrismaTransactionOptions`         |
+  | `PrismaCapabilityDerivationError`  | `AvPrismaCapabilityDerivationError`  |
+  | `PrismaDiscoveryArtifactError`     | `AvPrismaDiscoveryArtifactError`     |
+  | `PrismaEmulationError`             | `AvPrismaEmulationError`             |
+  | `PrismaExecutionError`             | `AvPrismaExecutionError`             |
+  | `PrismaExistenceGateError`         | `AvPrismaExistenceGateError`         |
+  | `PrismaFieldProjectionError`       | `AvPrismaFieldProjectionError`       |
+  | `PrismaGenerateCliError`           | `AvPrismaGenerateCliError`           |
+  | `PrismaGenerateStepError`          | `AvPrismaGenerateStepError`          |
+  | `PrismaModelCompositionError`      | `AvPrismaModelCompositionError`      |
+  | `PrismaMutationTranslationError`   | `AvPrismaMutationTranslationError`   |
+  | `PrismaOperationTranslationError`  | `AvPrismaOperationTranslationError`  |
+  | `PrismaOrderTranslationError`      | `AvPrismaOrderTranslationError`      |
+  | `PrismaProjectionTranslationError` | `AvPrismaProjectionTranslationError` |
+  | `PrismaResultShapeError`           | `AvPrismaResultShapeError`           |
+  | `PrismaScalarConversionError`      | `AvPrismaScalarConversionError`      |
+  | `PrismaSchemaReaderError`          | `AvPrismaSchemaReaderError`          |
+  | `PrismaTypesReaderError`           | `AvPrismaTypesReaderError`           |
+  | `PrismaWhereTranslationError`      | `AvPrismaWhereTranslationError`      |
+
+- 68d4395: New: the generated client checks field validators before it sends. When the ClientContract carries a field's
+  `validators` or a Json Shape's checks, `avclient generate` emits them into the client with the check code that runs
+  them, and every call and every transaction checks the values it holds first. A call that breaks a check rejects with
+  the same `AvValidationError` the server would answer, `A2004` with the same issues (`code`, `path`, `check`,
+  `params`, `message`), and no request is sent:
+
+  ```ts
+  try {
+    await avClient.projects.create.one({ data: { id: "p1", name: "no" } });
+  } catch (error) {
+    // error instanceof AvValidationError, error.code === "A2004", nothing was sent:
+    // error.cause.issues[0] → { code: "V1004", path: ["arguments", "data", "name"],
+    //   message: "Value must be at least 3 characters long.", check: "min_length", params: { minimum: 3 } }
+  }
+  ```
+
+  - The server checks every value again. The client checks a value as the caller wrote it and the server checks it
+    after its field pipes, so a field pipe that normalizes a value (trims it, lower-cases it) must not turn a value the
+    client accepted into one the server refuses.
+  - A transaction is checked whole before it is sent: a bad literal value in any step rejects with the server's answer,
+    `cause.operation` naming the step. A `$ref` value is checked by the server, at its step.
+  - Nested write data, list fields (each entry and the list's length), `$push` entries and Json Shape checks are all
+    checked, a Json Shape's checks with the other validators in the order the call wrote the fields, and a plan step
+    by step, as the server does. A Json value that does not match its shape is sent, and the server answers it.
+  - The check code is `@aventara/core`'s own, copied into the generated output; the client still imports nothing from
+    `@aventara/*` or zod at runtime. A contract with no checks generates the same files as before.
+  - `AvValidationIssue` declares `check` and `params`, and the client keeps them on the issues a server sends (they
+    were dropped before).
+  - The server lists validator issues in the order the call wrote the fields (it used the model's field order), and a
+    Json Shape's issues in the order of its keys as the Contract lists them, so the client can list the same issues in
+    the same order. An issue inside a nested write whose operand is one entry rather than a list no longer names an
+    index the request does not have (`[…, "$update", "data", …]`, not `[…, "$update", 0, "data", …]`).
+
+- 7e3d06f: Breaking: the configuration has a new shape. Every layer (the root, `application` and `client`) now holds the
+  same six keys: `exposed`, `transactionsStyle`, `limits`, `pipelines`, `resources` and `exemptions`. Everything about
+  one Resource lives under `resources.<Resource>`: its fields, and each field's `definition` and `pipelines`. The old
+  keys are refused when the framework starts, with a message that names where each one moved:
+
+  | Before (rc.0)                                           | Now (rc.1)                                                                          |
+  | ------------------------------------------------------- | ----------------------------------------------------------------------------------- |
+  | `fields: { Post: { url: { type, nullable, … } } }`      | `resources: { Post: { fields: { url: { definition: { type, nullable, … } } } } }`   |
+  | `behaviors: { Post: { fields: { slug: { create } } } }` | `resources: { Post: { fields: { slug: { pipelines: { compute: { create } } } } } }` |
+  | `transactions: "none"`                                  | `transactionsStyle: "none"`                                                         |
+  | `restrictions`                                          | `exposed` + `exemptions` (see below)                                                |
+  | `@aventara/core/json`                                   | `@aventara/core/avz`                                                                |
+
+  Before:
+
+  ```ts
+  createFramework({
+    api: "/api",
+    adapter,
+    transactions: "interactive",
+    fields: {
+      Post: {
+        url: {
+          type: { scalar: "string" },
+          nullable: false,
+          list: false,
+          lifecycle: ["VIRTUAL"],
+        },
+      },
+    },
+    behaviors: {
+      Post: {
+        fields: {
+          url: {
+            read: {
+              dependsOn: ["slug"],
+              compute: ({ record }) => `/p/${record.slug}`,
+            },
+          },
+        },
+      },
+    },
+  });
+  ```
+
+  After:
+
+  ```ts
+  createFramework({
+    api: "/api",
+    adapter,
+    transactionsStyle: "interactive",
+    resources: {
+      Post: {
+        fields: {
+          url: {
+            definition: {
+              type: { scalar: "string" },
+              nullable: false,
+              list: false,
+              lifecycle: ["VIRTUAL"],
+            },
+            pipelines: {
+              compute: {
+                read: {
+                  dependsOn: ["slug"],
+                  compute: ({ record }) => `/p/${record.slug}`,
+                },
+              },
+            },
+          },
+        },
+      },
+    },
+  });
+  ```
+
+  What else changed:
+
+  - A field is defined at the root only. A `definition` in `application` or `client` is refused
+    (`CONFIG_FORBIDDEN_IN_OVERLAY`). Define the field
+    at the root; `application` and `client` can still add compute stages to it.
+  - Computed values chain. When the root and an overlay both compute a field, the root's stage runs first and the
+    overlay's receives its result as `value`. A stage can no longer be turned off with `false`. Returning `undefined`
+    keeps the current value. An upsert computes its create branch with `compute.create` and its update branch with
+    `compute.update`.
+  - A discovered field keeps the adapter's facts. On a field the adapter discovered you may restate its own `type`,
+    `nullable` and `list`, and give a Json field its shape (`definition.json`). Setting a different type, any `format`
+    or any `capabilities` on it is refused. `format` is for fields you add, and it must be one of zod's named string
+    formats (`"email"`, `"url"`, `"uuid"`, …); any other name is a type error and refused at startup.
+  - A misplaced key is a type error. In a configuration written inline in `createFramework({ ... })` or
+    `AventaraModule.forRoot`, a key that has no place there (a typo, an old key, `compute` on a relation field, a field
+    name neither your schema nor the root has) is now a type error at that key, and still refused at startup.
+  - A Resource whose name starts with `$` is refused at startup (`$` names are the framework's).
+  - The Json shape builder moved from `@aventara/core/json` to `@aventara/core/avz`. Change the import; `AvZ` is
+    the same.
+
+  `exposed` and `exemptions`, which replace `restrictions`, have their own entry.
+
+- 1b5d3c0: Breaking: every framework member of a pipeline ctx is `$`-prefixed, and ctx is now the framework's executor.
+  The rest of ctx is your Resources: `ctx.<Resource>.<family>.<variant>(args)`, plus `ctx.$sql` and
+  `ctx.$transaction`. Because a Resource name can never start with `$` (`COMPILER_RESERVED_RESOURCE_NAME`), a Resource
+  never shadows a framework member. The old names are gone with no alias. Reading one is a type error; at runtime it
+  is `undefined`.
+
+  | rc.0                                                      | rc.1                                                                        |
+  | --------------------------------------------------------- | --------------------------------------------------------------------------- |
+  | `ctx.resource`, `ctx.family`, `ctx.variant`, `ctx.nested` | `ctx.$operation.resource`, `.family`, `.variant`, `.nested`                 |
+  | `ctx.args`                                                | `ctx.$args` (a transaction stage: the plan, `readonly AvTransactionStep[]`) |
+  | `ctx.origin`                                              | `ctx.$origin`                                                               |
+  | `ctx.requestId`                                           | `ctx.$requestId`                                                            |
+  | `ctx.transport`                                           | `ctx.$transport`                                                            |
+  | `ctx.contract`                                            | `ctx.$contract`                                                             |
+
+  A transaction stage's ctx has no `$operation`. Every ctx also carries `ctx.$state`, the request's writable state (see
+  the `$state` entry below).
+
+  ```ts
+  hooks: {
+    after: [
+      async (post, ctx) => {
+        await ctx.User.update.unique({ where: { id: authorId }, data: { postCount: { $increment: 1 } } });
+        await ctx.$sql`insert into audit_events (actor, action) values (${actorId}, ${"post.create"})`;
+      },
+    ],
+  },
+  ```
+
+  - A ctx call is raw and application-origin. It runs the Framework Validation Layer against the
+    ApplicationContract, plus field pipes, field validators and compute. It runs no developer stage: no guards, pipes,
+    hooks, interceptors or filters at any level, no field write guards, no nested target guards, no Resource
+    transaction stages, and no `forceTransaction` wrapping. So a hook's call never re-enters the hook that made it.
+    The application layer's exposure limits it. The client's does not.
+  - A call resolves the operation's data directly (a row, a list, a count, or `null` for a first-style miss). A
+    failure throws the `AvError` subclass of its code's class (`AvNotFoundError`, `AvValidationError`, …; see the
+    in-process calls entry below) carrying the failure's `code` and `cause`.
+  - It joins the current transaction. That covers a plan step's interceptors and hooks, a forced call's, a Resource's
+    transaction stages and a `ctx.$transaction` callback. A step's guards and pipes run before the transaction opens,
+    so their calls run on their own, as every call outside a transaction does. Under
+    `forceTransaction`, an after hook's ctx writes commit with the operation or not at all (the outbox and
+    counter-on-another-Resource cases).
+  - `ctx.$sql` is the bound tagged template of `appTx.$sql`, run at once. It takes only the tagged-template form,
+    binds every value, needs the Adapter's `sqlStatements`, and accepts no `$ref`. It resolves the rows, typed by
+    `ctx.$sql<Row>`. Inside a transaction it runs on it; outside one it is a plain statement, with no transaction
+    opened around it, and `transactionsStyle: "none"` does not affect it (only `ctx.$transaction` is refused there).
+  - `ctx.$transaction(async (tx) => …)` runs the callback in one transaction, with `tx` the ctx bound to it, and
+    resolves what the callback returns. A throw rolls it back and is rethrown as it was. Inside an open transaction it
+    opens nothing and joins.
+  - The executor is typed from the adapter's model, with the application forms and the operation's data
+    as the result, like `framework.application`'s success data. A stage typed for any model (`AvGuard` with no model)
+    names no Resource.
+  - Compute gets a read-only ctx, `AvComputeContext` (new public name). It carries the `$` facts, a read-only view
+    of `ctx.$state`, and `ctx.<Resource>.find.*` (`find.count` included), and nothing that writes: no write families, no `$sql`, no
+    `$transaction`. This holds at runtime too: reaching one throws, and the operation answers `A3000`. A compute
+    stage's input is now `{ field, value, data, ctx }` (`{ field, value, record, ctx }` on read). rc.0's `origin`,
+    `resource` and `operation` members are gone: use `ctx.$origin`, `ctx.$operation`, and the stage's placement for
+    its Resource.
+  - A transaction pipe's returned plan is typed `readonly AvTransactionStep[]` (any model). The runtime holds it to
+    the plan it was given, as before.
+
+- 6317811: Breaking: `exposed` and `exemptions` replace `restrictions`. Every layer (the root, `application` and `client`)
+  says what it exposes with two keys: `exposed`, the layer's default, and `exemptions`, the entries that are the
+  opposite of it.
+
+  - `exposed: true` (the root's default) exposes everything the layer above offers, and `exemptions` lists what to
+    hide. `exposed: false` exposes nothing, and `exemptions` lists the only things to expose.
+  - In `exemptions`, `true` exempts an entry whole, `false` and `[]` exempt nothing, a list exempts the listed
+    entries one level down, and an object goes one level deeper. A Resource takes `true`, `false` or
+    `{ operations, fields }`. Operations are nested: `operations: { find: ["many"], update: { unique: true } }`.
+    A field takes a list of capability names, or an object per capability whose token lists name filter operators,
+    directives, reducers or pagination kinds.
+  - A list now always means "exempt these". rc.0's `filter: ["equals"]` meant "keep only `equals`"; under
+    `exposed: true` the same intent is the list of the operators to remove.
+  - Overlays only narrow. `application` and `client` start from the root's view. An overlay can no longer bring
+    back what the root hid (rc.0's `hidden: false`); that is now refused at startup, and the message names the other
+    overlay to hide it in instead. Expose an entry at the root and hide it in the overlay that must not see it.
+  - An overlay that sets `exemptions` must also set its own `exposed`.
+  - Relation positions are the adapter's: an exemption can no longer narrow where a relation is projected or written.
+  - A unique operation (`find.unique`, `update.unique`, `delete.unique`, `upsert.unique`) needs an identifier. Picking
+    one without the identifier's fields, or hiding every identifier while one stays exposed, is refused at startup
+    with `COMPILER_MISSING_IDENTIFIER` instead of the operation silently disappearing.
+
+  Every name in `exemptions` must exist, in both styles: a Resource, field, family, variant, capability or token the
+  adapter does not offer is refused at startup with its path (`COMPILER_UNKNOWN_RESOURCE`, `COMPILER_UNKNOWN_FIELD`,
+  `COMPILER_UNAVAILABLE_OPERATION`, `COMPILER_UNAVAILABLE_CAPABILITY`), and in a configuration written inline in
+  `createFramework({ ... })` it is a type error first. Under `exposed: true`, hiding in an overlay what the root
+  already hid does nothing.
+
+  Before (rc.0):
+
+  ```ts
+  createFramework({
+    api: "/api",
+    adapter,
+    restrictions: {
+      User: {
+        fields: {
+          passwordHash: { hidden: true },
+          email: { capabilities: { filter: ["equals"] } },
+        },
+      },
+    },
+    client: {
+      restrictions: {
+        AuditLog: { hidden: true },
+        Post: { operations: { delete: { unique: false } } },
+      },
+    },
+  });
+  ```
+
+  After (rc.1):
+
+  ```ts
+  createFramework({
+    api: "/api",
+    adapter,
+    // The root: `exposed` defaults to true, so these are hidden from every origin.
+    exemptions: {
+      resources: {
+        User: {
+          fields: {
+            passwordHash: true,
+            email: { filter: ["contains", "startsWith"] }, // remove every operator but `equals`
+          },
+        },
+      },
+    },
+    client: {
+      exposed: true,
+      exemptions: {
+        resources: {
+          AuditLog: true,
+          Post: { operations: { delete: ["unique"] } },
+        },
+      },
+    },
+  });
+  ```
+
+  Or expose only what a frontend calls:
+
+  ```ts
+    client: {
+      exposed: false,
+      exemptions: {
+        resources: {
+          Post: {
+            operations: { find: ["many", "unique"], create: ["one"] },
+            fields: { id: ["select"], title: ["select", "create"], body: ["select", "create"] },
+          },
+        },
+      },
+    },
+  ```
+
+  `aventara init` and `aventara new` now write `exposed: true` into `src/aventara.config.ts`, with a comment that
+  links the exposure documentation.
+
+- 6d0e5d6: New: field validators. `resources.<R>.fields.<f>.pipelines.validators` takes declarative checks written with
+  `AvZ` from `@aventara/core/avz`, in zod's check vocabulary:
+
+  ```ts
+  import { AvZ } from "@aventara/core/avz";
+
+  resources: {
+    Project: {
+      fields: {
+        name: { pipelines: { validators: [AvZ.minLength(3), AvZ.maxLength(80)] } },
+        slug: { pipelines: { validators: [AvZ.regex(/^[a-z0-9-]+$/)] } },
+        budget: { pipelines: { validators: [AvZ.gte(0), AvZ.multipleOf(100)] } },
+        tags: { pipelines: { validators: [AvZ.maxItems(5), AvZ.maxLength(20)] } }, // at most 5 tags of at most 20 characters
+      },
+    },
+  },
+  ```
+
+  - The builders: `lt`, `lte`, `gt`, `gte`, `positive`, `nonnegative`, `negative`, `nonpositive`, `multipleOf`,
+    `minLength`, `maxLength`, `length`, `minItems`, `maxItems`, `minSize`, `maxSize`, `size`, `regex`, `includes`,
+    `startsWith`, `endsWith`, `lowercase`, `uppercase`, and one per named format: `email`, `url`, `uuid`, `e164`,
+    `ipv4`, `ipv6`, `base64`, `nanoid`, `cuid`, `ulid` and the rest, with `AvZ.iso.datetime()`, `.date()`, `.time()`
+    and `.duration()`. Each behaves as zod 4's check does.
+  - A check has to fit the field's type: `AvZ.maxLength` on an `int` field, or `AvZ.maxItems` on a field that is not a
+    list, is a type error and a startup error (`COMPILER_INVALID_VALIDATOR`, naming the path and why). On a list field
+    `minItems`/`maxItems` check the list and every other check applies to each entry. A bound is a number, a bigint or a
+    `Date`, matching the field.
+  - A Json field takes no `validators` key. Its checks go in its `definition.json` shape, written as zod/mini writes
+    them: `AvZ.object({ code: AvZ.string().check(AvZ.length(4)), tags: AvZ.array(AvZ.string()).check(AvZ.maxItems(3)) })`.
+  - Where they run: once, after every pipe (the guards, then the operation's pipes, then the field pipes) and before
+    any interceptor or hook; for a transaction plan or a forced call, on every step's literal values before the
+    transaction opens, and on a `$ref` value at its step; on nested write data with the target Resource's checks.
+    What they judged is what is written: no later stage can change it. Validators add up across layers: the root's
+    apply to both origins, an overlay's to its own.
+  - A Json field's shape is one of its validators. Its structure and its checks are judged where validators run, after
+    every pipe (rc.0 judged the shape before the pipes), with the same reach: plan literals before the transaction
+    opens, a `$ref` value at its step, and nested write data. Its issues come in the order the call wrote the fields,
+    with the other validators'. Before the
+    pipes the framework only checks that a Json value is plain JSON. A field or operation pipe whose Json output breaks
+    the shape is answered `A2004`, as the caller's, not `A3004`. The shape still types the field.
+  - A failure answers `A2004` (HTTP 422) with one issue per broken rule, on `V1004` (range, length, size) or `V1003`
+    (pattern, format). Each issue now also carries zod's `check` name and the check's `params`, for example
+    `{ "code": "V1004", "path": ["arguments", "data", "name"], "check": "max_length", "params": { "maximum": 80 }, "message": "Value must be at most 80 characters long." }`.
+  - The checks are in the Contract: a field's `validators` (`AvFieldCheck`, now exported) and a Json Shape node's
+    `checks`, only on fields the layer exposes. Adding, removing or changing a client-visible check changes the
+    ClientContract hash, so regenerate the client. The generated client runs the same checks before it sends a call.
+
+- 7a0cab9: A `where` now offers each field only the filter operators that field allows. The types of `framework.client`,
+  `framework.application`, `framework.clientTx`, `framework.appTx` and a generated client read the operators from the
+  field's effective `filter` capability, so an operator the server would refuse with `V1006` is now a type error
+  instead. That covers an operator the adapter does not offer for the field's type (no `contains` on an Int), an
+  operator a layer's exemptions removed (the client layer narrowing `email` to `equals` is refused on
+  `framework.client` and still allowed on `framework.application`), and operators inside a nested `not`. A plain
+  value, `null` or `$ref` as shorthand is equality, so it is only accepted where the field allows `equals`, and a field
+  narrowed to no operators at all can no longer be named in a `where`. Runtime behavior is unchanged.
+
+  A generated client picks this up when it is regenerated with this version of `@aventara/client`.
+
+- eb2a718: New limit `maxJsonDepth` (default 64): how deeply a `json` field's value may nest. Each array or object inside the value
+  is one level, counted from the value itself, wherever it is written or filtered on. A value past the limit is refused
+  with `A2009` and the new issue code `V1021` at the field's path, before anything else reads it, in single calls,
+  transaction steps and over HTTP. It is set like the other limits, at the root or per layer, and appears in the
+  Contract's `limits`, so the ClientContract hash changes: regenerate your client. `maxNestingDepth` does not count Json
+  values. Before, a value 10,000 levels deep was written and then failed over HTTP with an internal `A3003`, and in a
+  transaction failed with `A3000`. The HTTP response encoder and `canonicalizeJson` no longer recurse on a value's depth,
+  so a deep value already in your database is read without an error.
+- 03312c5: Fixed a bug where operators inside `not` weren't checked against a field's allowed operators. On a field whose
+  `filter` capability allowed only `equals` and `not`, a request like `where: { id: { not: { contains: "a" } } }` passed
+  validation and reached the adapter, so a remote caller could use an operator the client layer had removed. Operators
+  inside `not` are now checked at every depth, in single calls and transaction steps, under `AND`/`OR`/`NOT` and relation
+  filters, and are refused with `A2004`/`V1006` at the nested operator's path. A `not` written as a plain value, `null` or
+  `$ref` means "not equal", so it is accepted only where the field allows `equals`; the types now say the same. An empty
+  `not: {}` is refused with `V1001`, like an empty filter object.
+- 123f6dc: Breaking: nested writes now run the target's guards. When a create, update or upsert reaches another Resource
+  through a relation directive, that target Resource's own guards and field stages now run on the nested data, in
+  Node, before the single adapter call (still one call). In rc.0 a nested write ran none of them, so a client could
+  create a Category through `Post.create({ data: { category: { $create: … } } })` past a guard that refuses
+  `Category.create`. That call is now refused with `A4001`.
+
+  Which stages a directive runs on its target:
+
+  | Directive                                                                              | The target's stages                                                                                                                                                |
+  | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+  | `$create`, `$connectOrCreate`                                                          | Resource and `create` guards; field stages on the created data                                                                                                     |
+  | `$update`, `$upsert`                                                                   | Resource and `update` guards; field stages (an `$upsert`'s `create` branch gets the create field stages and `compute.create`, its `update` branch the update ones) |
+  | `$delete`                                                                              | Resource and `delete` guards                                                                                                                                       |
+  | `$connect`, `$disconnect`, `$set` on a to-one whose key the parent holds               | None: the parent's relation field write guard covers it                                                                                                            |
+  | `$connect`, `$disconnect`, `$set` on a to-many, or a to-one whose key the target holds | Resource and `update` guards                                                                                                                                       |
+
+  - The field stages are the target's field pipes, field validators, field write guards and write compute.
+  - Order: each kind runs after the top-level operation's stages of the same kind, for the targets depth first in
+    data order: the operation's guards and field write guards, then each target's Resource guards, family guards and
+    field write guards; the operation's pipes; the operation's field pipes, then the targets'; the validators; the
+    operation's write compute, then the targets'.
+  - What a target's stage is told: `ctx.$operation.resource` is the target, `ctx.$operation.family` the family its directive maps to,
+    `ctx.$operation.variant` is `"one"`, `ctx.$operation.nested` is `true` and `ctx.$args` is the directive's entry (for example the
+    `$create` data, or a `$connect`'s identifier). A family stage's `ctx.$operation.variant` is now typed as the family's
+    variants or `"one"`, for `create`, `update` and `delete`.
+  - Not run for a target: its layer and variant stages, operation pipes, hooks, interceptors and filters, and its
+    Resource transaction stages. A nested write is part of its parent's operation; an error a target's guard throws
+    goes through the parent operation's filters.
+  - Who holds the key is read from the adapter's referential edges (`AvAdapter.referentialActions`). An adapter
+    that states no edge for a to-one relation is read as the target holding it, so the target's `update` guards run.
+  - The same holds for a transaction step and a forced call: each step's nested targets' guards, field pipes and
+    validators run with the step's own before the transaction opens, and a nested `$ref` value goes through the
+    target's field pipes and validators when it resolves at its step.
+
+- b65df2e: Fixed a gap where a chain of `not` inside a scalar filter (`{ id: { not: { not: … } } }`) wasn't counted toward
+  `maxNestingDepth`. A 50-level chain reached the adapter, and a 5,000-level one failed with an internal `A3000` error
+  (a stack overflow) instead of a validation error. Each `not` whose value is an object now counts as one level of
+  `where` nesting, like `NOT`, so a chain past the limit is refused with `A2009`/`V1013` before anything runs, in single
+  calls, transaction steps and over HTTP. `framework.transaction` no longer overflows on deeply nested arguments either.
+- c6e5010: Breaking: one stage order, and hooks now run inside interceptors. Every operation runs
+
+  ```
+  guards → pipes → validators → interceptors (before) → hooks.before → operation → hooks.after → interceptors (after) → filters
+  ```
+
+  Each stage runs over every level, outer to inner, before the next starts, so every interceptor wraps every hook: all
+  interceptors enter, then every `before` hook runs, then the operation, then every `after` hook (inner to outer), then
+  the interceptors unwind (inner to outer). In rc.0 every `before` hook ran ahead of every interceptor, every `after`
+  hook after every interceptor had unwound, and the overlay's `after` hooks after the root's; now the overlay's run
+  before the root's. Filters run inner to outer, and the first filter that handles an error wins. A call that a guard,
+  a pipe's output or a validator refuses runs no interceptor and no hook; the filters still see a thrown error. Inside
+  a transaction, a step's error its own filters leave unhandled continues to the Resource transaction filters (the
+  transaction's outer layer) before it is answered.
+
+  New: stages at every level of `resources`. `resources.<R>.pipelines`, `resources.<R>.operations.<family>.pipelines`
+  and `resources.<R>.operations.<family>.<variant>.pipelines` run now, in both layers, level by level: root layer,
+  overlay layer, root Resource, overlay Resource, root family, overlay family, root variant, overlay variant. Nothing
+  below removes a stage above. A stage is told the level it sits at: a Resource's `ctx.$operation.resource` is its name, a
+  family's `ctx.$operation.family` too, a variant's `ctx.$operation.variant` as well.
+
+  - Field pipes (`resources.<R>.fields.<f>.pipelines.pipes`) are pure: value in, value out, no `ctx`. They run on
+    each value the caller sent in top-level create, update or upsert data, right after the operation's pipes, root's
+    then overlay's; guards see the value as sent. In a transaction they run on every step's literal values before the
+    transaction opens, and on a `$ref` value when it is resolved at its step. A value a field pipe returns is held to the server's rules
+    (`A3004`). A relation field takes no field pipes (`COMPILER_RELATION_FIELD_CONFIG_UNSUPPORTED`).
+  - Field write guards (`resources.<R>.fields.<f>.pipelines.guards`) refuse with `A4001` when the caller sends
+    the field in create, update or upsert data, a relation field's `$connect` included. They run right after the
+    operation's guards, last among the guards.
+  - Transactions: every step's guards, pipes and validators run before the transaction opens, in plan order; an
+    operation pipe sees a `$ref` as the reference it is. A refused step opens nothing. Then BEGIN, and at each step
+    its `$ref`s are resolved, their field pipes and validators run, then the step's interceptors and hooks around its
+    adapter call. A forced call runs the same way. A step's guards and pipes no longer run inside the transaction, so
+    their ctx calls do not join it.
+  - Resource transaction stages (`resources.<R>.transactions.pipelines`) run once per transaction with a
+    top-level step on the Resource, inside it: guards and pipes see the whole plan (`ctx.$args`, `$ref`s unresolved),
+    interceptors and hooks wrap every step, and the `after` hooks see every step's result before the commit, so a
+    throw rolls everything back. Touched Resources run in the order their first step appears; a SQL step touches
+    nothing. A transaction pipe may change a step's arguments; they are held to the server's rules and their
+    validators at the step.
+  - `forceTransaction` on a family or a variant runs a plain call of that operation as a one-step transaction,
+    so its after hooks commit with the write or not at all, and the Resource's transaction stages run. It holds when
+    any layer sets it. As a step of a plan it is just a step. Under an effective `transactionsStyle: "none"` it is a
+    startup error (`CONFIG_INVALID_VALUE`).
+
+  Breaking: a transaction has one origin. `framework.transaction` refuses a list that mixes `appTx` and
+  `clientTx` handles: `A2004` with one new `V1020` issue, "Transaction mixes application and client steps.", at the
+  first step of the other origin, before anything runs. An `appTx.$sql` step is application-origin. Run each
+  origin's steps as its own transaction. The generated client's error codes include `V1020`.
+
+- c1f9389: A forced operation no longer commits a failed step when a Resource transaction interceptor catches the rollback.
+  A transaction plan and a plain call of a `forceTransaction` operation now settle through one path, so the check that
+  already kept a plan from committing a swallowed failure covers forced calls too.
+
+  `next()` runs once. A Resource transaction interceptor that calls it a second time, or resolves without calling it,
+  rolls the whole transaction back and answers `A3002`, with an `AvTransactionIntegrityError` (`next-called-twice` or
+  `steps-not-run`) on the diagnostics channel. An operation interceptor's second `next()` is refused the same way and
+  answers `A3000`. Both hold even when the interceptor catches the refusal, and no filter sees it.
+
+  What a field pipe returns is checked against the server's rules before the transaction opens, for a plan step and
+  for a forced call. A refusal (`A3004`) no longer opens a transaction or runs transaction stages first.
+
+  A `compute.read` `dependsOn` is resolved against the adapter's model, before exposure. A field hidden at the root can
+  now be a dependency: it is read for the compute and never returned. A dependency must be a scalar field the adapter
+  stores on the same Resource; the type of `dependsOn` now says so.
+
+  Under `exposed: false`, an exemption object that grants nothing (`{}`, `{ select: false }`, `{ create: [] }`, or a
+  Resource object that grants no field and no operation) leaves the field or Resource out of the Contract, exactly as
+  leaving the entry out does. Its name no longer reaches the ClientContract, and the hash is the same either way.
+
+  Compute mistakes are reported once, at the path where they were written. A root mistake is no longer repeated under
+  `application` and `client` paths.
+
+  `forceTransaction: true` is a type error where the types know the effective `transactionsStyle` is `"none"`: the
+  adapter's model states `transactions: "none"`, or the layers state a literal `"none"`.
+
+  Resource transaction stages are told a typed plan. `ctx.$args` is `readonly AvTransactionStep[]`, an operation step
+  `{ resource, family, variant, args }` or a SQL step `{ sql }`, and a transaction pipe returns that type or `undefined`.
+  `AvTransactionStep` is a new public type.
+
+  Renamed compiler codes: `COMPILER_MISSING_READ_BEHAVIOR` is now `COMPILER_MISSING_READ_COMPUTE`, and
+  `COMPILER_INVALID_BEHAVIOR_DEPENDENCY` is now `COMPILER_INVALID_COMPUTE_DEPENDENCY`.
+
+  Smaller fixes: a plan with steps of two origins is refused with `V1020` when the plan is validated too, not only by the
+  typed runner; a transaction pipe may return a deep copy of a SQL step; `validators: []` is accepted; a `hidden` key on a Resource or field entry is `CONFIG_MOVED_PROPERTY`; and
+  an overlay's moved `restrictions` key now names `client.exposed + client.exemptions`.
+
+- 9c52482: A `$connect` to a row that does not exist now answers `404 A2003` (not found), the same as reading a missing row.
+  Before, it answered `422 A2004`. This covers a to-one `$connect` in `create`, `update` and `upsert`, a to-many
+  `$connect`, and the same writes inside a transaction plan, where `cause.operation` names the step. The message is
+  unchanged: "The operation's arguments referenced a record that does not exist." On `update.first`, the same mistake
+  answered `A2014` before, as if the row had changed underneath; it now answers `A2003` too, and a duplicate unique value
+  written through `update.first` answers `409 A2008` instead of `A3001`.
+
+  Clearer top-level messages for an unknown Resource or operation. `A2001` now says "The requested Resource is not
+  available." and `A2002` says "The requested operation is not available on this Resource.", instead of "Operation
+  arguments failed framework validation.", which stays the message of `A2004`, `A2007` and `A2009`. A transaction step
+  whose operation is outside the standard grammar now carries the same issue message as a single call, naming the
+  operation and the Resource (for example `Operation "dance.one" is not available on Resource "posts".`), instead of
+  "Operation is not part of the standard operation grammar."
+
+  A `$ref` with no `fingerprint` is `V1000` (required value missing) and answers `422 A2004`. Before, it was `V1017`
+  (fingerprint mismatch) under `A2007`. A fingerprint that is present but wrong is still `V1017`.
+
+  `aventara init` and `aventara new` link to the documentation at https://aventara-framework.vercel.app. The old
+  address redirects, so links already written into projects keep working.
+
+- 8396148: Types: a method that returns a call's result without a return type now compiles in a project that emits
+  declarations (`declaration: true`, Nest's default). With a shaped Json field, or a `$sql` or `clientTx` handle in
+  the result, TypeScript stopped with TS2742 (TS2883 in TypeScript 6) or TS4053, because the declaration had to name
+  a type that was not exported. Two type exports are new: `AvZShapedSchema` from `@aventara/core/avz` (a shaped Json
+  field's schema in a typed Contract view) and `AvOperationHandle<T, Origin>` from `@aventara/core` (the opaque part of
+  a transaction handle).
+
+  A handle now carries its builder's origin: `framework.transaction([...])` with `appTx` and `clientTx` handles in one
+  list is a type error (it was refused only at runtime, `A2004` / `V1020`, which still guards). `AvOperation<T>`
+  takes an optional second type argument, `"application"` or `"client"`; a handle typed without it joins either list.
+
+  A method that returns a façade node without a return type now compiles there too:
+  `posts() { return this.framework.application.Post; }`, a whole surface, a Resource, a family, on any of
+  `application`, `client`, `appTx` and `clientTx`. The declaration writes the node's name with the Contract view as
+  its argument, instead of expanding every call under it, which TypeScript refused (TS4053, then TS7056 "exceeds the
+  maximum length the compiler will serialize") from a few Resources up. Twelve type exports are new, one set per
+  surface: `AvApplicationFacade`, `AvApplicationResourceFacade`, `AvApplicationFamilyFacade`, and the same for
+  `AvClient…`, `AvAppTx…` and `AvClientTx…`. Measured over 50 Resources (Nest 12's `tsconfig`, TypeScript 6): each such
+  method emits about 400 KB of declaration and the build peaks at about 370 MB. A variant (`…Post.find.many`)
+  is still a call type the declaration cannot name: give that method a return type, or return the call's result.
+
+  An exported `defineResource(...)` result, and an exported configuration or Framework builder that holds typed
+  stages (spread from a `defineResource` result or written inline in `createFramework`), now compile there too. Before,
+  one typed variant pipe was enough for TS7056: a declaration wrote each inline stage's parameter types, and with them
+  the whole model, once per parameter. The types that carry a configuration onwards now state each stage list by its
+  public type for any model (`readonly AvGuard[]`, `readonly AvPipe[]`, …): `defineResource` returns the new
+  `AvDefinedResource<R, Block, Overlays>`, and `createFramework`'s `AvFramework<M, Cfg>` carries the configuration that
+  way. Every key, field definition, `forceTransaction`, validator and compute phase is kept as written, so a spread
+  block is still checked where it is placed and the façades are unchanged; `AvFramework<M, typeof config>` still
+  receives `createFramework(config)`. Measured with the scaffold's shape over 2 Resources, the declarations shrink from
+  5.4 MB to 84 KB; over 50 Resources they emit (before: TS7056) and the build peaks under 400 MB.
+
+- e8fbb02: Breaking: data is read-only once it is final, and every stage gets `ctx.$state`.
+
+  Pipes are now the only stage that changes the arguments. A pipe is told frozen arguments and returns new ones (or
+  `undefined` to keep them); changing them in place throws a `TypeError`. Guards, interceptors, hooks and filters are
+  told frozen arguments too, and an `after` hook a frozen copy of the result. The validators judge what the pipes
+  returned, and that is exactly what the adapter writes: a hook or an interceptor can no longer change the write after
+  validation. An interceptor may still return a different result after `next()`; the output check holds it. The result a
+  caller receives is not frozen. A `Date` or a `Uint8Array` cannot be frozen, so after validation each stage gets its
+  own copy of it. Compute fills its fields on the framework's own copy, and its `data` is a frozen snapshot.
+
+  ```ts
+  // rc.1: return new arguments instead of changing them.
+  pipes: [(args) => ({ ...args, data: { ...args.data, ownerId: ownerOf(args) } })],
+  ```
+
+  `ctx.$state` is the one writable space per request. Declare what it holds once, then read and write it in any stage:
+
+  ```ts
+  declare module "@aventara/core" {
+    interface AvState {
+      user?: { id: string; roles: string[] };
+    }
+  }
+
+  const signedIn: AvGuard = (ctx) => ctx.$state.user !== undefined;
+  ```
+
+  - One object per request. A transaction's steps and its Resource transaction stages share it, and a ctx call,
+    `ctx.$sql` and `ctx.$transaction` inherit the stage's. Compute gets a read-only view; writing through it throws a
+    `TypeError`.
+  - Seed it per call: `framework.application.Post.create.one(args, { state })`, the same on `framework.client`, and
+    `framework.transaction(handles, { state })`. The object is used as it is, so you see what the stages wrote. A call
+    that seeds nothing starts with `{}`.
+  - `framework.execute` and `executeTransaction` take it as the request's `state` member (not an object: `A2004`,
+    `V1001` at `["state"]`). `AvProtocol.bind(framework).handleOperation(request, { state: () => … })` and
+    `handleTransaction` take a seed function, called once the request is decoded. A seed that throws an `AvError`
+    answers that error; any other throw answers `A3000` and reaches diagnostics.
+  - `@aventara/nest` seeds it from the platform request (see its changelog).
+
+  New public types: `AvState` and `AvDeepReadonly<T>`, the read-only shape to claim when a stage reads
+  `ctx.$args` (`ctx.$args as AvDeepReadonly<PostArgs>`). A generated client copies `AvState`'s declaration with the
+  rest of core's types; it does nothing there.
+
+- 916e5f6: Breaking: in-process calls return data and throw, with the generated client's error classes.
+  `framework.application`, `framework.client` and `framework.transaction` now settle the way the generated client
+  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                             |
+
+  `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`,
+  `framework.executeTransaction` and the protocol binding still answer the envelope: it is the transport's format.
+
+  ```ts
+  // Before
+  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]);
+  if (result.code === "A1009") use(result.data[1]);
+
+  // After
+  try {
+    return await framework.application.Post.find.unique({
+      where: { id },
+      select: ["id", "title"],
+    });
+  } catch (error) {
+    if (error instanceof AvNotFoundError) return null;
+    throw error;
+  }
+  const [created, written] = await framework.transaction([user, post]);
+  ```
+
+  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.
+
+  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
+  completes `data`, `where`, `select`; a pipe there is told that type, deep read-only too, and must return it (or
+  `undefined`). The type is read from the model's Application Contract view in the application forms, and a reference
+  position also admits a plan step's unresolved `$ref`. Layer, Resource and family stages keep `unknown`. A pipe typed
+  for any operation (`AvPipe`) still fits a variant; its output is held to the server's rules at runtime (`A3004`). The
+  stage types `AvContext`, `AvGuard`, `AvPipe`, `AvBeforeHook`, `AvAfterHook`, `AvInterceptor`, `AvFilter` and
+  `AvPipeline` take the arguments as a new last type parameter, `unknown` by default.
+
+  Behaviour change: a Resource's transaction filters are the transaction's outer layer, and they run last. An error a
+  step throws inside a transaction goes through that step's own filters first, inner to outer; when none handles it,
+  the transaction interceptors unwind (their `next()` rejects), and then it goes to the touched Resources' transaction
+  filters (the last-touched Resource's first) before it is answered. A transaction interceptor's `next()` rejects with
+  the failed step's outcome as the `AvError` a façade would throw for it (`AvNotFoundError` for a unique miss,
+  `instanceof` works, `code` and `cause` are set); before, it rejected with an internal rollback object. An error the
+  step's filters leave unhandled reaches the interceptor sanitized, as the caller would get it. Catching it still cannot
+  commit the failed step. An error a transaction stage throws goes to the
+  transaction filters alone, also after the interceptors have unwound. ROLLBACK follows both. Before, a step's
+  unhandled error was answered without reaching them.
+
+  Behaviour change: a strict unique operation that matches no row (`find.unique`, `update.unique`, `delete.unique`)
+  now fails at the operation, inside the pipeline, as a missing `$connect` target already did. No `after` hook runs
+  for it, an interceptor's `next()` throws the `AvNotFoundError` (it resolved `null` before), the filters see it and
+  may answer another outcome, and a forced call or a transaction step rolls back. Unhandled, it is the same `A2003`
+  as before: the façades throw `AvNotFoundError` and HTTP answers `404`. A `find.first`, `update.first` or
+  `delete.first` that matches no row still resolves `null`, and its `after` hooks run.
+
+  Performance: field write guards and field pipes are dispatched from lists planned at startup, per origin and
+  Resource. A call to a Resource with no field guard reads no record for one, a `create.many` walks its records for
+  guards only when a guarded field is registered, and nested data is walked for guards only when some guard exists.
+
+- Breaking: required create fields are typed. Each Resource now states what a create cannot do without, and every
+  create payload is typed by it: `framework.application`, `framework.client`, `appTx`/`clientTx`, a stage's `ctx` and
+  typed `args`, and generated clients. Leaving out a required field is a type error, and so is writing a required
+  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" } }); // type error: `author` or `authorId`
+  await framework.application.Post.create.one({ data: { authorId } }); // type error: `title`
+  ```
+
+  It covers `create.one`'s `data`, every `create.many` and `create.count` record, `upsert`'s `create`, and nested
+  `$create`, `$connectOrCreate` and `$upsert` payloads. A create nested through a relation gets that relation from its
+  parent, so `author: { $create: … }` is not needed inside `Author.posts.$create`. A `$ref` satisfies a field.
+
+  The fact is a new optional member of every Resource in every Contract, `createRequirements`
+  (`AvCreateRequirements`, `AvCreateRequirementGroup`): `required` (fields), `oneOf` (each required to-one relation and
+  the fields holding its reference, `[["author", "authorId"]]`; a composite reference is all of its fields together),
+  and `parentSupplies` (what a nested create gets from its parent). Each layer's Contract states only what that layer
+  lets a caller write: when the layer hides `authorId`, `author` alone is required; when it hides `author`, `authorId`
+  is. A field a `compute.create` stage fills is not required. The Client Contract's hash changes for every schema with a
+  required field or relation, so regenerate your clients.
+
+  Adapter authors: the requirements move from the adapter's own `createRequirements` table, which is removed, onto its
+  model (`AvAdapterResource.createRequirements`, the same shape as the Contract's, before any layer is applied). A name
+  there that is no field of the right kind fails construction with `COMPILER_UNKNOWN_FIELD`.
+
+  The runtime check is unchanged in what it answers (`A2004` with `V1000` at the missing field, or at the relation where
+  the caller may write it; `V1012` for both), and now reads the active Contract's statement. Two consequences: a
+  relation the layer requires alone is reported without naming a reference field the layer hides, and a required
+  relation's reference fields come from the statement, so an adapter that states no referential edges still has a
+  required relation written either way.
+
+  A field an operation pipe fills on the server is now required of the caller. Give it a `compute.create` stage or a
+  database default so callers can leave it out, or have them pass it.
+
+  A layer that still creates a Resource can no longer leave a requirement unwritable. Hiding a required field (or
+  exempting its `create` capability), or a required relation together with a reference field it needs, while the layer
+  keeps a `create` or `upsert` variant or a nested create into the Resource, fails construction with
+  `COMPILER_HIDDEN_REQUIRED_FIELD`. A composite reference is written whole: each of its blocked fields needs a
+  `compute.create`. For example:
+
+  ```text
+  the client layer still creates resource "Post" (create.one, upsert.unique) but hides its required field "tenantId",
+  which every create must write; expose "tenantId", give "tenantId" a compute.create, or exempt the create operation
+  ```
+
+  A pipe that filled the hidden field is not enough. Move the value into a `compute.create` stage on the field (at the
+  root or in that layer), keep the field exposed, or exempt the layer's create operations.
+
+  A `create.many` or `create.count` record cannot write a relation, so a required relation is met there by its
+  reference fields alone. In those records `authorId` is plainly required by the types, and a record without it answers
+  `A2004` with `V1000` at `data.<n>.authorId` (before, a layer that hid `authorId` let it reach the database, which
+  answered `A3001`). A layer that hides `authorId`, even with `author` exposed, while it keeps `create.many` or
+  `create.count` now fails construction with `COMPILER_HIDDEN_REQUIRED_FIELD`:
+
+  ```text
+  the client layer still creates resource "Post" in bulk (create.count, create.many) but hides its reference field
+  "authorId", which every bulk create must write: a bulk record cannot write the relation "author"; expose "authorId",
+  give "authorId" a compute.create, or exempt create.count and create.many
+  ```
+
+  A `compute.create` written inline in `createFramework({ ... })` without parameter types now counts, at the root and in
+  an overlay: the field it fills is no longer required by the types. Before, such a stage made the whole inline
+  configuration's type fall back to the untyped one, so the façades ignored it (and everything else the literal stated).
+  For that, a `compute.create` or `compute.update` stage's `field` and `data` are keyed by `string` now, not by your
+  field names; their values were `unknown` already. `AvComputeCreate` and `AvComputeUpdate` take the model alone
+  (`AvComputeCreate<Model>`).
+
+- Breaking: the root key `entrypoint` is now `api`, and `framework.entrypoint` is `framework.api`. The value is the
+  same mount path, normalized the same way:
+
+  ```ts
+  createFramework({ api: "/api", adapter });
+  ```
+
+  `entrypoint` is refused with `CONFIG_MOVED_PROPERTY` ("entrypoint moved in rc.1: use api") and is a type error. A
+  generated client still takes `entrypoint` (the server's URL), and so do `defineClientConfig` and
+  `avclient init --entrypoint`: those name where a client points, not where the server mounts.
+
+- New: the `agent` layer and the Agent Contract, the base for serving AI agents over MCP. `agent` holds the six layer
+  keys an overlay holds, plus `extends`: the layer it starts from, `"client"` (the default), `"application"` or
+  `"root"`. Its view is that layer's final view, narrowed by its own `exposed`/`exemptions`; it never widens it. An
+  exemption that would expose what its parent hid fails construction, and the message names the parent:
+
+  ```text
+  field "Post.body" is hidden by client, the layer agent extends, and the agent layer only narrows that view;
+  expose it in client, or extend a layer that exposes it
+  ```
+
+  Stages run along the chain: the root's, then the parent overlay's, then the agent's, level by level, and every stage
+  is told `ctx.$origin === "agent"` (`AvRequestOrigin` and `AvConfigLayerName` gain `"agent"`). Compute chains the same
+  way. `limits` and `transactionsStyle` are the parent's effective values unless the agent states its own. Left out,
+  the agent layer is its parent's view exactly. `defineResource` takes an `agent` block beside `application` and
+  `client`.
+
+  The layer compiles to `framework.contracts.agent` (`AvContractAgent`), built and identified like the Client Contract:
+  its protocol version and its own hash over its own content, so an agent that exposes what the client exposes has the
+  client's hash. Required create fields, hidden-requirement checks and `forceTransaction` checks apply to it as to any
+  layer, and a refusal names `agent`.
+
+  `AvProtocol.bind(framework, { origin: "agent" })` runs agent calls through the same decoding and validation as HTTP
+  client calls: its surface and `/_contract` are the Agent Contract's, the identity headers must carry the Agent
+  Contract's hash (the Client Contract's is `A2005`), and the calls run under the agent's pipelines. The default
+  binding is unchanged. `framework.execute` and `executeTransaction` take `origin: "agent"` with the Agent Contract's
+  protocol identity.
+
+- New: the root key `mcp` turns MCP on. It is a mount path (`mcp: "/mcp"`), or `{ path, authorization }` where
+  `authorization` is `{ servers, verify }`: the OAuth authorization servers (https URLs) a caller gets its token from,
+  and `verify(token)`, which resolves the caller or `null`. The path is written as `api` is and must not be `api` itself
+  or inside its `_` namespace. Each mistake is a startup error at its path (`mcp.path`,
+  `mcp.authorization.servers[1]`, …). The resolved endpoint is `framework.mcp` (`AvMcpEndpoint`), for the host that
+  serves it; `undefined` when MCP is off. `agent` without `mcp` is allowed.
+
+- New: `AvDiagnostic` has a third kind, `AvMcpDiagnostic` (`kind: "mcp"`). When the MCP endpoint itself fails, outside
+  any tool call's operation (the MCP SDK's server or transport), the caller gets a bare `500` and the diagnostics sink
+  gets the raw error with `code: "A3000"`, `origin: "agent"` and a minted `requestId`. A sink that narrows on `kind`
+  now has three arms.
+
+- Faster startup: each remote Contract (client and agent) is written as canonical JSON once. Its hash, the Contract
+  object and the `/_contract` body all come from that one text instead of four separate passes. The bytes and
+  hashes are unchanged. `createFramework` plus binding the client and agent protocols took 186 ms at 117 Resources and
+  now takes 133 ms (90 to 67 ms at 50, 20 to 15 ms at 6).
+
+- Smaller edge bundles: `@aventara/core/avz` imports only the zod builders it uses, so a bundler drops the rest of
+  `zod/mini`, its locales included. A minified bundle of the entry went from 453 KB to 48 KB.
+
 ## 1.0.0-rc.0
 
 ### Major Changes
@@ -185,6 +2251,7 @@
 
   A value whose first read throws is now refused even if reading it again would succeed: `A2004`/`V1001` at the object
   or array whose read failed. Before, it was copied from the second read.
+
 - 2d00ad7: An issue your own code throws from a transaction step now keeps its `path`. A pipe, guard, hook, interceptor,
   filter or computed behavior does not know where its operation stands in a plan, so it writes the path as it would for
   a single call — `["arguments", "data", "name"]`. Inside `framework.transaction`, `framework.executeTransaction` and
@@ -200,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"`