@aventara/prisma7-adapter 1.0.0-rc.1 → 1.0.0-rc.10

package/CHANGELOG.md

@@ -1,5 +1,423 @@
 # @aventara/prisma7-adapter
 
+## 1.0.0-rc.10
+
+### Patch Changes
+
+- 04bb39a: `engines.node` is now `^22.23.4 || >=24.22.1`, the Node security releases of 2026-10-20 (CVE-2026-105481,
+  CVE-2026-105482, CVE-2026-105483, CVE-2026-106069, CVE-2026-106072, CVE-2026-106073, CVE-2026-106074,
+  CVE-2026-111497). The bins refuse an older Node in one sentence naming that range.
+- 827ccb6: A listed update (`afterChecks`) no longer refuses an unchanged row on PostgreSQL. The compare-and-swap that holds the
+  write to the rows as they were read compares each field by `equals`, and the adapter's `equals` now matches every row
+  that reads as the value:
+
+  - a scalar list a create left out, which Prisma stores as `NULL` and reads as `[]`: an operator object that holds for
+    `[]` (`equals: []`, `isEmpty: true`, `hasEvery: []`) holds for that row too, in every filter;
+  - a timestamp finer than a millisecond (a `@db.Timestamptz(6)` the database writes), which Prisma reads truncated:
+    equality with an instant also holds the instants inside its millisecond.
+
+  On a `Bytes[]` column, `equals`, `hasEvery` and `hasSome` are no longer offered: Prisma 7.10.1 binds their operand's
+  members as base64 text, so they matched other rows than they named. `has` and `isEmpty` remain. Such a column is not
+  part of the compare-and-swap.
+
+  The compare-and-swap takes its fields from what the adapter compares, so an exemption that hides `equals` from callers
+  no longer takes a field out of it.
+- 4f0fd29: The Prisma 7 adapter's peer floor is now `^7.10.1` (`prisma`, `@prisma/client`, `@prisma/adapter-pg`,
+  `@prisma/adapter-better-sqlite3`). `prisma` 7.10.0 pins `mysql2` 3.15.3 (GHSA-3f6p-5ww8-9rcr, GHSA-rgwj-5xj2-c3m3)
+  and, through `@prisma/config`, `deepmerge-ts` 7.1.5 (GHSA-ggr8-5vv4-36mx); 7.10.1 pins `mysql2` 3.24.4 and
+  `deepmerge-ts` 8.0.2. `aventara new` and `aventara init` install Prisma at the floor, so new projects get 7.10.1, and
+  `aventara init` refuses a project whose Prisma is below it.
+- f52c499: The generate step reads multiSchema's `@@schema("auth")`: a model states its PostgreSQL schema in the discovery
+  artifact (`schema`), and the Core Contract carries it. Until now `@@schema` stopped the build. On an enum it is read and
+  dropped. A model whose table another service owns is marked `managedElsewhere: true` in the Aventara configuration and
+  listed in `prisma.config.ts` as an external table (`experimental.externalTables`, `tables.external`), so neither
+  Aventara writes it nor `prisma migrate` changes it.
+- 10341d5: Policy checks, tightened:
+
+  - Writing a reference field itself (`authorId: "u2"`) is held to the target's read scope, as `$connect` is: the row it
+    names must be one the caller may read, or the write is refused (`A4002`). Creates, updates, both branches of an
+    upsert and the records of nested writes are all checked. The reference is handed to the adapter as a `$connect` that
+    carries the read scope, so the write itself refuses a row outside it, with no extra query; a row that is not there is
+    refused the same way. Where Prisma's input takes no relation (`createMany`, `updateMany`, a to-many nested
+    `$update`), and where a create writes a reference `null` (left out, the column's default would fill it), one count
+    per target Resource asks before the write whether every row named is there and readable. Nothing is asked where that
+    Resource is read by everyone, and a `null` reference is not asked about. A record written this way writes its other
+    references as links too, so a missing row there answers `A2003` rather than `A2008`.
+  - A row a write names to link that is not there is refused (`A4002`) like a row the caller cannot read, wherever the
+    target has a scope: a reference field, and a `$connect`, `$set` or `$disconnect` selector. Before, a missing row
+    answered the store's `A2008` or `A2003`, which told a caller which rows it cannot read exist. Without a scope, the
+    codes are unchanged.
+  - An update the engine lists in `afterChecks` now holds a to-one nested `$update` to its row as it was read. A row a
+    concurrent write changed in between refuses the write (`A4002`) and rolls it back, with no extra query.
+  - A listed `update.many` or `update.count` that changes fewer rows than it read (a concurrent write changed one in
+    between) is refused (`A4002`) and rolled back, rather than answering a partial success.
+  - The client and agent Contracts leave out an enum that only a Resource managed elsewhere uses. The ClientContract hash
+    of an app with such an enum changes.
+  - Seven public types write their members out in an editor's hover instead of naming a type no entry exports (`ctx.$sql`,
+    a compute stage's context, a pipe's return, `defineResource`'s overlays, a family's variants, the `access` and
+    `policy` check, `AvConfigComputedFields.agentExtends`).
+
+- 88263a1: On PostgreSQL, a scalar list Prisma stored as `NULL` (a create left it out; it reads as `[]`) now answers every list
+  filter as `[]` does, negated ones included: `NOT { tags: { has: "a" } }` (and `hasSome`, `hasEvery`, `isEmpty: false`,
+  `equals: [x]`) holds for that row. Inside a relation's `every`, a related row whose list was never written fails
+  `every: { tags: { has: "a" } }` as an empty list does, so its parent is no longer kept.
+- Updated dependencies [587dd01]
+- Updated dependencies [d7e7369]
+- Updated dependencies [7ee547b]
+- Updated dependencies [f52c499]
+- Updated dependencies [2907484]
+- Updated dependencies [a6bbdf0]
+- Updated dependencies [3e26549]
+- Updated dependencies [a6bbdf0]
+- Updated dependencies [6f3f6f6]
+- Updated dependencies [04bb39a]
+- Updated dependencies [3fb3333]
+- Updated dependencies [827ccb6]
+- Updated dependencies [7f5abc3]
+- Updated dependencies [88263a1]
+- Updated dependencies [10341d5]
+- Updated dependencies [8129844]
+- Updated dependencies [88263a1]
+- Updated dependencies [3020b5c]
+- Updated dependencies [88263a1]
+- Updated dependencies [88263a1]
+  - @aventara/core@1.0.0-rc.10
+
+## 1.0.0-rc.9
+
+### Patch Changes
+
+- Updated dependencies [205a379]
+- Updated dependencies [a0bb05e]
+- Updated dependencies [86ab319]
+- Updated dependencies [fdf52e6]
+  - @aventara/core@1.0.0-rc.9
+
+## 1.0.0-rc.8
+
+1.0.0-rc.5, rc.6 and rc.7 were tagged but never published; 1.0.0-rc.8 contains everything listed under them and the changes below.
+
+### Patch Changes
+
+- 1c8e4ee: The discovery artifact's referential actions say `referenceFields` where they said `references`: in
+  `referentialActions.<Resource>.owningEdges[]`, the fields of the Resource itself that hold the reference
+  (`@relation(fields: [...])`). The model's relation fields already use `references` for the target's fields
+  (`@relation(references: [...])`) and `referenceFields` for these, so the same word meant two different lists in one
+  file. The generated `discovery.artifact.ts` changes on the next `aventara:prepare` (it runs on install, build and
+  start), and only in those keys: `modelHash` is unchanged, since the referential actions are outside it, and so is the
+  prebuilt Contracts file `aventara-build` writes. Code that read `owningEdges[i].references` reads
+  `owningEdges[i].referenceFields`.
+- Updated dependencies [1c8e4ee]
+  - @aventara/core@1.0.0-rc.8
+
+## 1.0.0-rc.7
+
+1.0.0-rc.5 and 1.0.0-rc.6 were tagged but never published; 1.0.0-rc.7 contains everything listed under them and the changes below.
+
+### Patch Changes
+
+- Updated dependencies [f917c1c]
+  - @aventara/core@1.0.0-rc.7
+
+## 1.0.0-rc.6
+
+1.0.0-rc.5 was tagged but never published. 1.0.0-rc.6 contains everything listed under 1.0.0-rc.5 and the fix below.
+
+### Patch Changes
+
+- Updated dependencies [1cf72e0]
+  - @aventara/core@1.0.0-rc.6
+
+## 1.0.0-rc.5
+
+### Patch Changes
+
+- 4795ff1: Two additions for policy engines. A Framework without a policy, and every Contract a caller is served, are unchanged.
+
+  - A policy engine can check a create whose row reaches another Resource through a relation. Discovery now states, on the end of a relation that holds the reference, which of the target's fields its reference fields name, pair by pair (`Note.campaign`: `referenceFields: ["campaignId"]`, `references: ["id"]`). An engine reads them from the model it is built from (a Prisma discovery artifact's `model`) or from `framework.contracts.core`, and asks one `exists` about the row they name: "a player creates a note only in a campaign they play in". Only the adapter's model and the Core Contract carry them. The Application, Client and Agent Contracts, `/_contract`, the MCP tools and every ClientContract hash are unchanged. The discovery artifact's model hash, and so a prebuilt Contracts file's fingerprint, change: regenerate the artifact and rebuild the prebuilt file.
+  - `fieldsOf({ access: "write" })` also names the action that writes the record, `action: "create" | "update"` (an upsert's branches each their own, a nested record its directive's), so an engine can lock a field on update and still let a create write it. A read question names none. An engine that ignores it keeps working.
+
+- 9e178ca: Fixes for applications that check requests with a policy engine. A Framework without a policy behaves as before.
+
+  - A cursor on a row the caller cannot read is answered exactly as a cursor on a row that does not exist, at the root and in a to-many relation, whatever values the caller sends beside the identifier. Before, the page started at the hidden row, so it told that the row exists and where its values sort. The Prisma adapter reads the cursor's row under the read scope first: one statement more for a cursor on a readable row, and only that read for one on a row the caller cannot read.
+  - A unique update with a nested write (`$create`, `$connect`, …) on a row the caller can read but not change answers `A4002`, as the same update without one does. It answered `A2003`. A row the caller cannot read still answers `A2003`.
+  - The `exists` questions a policy asks select the Resource's primary identifier, never another unique field such as a governed `email`.
+  - `policy.principal` may answer with a promise. A synchronous principal works as before; a rejection answers `A3000`, as a throw does.
+  - `AvConstructionError.message` names the first problem and how many more there are, for example `Aventara framework configuration validation failed: CONFIG_INVALID_TYPE at adapter.execute: adapter.execute must be a function (+2 more)`. `stage` and `diagnostics` are unchanged.
+
+## 1.0.0-rc.4
+
+### Patch Changes
+
+- 7c3b65f: Build-time Contracts for serverless and edge cold starts.
+
+  - New package `@aventara/build`, bin `aventara-build`, a development dependency. It runs `src/aventara.config.ts` and
+    `src/aventara.adapter.ts` without a database client, compiles the Contracts with the project's `@aventara/core` and
+    writes `src/generated/aventara/contracts.generated.ts` (`aventaraContracts`), which a serverless or edge entry passes
+    to `createFramework` as `prebuilt`. A configuration that startup would refuse fails the build with the same
+    `CONFIG_…`/`COMPILER_…` diagnostics. `aventara-build --check` writes nothing and exits 1 when the file is missing or
+    stale, naming the Resources that changed.
+  - `@aventara/prisma7-adapter`: `describePrismaAdapter({ discovery, provider, driver })` states the adapter's passive
+    facts (the model, the driver's transaction capability, the referential actions, the computed fields) with no client.
+    `createPrismaAdapter({ ...description, client })` builds the adapter from the same facts, and still checks the client
+    against the discovery artifact.
+  - `@aventara/cli`: the scaffold's `src/aventara.config.ts` exports the configuration as a plain value
+    (`export const aventaraConfig = { … } as const`) with no `adapter`. A new `src/aventara.adapter.ts` default-exports
+    `describePrismaAdapter(…)`, and `app.module.ts` joins the two:
+    `config: { ...aventaraConfig, adapter: await createPrismaAdapter({ ...adapter, client: prisma }) }`. The Nest server
+    still compiles its Contracts at startup and passes no `prebuilt`. `aventara:prepare` ends with `&& aventara-build`,
+    and `@aventara/build` is an exact development dependency.
+
+- 2b1b17e: `aventara-build`'s files no longer land inside a Prisma client generated into `src/generated`.
+
+  When `aventara init` reuses a project whose Prisma client is generated into `src/generated`, it already puts the
+  discovery artifact in `src/aventara/`, because `prisma generate` deletes every file in its output directory that it did
+  not write. `aventara-build` still wrote its three files to `src/generated/aventara/`, so each `prisma generate` deleted
+  them and the project stopped compiling until the next `aventara:prepare`. Now all of Aventara's generated files are
+  in one place.
+
+  - `@aventara/build`: `aventara-build` writes `resources.generated.ts`, `computed-fields.generated.ts` and
+    `contracts.generated.ts` to the directory the configuration imports `aventaraResources` from, so the tree is always
+    written where the configuration reads it. A configuration that imports no tree keeps `src/generated/aventara/`.
+    The files of a project whose client is generated anywhere else are the same bytes, in the same place.
+  - `@aventara/prisma7-adapter`: with `--config`, the artifact imports the computed fields from its sibling,
+    `./computed-fields.generated`, wherever `--out` puts it. `--config` is still required for that import and the step
+    still checks that the file exists, but the step no longer uses its location. A scaffold's artifact is unchanged.
+  - `@aventara/cli`: in that project, `src/aventara.config.ts` imports the tree from `./aventara/resources.generated`,
+    and `.gitignore` gets the one `/src/aventara/` line that covers all four files (no separate
+    `/src/generated/aventara/contracts.generated.ts` line). The agent skill says where the generated files are in
+    both cases.
+
+- 3a0dfca: A write the policy checks costs fewer database round trips. What each check decides and refuses is unchanged.
+
+  - A single-row update or delete carries the caller's scopes inside its own `where` and runs as one statement, with no
+    read of its row before it. One that matches nothing still answers `A4002` when the caller can read the row and
+    `A2003` when it cannot, with one lookup on that miss only. The Prisma adapter sends it as
+    `update({ where: { id, AND: [scope] } })`.
+  - A create asks `can({ action: "create", row })` and its `exists` lookups before the insert, without a transaction. A
+    transaction around them never closed the race between the lookup and the insert at the database's default
+    isolation, and cost a BEGIN and a COMMIT.
+  - A transaction opens only when a check after the write may roll it back: an update's after check or move-out, a
+    created row held to a write grant, a nested write, or returned rows checked by `exists`. A plain checked create or
+    delete is one statement, its interceptors and hooks outside any transaction.
+  - The after check asks `can` about the row the update returned, so it reads nothing again. Only a move-out reads the
+    changed rows again. An `update.count` runs as the returning `update.many` when the Contract offers it.
+
+  Round trips per request on PostgreSQL: `create.one` 3 → 1, `delete.unique` 4 → 1, `update.unique` 5 → 3,
+  `update.many` 4 → 3, `update.count` 5 → 3. Reads, and a Framework without a policy, are unchanged.
+
+- 3813207: The Resource tree and the computed fields come from `aventara-build`.
+
+  - `@aventara/build`: before it compiles the Contracts, `aventara-build` writes two more files under
+    `src/generated/aventara/`. `resources.generated.ts` exports `aventaraResources`: every `defineResource(…)` result
+    that the files `src/resources/**/*.resource.ts` export, found by its type (never run), one `resources` tree per
+    layer, written as the plain spreads you wrote by hand (`root` always, `application`, `client` and `agent` when some
+    Resource has a block for them). Two definitions of one Resource stop the build, naming both. Imports are spelled as
+    the project spells its own. `computed-fields.generated.ts` exports `computedFields` and its type `AvComputedFields`:
+    which fields the configuration's write compute fills, read off its type after the tree exists, so a fresh install is
+    typed right on its first `aventara:prepare`. `--check` covers all three files. `typescript` (`>=5.7.0 <7`) is now a
+    peer dependency.
+  - `@aventara/prisma7-adapter`: the generate step no longer reads the configuration. With `--config`, the discovery
+    artifact imports `computedFields` and `AvComputedFields` from the file `aventara-build` writes beside the
+    configuration (`generated/aventara/computed-fields.generated.ts`); a `--config` file that does not exist is still
+    refused. `readConfigComputedFields`, `AvPrismaConfigReaderError` and `ConfigComputedFieldsReading` are removed from
+    `@aventara/prisma7-adapter/generate`, as are `PrismaGenerateToolchain.readComputedFields` and
+    `PrismaGenerateResult.computedFields`.
+  - `@aventara/cli`: the scaffold's `src/aventara.config.ts` takes its Resources from the tree,
+    `resources: aventaraResources.root`, so a new Resource file needs no configuration edit; the agent skill says so.
+
+- Updated dependencies [e3d03a7]
+- Updated dependencies [d10639a]
+- Updated dependencies [f67e68c]
+- Updated dependencies [708556c]
+- Updated dependencies [3a0dfca]
+- Updated dependencies [99169d2]
+- Updated dependencies [0fd2608]
+- Updated dependencies [154e440]
+- Updated dependencies [2fcffdb]
+  - @aventara/core@1.0.0-rc.4
+
+## 1.0.0-rc.3
+
+### Patch Changes
+
+- b38034d: `aventara-prisma7-generate` refuses a `--provider` that the schema's `datasource` block contradicts, or a block naming
+  a provider the adapter does not support, before `prisma generate` runs, so neither the Prisma client nor the artifact
+  is written:
+
+  ```text
+  aventara-prisma7-generate: --provider postgresql contradicts the schema's datasource `db` (prisma/schema.prisma:12), which names provider "sqlite"; pass --provider sqlite.
+  ```
+
+  PSL's `postgres` spelling counts as `postgresql`, and a provider that is not a string literal is not compared.
+  Before, the flag was taken on trust, and a wrong one wrote the wrong provider into the artifact and the wrong filter
+  modes into the Contract.
+
+  When the file system refuses the artifact file (`--out`), the step says so in one sentence naming the file and why,
+  such as
+  `the artifact file /app/src/generated/aventara/discovery.artifact.ts (--out) cannot be written: permission denied (EACCES).`,
+  and leaves no staged file behind. Before, every such failure except a directory printed a stack trace.
+
+- b38034d: On PostgreSQL, a `@unique` value too long for its index (an index row past the B-tree's limit of about 2704 bytes, SQLSTATE
+  `54000`) is answered `422 A2004`, not `500 A3001`: one `V1004` issue at `["arguments"]`, as a value too long for its
+  column already was. The adapter reads the SQLSTATE, never the message. The issue's message for a value too long now
+  reads `The database refused this value: it is longer than the database can hold for its column.`
+  (it said `longer than its column can hold`, which an index refusal is not).
+- Updated dependencies [b38034d]
+- Updated dependencies [b38034d]
+- Updated dependencies [b38034d]
+- Updated dependencies [b38034d]
+- Updated dependencies [b38034d]
+- Updated dependencies [b38034d]
+  - @aventara/core@1.0.0-rc.3
+
+## 1.0.0-rc.2
+
+### Patch Changes
+
+- On Cloudflare D1, a `BigInt` value beyond ±(2^53 − 1) is answered `A2004`, not `A3001`. `@prisma/adapter-d1`
+  binds a bigint as a JavaScript number and refuses one beyond that range before the statement runs, written,
+  compared in a filter or used in an `$increment`, and Prisma reports it as a database error (`P2039`). The adapter
+  answers that refusal as a value the database refused: `422 A2004` with one `V1004` issue, `The database refused
+this value: it is outside the range its column can hold.`, at the value in the arguments (for example
+  `["arguments", "where", "views", "gt"]`). Nothing is written by the refused statement. It reads the arguments only
+  after the driver refused them, and only for the D1 driver; every other D1 database error stays `A3001`, and so does
+  a raw `ctx.$sql` statement binding such a value. Within ±(2^53 − 1) a bigint round-trips exactly on D1.
+  In rc.1 the refusal answered `500 A3001`. Measured on 7.10.0 through Miniflare's D1 binding.
+- The README's D1 notes are corrected: D1 is measured in process through Miniflare, where Prisma's client refuses
+  an interactive `$transaction` and the D1 driver runs Prisma's implicit transaction for a nested write as single
+  statements, so a nested write is not atomic on D1.
+- The optional `typescript` peer range is `>=5.7.0 <7` (it was `>=5.5.0 <7`). Under TypeScript 5.5 and 5.6 a
+  variant's stages written inline in `createFramework` are told `unknown` arguments, so `ctx.$args.data` and the
+  documented spread pipe `(args) => ({ ...args, data: { ...args.data, title: "t" } })` do not compile; TypeScript 5.7
+  and later type them. A project on TypeScript 5.5 or 5.6 upgrades to 5.7 or later.
+- `createPrismaAdapter` checks the installed `@prisma/client`'s major against the discovery artifact's, as the
+  README says. It reads the version from `@prisma/client/package.json`, resolved from the adapter's own location and
+  then from the working directory, and refuses an artifact generated against another major with
+  `AvPrismaDiscoveryArtifactError`. In rc.1 the artifact's version stood in for the installed one when no
+  `installedPrismaVersion` was passed, which a scaffolded project never does, so the check compared the artifact with
+  itself. Where the version cannot be read (a runtime without Node's module loader, a bundle deployed without
+  `@prisma/client`), the adapter starts and emits a warning, code `AVENTARA_PRISMA_VERSION_UNCHECKED`, saying the
+  majors were not compared. `installedPrismaVersion` still overrides the version read.
+- `aventara-prisma7-generate` refuses an `--out` inside `--client`, before `prisma generate` runs: exit 1 and one
+  sentence naming both paths. Prisma's next `prisma generate` clears the client's directory, so an artifact written
+  there was deleted. In rc.1 the step wrote it and exited 0. The same refusal applies to
+  `generatePrismaDiscoveryArtifact` and `runPrismaGenerateStep`.
+- `aventara-prisma7-generate` refuses an `--out` that names a directory in one sentence (exit 1), before
+  `prisma generate` runs. In rc.1 it ran Prisma and then failed with an `EISDIR` stack trace.
+- A nested write that writes its relation back is answered `A2004`, not `A3001`. Prisma writes a record reached
+  through a relation without that relation's other end, so it refuses a post created in `author.posts` that names
+  `author` or `authorId`, and a category created in a post's `category` that nests `posts`. The discovery artifact
+  now states each relation's other end (`inverse`, paired from the schema by relation name) and no relation writable
+  at the `"loopback"` position, so `@aventara/core` refuses such a write before any guard or SQL: `A2004`, `V1012` at
+  the field written back. It holds for `$create`, `$connectOrCreate`, `$update` and `$upsert`, to-one and to-many,
+  self-relations and one-to-ones. Where a layer hides the relation's other end, its Contract states no pairing and
+  Prisma's client is the one that refuses: the adapter answers that refusal as the caller's too, `A2004` with a
+  `V1012` issue at the field and the message `The data source refused this nested write: a record written through a
+relation cannot write that relation or its reference fields back.` It reads the arguments only after Prisma
+  refused them; every other refusal of Prisma's client stays `A3001`. In rc.1 every case answered `500 A3001`.
+  Measured on 7.10.0, SQLite and PostgreSQL. Run `npm run aventara:prepare` to regenerate the artifact: the model's
+  hash and every Contract's hash change.
+- The discovery artifact states each relation's reference fields (`referenceFields`, read from the schema's
+  `@relation(fields: …)`), on optional and required relations alike, and none on the end that holds no reference.
+  So the types leave `categoryId` out of a post created in `Category.posts`, as `@aventara/core` refuses it. Run
+  `npm run aventara:prepare` to regenerate the artifact: the model's hash and every Contract's hash change.
+- A `$divide` by zero is answered `A2004`, not `A3001`. It reaches the database as given: PostgreSQL refuses the
+  division (`P2039`, `22012`) and the adapter answers `V1004` `The database refused this value: it divides by zero.`;
+  SQLite computes NULL and the `NOT NULL` column refuses it (`P2011`), answered `V1004` `The database refused this
+value: the write computes no value for a column that requires one, as a division by zero does.` Both at
+  `["arguments"]`, nothing written. `P2011` reaches the adapter only this way: core refuses a `null` for a required
+  field and a missing one, and so does Prisma's client before the query. In rc.1 both answered `500 A3001`. Measured
+  on 7.10.0 for `Int`, `BigInt`, `Float` and `Decimal`, in `update` and `updateMany`.
+- `null` on a nullable `Json` field is the database NULL, as on every other nullable field. A write of `null`
+  (create, update, upsert, bulk, nested, a plan step) is sent as Prisma's `DbNull`; `{ meta: null }` and
+  `{ meta: { equals: null } }` are sent as Prisma's `AnyNull` and match every row that reads back `null` (a database
+  NULL or a JSON `null` stored by other means), and `{ meta: { not: null } }` matches the other rows. A JSON `null`
+  inside a value is sent as written, and so is a `null` beside a `path`: Prisma matches the documents whose value at
+  that path is a JSON `null`. In rc.1 a write of `null` stored a JSON `null`, `equals: null` matched only the stored
+  JSON nulls, and `{ meta: null }` failed with `500 A3001`. Reads are unchanged. Measured on 7.10.0, SQLite and
+  PostgreSQL.
+- A to-one relation filter is sent under Prisma's `is`. `{ category: {} }` matches the rows that have a related row and
+  `{ NOT: { category: {} } }` the rows that have none. In rc.1 the empty predicate was sent unwrapped, which Prisma
+  reads as no condition: both matched every row, and `Post.delete.count({ where: { NOT: { author: {} } } })` deleted
+  every post although each has its required author. A non-empty nested `where` and `null` match what they did.
+- A value the database refuses is answered `A2004`, not `A3001`. Text-match operands and written values reach Prisma
+  as given (`%` and `_` are what the engine's `LIKE` makes of them, a column rounds or keeps what it does); when
+  PostgreSQL refuses a caller's value, the adapter answers `A2004` with one issue at `["arguments"]` (Prisma's error
+  names no column): `V1004` for a value too long for its column (`P2000`), out of its column's range (`P2020`: a
+  `Decimal` past its precision, `Number.MAX_VALUE` in a `Float`, an `Int` `$increment` past 2^31) or a `DateTime`
+  outside PostgreSQL's range (`P2039`, `22009`); `V1001` for U+0000 in text or `json` (`P2039`, `22021` and `22P05`),
+  a lone surrogate in `json` (`P2007`) and a `LIKE` pattern ending in `\` (`P2039`, `22025`). The issue's message
+  says which of these the database refused, in core's words and none of the database's (`The database refused this
+value: it is longer than its column can hold.`), not the code's generic text. Inside a plan the
+  issue stands at the step (`["operations", i, "args"]`) and the plan rolls back. Every other database failure stays
+  `A3001`. In rc.1 each of these answered `500 A3001`. Measured on 7.10.0, SQLite and PostgreSQL; SQLite refused none
+  of these values.
+- A field's `not` holding an operator object now means the negation of the whole object, on every field type, on
+  both engines, in reads and in bulk writes. `{ f: { not: X } }` matches exactly the rows `{ NOT: { f: X } }` matches:
+  a row where `X` is neither true nor false (the column is `NULL`, a `json` `path` is not in the document, a `json`
+  value is not the kind the operator reads) matches neither `X` nor `not: X`, as SQL's `NOT` reads it. The adapter
+  sends it to Prisma as `NOT` of the field's filter, ANDed with the rest of the `where`, because Prisma's own
+  field-level `not` says less (measured on 7.10.0, SQLite and PostgreSQL):
+
+  - In rc.1, a `json` field's `not` holding operators matched every row on both engines, because Prisma reads that
+    `not` as a JSON value to compare the document with. That covers `{ meta: { not: { path: ["label"],
+stringContains: "x" } } }`, `{ meta: { not: { equals: { a: 1 } } } }` and every other operator under it, and an
+    `update.many`, `update.count`, `delete.count` or `delete.first` under such a filter wrote or deleted every row
+    the rest of the filter allowed.
+  - In rc.1, two or more operators under `not` were negated one at a time and ANDed, so
+    `{ views: { not: { gt: 2, lte: 5 } } }` matched no row. It now matches the rows outside that range.
+  - In rc.1 on PostgreSQL, a `mode` inside `not` (`{ title: { not: { contains: "x", mode: "insensitive" } } }`)
+    failed with `A3001`, because Prisma's filter under `not` has no `mode`. It now matches the titles that do not
+    contain `x` in any case.
+
+  The object under `not` is its own level: nothing from the object around it reaches into it. In rc.1 on
+  PostgreSQL, `{ title: { mode: "insensitive", not: { contains: "x" } } }` excluded `X` as well as `x`, because Prisma
+  applied the outer `mode` inside its own `not`. Core now refuses that filter (`A2004`, `V1001` at the `mode`); write
+  `{ title: { not: { contains: "x", mode: "insensitive" } } }`. A plain value under `not` (`{ not: "x" }`,
+  `{ not: null }`) is equality negated and is sent as before.
+
+- A `json` field's bare value in a filter is equality on both engines: `{ meta: "x" }` and `{ meta: [1, 2] }` are sent
+  to Prisma as `{ equals: … }`. In rc.1 they failed with `A3001`, because Prisma's Json filter takes no bare value.
+- Filter modes, measured on each engine. PostgreSQL offers `"default"`, `"sensitive"` and `"insensitive"` on a string
+  column and on a `json` value at a `path`; on a whole `json` document it offers `"default"` and `"sensitive"`, because
+  Prisma accepts an insensitive `stringContains` there and PostgreSQL then fails (`42883 function lower(jsonb) does not
+exist`, answered `A3001`). That filter is now refused before any query (`A2004`, `V1006` at the `mode`). SQLite, and
+  so D1, offers `"default"` only: its `LIKE` folds ASCII case and nothing else, and `equals` folds none, so neither
+  promise holds. Every string field with a text operator now offers `mode` (on SQLite with `"default"` alone), and
+  `"default"` and `"sensitive"` are sent to Prisma as no `mode` at all. Regenerate the discovery artifact
+  (`aventara:prepare`).
+- 9366e16: The discovery artifact names the model's type: it exports `AvModel`, and `model` is declared with it
+  (`typeof model` is `AvModel`). A project that emits declarations (Nest's `declaration: true`) now writes that
+  name wherever an exported declaration holds the model, instead of the whole model. Over 50 models the scaffold's
+  `aventara.config.d.ts` goes from 485 KB to 0.4 KB, and a `buildFramework` / `AppFramework` module from 931 KB to
+  0.6 KB (1.2 MB to 0.6 KB, and 2.4 MB to 22 KB for exported configurations holding typed stages, in the consumer-build
+  gate). Regenerate the artifact (`aventara:prepare`, which runs on install, build and start) to get it; Contract bytes
+  and hashes are unchanged.
+- New: `aventara-prisma7-generate --config <file>`, optional. Given your Aventara configuration module
+  (`src/aventara.config.ts` in a project set up by `aventara`; its `aventaraConfig` export, a function or a value, or
+  its default export), the artifact states which fields it computes on create and on update, per layer. They are read
+  off the configuration's TypeScript type, never by running it, so nothing connects to a database and no environment
+  is needed. The artifact exports them as `computedFields` (type `AvComputedFields`), carries them on `AvModel` so a
+  variant's guards, pipes and filters may leave exactly those fields out of a create, and hands them to the framework
+  through `discovery.computedFields`, which it compares with the configuration at startup. A configuration that is
+  not a literal where a compute stage is written (one annotated with the wide `AvConfig`, a conditional spread) is not
+  read: the step prints where, and the artifact states nothing, so those stages may leave any create field out. A
+  `--config` file that does not exist, or exports neither `aventaraConfig` nor a default, stops the step.
+  `generatePrismaDiscoveryArtifact` and `runPrismaGenerateStep` take the same `config`, and
+  `readConfigComputedFields` is exported from `@aventara/prisma7-adapter/generate`.
+- The discovery artifact's format is now 4 (`computedFields` is new): an artifact written before it is refused with
+  the regeneration instruction. `aventara:prepare` regenerates it on install, build and start.
+- A transaction that expired (or was closed) under a step is answered `A3002`, as when the COMMIT finds it expired:
+  Prisma's `P2028`, raised by the step's own call, is the transaction's failure, at that step (`cause.operation`),
+  and the plan rolls back. In rc.1 it was unclassified and answered `500 A3001`, an adapter failure. Measured on
+  7.10.0, SQLite and PostgreSQL.
+- Updated dependencies [9366e16]
+- Updated dependencies [9366e16]
+- Updated dependencies [9366e16]
+- Updated dependencies [9366e16]
+  - @aventara/core@1.0.0-rc.2
+
 ## 1.0.0-rc.1
 
 ### Patch Changes