Merge main into prisma-8

.changeset/loud-comets-invent.md

@@ -143,7 +143,7 @@ field a `resolveInput` hook derives is embedded like any other.
 
 The embedding and its metadata are write-denied to application code: an ordinary create or
 update naming them throws. The plugin writes them itself, past that denial and running no
-hook of the list's (ADR-0066), after the write's transaction settles. Applications that maintain their own vectors opt out explicitly:
+hook of the list's (ADR-0068), after the write's transaction settles. Applications that maintain their own vectors opt out explicitly:
 
 ```typescript
 manualVector: embedding({ dimensions: 1536, allowManualWrites: true })

.changeset/quiet-columns-settle.md

@@ -65,7 +65,7 @@ It takes the `AccessContext` `Plugin.runtime` receives as its first argument; th
 `StackContext` `getContext` returns carries no ORM handle and is refused by name. That
 second argument, `sudo`, is now declared as the `StackContext` it always was — a plugin
 reaching `sudo().db` is unaffected, one reaching `ormHandle` off it was already getting
-`undefined` and now fails to compile. See ADR-0066.
+`undefined` and now fails to compile. See ADR-0068.
 
 A write refused by name is a wiring defect that fails identically on every row, so the RAG
 plugin's failure log now reports all three refusals — and `WriteCollectionMissingError`

.changeset/stale-planets-refuse.md

@@ -0,0 +1,22 @@
+---
+'@opensaas/stack-core': minor
+---
+
+The nested-write access gap reported in #1384 is closed by refusal, not by gating
+
+Nested `set`, `updateMany` and `deleteMany` under a relationship key used to
+reach the database as an unchecked pass-through: the target list's access was
+never consulted, no hooks ran, and an unscoped `where` could reach rows well
+outside the parent's own subtree. Nested `disconnect` could name a target row
+the caller could not read.
+
+Both are closed here by ADR-0050 rather than by per-kind access machinery:
+nested relation input leaves the write payload entirely, so `create`, `update`,
+`delete`, `connectOrCreate`, `disconnect`, `set`, `updateMany` and `deleteMany`
+are all refused with `NestedRelationInputError`. The refusal is unconditional —
+`sudo()` does not lift it — which is strictly stronger than the interim
+non-sudo-only refusal #1385 shipped on the previous line. Clearing an edge is
+now `null` on the relationship field; every other case is a write against the
+target list, wrapped in `context.transaction()` when it must land atomically.
+
+See `rugged-terminals-persist.md` for the full write-surface change.

CLAUDE.md

@@ -354,7 +354,7 @@ export function myPlugin(pluginConfig: MyConfig): Plugin {
 }
 ```
 
-A plugin writing a column it owns and the application cannot write — an embedding, say — uses `writePluginOwnedField` from `@opensaas/stack-core/extend` rather than driving the list's own pipeline under `sudo()`. Re-running the pipeline over a payload naming one field recomputes derived fields from input that is not there. See ADR-0066.
+A plugin writing a column it owns and the application cannot write — an embedding, say — uses `writePluginOwnedField` from `@opensaas/stack-core/extend` rather than driving the list's own pipeline under `sudo()`. Re-running the pipeline over a payload naming one field recomputes derived fields from input that is not there. See ADR-0068.
 
 **Runtime Access:**
 

CONTEXT.md

