@aventara/core 1.0.0-rc.1 → 1.0.0-rc.11

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (261) hide show
  1. package/CHANGELOG.md +1022 -16
  2. package/ERRORS.md +142 -0
  3. package/README.md +330 -16
  4. package/dist/adapters/adapter-discovery-diagnostic.guidance.d.ts +6 -0
  5. package/dist/adapters/adapter-discovery-diagnostic.guidance.js +7 -0
  6. package/dist/adapters/adapter-field.d.ts +22 -0
  7. package/dist/adapters/adapter-identifier.d.ts +9 -0
  8. package/dist/adapters/adapter-identifier.js +6 -1
  9. package/dist/adapters/adapter-model.d.ts +9 -0
  10. package/dist/adapters/adapter-operation.d.ts +18 -3
  11. package/dist/adapters/adapter-resource.d.ts +5 -0
  12. package/dist/adapters/adapter.interface.d.ts +10 -0
  13. package/dist/avz/avz.d.ts +1 -1
  14. package/dist/avz/json-shape.registry.d.ts +2 -1
  15. package/dist/compiler/contract-compiler-diagnostic.guidance.d.ts +6 -0
  16. package/dist/compiler/contract-compiler-diagnostic.guidance.js +97 -0
  17. package/dist/compiler/contract.compiler.d.ts +6 -0
  18. package/dist/compiler/contract.compiler.js +281 -31
  19. package/dist/compiler/create-requirements.projector.js +1 -3
  20. package/dist/compiler/field-validator.compiler.js +1 -3
  21. package/dist/compiler/managed-elsewhere.projector.d.ts +52 -0
  22. package/dist/compiler/managed-elsewhere.projector.js +179 -0
  23. package/dist/compiler/managed-elsewhere.validator.d.ts +9 -0
  24. package/dist/compiler/managed-elsewhere.validator.js +74 -0
  25. package/dist/config/cache-stage.factory.d.ts +24 -0
  26. package/dist/config/cache-stage.factory.js +3 -0
  27. package/dist/config/computed-fields.d.ts +62 -0
  28. package/dist/config/computed-fields.js +73 -0
  29. package/dist/config/config-diagnostic.guidance.d.ts +6 -0
  30. package/dist/config/config-diagnostic.guidance.js +32 -0
  31. package/dist/config/config.resolver.d.ts +24 -0
  32. package/dist/config/config.resolver.js +66 -7
  33. package/dist/config/config.validator.js +283 -21
  34. package/dist/config/define-resource.d.ts +1 -5
  35. package/dist/config/entrypoint.normalizer.d.ts +3 -2
  36. package/dist/config/exact-framework-config.d.ts +73 -22
  37. package/dist/config/field-compute.resolver.d.ts +2 -0
  38. package/dist/config/field-compute.resolver.js +9 -3
  39. package/dist/config/framework-config.d.ts +53 -15
  40. package/dist/config/framework-resources-config.d.ts +25 -14
  41. package/dist/config/pipeline-config.d.ts +20 -4
  42. package/dist/config/pipeline-tree.resolver.d.ts +2 -2
  43. package/dist/config/pipeline-tree.resolver.js +2 -3
  44. package/dist/contracts/access-route.rules.d.ts +10 -0
  45. package/dist/contracts/access-route.rules.js +45 -0
  46. package/dist/contracts/canonical-json.writer.d.ts +7 -0
  47. package/dist/contracts/canonical-json.writer.js +55 -0
  48. package/dist/contracts/capability.d.ts +26 -1
  49. package/dist/contracts/capability.js +20 -0
  50. package/dist/contracts/client-contract-structure.validator.d.ts +365 -89
  51. package/dist/contracts/client-contract-structure.validator.js +49 -2
  52. package/dist/contracts/contract-access.d.ts +29 -0
  53. package/dist/contracts/contract-access.js +1 -0
  54. package/dist/contracts/contract-canonicalizer.d.ts +9 -1
  55. package/dist/contracts/contract-canonicalizer.js +35 -4
  56. package/dist/contracts/contract-hash.d.ts +0 -1
  57. package/dist/contracts/contract-hash.js +1 -1
  58. package/dist/contracts/contract-limits.d.ts +6 -0
  59. package/dist/contracts/contract-limits.js +2 -0
  60. package/dist/contracts/contract.d.ts +42 -1
  61. package/dist/contracts/field.d.ts +58 -1
  62. package/dist/contracts/json-schema.projector.d.ts +11 -0
  63. package/dist/contracts/json-schema.projector.js +76 -0
  64. package/dist/contracts/scalar-value-type.d.ts +3 -1
  65. package/dist/framework/access-facade.d.ts +116 -0
  66. package/dist/framework/access-facade.js +118 -0
  67. package/dist/framework/contract-view.d.ts +120 -16
  68. package/dist/framework/framework-construction.error.d.ts +14 -4
  69. package/dist/framework/framework-construction.error.js +18 -2
  70. package/dist/framework/framework.d.ts +26 -5
  71. package/dist/framework/framework.factory.d.ts +1 -1
  72. package/dist/framework/framework.factory.js +145 -24
  73. package/dist/framework/operation-facade.d.ts +141 -13
  74. package/dist/framework/operation-facade.js +9 -1
  75. package/dist/framework/operation-set.runner.d.ts +47 -0
  76. package/dist/framework/operation-set.runner.js +168 -0
  77. package/dist/index.d.ts +19 -5
  78. package/dist/index.js +3 -0
  79. package/dist/internal.d.ts +9 -2
  80. package/dist/internal.js +8 -0
  81. package/dist/operations/database-refusal.d.ts +51 -0
  82. package/dist/operations/database-refusal.js +45 -0
  83. package/dist/operations/operation-arguments.d.ts +148 -60
  84. package/dist/operations/operation-call.d.ts +9 -5
  85. package/dist/operations/operation-result.d.ts +6 -4
  86. package/dist/operations/operation-validator-core.js +160 -39
  87. package/dist/operations/operation-validator.d.ts +1 -1
  88. package/dist/operations/structural-limits.walker.d.ts +1 -1
  89. package/dist/operations/structural-limits.walker.js +1 -3
  90. package/dist/operations/validation-code.guidance.d.ts +6 -0
  91. package/dist/operations/validation-code.guidance.js +90 -0
  92. package/dist/operations/write-scope.resolver.d.ts +4 -0
  93. package/dist/operations/write-scope.resolver.js +2 -0
  94. package/dist/policy/access-provider.interface.d.ts +91 -0
  95. package/dist/policy/access-provider.interface.js +1 -0
  96. package/dist/policy/access-provider.registry.d.ts +17 -0
  97. package/dist/policy/access-provider.registry.js +15 -0
  98. package/dist/policy/access-question.d.ts +20 -0
  99. package/dist/policy/access-question.js +1 -0
  100. package/dist/policy/access-question.registry.d.ts +5 -0
  101. package/dist/policy/access-question.registry.js +19 -0
  102. package/dist/policy/access-question.runtime.d.ts +36 -0
  103. package/dist/policy/access-question.runtime.js +295 -0
  104. package/dist/policy/access-verb.table.d.ts +56 -0
  105. package/dist/policy/access-verb.table.js +21 -0
  106. package/dist/policy/access-verbs.d.ts +46 -0
  107. package/dist/policy/access-verbs.js +1 -0
  108. package/dist/policy/policy-admission.d.ts +20 -0
  109. package/dist/policy/policy-admission.js +407 -0
  110. package/dist/policy/policy-after-update.runtime.d.ts +79 -0
  111. package/dist/policy/policy-after-update.runtime.js +206 -0
  112. package/dist/policy/policy-condition.d.ts +15 -0
  113. package/dist/policy/policy-condition.js +36 -0
  114. package/dist/policy/policy-engine.d.ts +205 -0
  115. package/dist/policy/policy-engine.js +1 -0
  116. package/dist/policy/policy-named-rows.d.ts +18 -0
  117. package/dist/policy/policy-named-rows.js +51 -0
  118. package/dist/policy/policy-nested-write.runtime.d.ts +44 -0
  119. package/dist/policy/policy-nested-write.runtime.js +536 -0
  120. package/dist/policy/policy-read.runtime.d.ts +81 -0
  121. package/dist/policy/policy-read.runtime.js +501 -0
  122. package/dist/policy/policy-reference-write.runtime.d.ts +51 -0
  123. package/dist/policy/policy-reference-write.runtime.js +336 -0
  124. package/dist/policy/policy-request.d.ts +72 -0
  125. package/dist/policy/policy-request.js +115 -0
  126. package/dist/policy/policy-session.d.ts +106 -0
  127. package/dist/policy/policy-session.js +293 -0
  128. package/dist/policy/policy-startup.validator.d.ts +10 -0
  129. package/dist/policy/policy-startup.validator.js +112 -0
  130. package/dist/policy/policy-write.runtime.d.ts +39 -0
  131. package/dist/policy/policy-write.runtime.js +530 -0
  132. package/dist/prebuilt/core-version.generated.d.ts +2 -0
  133. package/dist/prebuilt/core-version.generated.js +1 -0
  134. package/dist/prebuilt/prebuilt-changes.d.ts +29 -0
  135. package/dist/prebuilt/prebuilt-changes.js +63 -0
  136. package/dist/prebuilt/prebuilt-contracts.d.ts +40 -0
  137. package/dist/prebuilt/prebuilt-contracts.emitter.d.ts +16 -0
  138. package/dist/prebuilt/prebuilt-contracts.emitter.js +50 -0
  139. package/dist/prebuilt/prebuilt-contracts.js +1 -0
  140. package/dist/prebuilt/prebuilt-contracts.loader.d.ts +19 -0
  141. package/dist/prebuilt/prebuilt-contracts.loader.js +75 -0
  142. package/dist/prebuilt/prebuilt-inputs.fingerprint.d.ts +16 -0
  143. package/dist/prebuilt/prebuilt-inputs.fingerprint.js +227 -0
  144. package/dist/protocol/absent-route.responder.d.ts +49 -14
  145. package/dist/protocol/absent-route.responder.js +92 -15
  146. package/dist/protocol/contract-document.responder.d.ts +9 -1
  147. package/dist/protocol/contract-document.responder.js +3 -2
  148. package/dist/protocol/http-request.decoder.d.ts +52 -3
  149. package/dist/protocol/http-request.decoder.js +45 -6
  150. package/dist/protocol/http-request.reader.d.ts +10 -3
  151. package/dist/protocol/http-request.reader.js +12 -2
  152. package/dist/protocol/http-response.encoder.d.ts +12 -0
  153. package/dist/protocol/http-response.encoder.js +17 -3
  154. package/dist/protocol/operation-response.guard.js +1 -3
  155. package/dist/protocol/operation-set.decoder.d.ts +48 -0
  156. package/dist/protocol/operation-set.decoder.js +185 -0
  157. package/dist/protocol/operation-set.handler.d.ts +27 -0
  158. package/dist/protocol/operation-set.handler.js +179 -0
  159. package/dist/protocol/protocol-headers.d.ts +12 -3
  160. package/dist/protocol/protocol-headers.js +12 -5
  161. package/dist/protocol/protocol-surface.d.ts +16 -3
  162. package/dist/protocol/protocol-surface.js +41 -1
  163. package/dist/protocol/protocol.binder.d.ts +52 -1
  164. package/dist/protocol/protocol.binder.js +6 -1
  165. package/dist/protocol/protocol.handler.d.ts +45 -1
  166. package/dist/protocol/protocol.handler.js +164 -19
  167. package/dist/protocol/read-cache.responder.d.ts +26 -0
  168. package/dist/protocol/read-cache.responder.js +47 -0
  169. package/dist/protocol/read-query.codec.d.ts +34 -0
  170. package/dist/protocol/read-query.codec.js +125 -0
  171. package/dist/runtime/caller-data.copier.d.ts +18 -3
  172. package/dist/runtime/caller-data.copier.js +21 -8
  173. package/dist/runtime/caller-data.door.d.ts +13 -6
  174. package/dist/runtime/computed-read-runtime.d.ts +6 -1
  175. package/dist/runtime/computed-read-runtime.js +229 -48
  176. package/dist/runtime/computed-value.error.d.ts +3 -2
  177. package/dist/runtime/computed-value.error.js +3 -2
  178. package/dist/runtime/context-executor.runtime.d.ts +4 -3
  179. package/dist/runtime/context-executor.runtime.js +4 -2
  180. package/dist/runtime/core-class.brand.d.ts +10 -0
  181. package/dist/runtime/core-class.brand.js +21 -0
  182. package/dist/runtime/create-requirement.d.ts +31 -5
  183. package/dist/runtime/create-requirement.js +130 -24
  184. package/dist/runtime/decimal.d.ts +14 -0
  185. package/dist/runtime/decimal.js +21 -0
  186. package/dist/runtime/diagnostics-reporter.d.ts +49 -9
  187. package/dist/runtime/diagnostics-reporter.js +16 -9
  188. package/dist/runtime/error-boundary.d.ts +9 -2
  189. package/dist/runtime/error-boundary.js +12 -0
  190. package/dist/runtime/error-guidance.d.ts +12 -0
  191. package/dist/runtime/error-guidance.js +1 -0
  192. package/dist/runtime/error.catalog.d.ts +49 -0
  193. package/dist/runtime/error.catalog.js +49 -0
  194. package/dist/runtime/execution-options.d.ts +8 -0
  195. package/dist/runtime/field-check.evaluator.d.ts +0 -2
  196. package/dist/runtime/field-check.evaluator.js +1 -1
  197. package/dist/runtime/field-compute.d.ts +11 -10
  198. package/dist/runtime/field-stage.runtime.d.ts +3 -3
  199. package/dist/runtime/field-stage.runtime.js +9 -11
  200. package/dist/runtime/field-validator.runtime.d.ts +19 -1
  201. package/dist/runtime/field-validator.runtime.js +49 -9
  202. package/dist/runtime/framework-error.js +9 -0
  203. package/dist/runtime/framework-warning.emitter.d.ts +6 -0
  204. package/dist/runtime/framework-warning.emitter.js +8 -0
  205. package/dist/runtime/json-value.d.ts +10 -5
  206. package/dist/runtime/level-lifecycle.runtime.d.ts +4 -3
  207. package/dist/runtime/level-lifecycle.runtime.js +3 -5
  208. package/dist/runtime/mutation-planner.d.ts +1 -6
  209. package/dist/runtime/mutation-planner.js +4 -17
  210. package/dist/runtime/nested-write.walker.js +2 -1
  211. package/dist/runtime/operation-code.guidance.d.ts +6 -0
  212. package/dist/runtime/operation-code.guidance.js +167 -0
  213. package/dist/runtime/operation-request.d.ts +16 -9
  214. package/dist/runtime/operation-runtime.d.ts +35 -17
  215. package/dist/runtime/operation-runtime.js +220 -49
  216. package/dist/runtime/outcome-mapper.d.ts +2 -1
  217. package/dist/runtime/output-validator.d.ts +1 -1
  218. package/dist/runtime/output-validator.js +1 -3
  219. package/dist/runtime/owned-execution.registry.d.ts +34 -4
  220. package/dist/runtime/pipe-output.validator.d.ts +10 -0
  221. package/dist/runtime/pipe-output.validator.js +4 -2
  222. package/dist/runtime/pipeline.d.ts +52 -23
  223. package/dist/runtime/readonly-value.d.ts +20 -5
  224. package/dist/runtime/readonly-value.js +74 -26
  225. package/dist/runtime/record.guard.d.ts +14 -0
  226. package/dist/runtime/record.guard.js +10 -0
  227. package/dist/runtime/referential-action.d.ts +1 -1
  228. package/dist/runtime/request-envelope.validator.js +13 -10
  229. package/dist/runtime/scalar-runtime.d.ts +4 -21
  230. package/dist/runtime/scalar-runtime.js +91 -31
  231. package/dist/runtime/thenable.guard.d.ts +7 -0
  232. package/dist/runtime/thenable.guard.js +5 -0
  233. package/dist/runtime/unsent-value.normalizer.d.ts +15 -0
  234. package/dist/runtime/unsent-value.normalizer.js +129 -0
  235. package/dist/transactions/operation-arguments-encoder.js +9 -10
  236. package/dist/transactions/operation-fingerprint.js +2 -2
  237. package/dist/transactions/sql-statement.d.ts +10 -2
  238. package/dist/transactions/sql-statement.validator.d.ts +2 -2
  239. package/dist/transactions/sql-statement.validator.js +40 -6
  240. package/dist/transactions/transaction-envelope.d.ts +5 -4
  241. package/dist/transactions/transaction-integrity-error.js +2 -0
  242. package/dist/transactions/transaction-plan-assembler.d.ts +12 -5
  243. package/dist/transactions/transaction-plan-assembler.js +49 -17
  244. package/dist/transactions/transaction-plan-validator.d.ts +23 -7
  245. package/dist/transactions/transaction-plan-validator.js +31 -7
  246. package/dist/transactions/transaction-reference-collector.js +8 -10
  247. package/dist/transactions/transaction-reference-resolver.d.ts +3 -2
  248. package/dist/transactions/transaction-reference-resolver.js +1 -3
  249. package/dist/transactions/transaction-reference-validator.d.ts +43 -3
  250. package/dist/transactions/transaction-reference-validator.js +83 -57
  251. package/dist/transactions/transaction-reference.d.ts +1 -1
  252. package/dist/transactions/transaction-reference.js +5 -0
  253. package/dist/transactions/transaction-request.d.ts +8 -8
  254. package/dist/transactions/transaction-runtime.d.ts +5 -2
  255. package/dist/transactions/transaction-runtime.js +108 -27
  256. package/dist/transactions/transaction-settlement.runtime.d.ts +4 -3
  257. package/dist/transactions/transaction-slot-path-error.js +2 -0
  258. package/dist/transactions/transaction-stage.runtime.d.ts +5 -3
  259. package/dist/transactions/transaction-stage.runtime.js +8 -7
  260. package/package.json +6 -5
  261. package/src/runtime/field-check.evaluator.ts +1 -1
