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

package/CHANGELOG.md

@@ -1,5 +1,1438 @@
 # @aventara/core
 
+## 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 +1618,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