@aventara/prisma7-adapter 0.1.0-pilot.0 → 0.1.0-pilot.1

package/README.md

@@ -210,15 +210,13 @@ plus a to-one relation and carry no to-many relation and no `$count`, where the
 `*Include` carries both.
 
 A to-one projection on `update.many` works. A projection reaching a **to-many** relation or `$count`
-on these two variants answers `A3001` — sanitized, with nothing written. That is a 500 for an
-argument the Contract advertised, and it is a known, open gap rather than a surprise: the Contract has
-no per-variant projection slot in which to say "available on `update.one`, not on `update.many`".
+on these two variants is refused before any statement runs: `A2004` (a validation error) with the
+issue `V1008`, nothing written. The Contract advertises each relation's projection per position, and
+on these two variants the position the bulk result is read in does not include to-many relations.
 
-**Today:** keep `update.many`/`create.many` projections to scalars and to-one relations; read to-many
-relations with a separate `find`. **Phase 9** adds the per-variant projection capability so the
-Contract stops advertising a projection it cannot serve, and the refusal becomes a caller error
-(`A2004`) instead of a server failure. The adapter deliberately does **not** paper over it with a
-follow-up read: that would add a statement and a new consistency window to a bulk write.
+**In practice:** keep `update.many`/`create.many` projections to scalars and to-one relations; read
+to-many relations with a separate `find`. The adapter deliberately does **not** paper over the gap
+with a follow-up read: that would add a statement and a new consistency window to a bulk write.
 
 ---
 
@@ -491,7 +489,7 @@ the artifact.
 Neither the model nor the compiled Contracts carry a referential action — the actions are beside the
 model and outside `modelHash`, so they move no Contract value and no hash. `createPrismaAdapter` states
 them to core through the adapter's optional `referentialActions` member, translated one to one into core's
-five words (the architect's, 2026-10-04, mirroring Prisma's and SQL's actions; direction unchanged):
+five words (mirroring Prisma's and SQL's actions; direction unchanged):
 
 | Prisma action | core's word | deleting a `target` row does this to rows of the enclosing Resource |
 |---|---|---|
@@ -502,12 +500,12 @@ five words (the architect's, 2026-10-04, mirroring Prisma's and SQL's actions; d
 | `set-default` | `setDefault` | keeps them, the reference set to its column default |
 
 Only `cascade` drives core behaviour (the `V1019` closure below). `restrict`, `noAction`, `setNull` and
-`setDefault` are carried as informational adapter facts, by the architect's choice: the adapter states
+`setDefault` are carried as informational adapter facts: the adapter states
 what the schema says rather than collapsing it into what core currently reads.
 
 `onUpdate` is not carried: core plans the **delete** closure only.
 
-**Planning-phase refusal is wired (Phase 9 S10).** Core builds the transitive closure of `cascade` edges
+**Planning-phase refusal.** Core builds the transitive closure of `cascade` edges
 once, at framework construction, and the transaction planner refuses a step that depends on rows an
 earlier step's cascade removed — its own Resource, or one its arguments reach through a relation — with
 `A2004`/`V1019` *"Transaction step depends on a row removed by an earlier step's cascade"*, before any

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aventara/prisma7-adapter",
-  "version": "0.1.0-pilot.0",
+  "version": "0.1.0-pilot.1",
   "license": "SEE LICENSE IN LICENSE",
   "description": "The Prisma 7 adapter for Aventara.",
   "type": "module",
@@ -29,7 +29,7 @@
     "LICENSE-ADDITIONAL-PERMISSION.md"
   ],
   "dependencies": {
-    "@aventara/core": "0.1.0-pilot.0"
+    "@aventara/core": "0.1.0-pilot.1"
   },
   "peerDependencies": {
     "@prisma/adapter-better-sqlite3": "^7.10.0",