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

package/CHANGELOG.md

@@ -1,5 +1,466 @@
 # @aventara/cli
 
+## 1.0.0-rc.10
+
+### Patch Changes
+
+- 82afc5e: The scaffolded configuration's `diagnostics` sink logs `String(error)` when an error's `stack` is empty or missing,
+  instead of an empty `raw error` line.
+
+  `aventara` prints a defect as `String(error)` when its `stack` is empty or missing, instead of a blank or `undefined`
+  line.
+
+- 09585dd: The agent skill's configuration reference covers `managedElsewhere`: a model whose table another service owns, and
+  the Prisma 7 external-tables setup that keeps `prisma migrate` off it.
+- 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.
+- 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.
+- 10341d5: The Next.js scaffold's `src/prisma.ts` keeps one PrismaClient per generated schema: after `aventara:prepare` regenerates
+  the client, the next call makes a new one and disconnects the old one, so `next dev` needs no restart.
+- 88263a1: Startup checks, tightened:
+
+  - An `mcp.authorization.servers` entry with a query or a fragment is refused for https URLs too, not only for loopback
+    http ones: an authorization server's issuer has neither (RFC 8414).
+  - A `client.resources` or `agent.resources` entry for a Resource managed elsewhere is refused (`COMPILER_UNKNOWN_RESOURCE`):
+    those layers never have the Resource, so nothing configured there would run. Configure it at the root or in
+    `application`.
+
+- 88263a1: Documentation: `$access.can([])` answers `[]`, not a refusal; the MCP README states the query and fragment rule for
+  every authorization server.
+
+## 1.0.0-rc.9
+
+### Patch Changes
+
+- a0bb05e: The agent skill that `aventara new`, `aventara init` and `aventara skill` write has a new section, "Calling the API over
+  HTTP", with a working curl example: the operation path uses the model's name as written in the Prisma schema
+  (`/api/_resources/User/create/one`), every request sends the `Aventara-Protocol-Version: 1` and
+  `Aventara-Contract-Hash` headers (the hash comes from `GET /api/_contract`), and a create's body is `{ "data": … }`. It
+  lists the answers each mistake gets. The printed next steps point to it. To refresh the skill in an existing
+  project, run `aventara skill`.
+- 8c40b81: `aventara new` and `aventara init` now scaffold Next.js apps.
+
+  - `aventara new <name> --host next` runs `create-next-app@latest` (TypeScript, the App Router under `src/`, the `@/*`
+    alias, no install of its own), then the same `init` steps, then the install. create-next-app asks its own questions
+    on your terminal; with `--yes` it takes its defaults. Its own flags go after `--`, as they are:
+    `aventara new my-app --host next --yes -- --tailwind`. `--skip-git` becomes its `--disable-git`. Without a terminal,
+    `--yes` is required. `--host` defaults to `nest`: a NestJS project is scaffolded exactly as before.
+  - `aventara init` tells the host by `package.json`: `@nestjs/core` is NestJS 12, `next` is Next.js 16, and a project
+    that depends on both or neither is refused in one sentence, with nothing written. A Next.js app needs `src/app/`
+    and the `@/*` → `./src/*` path in `tsconfig.json`, and no ORM yet.
+  - In a Next.js app, init writes `src/aventara/config.ts`, `src/aventara/adapter.ts`, `src/aventara/server.ts`
+    (`Aventara()`, exporting `handlers`, `avClient`, `avApp` and `ready`), `src/app/api/[...aventara]/route.ts`,
+    `src/instrumentation.ts` (awaiting `ready()` on the Node.js runtime) and `src/prisma.ts`, with Prisma's schema and
+    config. `aventara:prepare` ends with `aventara-build --client` and runs on `postinstall` and `prebuild`; the files it
+    generates (`src/aventara/generated/`, `src/aventara/client.ts`, `src/aventara/universal.ts`) are added to
+    `.gitignore`. An instrumentation file of your own is never replaced: the lines to add are printed.
+  - Each host package now declares its project layout in its manifest (`"aventara": { "host": … }`). The CLI scaffolds
+    from it and `aventara-build` reads its paths from it, so the two always agree.
+
+- 501b832: `aventara new --host next` and `aventara init` in a Next.js app add `serverExternalPackages: ["@aventara/core",
+"@aventara/prisma7-adapter"]` to `next.config.ts`, so Node.js loads them once per server process: every route and
+  page shares one core, one Framework and one Prisma client. The line goes into create-next-app's config, or any config
+  whose `const nextConfig = {` object has no `serverExternalPackages`; an app with no config gets a `next.config.ts`. A
+  config that already names `serverExternalPackages`, or is written another way, is never changed, even with `--yes`:
+  the line to add is printed, with a warning. The agent skill's Next.js section says to keep it.
+- The agent skill's Next.js section says what a page that calls `avClient` or `avApp` needs under Cache Components
+  (create-next-app's default): the calling component inside `<Suspense>` (or a `loading.tsx`), `"use cache"` on the
+  function that makes the call, or `export const instant = false`.
+
+## 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.
+
+## 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.
+
+## 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.
+
+## 1.0.0-rc.5
+
+## 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.
+
+- 99169d2: Policy engines, reads first. `createFramework` takes an optional root `policy: { engine, principal }`: an engine that
+  answers three questions (`can`, `scopeOf`, `fieldsOf`, each now or as a promise), and a function that derives a
+  request's principal from its `ctx.$state`. Core never imports an engine; one satisfies `AvPolicyEngine` by its shape,
+  and a scope or grant is a fragment of Aventara's own `where` (`AvPolicyWhere`).
+
+  - Client and agent requests are checked (an MCP tool call is an agent request). An application call is checked only
+    when it names a principal: `framework.application.Note.find.many(args, { as: user })`. A call a stage makes through
+    `ctx` never is.
+  - Before any guard, `can` and the fields the request names or receives (`fieldsOf`); a refusal is `403 A4002`. At the
+    adapter call, after every developer stage, the read scope is ANDed into the root `where`, every to-many include and
+    its `$count`, and every relation filter, at every level. A to-one include of a row out of scope refuses the request;
+    it is never nulled.
+  - Governed fields (the engine's `governed` list) are left out of every default projection and carry `governed: true`
+    in the Contracts. Name one to get it: `select: ["$defaults", "email"]`, where `$defaults` is the level's default
+    projection. It is refused where a returned row does not grant it, and a filter or sort by it is checked before the
+    query runs, so it cannot reveal values the caller may not read.
+  - The engine's `governed` and `paths` lists are checked against the Core Contract at startup. A rule's paths are lists
+    of segments, as other paths in core are: `["Note", "campaign", "members", "some", "userId", "equals"]`.
+  - Writes are checked as well; see the policy writes entry.
+
+  Without `policy`, nothing changes: the Contracts and their hashes are the same bytes.
+
+- 154e440: Policy engines check writes. Every create, update, delete and upsert a client or agent makes (or an application call
+  made `{ as }` a principal) is now checked by the configuration's `policy`, where before it was refused.
+
+  - The fields a write sends are held to `fieldsOf({ access: "write" })` before any guard; a field outside it answers
+    `403 A4002`. A field writable on some rows only is checked against every row an update reaches, and against the
+    row a create inserts, after the insert and inside its transaction.
+  - A create asks `can({ action: "create", row })` about each new row on its final data. Its rules can look rows up
+    through `exists`, which runs inside the write's transaction, so a plan that creates a campaign and then its first
+    note sees the campaign.
+  - An update or delete acts only on rows the caller may both change (`scopeOf` for the action) and read. A single-row
+    one that matches nothing answers `A4002` when the caller can read the row, and `A2003` when it cannot, so the
+    answer does not reveal that the row exists. A `many` or `count` one answers for the caller's rows only.
+  - An update that moves a row out of what the caller reads is rolled back with `A4002`. So is one that fails an `after`
+    condition: inside the transaction core asks `can({ action: "update", row })` about each changed row of every
+    checked update. The engine's new `afterChecks` member (`{ Note: ["update"] }`) names the updates whose grants carry
+    such a condition, which are the ones refused where there is no interactive transaction.
+  - Where the operation's `transactionsStyle` is `"interactive"`, a checked write runs in a transaction of its own. Where
+    it is `"none"` (Cloudflare D1), a write that can only be checked after it runs is refused before it runs; every other
+    write runs, a create looking up before it inserts, and an unlisted update without the after check.
+  - Nested writes (a relation directive in a write's data) are refused under a policy for now.
+
+  `afterChecks` is checked against the Core Contract at startup and changes no Contract and no prebuilt fingerprint.
+
+- 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.
+
+## 1.0.0-rc.3
+
+### Patch Changes
+
+- b38034d: A refusal that quotes a failed child's output (`npm install`, `nest new`) ends with that output as the child wrote it.
+  It printed a period of its own after the child's last line (`npm ERR! the registry said no.`).
+
+## 1.0.0-rc.2
+
+### Patch Changes
+
+- `aventara init`'s refusal of a TypeScript 7 project names the supported range: "use TypeScript 5.7 to 6" (it said
+  "use TypeScript 6 or 5"). The Prisma adapter's `typescript` peer range starts at 5.7.0 now.
+- An agent skill for your AI coding agent. `aventara new` and `aventara init` write `.claude/skills/aventara/`:
+  `SKILL.md` (the Agent Skills format Claude Code reads: when to use it, and one rule per task) and
+  `reference/config.md`, `reference/stages.md`, `reference/recipes.md` and `reference/errors.md` (`@aventara/core`'s
+  `ERRORS.md`), for the Aventara version they install. They also add a short Aventara section to `AGENTS.md`, between
+  `<!-- aventara:start -->` and `<!-- aventara:end -->`, for agents that read `AGENTS.md`: an existing `AGENTS.md`
+  keeps everything else, and `CLAUDE.md` is never written.
+- `aventara skill` refreshes those files for the `@aventara/core` installed in the project (its version and its
+  `ERRORS.md`; it runs none of the project's packages). It rewrites the skill files it wrote, keeps one you changed
+  and says so (`--force` replaces it), and replaces only the marked section of `AGENTS.md`.
+- `aventara new` and `aventara init` write an `aventara:prepare` script that also passes
+  `--config src/aventara.config.ts`, so the generated types know which fields your configuration computes: a
+  variant's guards, pipes and filters may leave exactly those out of a create. A project set up before keeps working;
+  add the flag to its script to get the precise types.
+- The agent skill says that a `Date` or bytes value a stage is told is that stage's own copy, so changing it in place
+  changes nothing another stage sees, what is written or what the caller receives; and that a `compute.read` stage with
+  no `dependsOn` computes from the same inputs for every row, so its value usually belongs in response metadata or
+  `ctx.$state`. In rc.1 it said neither.
+- The agent skill says that a `compute.read` stage is told the row frozen: it returns its field's value, and writing
+  into `record` answers `A3000`. Its error reference lists a nested write that writes its relation back (`A2004`,
+  `V1012`).
+- The agent skill says that a computed value its field's `format` refuses (a relative path for `format: "url"`)
+  answers `A3000`, as a value of the wrong type does.
+- Released with the other Aventara packages, and `aventara new` and `aventara init` install them at 1.0.0-rc.2.
+
+## 1.0.0-rc.1
+
+### Patch Changes
+
+- 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.
+
+- 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.
+
+- 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.
+
+- 8db76e7: `aventara new` and `aventara init` write a `diagnostics` sink into `src/aventara.config.ts`. When something fails
+  inside the server, the caller gets a plain 500 and the Nest log said only which request failed; the raw error went to
+  a sink the scaffold did not set. Now the sink logs the raw error with its stack through Nest's `Logger` (context
+  `Aventara`), at error level, right after that line. Replace it with your own reporter when you have one.
+
+- `aventara new` and `aventara init` write `api: '/api'` into `src/aventara.config.ts` (the root key was renamed from
+  `entrypoint`).
+
 ## 1.0.0-rc.0
 
 ### Major Changes