@@ -111,7 +111,7 @@ The single module that runs the canonical, secured write sequence (operation-lev
 _Avoid_: operation handler, mutation service
 
 **Plugin-owned field write**:
-The write a plugin makes to a field it computes and application code is denied — an embedding, say. It is not an application update: it carries that field's columns alone and completes a write the application already made, whose hooks have already run against the caller's real input, so it runs **no** hook. `writePluginOwnedField` on `@opensaas/stack-core/extend` is the whole of it: resolve the field against the config the context carries, split the value through that field's own `splitColumns`, issue one id-scoped `UPDATE` marked with the engine origin. It reaches no field but the one named — enforced, since the caller supplies no column layout — and a list, a field or a value (`undefined`) it cannot make sense of is refused by name. Driving it through `sudo().db` instead re-runs the list's pipeline over a payload naming one field, which recomputes a derived field from input that is not there and destroys it (ADR-0066).
+The write a plugin makes to a field it computes and application code is denied — an embedding, say. It is not an application update: it carries that field's columns alone and completes a write the application already made, whose hooks have already run against the caller's real input, so it runs **no** hook. `writePluginOwnedField` on `@opensaas/stack-core/extend` is the whole of it: resolve the field against the config the context carries, split the value through that field's own `splitColumns`, issue one id-scoped `UPDATE` marked with the engine origin. It reaches no field but the one named — enforced, since the caller supplies no column layout — and a list, a field or a value (`undefined`) it cannot make sense of is refused by name. Driving it through `sudo().db` instead re-runs the list's pipeline over a payload naming one field, which recomputes a derived field from input that is not there and destroys it (ADR-0068).
 _Avoid_: sudo write, plugin update, escalated update
 
 **Hook Pipeline**:

docs/adr/0052-the-generated-types-declare-the-contract-remainder-and-instantiate-core-generics.md

@@ -135,3 +135,40 @@ Four spellings today say what a field's TypeScript face is: `getTypeScriptType()
 - **The dependency set is emitted twice from one pass** — as data for the engine (ADR-0051) and as the `needs` type here. They cannot drift because the generator computes the set once and renders it in both forms; a build effort that computes them separately has reintroduced the two-walker shape ADR-0051 deleted.
 - **ADR-0032 is amended**: its rejected mapped-type option is adopted now the registry exists; its interface rule stands and extends to the generics core exports. **ADR-0040 is amended**: its "shrinks to what the contract cannot express" consequence resolves to the four items above. **ADR-0051 is amended**: the emitted set also has a type-level form, and its silent-break consequence is narrowed to untyped hooks.
 - **`CONTEXT.md` gains "Contract remainder"** for the per-list facts the generator authors because the contract cannot.
+
+## Amendment — a hook's `context` is keyed too ([#1211](https://github.com/OpenSaasAU/stack/issues/1211))
+
+The Hook arguments section above has three consequences; there is a fourth, and
+it was missing rather than decided against. Every hook-args type hardcodes an
+unparameterised `context`, so a hook's context statically resolves over
+`PrismaClientLike = any`. `AccessControlledDB<any>` is a mapped type over
+`keyof any` intersected with an index signature: it declares no named delegate,
+is therefore assignable to nothing, and accepts `context.db.typoedListName`
+without complaint. A consumer passing a hook's `context` into its own typed
+function has no expressible spelling and must write
+`context as unknown as Context`.
+
+This record's own keying is what closes it. `TypeInfo` is the config-facing
+seam, so it carries the app's `DB` alongside `item`, `output`, `inputs` and
+`fields`, and core's generic hook types read `context` off it — a hook's
+`context` is keyed to the same `DB` the generated `Context` instantiates, not
+widened. The consequence "Core gains the generics and loses `any`" already
+deletes `PrismaClientLike` and `AccessControlledDB`'s structural probing; this
+says the hook args must be keyed at the same time rather than left reading a
+deleted default.
+
+What a hook's context is keyed to is settled here; what it _carries_ is not.
+Under this record every hook — `resolveInput`, `validate`,
+`beforeOperation`, `afterOperation` and a field `resolveOutput` — receives
+`StackBaseContext<DB, S, PluginServices>`, emitted per app as `BaseContext`:
+the secured `db`, the session and the ambient plumbing, and nothing that can
+start a transaction or change who is asking. `sudo()`, `withSession()` and
+`transaction()` live on `StackContext` (`Context`), which a server action or
+page component holds. `beforeTransaction` / `afterTransaction` keep the plain
+base-client-bound context of ADR-0028, keyed to the same `DB`.
+
+`main` closes this ahead of the build, threading the client type through
+`TypeInfo` under the pre-contract keying (#1211). That work is not wasted and
+not a second mechanism: the seam it establishes — the client type enters at
+`TypeInfo`, and core's hook types read it from there — is the seam this record
+keeps. What changes under the contract is only what `TypeInfo` holds.