package/CHANGELOG.md CHANGED
@@ -1,5 +1,1002 @@
1
1
  # @aventara/core
2
2
 
3
+ ## 1.0.0-rc.11
4
+
5
+ ### Patch Changes
6
+
7
+ - 6197c08: `@/aventara/universal`'s calls are the generated client's own calls again. The entry no longer wraps each one in
8
+ `io().then(call)`, so its own `signal`, `avClient.all`'s `signal` and strict abort, and `avLazy` all reach it, in the
9
+ browser and on the server. Next's `io()` is now awaited before the request is sent.
10
+
11
+ In the browser, the calls made in one tick are still grouped into one `/_all`. On the server, none is grouped: each
12
+ call has a client of its own with grouping off, and it is sent from the async context of the code that made it. Before,
13
+ one queue served every request. Calls from two concurrent requests, or a call inside `unstable_cache` and one outside
14
+ it, could share a flush and run with the first call's headers and `state`.
15
+
16
+ `avLazy` no longer keeps one answer for every request on a server:
17
+
18
+ - The generated client's `avLazy` keeps its answer in a page. On a server (no `location`) it keeps none, and each await
19
+ makes the call again.
20
+ - `@aventara/core`'s `avLazy` keeps none: each await makes the call again.
21
+ - `@/aventara/universal` now exports its own `avLazy`, which keeps one answer per request inside a React render
22
+ (React's `cache`, which the entry now imports) and none where React keeps no request.
23
+
24
+ Before, an `avLazy` made at module scope handed the first request's answer to every request after it.
25
+
26
+ `ready()`'s in-process path now splits a cached read's GET URL into its path and its `?q=&v=` query, with an empty
27
+ body, so the read reaches its GET route instead of being answered as absent.
28
+
29
+ - e0e89c1: A streamed `/_all` answer carries `Cache-Control: no-store` and `X-Accel-Buffering: no`, so no cache keeps it and a
30
+ buffering proxy passes each line on. A host that stops reading the lines (`return()`) now stops the set at once, even
31
+ while it waits for the next line.
32
+ - 186bc29: `POST /_all` answers an Operation Set: several independent operations in one request, under keys the caller names
33
+ (`{ operations: { <key>: { resource, family, variant, args } } }`). Every entry runs concurrently and exactly as it would
34
+ through its own route, and the answer is `200 A1000` with each key holding that entry's own envelope. With `Accept:
35
+ application/x-ndjson` the binding answers one line per entry as it settles instead. The host seeds the state once and the
36
+ principal is derived once for the whole request. `AvProtocol.bind(framework).handleAll(request, { state?, signal? })`
37
+ answers the route, `surface()` lists it (`kind: "all"`) whenever the Contract advertises an operation, and
38
+ `limits.maxAll` (default 10, root and per layer) bounds it, and `limits.maxAllConcurrency` (default 4) caps how many of
39
+ its entries run at once. `AvOperationDiagnostic.key` names the entry a failure met. Every Client
40
+ Contract's hash moves once, because its limits now include `maxAll` and `maxAllConcurrency`.
41
+ - 33b5f83: Reads can be cached. A `cache({ for, maxAge })` stage (exported from `@aventara/core`) at `pipelines.cache` of the root or
42
+ client layer, a Resource, the `find` family or one `find` variant serves those reads as
43
+ `GET /_resources/<R>/find/<variant>?q=<arguments>&v=<contract hash>` beside their POST; the most specific level's stage
44
+ wins, and a write, a transaction or the application or agent layer refuses it (`CONFIG_INVALID_VALUE`). `for` is who may
45
+ share one answer: `"user"` (the default; `Cache-Control: private` and `Vary: Authorization, Cookie`), `"anonymous"`
46
+ (`public` for an anonymous caller, `private` for a signed-in one, both varying on `Authorization` and `Cookie`) or
47
+ `"everyone"` (`public`). Write `for` every time, even for `"user"`. With a policy, anonymous is a `null` principal;
48
+ without one, a request with no `Cookie` and no `Authorization`. `q` is the arguments' canonical JSON, plain or
49
+ deflate-raw + base64url; more than `limits.maxRequestBytes` of it, inflated or not, is `413 A2010`, and a `v` that is not
50
+ the Client Contract's hash is `409 A2005`. A `200` also answers `Referrer-Policy: no-referrer` and an `ETag`; a matching
51
+ `If-None-Match` is `304`; anything else is `no-store`; a public answer echoes no `Aventara-Request-Id`. Every answer to a
52
+ GET, `/_contract`'s included, carries `X-Content-Type-Options: nosniff`. The Client Contract marks each cached read, so
53
+ its hash moves. `ctx.$transport.method` is `"POST" | "GET"`, and `AvProtocolRequest` takes the URL's `query`.
54
+ - 6d8b589: Internal: the object and plain-object checks the runtime, compiler, configuration and protocol modules share now live in
55
+ one module, the thenable check and the `maxAllConcurrency` reader have one copy each, and the three fixed `POST` routes (`/_transactions`, `/_access/can`, `/_all`) share one check before their
56
+ body. No behaviour changes.
57
+ - 11ece49: `framework.serverClient.all(entries, { settle?, signal? })` is the generated client's `avClient.all` in process: an
58
+ object of promises awaited in memory, never over HTTP. `serverClient` calls stay eager (they run when made), so `all`
59
+ awaits them as they are; `avLazy(() => call)`, new in `@aventara/core`, is a thenable that makes its call on its first
60
+ await, once, and `all` starts its `avLazy` entries itself, at most the Client Contract's `limits.maxAllConcurrency` at
61
+ once; any number of entries is accepted (`limits.maxAll` guards `POST /_all` only). Strict by default (one value per key; the
62
+ first failure rejects it and its `avLazy` entries not yet started never start); `settle: true` gives
63
+ `{ status: "fulfilled", value } | { status: "rejected", reason }` per key. Its `signal` aborts each entry, and a
64
+ `serverClient` call takes its own `signal`. A Client Contract Resource named `all` is refused at construction
65
+ (`COMPILER_RESERVED_RESOURCE_NAME`).
66
+ - 92fd093: Core's declarations name no platform global. The `signal` of a `serverClient` call, of `serverClient.all` and of the
67
+ protocol binding's `handleAll` is typed by the members core reads (`aborted`, `reason`, and `addEventListener` /
68
+ `removeEventListener` for `"abort"`) instead of `AbortSignal`, so a project with neither DOM's lib nor Node's types
69
+ type-checks against `@aventara/core` again. Any runtime's `AbortSignal` is still accepted as it is.
70
+ - e5e98e6: The docs moved to https://aventara.razor34.dev/framework. Every `docs` link in `AvErrorCatalog` (and
71
+ `ERRORS.md`), and every docs link `aventara new`, `aventara init` and `aventara skill` write into the scaffold and the
72
+ agent skill, now point there instead of https://aventara-framework.vercel.app.
73
+ - a05d970: A plan's principal is derived once, before any step runs. `/_transactions`, `framework.executeTransaction` and
74
+ `framework.transaction` read `policy.principal` once per origin, before the first step's guards, pipes and compute, as
75
+ `/_all` does. A stage of an earlier step that writes `ctx.$state` no longer changes who a later step is checked as.
76
+ `@aventara/core/internal` adds `holdRequestPrincipal(state)`, which a host calls on the one state object it shares
77
+ between a request's calls, so each call reads the principal the first one derived. A call that names its principal (`{ as }`)
78
+ under a held state still derives and holds the state's own first, before its stages run.
79
+
80
+ ## 1.0.0-rc.10
81
+
82
+ ### Security
83
+
84
+ - A nested to-one relink could bypass a policy's update scope. In rc.9 and earlier, a to-one `$update` or `$upsert`
85
+ beside `$connect`, `$connectOrCreate`, `$create`, `$set` or `$disconnect` on the same relation ran the relink first
86
+ and then wrote the newly linked row, while the update scope, field grants, `grantsOf` and the after check had been
87
+ asked about the row linked before the call. A caller whose read scope reached a row its update scope did not could
88
+ change that row (`Post.update.unique({ data: { author: { $connect: { id }, $update: { data } } } })`). rc.10 refuses
89
+ the combination for every caller (`A2004`, one `V1012` issue at the relation) before anything runs, and the argument
90
+ types reject it. Upgrade if a policy engine guards updates through to-one relations; to relink and update, use two
91
+ writes. Details under Patch Changes below.
92
+
93
+ ### Patch Changes
94
+
95
+ - 587dd01: With `access` configured, the protocol serves `POST {api}/_access/can`: a page asks the policy engine about all of its
96
+ buttons in one request and gets one boolean per question, in order.
97
+
98
+ ```http
99
+ POST /api/_access/can
100
+ { "questions": [
101
+ { "resource": "Order", "action": "update", "where": { "id": 41 } },
102
+ { "resource": "Refund", "action": "create" }
103
+ ] }
104
+ ```
105
+
106
+ ```json
107
+ 200 { "code": "A1000", "data": [true, false], "cause": null }
108
+ ```
109
+
110
+ - Each answer is what the call the question stands for would do before any data is sent, under the principal
111
+ `ctx.$state.me` (seeded by the provider's `state`) and the origin `client`:
112
+ - an operation the Client Contract does not offer (with `where`, the action's unique variant) answers `false`;
113
+ - a question without `where` is the operation-level `policy.can`;
114
+ - a question with `where` (the Resource's unique where) is that unique call's policy admission (`can` without a
115
+ row, then every field it names against `fieldsOf`), then one `exists` for the row within its scopes: the read
116
+ scope, and for an update or delete the action's scope too. A row out of scope answers `false` exactly as a
117
+ missing row does, and no value of the row is read or handed to the engine;
118
+ - an update question answers `false` where the real update is refused before it runs: an update the engine lists
119
+ in `afterChecks` on a database without interactive transactions;
120
+ - an `AvError` the engine throws with a refusal code and a well-formed cause answers `false` for its question;
121
+ anything else it throws is `500 A3000`.
122
+ - The answer is about the row and the action, not about what a page reads of the row: it is the call selecting the
123
+ Resource's identifier. A page's own call that selects a field readable on some rows only is checked on its own.
124
+ - The answer only shapes a UI: the real call is still checked, and the route never answers `403`. It refuses malformed
125
+ input only, with codes the other routes already use: `404 A2002` (`V1006` at `["questions"]`) without `access`,
126
+ `405 A2012`, `400 A2000`, `409 A2005`, `400 A2006`, `404 A2001` for an unknown or client-hidden Resource,
127
+ `422 A2004` with each issue at `["questions", i, …]` (a `create` question with `where` included), `422 A2009`
128
+ (`V1014`) for more questions than the Client Contract's `maxListLimit`, and `500 A3000` when the engine fails
129
+ (`A3001` when the adapter fails under it). Questions are answered at most eight at a time, and
130
+ `questions: []` answers `200` with `[]`.
131
+ - `AvProtocol.bind(framework).handleCan(request, { state })` answers it, and `protocol.surface()` lists it as
132
+ `{ kind: "can", method: "POST", path: "/_access/can" }`, last, exactly when the route exists. An agent binding has
133
+ no `can` route.
134
+ - The Client Contract carries an `access` section exactly when `access` is configured (`{}` for now), so the
135
+ Contract hash changes only for apps that configure `access`. `validateClientContractStructure` accepts it.
136
+ - A failure while answering reaches the `diagnostics` sink as a new kind, `AvCanDiagnostic`
137
+ (`{ kind: "can", error, code, origin: "client", requestId }`). When one question met it, it also names that
138
+ question's index (`question`), `resource` and `action`; a failure of the whole request (the state seed, say) names
139
+ none.
140
+ - New main-entry types: `AvAccessQuestion` (one question, generic over the Resource names and their unique where),
141
+ `AvContractClientAccess` (the section) and `AvCanDiagnostic`.
142
+
143
+ - d7e7369: `$access` on `framework.serverClient`, and the access provider's optional `client`.
144
+
145
+ - `AvAccessProvider.client?: { url, verbs }` states where the app mounted Aventara Access and the verbs it offers:
146
+ `signIn`, `signUp`, `signOut`, `resetPassword` and `me`, each optional (a `service` profile has no `signIn` or
147
+ `signUp`). Each verb is `{ method, path, args?, result, call }`: its route, the JSON Schema of its arguments and
148
+ result, and `call`, the verb run in process with `{ args, headers, request?, response? }`. `url` must be an
149
+ absolute `http(s)` URL or a root-relative path; each verb is checked at startup (`access.client.*`).
150
+ - The Client Contract's `access` section carries `url` and the stated verbs, each `call` dropped, its schemas checked
151
+ against the `json` field subset. Apps without `access`, or whose provider states no `client`, keep their hash. The
152
+ prebuilt fingerprint reads the `client`'s data, never its `call`.
153
+ - `framework.serverClient.$access` exists exactly when `access` is configured (a type error otherwise): `can(questions,
154
+ options?)` is answered in process by the `/_access/can` route's own answerer, under the call's `state`, a
155
+ question's `where` read in the application forms; `me()` and the other verbs the provider offers run its `call`
156
+ with the `headers` you pass (a Web `Headers` or a Node request's `headers`) and, when given, the host's `request`
157
+ and `response` (Access sets a sign-in's cookie on the response under Nest). `me()` resolves the token identity, or
158
+ `null`. A provider without `client` offers `can` alone.
159
+ - New main-entry type `AvAccessVerbs`: `$access`'s type on every client.
160
+ - `validateClientContractStructure` holds the section's `url` (absolute `http(s)` or root-relative, never `//host`) and
161
+ each verb's `path` (one leading `/`) to the same rule the configuration is held to, so a consumer refuses a served
162
+ ClientContract that points elsewhere.
163
+ - `serverClient.$access.can` called with `headers` and no `state` is answered under the state the provider seeds from
164
+ those headers; with neither, anonymously.
165
+
166
+ - 7ee547b: `AvAccessProvider.client.verbs` takes Aventara Access's `kiosk` profile verbs too: `switchUser`, `lock`, `setPin`,
167
+ `enrollDevice` and `revokeDevice`, each optional and shaped as the other verbs (`{ method, path, args?, result, call }`); any
168
+ other name is still refused at startup. They reach the Client Contract's `access` section only when the provider
169
+ states them, so an app without them keeps its hash. `framework.serverClient.$access` runs each through its `call` in
170
+ process, with the headers, request and response you pass (Access sets the rotated device cookie on the response under
171
+ Nest): `switchUser(args)` and `enrollDevice(args)` resolve Access's answer; `lock()`, `setPin(args)` and
172
+ `revokeDevice(args)` resolve nothing. `AvAccessVerbs` gains the five members, and its `Args` names `switchUser`,
173
+ `setPin`, `enrollDevice` and `revokeDevice`. The MCP agent surface offers none of them.
174
+
175
+ The `access` section's `url` and each verb's `path` now also refuse U+0000–U+0020 and DEL, `.`/`..` segments
176
+ (percent-encoded too) and a bare `"/"` url, in the configuration and in every ClientContract read: a URL parser drops
177
+ tab, LF and CR, so `"/\t/evil.example"` resolved to another host. `serverClient.$access` now projects every verb's
178
+ answer (and `me`'s identity) onto its result schema, as the generated client and MCP `me` do; an answer the schema
179
+ cannot describe throws.
180
+
181
+ - f52c499: A model whose table another service owns can be marked at the root: `resources.<R>.managedElsewhere: true`. Aventara
182
+ reads it and joins through it, and no standard operation writes it.
183
+
184
+ ```ts
185
+ createFramework({
186
+ api: "/api",
187
+ adapter,
188
+ resources: { Account: { managedElsewhere: true } },
189
+ });
190
+ ```
191
+
192
+ - No `create`, `update`, `delete` or `upsert` on it in any layer, and no field write. A call is a type error, and an
193
+ untyped one is `A2002`.
194
+ - A relation into it keeps only `$connect`/`$disconnect`, and only where the source holds the key; a nested
195
+ `$create`/`$update`/`$upsert` into it is a type error and `A2004` (`V1006`).
196
+ - The client and agent Contracts leave it out, with every relation into it. `framework.application` reads and joins it.
197
+ - A stage on one of its write families is refused at startup (`COMPILER_UNAVAILABLE_OPERATION`); the key in an overlay
198
+ is `CONFIG_FORBIDDEN_IN_OVERLAY`.
199
+ - The Core Contract marks it `managedElsewhere: true` and states each Resource's database `schema` when the adapter
200
+ does (`AvCoreResource.schema`, `AvCoreResource.managedElsewhere`; the adapter states it as `AvAdapterResource.schema`).
201
+ No other Contract carries them, so no Client Contract hash moves.
202
+ - A delete whose referential action would write it (`cascade`, `setNull`, `setDefault`, directly or through other
203
+ cascades) is refused at startup (`CONFIG_INVALID_VALUE` at `resources.<R>.managedElsewhere`), and a create that only
204
+ the hidden relation could satisfy is `COMPILER_HIDDEN_REQUIRED_FIELD`.
205
+ - Not covered: key updates follow the owner's foreign key (core has no `onUpdate` facts), and `ctx.$sql` or a stage
206
+ calling the ORM can still write it.
207
+
208
+ - 2907484: `mcp.authorization.servers` accepts an http authorization server on this machine, so an MCP setup on a laptop needs no
209
+ TLS: `http://127.0.0.1:4000` or `http://[::1]:4000`, with any port and path.
210
+
211
+ - `localhost` (any case) is refused with the address to use: `… is an http loopback URL; write it as
212
+ http://127.0.0.1:4000, the spelling every client reads as this machine`. A name is looked up, and `localhost` can
213
+ resolve somewhere else (RFC 8252 §8.3).
214
+
215
+ - Any other http URL is refused as before (`mcp.authorization.servers[0] must be an absolute https URL`). That covers
216
+ `0.0.0.0`, `[::]`, other `127.x` addresses, IPv4-mapped addresses, names such as `auth.localhost` or
217
+ `localhost.example.com`, and URLs with credentials.
218
+ - The host is read the way the WHATWG URL parser reads it, and the URL must be written the way that parser writes it
219
+ back. `http://127.1:4000`, `http://2130706433:4000` and `http://127.0.0.1:4000\@example.com` are refused with the
220
+ spelling to use (`… is an http loopback URL; write it as http://127.0.0.1:4000, the spelling every client reads as
221
+ this machine`), so no client can read a different host from the URL your metadata advertises.
222
+ - Every server, https included, is refused when its path has an empty segment (`//`) or it names port 0. A client
223
+ builds its discovery URLs from the path, and a path starting `//` is protocol-relative: `http://127.0.0.1//evil.com`
224
+ would send the client to `evil.com` for its metadata. A loopback http server also takes no query or fragment.
225
+ - An http authorization server is for local development only; deploy with https.
226
+
227
+ - a6bbdf0: For an update the engine lists in `afterChecks`, the after check now also hands the engine the changed row as it was
228
+ before the update: `can({ action: "update", row, before })`. Core reads it inside the update's transaction, ahead of
229
+ the write, with the fields `row` carries, so an engine can require that one grant covers a row both before and after
230
+ the update and stop an update moving a row from one grant's rows to another's. `before` is optional and present only
231
+ for a listed update; an unlisted update gets none and runs exactly the statements it ran before. A listed root
232
+ `update.unique`, `update.many` or `update.count` runs one read more (a nested write reuses the read it already makes).
233
+
234
+ The listed update is held to the rows as that read saw them (their values ANDed into the write's selector), so a row
235
+ changed concurrently is missed instead of checked against a stale `before`. A listed update that writes several rows
236
+ and cannot pair a changed row with its `before`, or of a Resource offering no `find.many`, is refused (`A4002`).
237
+
238
+ Fixed: an update whose rows are checked after it without being returned (a nested `$update`, a linked row, an
239
+ `update.count` that reads its rows first) skipped the after check for a row whose identifier it changed. It is now
240
+ refused (`A4002`) and rolled back.
241
+
242
+ - 3e26549: A policy engine may answer a new optional question, `grantsOf({ principal, origin, resource, action: "update", row,
243
+ exists })`, with a list of strings: its own keys for the grants that cover `row`. For an update the engine lists in
244
+ `afterChecks`, core asks it about each row as it was before the update, right after reading that row and before any
245
+ interceptor, hook or the write itself, inside the update's transaction, so the rule's `exists` lookups see nothing the
246
+ request writes. The after check of the same row then states the answer, unchanged, as `beforeGrants` beside `before`.
247
+ An engine that requires one grant to cover a row both before and after its update can require the grant covering
248
+ `row` to be one of `beforeGrants`, so a nested write in the same request (a membership created alongside the update)
249
+ can no longer make `before` appear to meet a relation-based grant it did not meet.
250
+
251
+ Additive: an engine without `grantsOf`, and an update `afterChecks` does not list, are asked exactly what they were
252
+ before. An answer that is not a list of strings answers `A3000` and nothing is written; a `grantsOf` that is present
253
+ and not a function fails construction (`CONFIG_INVALID_TYPE`).
254
+
255
+ - a6bbdf0: A policy engine may state a typed literal in a fragment it answers (a `scopeOf` scope, a `fieldsOf` per-row grant, an
256
+ `exists` question) in its wire form as well as its application form: `"2026-01-01T00:00:00.000Z"` or a `Date`,
257
+ `"0.3"` or an `AvDecimal`, `"9007199254740993"` or a `bigint`. Both reach the adapter as the runtime value and select
258
+ the same rows. Before, a wire form answered `A3000`, so an engine whose rules are data (read from JSON) could not
259
+ compare a `datetime`, `decimal` or `bigint` field. A value in neither form is still the server's `A3000`.
260
+ - 6f3f6f6: **Security.** A to-one `$update` or `$upsert` next to `$connect`, `$connectOrCreate`, `$create`, `$set` or
261
+ `$disconnect` on the same relation is now refused for every caller: `A2004` with one `V1012` issue at the relation,
262
+ before anything runs. The argument types now reject the combination too. Before this fix (rc.9 and earlier), the ORM ran
263
+ the relink first and the update then wrote the newly linked row. But a policy's update scope, its field grants,
264
+ `grantsOf` and the after check had all been asked about the row linked before the call. So a caller whose read scope
265
+ reached a row that its update scope did not could still change that row, for example with
266
+ `Post.update.unique({ data: { author: { $connect: { id }, $update: { data } } } })`. To do both, relink in one write and
267
+ update the linked row in another. A to-many operand may still combine them, because each entry names its own rows.
268
+
269
+ A `grantsOf` answer that is a sparse list (one with a hole) is now the server's defect (`A3000`), as any other answer
270
+ that is not a list of strings already was. Before, the hole reached `can` as an `undefined` grant.
271
+
272
+ - 04bb39a: `engines.node` is now `^22.23.4 || >=24.22.1`, the Node security releases of 2026-10-20 (CVE-2026-105481,
273
+ CVE-2026-105482, CVE-2026-105483, CVE-2026-106069, CVE-2026-106072, CVE-2026-106073, CVE-2026-106074,
274
+ CVE-2026-111497). The bins refuse an older Node in one sentence naming that range.
275
+ - 3fb3333: `@aventara/mcp` pins `@modelcontextprotocol/sdk` 1.32.2 (was 1.30.1) and `zod` `^4.6.7` (was `^4.6.5`); `@aventara/core`
276
+ also takes `zod` `^4.6.7`. This clears the advisories against those versions:
277
+
278
+ | Advisory | Severity | Package | What it was |
279
+ | ------------------------------------- | -------- | ------------------- | -------------------------------------------------------------------------------------------------------- |
280
+ | GHSA-46jr-4wx8-v453 (CVE-2026-111768) | high | sdk < 1.32.0 | One HTTP request within the default size limit could exhaust server memory during validation |
281
+ | GHSA-22jm-h49p-29qw (CVE-2026-111767) | high | sdk 1.24.0 – 1.31.x | Experimental tasks were not tied to the session that created them |
282
+ | GHSA-6qxp-vccf-f47h (CVE-2026-104850) | high | sdk 1.12.0 – 1.30.x | The OAuth client could send credentials to an authorization server chosen by the MCP server |
283
+ | GHSA-mrhx-c7xc-m3w5 | high | zod ≤ 4.6.5 | Validating an oversized unconstrained array could exhaust memory |
284
+ | GHSA-rvq5-wwqv-78pq (CVE-2026-111771) | moderate | sdk 1.6.0 – 1.31.x | Server bearer authentication accepted tokens issued for another service |
285
+ | GHSA-6prh-2h8m-c8cw (CVE-2026-111769) | moderate | sdk < 1.32.0 | HTTP client transports and OAuth requests followed cross-origin redirects with custom headers and bodies |
286
+
287
+ Aventara's MCP server was already outside most of these: it uses the low-level `Server` (no `taskStore`, no
288
+ `requireBearerAuth`, no SDK OAuth client), and its transport's `maxRequestBodySize` is the agent layer's
289
+ `limits.maxRequestBytes`. No API of `@aventara/mcp` changes.
290
+
291
+ - 827ccb6: A listed update (`afterChecks`) no longer refuses an unchanged row on PostgreSQL. The compare-and-swap that holds the
292
+ write to the rows as they were read compares each field by `equals`, and the adapter's `equals` now matches every row
293
+ that reads as the value:
294
+
295
+ - a scalar list a create left out, which Prisma stores as `NULL` and reads as `[]`: an operator object that holds for
296
+ `[]` (`equals: []`, `isEmpty: true`, `hasEvery: []`) holds for that row too, in every filter;
297
+ - a timestamp finer than a millisecond (a `@db.Timestamptz(6)` the database writes), which Prisma reads truncated:
298
+ equality with an instant also holds the instants inside its millisecond.
299
+
300
+ On a `Bytes[]` column, `equals`, `hasEvery` and `hasSome` are no longer offered: Prisma 7.10.1 binds their operand's
301
+ members as base64 text, so they matched other rows than they named. `has` and `isEmpty` remain. Such a column is not
302
+ part of the compare-and-swap.
303
+
304
+ The compare-and-swap takes its fields from what the adapter compares, so an exemption that hides `equals` from callers
305
+ no longer takes a field out of it.
306
+
307
+ - 7f5abc3: An editor's hover over a provider written `satisfies AvAccessProvider`, and the declarations a consumer emits for one,
308
+ no longer name `AccessRequestHeaders`, a module-local alias no entry exports. `state`'s `headers` is written inline
309
+ again, and each verb's `call` reads the same type from `state` (`Parameters<AvAccessProvider["state"]>[0]["headers"]`),
310
+ so both print as the part of a Web `Headers` they are. A test now holds what a provider's hover names to the
311
+ entry's exports and TypeScript's library.
312
+ - 88263a1: Startup checks, tightened:
313
+
314
+ - An `mcp.authorization.servers` entry with a query or a fragment is refused for https URLs too, not only for loopback
315
+ http ones: an authorization server's issuer has neither (RFC 8414).
316
+ - A `client.resources` or `agent.resources` entry for a Resource managed elsewhere is refused (`COMPILER_UNKNOWN_RESOURCE`):
317
+ those layers never have the Resource, so nothing configured there would run. Configure it at the root or in
318
+ `application`.
319
+
320
+ - 10341d5: Policy checks, tightened:
321
+
322
+ - Writing a reference field itself (`authorId: "u2"`) is held to the target's read scope, as `$connect` is: the row it
323
+ names must be one the caller may read, or the write is refused (`A4002`). Creates, updates, both branches of an
324
+ upsert and the records of nested writes are all checked. The reference is handed to the adapter as a `$connect` that
325
+ carries the read scope, so the write itself refuses a row outside it, with no extra query; a row that is not there is
326
+ refused the same way. Where Prisma's input takes no relation (`createMany`, `updateMany`, a to-many nested
327
+ `$update`), and where a create writes a reference `null` (left out, the column's default would fill it), one count
328
+ per target Resource asks before the write whether every row named is there and readable. Nothing is asked where that
329
+ Resource is read by everyone, and a `null` reference is not asked about. A record written this way writes its other
330
+ references as links too, so a missing row there answers `A2003` rather than `A2008`.
331
+ - A row a write names to link that is not there is refused (`A4002`) like a row the caller cannot read, wherever the
332
+ target has a scope: a reference field, and a `$connect`, `$set` or `$disconnect` selector. Before, a missing row
333
+ answered the store's `A2008` or `A2003`, which told a caller which rows it cannot read exist. Without a scope, the
334
+ codes are unchanged.
335
+ - An update the engine lists in `afterChecks` now holds a to-one nested `$update` to its row as it was read. A row a
336
+ concurrent write changed in between refuses the write (`A4002`) and rolls it back, with no extra query.
337
+ - A listed `update.many` or `update.count` that changes fewer rows than it read (a concurrent write changed one in
338
+ between) is refused (`A4002`) and rolled back, rather than answering a partial success.
339
+ - The client and agent Contracts leave out an enum that only a Resource managed elsewhere uses. The ClientContract hash
340
+ of an app with such an enum changes.
341
+ - Seven public types write their members out in an editor's hover instead of naming a type no entry exports (`ctx.$sql`,
342
+ a compute stage's context, a pipe's return, `defineResource`'s overlays, a family's variants, the `access` and
343
+ `policy` check, `AvConfigComputedFields.agentExtends`).
344
+
345
+ - 8129844: A policy engine may take the optional `hosted({ held })`. Core calls it once, when a Framework is built on the engine
346
+ and every construction check has passed, with the Resources a written reference is held to the read scope of: every
347
+ Resource of the Core Contract, so none the root's exemptions hide. An engine can check its rules against that list and
348
+ warn about a write its rules allow that the hold would always refuse. It changes no answer. A `hosted` that is not a
349
+ function fails construction (`CONFIG_INVALID_TYPE`), as `grantsOf` does.
350
+ - 88263a1: Policy checks, tightened:
351
+
352
+ - The rows a write returns are checked against the database as the write left it. An `exists` answer asked before the
353
+ write (by `grantsOf`, say) is no longer reused for the same question after it.
354
+ - A `fieldsOf` answer whose `always` is a sparse list is the server's defect (`A3000`), as a sparse `grantsOf` answer
355
+ is.
356
+ - An access provider's verbs are its own enumerable `client.verbs` keys. A verb `verbs` only inherits, or holds
357
+ non-enumerable, is no verb: never offered on `$access` and never compiled into the Client Contract.
358
+
359
+ - 3020b5c: A policy engine may list `unheld`: the Resources its rules read in conditions and decide no read of, such as one another
360
+ service owns. A reference a write sends to a row of one, and a `$connect` or `$set` that links one by the reference's
361
+ own values where the writing row holds the reference, is no longer held to the caller's read scope, which is `false` for every caller there and refused
362
+ every such write (`A4002`). The write's own grant decides which row may be linked (`can`, and the after check). Reads of
363
+ those Resources are decided by `scopeOf` as before, and `hosted({ held })` leaves them out. A value that is no list of
364
+ strings fails construction (`CONFIG_INVALID_TYPE`), and so does a name the data source's model does not have
365
+ (`CONFIG_INVALID_VALUE`).
366
+ - 88263a1: Documentation: `$access.can([])` answers `[]`, not a refusal; the MCP README states the query and fragment rule for
367
+ every authorization server.
368
+ - 88263a1: A value projected onto an `access` verb's result schema is refused with the projector's own `TypeError` when the schema
369
+ is outside the forms a Client Contract states (a free-form object or list, a tuple read past its length), whatever the
370
+ value, an empty one included. A Client Contract that passed its structure check never holds such a schema.
371
+
372
+ ## 1.0.0-rc.9
373
+
374
+ ### Patch Changes
375
+
376
+ - 205a379: `createFramework` takes `access`, an access provider: the policy engine and the request state from one object.
377
+ `AvAccessProvider` is the new main-entry type it is written against, with two members:
378
+
379
+ - `policy`: the engine every client and agent request is checked against, as `policy.engine` takes it.
380
+ - `state({ headers, request })`: seeds each request's `ctx.$state`. Its `me` is the principal the engine is asked
381
+ about, `null` for an anonymous caller.
382
+
383
+ Aventara Access provides one, and a hand-written provider works the same way (a till's PIN sign-in, say: see the
384
+ README). The host calls `state` once per request; server code that calls the Framework directly passes the state
385
+ itself. A governed field of the provider's engine is left out of the default projection's type, as with `policy`.
386
+ `access` together with `policy` is refused at startup (`CONFIG_INVALID_VALUE` at `policy`) and is a type error at
387
+ `policy`. A provider whose `policy` is no engine or whose `state` is no function is refused at startup, member by
388
+ member, and the engine's `governed`, `paths` and `afterChecks` are checked against the Core Contract under
389
+ `access.policy`. A prebuilt Contracts file counts the provider by its engine's governed set alone.
390
+
391
+ - a0bb05e: A Framework's `diagnostics` sink receives every report when the process holds more than one copy of `@aventara/core`
392
+ (Next.js giving each layer its own copy, a duplicate install, a monorepo). A protocol failure such as a result with no
393
+ wire form (`500 A3003`), or an MCP endpoint failure, raised through another copy than the one that built the Framework
394
+ now reaches the sink instead of being silently dropped. Copies of one major version share the sinks; nothing in the
395
+ public API or its types changed.
396
+ - 86ab319: Values and errors from `@aventara/core` are recognized across duplicate copies of the package in one process. A
397
+ bundler that gives each layer its own copy (Next.js instrumentation, route handlers and pages), a duplicate install, a
398
+ monorepo, Vite SSR, per-function bundles and test runners' module isolation all load core more than once.
399
+
400
+ - A decimal made by one copy is an `AvDecimal` to every other: `value instanceof AvDecimal` is `true`, the protocol
401
+ encodes it (a `find.many` selecting a decimal no longer answers `500 A3003` "Result serialization failed"), and a
402
+ Framework accepts it in arguments, `$sql` values and Adapter results.
403
+ - `AvError` and its subclasses (`AvValidationError`, `AvNotFoundError`, `AvConflictError`, `AvAuthError`,
404
+ `AvInternalError`, `AvProtocolError`, `AvContractMismatchError`), `AvConstructionError`,
405
+ `AvTransactionIntegrityError` and `AvTransactionSlotPathError` pass `instanceof` across copies, with the same
406
+ subclass rules: every one is an `AvError`, and each is only its own subclass. An `AvError` a pipeline throws with
407
+ another copy's class is answered as the outcome it names. A subclass you declare yourself is checked as before.
408
+ - Copies recognize each other within one major version only. Nothing in the public API or its types changed.
409
+
410
+ - fdf52e6: `framework.serverClient` and `framework.serverClientTx`: the client layer for server code, called with application
411
+ values, such as a Next.js Server Component's.
412
+
413
+ - `framework.serverClient.<Resource>.<family>.<variant>(args, options?)` is typed from the Client Contract's view, as
414
+ `framework.client` is: what the client layer hides is absent. Its arguments are the application forms (`Date`,
415
+ `bigint`, `AvDecimal`, `Uint8Array`), the ones `framework.application` takes, and their wire strings are type errors.
416
+ Its results are `framework.client`'s. At runtime a value already in its wire form is accepted too, as
417
+ `framework.client` reads it.
418
+ - Each call copies its arguments, encodes the copy into the wire forms against the Client Contract, and runs the request
419
+ `framework.client` would run for those wire forms: the same client pipelines, validation, exposure and policy, the
420
+ same answers and the same `AvError` classes. `framework.client` itself is unchanged and keeps the wire forms.
421
+ - `framework.serverClientTx` builds client-origin transaction handles from application values. One
422
+ `framework.transaction([...])` may hold them beside `clientTx` handles, never beside `appTx` ones.
423
+ - New main-entry type names: `AvServerClientFacade`, `AvServerClientResourceFacade`, `AvServerClientFamilyFacade`,
424
+ `AvServerClientProjectingCall`, `AvServerClientPlainCall`, `AvServerClientTxFacade`,
425
+ `AvServerClientTxResourceFacade`, `AvServerClientTxFamilyFacade`, `AvServerClientTxProjectingCall`,
426
+ `AvServerClientTxPlainCall`.
427
+
428
+ ## 1.0.0-rc.8
429
+
430
+ 1.0.0-rc.5, rc.6 and rc.7 were tagged but never published; 1.0.0-rc.8 contains everything listed under them and the changes below.
431
+
432
+ ### Patch Changes
433
+
434
+ - 1c8e4ee: Helpers typed off the façades compile again in projects that emit declarations. In 1.0.0-rc.7 a function that took
435
+ `Parameters<AppFramework["application"]["Post"]["find"]["many"]>[0]` and returned its `where` (or built a new one
436
+ from it, `{ AND: [args.where ?? {}, { published: { equals: true } }] }`) without a return type failed `nest build`
437
+ (and `tsc` with `"declaration": true`) with `TS4023: ... has or is using name 'ScalarFilterOperands' ... but cannot be
438
+ named`, usually beside `TS7056`. A nested write's data could fail the same way, or name `NO_ADVERTISED_MEMBER`, and a
439
+ nested `$update`'s `where` was written into the `.d.ts` as `any`. The declaration now names the argument types
440
+ `@aventara/core` exports (`AvWhereInput`, `AvUpdateDataInput`, `AvCreateDataInput`, ...), and these new exports cover
441
+ the rest:
442
+
443
+ - `AvScalarFilterOperands`: one field's filter operators, which a filter's `not` holds again.
444
+ - `AvScalarWhereInput`: the `where` of a nested `$update` or `$delete` that only takes plain fields.
445
+ - `AvNoAdvertisedMember`: a write member that advertises nothing; it takes `{}` and refuses every key.
446
+ - `AvSqlStatementBuilder` and `AvSqlStatementValue`: the type of `framework.appTx.$sql` and the values it binds.
447
+ A method returning `framework.appTx.$sql` failed with `TS2883`/`TS2742` before.
448
+
449
+ `framework.execute` and `framework.executeTransaction` take request types that `@aventara/core` exports:
450
+ `AvOperationRequest` (`AvApplicationOperationRequest`, `AvClientOperationRequest`, `AvAgentOperationRequest`),
451
+ `AvTransactionRequest` (`AvApplicationTransactionRequest`, `AvClientTransactionRequest`,
452
+ `AvAgentTransactionRequest`) and `AvRequestProtocol` (a remote request's `protocol`). They were named from
453
+ `@aventara/core/internal` (`FrameworkOperationRequest`, `FrameworkTransactionRequest`, ...), so a declaration that
454
+ spelled them reached into the package's internal entry. Those names are gone from `@aventara/core/internal`.
455
+
456
+ An adapter's `referentialActions` edges name the fields that hold the reference `referenceFields`, as a relation of
457
+ the Core Contract does. They were called `references`, which the Core Contract uses for the target's fields.
458
+
459
+ Reading a projecting variant's argument type (`Parameters<…["find"]["many"]>[0]`) also type-checks faster: about
460
+ 6,000 type instantiations over a three-field model, where rc.7 took about 29,000. The part of the argument other than
461
+ `select`/`include` is now marked `NoInfer` in the call's parameter, so an editor shows that parameter as
462
+ `NoInfer<Omit<…>> & …`. What it accepts is unchanged.
463
+
464
+ A create's `data` type now states each required field once, as a required member (`Readonly<{ title: string; } & {
465
+ body?: ... }>` in an editor's expanded hover). Before, a required field appeared as an optional member beside a
466
+ separate `{ readonly title: WrittenValue }`, and a declaration file wrote both. What a create accepts and refuses is
467
+ unchanged.
468
+
469
+ - Operation results read as their value types in an editor and in emitted declarations. A result field that is nullable,
470
+ an enum or a `boolean` (such as a `Boolean @default(false)` column) was shown as `AvScalarValueType<…>`, with the
471
+ whole Contract view as its argument, and a project with `"declaration": true` wrote that view into its `.d.ts` once
472
+ per such field: a Nest service of five methods with no return types came out at 524 lines. Those fields now read
473
+ `body: string | null`, `published: boolean`, `publishedAt: Date | null`, and that service's declaration is 44 lines.
474
+ A result, and a relation included in it, is shown as its fields rather than as `ProjectedFields<…>`. This covers
475
+ `framework.application` and `framework.client` results, the same fields in a write's `data`, and clients generated
476
+ by `avclient`. What each type accepts is unchanged.
477
+
478
+ ## 1.0.0-rc.7
479
+
480
+ 1.0.0-rc.5 and 1.0.0-rc.6 were tagged but never published; 1.0.0-rc.7 contains everything listed under them and the changes below.
481
+
482
+ ### Patch Changes
483
+
484
+ - f917c1c: A helper that reads `framework.contracts.core` compiles again in projects that emit declarations. In 1.0.0-rc.6 a
485
+ function returning a Resource or a field of the Core Contract without a return type, such as
486
+ `core.resources[resource]?.fields[relation]`, failed `nest build` (and `tsc` with `"declaration": true`, which Nest's
487
+ `tsconfig.json` sets) with `TS2883: The inferred type of 'relationOf' cannot be named without a reference to
488
+ 'AvCoreField'` under TypeScript 6 (`TS2742` under 5.9), or with `TS4058`/`TS4023` naming `AvCoreResource`.
489
+ `@aventara/core` now exports the three types the Core Contract is written with: `AvCoreResource` (a Resource),
490
+ `AvCoreField` (one of its fields) and `AvCoreRelationField` (a relation field, with the target fields its reference
491
+ names in `references`).
492
+
493
+ A policy's startup check states the path once: `CONFIG_INVALID_VALUE at policy.engine.governed.Nope: "Nope" is no
494
+ Resource of the Core Contract`, where rc.6 repeated `policy.engine.governed.Nope:` inside the message. Each
495
+ diagnostic's `message` no longer starts with its `path`; read the path from `path`.
496
+
497
+ ## 1.0.0-rc.6
498
+
499
+ 1.0.0-rc.5 was tagged but never published. 1.0.0-rc.6 contains everything listed under 1.0.0-rc.5 and the fix below.
500
+
501
+ ### Patch Changes
502
+
503
+ - 1cf72e0: Typed policy engines compile again in projects that emit declarations. In 1.0.0-rc.5 an engine written
504
+ `as const satisfies AvPolicyEngine` failed `nest build` (and `tsc` with `"declaration": true`, which Nest's
505
+ `tsconfig.json` sets) with `TS2883: The inferred type of 'policyEngine' cannot be named without a reference to
506
+ 'PolicyFieldsAccess'` under TypeScript 6, or `TS2742` under 5.9, and so did the configuration and the framework holding
507
+ it. `fieldsOf`'s question is now written out in full in `AvPolicyEngine`, so a declaration can spell it.
508
+
509
+ A read question's `action` is now typed `undefined`, so an engine can destructure it from either question:
510
+ `fieldsOf({ resource, access, action })`. A write question's `action` is `"create"` or `"update"`, as before.
511
+
512
+ ## 1.0.0-rc.5
513
+
514
+ ### Patch Changes
515
+
516
+ - 4795ff1: Two additions for policy engines. A Framework without a policy, and every Contract a caller is served, are unchanged.
517
+
518
+ - A policy engine can check a create whose row reaches another Resource through a relation. Discovery now states, on the end of a relation that holds the reference, which of the target's fields its reference fields name, pair by pair (`Note.campaign`: `referenceFields: ["campaignId"]`, `references: ["id"]`). An engine reads them from the model it is built from (a Prisma discovery artifact's `model`) or from `framework.contracts.core`, and asks one `exists` about the row they name: "a player creates a note only in a campaign they play in". Only the adapter's model and the Core Contract carry them. The Application, Client and Agent Contracts, `/_contract`, the MCP tools and every ClientContract hash are unchanged. The discovery artifact's model hash, and so a prebuilt Contracts file's fingerprint, change: regenerate the artifact and rebuild the prebuilt file.
519
+ - `fieldsOf({ access: "write" })` also names the action that writes the record, `action: "create" | "update"` (an upsert's branches each their own, a nested record its directive's), so an engine can lock a field on update and still let a create write it. A read question names none. An engine that ignores it keeps working.
520
+
521
+ - 9e178ca: Fixes for applications that check requests with a policy engine. A Framework without a policy behaves as before.
522
+
523
+ - A cursor on a row the caller cannot read is answered exactly as a cursor on a row that does not exist, at the root and in a to-many relation, whatever values the caller sends beside the identifier. Before, the page started at the hidden row, so it told that the row exists and where its values sort. The Prisma adapter reads the cursor's row under the read scope first: one statement more for a cursor on a readable row, and only that read for one on a row the caller cannot read.
524
+ - A unique update with a nested write (`$create`, `$connect`, …) on a row the caller can read but not change answers `A4002`, as the same update without one does. It answered `A2003`. A row the caller cannot read still answers `A2003`.
525
+ - The `exists` questions a policy asks select the Resource's primary identifier, never another unique field such as a governed `email`.
526
+ - `policy.principal` may answer with a promise. A synchronous principal works as before; a rejection answers `A3000`, as a throw does.
527
+ - `AvConstructionError.message` names the first problem and how many more there are, for example `Aventara framework configuration validation failed: CONFIG_INVALID_TYPE at adapter.execute: adapter.execute must be a function (+2 more)`. `stage` and `diagnostics` are unchanged.
528
+
529
+ ## 1.0.0-rc.4
530
+
531
+ ### Patch Changes
532
+
533
+ - e3d03a7: The error catalog says more about policies. `A2003` now names the cases a policy adds: a unique read of a row outside the
534
+ caller's read scope, and a single-row update or delete of a row the caller cannot read, are misses, while a row the
535
+ caller can read but not change answers `A4002`. `CONFIG_REQUIRED`, `CONFIG_UNKNOWN_PROPERTY` and `CONFIG_INVALID_VALUE`
536
+ name the `policy` key's rules: `policy.engine` and `policy.principal` are required, `policy` and `prebuilt` are root-only,
537
+ and the engine's `governed`, `paths` and `afterChecks` lists must name what the Core Contract has. Wording only; no
538
+ behaviour changes.
539
+ - d10639a: Faster reads. The read-only copies stages are told cost about half what they did: a read with a computed field
540
+ copies each row in one pass, a row with several computed fields shares its nested objects between the stages'
541
+ copies, and after hooks share one frozen copy of the result. A row whose computed field returns a value at once no
542
+ longer waits a turn per row. The MCP endpoint builds its JSON Schema validator once instead of on every request.
543
+ What stages are told, the order they run in and what a request answers are unchanged.
544
+ - f67e68c: A service method can return any façade node or variant without a return type. Under `declaration: true` (a Nest
545
+ build) the declaration file now writes a short reference, under half a kilobyte per method at any schema size, where it
546
+ wrote the whole Contract view (about 440 KB per method over 50 Resources). A method returning a variant
547
+ (`this.framework.application.Post.find.many`) no longer needs an annotation to compile, and one returning a transaction
548
+ variant (`this.framework.appTx.Post.create.one`) no longer runs the compiler out of memory.
549
+
550
+ New type names, exported from `@aventara/core` so a declaration can write them (you never need to write them yourself):
551
+
552
+ - `AvContractView`, the Contract view the façades are typed over;
553
+ - one call type per surface and shape: `AvApplicationProjectingCall`, `AvApplicationPlainCall`,
554
+ `AvClientProjectingCall`, `AvClientPlainCall`, `AvAppTxProjectingCall`, `AvAppTxPlainCall`,
555
+ `AvClientTxProjectingCall`, `AvClientTxPlainCall`.
556
+
557
+ A configuration with `fields` entries still writes those entries after each reference; annotate the method if that
558
+ matters (see the README's "Returning a façade from a method").
559
+
560
+ - 708556c: Policy engines check nested writes. A create, update or upsert whose data writes a relation through a directive
561
+ (`$create`, `$connect`, `$connectOrCreate`, `$update`, `$upsert`, `$delete`, `$disconnect`, `$set`) now runs under a
562
+ policy, where before it was refused. It runs as one adapter call inside the write's interactive transaction, and one
563
+ failed check rolls the whole write back with `403 A4002`.
564
+
565
+ - Every row the nested write creates is read back as stored (its parent's reference filled, database defaults
566
+ present) and asked `can({ action: "create", row })`, its `exists` lookups seeing the rows the same call wrote. A
567
+ create whose own data holds a nested write is asked about its row the same way, after the insert.
568
+ - A row a directive links or unlinks is held to the scope of the row that changes: a linked row that holds the
569
+ reference (a to-many relation's rows, the back end of a one-to-one, a many-to-many relation's rows) must be in its
570
+ update scope, one whose parent holds the reference (a to-one relation's target) in its read scope. One `exists`
571
+ per Resource answers it, inside the transaction. A linked row that changes is an update: after the call it gets
572
+ the after check (`can({ action: "update", row })`) and the move-out re-read. Linking a new row to a one-to-one's
573
+ back end unlinks the old one, which is held the same way.
574
+ - A to-many nested `$update` or `$delete` acts only on the rows within the update (or delete) scope, as
575
+ `update.many` and `delete.many` do: core reads those rows' identifiers inside the transaction and hands the
576
+ adapter `where: { id: { in: [...] } }`. A to-one one refuses the write when its row is outside the scope. A nested
577
+ `$update`'s changed rows get the after check and the move-out re-read after the call.
578
+ - The fields a nested record sends are held to its Resource's `fieldsOf({ access: "write" })`, and a relation written
579
+ through a directive to the parent's grant, its reference fields with it.
580
+ - Where the operation's `transactionsStyle` is `"none"`, a nested write under a policy is refused before it runs.
581
+
582
+ - 3a0dfca: A write the policy checks costs fewer database round trips. What each check decides and refuses is unchanged.
583
+
584
+ - A single-row update or delete carries the caller's scopes inside its own `where` and runs as one statement, with no
585
+ read of its row before it. One that matches nothing still answers `A4002` when the caller can read the row and
586
+ `A2003` when it cannot, with one lookup on that miss only. The Prisma adapter sends it as
587
+ `update({ where: { id, AND: [scope] } })`.
588
+ - A create asks `can({ action: "create", row })` and its `exists` lookups before the insert, without a transaction. A
589
+ transaction around them never closed the race between the lookup and the insert at the database's default
590
+ isolation, and cost a BEGIN and a COMMIT.
591
+ - A transaction opens only when a check after the write may roll it back: an update's after check or move-out, a
592
+ created row held to a write grant, a nested write, or returned rows checked by `exists`. A plain checked create or
593
+ delete is one statement, its interceptors and hooks outside any transaction.
594
+ - The after check asks `can` about the row the update returned, so it reads nothing again. Only a move-out reads the
595
+ changed rows again. An `update.count` runs as the returning `update.many` when the Contract offers it.
596
+
597
+ Round trips per request on PostgreSQL: `create.one` 3 → 1, `delete.unique` 4 → 1, `update.unique` 5 → 3,
598
+ `update.many` 4 → 3, `update.count` 5 → 3. Reads, and a Framework without a policy, are unchanged.
599
+
600
+ - 99169d2: Policy engines, reads first. `createFramework` takes an optional root `policy: { engine, principal }`: an engine that
601
+ answers three questions (`can`, `scopeOf`, `fieldsOf`, each now or as a promise), and a function that derives a
602
+ request's principal from its `ctx.$state`. Core never imports an engine; one satisfies `AvPolicyEngine` by its shape,
603
+ and a scope or grant is a fragment of Aventara's own `where` (`AvPolicyWhere`).
604
+
605
+ - Client and agent requests are checked (an MCP tool call is an agent request). An application call is checked only
606
+ when it names a principal: `framework.application.Note.find.many(args, { as: user })`. A call a stage makes through
607
+ `ctx` never is.
608
+ - Before any guard, `can` and the fields the request names or receives (`fieldsOf`); a refusal is `403 A4002`. At the
609
+ adapter call, after every developer stage, the read scope is ANDed into the root `where`, every to-many include and
610
+ its `$count`, and every relation filter, at every level. A to-one include of a row out of scope refuses the request;
611
+ it is never nulled.
612
+ - Governed fields (the engine's `governed` list) are left out of every default projection and carry `governed: true`
613
+ in the Contracts. Name one to get it: `select: ["$defaults", "email"]`, where `$defaults` is the level's default
614
+ projection. It is refused where a returned row does not grant it, and a filter or sort by it is checked before the
615
+ query runs, so it cannot reveal values the caller may not read.
616
+ - The engine's `governed` and `paths` lists are checked against the Core Contract at startup. A rule's paths are lists
617
+ of segments, as other paths in core are: `["Note", "campaign", "members", "some", "userId", "equals"]`.
618
+ - Writes are checked as well; see the policy writes entry.
619
+
620
+ Without `policy`, nothing changes: the Contracts and their hashes are the same bytes.
621
+
622
+ - 0fd2608: A write the policy checks costs less CPU after the round-trip changes. The operation core hands its adapter no longer
623
+ carries the request's policy session, so an adapter that keeps its operations no longer keeps each request's session
624
+ with them. The fields a write returns only for the after check are dropped as soon as the check has read them, so a
625
+ read compute stage is told the row the request asked for, not every scalar field. What each check decides, the
626
+ fields `can` is asked about, and the database round trips are unchanged.
627
+ - 154e440: Policy engines check writes. Every create, update, delete and upsert a client or agent makes (or an application call
628
+ made `{ as }` a principal) is now checked by the configuration's `policy`, where before it was refused.
629
+
630
+ - The fields a write sends are held to `fieldsOf({ access: "write" })` before any guard; a field outside it answers
631
+ `403 A4002`. A field writable on some rows only is checked against every row an update reaches, and against the
632
+ row a create inserts, after the insert and inside its transaction.
633
+ - A create asks `can({ action: "create", row })` about each new row on its final data. Its rules can look rows up
634
+ through `exists`, which runs inside the write's transaction, so a plan that creates a campaign and then its first
635
+ note sees the campaign.
636
+ - An update or delete acts only on rows the caller may both change (`scopeOf` for the action) and read. A single-row
637
+ one that matches nothing answers `A4002` when the caller can read the row, and `A2003` when it cannot, so the
638
+ answer does not reveal that the row exists. A `many` or `count` one answers for the caller's rows only.
639
+ - An update that moves a row out of what the caller reads is rolled back with `A4002`. So is one that fails an `after`
640
+ condition: inside the transaction core asks `can({ action: "update", row })` about each changed row of every
641
+ checked update. The engine's new `afterChecks` member (`{ Note: ["update"] }`) names the updates whose grants carry
642
+ such a condition, which are the ones refused where there is no interactive transaction.
643
+ - Where the operation's `transactionsStyle` is `"interactive"`, a checked write runs in a transaction of its own. Where
644
+ it is `"none"` (Cloudflare D1), a write that can only be checked after it runs is refused before it runs; every other
645
+ write runs, a create looking up before it inserts, and an unlisted update without the after check.
646
+ - Nested writes (a relation directive in a write's data) are refused under a policy for now.
647
+
648
+ `afterChecks` is checked against the Core Contract at startup and changes no Contract and no prebuilt fingerprint.
649
+
650
+ - 2fcffdb: Prebuilt Contracts. `createFramework` takes an optional `prebuilt` key: the four Contracts compiled ahead of time (type
651
+ `AvPrebuiltContracts`), so a serverless or edge cold start loads them instead of compiling them. A file is used only
652
+ when this core compiled it, for this protocol, from the same configuration and adapter model; its Contracts, hashes
653
+ and `/_contract` bytes are then the ones compiling would give. Any other file is ignored whole: the framework compiles
654
+ at startup exactly as without one and warns once (`AVENTARA_PREBUILT_STALE`), naming the Resources whose configuration
655
+ or model changed, or the version that differs. Without `prebuilt`, nothing changes. The build step that writes the
656
+ file arrives with `@aventara/build`.
657
+
658
+ ## 1.0.0-rc.3
659
+
660
+ ### Patch Changes
661
+
662
+ - b38034d: An issue inside one entry of a to-many relation directive's array names that entry's index:
663
+ `["arguments", "data", "posts", "$update", 1, "data", "category"]`, where it read `[…, "$update", "data", "category"]`.
664
+ This holds for `$create`, `$connect`, `$connectOrCreate`, `$update`, `$delete`, `$upsert`, `$set` and `$disconnect`,
665
+ as the runtime's own nested-write paths already did. A directive given one object, not an array, keeps its issue at the
666
+ directive.
667
+ - b38034d: An empty boolean node in the `where` of a write is refused, as an `undefined` there is, and nothing runs. In
668
+ `update.many`, `update.count`, `update.first`, `delete.many`, `delete.count`, `delete.first` and a to-many `$update`
669
+ or `$delete`, an empty `NOT: {}`, `AND: {}` or `[]`, `OR: []` or `AND`/`OR` entry `{}`, at any depth, answers
670
+ `422 A2004` with a `V1001` issue at the node:
671
+ `A boolean node must hold a condition here: an empty one matches every row, and the write would reach more rows.`
672
+ The ORM reads these as no condition, so `delete.count({ where: { NOT: {} } })` deleted every row, and `delete.first`
673
+ with one deleted an arbitrary row. A `where` that is `{}` itself still means every row, and reads pass empty nodes through as before. Field filters are unchanged: a scalar's `{}` and a
674
+ to-many relation's `{}` were already refused, and a to-one relation's `{}` matches the rows that have a related row.
675
+ - b38034d: The error catalog (`AvErrorCatalog`, `ERRORS.md`) catches up with the code: `A2004` says a value the database refused
676
+ may stand at the value itself where the adapter can place it (a bigint its driver cannot bind) and may be too long for
677
+ its index; `V1001` lists an `undefined` in a filter, selector or cursor and an empty boolean node in a bulk write's
678
+ `where`; `V1004` lists a value the database refused as too long or out of range, a bigint a driver cannot bind among
679
+ them.
680
+ - b38034d: A value write compute writes to a field the caller's layer hides is judged by that field's validators and Json shape
681
+ (the Core Contract's), and a value they refuse is the server's error: `500 A3000`, the issues to the `diagnostics` sink
682
+ on an `AvComputedValueError`, with nothing of the hidden field in the answer. Before, a shaped Json field hidden from
683
+ the layer was not judged at all, and a hidden field's own validators answered the caller `A2004` with an issue at the
684
+ hidden field's path. A layer that shows the field still answers `A2004` at it.
685
+ - b38034d: On PostgreSQL, a `@unique` value too long for its index (an index row past the B-tree's limit of about 2704 bytes, SQLSTATE
686
+ `54000`) is answered `422 A2004`, not `500 A3001`: one `V1004` issue at `["arguments"]`, as a value too long for its
687
+ column already was. The adapter reads the SQLSTATE, never the message. The issue's message for a value too long now
688
+ reads `The database refused this value: it is longer than the database can hold for its column.`
689
+ (it said `longer than its column can hold`, which an index refusal is not).
690
+ - b38034d: A Pick layer's list entry that names what its parent hid is refused with the sentence written inline too. Inline in
691
+ `createFramework` or `AventaraModule.forRoot`, the error is at the key and reads:
692
+
693
+ ```text
694
+ Type '["select"]' is not assignable to type '…'.
695
+ …
696
+ Property '"Error: client cannot expose 'Post.internalNote': hidden by root"' is missing in type '["select"]' but required in type '{ readonly "Error: client cannot expose 'Post.internalNote': hidden by root": true; }'.
697
+ ```
698
+
699
+ where it ended at `Type 'string' is not assignable to type 'never'.` at the list's element. A list entry is now typed as
700
+ an object keyed by the sentence, which no list has, so a configuration that is not inline (an `aventaraConfig()` handed
701
+ to `AventaraModule.forRootAsync`) ends at the same `Property '"Error: …"' is missing` line, where it ended at
702
+ `Type '"select"' is not assignable to type '"Error: …"'`. An entry written `true` or as an object is unchanged.
703
+
704
+ ## 1.0.0-rc.2
705
+
706
+ ### Patch Changes
707
+
708
+ - A pipe may move a transaction step's `$ref`. A pipe sees a `$ref` as the reference it is, unresolved, and a
709
+ scoping pipe moves it: `({ args }) => ({ ...args, where: { AND: [args.where ?? {}, { published: true }] } })` puts
710
+ the caller's `where: { categoryId: cat.$ref("id") }` at `where.AND.0.categoryId`. The reference is now resolved
711
+ wherever the pipe put it: in an `AND`, an `OR` or a `NOT`, in a relation filter, under any operator, or copied from a
712
+ data value into another field or into a `$connect` key. Before, only a reference still standing where the caller
713
+ wrote it was resolved, and the step failed inside the transaction with `500 A3004` ("A server pipeline produced
714
+ invalid arguments."), the `diagnostics` sink naming the moved `$ref` (`V1006: Filter operator "$ref" is not
715
+ available on field "categoryId"`, or `V1001` under `gte`). A moved reference is held to the rules a reference the
716
+ caller writes at that place is held to (where a `$ref` may stand, its source step, and its source field's type
717
+ against its new place): one that breaks them, such as a `$ref` moved into an `orderBy` or onto a field of another
718
+ type, is still the server's `A3004`, and an operation pipe's is now answered before the transaction opens. A
719
+ transaction pipe that moves a `$ref` is held to the same rules at its step. A literal a pipe writes where the caller
720
+ had a `$ref` now goes through that field's pipes, as any other value does.
721
+ - A relation the request writes together with its reference field (`{ authorId: 1, author: { $connect: { id: 1 } } }`)
722
+ is refused by the framework validation, before any guard, pipe or compute stage runs and, in a plan, before the
723
+ transaction opens: `A2004`, `V1012` at the relation, as before. In rc.1 it was judged only after the guards, pipes
724
+ and write compute, so the developer's stages ran on the request first, and a plan opened its transaction and ran the
725
+ steps before it.
726
+ - The field validators run after write compute. The order of a call is now the framework validation, the guards, the
727
+ pipes and field pipes, write compute, then the re-check: Aventara's own checks again on what the pipes and compute
728
+ produced, then the field validators (a Json field's shape among them) on every value the adapter will be handed,
729
+ then the interceptors and hooks. So a validator judges what is stored: a value a `compute.create` or
730
+ `compute.update` stage replaces is judged as computed, not as the caller sent it. In rc.1 the validators ran after
731
+ the pipes and before write compute, and a computed value was not judged by them. A plan step and a forced call still
732
+ judge before the transaction opens the literal values no write compute stage of their phase changes, so a caller's
733
+ refusal there opens nothing; the rest is judged at the step, and a refusal rolls the transaction back.
734
+ - A computed write value its field's validators or Json shape refuse is answered `A2004` at the field, as any validator
735
+ refusal is (`{ code: "V1003", path: ["arguments", "data", "slug"], check: "string_format", … }`), at the top level,
736
+ in nested writes and in both branches of an upsert. In rc.1 such a value was not judged at all. A computed value of
737
+ the wrong type is still the server's error: `A3000`, its issues to the `diagnostics` sink on an
738
+ `AvComputedValueError`. `compute.read` values are output and are not judged.
739
+ - A field computed on read with no `dependsOn` (the function form, `read: () => "stamped"`) has the Resource's
740
+ identifier read for it, the adapter's first one (with Prisma, the primary key when the model declares it first), so
741
+ each row comes back whatever else is selected; a `dependsOn` field is read as before. The answer holds exactly what
742
+ was selected: `{ select: ["stamp"] }` answers `[{ stamp: "stamped" }]` on every reading variant and in a write's
743
+ `select`, and inside a relation projection (`{ select: [{ category: { select: ["stamp"] } }] }`) the relation's row
744
+ is read and computed. In rc.1 a select of only such fields handed the adapter an empty projection, which Prisma
745
+ cannot express: `500 A3001` at the top level, and inside a relation the row was not read (`500 A3000`).
746
+ - Every stage told a frozen view gets its own copy of a `Date` or a `Uint8Array`, which freezing cannot reach: a guard,
747
+ a field write guard, a pipe (its input and its `ctx.$args`), a field pipe, write compute (`data`, `value`,
748
+ `ctx.$args`), an interceptor, a before hook, each after hook (the result and `ctx.$args`), a filter and a Resource
749
+ transaction stage. Changing one in place changes only that stage's copy, never what a later stage is told, what is
750
+ written or what the caller receives; data changes only by returning it. In rc.1 every stage after write compute
751
+ shared one copy, so an after hook was told the `Date` a before hook had changed in place, and a guard or a pipe was
752
+ told the framework's own value. Arguments holding no such value are handed on as they are, at no cost per stage; a
753
+ copy is made only along the path to one (about 3 µs per stage for a record with a `Date` and a 64-byte
754
+ `Uint8Array`).
755
+ - A `compute.read` stage is told the row as its own deep-frozen copy, a `Date` or a `Uint8Array` in it copied, like
756
+ every stage above; its field's `value` too. It returns its field's value: writing into `record` throws a
757
+ `TypeError`, answered `A3000` when the stage lets it through, as a pipe's write into its arguments is. The answer is
758
+ built from the row as read. In rc.1 the stage was told a mutable copy of the row and the answer was built from it,
759
+ so `record.title = "x"` changed the title every surface answered. The copy costs about 1.3 µs per row and stage
760
+ (1.8 µs with a `Date` and 64 bytes): a 100-row read with one computed field took 0.33 ms instead of 0.19 ms.
761
+ - A record written through a relation cannot write that relation back. Inside a post created in `author.posts`,
762
+ `author` and `authorId` are what the write the post sits in supplies; inside a category created in a post's
763
+ `category`, `posts` is (`{ posts: { $create: { category: { $create: { posts: { $create: … } } } } } }`). The
764
+ framework validation refuses such a write before any guard, pipe or adapter work: `A2004` with one `V1012` issue at
765
+ the field (`["arguments", "data", "posts", "$create", "category", "$create", "posts"]`), message `Relation "posts"
766
+ is the relation this Category is written through, from its other end ("Post.category"): the write it sits in
767
+ supplies it.`, under every directive that carries a record (`$create`, `$connectOrCreate`, `$update`, `$upsert`),
768
+ to-one and to-many, and in a plan step. Only the edge walked is refused: a self-relation's other edge to the same
769
+ Resource stays writable. It is a type error on the façades, the builders and the generated client. In rc.1 the
770
+ Contract admitted these writes and the Prisma adapter answered `500 A3001`.
771
+ - The Contract states each relation's other end, `inverse` on a relation field (`User.posts` has `inverse: "author"`),
772
+ as the adapter pairs them, and only where the layer shows that other end. The write axis has a third position,
773
+ `"loopback"`: that other end inside a record written through the relation. An adapter states whether a relation is
774
+ writable there as it states the other two positions (an arm that lists `"loopback"`, or an unqualified arm). A
775
+ Contract whose adapter states a pairing has a new hash; one that states none is unchanged, and so is an arm that
776
+ lists every position. `AvAdapterRelationField.inverse` is how an adapter states the pairing.
777
+ - The Contract states which scalar fields hold each relation's reference: `referenceFields` on a relation field
778
+ (`Post.category` has `referenceFields: ["categoryId"]`; a composite reference lists every field, in the order the
779
+ data source pairs them with the target's key), on an optional relation as on a required one. It is absent on the
780
+ end that holds no reference (`Category.posts`), never an empty list. A layer keeps the fields it shows, in the
781
+ adapter's order, and leaves the property out when it shows none. The argument types now leave a loopback edge's
782
+ reference fields out for an optional relation too: `categoryId` in a post created in `Category.posts` is a type
783
+ error on the façades, the builders and the generated client, as the framework validation refuses it (`V1012`). In
784
+ rc.1 only a required relation's reference fields were left out, read off `createRequirements`.
785
+ `AvAdapterRelationField.referenceFields` is how an adapter states them. A Contract whose adapter states them has a
786
+ new hash.
787
+ - A computed value is held to every named `format` its field declares, not only `uuid`: a `compute.read`,
788
+ `compute.create` or `compute.update` value that breaks `email`, `url`, `ipv4` or any other of zod's named formats
789
+ is the server's error, `A3000`, its `V1003` issue to the `diagnostics` sink on an `AvComputedValueError`, as a value
790
+ of the wrong type is. Each entry of a list field is judged. In rc.1 only `uuid` was checked and any other format
791
+ reached the caller unchecked. A relative path is no URL: compute an absolute one into a `format: "url"` field
792
+ (`` `https://example.com/p/${record.slug}` ``), or leave `format` out. A caller's own value is still held only to
793
+ `uuid` (a format describes the value; a rule on caller input is a validator, `AvZ.url()`).
794
+ - `AvErrorCatalog` (and `ERRORS.md`): `A2004` and `V1012` list a record written through a relation that writes that
795
+ relation, or a field holding its reference, back. An adapter that meets one core cannot see (the layer hides the
796
+ relation's other end, so its Contract states no pairing) answers it with the new `V1012` sentence `The data source
797
+ refused this nested write: a record written through a relation cannot write that relation or its reference fields
798
+ back.`, which the response boundary keeps as it keeps a database refusal's.
799
+ - A nested `$update` on a to-many relation is a bulk write: its one `data` applies to every related row its `where`
800
+ matches, so it takes what `update.many`'s `data` takes. A relation the adapter does not offer in a bulk write is
801
+ refused before the adapter with `A2004` and `V1006` at the member
802
+ (`["arguments", "data", "posts", "$update", "data", "category"]`, `Relation "category" is not writable during
803
+ update.`), and is a type error on the façades, the builders and the generated client. A to-one `$update` is
804
+ unchanged. In rc.1 the Contract admitted it and the Prisma adapter refused it as `500 A3001`.
805
+ - `AvErrorCatalog` (and `ERRORS.md`): `A3002` lists a transaction that expired or was closed under a step among its
806
+ causes, and `V1006` a relation write in a to-many `$update`'s `data`.
807
+ - A relation a pipe or a compute stage writes together with its reference field is the server's error: the caller
808
+ gets `A3004` with the generic pipe-output message, and the `diagnostics` sink gets an `AvPipeOutputError` holding the
809
+ `V1012` issue and its path. In rc.1 the caller got `A2004`/`V1012`, as if it had sent both. A pipe's output that
810
+ breaks a field validator or a Json field's shape is still the caller's `A2004`: those are the developer's rules for
811
+ what may be stored, not Aventara's.
812
+ - In a transaction plan, a `$ref` holding no object (`{ payload: { $ref: "x" } }`, `{ $ref: null }`) is answered as a
813
+ single call answers it: `A2004` with `V1006` at the `$ref` key (`Mutation directive "$ref" is not available on field
814
+ "payload".`), at `["operations", i, "args", …, "$ref"]`. In rc.1 a plan read it as a malformed reference:
815
+ `A2007` with `V1016` at `…, "$ref", "operation"`. A `$ref` holding an object is still a reference, and a broken one
816
+ still `A2007`.
817
+ - `AvJsonValue` admits a key holding `undefined`, so an object with optional properties
818
+ (`{ readonly note?: string }`) is assignable to a `json` field; the key is left out at runtime. In rc.1 the type
819
+ refused it. An array element holding `undefined` is still a type error (at runtime it is `null`).
820
+ - `AvErrorCatalog` (and `ERRORS.md`): `V1001` lists two directives in one scalar action object among its causes,
821
+ `A2004` a computed value the validators refuse, `A3000` a computed value of the wrong type, and `A3004` a reference
822
+ a pipe or write compute wrote together with its relation.
823
+ - A scalar action object holds one directive. `{ score: { $increment: 1, $decrement: 2 } }` is refused before the
824
+ adapter with `A2004` and `V1001` at the field (`Scalar mutation action objects may contain only one directive.`),
825
+ and is a type error on the façades, the builders and the generated client. In rc.1 it passed validation and the
826
+ ORM refused it: `500 A3001`. A directive the field does not offer is still `V1006` at the directive.
827
+ - An `undefined` inside a `json` value is what JSON makes of it, on every surface: a key holding it is left out and an
828
+ array element holding it (or a hole) is `null`, as `JSON.stringify` writes them, so
829
+ `{ meta: { a: undefined, b: [undefined] } }` stores `{"b":[null]}` through `framework.application`,
830
+ `framework.client`, `framework.execute`, the ctx executor and a plan step, as it does through the generated client
831
+ and over HTTP. The same holds in a `json` filter operand, and an operation's fingerprint is computed from the value
832
+ as JSON carries it. In rc.1 the in-process surfaces refused the key with `A2004`/`V1001`, and a hole in an array
833
+ inside a `json` value was dropped, moving the elements after it down one index.
834
+ - `DATABASE_REFUSALS` has two more sentences an adapter answers a refused value with, both `V1004`:
835
+ `The database refused this value: it divides by zero.` and `The database refused this value: the write computes no
836
+ value for a column that requires one, as a division by zero does.`
837
+ - `AvErrorCatalog`'s `A2004` entry (and `ERRORS.md`) covers a value the database refused: an adapter answers it with
838
+ one issue at `["arguments"]`, `V1004` for a length or range, `V1001` otherwise, and the issue's message says what
839
+ the database refused (`The database refused this value: its text cannot contain the NUL character (U+0000).`).
840
+ The response boundary keeps such a message only when it is core's own sentence for that refusal under its own
841
+ code; every other adapter issue message is still replaced by the code's published text.
842
+ - An `appTx` or `clientTx` builder no longer runs a getter inside an object carrying `$ref` when it copies a step's
843
+ arguments: it mirrors the object as `framework.executeTransaction` does, and the run refuses it the same way
844
+ (`A2004`, `V1001` at the extra key). In rc.1 the builder ran the getter at the call.
845
+ - `AvProtocol.bind(framework).handleOperation` copies a `{ kind: "parsed" }` body at the call, before it awaits the
846
+ state seed, so a host that changes its parsed object after the call changes nothing, and a body that cannot be
847
+ copied is refused at the call (`A2004`, `V1001` at its path). In rc.1 the copy was taken after the first await.
848
+ - `AvProtocol.bind(framework).handleTransaction` takes a `{ kind: "parsed" }` plan at the call, before it awaits the
849
+ state seed, as `framework.executeTransaction` takes one: the plan's structure is mirrored by its property
850
+ descriptors, so no getter the plan validator refuses runs, and each step's arguments are copied, its `$ref` control
851
+ objects mirrored. A host that changes the plan after the call changes nothing, and a step whose arguments cannot be
852
+ copied is answered at its turn (`A2004`, `V1001` at its path). In rc.1 the plan was read after the first await, so a
853
+ step changed after the call failed its fingerprint (`A2007`, `V1017`) or ran as changed.
854
+ - `framework.appTx.$sql` mirrors a `$ref` control object among its values as the builders mirror one in a step's
855
+ arguments: no getter inside it runs, and a malformed one is refused as `framework.executeTransaction` refuses it
856
+ (`A2004`, `V1001` at its extra key). A well-formed hand-written `{ $ref: { operation, fingerprint, path } }` is read
857
+ as a reference to that step's field, held to the same checks as one in an operation step. In rc.1 the value was
858
+ copied by value at the call, which ran its getters, and bound as JSON text.
859
+ - An `orderBy` value that is no order says what is wrong with it. A `$ref` there is refused with `A transaction
860
+ reference cannot stand in orderBy: order "email" by "asc", "desc" or { sort, nulls }.`, and a malformed null-order
861
+ object with `Null ordering for "email" must be exactly { sort: "asc" | "desc", nulls: "first" | "last" }.`. The
862
+ code (`V1001`) and path are unchanged; rc.1 answered both with `Extended null ordering for "email" must contain sort
863
+ and nulls.`
864
+ - Each filter operator object stands alone: a `mode` or `path` qualifies only the operators written beside it, and an
865
+ object under `not` has its own. A `mode` or `path` with no comparing operator beside it is refused with `A2004` and
866
+ `V1001` at that key, before the adapter, with the message `mode on field "title" qualifies no operator: write it next
867
+ to the operator it applies to (inside "not" to apply to a negated one).`. That covers `{ mode: "insensitive", not: {
868
+ contains: "x" } }` (write `{ not: { contains: "x", mode: "insensitive" } }`), `{ path: ["label"], not: { … } }`
869
+ (write the `path` inside the `not`), and a `mode` or `path` alone, such as `{ title: { mode: "default" } }`, which
870
+ reached the adapter as no condition and matched every row. A value under `not` (`{ path: ["label"], not: "x" }`)
871
+ compares at its own level and is accepted. The typed calls refuse the same objects at compile time.
872
+ - An error catalog: `AvErrorCatalog`, exported from `@aventara/core`, maps every outcome code (`A1000` to `A4002`),
873
+ validation code (`V1000` to `V1021`) and startup code (`CONFIG_…`, `DISCOVERY_…`, `COMPILER_…`) to its `kind`,
874
+ `message`, `cause`, `fix` and `docs` URL, the code's entry on the error-codes page
875
+ (`https://aventara-framework.vercel.app/docs/error-codes#a2004`: the code in lower case). The package also ships the
876
+ catalog as `ERRORS.md`, one table per kind. New names: `AvErrorCatalog` (a value and its type),
877
+ `AvErrorCatalogEntry`, `AvErrorCatalogCode`, `AvErrorKind`.
878
+ - A startup diagnostic links to its documentation: every entry of `AvConstructionError`'s `diagnostics` is now
879
+ `{ code, path, message, docs }`, where `docs` is `AvErrorCatalog[code].docs`. Codes, paths and messages are
880
+ unchanged. A test that compares a whole diagnostic with `toEqual` now sees the `docs` key.
881
+ - A spread of the arguments compiles on a Resource with a `json` field. A variant pipe returning
882
+ `{ ...args, data: { ...args.data, slug } }`, or a guard spreading `ctx.$args.data`, was TS2589 ("Type instantiation
883
+ is excessively deep and possibly infinite"), inline and in `defineResource`: the deep read-only typing re-entered
884
+ `AvJsonValue` through its array member without end. `AvDeepReadonly` now maps an array through its own
885
+ `readonly …[]` branch (a tuple keeps its positions); the types a stage is told are unchanged, and a wrong value in a
886
+ pipe's return is still a compile error.
887
+ - An explicit `undefined` in write data means the key was not sent, as Prisma reads its data. In a create's or
888
+ update's `data`, an upsert's `create` and `update`, each record of a bulk create and every nested create or update,
889
+ `{ name: undefined }` is now `{}`: on a create an optional field takes what leaving it out gives it and a required one
890
+ is missing (`A2004` with `V1000` at its path); an update leaves the field untouched. Before, it was refused as
891
+ `A2004`/`V1001` "Value must be a string.". The same holds for the in-process façades, ctx calls, `appTx` plans and
892
+ the arguments a pipe or a transaction pipe returns: an optional field a pipe sets to `undefined` is omitted, a
893
+ required one is a dropped field (`A3004`). Filters and unique selectors are unchanged: `where: { id: undefined }` is
894
+ still refused (`V1001`), so an `update.many` or `delete.many` never widens to every row. The refusal says why, in the
895
+ generated client's words where they apply in process: `Value must not be undefined: it would be left out, and the
896
+ request would reach more rows.` (it said what the value is not, such as `Value must be a string.`). This holds at
897
+ any depth of a filter, a unique selector or a cursor: an operator's operand, an `in` entry, an `AND` entry, a `NOT`,
898
+ a relation filter, a relation's `where` under `select` or `include`, and a nested write's `$connect`, `$disconnect`,
899
+ `$set` and `$update` selectors. Code and path are unchanged.
900
+ - An `undefined` `mode`, `isEmpty` or `path` in a filter is refused (`A2004` with `V1001` at the operand), as every
901
+ other operator's `undefined` already was. These three are passed to the adapter as given, so
902
+ `{ tags: { isEmpty: undefined } }` reached it as no condition and matched every row.
903
+ - A filter operand of the wrong type is refused (`A2004` with `V1001` at the operand) before the adapter is called:
904
+ `mode` takes `"default"`, `"sensitive"` or `"insensitive"`, `isEmpty` a boolean, `path` an array of strings (a wrong
905
+ entry is named at its index) and a `json` field's `stringContains`, `stringStartsWith` and `stringEndsWith` a string.
906
+ Before, a value such as `mode: "loud"`, `isEmpty: 3`, `path: "a.b"` or `stringContains: 3` from an HTTP or MCP caller
907
+ reached the adapter, and the ORM refused it as `A3001`. The typed calls and the generated client type these operands
908
+ the same way: `mode`, `isEmpty` and `path` were `unknown`, and a `json` `string*` operand accepted any non-null JSON
909
+ value.
910
+ - Filter modes are advertised per field. `mode` has three values: `"default"` is the database's own comparison and
911
+ every field that offers `mode` takes it; `"sensitive"` and `"insensitive"` are an explicit promise, taken only where
912
+ the field's new `capabilities.filterModes` lists them (and, on a `json` field that offers `path`,
913
+ `capabilities.pathFilterModes` when the filter names a `path`). The Contract and the ClientContract carry both lists,
914
+ configuration never names them, and a layer that hides `mode` or `path` drops them. A mode the field does not offer is
915
+ refused like an unadvertised operator: `A2004` with `V1006` at the `mode`, `Filter mode "insensitive" is not available
916
+ on field "email".`; the typed calls offer only the field's modes, and on a `json` field the list that applies: an
917
+ operator object with `path` takes `pathFilterModes`, one without it `filterModes`. On Postgres
918
+ `where: { meta: { stringContains: "x", mode: "insensitive" } }` is a compile error (`Property 'path' is missing`),
919
+ and the same filter with `path: ["label"]` compiles. Contract hashes change for every field that offers `mode`:
920
+ regenerate the client.
921
+ - A `where`, `limit`, `offset` or `cursor` argument set to `undefined` is refused with a message that says what to
922
+ write: `where must not be undefined: leave the key out to mean no filter.` (and the same for `limit`, `offset` and
923
+ `cursor`), at the top level and in a relation under `select` or `include`. The code and path are unchanged
924
+ (`A2004` with `V1001` at the key; `V1009` for `cursor`). A wrong value keeps its message, such as
925
+ `where must be an object.` or `limit must be a non-negative integer.`.
926
+ - 9366e16: MCP endpoint polish:
927
+
928
+ - A request with no bearer credentials (no `Authorization` header, or another scheme such as `Basic`) is answered
929
+ `401` with `WWW-Authenticate: Bearer resource_metadata="…"` and no error code, as RFC 6750 §3.1 asks; its body no
930
+ longer says "Missing Authorization header". A bad bearer token keeps `error="invalid_token"`.
931
+ - A `mcp.authorization.verify` that throws is still answered `401`, and is now reported to the `diagnostics` sink as
932
+ an `AvMcpDiagnostic` holding the error.
933
+ - With `mcp` configured and `@aventara/mcp` missing, the startup error names the command that installs it at the
934
+ installed `@aventara/core`'s exact version: `npm install --save-exact @aventara/mcp@<version>`.
935
+
936
+ - 9366e16: A variant's guards, pipes and filters may leave out of a create exactly the fields your configuration's
937
+ `compute.create` stages fill. Write compute runs after those stages, so a field it fills may still be missing when
938
+ they run, and a pipe may return a create without it: in a pipe, `args.data.slug` is `string | undefined` when
939
+ `slug` has a `compute.create`, and every other required field stays required. A stage's type cannot read the
940
+ configuration it is written in, so the adapter's generate step reads the configuration's type (`aventara:prepare`
941
+ passes `--config src/aventara.config.ts`) and writes which fields each layer computes into the model's type. A
942
+ stage counts the layers whose compute runs for its requests: a root stage the root's, the application's, the
943
+ client's and the agent's; an `application` or `client` stage the root's and its own (and the agent's, when the agent
944
+ extends it); an `agent` stage the root's, its own and its parent's. This holds inline in `createFramework`, in
945
+ `AventaraModule`'s `config`, and in `defineResource` blocks and their overlays, for a create's `data`, an upsert's
946
+ `create` and a nested create. Values are still typed. Hooks and interceptors run after compute and keep every
947
+ requirement. A model generated without a configuration lifts every create requirement in those stages, as before.
948
+ - Breaking: a create missing a required field is refused before any pipeline stage runs. The framework's own
949
+ validation (types, unknown fields, structure) now also checks that every create position holds the fields its
950
+ layer requires (`A2004`/`V1000` at the field), before the guards, where it ran after the pipes and compute. A field a
951
+ `compute.create` stage fills is not required there and stays optional until compute. So a guard or a pipe is always
952
+ told a create that holds every other required field, which is what their types say, and a pipe can no longer fill a
953
+ required field the caller left out: give that field a `compute.create` stage or a database default. This holds for
954
+ a create's `data`, every bulk record, an upsert's `create` branch and nested creates, and for each step of a
955
+ transaction before it opens (a `$ref` counts as a value). Which fields are required is already public in the client
956
+ contract, so the earlier answer reveals nothing new.
957
+ - A required create field the caller sent and a pipe then dropped is now the server's error: the caller gets `A3004`
958
+ with the generic pipe-output message, and the `diagnostics` sink gets an `AvPipeOutputError` holding the `V1000`
959
+ issue. Until now the caller got `A2004`/`V1000`, as if it had left the field out.
960
+ - New: `AvConfigComputedFields`, the shape of that statement: per layer (`root`, `application`, `client`, `agent`),
961
+ per Resource, the fields with a `compute.create` and a `compute.update` stage, and the layer the agent extends. The
962
+ adapter hands it to the framework as `AvAdapter.computedFields`, and the framework compares it with the
963
+ configuration it starts with. When they differ (you changed a compute stage and did not run `aventara:prepare`),
964
+ startup emits one warning, `AVENTARA_STALE_GENERATED_TYPES`, naming each difference:
965
+
966
+ ```text
967
+ (node:1234) [AVENTARA_STALE_GENERATED_TYPES] AventaraWarning: generated types are stale: run aventara:prepare. The computed fields the pre-compute stages are typed with differ from the configuration's:
968
+ - computed in the configuration, not in the types: root User.handle (update)
969
+ ```
970
+
971
+ It is a warning and changes nothing at runtime: the statement only types the stages.
972
+
973
+ - A `compute.create` stage that returns `undefined` for a field a create cannot do without (not nullable, no default,
974
+ not generated) and that the caller did not send now fails as the server's error: the caller gets `A3000`, and the
975
+ `diagnostics` sink gets an `AvComputedValueError` whose message is
976
+ `compute.create on <Resource>.<field> returned undefined for a required field`. The field left the create
977
+ requirements because the stage fills it; until now the create reached the database without it, and the
978
+ database's refusal answered `A3001`. This holds for a create's `data`, every record of a bulk create, an upsert's `create`
979
+ branch and a nested create. A reference field counts as missing only when the record writes neither its relation nor
980
+ every reference field, and a nested create's field the parent supplies is never missing. Updates are not checked:
981
+ nothing is required of an update.
982
+ - 9366e16: A Pick layer (`exposed: false`) that names what its parent hid now says why in the type error. A Resource, field,
983
+ family, variant or capability the root (or, for the agent, the layer it extends) hid is typed as
984
+ `readonly ["Error: client cannot expose 'Post.internalNote': hidden by root"]`, so the error TypeScript reports through
985
+ the scaffold's `aventaraConfig()` and `AventaraModule.forRootAsync` ends at:
986
+
987
+ ```text
988
+ The types of 'client.exemptions.resources.Post.fields.internalNote' are incompatible between these types.
989
+ Type 'readonly ["select"]' is not assignable to type 'readonly ["Error: client cannot expose 'Post.internalNote': hidden by root"]'.
990
+ Type '"select"' is not assignable to type '"Error: client cannot expose 'Post.internalNote': hidden by root"'.
991
+ ```
992
+
993
+ where it ended at `Type 'readonly ["select"]' is not assignable to type 'never'.` An entry written `true` names it
994
+ the same way (`Type 'boolean' is not assignable to type 'readonly ["Error: client cannot expose 'Comment': hidden by
995
+ root"]'.`), where it ended at `Type 'true' is not assignable to type 'never'.`. Written inline in `createFramework`
996
+ or `AventaraModule.forRoot`, the error at a `true` entry starts with the sentence:
997
+ `Type 'true' is not assignable to type 'true & (readonly ["Error: client cannot expose 'Comment': hidden by root"] & …)'`.
998
+ An inline literal's list still reads `not assignable to type 'never'` at the key.
999
+
3
1000
  ## 1.0.0-rc.1
4
1001
 
5
1002
  ### Patch Changes
@@ -445,7 +1442,6 @@
445
1442
  nullable: false,
446
1443
  list: false,
447
1444
  lifecycle: ["VIRTUAL"],
448
- format: "url",
449
1445
  },
450
1446
  pipelines: {
451
1447
  compute: {
@@ -943,15 +1939,15 @@
943
1939
  does: they resolve the data and throw every failure as the `AvError` subclass of its code's class. The subclasses
944
1940
  are new exports of `@aventara/core`, chosen by one code→class table the generated client reads too:
945
1941
 
946
- | Class | Codes |
947
- | ------------------------- | ------------------------------------------- |
948
- | `AvProtocolError` | A2000, A2001, A2002, A2006, A2010–A2012 |
949
- | `AvNotFoundError` | A2003 |
950
- | `AvValidationError` | A2004, A2007, A2009 |
951
- | `AvContractMismatchError` | A2005 |
952
- | `AvConflictError` | A2008, A2013, A2014 |
953
- | `AvInternalError` | A3000–A3004 |
954
- | `AvAuthError` | A4000–A4002 |
1942
+ | Class | Codes |
1943
+ | ------------------------- | --------------------------------------- |
1944
+ | `AvProtocolError` | A2000, A2001, A2002, A2006, A2010–A2012 |
1945
+ | `AvNotFoundError` | A2003 |
1946
+ | `AvValidationError` | A2004, A2007, A2009 |
1947
+ | `AvContractMismatchError` | A2005 |
1948
+ | `AvConflictError` | A2008, A2013, A2014 |
1949
+ | `AvInternalError` | A3000–A3004 |
1950
+ | `AvAuthError` | A4000–A4002 |
955
1951
 
956
1952
  `instanceof` works, and `error.code` and `error.cause` are what the envelope carried (a transaction's
957
1953
  `cause.operation` names the failing step). A stage's ctx calls throw the same subclasses. `framework.execute`,
@@ -959,7 +1955,10 @@
959
1955
 
960
1956
  ```ts
961
1957
  // Before
962
- const res = await framework.application.Post.find.unique({ where: { id }, select: ["id", "title"] });
1958
+ const res = await framework.application.Post.find.unique({
1959
+ where: { id },
1960
+ select: ["id", "title"],
1961
+ });
963
1962
  if (res.code !== "A1000") return null;
964
1963
  return res.data;
965
1964
  const result = await framework.transaction([user, post]);
@@ -967,7 +1966,10 @@
967
1966
 
968
1967
  // After
969
1968
  try {
970
- return await framework.application.Post.find.unique({ where: { id }, select: ["id", "title"] });
1969
+ return await framework.application.Post.find.unique({
1970
+ where: { id },
1971
+ select: ["id", "title"],
1972
+ });
971
1973
  } catch (error) {
972
1974
  if (error instanceof AvNotFoundError) return null;
973
1975
  throw error;
@@ -978,7 +1980,7 @@
978
1980
  The façades' result types follow: a call resolves the operation's slot (`T`, or `T | null` for a `first`), and
979
1981
  `framework.transaction` resolves its results tuple. `AvOperationCall` loses its `Settlement` parameter (every direct
980
1982
  call settles to data), and `AvError` takes its code as a type parameter (`AvError<"A2003">`); `new AvError(code,
981
- cause)` is unchanged.
1983
+ cause)` is unchanged.
982
1984
 
983
1985
  New: a stage registered at a variant (`resources.<R>.operations.<family>.<variant>.pipelines`) gets its operation's
984
1986
  arguments typed. `ctx.$args` is that operation's arguments, deep read-only, so a write is a type error and the editor
@@ -1017,8 +2019,12 @@
1017
2019
  relation neither way or both ways:
1018
2020
 
1019
2021
  ```ts
1020
- await framework.application.Post.create.one({ data: { title: "Hi", authorId } }); // ok
1021
- await framework.application.Post.create.one({ data: { title: "Hi", author: { $connect: { id } } } }); // ok
2022
+ await framework.application.Post.create.one({
2023
+ data: { title: "Hi", authorId },
2024
+ }); // ok
2025
+ await framework.application.Post.create.one({
2026
+ data: { title: "Hi", author: { $connect: { id } } },
2027
+ }); // ok
1022
2028
  await framework.application.Post.create.one({ data: { title: "Hi" } }); // type error: `author` or `authorId`
1023
2029
  await framework.application.Post.create.one({ data: { authorId } }); // type error: `title`
1024
2030
  ```
@@ -1340,7 +2346,7 @@
1340
2346
  `framework.transaction`, `framework.executeTransaction` and `POST /_transactions` alike. A single call is unchanged
1341
2347
  (`["arguments", …]`). If your code reads `issue.path` from a transaction's answer, drop the `"operations", i, "args"`
1342
2348
  prefix to get the path inside that step's arguments. `@aventara/testing`'s protocol corpus row "a client-hidden
1343
- field — /_transactions" and `fixtures/protocol-v1.json` carry the new path.
2349
+ field — /\_transactions" and `fixtures/protocol-v1.json` carry the new path.
1344
2350
  - d43d1cc: **Types:** `diagnostic.deliberate` now type-checks on any `FrameworkDiagnostic`, without checking
1345
2351
  `diagnostic.kind` first, so a `diagnostics` sink can log it for every report. It is `true` only on an `"operation"`
1346
2352
  diagnostic for a `FrameworkError` you threw on purpose with an `A3xxx` code, and always absent on a `"transaction"`