@aventara/core 0.1.0-pilot.4 → 1.0.0-rc.1

package/CHANGELOG.md

@@ -0,0 +1,1478 @@
+# @aventara/core
+
+## 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"],
+              format: "url",
+            },
+            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
+
+- First release candidate of Aventara 1.0. The public API is now considered stable; changes before 1.0.0 are possible
+  based on feedback.
+
+### Minor Changes
+
+- 24ffbab: A `Json` field can now have a type. Build its shape with `AvZ` from the new entry `@aventara/core/json` and declare it
+  on the field: `fields: { Post: { meta: { json: AvZ.object({ title: AvZ.string() }) } } }`. `framework.application`,
+  `framework.client`, `appTx`/`clientTx` and the generated client then read and write the field as that type instead of
+  generic JSON, and every write to it — create, update, upsert, nested writes and transaction steps, a value taken from
+  an earlier step included — is checked before the database is asked: a value out of shape is refused with `A2004` and
+  one issue per problem at its exact path (`V1000` missing key, `V1001` wrong type, `V1002` outside an enum or literal,
+  `V1004` integer out of range, `V1005` unknown key). Shapes are types only and their objects are closed; reads and
+  filters are never checked. Only a field the adapter discovered as `Json` takes a shape, and a Zod schema is not
+  accepted. The shape is part of the ClientContract (as JSON Schema), so declaring or changing one changes its hash:
+  regenerate the client. `@aventara/core` now depends on `zod` (`^4.6.5`), which only `@aventara/core/json` loads. The
+  shape types `AvZShape`, `AvZObject`, `AvZOptional` and `AvZNullable` are exported too, so a project that emits
+  declarations can export a shape or a configuration holding one.
+- 24ffbab: Transaction steps can now reference earlier results in `$connect`, `$disconnect`, `$set`, `$connectOrCreate`'s `where`,
+  a `cursor`, a unique `where`, and anywhere in a filter — `AND`/`OR`/`NOT` and relation filters included, with every
+  scalar operator. `framework.appTx` and `framework.clientTx` type each position by what it holds: a filter's value,
+  `equals` and `not` take a source of the field's own type (nullable only where the field is, and a `null` then matches
+  the rows where the field is unset, as a literal `null` does); a unique key, a `cursor`, a comparison or a text operator a
+  non-null source; `in`, `notIn`, `hasEvery` and `hasSome` a list field; `has` one value. The server checks the same rule
+  before anything runs and refuses a mismatch with `A2007`/`V1011`. Nested relation writes take references at any depth
+  too: the values and keys of nested `$create`, `$update` and `$upsert` data, and the `where` of a nested `$update`,
+  `$delete` or `$upsert`. A reference in an ordering or a projection's nested `where` is still refused.
+- 24ffbab: **Behaviour changes:** server-side calls now copy what you pass them. `framework.application`, `framework.client`,
+  `framework.execute`, `framework.executeTransaction` and the `appTx`/`clientTx` builders read your arguments once, when
+  you call them, into plain data the framework owns; validation, guards, pipes, computed values and the adapter see only
+  that copy, so changing or revoking your object afterwards (an Immer draft after `produce`) no longer affects the
+  operation. A live Proxy (Vue `reactive`, MobX) still works.
+
+  A value that cannot be read — a revoked Proxy, a getter that throws — or that is not plain data — a class instance or a
+  `Map`; `Date`, `Decimal` and `Uint8Array` are fine — is now refused as your request's error: `A2004` with one `V1001` at
+  the value's path (`["arguments", …]`, or `["operations", i, "args", …]` with `cause.operation` in a transaction), before
+  any guard, pipe or adapter runs. Before, it was `A3000` (an internal error) or, from `appTx`/`clientTx`, a `TypeError`
+  thrown at the builder call; a builder now never throws, and `framework.transaction([...])` answers the refusal. The same
+  holds for a `framework.execute` / `executeTransaction` request object that cannot be read. Two answers change for
+  inputs that were never supported: a class instance where an object of arguments belongs (`where`, `data`, …) was
+  accepted or failed as `A3000`, and is now refused; inherited, non-enumerable and symbol keys are dropped, as JSON drops
+  them.
+
+  New optional root setting `misuse` (types `FrameworkMisuseSink`, `FrameworkMisuseEvent`), beside `diagnostics`: it
+  receives one event per refused value — its `kind` (`"unreadable-value"` or `"non-plain-value"`), the `path` the caller
+  received, and the operation's `origin`, `resource`, `family`, `variant` and transaction step (`operation`) when they
+  could be read — never the value itself. It cannot change a response; an error it throws or a promise it rejects is
+  ignored. `diagnostics` keeps receiving only unexpected failures.
+
+  HTTP requests are not copied again: a body the protocol parses from raw content is already plain data.
+
+  The generated client reads your arguments through one guard too: a value that cannot be read is refused with a
+  `TypeError` naming where (`… the value at /where/id could not be read.`) before anything is sent, and a `tx` builder
+  never throws — `transaction([...])` rejects with that error instead. Regenerate the client to pick this up.
+
+- 24ffbab: A nested `$update` or `$delete` through a to-many relation filters plain fields only on Prisma 7, and Aventara now says
+  so up front: a relation filter in its `where` — `{ posts: { $update: { where: { category: { name: "x" } }, … } } }`, at
+  any depth, under `AND`/`OR`/`NOT` too — is refused with `A2004` / `V1006` before the database is asked, and is a type
+  error in `framework.application`, `framework.client`, `appTx`/`clientTx` and the generated client. Before, it reached
+  Prisma and fail as `A3001`. A to-one relation's nested filter keeps relation filters. The limit is stated by the adapter
+  in the Contract (`nestedWriteFilter: "scalar"`), so the ClientContract hash changes: regenerate the client.
+
+### Patch Changes
+
+- 24ffbab: **Behaviour changes:** `@aventara/core` exports fewer names. Every name it no longer exports was undocumented; every
+  documented name (`createFramework`, `FrameworkConfig`, `defineFields`, `Decimal`, `FrameworkError`, the pipeline types and
+  the rest) is still exported. Types shown in a hover or an error message still resolve; what changes is only which names
+  your own code can import. `OperationScope` was a deprecated alias: use `RequestOrigin`.
+
+  What Aventara's own packages need from core moved to `@aventara/core/internal`. It is not public API: it carries no
+  stability promise, and any of its exports may change or disappear in any release. Applications import from
+  `@aventara/core`.
+
+  Moved to `@aventara/core/internal`: `AdapterField`, `AdapterFieldKey`, `AdapterFieldMap`, `AdapterIdentifier`, `AdapterLifecycleTrait`, `AdapterOperation`, `AdapterOperationExecutor`, `AdapterRelationField`, `AdapterResource`, `AdapterScalarField`, `AdapterScalarFieldKey`, `advertisedDirectives`, `advertisedReducers`, `ApplicationContractView`, `ApplicationOperationRequest`, `ApplicationTransactionRequest`, `AVENTARA_PROTOCOL_VERSION`, `BUILT_IN_SCALARS`, `BuiltinNonRow`, `canonicalizeContract`, `canonicalizeJson`, `CanonicalJsonError`, `ClientContractHashInput`, `ClientOperationRequest`, `ClientProtocolIdentity`, `ClientTransactionRequest`, `compileContracts`, `computeClientContractHash`, `computeOperationFingerprint`, `DEFAULT_CONTRACT_LIMITS`, `FrameworkOperationRequest`, `FrameworkTransactionRequest`, `isOperationVariantAvailable`, `LIFECYCLE_TRAITS`, `OPERATION_CODES`, `OperationFingerprint`, `PROJECTION_SCOPES`, `projectionScopeOf`, `resolveFrameworkConfig`, `SemanticOperationArguments`, `TRANSACTION_CAPABILITIES`, `validateClientContractStructure`, `VALIDATION_CODES`, `verifyClientContractHash`, `WRITE_SCOPES`, `writeScopeOf`.
+
+  No longer exported from any entry: `advertisedDirectivesAt`, `advertisedReducersAt`, `ClientContractStructureVerdict`, `ContractCompilationResult`, `DeferredOperation`, `EffectiveFieldKeyAt`, `holdsAt`, `holdsInAnyScope`, `isOperationFingerprint`, `isTransactionReferenceCandidate`, `isTransactionReferenceObject`, `operationFailure`, `OperationFingerprintNode`, `OperationInternalErrorCode`, `operationNoMatch`, `OperationScope`, `operationSuccess`, `OperationValidationResult`, `RelationMutationAction`, `ResolvedFrameworkConfig`, `ResolvedFrameworkScopeConfig`, `ResolvedPipelineConfig`, `ScalarFilterInput`, `ScalarMutationAction`, `transactionCommitted`, `TransactionCreateDataInput`, `transactionInfrastructureFailure`, `TransactionOperationArgumentsFor`, `transactionOperationFailure`, `TransactionPlan`, `TransactionReferenceCandidate`, `TransactionScalarValue`, `TransactionUpdateDataInput`, `validateFrameworkConfig`, `validateOperationArguments`, `VALIDATION_CODE_MESSAGES`.
+
+- 24ffbab: Each package ships its `CHANGELOG.md`, so the release notes are in the installed package beside the README.
+- 24ffbab: A `null` given to a filter operator that has no `null` meaning — `gt`, `contains`, `in`, `has`, `mode`, `isEmpty`,
+  `path`, a JSON `string*` operator and the rest — is now refused as `A2004` / `V1001` at that operator, before the
+  database is asked, and is a type error. Before, it reached the database and failed as `A3001`. `equals: null` and
+  `not: null` still match the rows where a nullable field is unset or set.
+- 24ffbab: **Diagnostics:** if your own HTTP host mounts only some of `protocol.surface()` and a request for a route it left out
+  reaches `protocol.answerAbsent`, your `diagnostics` sink now receives one `A3000` diagnostic naming the route: an
+  `"operation"` diagnostic with the Resource, family and variant (a `"transaction"` one for `/_transactions`), whose
+  `error` is named `"UnmountedRouteError"` and says which `surface()` entry to mount. The caller's `500 A3000` answer is
+  unchanged, and a route your ClientContract does not offer is still answered without a report. `@aventara/nest` mounts
+  every route, so its applications are not affected.
+- 24ffbab: **Diagnostics:** a `FrameworkError` you throw on purpose with an `A3xxx` code — from a guard, pipe, hook, interceptor,
+  computed field or adapter, or returned by a filter — now reaches your `diagnostics` sink once, as the error you threw,
+  under its code, with `deliberate: true` on the diagnostic. Before, the caller received the generic `A3000`/`A3001` and
+  your message and issues were reported nowhere. A failure Aventara did not expect carries no `deliberate` field, so a sink
+  can tell the two apart. What the caller receives is unchanged, and `A2xxx`/`A4xxx` outcomes are still not reported.
+- 24ffbab: **Diagnostics:** a result that does not match its Contract — an adapter row with a wrong value, a missing field, a
+  result of the wrong shape — now reaches your `diagnostics` sink as one `A3000` diagnostic whose `error` (`name`
+  `"OutputValidationError"`) names the operation and lists the problems (`error.issues`). Before, the caller got `A3000`
+  and the sink got nothing unless reading the result threw. The same now holds for a computed field: a read or write
+  behavior that returns a value its field refuses is reported as an error named `"ComputedValueError"` with the issues
+  (before, the sink received only the field's location). What the caller receives is unchanged. A filter that inspects
+  the error now sees that error instead of a `FrameworkError` with code `A3000`.
+
+  The `FrameworkError` documentation now states the message rule: for any code outside `A3xxx`, the message is sent to
+  the caller exactly as written, so it must not carry database text, SQL, a stack, a path or a secret.
+
+- 24ffbab: **Behaviour changes:** Pipelines and guards read where a request came from as `request.origin` (was `request.scope`).
+  The same property is renamed everywhere it means `"application"` or `"client"`: the pipeline context
+  (`context.origin`), the request objects `framework.execute` and `framework.executeTransaction` take
+  (`{ origin: "client", … }`), the context a computed field's behaviour receives, and every diagnostic the diagnostics
+  sink receives. There is no `scope` alias: replace `scope` with `origin` in those places. Nothing sent over HTTP
+  changes.
+
+  The Nest host's log line for an internal failure now reads `(client origin, request …)` instead of
+  `(client scope, request …)`.
+
+- 24ffbab: **Types:** a guard, pipe, hook, interceptor or filter typed with `Guard`, `Pipe`, `BeforeHook`, `AfterHook`,
+  `Interceptor` or `Filter` without a model type now type-checks wherever one typed for your model is expected, so you
+  can put it in an `as const` configuration (the shape `aventara init` writes), in `client.pipelines` or
+  `application.pipelines`, and mix it with model-typed callbacks in one list. Before, TypeScript refused it there, and
+  the way around it was a structural parameter type such as `Pick<PipelineContext, "family" | "transport">`, which you no
+  longer need (it keeps working). A callback typed for a different model is still refused.
+- a973e89: An issue your own code throws now reaches the caller with the message you wrote. When a pipe, guard, hook, interceptor,
+  filter or computed behavior throws `new FrameworkError("A2004", { message, issues: [{ path, code, message }] })`, each
+  issue's `message` is sent as written instead of the generic text for its code — standalone, inside a transaction plan,
+  and over HTTP. The message must have a visible character and be at most 1,000 characters; otherwise the caller receives
+  the generic text for the code and your message goes to the `diagnostics` sink. The rest is unchanged: an issue whose
+  `code` is not a validation code (`V1000` and up) is dropped, a `path` that does not name a member of the request's own
+  arguments is dropped, an `A3xxx` outcome still carries no issues, and an issue an Adapter throws still carries the
+  generic text for its code.
+- 1e65e9a: `framework.execute(request)` and `framework.executeTransaction(request)` now check the request object itself before
+  running it. A wrong one — not an object, a missing or empty `requestId`, an `origin` other than `"application"` or
+  `"client"`, a client request without a `protocol` of `{ version, hash }`, malformed `transport`, `protocol` or
+  `transport` on an application request, or a missing or non-string `resource`, `family` or `variant` — is answered
+  `A2004` with one issue per wrong member at its own path (`["requestId"]`, `["protocol", "hash"]`, …), and nothing
+  runs: no guard, pipe or hook, no adapter call. Before, most of these answered `A3000` (an internal error) or ran as
+  though the request were well formed. A well-formed request is unchanged, including `A2005`/`A2006` for a stale
+  `protocol` and `A2001` for an unknown Resource.
+- a973e89: A write that sets an optional relation both ways — its reference field and the relation itself, such as `categoryId`
+  and `category: { $connect: … }` in the same record — is now refused before it reaches the database, exactly like a
+  required relation: `A2004` with a `V1012` issue at the relation, message `Set "categoryId" or "category", not both.`
+  Before, the database refused it and the caller received `A3001`. It applies to `create`, `update` and `upsert`, to
+  nested writes at any depth, and to each step of a transaction.
+
+  The discovery artifact now records, for each relation, the fields that hold its reference (`references` on each edge
+  of `referentialActions`), and a create requirement no longer repeats them. Regenerate your artifact with
+  `npm run aventara:prepare` (or `aventara-prisma7-generate`); an artifact from an earlier version is refused with a
+  message that says so. An adapter's `referentialActions` edges carry the same `references` member.
+
+- a973e89: With the Prisma adapter, a record that writes one relation through its reference field and another relation directly —
+  such as `authorId` beside `category: { $connect: … }` — is now refused before it reaches the database: `A2004` with a
+  `V1012` issue at the relation write, message
+  `Use relation fields only, or reference fields only, in one record: "authorId" is a reference field and "category" is a relation.`
+  Before, Prisma refused it and the caller received `A3001`. Write the record's relations all as relations
+  (`author: { $connect: … }, category: { $connect: … }`) or all through their fields (`authorId`, `categoryId`). A
+  reference field beside a relation that holds no reference on that side — `mentorId` beside `posts: { $create: … }` on
+  an author — is unchanged and still accepted. It applies to `create`, `update` and `upsert`, to nested writes at any
+  depth, and to each step of a transaction.
+
+  The limit is part of the Contract: a Contract whose data source has it carries `referenceWrites: "uniform"`, so the
+  Contract hash of every Prisma-backed application changes. Regenerate your discovery artifact
+  (`npm run aventara:prepare`) and your generated client (`avclient generate`). An adapter states the limit with
+  `referenceWrites: "uniform"` in its model; without it, nothing changes.
+
+- 1e65e9a: A write that sets a required relation both ways — its reference field and the relation itself, such as `authorId` and
+  `author: { $connect: … }` in the same `data` — is now refused before it reaches the database: `A2004` with a `V1012`
+  issue at the relation (`["arguments", "data", "author"]`), message `Set "authorId" or "author", not both.` It applies to
+  `create`, `update` and `upsert`, to nested writes at any depth, and to each step of a transaction, and nothing is
+  written. Before, the database refused it and the caller received `A3001`. Writing either one alone is unchanged.
+- 1e65e9a: A guard, pipe, hook, interceptor or filter typed for any Resource — `Guard`, `Pipe`, `BeforeHook` and the rest without a
+  model argument, or a callback whose context is a `Pick<PipelineContext, …>` — in the root `pipelines` no longer erases
+  `framework.application`, `framework.client`, `framework.appTx` and `framework.clientTx` to an untyped object. They stay
+  typed from your adapter's model with any mix of stage types, at the root and in the `application` and `client`
+  overlays, with or without `as const`, and a callback written inline is still told your Resource names.
+- 24ffbab: **Behaviour changes, transactions:** an object carrying `$ref` in a step's `args` is now copied when you call
+  `framework.executeTransaction`, like the rest of your arguments. Where a `$ref` belongs (a field value, a filter
+  value, a `$connect` key) it is answered exactly as before; changing it after the call no longer affects the plan.
+  Placed anywhere else — the whole `where`, a whole relation value, the whole `data` — a member of it that cannot be
+  read (a getter that throws, a revoked Proxy) is now your request's error, `A2004` with one `V1001` at that member's
+  path and `cause.operation`, reported to `misuse`; before, it was `A3000`. The framework never runs a getter inside an
+  object that carries `$ref`, wherever it stands, so such a getter is refused unread.
+
+  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
+  `POST /_transactions` that path is now checked against that step's own arguments and sent as
+  `["operations", i, "args", "data", "name"]` beside `cause.operation`; before, it was dropped and the issue reached the
+  caller without a path. A path written as `["operations", i, "args", …]` with the step's own index is accepted as
+  before, and a path that does not name a member of the step's arguments is still dropped.
+- 384a50c: **Behaviour changes, transactions:** every issue about a transaction step's arguments now names where it is
+  in the plan, `["operations", i, "args", …]`, beside `cause.operation: i`. Before, the framework's own checks — a wrong
+  type, an unknown field or operator, a structural limit, a Json value out of its `AvZ` shape, a value that is not valid
+  JSON — answered `["arguments", …]` inside a plan while a bad `$ref`, a refused value and a step that depends on a
+  cascaded delete already answered `["operations", i, "args", …]`; now one plan uses one spelling, through
+  `framework.transaction`, `framework.executeTransaction` and `POST /_transactions` alike. A single call is unchanged
+  (`["arguments", …]`). If your code reads `issue.path` from a transaction's answer, drop the `"operations", i, "args"`
+  prefix to get the path inside that step's arguments. `@aventara/testing`'s protocol corpus row "a client-hidden
+  field — /_transactions" and `fixtures/protocol-v1.json` carry the new path.
+- d43d1cc: **Types:** `diagnostic.deliberate` now type-checks on any `FrameworkDiagnostic`, without checking
+  `diagnostic.kind` first, so a `diagnostics` sink can log it for every report. It is `true` only on an `"operation"`
+  diagnostic for a `FrameworkError` you threw on purpose with an `A3xxx` code, and always absent on a `"transaction"`
+  diagnostic, which reports the transaction's own failure (`A3002`). Before, reading it on the union was a TypeScript
+  error (`TS2339`).
+- 3f98749: **Types:** `framework.application`, `framework.client`, `framework.appTx` and `framework.clientTx` now follow
+  your `restrictions` the way the generated client does. A field whose capability you turn off — `select`, `filter`,
+  `order`, `create` or `update` — is refused in that position and left out of the result types; an operation you turn
+  off (`operations: { delete: { unique: false } }`) is not on the façade; and a unique operation disappears when its
+  only identifier is hidden. Each façade reads its own layer: `framework.client` the root restrictions with
+  `client.restrictions` over them, `framework.application` the root restrictions with `application.restrictions` over
+  them — so `hidden` now applies to `framework.application` too. Before, only `client`'s `hidden` was reflected, so with
+  `passwordHash: { capabilities: { select: false, … } }` a call such as
+  `framework.client.User.find.many({ select: ["passwordHash"] })` compiled and every result type carried `passwordHash`.
+  Nothing changes at runtime: the server refused those calls before and still does. A restriction value typed as a plain
+  `boolean` rather than `true`/`false` still leaves the field as it was.
+- 032f792: **Behaviour changes, transactions:** an error about a transaction step itself — rather than its arguments — now
+  names the step too, so every path in a transaction's answer is a path through the request you sent: an unknown or
+  hidden Resource is at `["operations", i, "resource"]`, a fingerprint that does not match at
+  `["operations", i, "fingerprint"]`, a missing or unknown key on the step at `["operations", i, "<key>"]`, and a step
+  that is not an object at `["operations", i]`. An operation the step cannot run points at the key that is wrong:
+  `["operations", i, "family"]` when the family is not a string, not a standard family, or one the Resource offers no
+  variant of; `["operations", i, "variant"]` when the family is right and the variant is not (unknown, not offered or
+  restricted for it). Before, these answered `["resource"]`, `["operation"]`, `["fingerprint"]` and `["<key>"]`.
+  `cause.operation` and the outcome code are unchanged: an unknown Resource is still `A2001`, an unavailable operation
+  `A2002`. `framework.transaction([...])` refuses an entry that is not a handle, or one handle placed twice, at
+  `["operations", i]`. A single call is unchanged. `@aventara/testing`'s protocol corpus and `fixtures/protocol-v1.json`
+  carry the new paths.
+- dbe6961: **Behaviour changes:** a single call to an operation a Resource does not offer now names the key of the
+  request that is wrong instead of `["operation"]`, which no request has: `["family"]` when the family is not a standard
+  one or the Resource offers none of its operations, `["variant"]` when the family is right and the variant is not. This
+  holds for `framework.execute` and for an HTTP route, whose `/_resources/:resource/:family/:variant` segments are named
+  by those same keys. The code is unchanged (`A2002` / `V1006`), and so is `["resource"]` for an unknown Resource.
+  `@aventara/testing`'s protocol corpus and `fixtures/protocol-v1.json` carry the new paths.
+
+## 0.1.0-pilot.4
+
+### Patch Changes
+
+- f37dcd6: The documentation shipped with the package — the comments an editor shows on hover, and the README — now describes
+  what each export does, how to use it, what it returns and what it throws. Notes about how the package was built and
+  why are no longer part of what is published.
+
+  The declarations a generated client copies from `@aventara/core` carry the same documentation.
+
+## 0.1.0-pilot.3
+
+## 0.1.0-pilot.2
+
+### Patch Changes
+
+- c2a3b7c: A `bigint` value outside the signed 64-bit range is refused as `A2004` with a `V1004` issue at its path, from the wire
+  and from the application alike, before any pipeline or adapter runs. Before this release it reached the database and
+  answered `A3001`.
+- e69e88d: The published packages are written for the people who use them. The JavaScript ships without comments; the type
+  declarations keep their documentation, and it, the error messages, the protocol fixtures' labels and the comments in a
+  generated client no longer carry the project's internal development notes.
+- ab58424: A pipe's output is checked against the server's own rules before it reaches the adapter. The request is validated
+  against the caller's Contract; after each pipe, the arguments are validated against the Core Contract (plus fields the
+  caller's scope adds), so a pipe may still write what the caller cannot — a field the client Contract hides, such as a
+  password hash — but not what the server cannot store. A refusal is the new internal code `A3004 PIPE_OUTPUT_INVALID` (HTTP
+  500). The caller receives only the generic `A server pipeline produced invalid arguments.`, like every internal
+  failure; the pipe (`pipes[i]` and its function name), the operation, the offending field and its V-code go to the
+  diagnostics sink as a `PipeOutputError`, and `@aventara/nest` writes them into its error log line. Nothing reaches the
+  adapter. This holds for operations and transaction steps alike (a plan answers with `cause.operation`). Generated
+  clients map `A3004` to `InternalError`; the protocol fixtures in `@aventara/testing` include an `A3004` row.
+- 23937f8: A create that lacks a value the database requires is refused as `A2004` with a `V1000` issue at the value's path,
+  instead of reaching the database and answering `A3001`. It covers `create.one`, every row of `create.many`, `upsert`'s
+  `create` branch, nested `$create` (and `$connectOrCreate`/`$upsert` creates) at any depth, and transaction steps
+  (`["operations", i, "args", …]`). A required relation is satisfied by writing it or every scalar that holds its
+  reference; a nested create never needs the relation it is created through. Defaults, `@updatedAt`, autoincrement,
+  optional and list columns are never required. The check runs after pipes and computed behaviours, so a value they
+  supply counts.
+
+  An adapter states the requirements through the new optional `Adapter.createRequirements`; the Prisma 7 adapter reads
+  them from the generated client's create inputs at generate time and records them in the discovery artifact, so the
+  artifact must be regenerated (`aventara:prepare`).
+
+## 0.1.0-pilot.1
+
+### Patch Changes
+
+- a45f8a8: The `400 A2000` for a request without its identity headers now says which one: `cause.message` is "The
+  Aventara-Contract-Hash header is missing." (or "The Aventara-Protocol-Version header is missing.", or both, naming both),
+  instead of the generic "The request is malformed and cannot be interpreted." It names headers only and echoes no value.
+  The code, status and every other `A2000` are unchanged. The protocol fixtures in `@aventara/testing` check the new messages, with a row
+  for a request with neither header.
+- 799346e: The package READMEs (each package's npm page) are rewritten for the people who use the packages. The Prisma 7
+  adapter's README now states the actual behaviour of a to-many relation or `$count` projected on
+  `update.many`/`create.many`: a validation refusal, `A2004` with `V1008`, before any statement runs (it said `A3001`).
+  Every install or run command names the `@pilot` dist-tag.
+
+## 0.1.0-pilot.0
+
+### Minor Changes
+
+- First pilot release of `@aventara/core`: the framework itself — configuration, Contracts, validation, operations,
+  pipelines and transactions — independent of any HTTP server or ORM.
+
+  - **`createFramework(config)`** builds a Framework from an adapter and a configuration. The configuration is typed
+    against the adapter's model, so restriction keys, behaviors, `dependsOn` and pipeline `resource` guards are checked
+    against the Resources and fields that exist; `defineFields` declares the fields a configuration adds so the rest of
+    it can name them.
+  - **Contracts.** The adapter's capabilities and your configuration compile into the Core, Application and Client
+    Contracts at startup. The ClientContract is what clients are generated from, and its hash identifies it. A scoped
+    configuration (`application`, `client`) only narrows what the root allows, and a configuration asking for a
+    capability the root or the adapter does not offer fails at startup with `COMPILER_UNAVAILABLE_CAPABILITY` at its
+    path. A value the Contract cannot represent, or an invalid ClientContract (`COMPILER_INVALID_CLIENT_CONTRACT`), also
+    fails at startup.
+  - **Capabilities by argument position.** A relation the database projects or writes only in some operations is
+    advertised only there; asking for it elsewhere is refused with `A2004` (`V1008` for a projection, `V1006` for a
+    write) before any query, and is a type error.
+  - **Typed calls.** `framework.application.<resource>.<family>.<variant>(args)` and `framework.client.…` take arguments
+    and return results typed from the Contract (`OperationResultFor`); an optional second argument, `ExecutionOptions`
+    (`{ requestId }`), sets the request id every pipeline context, adapter call and diagnostic of the call carries.
+  - **Transactions.** `framework.appTx` and `framework.clientTx` build typed plans whose steps can use earlier steps'
+    results through `$ref`; `framework.transaction(steps, options)` runs them. A step that depends on rows an earlier
+    step's cascading delete removed is refused before the plan runs (`A2004`/`V1019`).
+  - **Fields and pipelines.** Computed and virtual fields under `application.fields` and `client.fields`; guards, pipes,
+    before and after hooks, interceptors and filters.
+  - **Scalars.** `Decimal` (string-backed; `toJSON()` writes its digits; a non-string argument throws a `TypeError`),
+    `JsonValue`, and the `ApplicationScalarForms` / `WireScalarForms` maps. A `Date`, `Decimal` or `Uint8Array` at a
+    filter position is shorthand for equality.
+  - **`@aventara/core/protocol`**, a second entry point: the HTTP protocol as data and pure functions a host mounts —
+    `AvProtocol.headers`, `httpStatus`, `scalarFormats`, `normalizeEntrypoint` and `isOperationResponse`, and
+    `AvProtocol.bind(framework)` with `surface()` (the routes to mount), `handleOperation`, `handleTransaction`,
+    `encodeContract` (`GET /_contract`, with `ETag` and `304`), `answerAbsent`, `failure`, and the decoders and encoders
+    under them. A request without an identity header answers `400 A2000`, a wrong protocol version `A2006`, a stale
+    contract hash `A2005`; a body larger than `limits.maxRequestBytes` `413 A2010`, a content type other than
+    `application/json` `415 A2011`; every `405 A2012` carries `Allow`. A malformed request never throws: it answers
+    `400 A2000`.
+  - **The entrypoint** is normalized once: `"api"`, `"/api/"` and `"//api//"` become `"/api"`, `"/"` becomes `""`, and an
+    entrypoint that is not a plain path (whitespace, a scheme, a query, a `..` segment, a `%` and the like) fails at
+    startup with `CONFIG_INVALID_VALUE`.
+  - Every export has a `default` condition, so a CommonJS project can `require()` the package.