From 82956ea6d0d78b948ddbe481289afcc9c1e86b89 Mon Sep 17 00:00:00 2001
From: Mobeen Abdullah <mobeenabdullah@gmail.com>
Date: Sat, 12 Sep 2026 03:38:54 +0300
Subject: [PATCH 1/6] fix(nextly): a function default cannot read a field the
 caller may not write

Field write access now runs before the defaults as well as after the hooks, the
two passes the read path already runs. A function `defaultValue` receives the
data built so far, and it ran while a field this caller is denied was still in
the record, so a default could read the forbidden value and carry it into a
field the caller IS allowed to write. The denied field was stripped and its
value persisted anyway, one column across, which is the field rule defeated by
proxy. Both passes share one grants resolver, so the caller's roles and
permissions are still read once.

A config reload re-registers the live config's field functions. The registry
holds every field's access rules, hooks, validate and function defaultValue,
none of which survive being stored, and a reload never went back through service
registration: an edit to any of them kept running the version from process start
until the dev server was restarted. Wrong in the direction that matters most for
an access rule, since a rule tightened in the config was not the one enforced.
Applied on the same optimistic terms as the field-type registry, and put back by
the same undo when a reload is abandoned.

The registry keyed only named entries, so every rule, hook and validator
declared inside an unnamed presentational group was dropped. `defineCollection`
refuses a field with no name, but the plugin declaration gate checks field TYPES
and not their names, so the shape reaches the live config. Flattened through the
repository's own addressable-fields walk, which already knows an unnamed group
stores its children at its own level while an unnamed repeater does not.

A Single's first read no longer invents an incomplete group: filling one for the
sake of a defaulted child while a required sibling has no value stored a
document the next write would refuse, and that insert runs no validation pass.

The docs no longer claim a field group's children take their defaults before the
entry's hooks; they are written in their own pass afterwards.
---
 .../a-default-cannot-read-a-denied-field.md   | 37 ++++++++
 docs/configuration/fields.mdx                 |  9 +-
 ...ot-read-a-denied-field.integration.test.ts | 94 +++++++++++++++++++
 .../services/collection-mutation-service.ts   | 34 +++++++
 ...t-read-nested-defaults.integration.test.ts | 61 ++++++++++++
 .../singles/services/single-query-service.ts  | 48 ++++++++++
 packages/nextly/src/init/reload-config.ts     | 37 ++++++++
 .../field-functions-snapshot.test.ts          | 61 ++++++++++++
 .../src/shared/lib/field-level-registry.ts    | 92 ++++++++++++++++--
 9 files changed, 463 insertions(+), 10 deletions(-)
 create mode 100644 .changeset/a-default-cannot-read-a-denied-field.md
 create mode 100644 packages/nextly/src/collections/__tests__/default-cannot-read-a-denied-field.integration.test.ts
 create mode 100644 packages/nextly/src/shared/lib/__tests__/field-functions-snapshot.test.ts

diff --git a/.changeset/a-default-cannot-read-a-denied-field.md b/.changeset/a-default-cannot-read-a-denied-field.md
new file mode 100644
index 0000000000..bb22948578
--- /dev/null
+++ b/.changeset/a-default-cannot-read-a-denied-field.md
@@ -0,0 +1,37 @@
+---
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/admin": patch
+"@nextlyhq/admin-css": patch
+"@nextlyhq/blocks-engine": patch
+"@nextlyhq/blocks-react": patch
+"@nextlyhq/builder": patch
+"create-nextly-app": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
+"@nextlyhq/module-specifiers": patch
+"nextly": patch
+"@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-page-builder": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/plugin-seo": patch
+"@nextlyhq/prettier-config": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
+"@nextlyhq/telemetry": patch
+"@nextlyhq/tsconfig": patch
+"@nextlyhq/ui": patch
+---
+
+A function default cannot read a field the caller may not write. Field write access now runs before the defaults as well as after the hooks, the two passes the read path already runs: a `defaultValue` written as a function receives the data built so far, and it ran while a field this caller is denied was still in the record, so a default could read the forbidden value and carry it into a field the caller IS allowed to write. The denied field was stripped and its value was persisted anyway, one column across.
+
+A config reload re-registers the live config's field functions. The field-level registry holds every field's `access` rules, hooks, `validate` and function `defaultValue`, none of which survive being stored, and a reload never went back through service registration: an edit to any of them kept running the version from process start until the dev server was restarted. That is wrong in the direction that matters most for an access rule, since a rule tightened in the config was not the one being enforced. Applied on the same optimistic terms as the field-type registry, and restored by the same undo when a reload is abandoned.
+
+An access rule declared inside an unnamed container is captured. The registry keyed only named entries, so every rule, hook and validator inside an unnamed presentational group was dropped. `defineCollection` refuses a field with no name, but a plugin contributing raw config is checked on its field TYPES and not their names, so the shape reaches the live config.
+
+A Single's first read no longer invents an incomplete group. Filling a group for the sake of one defaulted child, while a required sibling has no default and no value, stored a document the next create or update would refuse; that insert runs no validation pass of its own. The group is left absent instead.
+
+The documentation no longer claims a field group's children take their defaults before the entry's hooks. They are written in their own pass afterwards, so the parent's hooks see such a child as absent.
diff --git a/docs/configuration/fields.mdx b/docs/configuration/fields.mdx
index d84f45d8bb..60b24c662e 100644
--- a/docs/configuration/fields.mdx
+++ b/docs/configuration/fields.mdx
@@ -1025,9 +1025,12 @@ Static value or `(data) => value` function. The function form receives the docum
 Both forms are applied on the server, so a default holds for every write
 path that applies defaults, not only for the admin form. On an ordinary
 collection create through the REST or Direct API, an omitted field takes its
-default before any hook runs, at every depth: a group's children, each
-supplied repeater row's children, and the children of each new field-group
-instance. A function default is read from the live config, since a
+default before any hook runs, at every depth: a group's children and each
+supplied repeater row's children. A new field-group instance also fills its own
+children's defaults, but LATER: a field group's rows are written in their own
+pass after the entry's hooks have run, so the parent's hooks see such a child as
+absent and cannot read or derive from the value that will be stored. A function
+default is read from the live config, since a
 collection's stored definition cannot hold a function, and it receives the
 data built so far at its own level: the document for a top-level field, the
 group or the row for a nested one. Rows are never invented; `minRows` is a
diff --git a/packages/nextly/src/collections/__tests__/default-cannot-read-a-denied-field.integration.test.ts b/packages/nextly/src/collections/__tests__/default-cannot-read-a-denied-field.integration.test.ts
new file mode 100644
index 0000000000..e379bc0898
--- /dev/null
+++ b/packages/nextly/src/collections/__tests__/default-cannot-read-a-denied-field.integration.test.ts
@@ -0,0 +1,94 @@
+/**
+ * A function default is evaluated on what the caller was ALLOWED to send.
+ *
+ * Function defaults receive the data built so far. They ran before field write
+ * access, so a field this caller may not create was still in the record while
+ * they ran: a default could read the forbidden value and carry it into a field
+ * the caller IS allowed to write. The denied field was stripped from the
+ * record and its value was persisted anyway, one column across, which is the
+ * field rule defeated by proxy.
+ *
+ * Write access now runs before the defaults as well as after the hooks, the
+ * two passes the read path runs for the same reason: the first decides what
+ * the caller may put in, the second catches a denied key a hook put back.
+ */
+import { afterEach, describe, expect, it } from "vitest";
+
+import { defineCollection, text } from "../../config";
+import { createTestNextly, type TestNextly } from "../../plugins/test-nextly";
+import type { CollectionsHandler } from "../../services/collections-handler";
+
+let current: TestNextly | undefined;
+afterEach(async () => {
+  await current?.destroy();
+  current = undefined;
+});
+
+const CALLER = { id: "u1", email: "u@x.test", roles: [] };
+
+async function boot() {
+  current = await createTestNextly({
+    collections: [
+      defineCollection({
+        slug: "leaky",
+        fields: [
+          text({ name: "title" }),
+          text({ name: "secret", access: { create: () => false } }),
+          text({
+            name: "derived",
+            defaultValue: d => `saw:${String(d.secret)}`,
+          }),
+          text({ name: "open" }),
+          text({
+            name: "fromOpen",
+            defaultValue: d => `saw:${String(d.open)}`,
+          }),
+        ],
+      }),
+    ],
+  });
+  return current.getService<"collectionsHandler">("collectionsHandler");
+}
+
+describe("a function default cannot read a field the caller may not write", () => {
+  it("evaluates on the authorized record, not the raw request", async () => {
+    const handler = (await boot()) as unknown as CollectionsHandler;
+
+    const created = await handler.createEntry(
+      {
+        collectionName: "leaky",
+        // The route gate has run; the FIELD rules are the ones under test.
+        routeAuthorized: true,
+        user: CALLER,
+      },
+      { title: "t", secret: "forbidden-value", open: "fine" }
+    );
+
+    expect(created.success, JSON.stringify(created)).toBe(true);
+    const row = created.data as Record<string, unknown>;
+    // The denied field is stripped, as it always was.
+    expect(row.secret ?? null).toBeNull();
+    // And its value did not reach the database through the default either.
+    expect(row.derived).not.toContain("forbidden-value");
+    expect(row.derived).toBe("saw:undefined");
+    // A default reading an ALLOWED field still sees it: the pass removes what
+    // the caller may not send, not everything they sent.
+    expect(row.fromOpen).toBe("saw:fine");
+  });
+
+  it("still lets a trusted caller's default read the field", async () => {
+    const handler = (await boot()) as unknown as CollectionsHandler;
+
+    const created = await handler.createEntry(
+      { collectionName: "leaky", overrideAccess: true },
+      { title: "t", secret: "system-value", open: "fine" }
+    );
+
+    expect(created.success, JSON.stringify(created)).toBe(true);
+    const row = created.data as Record<string, unknown>;
+    // `overrideAccess` means the field rules do not apply, so the value is
+    // both stored and visible to the default.
+    expect(row.secret).toBe("system-value");
+    expect(row.derived).toBe("saw:system-value");
+  });
+});
diff --git a/packages/nextly/src/domains/collections/services/collection-mutation-service.ts b/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
index 200940f0f5..2f80a3ddd4 100644
--- a/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
+++ b/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
@@ -83,6 +83,7 @@ import { applyFieldDefaults } from "../../../shared/lib/field-defaults";
 import {
   applyFieldReadAccess,
   applyFieldWriteAccess,
+  writeAccessGrants,
   attachFieldValidators,
   getFieldFunctions,
   runFieldHooks,
@@ -2903,6 +2904,37 @@ export class CollectionMutationService extends BaseService {
       // of write access matches generation, so a field the caller may not
       // create is not reintroduced.
       const seededBody: Record<string, unknown> = { ...body };
+      // One resolver for both write-access passes over this record, so the
+      // caller's roles and permissions are read once and both judge with one
+      // authority.
+      const writeGrants = writeAccessGrants(
+        params.user,
+        params.authenticatedScope
+      );
+      // Field write access runs HERE as well as below, the two passes the read
+      // path runs around its hooks and for the same reason.
+      //
+      // A function default receives the data built so far. Judged only after
+      // the defaults, a field this caller may not create would still be sitting
+      // in the record while those functions ran, so a default could read the
+      // forbidden value and carry it into a field the caller IS allowed to
+      // write. The denied field was stripped and its value persisted anyway,
+      // one column across. Stripping first means the functions see what this
+      // caller was actually allowed to send.
+      //
+      // The second pass below is not redundant: the hooks in between may put a
+      // denied key back, and that pass judges the key by its own rule on the
+      // value the hook wrote.
+      await applyFieldWriteAccess({
+        kind: "collection",
+        slug: params.collectionName,
+        data: seededBody,
+        operation: "create",
+        user: params.user,
+        authenticatedScope: params.authenticatedScope,
+        overrideAccess: params.overrideAccess,
+        grants: writeGrants,
+      });
       // The stored fields carry constant defaults; a function default exists
       // only in the live config, which the registry captured at boot.
       applyFieldDefaults(
@@ -2995,7 +3027,9 @@ export class CollectionMutationService extends BaseService {
         data: finalData,
         operation: "create",
         user: params.user,
+        authenticatedScope: params.authenticatedScope,
         overrideAccess: params.overrideAccess,
+        grants: writeGrants,
       });
 
       // Field-level beforeValidate hooks transform values ahead of the
diff --git a/packages/nextly/src/domains/singles/__tests__/single-first-read-nested-defaults.integration.test.ts b/packages/nextly/src/domains/singles/__tests__/single-first-read-nested-defaults.integration.test.ts
index b3e384269f..1da34d6d0b 100644
--- a/packages/nextly/src/domains/singles/__tests__/single-first-read-nested-defaults.integration.test.ts
+++ b/packages/nextly/src/domains/singles/__tests__/single-first-read-nested-defaults.integration.test.ts
@@ -168,4 +168,65 @@ describe("a Single's first read fills nested defaults (integration)", () => {
 
     expect(messages).toContain("must be a page document");
   });
+  it("leaves an invented group absent when a required child has no value", async () => {
+    current = await createTestNextly({
+      singles: [
+        defineSingle({
+          slug: "partial",
+          fields: [
+            group({
+              name: "contact",
+              fields: [
+                text({ name: "label", defaultValue: "Support" }),
+                // Required, with no default and nothing to supply it on a
+                // first read: a group created for `label` alone would be a
+                // document the next write refuses.
+                text({ name: "email", required: true }),
+              ],
+            }),
+          ],
+        }),
+      ],
+    });
+
+    const doc = (await current.nextly.findSingle({
+      slug: "partial",
+      overrideAccess: true,
+    })) as { contact?: unknown } | null;
+
+    expect(doc?.contact ?? null).toBeNull();
+  });
+
+  it("still fills a group whose required children are all satisfied", async () => {
+    current = await createTestNextly({
+      singles: [
+        defineSingle({
+          slug: "complete",
+          fields: [
+            group({
+              name: "contact",
+              fields: [
+                text({ name: "label", defaultValue: "Support" }),
+                text({
+                  name: "email",
+                  required: true,
+                  defaultValue: "support@example.test",
+                }),
+              ],
+            }),
+          ],
+        }),
+      ],
+    });
+
+    const doc = (await current.nextly.findSingle({
+      slug: "complete",
+      overrideAccess: true,
+    })) as { contact?: { label?: string; email?: string } } | null;
+
+    expect(doc?.contact).toEqual({
+      label: "Support",
+      email: "support@example.test",
+    });
+  });
 });
diff --git a/packages/nextly/src/domains/singles/services/single-query-service.ts b/packages/nextly/src/domains/singles/services/single-query-service.ts
index 177f67a110..9391368fd6 100644
--- a/packages/nextly/src/domains/singles/services/single-query-service.ts
+++ b/packages/nextly/src/domains/singles/services/single-query-service.ts
@@ -423,6 +423,38 @@ function hasFieldName<T extends { name?: string }>(
   return typeof field.name === "string" && field.name.length > 0;
 }
 
+/**
+ * Whether a filled container is missing a child its own declaration requires.
+ *
+ * Only asked of a container the default fill created, so "missing" means no
+ * default reached it and no caller supplied it. A required child inside a
+ * nested container counts as well: an incomplete group two levels down is
+ * still a document the write path would refuse.
+ */
+function missesARequiredChild(
+  fields: readonly ValidatableField[] | undefined,
+  filled: unknown
+): boolean {
+  if (!fields) return false;
+  if (Array.isArray(filled)) {
+    return filled.some(row => missesARequiredChild(fields, row));
+  }
+  if (!isPlainRecord(filled)) return false;
+  for (const child of fields) {
+    if (!child.name) {
+      // A layout container holds no value; its children are on this object.
+      if (missesARequiredChild(child.fields, filled)) return true;
+      continue;
+    }
+    const value = filled[child.name];
+    if (child.required && (value === undefined || value === null)) return true;
+    if (value !== undefined && missesARequiredChild(child.fields, value)) {
+      return true;
+    }
+  }
+  return false;
+}
+
 /**
  * A record the nested walk can read children off: an array is a repeater's
  * rows and is walked as rows, and a primitive holds no children at all.
@@ -1581,6 +1613,22 @@ export class SingleQueryService extends BaseService {
       applyFieldDefaults(logicalDefaults, [source]);
       const after = logicalDefaults[field.name];
       if (after === before) return;
+      // A group the fill INVENTED has to be complete to be stored. This insert
+      // is direct and runs no validation pass, so a group created for the sake
+      // of one defaulted child, while a required sibling has no default and no
+      // value, would persist a document that the next create or update refuses.
+      // Left absent instead, which is where it stood before anything was
+      // filled, rather than stored knowing it is invalid.
+      if (
+        before === undefined &&
+        missesARequiredChild(
+          (source as { fields?: readonly ValidatableField[] }).fields,
+          after
+        )
+      ) {
+        delete logicalDefaults[field.name];
+        return;
+      }
       await assertNestedDefaultsValid(
         (source as { fields?: readonly ValidatableField[] }).fields,
         after,
diff --git a/packages/nextly/src/init/reload-config.ts b/packages/nextly/src/init/reload-config.ts
index aab9a677bb..3da9e36602 100644
--- a/packages/nextly/src/init/reload-config.ts
+++ b/packages/nextly/src/init/reload-config.ts
@@ -1549,6 +1549,43 @@ async function applyReload(opts?: {
       singles: newConfig?.singles,
       fieldGroups: newConfig?.fieldGroups,
     });
+
+    // The field-level registry holds the function-bearing half of the live
+    // config: a field's `access` rules, its hooks, its `validate`, and a
+    // `defaultValue` written as a function. None of it survives being stored,
+    // so it is captured from the config object at boot and read from here on
+    // every write and every read.
+    //
+    // A reload never goes back through `registerServices`, so that capture was
+    // never refreshed. An edit to any of it kept running the version from
+    // process start until the dev server was restarted, which is wrong in the
+    // direction that matters most for an access rule: a rule TIGHTENED in the
+    // config was not the one being enforced.
+    //
+    // Applied on the same optimistic terms as the field types above, and put
+    // back by the same undo, so a reload that is abandoned leaves the retained
+    // config's functions in force.
+    const {
+      registerFieldFunctions,
+      snapshotFieldFunctions,
+      restoreFieldFunctions,
+    } = await import("../shared/lib/field-level-registry");
+    const previousFieldFunctions = snapshotFieldFunctions();
+    reloadUndo.push(() => restoreFieldFunctions(previousFieldFunctions));
+    for (const collection of newConfig?.collections ?? []) {
+      const slug = (collection as { slug?: string }).slug;
+      const fields = (collection as { fields?: unknown[] }).fields;
+      if (slug && Array.isArray(fields)) {
+        registerFieldFunctions("collection", slug, fields);
+      }
+    }
+    for (const single of newConfig?.singles ?? []) {
+      const slug = (single as { slug?: string }).slug;
+      const fields = (single as { fields?: unknown[] }).fields;
+      if (slug && Array.isArray(fields)) {
+        registerFieldFunctions("single", slug, fields);
+      }
+    }
   } catch (err) {
     // The registry was rebuilt from the config that just failed; put the
     // working set back so the retained config keeps the behavior it was
diff --git a/packages/nextly/src/shared/lib/__tests__/field-functions-snapshot.test.ts b/packages/nextly/src/shared/lib/__tests__/field-functions-snapshot.test.ts
new file mode 100644
index 0000000000..8e6a958be6
--- /dev/null
+++ b/packages/nextly/src/shared/lib/__tests__/field-functions-snapshot.test.ts
@@ -0,0 +1,61 @@
+/**
+ * The field-function registry can be snapshotted and put back.
+ *
+ * A config reload re-registers from the newly read config before it knows the
+ * reload will land, on the same optimistic terms as the field-type registry.
+ * A reload that is then abandoned has to leave the retained config's functions
+ * in force: an access rule from a config that never took effect must not be
+ * the one deciding writes.
+ */
+import { describe, expect, it } from "vitest";
+
+import {
+  getFieldFunctions,
+  registerFieldFunctions,
+  restoreFieldFunctions,
+  snapshotFieldFunctions,
+} from "../field-level-registry";
+
+describe("snapshotFieldFunctions / restoreFieldFunctions", () => {
+  it("puts back what was registered, and drops what the abandoned run added", () => {
+    registerFieldFunctions("collection", "kept", [
+      { name: "tone", type: "text", defaultValue: () => "before" },
+    ]);
+    const snapshot = snapshotFieldFunctions();
+
+    // What an abandoned reload would have done: change one entity and add one.
+    registerFieldFunctions("collection", "kept", [
+      { name: "tone", type: "text", defaultValue: () => "after" },
+    ]);
+    registerFieldFunctions("collection", "added", [
+      { name: "tone", type: "text", defaultValue: () => "new" },
+    ]);
+    expect(
+      getFieldFunctions("collection", "kept")?.tone?.defaultValue?.({})
+    ).toBe("after");
+    expect(getFieldFunctions("collection", "added")).toBeDefined();
+
+    restoreFieldFunctions(snapshot);
+
+    expect(
+      getFieldFunctions("collection", "kept")?.tone?.defaultValue?.({})
+    ).toBe("before");
+    // The entity the abandoned run introduced is gone, not merely stale.
+    expect(getFieldFunctions("collection", "added")).toBeUndefined();
+  });
+
+  it("is a copy, so registering after the snapshot does not change it", () => {
+    registerFieldFunctions("collection", "copied", [
+      { name: "tone", type: "text", defaultValue: () => "one" },
+    ]);
+    const snapshot = snapshotFieldFunctions();
+    registerFieldFunctions("collection", "copied", [
+      { name: "tone", type: "text", defaultValue: () => "two" },
+    ]);
+
+    restoreFieldFunctions(snapshot);
+    expect(
+      getFieldFunctions("collection", "copied")?.tone?.defaultValue?.({})
+    ).toBe("one");
+  });
+});
diff --git a/packages/nextly/src/shared/lib/field-level-registry.ts b/packages/nextly/src/shared/lib/field-level-registry.ts
index 6db6f07d92..980a22d664 100644
--- a/packages/nextly/src/shared/lib/field-level-registry.ts
+++ b/packages/nextly/src/shared/lib/field-level-registry.ts
@@ -40,6 +40,7 @@ import {
   listEffectivePermissions,
   listRoleSlugsForUser,
 } from "../../services/lib/permissions";
+import { addressableFields } from "../addressable-fields";
 
 import { detachData } from "./detach";
 import type { ValidatableField } from "./entry-validation";
@@ -220,14 +221,46 @@ function extractFieldFunctions(
   return hasAny ? out : undefined;
 }
 
+/**
+ * An unnamed GROUP is layout: its children are stored at the level the group
+ * sits in, which is the level this map is keyed by. An unnamed REPEATER is not:
+ * its children are stored PER ROW, so flattening them here would file a row's
+ * field under the parent's name and hand its rules the wrong object.
+ *
+ * The same distinction `collection-sources` draws, and it has to be made DURING
+ * the walk: the walk emits the children themselves, so by the time a predicate
+ * could read the result, a field reached through an unnamed repeater is
+ * indistinguishable from one reached through an unnamed group.
+ */
+function storedAtThisLevel(container: { type?: unknown }): boolean {
+  return container.type === "group";
+}
+
+/**
+ * The function-bearing fields at one level, keyed by name.
+ *
+ * Flattened through the shared `addressableFields` walk rather than a loop over
+ * the array, because an unnamed presentational container stores its children at
+ * the level it sits in. A loop over named entries drops every rule declared
+ * inside one: not just a `defaultValue`, but the `access` rule deciding whether
+ * a caller may read or write that field, and the hooks that shape it. The data
+ * side already flattens these containers, so the two now agree.
+ *
+ * `defineCollection` refuses a field with no name, so the documented code-first
+ * path cannot build this shape. A plugin contributing raw config can:
+ * `assertPluginFieldDeclarations` checks each field's TYPE and not its name, so
+ * an unnamed `group` reaches the live config and this map. Silently dropping
+ * the access rules inside it is the failure worth spending a walk to avoid.
+ */
 function collectFieldFunctions(
   fields: unknown[]
 ): Record<string, FieldFunctions> | undefined {
   const map: Record<string, FieldFunctions> = {};
   let hasAny = false;
-  for (const raw of fields) {
-    if (raw === null || typeof raw !== "object") continue;
-    const field = raw as Record<string, unknown>;
+  for (const raw of addressableFields(fields, {
+    descendInto: storedAtThisLevel,
+  })) {
+    const field = raw as unknown as Record<string, unknown>;
     if (typeof field.name !== "string" || !field.name) continue;
     const fns = extractFieldFunctions(field);
     if (fns) {
@@ -255,6 +288,27 @@ export function registerFieldFunctions(
   }
 }
 
+/**
+ * The whole registry as it stands, and the means to put it back.
+ *
+ * A config reload re-reads the live config and re-registers from it, which has
+ * to happen before the reload knows it will land: the same optimistic terms the
+ * field-type registry and the config's hooks are applied on. A reload that is
+ * then abandoned must leave the retained config's functions in force, or an
+ * access rule, hook or default from a config that never took effect would be
+ * the one deciding writes.
+ */
+export function snapshotFieldFunctions(): Store {
+  return new Map(store());
+}
+
+/** Put a {@link snapshotFieldFunctions} result back, discarding what is there. */
+export function restoreFieldFunctions(snapshot: Store): void {
+  const current = store();
+  current.clear();
+  for (const [k, v] of snapshot) current.set(k, v);
+}
+
 export function getFieldFunctions(
   kind: EntityKind,
   slug: string
@@ -432,6 +486,13 @@ export async function applyFieldWriteAccess(opts: {
   authenticatedScope?: AuthenticatedScope;
   overrideAccess?: boolean;
   id?: string;
+  /**
+   * A resolver shared with another pass over the same write, so the caller's
+   * roles and permissions are read once and both passes judge with one
+   * authority. Build it with {@link writeAccessGrants}. Omitted, this pass
+   * builds its own, which is right for a write judged only once.
+   */
+  grants?: () => Promise<CallerGrants>;
 }): Promise<void> {
   // Bypass for a caller that has SAID it is trusted, and only that. The read
   // side gates on the same single condition, and the two must agree: a rule
@@ -458,10 +519,12 @@ export async function applyFieldWriteAccess(opts: {
     // answers `{ permissions: [], roles: [] }` — so a rule written as
     // `({ permissions }) => permissions.includes(...)` refuses it, which is
     // the correct answer rather than an accident of the shape.
-    grants: grantsResolver(
-      typeof opts.user?.id === "string" ? opts.user.id : undefined,
-      opts.authenticatedScope
-    ),
+    grants:
+      opts.grants ??
+      grantsResolver(
+        typeof opts.user?.id === "string" ? opts.user.id : undefined,
+        opts.authenticatedScope
+      ),
   });
 }
 
@@ -681,6 +744,21 @@ export function readAccessGrants(
   );
 }
 
+/**
+ * The caller's grants resolver for a write, to hand to every field-access pass
+ * over one record so roles and permissions are read once. The counterpart to
+ * {@link readAccessGrants}, for the write path's two passes.
+ */
+export function writeAccessGrants(
+  user: Record<string, unknown> | undefined,
+  authenticatedScope?: AuthenticatedScope
+): () => Promise<CallerGrants> {
+  return grantsResolver(
+    typeof user?.id === "string" ? user.id : undefined,
+    authenticatedScope
+  );
+}
+
 /**
  * Enforce field-level read access on a serialized entry: fields whose
  * `access.read` denies are removed from the response, at every depth.

From 9b65954c2c3352845a46e3f0236b57ea84e8e0bd Mon Sep 17 00:00:00 2001
From: Mobeen Abdullah <mobeenabdullah@gmail.com>
Date: Sat, 12 Sep 2026 12:59:37 +0300
Subject: [PATCH 2/6] feat(nextly): a field-group child takes a function
 default (#1822)

A field group's fields are read from its stored definition on every write, and a
function does not survive being stored, so only a constant default applied
there. A `defaultValue` written as a function on a field-group child was
silently dropped on every write, which #1809 documented as an exception rather
than closed.

The field-level registry already solves exactly this for collections and
Singles: it captures the function-bearing half of the live config at boot, and
the write path reads the function from there. Field groups now join it. The
configs were already in hand at the point of registration, so nothing new is
loaded: `NextlyServiceConfig` carries `fieldGroups`, and the same function that
registers every collection and every single registers them beside it. The
config-reload path re-registers them too, so an edit is picked up without a
restart.

`prepareInstanceForWrite` takes the field group's slug, available at all six of
its call sites, and hands the function map to `applyFieldDefaults` exactly as a
collection create does.

Only the default is wired. The same capture holds a field's access rules, hooks
and validate, and nothing reads those for a field group, so registering them
changes nothing about whether they are enforced. The entity kind's comment says
so, rather than leaving the next reader to infer it.
---
 ...ld-group-child-takes-a-function-default.md | 31 ++++++++++
 docs/configuration/fields.mdx                 | 11 ++--
 packages/nextly/src/di/register.ts            | 12 ++++
 ...roup-instance-defaults.integration.test.ts | 57 +++++++++++++++++++
 .../services/field-group-mutation-service.ts  | 33 ++++++++---
 packages/nextly/src/init/reload-config.ts     |  7 +++
 .../src/shared/lib/field-level-registry.ts    | 12 +++-
 7 files changed, 148 insertions(+), 15 deletions(-)
 create mode 100644 .changeset/a-field-group-child-takes-a-function-default.md

diff --git a/.changeset/a-field-group-child-takes-a-function-default.md b/.changeset/a-field-group-child-takes-a-function-default.md
new file mode 100644
index 0000000000..9c58277b33
--- /dev/null
+++ b/.changeset/a-field-group-child-takes-a-function-default.md
@@ -0,0 +1,31 @@
+---
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/admin": patch
+"@nextlyhq/admin-css": patch
+"@nextlyhq/blocks-engine": patch
+"@nextlyhq/blocks-react": patch
+"@nextlyhq/builder": patch
+"create-nextly-app": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
+"@nextlyhq/module-specifiers": patch
+"nextly": patch
+"@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-page-builder": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/plugin-seo": patch
+"@nextlyhq/prettier-config": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
+"@nextlyhq/telemetry": patch
+"@nextlyhq/tsconfig": patch
+"@nextlyhq/ui": patch
+---
+
+A `defaultValue` written as a function now works on a reusable field group's children. A field group's fields are read from its stored definition on every write, and a function does not survive being stored, so only constants applied there: a function default on a field-group child was silently dropped on every write. Field groups now get the same live-config capture collections and Singles have, so the function form resolves from the config at boot, and it is re-read when the dev server reloads the config. It resolves against the instance being built, so a child may compute from a sibling defaulted before it.
+
+Only the default is wired. The same capture holds a field's `access` rules, hooks and `validate`, and nothing reads those for a field group, so registering them changes nothing about whether they are enforced.
diff --git a/docs/configuration/fields.mdx b/docs/configuration/fields.mdx
index 60b24c662e..ba339f56d3 100644
--- a/docs/configuration/fields.mdx
+++ b/docs/configuration/fields.mdx
@@ -1036,12 +1036,11 @@ data built so far at its own level: the document for a top-level field, the
 group or the row for a nested one. Rows are never invented; `minRows` is a
 validation rule, not an instruction to create rows.
 
-Inside a reusable field group, only a constant default applies. A field
-group's fields are read from its stored definition on every write, and a
-function cannot be stored, so a `defaultValue` written as a function on a
-field-group child is not applied anywhere: not on a collection create, not on
-a Single's first read, and not in the admin form. Give a field-group child a
-constant default, or set the value from the parent's own field.
+A field-group child takes its default the same way, constant or function. Its
+fields are read from a stored definition, which cannot carry a function, so the
+function form is read from the live config exactly as a collection's is. It
+resolves against the instance being built, so a child may compute from a sibling
+that was defaulted before it.
 
 A Single's first read creates its row with the same defaults, top-level and
 nested, with two exceptions: a default on a `fieldGroup` field itself is
diff --git a/packages/nextly/src/di/register.ts b/packages/nextly/src/di/register.ts
index c272f8c7c9..706f3bf825 100644
--- a/packages/nextly/src/di/register.ts
+++ b/packages/nextly/src/di/register.ts
@@ -1823,6 +1823,18 @@ async function registerConfigTablesInResolver(
       );
     }
   }
+
+  // Field groups: no table to resolve here (a field group's own table is
+  // provisioned by the field-group services), only the live config to capture.
+  // Its fields are read from the stored definition on every write, the same
+  // place a collection's are, so a `defaultValue` written as a function is
+  // dropped there and can only come from here.
+  for (const fieldGroup of config.fieldGroups ?? []) {
+    const slug = (fieldGroup as { slug?: string }).slug;
+    const fields = (fieldGroup as { fields?: unknown[] }).fields;
+    if (!slug || !Array.isArray(fields) || fields.length === 0) continue;
+    registerFieldFunctions("fieldGroup", slug, fields);
+  }
 }
 
 function logStorageConfiguration(
diff --git a/packages/nextly/src/domains/field-groups/__tests__/field-group-instance-defaults.integration.test.ts b/packages/nextly/src/domains/field-groups/__tests__/field-group-instance-defaults.integration.test.ts
index 07016de12c..ad76c2b8e9 100644
--- a/packages/nextly/src/domains/field-groups/__tests__/field-group-instance-defaults.integration.test.ts
+++ b/packages/nextly/src/domains/field-groups/__tests__/field-group-instance-defaults.integration.test.ts
@@ -166,4 +166,61 @@ describe("a new field-group instance takes its declared defaults (integration)",
       { heading: "Given", tone: "calm" },
     ]);
   });
+  it("applies a FUNCTION default declared on a field-group child", async () => {
+    current = await createTestNextly({
+      fieldGroups: [
+        defineFieldGroup({
+          slug: "fnhero",
+          fields: [
+            text({ name: "mode", defaultValue: "dark" }),
+            // A function cannot be stored, so the stored definition this write
+            // reads carries nothing for it. It resolves from the live config.
+            text({
+              name: "label",
+              defaultValue: d => `mode-${String(d.mode)}`,
+            }),
+          ],
+        }),
+      ],
+      collections: [
+        defineCollection({
+          slug: "fnpages",
+          fields: [
+            text({ name: "title" }),
+            fieldGroup({ name: "hero", component: "fnhero" }),
+            fieldGroup({
+              name: "slides",
+              component: "fnhero",
+              repeatable: true,
+            }),
+          ],
+        }),
+      ],
+    });
+    const handler = current.getService("collectionsHandler");
+
+    const created = await handler.createEntry(
+      { collectionName: "fnpages", overrideAccess: true },
+      { title: "Home", hero: {}, slides: [{ mode: "light" }] }
+    );
+    expect(created.success, JSON.stringify(created)).toBe(true);
+
+    const read = await handler.getEntry({
+      collectionName: "fnpages",
+      entryId: (created.data as { id: string }).id,
+      overrideAccess: true,
+    });
+    const data = read.data as {
+      hero?: { mode?: string; label?: string };
+      slides?: Array<{ mode?: string; label?: string }>;
+    };
+    // Resolved against the instance built so far, as it is for a collection
+    // field: the constant before it is visible to the function after it.
+    expect(data.hero).toMatchObject({ mode: "dark", label: "mode-dark" });
+    // A supplied sibling value is what the function reads, not the default.
+    expect(data.slides?.[0]).toMatchObject({
+      mode: "light",
+      label: "mode-light",
+    });
+  });
 });
diff --git a/packages/nextly/src/domains/field-groups/services/field-group-mutation-service.ts b/packages/nextly/src/domains/field-groups/services/field-group-mutation-service.ts
index 6c3af5a0c9..6875fe62c7 100644
--- a/packages/nextly/src/domains/field-groups/services/field-group-mutation-service.ts
+++ b/packages/nextly/src/domains/field-groups/services/field-group-mutation-service.ts
@@ -19,6 +19,7 @@ import type { FieldGroupRegistryService } from "../../../services/field-groups/f
 import { BaseService } from "../../../shared/base-service";
 import { validateEntryData } from "../../../shared/lib/entry-validation";
 import { applyFieldDefaults } from "../../../shared/lib/field-defaults";
+import { getFieldFunctions } from "../../../shared/lib/field-level-registry";
 import {
   coerceDateFieldsToDate,
   normalizeRelationshipFields,
@@ -667,7 +668,8 @@ export class FieldGroupMutationService extends BaseService {
         data,
         componentFields,
         existing.length > 0 ? "update" : "create",
-        req
+        req,
+        componentMeta.slug
       );
 
       // i18n: split translatable values out of the main comp_ write — they live on the
@@ -784,7 +786,8 @@ export class FieldGroupMutationService extends BaseService {
         data,
         componentFields,
         existing.length > 0 ? "update" : "create",
-        req
+        req,
+        componentMeta.slug
       );
 
       // i18n: split translatable values out of the main comp_ write (companion-owned).
@@ -898,7 +901,8 @@ export class FieldGroupMutationService extends BaseService {
           instance,
           componentFields,
           instanceId && existingMap.has(instanceId) ? "update" : "create",
-          req
+          req,
+          componentMeta.slug
         );
 
         // i18n: split translatable values out per instance (companion-owned). The
@@ -1032,7 +1036,8 @@ export class FieldGroupMutationService extends BaseService {
           instance,
           componentFields,
           instanceId && existingMap.has(instanceId) ? "update" : "create",
-          req
+          req,
+          componentMeta.slug
         );
 
         // i18n: split translatable values out (companion-owned) per instance.
@@ -1217,7 +1222,8 @@ export class FieldGroupMutationService extends BaseService {
           instance,
           componentFields,
           instanceId && globalExistingMap.has(instanceId) ? "update" : "create",
-          req
+          req,
+          meta.slug
         );
 
         // i18n: split translatable values out per instance using its own component meta.
@@ -1385,7 +1391,8 @@ export class FieldGroupMutationService extends BaseService {
           instance,
           componentFields,
           instanceId && globalExistingMap.has(instanceId) ? "update" : "create",
-          req
+          req,
+          meta.slug
         );
 
         // i18n: split translatable values out per instance using its own component meta.
@@ -1630,7 +1637,13 @@ export class FieldGroupMutationService extends BaseService {
     instance: ComponentInstanceData,
     componentFields: FieldConfig[],
     mode: "create" | "update",
-    req: Record<string, unknown> = {}
+    req: Record<string, unknown> = {},
+    /**
+     * The field group's slug, so a `defaultValue` written as a FUNCTION can be
+     * read from the field-level registry. The fields above come from the
+     * stored definition, which carries constants and cannot carry a function.
+     */
+    slug?: string
   ): Promise<void> {
     // A component instance must be a plain object. A primitive (e.g. a bare
     // string sent for a non-repeatable component field) would make the field
@@ -1653,7 +1666,11 @@ export class FieldGroupMutationService extends BaseService {
     // instance the caller could not have completed. An existing instance is
     // left alone: its absent keys are the caller's patch, not missing values.
     if (mode === "create") {
-      applyFieldDefaults(instance, componentFields);
+      applyFieldDefaults(
+        instance,
+        componentFields,
+        slug ? getFieldFunctions("fieldGroup", slug) : undefined
+      );
     }
     // Reduced in place, and before validation, because both halves of the write
     // depend on it. A validator is written against a field's public value, the
diff --git a/packages/nextly/src/init/reload-config.ts b/packages/nextly/src/init/reload-config.ts
index a86b32bf62..566fe5123f 100644
--- a/packages/nextly/src/init/reload-config.ts
+++ b/packages/nextly/src/init/reload-config.ts
@@ -1562,6 +1562,13 @@ async function applyReload(opts?: {
         registerFieldFunctions("single", slug, fields);
       }
     }
+    for (const fieldGroup of newConfig?.fieldGroups ?? []) {
+      const slug = (fieldGroup as { slug?: string }).slug;
+      const fields = (fieldGroup as { fields?: unknown[] }).fields;
+      if (slug && Array.isArray(fields)) {
+        registerFieldFunctions("fieldGroup", slug, fields);
+      }
+    }
   } catch (err) {
     // The registry was rebuilt from the config that just failed; put the
     // working set back so the retained config keeps the behavior it was
diff --git a/packages/nextly/src/shared/lib/field-level-registry.ts b/packages/nextly/src/shared/lib/field-level-registry.ts
index 980a22d664..bf28f9aafc 100644
--- a/packages/nextly/src/shared/lib/field-level-registry.ts
+++ b/packages/nextly/src/shared/lib/field-level-registry.ts
@@ -157,7 +157,17 @@ export interface FieldFunctions {
   fields?: Record<string, FieldFunctions>;
 }
 
-type EntityKind = "collection" | "single";
+/**
+ * What a registration is keyed by.
+ *
+ * A field group joins the two entity kinds because it has the same problem and
+ * only the registry solves it: its fields are read from a stored definition on
+ * every write, and a function does not survive being stored. What is CONSUMED
+ * from a field group's entry today is the `defaultValue` alone. Its `access`
+ * rules and hooks are captured by the same walk but nothing reads them for a
+ * field group, so registering one does not mean they are enforced.
+ */
+type EntityKind = "collection" | "single" | "fieldGroup";
 type Store = Map<string, Record<string, FieldFunctions>>;
 
 const GLOBAL_KEY = "__nextlyFieldFunctionRegistry";

From 19bf093ac9c5476f1a007055fec2bc0501ce4a4e Mon Sep 17 00:00:00 2001
From: Mobeen Abdullah <mobeenabdullah@gmail.com>
Date: Sat, 12 Sep 2026 13:12:46 +0300
Subject: [PATCH 3/6] fix(nextly): judge a create's field rules on a copy, and
 swap the registry at the commit

Three review findings on the access and reload changes.

The pre-defaults access pass DELETED denied fields, and a create rule may
depend on a sibling the caller omitted precisely BECAUSE it has a default
(`data.kind === "public"` where `kind` defaults to `public`). The rule was
judged before that default existed, denied, and the caller's value was gone
before the pass that decides correctly could keep it. Measured: a supplied
`note` came back null on a create that succeeded before.

The rules now run over a COPY, and the copy is what the function defaults read.
`applyFieldDefaults` takes that view as an argument and threads it through
groups and repeater rows, so a nested default reads the nested view. The record
itself is untouched until the authoritative pass, which runs after the defaults
and therefore judges the condition they establish.

The reload installed the new field functions as soon as the config was read,
with an undo on the abandon paths. A reload whose DDL succeeds and whose later
metadata sync fails does not commit and does not run those undos, so a rule
from a config the process refused was deciding writes while every other service
ran the previous one. It is now staged and installed by `commitReload`, the
same boundary the config's hooks and the retention policies are published from.

That install replaces the registry wholesale rather than overwriting the slugs
it finds. A collection dropped from the config keeps its registry row and its
table so an orphan sweep can find them later, so it stays addressable, and its
entry here would have gone on running its old access rules, hooks, validators
and defaults until the process restarted.
---
 .../a-default-cannot-read-a-denied-field.md   |  5 +-
 ...ot-read-a-denied-field.integration.test.ts | 37 +++++++++
 .../services/collection-mutation-service.ts   | 32 ++++----
 packages/nextly/src/init/reload-config.ts     | 55 +++++++------
 .../__tests__/field-functions-replace.test.ts | 80 +++++++++++++++++++
 .../field-functions-snapshot.test.ts          | 61 --------------
 .../nextly/src/shared/lib/field-defaults.ts   | 51 +++++++++---
 .../src/shared/lib/field-level-registry.ts    | 43 ++++++----
 8 files changed, 238 insertions(+), 126 deletions(-)
 create mode 100644 packages/nextly/src/shared/lib/__tests__/field-functions-replace.test.ts
 delete mode 100644 packages/nextly/src/shared/lib/__tests__/field-functions-snapshot.test.ts

diff --git a/.changeset/a-default-cannot-read-a-denied-field.md b/.changeset/a-default-cannot-read-a-denied-field.md
index bb22948578..33c672cbc2 100644
--- a/.changeset/a-default-cannot-read-a-denied-field.md
+++ b/.changeset/a-default-cannot-read-a-denied-field.md
@@ -24,11 +24,12 @@
 "@nextlyhq/telemetry": patch
 "@nextlyhq/tsconfig": patch
 "@nextlyhq/ui": patch
+"@nextlyhq/plugin-mcp": patch
 ---
 
-A function default cannot read a field the caller may not write. Field write access now runs before the defaults as well as after the hooks, the two passes the read path already runs: a `defaultValue` written as a function receives the data built so far, and it ran while a field this caller is denied was still in the record, so a default could read the forbidden value and carry it into a field the caller IS allowed to write. The denied field was stripped and its value was persisted anyway, one column across.
+A function default cannot read a field the caller may not write. A `defaultValue` written as a function receives the data built so far, and that data still held every value the caller sent, including one a field rule denies them, so a default could read the forbidden value and carry it into a field the caller IS allowed to write: the denied field was stripped and its value persisted anyway, one column across. The rules are now applied to a COPY, and the copy is what the functions read. The record itself is left alone until the pass that decides what is stored, because a rule may depend on a sibling the caller omitted precisely BECAUSE it has a default, and judging that rule before the defaults exist would deny it and lose the value for good.
 
-A config reload re-registers the live config's field functions. The field-level registry holds every field's `access` rules, hooks, `validate` and function `defaultValue`, none of which survive being stored, and a reload never went back through service registration: an edit to any of them kept running the version from process start until the dev server was restarted. That is wrong in the direction that matters most for an access rule, since a rule tightened in the config was not the one being enforced. Applied on the same optimistic terms as the field-type registry, and restored by the same undo when a reload is abandoned.
+A config reload installs the live config's field functions, replacing them wholesale at the point the reload commits. Replacing rather than adding, so an entity the new config no longer declares stops deciding anything: a collection dropped from the config keeps its registry row and its table so an orphan sweep can find them, so it stays addressable. At the commit point rather than when the config is read, so a reload whose DDL succeeds and whose later sync fails does not leave a rule from a config the process refused deciding writes. The field-level registry holds every field's `access` rules, hooks, `validate` and function `defaultValue`, none of which survive being stored, and a reload never went back through service registration: an edit to any of them kept running the version from process start until the dev server was restarted. That is wrong in the direction that matters most for an access rule, since a rule tightened in the config was not the one being enforced. Applied on the same optimistic terms as the field-type registry, and restored by the same undo when a reload is abandoned.
 
 An access rule declared inside an unnamed container is captured. The registry keyed only named entries, so every rule, hook and validator inside an unnamed presentational group was dropped. `defineCollection` refuses a field with no name, but a plugin contributing raw config is checked on its field TYPES and not their names, so the shape reaches the live config.
 
diff --git a/packages/nextly/src/collections/__tests__/default-cannot-read-a-denied-field.integration.test.ts b/packages/nextly/src/collections/__tests__/default-cannot-read-a-denied-field.integration.test.ts
index e379bc0898..b38346a428 100644
--- a/packages/nextly/src/collections/__tests__/default-cannot-read-a-denied-field.integration.test.ts
+++ b/packages/nextly/src/collections/__tests__/default-cannot-read-a-denied-field.integration.test.ts
@@ -91,4 +91,41 @@ describe("a function default cannot read a field the caller may not write", () =
     expect(row.secret).toBe("system-value");
     expect(row.derived).toBe("saw:system-value");
   });
+  it("keeps a value whose permission a DEFAULT establishes", async () => {
+    current = await createTestNextly({
+      collections: [
+        defineCollection({
+          slug: "gated",
+          fields: [
+            text({ name: "title" }),
+            text({ name: "kind", defaultValue: "public" }),
+            text({
+              name: "note",
+              access: {
+                create: ({ data }) =>
+                  (data as { kind?: string } | undefined)?.kind === "public",
+              },
+            }),
+          ],
+        }),
+      ],
+    });
+    const handler = current.getService<"collectionsHandler">(
+      "collectionsHandler"
+    ) as unknown as CollectionsHandler;
+
+    const created = await handler.createEntry(
+      { collectionName: "gated", routeAuthorized: true, user: CALLER },
+      // `kind` is omitted on purpose: its default is what satisfies the rule
+      // guarding `note`.
+      { title: "t", note: "should survive" }
+    );
+
+    expect(created.success, JSON.stringify(created)).toBe(true);
+    const row = created.data as Record<string, unknown>;
+    expect(row.kind).toBe("public");
+    // The rules that decide what is STORED run after the defaults, so the
+    // value the caller sent is still there to be allowed.
+    expect(row.note).toBe("should survive");
+  });
 });
diff --git a/packages/nextly/src/domains/collections/services/collection-mutation-service.ts b/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
index 2f80a3ddd4..cd647a641f 100644
--- a/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
+++ b/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
@@ -2911,24 +2911,27 @@ export class CollectionMutationService extends BaseService {
         params.user,
         params.authenticatedScope
       );
-      // Field write access runs HERE as well as below, the two passes the read
-      // path runs around its hooks and for the same reason.
+      // What a function default is allowed to READ, which is not the same as
+      // what this write is allowed to STORE.
       //
-      // A function default receives the data built so far. Judged only after
-      // the defaults, a field this caller may not create would still be sitting
-      // in the record while those functions ran, so a default could read the
-      // forbidden value and carry it into a field the caller IS allowed to
-      // write. The denied field was stripped and its value persisted anyway,
-      // one column across. Stripping first means the functions see what this
-      // caller was actually allowed to send.
+      // A function default receives the data built so far, and that data still
+      // holds every value the caller sent, including one a field rule denies
+      // them. Left alone, a default could read the forbidden value and carry it
+      // into a field the caller IS allowed to write: the denied field would be
+      // stripped below and its value persisted anyway, one column across.
       //
-      // The second pass below is not redundant: the hooks in between may put a
-      // denied key back, and that pass judges the key by its own rule on the
-      // value the hook wrote.
+      // So the rules are applied to a COPY, and the copy is what the functions
+      // read. Applying them to the record itself would be wrong in the other
+      // direction: a rule may depend on a sibling the caller omitted BECAUSE it
+      // has a default (`data.kind === "public"` where `kind` defaults to
+      // `public`), and judging that rule before the defaults exist denies it.
+      // Deleting the value then would lose it for good, since the pass that
+      // decides correctly runs after the defaults and has nothing left to keep.
+      const readableByDefaults: Record<string, unknown> = { ...seededBody };
       await applyFieldWriteAccess({
         kind: "collection",
         slug: params.collectionName,
-        data: seededBody,
+        data: readableByDefaults,
         operation: "create",
         user: params.user,
         authenticatedScope: params.authenticatedScope,
@@ -2940,7 +2943,8 @@ export class CollectionMutationService extends BaseService {
       applyFieldDefaults(
         seededBody,
         fields,
-        getFieldFunctions("collection", params.collectionName)
+        getFieldFunctions("collection", params.collectionName),
+        readableByDefaults
       );
 
       const beforeOpArgs =
diff --git a/packages/nextly/src/init/reload-config.ts b/packages/nextly/src/init/reload-config.ts
index a86b32bf62..e6d605a480 100644
--- a/packages/nextly/src/init/reload-config.ts
+++ b/packages/nextly/src/init/reload-config.ts
@@ -1450,6 +1450,15 @@ async function applyReload(opts?: {
    * registered as that work happens and run together on abandonment.
    */
   const reloadUndo: Array<() => void> = [];
+  /**
+   * Installs the field-level registry the newly read config describes.
+   *
+   * Set once that config has been read and collected, and called only from
+   * `commitReload`. A reload abandoned before it is set, or one that never
+   * commits, leaves the previous registry in force by never having replaced
+   * it, so no rule from a refused config decides a write.
+   */
+  let commitFieldFunctions: (() => void) | undefined;
   /**
    * Put the field-type registry and the config's hooks back when a reload does
    * not take effect.
@@ -1538,30 +1547,27 @@ async function applyReload(opts?: {
     // direction that matters most for an access rule: a rule TIGHTENED in the
     // config was not the one being enforced.
     //
-    // Applied on the same optimistic terms as the field types above, and put
-    // back by the same undo, so a reload that is abandoned leaves the retained
-    // config's functions in force.
-    const {
-      registerFieldFunctions,
-      snapshotFieldFunctions,
-      restoreFieldFunctions,
-    } = await import("../shared/lib/field-level-registry");
-    const previousFieldFunctions = snapshotFieldFunctions();
-    reloadUndo.push(() => restoreFieldFunctions(previousFieldFunctions));
-    for (const collection of newConfig?.collections ?? []) {
-      const slug = (collection as { slug?: string }).slug;
-      const fields = (collection as { fields?: unknown[] }).fields;
-      if (slug && Array.isArray(fields)) {
-        registerFieldFunctions("collection", slug, fields);
-      }
-    }
-    for (const single of newConfig?.singles ?? []) {
-      const slug = (single as { slug?: string }).slug;
-      const fields = (single as { fields?: unknown[] }).fields;
-      if (slug && Array.isArray(fields)) {
-        registerFieldFunctions("single", slug, fields);
-      }
-    }
+    // Staged here and installed by `commitReload`, the same boundary the
+    // config's hooks and the retention policies are published from. A reload
+    // whose DDL succeeds and whose metadata sync then fails does not commit,
+    // and a rule from a config the process refused must not be the one
+    // deciding writes in the meantime.
+    const { replaceFieldFunctions } = await import(
+      "../shared/lib/field-level-registry"
+    );
+    const fieldFunctionSources = [
+      ...(newConfig?.collections ?? []).map(entity => ({
+        kind: "collection" as const,
+        slug: (entity as { slug?: string }).slug ?? "",
+        fields: (entity as { fields?: unknown[] }).fields ?? [],
+      })),
+      ...(newConfig?.singles ?? []).map(entity => ({
+        kind: "single" as const,
+        slug: (entity as { slug?: string }).slug ?? "",
+        fields: (entity as { fields?: unknown[] }).fields ?? [],
+      })),
+    ];
+    commitFieldFunctions = () => replaceFieldFunctions(fieldFunctionSources);
   } catch (err) {
     // The registry was rebuilt from the config that just failed; put the
     // working set back so the retained config keeps the behavior it was
@@ -1621,6 +1627,7 @@ async function applyReload(opts?: {
     if (committed) return;
     committed = true;
     commitConfigHooks();
+    commitFieldFunctions?.();
     // Published here rather than when the file is read. A reload that is later
     // refused still parsed a valid config, and publishing early would leave a
     // policy the process explicitly rejected in force — deleting on windows
diff --git a/packages/nextly/src/shared/lib/__tests__/field-functions-replace.test.ts b/packages/nextly/src/shared/lib/__tests__/field-functions-replace.test.ts
new file mode 100644
index 0000000000..1490a466f0
--- /dev/null
+++ b/packages/nextly/src/shared/lib/__tests__/field-functions-replace.test.ts
@@ -0,0 +1,80 @@
+/**
+ * The field-function registry is REPLACED from the config in force.
+ *
+ * A reload re-reads the config and installs what it describes at the reload's
+ * commit point. Two things have to be true of that install. An entity the new
+ * config no longer declares must stop deciding anything: a collection dropped
+ * from `nextly.config.ts` keeps its registry row and its table so an orphan
+ * sweep can find them, so it stays addressable, and a rule left behind here
+ * would keep running. And nothing may be installed by a reload that does not
+ * commit, or a rule from a config the process refused would decide writes
+ * while every other service ran the previous one.
+ */
+import { describe, expect, it } from "vitest";
+
+import {
+  getFieldFunctions,
+  registerFieldFunctions,
+  replaceFieldFunctions,
+} from "../field-level-registry";
+
+describe("replaceFieldFunctions", () => {
+  it("drops an entity the new config no longer declares", () => {
+    registerFieldFunctions("collection", "kept", [
+      { name: "tone", type: "text", defaultValue: () => "before" },
+    ]);
+    registerFieldFunctions("collection", "removed", [
+      { name: "tone", type: "text", defaultValue: () => "gone" },
+    ]);
+
+    replaceFieldFunctions([
+      {
+        kind: "collection",
+        slug: "kept",
+        fields: [{ name: "tone", type: "text", defaultValue: () => "after" }],
+      },
+    ]);
+
+    expect(
+      getFieldFunctions("collection", "kept")?.tone?.defaultValue?.({})
+    ).toBe("after");
+    // Not merely stale: absent, so nothing of it runs.
+    expect(getFieldFunctions("collection", "removed")).toBeUndefined();
+  });
+
+  it("keeps the kinds apart", () => {
+    replaceFieldFunctions([
+      {
+        kind: "collection",
+        slug: "shared",
+        fields: [{ name: "tone", type: "text", defaultValue: () => "coll" }],
+      },
+      {
+        kind: "single",
+        slug: "shared",
+        fields: [{ name: "tone", type: "text", defaultValue: () => "single" }],
+      },
+    ]);
+
+    expect(
+      getFieldFunctions("collection", "shared")?.tone?.defaultValue?.({})
+    ).toBe("coll");
+    expect(
+      getFieldFunctions("single", "shared")?.tone?.defaultValue?.({})
+    ).toBe("single");
+  });
+
+  it("installs nothing for an entity that declares no functions", () => {
+    registerFieldFunctions("collection", "plain", [
+      { name: "tone", type: "text", defaultValue: () => "x" },
+    ]);
+    replaceFieldFunctions([
+      {
+        kind: "collection",
+        slug: "plain",
+        fields: [{ name: "tone", type: "text" }],
+      },
+    ]);
+    expect(getFieldFunctions("collection", "plain")).toBeUndefined();
+  });
+});
diff --git a/packages/nextly/src/shared/lib/__tests__/field-functions-snapshot.test.ts b/packages/nextly/src/shared/lib/__tests__/field-functions-snapshot.test.ts
deleted file mode 100644
index 8e6a958be6..0000000000
--- a/packages/nextly/src/shared/lib/__tests__/field-functions-snapshot.test.ts
+++ /dev/null
@@ -1,61 +0,0 @@
-/**
- * The field-function registry can be snapshotted and put back.
- *
- * A config reload re-registers from the newly read config before it knows the
- * reload will land, on the same optimistic terms as the field-type registry.
- * A reload that is then abandoned has to leave the retained config's functions
- * in force: an access rule from a config that never took effect must not be
- * the one deciding writes.
- */
-import { describe, expect, it } from "vitest";
-
-import {
-  getFieldFunctions,
-  registerFieldFunctions,
-  restoreFieldFunctions,
-  snapshotFieldFunctions,
-} from "../field-level-registry";
-
-describe("snapshotFieldFunctions / restoreFieldFunctions", () => {
-  it("puts back what was registered, and drops what the abandoned run added", () => {
-    registerFieldFunctions("collection", "kept", [
-      { name: "tone", type: "text", defaultValue: () => "before" },
-    ]);
-    const snapshot = snapshotFieldFunctions();
-
-    // What an abandoned reload would have done: change one entity and add one.
-    registerFieldFunctions("collection", "kept", [
-      { name: "tone", type: "text", defaultValue: () => "after" },
-    ]);
-    registerFieldFunctions("collection", "added", [
-      { name: "tone", type: "text", defaultValue: () => "new" },
-    ]);
-    expect(
-      getFieldFunctions("collection", "kept")?.tone?.defaultValue?.({})
-    ).toBe("after");
-    expect(getFieldFunctions("collection", "added")).toBeDefined();
-
-    restoreFieldFunctions(snapshot);
-
-    expect(
-      getFieldFunctions("collection", "kept")?.tone?.defaultValue?.({})
-    ).toBe("before");
-    // The entity the abandoned run introduced is gone, not merely stale.
-    expect(getFieldFunctions("collection", "added")).toBeUndefined();
-  });
-
-  it("is a copy, so registering after the snapshot does not change it", () => {
-    registerFieldFunctions("collection", "copied", [
-      { name: "tone", type: "text", defaultValue: () => "one" },
-    ]);
-    const snapshot = snapshotFieldFunctions();
-    registerFieldFunctions("collection", "copied", [
-      { name: "tone", type: "text", defaultValue: () => "two" },
-    ]);
-
-    restoreFieldFunctions(snapshot);
-    expect(
-      getFieldFunctions("collection", "copied")?.tone?.defaultValue?.({})
-    ).toBe("one");
-  });
-});
diff --git a/packages/nextly/src/shared/lib/field-defaults.ts b/packages/nextly/src/shared/lib/field-defaults.ts
index 96785d49fa..23becbc6f5 100644
--- a/packages/nextly/src/shared/lib/field-defaults.ts
+++ b/packages/nextly/src/shared/lib/field-defaults.ts
@@ -62,14 +62,31 @@ const NON_COLUMN_TYPES: ReadonlySet<string> = new Set(fieldGroupFieldTypes);
 export function applyFieldDefaults(
   data: Record<string, unknown>,
   fields: readonly ValidatableField[],
-  functions?: DefaultFunctions
+  functions?: DefaultFunctions,
+  /**
+   * What a FUNCTION default reads, when that is not the record being filled.
+   *
+   * A function default receives the document built so far, and on a create
+   * that document still holds every value the caller sent, including one a
+   * field rule denies them. The caller passes a filtered view here so a
+   * default cannot read a value its writer was not allowed to send, while the
+   * record being filled keeps that value for the authoritative access pass to
+   * remove. Filtering the record itself instead would delete the value before
+   * the defaults that decide whether it is allowed have run at all.
+   *
+   * Defaults to the record, which is right wherever there is nothing to hide.
+   */
+  view?: Record<string, unknown>
 ): void {
+  const readFrom = view ?? data;
   for (const field of fields) {
     // A layout container (row, tabs, collapsible) groups fields visually
     // without holding a value: its children are stored on the parent, so they
     // are filled against the same object.
     if (!field.name) {
-      if (field.fields) applyFieldDefaults(data, field.fields, functions);
+      if (field.fields) {
+        applyFieldDefaults(data, field.fields, functions, readFrom);
+      }
       continue;
     }
     if (NON_COLUMN_TYPES.has(field.type)) continue;
@@ -92,7 +109,7 @@ export function applyFieldDefaults(
       // values the caller did supply, and earlier defaults in this same pass.
       data[field.name] = cloneDefault(
         typeof declared === "function"
-          ? (declared as (d: Record<string, unknown>) => unknown)(data)
+          ? (declared as (d: Record<string, unknown>) => unknown)(readFrom)
           : declared
       );
     }
@@ -103,9 +120,9 @@ export function applyFieldDefaults(
     // before it runs or a required child fails on an entry the caller could
     // not have satisfied.
     if (field.type === "group") {
-      fillGroup(data, field.name, field.fields, own?.fields);
+      fillGroup(data, field.name, field.fields, own?.fields, readFrom);
     } else if (field.type === "repeater") {
-      fillRepeaterRows(data, field.name, field.fields, own?.fields);
+      fillRepeaterRows(data, field.name, field.fields, own?.fields, readFrom);
     }
   }
 }
@@ -143,8 +160,11 @@ function fillGroup(
   data: Record<string, unknown>,
   name: string,
   fields: readonly ValidatableField[],
-  functions: DefaultFunctions | undefined
+  functions: DefaultFunctions | undefined,
+  /** The parent's view; a child reads the view's matching container. */
+  view?: Record<string, unknown>
 ): void {
+  const childView = isPlainObject(view?.[name]) ? view[name] : undefined;
   const existing = Object.prototype.hasOwnProperty.call(data, name)
     ? data[name]
     : undefined;
@@ -154,7 +174,7 @@ function fillGroup(
     // A shallow copy per level is enough, because each level down copies again
     // before it writes.
     const filled = { ...existing };
-    applyFieldDefaults(filled, fields, functions);
+    applyFieldDefaults(filled, fields, functions, childView);
     data[name] = filled;
     return;
   }
@@ -163,7 +183,7 @@ function fillGroup(
   if (existing !== undefined) return;
 
   const seeded: Record<string, unknown> = {};
-  applyFieldDefaults(seeded, fields, functions);
+  applyFieldDefaults(seeded, fields, functions, childView);
   if (Object.keys(seeded).length > 0) data[name] = seeded;
 }
 
@@ -178,17 +198,26 @@ function fillRepeaterRows(
   data: Record<string, unknown>,
   name: string,
   fields: readonly ValidatableField[],
-  functions: DefaultFunctions | undefined
+  functions: DefaultFunctions | undefined,
+  /** The parent's view; each row reads the view's row at the same index. */
+  view?: Record<string, unknown>
 ): void {
+  const viewRows = Array.isArray(view?.[name]) ? view[name] : undefined;
   const value = data[name];
   if (!Array.isArray(value)) return;
   // Rows are the caller's objects, so each one that gains a default is filled
   // through a copy and the list is rebuilt from the results.
   let changed = false;
-  const rows = value.map(row => {
+  const rows = value.map((row, index) => {
     if (!isPlainObject(row)) return row;
     const filled = { ...row };
-    applyFieldDefaults(filled, fields, functions);
+    const rowView = viewRows?.[index];
+    applyFieldDefaults(
+      filled,
+      fields,
+      functions,
+      isPlainObject(rowView) ? rowView : undefined
+    );
     changed = true;
     return filled;
   });
diff --git a/packages/nextly/src/shared/lib/field-level-registry.ts b/packages/nextly/src/shared/lib/field-level-registry.ts
index 980a22d664..c5180fad69 100644
--- a/packages/nextly/src/shared/lib/field-level-registry.ts
+++ b/packages/nextly/src/shared/lib/field-level-registry.ts
@@ -288,25 +288,40 @@ export function registerFieldFunctions(
   }
 }
 
+/** One entity's live config, for a wholesale registry replacement. */
+export interface FieldFunctionSource {
+  kind: EntityKind;
+  slug: string;
+  fields: unknown[];
+}
+
 /**
- * The whole registry as it stands, and the means to put it back.
+ * Rebuild the whole registry from the config that is now in force.
+ *
+ * Replacing rather than adding, because a reload can REMOVE an entity: a
+ * collection dropped from `nextly.config.ts` keeps its registry row and its
+ * table so an orphan sweep can find them later, so it stays addressable, and
+ * an entry left behind here would keep deciding its access, running its hooks
+ * and filling its defaults from a config that no longer declares it.
  *
- * A config reload re-reads the live config and re-registers from it, which has
- * to happen before the reload knows it will land: the same optimistic terms the
- * field-type registry and the config's hooks are applied on. A reload that is
- * then abandoned must leave the retained config's functions in force, or an
- * access rule, hook or default from a config that never took effect would be
- * the one deciding writes.
+ * Called at the reload's commit point, not when the new config is read. A
+ * reload that is refused after its DDL has run still parsed a valid config,
+ * and installing these early would leave a rule the process explicitly
+ * rejected deciding writes while every other service still ran the previous
+ * one.
  */
-export function snapshotFieldFunctions(): Store {
-  return new Map(store());
-}
-
-/** Put a {@link snapshotFieldFunctions} result back, discarding what is there. */
-export function restoreFieldFunctions(snapshot: Store): void {
+export function replaceFieldFunctions(
+  sources: readonly FieldFunctionSource[]
+): void {
+  const next: Store = new Map();
+  for (const source of sources) {
+    if (!source.slug || !Array.isArray(source.fields)) continue;
+    const map = collectFieldFunctions(source.fields);
+    if (map) next.set(key(source.kind, source.slug), map);
+  }
   const current = store();
   current.clear();
-  for (const [k, v] of snapshot) current.set(k, v);
+  for (const [k, v] of next) current.set(k, v);
 }
 
 export function getFieldFunctions(

From 3b8110a29706c8280ccd71241bcb690baf91d2b2 Mon Sep 17 00:00:00 2001
From: Mobeen Abdullah <mobeenabdullah@gmail.com>
Date: Sun, 13 Sep 2026 01:19:27 +0300
Subject: [PATCH 4/6] fix(nextly): the promote gate judges the draft the write
 commits (#1833)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* feat(builder): edit an instance's exposed link and visibility in the inspector (#1798)

* feat(builder): offer the site's components in the insert panel, placed as one linked node

The third tier of the palette, beside blocks and patterns. A component is
offered from the definitions a host supplies — read nothing, as the pattern
tier reads nothing — and placing one writes a SINGLE instance node carrying the
definition's id. Nothing of the definition's content is copied into the page;
the renderer inlines it at read time, which is what makes an edit to the
definition reach every page that placed it. That is the opposite promise from
a pattern's copy, so the tile says which: a visible badge for a sighted author
choosing between look-alikes, and the same promise leading the description a
screen reader hears after the name — not in the name, which stays exactly the
visible label so a spoken command matches what is written on the tile.

Placement is judged by the definition's ROOTS, through the rule patterns are
already judged by. The instance node's own type is not a registered block and
the nesting source answers "no restriction" for a type it cannot resolve, so
judging the node by its type would let a component whose root may only live
inside columns be placed at the page root — and render there.

Rows the palette has nothing to place for are skipped rather than refused: a
published definition saved without content, and a row holding something other
than a component. The kind check is pinned by a fixture that HAS roots, since
one without would be dropped by the empty-roots check first and the case would
pass whether or not the kind was ever read.

Click to place only, for now. The drag path judges a placement by one block
name, and a component is judged by its roots; giving it the instance type would
bypass that judgement, so it stays with the click path as a pattern does.

* feat(plugin-page-builder): component definitions reach the editor, and a placed one renders

The second half of placing a component. The builder could offer a component
and write an instance node for it, and the canvas then drew the
could-not-be-loaded marker: the renderer resolves an instance against a map of
definitions, and the editor handed it none — every definition read lived on
the served-page path. A component placed in the builder rendered on the site
and nowhere an author could see while editing.

The library route now carries the site's component definitions beside its
patterns, and the document comes from a BY-ID read rather than the listing.
That is the point, not a detail: the working-draft overlay lives in the
service's by-id path and nowhere else, so a definition built from the listing
would show an author a stale component beside the draft they just saved — a
defect this repository has fixed once already on the served-page path. The
plugin-facing collection service forwards no draft flag on its by-id read, so
the route binds the Direct API's `findByID({ draft: true })` as the user:
access rules decide what the caller may read, and the overlay is gated on the
caller being allowed to edit, so a reader who may only read sees the live one.

Two readers with different timing share the one route. The insert panel reads
the whole library only while it is open, as before. The canvas needs
definitions on every editor mount, and the pattern tier can run to the whole
byte ceiling, so a `tier=components` query narrows the read the editor makes
on mount. The route's paging walk and its admission under the ceiling are one
implementation for both tiers, each handing in only how a listed row becomes an
item; the two tiers spend one ceiling, patterns first.

The editor reads the tier once and hands the same response to both consumers:
the canvas gets a map by id, the panel a list — so the tile an author places
is built from the very document the canvas then resolves the instance against.

* fix(plugin-page-builder): definitions are read as the user, on their own route, at every state

The component tier moves from a `?tier=` query on the pattern library to
`GET …/library/components`, gated by the components collection's read
permission and answering the canonical `{ items, meta }` envelope. One
walk and one admission still serve both routes; a tier is a completion
function and a permission, not a copy of the loop.

Both component reads now say `overrideAccess: false`. `requireNextly()`
defaults every call to `true`, under which naming a `user` narrows
nothing: the by-id read overlaid the working draft without the
update-capability probe and skipped every field-level read rule, so an
author who could only read a component was handed its pending draft. The
listing asks for `status: "all"` — the plugin-facing service forwards no
lifecycle scope, and an untrusted read that states none is bounded to
public states, so a never-published component could not be placed on a
draft page. An API key's own scope travels on both reads.

`LibraryComponent` extends `SavedComponent`, and the client hands the
rows to the panel as received; a type test pins that the wire carries
every key the panel reads.

`pageRenderInputs` demands `definitions`, and the entry form's resting
render reads the component library too, so a placed component stays
drawn in the miniature after Done rather than becoming the
could-not-be-loaded marker.

The panel resolves each definition through the canvas's own lookup
before offering it: a root that is itself an instance is judged by what
it draws, and one the resolver had to leave standing is withheld. And
the panel says, in a status region above the tiles, when the library was
too large to load whole — naming the tier, and for components what a
left-out one looks like on the page.

* feat(builder): a selected component instance opens its own inspector, over its exposed properties

An instance's type is not in the block registry, so the block inspector
answered "select a block" to an author who had just clicked a
component. `inspectInstance` now describes the selection — the
library's title and usage for the definition, the node's own name and
lock, and one row per exposed property read back from the resolver's
own result, so a row shows what the page shows: the value in force,
which layer supplied it, whether it was cleared, and which exposure
shadows it when one does. Values stored for properties the definition
no longer exposes are carried separately, and only those this instance
holds.

`InstanceInspectorPanel` draws that in place of the tabs: text and
choice rows edit in place, an emptied text field clears the property
with the `$unset` sentinel rather than writing `""`, every override
carries a visible Reset that removes it (and drops the record with its
last entry, never writing an empty one), rows of a type with no control
yet show their value and say so, and the orphaned values are listed
with a Discard. `overridesPatch` writes the whole props object so
`componentId` survives every edit.

The name and lock fields move to `identity-fields.tsx` so both
inspectors draw one control, and every text field's draft follows the
stored value through one `useStoredDraft`. `InspectorPanel` takes the
host's component library as ONE prop — the lookup the canvas resolves
against and the rows that name the definitions — and the editor hands
it the same read the canvas gets.

* fix(plugin-page-builder): the component read overlaps, reaches drafts, and says when it failed

Every component's completion was a database round trip awaited one
after another — three thousand in a row at the library's ceiling. The
walk now completes rows in batches of eight, admitted in listing order
so the ceiling cuts the same rows it always did, and starts no batch
once it has.

The by-id read asks for `status: "all"` as the listing does: an
untrusted read that states nothing is bounded to public states, so the
never-published row the listing found answered 404 and the component
stayed unplaceable until published. The Direct API's `findByID` did not
forward `status` at all — a caller passing it was silently ignored — so
it does now, with `FindByIDArgs.status` declared and pinned by a test.

Every field of an item now comes from the by-id row, the one with the
working draft overlaid: a draft can rename a component or move it to
another category, and an item labelled from the live listing was named
by one version and drawn from another.

The identity the reads run as is built by `buildUserContext`, now
exported from `nextly/runtime` — the one builder of the user an access
rule is evaluated against — so the caller's verified claims travel and
the canonical identity wins. Roles are not on the route context; the
service resolves them from the account.

The component read's `pending`, `error` and `refetch` no longer vanish
behind an empty map. The canvas and the resting miniature wait for the
read and say when it failed, with a Try again; the insert panel tells a
tier that was cut from one that could not be read, and offers the retry.

The palette resolves a definition under the site's own document caps,
handed through `documentLimits`, and withholds one whose root resolves
to an empty forest.

* fix(plugin-page-builder): a failed component read no longer takes the canvas away

The component route refuses a role that may edit pages but not read
components, and the gate added for a pending read treated that failure
the same way — a least-privilege page editor lost the canvas for every
page, block-only pages included, and the resting card refused to
preview them. Only a PENDING component read gates now; a failed one
draws the page with its instances as could-not-be-loaded and says so
beside the canvas and beneath the miniature, with the retry.

A component's own content field no longer offers the definition it is
editing: placed, that instance points at the definition it sits in, and
the resolver draws the loop as a cycle after the save. `withoutSelf`
judges it on the opening document being a component and the form naming
the row — a page's field is never inside a component, and a create form
names no row.

Placing a component now asks the resolver whether the PAGE has room for
it, with the node in place: the apply counts stored nodes and an
instance is one, but the composed tree spends one budget across every
expansion, so a page near its cap accepted the node and rendered it
unresolved. `compositionRefusal` composes the candidate document under
the site's caps and turns a `budget` or depth reason into a sentence
the panel raises as a notice, leaving reasons that are the tile's
concern alone.

* fix(builder): the style trace composes instances through the definitions the canvas draws with

The builder's trace wrapper forwarded the site tier, the fetch policy,
the resolver and the caps to the renderer's trace, and not the
definitions — so on a page holding instances the cascade the inspector
reads its provenance from described a tree with every instance left
unresolved, while the canvas drew the composed one. The wrapper takes
the map and the editor hands it the canvas's own.

* fix(builder): a choice exposure with an empty option no longer crashes the inspector

The validator accepts an empty string as an option value — a "none"
beside class names — and the select control throws at render on an
item whose value is the empty string, which it reserves for no
selection. The empty value wears a NUL sentinel in the control and is
taken off again on the way back to the document, so the option is
offered and written as empty.

* fix(builder): judge a component's room under the site's limits, for every instance left standing

The insert preflight composed the candidate page the way the canvas does,
but dry-ran the insert itself under the engine's default limits, so a page
legal only under a raised cap threw out of the click before the resolver
ran; and it refused only when the PLACED instance was left unresolved, so
a nested instance the page had no room for, or an instance already on the
page that the new one took the budget from, was placed and drew a
placeholder.

The dry run now takes the same limits the composition does, a refusal the
apply itself makes is left to the editor's apply, and the refusal reads
every room-reason instance the placement introduces — compared against the
page composed without it, since an instance the page could not hold before
the click is not the click's doing.

* fix(builder): say when a library tier could not be reloaded, apart from one never read

A host that reads its library afresh on every open keeps the last answer
while it does, so a failed read can leave tiles standing — and beside them
"none are offered" was false. A stale tier gets its own sentence: the tiles
offered may be out of date, and a component on the page draws as it was.

* fix(plugin-page-builder): keep the definitions map still across renders, and name a failed refresh

The component read memoised its map and list on the route hook's refetch
wrapper too, which the hook mints per render, so the canvas was handed a
new map — and re-resolved every instance — on every render, keystrokes
included. The map and the list are now derived from the data alone, and the
retry keeps one identity for the life of the hook.

And a read that answered once and then failed to answer again was called
ready: the cached definitions drew with no sentence and no retry. Both
library reads now tell that state apart as `stale` — the page still draws,
from an answer an edit elsewhere may have overtaken — and the canvas note,
the entry card and the insert panel say so with the retry, rather than the
never-read sentences, which are false beside tiles that stand.

* fix(plugin-page-builder): leave out every component that reaches the one being edited

A component's content field left out only the row it was editing, so a
component holding an instance of that row — or one holding that — was still
offered, and placing it closed a loop nothing sees until the row is saved.
Every candidate is now resolved through the canvas's own lookup, and one
that reaches the row being edited at any depth is left out.

* fix(plugin-page-builder): count the classes linked components render on the page

The classes manager's on-this-page filter walked the stored document, where
a linked component is one instance node, so a class applied inside the
definition the canvas draws was missing from the filter. The walk now
composes through the same map the canvas draws with, under the same limits;
the usage record still asks what the document itself references.

* fix(plugin-page-builder): list components in pages of one completion batch

Every listed component is read again by id, so the listing's content is
never used — and the service reads whole rows however a caller narrows the
answer. A page of a hundred rows held while its batches completed was a
hundred documents of content in memory at once. The component listing now
pages by one completion batch, and the bound on reads is derived per tier
from its page size so the tier still reaches the item ceiling.

* fix(builder): offer the reset on the row that holds the override, not on the row it shadows

Two exposures aimed at one target share a value, and the resolver reports
the winning exposure's source on both — so a reset keyed on the source
stood on the shadowed row too, and pressing it removed nothing. Each row
now carries whether THIS instance's record holds a value under its id, and
the reset is offered on that.

* fix(builder): judge a moved component instance by the roots of the definition it draws

A pointer move judged the dragged node by its type, and an instance's type is
not a registered block, so the nesting rule answered "no restriction": a
component whose root belongs only inside a Columns, refused at the insert,
could be dragged into a paragraph afterwards. The drop query now carries the
types the placement is judged by — a block's own, or an instance's resolved
roots through the canvas's lookup under its caps — and the editor hands the
drag the same map and caps the canvas draws with.

* fix(builder): read an instance's definition under the resolver's own rule, published from the engine

The inspector judged a supplied definition by its kind alone, where the
resolver also refuses a format this build does not read and a list of nodes
that is not one. A definition the canvas left standing as a placeholder
therefore drew editable rows, and malformed nodes reached the exposure. The
engine now publishes `readableDefinition`, the rule the resolver applies
before inlining, and the inspector reads through it.

* feat(builder): edit an instance's exposed link and visibility in the inspector

Two more of the six exposed types get a control. A link exposure holds what
its url prop holds, a string, and is edited in the same field a url prop gets
in the block inspector, keyed for an address and clearing the property when
emptied. A visibility exposure is a checkbox writing `true` or `false` — the
two values the resolver reads there — with an inherited row reading as shown,
the component's own rule until the definition gates the node itself. Rich text
and image rows keep showing their value and source without a control.

* fix(plugin-page-builder): read components from the store the plugin was told they live in

A host may keep its definitions in a collection of its own and render from
it (`createBlocksPage`'s `componentCollection` and `componentField`), and the
plugin already lets the readiness notice follow that store through
`componentReadiness.collection` and `.field`. The editor's library route
read the plugin's own store regardless, so it drew a different definition
for the same id than the page did, or none. One derivation of the store now
feeds the route, its permission gate and the notice; a host whose
definitions come from no collection at all still gets the plugin's store,
which is the one thing a collection read can follow, and the option says so.

* fix(plugin-page-builder): build the editor under the site's caps, as the preflight and canvas are

The editor was built with no limits and so judged every apply under the
engine's defaults, while the insert's preflight and the canvas judged under
the site's. On a site that raised its cap, a placement the preflight and the
canvas accepted was refused silently by the apply. The caps are read once,
before the editor is built, and handed to it.

* fix(builder): read a tile's roots without composing its definition

The palette judged where a component may be placed by composing the whole
definition through the canvas's lookup and reading the roots of the result,
once per catalogue row, so a library of small wrappers around one large
definition cloned that definition once per wrapper every time the panel
opened — three thousand one-node wrappers around a five-thousand-node
definition was fifteen million nodes. The engine now publishes
`composedRootTypes`, which follows a root instance into the definition it
names through the resolver's own reader and its own four refusals, reading
each definition once and cloning nothing; the tile, the moved-instance rule
and the component's own field's exclusion all read through it or through
the stored graph. Room stays the click's question, asked of the resolver
with the page in hand.

* fix(builder): preflight a moved instance for room, and judge every edit under the editor's own caps

A move applied without asking whether the page still composed with the node
there: an instance carried ahead of another takes the budget that one had,
and one carried into another's slot content nests a composition deeper, so
the drop left a placeholder where a component stood. The preflight now takes
an op rather than a placed node, the drop asks it for a move and says why
when it refuses, and the caps it asks under are the editor's own — exposed
on the editor state, since they are the ones its apply enforces — which the
insert panel now reads too in place of a second reading handed in as a prop.

* feat(nextly,plugin-sdk): a plugin route resolves the caller's identity once, roles included

`PluginRouteCaller.identity()` resolves `readCaller(auth)` once per request —
the user context with the roles a stored read rule reads, its claims, and an
API key's scope — and `can()` reads through the same memo. The SDK publishes
`PluginRouteIdentity` as its answer.

A route that built its Direct API user from `ctx.user` carried no roles, so a
role-based read rule on the collection it read refused the very caller the
route's own gate had admitted, and the caller saw an empty library with
nothing to say why. The `nextly/runtime` export of `buildUserContext` added
for that route is gone again: the identity is the caller's to give.

* fix(nextly): findByID on users offers no status argument

`FindUserByIDArgs` omits `status` beside `collection` and `draft`. The users
read has no lifecycle scope to narrow by, and an argument the call accepts
and ignores reads as one it honours. Pinned by a type test the checker
evaluates (`users.test-d.ts`, under `tsconfig.tests.json`), with `depth` as
the control that still is offered.

* fix(blocks-engine,builder): the tile offers only a definition the resolver would read

The engine publishes `readableDefinition`, the resolver's own rule for a
supplied definition — a plain record whose nodes are a list, of kind
`component`, in this build's format — and `offerableDefinition` reads
through it, so the tile and the canvas read one rule.

Judged by kind alone, a definition in a format this build does not read was
offered, placed and drawn as a placeholder; one whose nodes were not a list
crashed the catalogue on `.length`.

* fix(plugin-page-builder): the style trace compiles under the canvas's caps

`pageStyleTrace` takes `canvasRender.limits` beside the canvas's definitions,
so the cascade the inspector reads describes the composed tree on screen —
neither one with every instance left unresolved, nor one composed past a cap
the canvas stopped at. Handed the map alone, the trace defaulted to the
engine's caps and reported declarations for nodes the canvas drew as a
placeholder.

* fix(plugin-page-builder): the component tier reads as the caller, failing on all but a missing row

`directComponentReads` reads through `caller.identity()` on both reads —
the user context with the roles a stored read rule reads, the verified
claims, and an API key's own scope — so a role-based read rule sees the
roles the route's gate resolved rather than an identity built from the
account alone, which carried none and refused the caller the gate admitted.

The by-id read no longer asks for `disableErrors`. It catches only not-found
and forbidden — a row gone between the two reads, or one THIS caller may not
read, which the walk reports as a cut library — and lets anything else fail
the route, which the client reports as unavailable with a retry. Swallowed,
a database fault read as a static ceiling with every instance on the page
drawn as missing and nothing to retry.

* fix(plugin-page-builder): a library row without a title is labelled by its id rather than dropped

A page's renderer keeps a component by its id and its document field; a
custom collection with no title field, or one whose title is redacted by
field-level access, renders every instance on the public page. The editor
dropped such rows — omitted from the component tier, counted as a cut —
and drew a placeholder where the page draws the component.

`identityOf` requires an id alone; a title only labels the row, and one
without a readable title is labelled by its id, the one name a row is sure
to have. One reader for both tiers, as before.

* fix(builder,plugin-page-builder): room is judged at the editor's apply; the host owns the notices

`useEditorState({ definitions, onRefused })` asks, after a fresh group
applies (`apply` and `applyAll` alike, never an undo or a redo), whether the
page still composes with the edit in — `compositionRefusal(before, after,
definitions, limits)` compares the resolver's unresolved sets by instance id
— and refuses with the sentence, committing nothing. The insert panel's and
the drag's own preflights are removed: every surface reaches the page through
this apply, so a duplicate, a paste, a pattern and a keyboard move are judged
exactly as a drop is, and no surface can forget to ask.

`BuilderShell` takes the host's `NoticeQueue`, and `useNoticeQueue`,
`NoticeQueue` and `RaiseNotice` are published from the shell entry. The
shell provides its sink only to what it renders, and the editor is built
above it, so a raise made there reached nothing in production; the host
builds the queue, hands it to the shell to draw, and raises into it.

* fix(builder,plugin-page-builder): a keyboard move judges an instance by the roots it draws

`nestingRefusalForMove` asks `placementVerdict(placementTypesOf(moving,
definitions), …)` — the function and the types a drop is judged by —
where it asked `blockAllowedAt(moving.type, …)`. An instance node's own type
is not a registered block, so the nesting rule restricted it nowhere, and
Alt+Arrow, the toolbar and the command palette could lift a component whose
root belongs only inside a container up to the root, where the same
instance's drop is refused.

`BlockKeyboardActions` takes the definitions the canvas draws with, as it
takes `nesting`, and the page-builder field passes its map. Without one an
instance is judged by its own type, which is how a placeholder stays movable.

* fix(plugin-page-builder): what a candidate reaches is read under the site's cap, failing closed

`withoutSelf` leaves out of a component's own field every component whose
stored graph reaches the one being edited. The walk read each definition with
`componentIdsIn` — the engine's default node cap, and no word on whether the
read was whole — so under a site cap other than the default, or a definition
longer than the cap, it answered a prefix, and a candidate whose reference
sat past it was cleared and could close a loop once saved.

Every read in the walk now goes through `componentUsageIn` under the SITE's
`maxNodes`, and a read the cap ends early counts as reaching: the candidate
is left out. That refuses no legitimate offer — a definition the cap cannot
read whole is one the resolver cannot inline under that cap either — and it
is the direction to err in, because the other is a saved loop every page
then draws as a placeholder.

* fix(blocks-engine,builder): composed root types are distinct and each definition is walked once

`composedRootTypes` walked a definition once per instance pointing at it and
concatenated the answers, so a definition of two hundred instances of another
holding two hundred more answered forty thousand roots, and walked the leaf
as many times — on every insert-panel open, for every component in the
library.

It now answers the DISTINCT types at the composed roots, in the order first
met, which is all `placementVerdict` reads, so the tile and the drop are
judged as before and the answer is bounded by the registry rather than the
forest. And it remembers each definition's answer for the query, reused at
the same depth or a shallower one only: the composition cap refuses by depth,
so what fit under an instance at depth one can be refused under one at depth
four. A refusal is never remembered — a cycle or the cap is a property of
where an instance sits — and the resolver's own refusals are still asked
first, per instance.

* fix(plugin-page-builder): the component tier is read in the language the document is edited in

A component's document field can be localized, and the public renderer reads
definitions in the page's locale; the editor's read named none, so an author
editing German drew a canvas of English components, and the resting
miniature too, from one locale-independent cache entry.

`useComponentLibrary` reads the surrounding form's `useDocumentLocale()` and
asks for `componentLibraryPath(code)`: `?locale=<code>` for a non-default
language, the bare path for the default or where the language cannot be
known — how an absent `?locale=` reads everywhere in the admin. The path is
the read hook's cache key, so a switch of language is a different read. The
route reads the parameter, spelled once in the shared contract, into BOTH
Direct API reads: a listing in one language completed by rows in another
would label one version and draw the other. An empty value is none, and an
unknown code resolves to the default in the Direct API.

The changeset now describes the caller's resolved identity, the title rule
and the locale, and no longer the `nextly/runtime` export this branch had
added and then removed.

* refactor(builder): the editor's room check is its own function, and its undo case can fail

The room question moves out of `run` into `refusedForRoom`, which asks
only when definitions were given and tells the host why when it refuses;
`run` keeps one condition, a fresh edit. One branch fewer took `run` back
under the complexity bound the audit holds this package to.

Re-breaking it showed the undo-and-redo case could not fail: the library
never changed between an edit and its replay, so a replay asked the room
question would have been allowed anyway. The library now grows between them
— a definition of three nodes becomes ten, which no longer fits — and a
fresh insert under the grown library is the control that refuses. Asking on
undo, on redo, or on both now fails the case.

* refactor(blocks-engine): a definition's remembered root types are read by their own function

`rootTypesOfNode` keeps the resolver's refusals — a malformed or gated
instance, a missing or unreadable definition, a cycle, the cap — and hands
the rest to `definitionRootTypes`, which serves an answer already given at
the same depth or a deeper one, or walks the definition and remembers it.
One branch fewer took the function back under the complexity bound the
audit holds this package to; the four ways the memo can be wrong — never
remembering, remembering across depths, answering before the refusals, and
answering the forest's width — each still fail a named test.

* fix(builder): the instance inspector reads a malformed instance and a definition's options safely

Every read of an instance's props goes through one guard, as the resolver
reads them: a stored instance whose `props` is missing or not a record — an
import, a hook, a hand edit — is drawn on the canvas as a malformed
placeholder, and selecting it threw on `node.props.componentId` where it now
reads as naming no component. The override patch spreads the same guarded
record.

A row's `options` and `label` are normalised where they are consumed. The
resolver checks the fields its own writer reads — id, node, path, type — so
a stored or hook-shaped definition could hand the panel options that were
not a list (`row.options.map` threw on selection), entries without a string
value, a value offered twice (one choice drawn twice under one key), or a
label that is an object. Options keep string values and labels, each value
once; a label that is not a string reads as the property's id.

* fix(builder): the instance panel spells each option apart and says what a structured value holds

Every option value wears a one-character prefix in the select control,
where only `""` wore a NUL sentinel. The control cannot take `""` — the
primitive reserves it for "no selection" — but a definition's option is free
text, so a sentinel for one value collides with the option that IS the
sentinel: the two items shared one value, the control drew the later of them
for either, and choosing one while the other was held changed nothing. A
prefix on every value is injective and never empty.

A read-only row and an orphaned override now summarise a structured value
instead of reading it through the text field's reader, which turned a value
that is there into the same nothing as one that is not: rich text as its
words through the engine's reader, a list by its count, other data as its
JSON, a cleared override as "(cleared)".

* fix(builder): a rename that differs only in spaces hands the field back the stored name

The name field compared a trimmed draft with the stored name and, when they
matched, returned — leaving the field showing a draft with spaces the
document does not hold. It now trims once, compares and stores the same
value, and hands the field the stored name back when nothing changes. The
field is the one both inspectors draw, so the block inspector's name
behaves the same; the comparison moved here from it unchanged.

* refactor(builder): the instance inspector's small text uses the type-scale token

Three font sizes in the instance inspector's rules were written as
`0.75rem` where the rest of the stylesheet names `var(--text-xs)`, the
theme's step of exactly that size — so the rendering is unchanged and the
rules follow the scale if it moves.

* fix(builder): a component is offered only when the canvas holds its definition, judged by that copy

`componentEntriesFrom` judged and previewed a tile from the row's own
document, while the placed instance is resolved by the canvas against its
lookup. A host of the published `InsertPanel` that passed `components`
without `componentDefinitions` was offered tiles whose every placement
landed as a missing component; and a row whose copy differed from the
lookup's was judged by roots the canvas does not draw. The offer now reads
the lookup's definition for the row — the drag and the keyboard already
judge a placed instance through the lookup — and a row the lookup does not
hold is not offered. The row still supplies the label, category and usage.

* fix(plugin-page-builder): a component's own field fails closed on a reference a cut library omits

The walk that keeps a component's own field from offering anything that
reaches it treated an id the canvas's lookup does not hold as a dead end.
From a library the ceiling or a permission cut, that id may be a component
the store holds and the read left out — and it may name the definition being
edited, so the candidate stayed offerable and a placement closed the loop
once saved. The field now passes whether its read was whole; out of a cut
library such an id counts as reaching and the candidate is left out, while
out of a whole one it is a component nobody supplied and names nothing.

`withoutSelf` takes the graph as one value (`ComponentGraph`: the lookup,
the site's caps, and whether the read was whole), and each walk starts from
the lookup's copy of the candidate, which is what the canvas draws.

* fix(blocks-engine): a root the inliner would drop stands for no type

`cloneDefinitionForest` skips a node it cannot clone — one that is not a
record, or whose id is not a string — so such a root never lands on the
page. `composedRootTypes` counted its type anyway, so a component was
offered, and refused, by a root the page never gets; one whose every root is
dropped was offered as placing something and placed nothing. The query now
passes over exactly what the inliner drops, and still answers nothing for a
root it keeps but cannot name.

* fix(builder): a pattern's roots are resolved through the lookup, as a component's are

A pattern is copied into the page as it stands, and one of its roots may be
a component instance — saving a placed component as a pattern stores exactly
that node. `rootsAllowedAt` judged the root's own type, which is not a
registered block and which the nesting source therefore restricts nowhere,
so a pattern wrapping a component whose root belongs only inside a Columns
was offered at the page root while the component's own tile was refused
there. Each root is now read through `placementTypesOf`, and the panel hands
its lookup to `allowedEntries`.

* fix(plugin-page-builder): a completed component keeps the id the listing named

The by-id read returns a PRESENTATION of the row — an `afterRead` hook may
rewrite or drop its `id` — while stored instances reference the id the
collection holds, which is the one the listing named. Completed from the
presentation, the client keyed its definitions by a name no instance uses,
or dropped the component, and every instance of it drew as missing. The
completion carries the listed id and takes the title, category, description
and content from the by-id row; a row with no readable title is still
labelled by that id, and a read that answered nothing is still a cut tier.

* fix(builder): every inspector control takes an id of its own, minted per mount

An exposed row's control and the block name and lock fields carried fixed
ids. A page can hold two blocks fields, each with its own editor, and both
labels then resolved to the FIRST editor's control: it carried two labels
and a doubled accessible name, while the second editor's input had none and
its label focused the other editor's field. Each control mints its id with
`useId`, so a label points at the control beside it.

The block inspector's own assertion no longer pins the literal id; it tells
the identity field from an attribute's by the placeholder only it has.

* fix(plugin-page-builder): a pattern that reaches the edited component is not offered

Saving a selection as a pattern keeps the instance nodes it held, so a pattern
is a second way to copy a component into itself. The component tier was
filtered and the pattern tier was forwarded whole, and the two tiers are
different rows out of different collections.

Both are now judged by one graph and one rule: which components a candidate
places, followed through the canvas's own lookup until the edited row is met.
A pattern nobody could read whole under the site's node cap is left out rather
than offered on an answer nobody has.

* fix(blocks-engine): a pattern's instances are judged by what they draw

`nextly/component-instance` is not a registered block, so every rule spelled
over node types answered wrong for it in both directions. A parent rule found
no restriction on the instance type and admitted a component whose root belongs
only inside a Columns. A slot naming what it admits did not name the instance
type, so every component was barred from every slot that lists its contents,
including the ones drawing exactly what the slot asks for — the tile was
offered and the click then planned nothing.

The rule the palette already used for a node's drawn types now lives in the
engine, beside the roots query it is built on, and the builder re-exports it.
The two pattern rules — the destination's placement and the forest's own
internal nesting — resolve through it whenever the caller holds a lookup, and
the panel hands the same lookup to the catalogue and to the planner. Callers
holding no library get the answer they got before.

* fix(blocks-engine): a nested instance's own overrides reach its definition's roots

`composedRootTypes` followed a root instance into its definition without asking
what that instance decided about the definition's nodes. A `visibility`
exposure overridden to false removes the node and its subtree from the composed
forest — `cloneDefinitionNode` returns nothing at all for it — so the query
reported a type the page never receives, and a component whose only root is
hidden was offered as placing something and placed nothing. Overridden to true
it deletes the node's own gate, so a gated root the author turned on is
expanded rather than left standing.

The decision comes from the resolver's own planner rather than a second reading
of `props.overrides`, so the chosen variant's presets are folded in under the
instance's answers exactly as the render folds them. A definition's remembered
roots are a property of the definition, so an instance that decides neither
reads that memo nor writes to it.

* fix(plugin-page-builder): a completed component must be the row the listing named, read whole

Two ways a by-id read answers with something that is not the component it was
asked for, both of which the completion took at face value.

A `beforeOperation` hook can redirect the read, so the record answering for one
component may be another's. Keyed by the listing's id, that row's draft was
served under the other component's name: the canvas drew one component's
content wherever the other was placed, with nothing anywhere saying so. A row
naming a different id is now left out and the tier reported cut. A row carrying
NO id is still keyed by the listing — field-level access drops it in
presentation, and that case is why the id comes from the listing at all.

And an absent document field was flattened into the same `null` as a
stored-empty one. The field layer writes an unset non-required field as SQL
NULL and reads it back with the key present, so `null` is an answer and a legal
row; no key at all means this caller did not read the row whole. Told apart,
the second marks the tier cut instead of reporting a complete library the
client has no definition for.

* fix(plugin-page-builder): the library is paged from a row, not from an offset

Both tiers walked their collection as independent offset queries against a
collection other authors are editing. A row inserted or deleted before the next
offset shifts every row after it, so one comes back twice and another never at
all — and a row never listed is never completed, so `omitted` stays false and
the response reports a whole library while the canvas has no definition for it
and draws every instance as missing.

The position is now the greatest id the last page named, and the next page is
the rows after it: ordered by id, that means the same thing however many rows
before it moved. What is left of the offset counts pages since the position
last MOVED, for the one page whose every row arrives without a readable id —
it names no position, and stepping past it is the only way to reach what is
behind it. A page that names an id resets it, so an ordinary walk never carries
an offset a mutation can move.

* fix(blocks-engine): the roots query survives a node whose own fields throw

The resolver composes a definition carrying a throwing property accessor
without raising; this query read the same fields with no boundary. Its one
caller builds the insert panel's catalogue, so a single such definition took
the whole panel down over a component the canvas draws.

The boundary is at the published entry point rather than per definition,
because the document's own roots are read by the same walk. Caught rather than
asked first, which is this module's usual answer to a stored shape: reading the
property IS the raise, so there is no question to ask before it. The answer is
`undefined` — the one already defined for a forest this cannot judge, and one
its callers already withhold the tile for.

* refactor: name the two questions each of these rules was asking

`withDraftDocument` asked three: is this the row that was asked for, was it read
whole, and what is it called. The first and third are now their own — and the
third was spelled twice, once here and once on the listing row, so an unnamed
component could have come to be called two things.

`rootTypesOfNode` asked what a root stands for and, for an instance, what its
definition draws. The second is its own function, reached once the first has
decided it is an instance at all.

Both were over fallow's CRAP bound, whose coverage is estimated and so cannot
be tested down; both are under it by branch count now.

* perf(plugin-page-builder): the resting card reads the component tier only when the page places one

The miniature every entry form draws at rest read the whole component tier on
mount, whatever the page held. That read is a listing over every row plus a
read of its own per row to reach the working draft, bounded at sixteen
mebibytes — so opening an entry whose page places no component paid for a
library it resolves nothing against and draws identically without.

The question is asked of the document, under the SITE's node cap, and an
unread prefix counts as placing one: a document past the cap answers
`complete: false`, and "names nothing" is what an unread document looks like
too, so the read is still made rather than the largest pages on a site drawing
as could-not-be-loaded markers.

A disabled read reports `ready` rather than `pending`. A query that never runs
never stops pending, and the card would have waited on an answer nobody asked
for.

* fix(blocks-engine): a visibility exposure reads the definition's own gate

With no override written, a `visibility` exposure reported nothing in force —
and something was. A definition node carrying entry-field conditions is not
served: `survivesGating` with no plan says so, and the composed forest keeps
the gate for the renderer's hidden-node pass to act on. Read as a blank, the
inspector drew the row checked and told the author the node was shown on this
page while the canvas withheld it.

The row now carries the definition's own decision, with `source: "definition"`
and no own override, so a surface can tell an inherited gate from an author's
own hiding without a vocabulary of its own. A node with no gate still reads as
nothing in force, because nothing is.

* test(builder): the visibility checkbox reflects a gate the definition itself carries

The rule is the engine's — a `visibility` exposure with no override now reads
the definition's own decision — and this is the surface it was wrong on: the
box drew checked and said the node was shown on this page while the renderer's
hidden-node pass withheld it. Asserted here as well as in the engine because
the panel is where an author reads it, and because the click that turns it on
writes the one value that removes the component's gate for this instance.

* fix(plugin-page-builder): gate a configured component store by the slug it reads

Two rules about a store the plugin was told about rather than owns.

The route resolved its permission through the scope helper, which follows the
host's rename of a collection the PLUGIN declared. The handler reads the
configured slug literally, so the two named different collections exactly when
a host renamed the contributed `components` collection and pointed the store at
another one called `components`: a caller holding read on the collection being
read was refused, and one holding read on the renamed collection was let into a
collection that permission says nothing about. The default store still resolves
through the helper, which is what a rename needs.

And a completed component now carries its `keywords`. `LibraryComponent`
derives from `SavedComponent`, and the catalogue builds a component tile's
search terms from that field exactly as it does a pattern's — through the same
reader here, so an absent field stays absent and a stored NULL arrives as
`null`, which is the shape the palette expects.

* fix(plugin-page-builder): a pattern that reaches the edited component is not offered

Saving a selection as a pattern keeps the instance nodes it held, so a pattern
is a second way to copy a component into itself. The component tier was
filtered and the pattern tier was forwarded whole, and the two tiers are
different rows out of different collections.

Both are now judged by one graph and one rule: which components a candidate
places, followed through the canvas's own lookup until the edited row is met.
A pattern nobody could read whole under the site's node cap is left out rather
than offered on an answer nobody has.

* fix(blocks-engine): a pattern's instances are judged by what they draw

`nextly/component-instance` is not a registered block, so every rule spelled
over node types answered wrong for it in both directions. A parent rule found
no restriction on the instance type and admitted a component whose root belongs
only inside a Columns. A slot naming what it admits did not name the instance
type, so every component was barred from every slot that lists its contents,
including the ones drawing exactly what the slot asks for — the tile was
offered and the click then planned nothing.

The rule the palette already used for a node's drawn types now lives in the
engine, beside the roots query it is built on, and the builder re-exports it.
The two pattern rules — the destination's placement and the forest's own
internal nesting — resolve through it whenever the caller holds a lookup, and
the panel hands the same lookup to the catalogue and to the planner. Callers
holding no library get the answer they got before.

* fix(blocks-engine): a nested instance's own overrides reach its definition's roots

`composedRootTypes` followed a root instance into its definition without asking
what that instance decided about the definition's nodes. A `visibility`
exposure overridden to false removes the node and its subtree from the composed
forest — `cloneDefinitionNode` returns nothing at all for it — so the query
reported a type the page never receives, and a component whose only root is
hidden was offered as placing something and placed nothing. Overridden to true
it deletes the node's own gate, so a gated root the author turned on is
expanded rather than left standing.

The decision comes from the resolver's own planner rather than a second reading
of `props.overrides`, so the chosen variant's presets are folded in under the
instance's answers exactly as the render folds them. A definition's remembered
roots are a property of the definition, so an instance that decides neither
reads that memo nor writes to it.

* fix(plugin-page-builder): a completed component must be the row the listing named, read whole

Two ways a by-id read answers with something that is not the component it was
asked for, both of which the completion took at face value.

A `beforeOperation` hook can redirect the read, so the record answering for one
component may be another's. Keyed by the listing's id, that row's draft was
served under the other component's name: the canvas drew one component's
content wherever the other was placed, with nothing anywhere saying so. A row
naming a different id is now left out and the tier reported cut. A row carrying
NO id is still keyed by the listing — field-level access drops it in
presentation, and that case is why the id comes from the listing at all.

And an absent document field was flattened into the same `null` as a
stored-empty one. The field layer writes an unset non-required field as SQL
NULL and reads it back with the key present, so `null` is an answer and a legal
row; no key at all means this caller did not read the row whole. Told apart,
the second marks the tier cut instead of reporting a complete library the
client has no definition for.

* fix(plugin-page-builder): the library is paged from a row, not from an offset

Both tiers walked their collection as independent offset queries against a
collection other authors are editing. A row inserted or deleted before the next
offset shifts every row after it, so one comes back twice and another never at
all — and a row never listed is never completed, so `omitted` stays false and
the response reports a whole library while the canvas has no definition for it
and draws every instance as missing.

The position is now the greatest id the last page named, and the next page is
the rows after it: ordered by id, that means the same thing however many rows
before it moved. What is left of the offset counts pages since the position
last MOVED, for the one page whose every row arrives without a readable id —
it names no position, and stepping past it is the only way to reach what is
behind it. A page that names an id resets it, so an ordinary walk never carries
an offset a mutation can move.

* fix(blocks-engine): the roots query survives a node whose own fields throw

The resolver composes a definition carrying a throwing property accessor
without raising; this query read the same fields with no boundary. Its one
caller builds the insert panel's catalogue, so a single such definition took
the whole panel down over a component the canvas draws.

The boundary is at the published entry point rather than per definition,
because the document's own roots are read by the same walk. Caught rather than
asked first, which is this module's usual answer to a stored shape: reading the
property IS the raise, so there is no question to ask before it. The answer is
`undefined` — the one already defined for a forest this cannot judge, and one
its callers already withhold the tile for.

* refactor: name the two questions each of these rules was asking

`withDraftDocument` asked three: is this the row that was asked for, was it read
whole, and what is it called. The first and third are now their own — and the
third was spelled twice, once here and once on the listing row, so an unnamed
component could have come to be called two things.

`rootTypesOfNode` asked what a root stands for and, for an instance, what its
definition draws. The second is its own function, reached once the first has
decided it is an instance at all.

Both were over fallow's CRAP bound, whose coverage is estimated and so cannot
be tested down; both are under it by branch count now.

* perf(plugin-page-builder): the resting card reads the component tier only when the page places one

The miniature every entry form draws at rest read the whole component tier on
mount, whatever the page held. That read is a listing over every row plus a
read of its own per row to reach the working draft, bounded at sixteen
mebibytes — so opening an entry whose page places no component paid for a
library it resolves nothing against and draws identically without.

The question is asked of the document, under the SITE's node cap, and an
unread prefix counts as placing one: a document past the cap answers
`complete: false`, and "names nothing" is what an unread document looks like
too, so the read is still made rather than the largest pages on a site drawing
as could-not-be-loaded markers.

A disabled read reports `ready` rather than `pending`. A query that never runs
never stops pending, and the card would have waited on an answer nobody asked
for.

* fix(blocks-engine): a visibility exposure reads the definition's own gate

With no override written, a `visibility` exposure reported nothing in force —
and something was. A definition node carrying entry-field conditions is not
served: `survivesGating` with no plan says so, and the composed forest keeps
the gate for the renderer's hidden-node pass to act on. Read as a blank, the
inspector drew the row checked and told the author the node was shown on this
page while the canvas withheld it.

The row now carries the definition's own decision, with `source: "definition"`
and no own override, so a surface can tell an inherited gate from an author's
own hiding without a vocabulary of its own. A node with no gate still reads as
nothing in force, because nothing is.

* fix(plugin-page-builder): gate a configured component store by the slug it reads

Two rules about a store the plugin was told about rather than owns.

The route resolved its permission through the scope helper, which follows the
host's rename of a collection the PLUGIN declared. The handler reads the
configured slug literally, so the two named different collections exactly when
a host renamed the contributed `components` collection and pointed the store at
another one called `components`: a caller holding read on the collection being
read was refused, and one holding read on the renamed collection was let into a
collection that permission says nothing about. The default store still resolves
through the helper, which is what a rename needs.

And a completed component now carries its `keywords`. `LibraryComponent`
derives from `SavedComponent`, and the catalogue builds a component tile's
search terms from that field exactly as it does a pattern's — through the same
reader here, so an absent field stays absent and a stored NULL arrives as
`null`, which is the shape the palette expects.

* chore: a changeset for the component library's review round

The round's own entry, since the PR it was raised against merged while this was
being written and its changeset went with it.

* fix(blocks-engine): a malformed slot entry refuses a placement, it does not raise

A stored forest reaches the internal-nesting walk unvalidated — its own comment
says a slot may hold anything — and asking what a node DRAWS reads one field
further than asking its type did: an entry typed as an instance but carrying no
`props` had its `componentId` read, where before only its type was.

Read defensively now, and an entry with no readable type stands for NO type
rather than for one spelled out of whatever was there: `placementVerdict`
compares these against a registry, and a string like "undefined" is a name a
slot's admissions list could be made to accept. The planners shape-check their
forest before they reach this, so it is a boundary rather than the whole
defence — what it must not be is a raise where a refusal belongs.

* fix(plugin-page-builder,blocks-engine): a by-id row's own id must be the one asked for

Four things a reader established about its own instruments rather than about the
data.

A row with no `id` KEY is the redaction case and is keyed by the listing. A row
that HAS the key answered with an identity, and `null`, a number or an empty
string is not "no id" — it is an answer, and not this one. Read as absence its
content travelled under a name it never claimed.

The lookup is now read INSIDE the roots query's exception boundary. It is a
caller-supplied object rather than a map the engine builds, so a `get` that
raises escaped to exactly the caller the boundary exists for.

The listing's cursor is taken from the greatest READABLE id on a page, and the
test stub now selects it the same way. Inspecting only the final row made the
stub fall back to an offset where the route carries a cursor, so the pagination
cases could pass about a walk that does not run — and the route's own selection
had no test at all, because the component tier's listing is injected. It is
asserted on the pattern tier, where the route's `page()` actually runs.

And the two `withoutSelf` suites share one set of fixture builders. Two copies of
what a component, an instance and the walk's inputs are is a second definition
of the thing under test.

* fix(builder): a value the inspector's control cannot hold is shown, not offered for editing

`OverrideValue` is unconstrained, so a host block may declare a text or link prop
as an object. A text field renders one as a blank — there is no string to show —
and the first edit then replaces the whole value with whatever was typed into
that blank, losing the rest of it with nothing reporting the loss.

Such a row now takes the same note a type this panel cannot edit yet takes: the
value is summarised and nothing overwrites it.

A select and a visibility row always stay editable. Neither carries the old value
into what it writes, so a value they cannot show is repairable by using the
control, and hiding it would strand the property instead.

* fix(nextly): a Single's publish re-judges the draft it promotes (#1826)

* fix(nextly): a Single's publish re-judges the draft it promotes

A Single's publish folds its held pending change into the live row. Field
access and validation both ran when the caller's payload arrived, and for a
publish that payload is just `{ status: "published" }`, so the draft's own
content reached the live row having been judged only when it was SAVED. The
collection publish path already gates its promotion; this is the same gate on
the Singles path, and it covers all three publish routes because it sits in the
shared promotion rather than in any one of them.

Two things can have changed between saving and publishing. The publisher may
not be the author, so a field rule can deny them a value the author was allowed
to write. And the schema can have tightened under a value that was legal when
it was held.

Both gates run on the merged document the promotion will actually persist, and
never on the live row: a schema change must not block someone from fixing and
republishing content that has nothing to do with it.

Validation refuses, naming each field and carrying the rule's own message.

Access refuses too, which is a departure from the ordinary write, where a
denied field is stripped. Stripping is right there, because the value is the
caller's own input and dropping it costs them nothing. A promotion is not that:
the value belongs to whoever saved the draft, and a successful publish CONSUMES
the draft. Stripping would publish everything else, delete the pending change,
and take the one edit this publisher may not write with it, leaving the author
no draft, no value and no message. Measured: zero draft rows remained after
such a publish. Refusing keeps the draft for someone who can write the field.

Judged on what would CHANGE, not on what the snapshot holds. A draft snapshot
is a full copy of the document, so a denied field appears in every one of them;
only a denied field whose promoted value differs from the live row is a change
this publisher is not allowed to make.

Researched first. Payload enforces at the publish transition what a draft save
skips; Strapi makes Publish its own RBAC action; WordPress re-checks
`publish_posts` at the transition rather than reusing the edit check. Two
cautions came from their bug trackers and are honoured here: Sanity's #11456
shows what happens when the check leaks onto the live document, and Strapi's
#15636 shows a deferred check falling through to a raw database constraint
instead of a field-scoped message.

* refactor(nextly): one promote gate, outside the transaction, over a logical snapshot

Codex found four defects in the first revision, three of them P1, and all four
were real. This reworks it rather than patching around them.

The gate ran INSIDE the write transaction. Both a field's `access` rule and its
`validate` are user code, and resolving the caller's grants issues its own
pooled queries, so on a small pool those queries wait for the connection the
transaction is holding and the publish hangs. It now runs before the
transaction opens, which is where the collection publish path has always run
its own, and for this reason.

It judged the snapshot as stored. A snapshot holds a JSON-backed value (a
group, a repeater, `chips`, `json`) as the string that was written, and the
validator for those fields expects the object. Measured: publishing an
ordinary Single that merely HAS a group field was refused with "seo must be an
object". The snapshot is now read in its logical shape first. My tests used
text fields only, which is why this reached review.

It covered one publish path. `SinglePublishAllService.promotePendingChanges`
loops every language's pending change, writes each and deletes them all, and
had no gate of its own, so publishing every language still promoted content
forbidden to the publisher or invalid under the current schema. Both paths now
call one shared `promote-gate` module: two gates would be two answers to one
question, and the second is the one nobody remembers to update.

It compared a denied field against the main-table row, which omits every
localized value. An unchanged translation therefore compared against
`undefined` and read as an edit, so a publisher without write access to that
field could be refused a publish they were entitled to make. The comparison now
reads the live document for the language the pending change belongs to.

* fix(builder,blocks-engine,plugin-page-builder): a component is judged by what it draws (#1824)

* fix(plugin-page-builder): a pattern that reaches the edited component is not offered

Saving a selection as a pattern keeps the instance nodes it held, so a pattern
is a second way to copy a component into itself. The component tier was
filtered and the pattern tier was forwarded whole, and the two tiers are
different rows out of different collections.

Both are now judged by one graph and one rule: which components a candidate
places, followed through the canvas's own lookup until the edited row is met.
A pattern nobody could read whole under the site's node cap is left out rather
than offered on an answer nobody has.

* fix(blocks-engine): a pattern's instances are judged by what they draw

`nextly/component-instance` is not a registered block, so every rule spelled
over node types answered wrong for it in both directions. A parent rule found
no restriction on the instance type and admitted a component whose root belongs
only inside a Columns. A slot naming what it admits did not name the instance
type, so every component was barred from every slot that lists its contents,
including the ones drawing exactly what the slot asks for — the tile was
offered and the click then planned nothing.

The rule the palette already used for a node's drawn types now lives in the
engine, beside the roots query it is built on, and the builder re-exports it.
The two pattern rules — the destination's placement and the forest's own
internal nesting — resolve through it whenever the caller holds a lookup, and
the panel hands the same lookup to the catalogue and to the planner. Callers
holding no library get the answer they got before.

* fix(blocks-engine): a nested instance's own overrides reach its definition's roots

`composedRootTypes` followed a root instance into its definition without asking
what that instance decided about the definition's nodes. A `visibility`
exposure overridden to false removes the node and its subtree from the composed
forest — `cloneDefinitionNode` returns nothing at all for it — so the query
reported a type the page never receives, and a component whose only root is
hidden was offered as placing something and placed nothing. Overridden to true
it deletes the node's own gate, so a gated root the author turned on is
expanded rather than left standing.

The decision comes from the resolver's own planner rather than a second reading
of `props.overrides`, so the chosen variant's presets are folded in under the
instance's answers exactly as the render folds them. A definition's remembered
roots are a property of the definition, so an instance that decides neither
reads that memo nor writes to it.

* fix(plugin-page-builder): a completed component must be the row the listing named, read whole

Two ways a by-id read answers with something that is not the component it was
asked for, both of which the completion took at face value.

A `beforeOperation` hook can redirect the read, so the record answering for one
component may be another's. Keyed by the listing's id, that row's draft was
served under the other component's name: the canvas drew one component's
content wherever the other was placed, with nothing anywhere saying so. A row
naming a different id is now left out and the tier reported cut. A row carrying
NO id is still keyed by the listing — field-level access drops it in
presentation, and that case is why the id comes from the listing at all.

And an absent document field was flattened into the same `null` as a
stored-empty one. The field layer writes an unset non-required field as SQL
NULL and reads it back with the key present, so `null` is an answer and a legal
row; no key at all means this caller did not read the row whole. Told apart,
the second marks the tier cut instead of reporting a complete library the
client has no definition for.

* fix(plugin-page-builder): the library is paged from a row, not from an offset

Both tiers walked their collection as independent offset queries against a
collection other authors are editing. A row inserted or deleted before the next
offset shifts every row after it, so one comes back twice and another never at
all — and a row never listed is never completed, so `omitted` stays false and
the response reports a whole library while the canvas has no definition for it
and draws every instance as missing.

The position is now the greatest id the last page named, and the next page is
the rows after it: ordered by id, that means the same thing however many rows
before it moved. What is left of the offset counts pages since the position
last MOVED, for the one page whose every row arrives without a readable id —
it names no position, and stepping past it is the only way to reach what is
behind it. A page that names an id resets it, so an ordinary walk never carries
an offset a mutation can move.

* fix(blocks-engine): the roots query survives a node whose own fields throw

The resolver composes a definition carrying a throwing property accessor
without raising; this query read the same fields with no boundary. Its one
caller builds the insert panel's catalogue, so a single such definition took
the whole panel down over a component the canvas draws.

The boundary is at the published entry point rather than per definition,
because the document's own roots are read by the same walk. Caught rather than
asked first, which is this module's usual answer to a stored shape: reading the
property IS the raise, so there is no question to ask before it. The answer is
`undefined` — the one already defined for a forest this cannot judge, and one
its callers already withhold the tile for.

* refactor: name the two questions each of these rules was asking

`withDraftDocument` asked three: is this the row that was asked for, was it read
whole, and what is it called. The first and third are now their own — and the
third was spelled twice, once here and once on the listing row, so an unnamed
component could have come to be called two things.

`rootTypesOfNode` asked what a root stands for and, for an instance, what its
definition draws. The second is its own function, reached once the first has
decided it is an instance at all.

Both were over fallow's CRAP bound, whose coverage is estimated and so cannot
be tested down; both are under it by branch count now.

* perf(plugin-page-builder): the resting card reads the component tier only when the page places one

The miniature every entry form draws at rest read the whole component tier on
mount, whatever the page held. That read is a listing over every row plus a
read of its own per row to reach the working draft, bounded at sixteen
mebibytes — so opening an entry whose page places no component paid for a
library it resolves nothing against and draws identically without.

The question is asked of the document, under the SITE's node cap, and an
unread prefix counts as placing one: a document past the cap answers
`complete: false`, and "names nothing" is what an unread document looks like
too, so the read is still made rather than the largest pages on a site drawing
as could-not-be-loaded markers.

A disabled read reports `ready` rather than `pending`. A query that never runs
never stops pending, and the card would have waited on an answer nobody asked
for.

* fix(blocks-engine): a visibility exposure reads the definition's own gate

With no override written, a `visibility` exposure reported nothing in force —
and something was. A definition node carrying entry-field conditions is not
served: `survivesGating` with no plan says so, and the composed forest keeps
the gate for the renderer's hidden-node pass to act on. Read as a blank, the
inspector drew the row checked and told the author the node was shown on this
page while the canvas withheld it.

The row now carries the definition's own decision, with `source: "definition"`
and no own override, so a surface can tell an inherited gate from an author's
own hiding without a vocabulary of its own. A node with no gate still reads as
nothing in force, because nothing is.

* fix(plugin-page-builder): gate a configured component store by the slug it reads

Two rules about a store the plugin was told about rather than owns.

The route resolved its permission through the scope helper, which follows the
host's rename of a collection the PLUGIN declared. The handler reads the
configured slug literally, so the two named different collections exactly when
a host renamed the contributed `components` collection and pointed the store at
another one called `components`: a caller holding read on the collection being
read was refused, and one holding read on the renamed collection was let into a
collection that permission says nothing about. The default store still resolves
through the helper, which is what a rename needs.

And a completed component now carries its `keywords`. `LibraryComponent`
derives from `SavedComponent`, and the catalogue builds a component tile's
search terms from that field exactly as it does a pattern's — through the same
reader here, so an absent field stays absent and a stored NULL arrives as
`null`, which is the shape the palette expects.

* chore: a changeset for the component library's review round

The round's own entry, since the PR it was raised against merged while this was
being written and its changeset went with it.

* fix(blocks-engine): a malformed slot entry refuses a placement, it does not raise

A stored forest reaches the internal-nesting walk unvalidated — its own comment
says a slot may hold anything — and asking what a node DRAWS reads one field
further than asking its type did: an entry typed as an instance but carrying no
`props` had its `componentId` read, where before only its type was.

Read defensively now, and an entry with no readable type stands for NO type
rather than for one spelled out of whatever was there: `placementVerdict`
compares these against a registry, and a string like "undefined" is a name a
slot's admissions list could be made to accept. The planners shape-check their
forest before they reach this, so it is a boundary rather than the whole
defence — what it must not be is a raise where a refusal belongs.

* fix(plugin-page-builder,blocks-engine): a by-id row's own id must be the one asked for

Four things a reader established about its own instruments rather than about the
data.

A row with no `id` KEY is the redaction case and is keyed by the listing. A row
that HAS the key answered with an identity, and `null`, a number or an empty
string is not "no id" — it is an answer, and not this one. Read as absence its
content travelled under a name it never claimed.

The lookup is now read INSIDE the roots query's exception boundary. It is a
caller-supplied object rather than a map the engine builds, so a `get` that
raises escaped to exactly the caller the boundary exists for.

The listing's cursor is taken from the greatest READABLE id on a page, and the
test stub now selects it the same way. Inspecting only the final row made the
stub fall back to an offset where the route carries a cursor, so the pagination
cases could pass about a walk that does not run — and the route's own selection
had no test at all, because the component tier's listing is injected. It is
asserted on the pattern tier, where the route's `page()` actually runs.

And the two `withoutSelf` suites share one set of fixture builders. Two copies of
what a component, an instance and the walk's inputs are is a second definition
of the thing under test.

* feat(nextly): a plugin can update many entries in one call (#1819)

* feat(nextly): a plugin can update many entries in one call

`ctx.services.collections` ended at `createMany`. Plugin code could write many
rows in one call and then had no way to change them in one, elevated or not, so
the only batch update available to it was a loop of `updateEntry` calls, each
with its own transaction, its own access pass and its own cache flush. The
engine path was already there: `updateEntries` takes `overrideAccess`.

`updateMany(slug, entries, opts?)` takes one `{ id, data }` per row, so a single
call can apply a different patch to each row, and applying one patch to many
rows is the same call with the patch repeated. It returns the
`BatchOperationResult` `createMany` returns, so a failed row leaves the rest
committed and is reported by the index of the entry the caller passed.

Researched first. Payload, Strapi's query engine, Directus and Sanity all take a
filter plus ONE shared patch, which cannot express a different patch per row and
whose documented failure is a filter matching more than its author meant;
Payload had to patch exactly that. WordPress's batch framework and this engine
already take a list of per-item patches. A by-filter form would also need a
second access, hook and revalidation pass to compute what it changed, and
`listEntries` composes with this method to the same capability with the rows
named, so there is one method rather than two.

A `locale` is refused by name, as on `createMany`: the bulk pipeline takes no
locale at all, and `forwardedFromContext` spreads one in where a spread
suppresses excess-property checking, so an accepted locale would be dropped and
every row written to the default language under a reported success.

The harness note on the D56 suite said bulk paths could not run end to end in
`createTestNextly`. They can: the new suite seeds with `createMany` and patches
the result with `updateMany` through a real boot. The note is corrected rather
than carried.

* fix(nextly): type the batch-update fixture, export its input type, and page the docs recipe

Three review findings on the new `updateMany`.

The end-to-end suite typed its services fixture as `any`, so every call in it
compiled whether or not `PluginCollectionService` declared the method: the suite
existed to pin the published surface and would have stayed green while that
surface lost it. Typed as `PluginContext["services"]` instead, which immediately
refused a plain string where `AuthUserId` is required and an unknown property on
`AuthUser`, both of which the `any` had been hiding.

`BulkUpdateEntry` is the input half of a public method and was exported from
neither the `nextly` root nor the SDK, so a plugin author could not name the
contract without an internal path or a `Parameters<>` extraction. Exported
beside `BatchOperationResult`, through both.

The by-filter recipe in the docs read one page and presented itself as the way
to update every match, so it silently stopped at 100 rows. It now loops, and
says why re-reading page one is right for a patch that changes what the filter
matches, and what to do instead when it does not.

* chore: the batch-update changeset covers the new lockstep package

* feat(nextly): a plugin can publish a widget source, and a slow one cannot hold the batch (#1823)

* feat(nextly): a plugin can publish a widget source, and a slow one cannot hold the batch

contributes.widgetSources takes a source and the function that answers it in
one value, so a source nothing can answer is not a state a plugin can reach.
The resolver type is the one core's own system sources already use rather than
a second contract beside it, and both kinds now share one resolver store: two
stores would be two answers to "what answers this id", and the invariant that
matters is which kinds may carry a resolver at all -- never a collection or a
single, whose rows the access-controlled Direct API is supposed to answer.

The signature is the SSRF boundary rather than a convenience. A resolver is
handed (query, caller) and reaches only what its own closure captured, and
every name in that query was checked against the plugin's own declared field
list first -- so there is no caller-controlled string for it to fetch. Directus
mitigated an import-endpoint SSRF with an IP denylist and the denylist was then
bypassed by DNS rebinding; this stays structural and never becomes a validated
escape hatch.

What the shape does NOT promise is that a resolver consults the caller. It
cannot: the host hands the caller over and the plugin decides. WordPress has
required a permission_callback on every REST route since 5.5 and plugins still
ship __return_true for it. The docblocks say so rather than implying a
guarantee the contract cannot make; this is the boundary a plugin's init, hooks
and services already cross.

The fold refuses a reserved namespace, a duplicate id and a missing resolver at
BOOT, each naming the plugin, because which resolver owned an id would
otherwise be decided by plugin load order with the loser silently never
answering. Core registers its own sources first, so a plugin shadowing one
fails naming the plugin rather than dying inside core's publication.

The query endpoint bounds each slot. Promise.all made the batch as slow as its
slowest member, so one query that never settled held every other card behind it
and the reader saw nothing rather than the cards that answered. The race
abandons rather than cancels, so the abandoned promise is marked handled and
the timer is unref'd.

Every declared source kind is now executable, which is why the final guard in
resolveExecutableSource narrows to never. It is kept and widened through a
string: the narrowing is a statement about TypeScript callers, not about the
values a separately compiled plugin can hand over.

* fix(nextly): a contributed widget source's resolver is handed its plugin's context

The contract shipped as `(query, caller)`, and a plugin's data services are
reachable through nothing else but its `PluginContext` -- so a contributed
resolver could answer from constants and little more. The feature could be
declared, validated and dispatched to, and could not do the one thing it exists
for. Every other contributed FUNCTION on this surface already receives the
context: `jobs.handler(ctx)`, `services[name](ctx)`. This one was the exception
by oversight.

The context arrives LAST, so a resolver that needs no data can ignore it, and
the source half stays a plain object -- `contributes` is still readable without
executing the plugin, which is what lets tooling work from config alone.

Registration moves out of `resetWidgetRegistries` and into `initializePlugins`,
because the reset runs before any context has been built. It sits beside the
contributed-services registration and binds the same way: per plugin, so each
resolver closes over ITS OWN context. Bound once outside that loop, every
plugin would share the first one's `ctx.self` and read another plugin's
entities believing they were its own. The fold still runs once across every
plugin first, so a duplicate id or a reserved namespace is refused naming both
owners before anything reaches a store.

Core still publishes its own sources first, which is what makes a plugin
shadowing a built-in fail on the PLUGIN's registration -- naming something an
operator can act on.

Proved through a real boot rather than a mock: a plugin whose resolver counts
rows through `ctx.services.collections` answers 2 over two written rows. No
stub could have failed that way, which is the point -- the two-argument
contract passed every mocked test it had.

* fix(nextly): say what the resolver contract bounds, and publish the type it takes

Two corrections, both about what the published contract PROMISES.

The SSRF claim was too strong. Validation checks a query's field names, its
operators and its operand SHAPES against the source's own declaration; it does
not constrain operand VALUES, and `where: { total: { equals: "http://..." } }`
is a legal query whose bytes a caller who may place a widget chooses. So the
docblocks no longer say a caller-supplied string cannot reach a resolver --
they say exactly what is bounded, what is not, and that a resolver must treat
every operand as caller-controlled before using one as a destination. Stated as
the contract's rule rather than a host-side filter, because Directus's IP
denylist for CVE-2022-23080 was itself bypassed by DNS rebinding: a filter over
a value the plugin then dereferences is one round of research from being none.

And `WidgetSourceResolver` is core's own two-argument shape, so an author who
followed the export and typed a standalone resolver with it had the context
parameter rejected -- the one parameter through which a contributed resolver
reads any data. `PluginSourceResolver` is published beside it, both names say
which is which, and a compile-time test asserts the three-argument shape is
what `contributes.widgetSources` takes.

* fix(nextly): a plugin's managed read keeps the claims its caller was authenticated with

`readCaller` spreads `auth.claims` onto the user it builds, so a caller handed
to a plugin carries whatever its token proved -- a tenant, a plan, an
entitlement -- and a collection's code-defined `access` rule may read exactly
those. `resolveServiceOpts` rebuilt the identity from id, name, email and roles
alone, so the rule was judged on a DIFFERENT caller than the endpoint
authenticated.

Both directions are wrong and one of them grants: a positive check on a claim
denies a caller who holds it, and an absence-tolerant check such as
`user.plan !== "suspended"` passes a caller whose token says otherwise.

Taken as "whatever else the supplied identity carried", so a caller passing a
plain `AuthUser` contributes nothing and is unaffected, and the declared fields
still come from the identity rather than from the spread.

* fix(nextly): a bulk write carries the localized split, so createMany reaches the companion (#1816)

* fix(nextly): a bulk write carries the localized split, so createMany reaches the companion

createMany failed EVERY row on a collection with localized: true - the shared
create implementation wrote translatable values to the main table, which has
no columns for them, so each row came back with the driver's own 'no column
named' message. It now performs the same split as a single create and writes
the companion row for the write's locale inside the same transaction.

The shared update implementation had the identical gap one function down, so
it upserts that row the way the single-entry update does - an upsert, not an
insert: the parent exists and may or may not have a row in this language, and
a patch that touches no translatable field writes nothing rather than claiming
a translation nobody made. A held edit writes no live row and so no companion
row either.

Both paths still refuse a named locale, as they did: this is the default
language's write.

* refactor(nextly): both create paths write a new companion row through one insert

The bulk create's companion insert repeated the single create's, down to the
staleness stamp, which is how the two would come to disagree about what a new
translation carries. insertCompanionRow states it once; the test asserts the
stamp is on every row a bulk create writes, which nothing had asserted for
either path.

* fix(nextly): a bulk localized write records the whole language, and rolls back when it cannot

Five findings from review, all on the write this PR added.

Readiness is never resolved inside a caller's transaction: the split now reads
the remembered verdict when it is handed an executor, as every other
in-transaction caller does. Resolving issues a pooled query that waits for the
connection the transaction holds, and on PostgreSQL a query against a missing
relation aborts the whole transaction. The batch services already warm the
verdict before they open one; the promoted-draft path, which passed an
executor since before this PR, stops querying there too.

A failure of the companion write is a write-integrity failure: the parent row
is already written, and a soft per-item failure would let a batch commit a
document whose translations never landed.

What the write RECORDS is now the whole language: the companion row is read
back on the transaction and overlaid with what this write set, so a patch
naming one translatable field no longer records a document missing the rest -
and the version is tagged with the locale those values belong to, without
which history reads them as shared and a restore drops them. The values
reattach under the field's name, not the column's, so a field whose column
differs reaches hooks and snapshots as itself.

* fix(nextly): a bulk write's events name the language they describe

The write locale reached the companion upsert and stopped there, so every
entry.created, entry.updated and status event a bulk localized write recorded
carried no locale on its resource - and a receiver reads the language from
there alone, so each was delivered as belonging to no translation in
particular. The interactive create has always set it.

* fix(nextly): a bulk write authorizes the translation it publishes, and reads the prior one first

Four corners of the same write, all from review.

A localized collection can keep its status per language, so the main row and a
translation can disagree about whether that language is published - the state a
reconcile leaves. The batch update judged the transition against the main row
alone, where `published -> published` is a no-op needing no grant, and then
wrote `_status` to the companion: an update-only caller could publish a
translation, and the inverse could take one down. The decision now runs against
both places through one implementation, so the two readings cannot drift.

What the write reports as the previous state came from the main row, which on a
migrated localized collection holds none of the translatable values. Every
translation therefore read as appearing from nothing, the old value of the field
that did change was lost, and a rename of a localized slug never busted the URL
it replaced. The prior translation is read before the write instead, and is what
`previous`, the previous slug and the status event's `from` are taken from.

Reading it first also removes a window rather than handling it: the document
recorded after the write is now derived from that read rather than fetched
again, so no read stands between the write and the commit. A patch naming only a
shared field wrote no companion row, so the failing read was unguarded, and a
caller tolerating per-item failures committed the main row with no version and
no event while reporting the item as failed.

A create landing on published derives a lifecycle event, a curated event and a
cache intent beside `entry.created`. Only the first named the language, so the
rest described no translation in particular and the locale-specific tag was
never flushed.

Also stated, rather than claimed away: inside a caller's transaction the
readiness verdict can only be remembered, and a verdict nobody warmed is
indistinguishable from a collection that was never migrated. The entry points
that open their own transaction warm first; the ones handed an open transaction
cannot.

* fix(nextly): a batch write reports the status of the translation it wrote, not the entry's

A regression from the previous commit, found in review.

Reading the prior status from the companion row was right, and left the other
end of the move reading the main row. On a collection that keeps status per
language those disagree exactly where it matters: the main row published, this
translation still a draft after a reconcile. A patch touching only translated
content then read `draft -> published` and announced `entry.published` and
`entry.status_changed` for a translation nothing had published, while the
recorded document and the version claimed it was live.

Both ends now come from the row that owns this language's publication state.
What the write leaves the companion holding is the value the patch set, or the
one already there when the patch named no status, and that is overlaid onto the
document the same way its values are - so the event, the snapshot and the
companion row cannot disagree about whether a translation is public.

Also verified and deliberately not changed here: both update paths give their
hooks the bare main row, so a hook comparing a localized field sees undefined
as the prior value. That is true of the single-entry update as much as this
one, and it predates this change; hydrating only this path would make batch
hooks see translations single-entry hooks do not.

* fix(nextly): a bulk write converts its values, and records each publication once

Four more from review, and all four came from the same place: the batch
writers re-derived work the interactive path already does completely, and
stopped short of it in a different way each time.

The headline claim was still false for rich text. A create prepared its
payload with two of the four conversions the interactive create runs, so a
JSON-backed value reached the localized split as a live object and went into
the companion column unconverted. The conversion is one method now, called by
both, and the whole eleven-step preparation either path performs before its
write is one method as well - which is the honest fix, because a list of steps
maintained by hand in two places is exactly how one of them went missing.

A translation's status is likewise decided in one place now, and it has a
third case the batch path never had: a locale being translated for the first
time has no companion row, so the upsert creates one and its status lands on
the column default. Reported from the main row instead, a brand-new draft
translation was announced as published.

The publication events were collapsed into one, which got a case wrong in
each direction. A content-only patch on a draft translation under a published
entry announced a publication nothing performed; a patch that really did
publish the main row, while that translation was already published, announced
nothing at all. Main row and translation move independently, so each is
recorded on its own terms and the main-row event is suppressed only when the
companion write encodes the identical move.

One reported case is not reachable and is left alone rather than guarded:
`readCompanionLocalizedValues` resolves an absent translation to null rather
than omitting it, so the localized document is never empty while a companion
exists. Recorded where the predicate is read.

* fix(nextly): a field hook fires for the translation the write touched, not its siblings

From review, and introduced by the overlay the previous commit added.

The whole language is put onto the updated row on purpose: the snapshot and
the event describe a translation rather than the one field of it that moved.
A field hook, though, runs for every key PRESENT in the row it is handed, so
the untouched siblings carried along for the snapshot would run their
afterChange handlers for values this write never changed - and those send
mail, re-index and call out.

They are taken off for the hook phase and put back after it, rather than the
hook being handed a copy: a handler's return value is written back into the
row it was given, and a copy would drop the transformations belonging to the
fields this write did set. Restored in a `finally`, so a throwing handler
cannot cost the response its translations either. The field registry performs
the same remove-then-restore around its own snapshots.

* fix(nextly): offer the collection step only where creating one would finish it (#1830)

* fix(nextly): offer the collection step only where creating one would finish it

The step completes when this reader can READ a collection, and
`seedPermissionsForCollection` assigns a new collection's CRUD permissions to
`super_admin` alone. So a caller holding the definition grant and nothing else
was offered "create your first collection", created it, gained no `read-<slug>`
for it, and found the step outstanding permanently -- the defect the predicate
exists to prevent, moved one action later rather than fixed.

It now asks both halves: may they define one, and would they read the result. A
scoped API key is refused outright, because a key is judged on the scope
stamped into it and gains nothing when a new collection appears.

The test that documented the old state is replaced by a pair. A stamped key is
offered NEITHER step and its checklist is complete, because it could finish
neither. A session super admin on an install with no collections at all IS
offered it -- the must-differ half, and the caller a fresh install actually has.
The fixture carries no collections on purpose: a super admin reads every
collection that exists, so any other fixture completes the step and completion
short-circuits the predicate, passing without exercising it.

* fix(nextly): derive who reads a new collection from the policy that seeds it

The predicate hard-coded "receives read on a new collection" as "is a super
admin", independently of the assignment `assignNewPermissionsToSuperAdmin`
actually performs. The two could then drift in either direction with nothing
reporting it: creation beginning to grant the creator would leave the checklist
hiding a step that had become finishable, and the assignment moving to another
role would leave it offering one that had stopped being. A reader would simply
see a checklist that was wrong about them.

`auth/new-entity-access-policy` declares the role a newly seeded entity's
permissions are assigned to, and both ends read it: the seeder assigns by it,
and `wouldReadOwnNewCollection` answers whether a caller is on the receiving
end. The membership test stays `isSuperAdmin` because it resolves role
inheritance, which a flat slug comparison would miss -- but it is now reached
through the policy rather than asserted beside it.

The API-key branch moves into the same place, where the reason belongs: a key
is judged on the scope stamped into it when it was minted, so a role gaining a
permission afterwards does not widen a key already issued.

* fix(nextly): compute the eligibility from the recipient, and let a stamped key finish

Sharing the slug was not sharing the policy. The predicate still tested
super-admin membership by name, so moving the recipient would have moved the
seeder and left the checklist behind -- the drift the constant was introduced to
prevent, one level in. Membership is now READ from the declared recipient, so
the constant is genuinely the single point of change.

And refusing every API key hid a step some keys can finish. A key never gains a
permission -- it is judged on the scope stamped into it when it was minted --
but a permission may be pre-seeded, and the read decision accepts a key's exact
`read-<slug>` once that collection exists. So a key holding `read-reports`
finishes this step by creating `reports`, and eligibility is that grant's
presence rather than the actor type.

Both halves break-verified: refusing every key fails the new stamped-key case
alone, and pointing membership at another role fails the super-admin case alone.

* fix(nextly): the promote gate judges the draft the write commits

Seven review findings on the publish gate, all from one root: the gate ran
BEFORE the write transaction, so it judged a copy of the world as it was, and a
check that runs before the write can always disagree with it. It now runs
inside that transaction, on the draft the transaction has locked.

That closes three of the seven at once. A draft another writer saves between
the check and the commit is now the draft that is judged. A `beforeChange` hook
that turns a status-less edit into a publish no longer slips past a check that
ran before the hooks. And `publishAllLocales`, which applies every language's
snapshot to one main row, judges the combined outcome instead of each language
against its own shared values, which could pass individually and land invalid.

Resolving the caller's grants is the one thing that cannot happen inside a
transaction: it queries the pooled connection the transaction is holding, and
on a small pool the publish would hang rather than fail. Both callers resolve
them beforehand and hand them in.

A field rule on a child of a group or a repeater row is enforced. The copy was
shallow, so the rules deleted the denied nested value from the copy and the
original alike, and the top-level comparison then saw an unchanged container
and reported nothing while the write persisted the forbidden edit. The copy is
deep and the difference is found at any depth, so the refusal names
`ops.runbook` rather than `ops`.

A publish is no longer refused over a field nobody touched. The live side came
from a read that expands an upload or a relationship into the document behind
it, while the snapshot holds the identifier, so an untouched field of either
kind compared unequal. Both sides now go through one conversion.

A draft older than a newly required field is refused rather than published. The
promoted document was judged as a patch, which skips absent properties by
design, so a snapshot written before the field existed reported nothing.

An API key is judged on the grants stamped on the key. There is no
request-local scope on the Direct API, so the scope travels as an argument.
---
 .../a-component-is-judged-by-what-it-draws.md |  31 +-
 .../a-plugin-can-answer-a-widgets-question.md |  72 ++
 ...-plugin-can-update-many-entries-at-once.md |  30 +
 .changeset/a-single-answers-as-one-row.md     |  31 +-
 .../a-single-publish-revalidates-its-draft.md |  40 +
 .../a-step-offered-is-a-step-finishable.md    |  38 +
 ...a-super-admins-key-copies-the-catalogue.md |  31 +-
 ...ance-can-be-shown-and-pointed-elsewhere.md |  38 +
 .../an-instance-shows-what-it-exposes.md      |  31 +-
 .../bulk-writes-carry-the-localized-split.md  |  36 +
 ...e-checklist-offers-what-a-reader-can-do.md |   1 +
 ...he-promote-gate-judges-the-locked-draft.md |  40 +
 docs/plugins/services.mdx                     |  66 +-
 .../src/instance-inspector-panel.test.tsx     | 200 ++++
 .../builder/src/instance-inspector-panel.tsx  |  70 +-
 .../builder/src/instance-inspector.test.ts    |  51 +-
 packages/builder/src/instance-inspector.ts    |  18 +-
 packages/nextly/src/api/widget-query.test.ts  | 167 ++++
 packages/nextly/src/api/widget-query.ts       | 123 ++-
 .../src/auth/new-entity-access-policy.ts      |  70 ++
 .../src/di/__tests__/register-widgets.test.ts |  37 +
 packages/nextly/src/di/register.ts            |  31 +
 .../src/di/registrations/register-widgets.ts  |  13 +
 .../auth/services/permission-seed-service.ts  |   3 +-
 .../bulk-writes-localized.integration.test.ts | 942 ++++++++++++++++++
 .../services/collection-mutation-service.ts   | 820 +++++++++++----
 .../services/collection-service.ts            |  61 +-
 .../src/domains/i18n/companion-columns.ts     |  36 +
 ...-revalidates-its-draft.integration.test.ts | 415 ++++++++
 .../domains/singles/services/promote-gate.ts  | 310 ++++++
 .../singles/services/single-entry-service.ts  |   8 +-
 .../services/single-mutation-service.ts       |  59 ++
 .../singles/services/single-publish-all.ts    | 129 ++-
 .../__tests__/onboarding.integration.test.ts  |  96 +-
 .../widgets/__tests__/plugin-sources.test.ts  | 168 ++++
 .../plugin-widget-source.integration.test.ts  | 213 ++++
 .../domains/widgets/caller-read-options.ts    |  58 ++
 .../src/domains/widgets/condition-probe.ts    |  47 +-
 .../src/domains/widgets/executable-source.ts  |  55 +-
 .../nextly/src/domains/widgets/execute.ts     |  11 +-
 packages/nextly/src/domains/widgets/index.ts  |  31 +
 .../src/domains/widgets/resolved-sources.ts   | 169 ++++
 .../src/domains/widgets/system-sources.ts     |  97 +-
 packages/nextly/src/index.ts                  |  16 +-
 .../__tests__/service-d56.integration.test.ts |  15 +-
 .../service-update-many.integration.test.ts   | 190 ++++
 packages/nextly/src/plugins/contributions.ts  |  28 +
 .../nextly/src/plugins/service-opts.test.ts   |  41 +
 packages/nextly/src/plugins/service-opts.ts   |  30 +-
 .../__tests__/collect-widget-sources.test.ts  | 156 +++
 .../plugins/widgets/collect-widget-sources.ts | 207 ++++
 .../src/shared/lib/field-level-registry.ts    |   2 +-
 packages/plugin-sdk/STABILITY.md              |  81 +-
 .../__snapshots__/plugin-surface.test.ts.snap |   6 +
 packages/plugin-sdk/src/index.ts              |  25 +-
 .../src/widget-source-exports.test-d.ts       |  56 ++
 scripts/doc-samples-baseline.json             |  17 +-
 57 files changed, 5413 insertions(+), 450 deletions(-)
 create mode 100644 .changeset/a-plugin-can-answer-a-widgets-question.md
 create mode 100644 .changeset/a-plugin-can-update-many-entries-at-once.md
 create mode 100644 .changeset/a-single-publish-revalidates-its-draft.md
 create mode 100644 .changeset/a-step-offered-is-a-step-finishable.md
 create mode 100644 .changeset/an-instance-can-be-shown-and-pointed-elsewhere.md
 create mode 100644 .changeset/bulk-writes-carry-the-localized-split.md
 create mode 100644 .changeset/the-promote-gate-judges-the-locked-draft.md
 create mode 100644 packages/nextly/src/auth/new-entity-access-policy.ts
 create mode 100644 packages/nextly/src/domains/collections/__tests__/bulk-writes-localized.integration.test.ts
 create mode 100644 packages/nextly/src/domains/singles/__tests__/single-publish-revalidates-its-draft.integration.test.ts
 create mode 100644 packages/nextly/src/domains/singles/services/promote-gate.ts
 create mode 100644 packages/nextly/src/domains/widgets/__tests__/plugin-sources.test.ts
 create mode 100644 packages/nextly/src/domains/widgets/__tests__/plugin-widget-source.integration.test.ts
 create mode 100644 packages/nextly/src/domains/widgets/caller-read-options.ts
 create mode 100644 packages/nextly/src/domains/widgets/resolved-sources.ts
 create mode 100644 packages/nextly/src/plugins/__tests__/service-update-many.integration.test.ts
 create mode 100644 packages/nextly/src/plugins/widgets/__tests__/collect-widget-sources.test.ts
 create mode 100644 packages/nextly/src/plugins/widgets/collect-widget-sources.ts
 create mode 100644 packages/plugin-sdk/src/widget-source-exports.test-d.ts

diff --git a/.changeset/a-component-is-judged-by-what-it-draws.md b/.changeset/a-component-is-judged-by-what-it-draws.md
index 256102cb9a..6b1d7c0488 100644
--- a/.changeset/a-component-is-judged-by-what-it-draws.md
+++ b/.changeset/a-component-is-judged-by-what-it-draws.md
@@ -1,29 +1,30 @@
 ---
-"@nextlyhq/adapter-drizzle": patch
-"@nextlyhq/adapter-mysql": patch
-"@nextlyhq/adapter-postgres": patch
-"@nextlyhq/adapter-sqlite": patch
+"nextly": patch
+"create-nextly-app": patch
 "@nextlyhq/admin": patch
 "@nextlyhq/admin-css": patch
 "@nextlyhq/blocks-engine": patch
 "@nextlyhq/blocks-react": patch
-"@nextlyhq/builder": patch
-"create-nextly-app": patch
-"@nextlyhq/eslint-config": patch
-"@nextlyhq/eslint-plugin": patch
-"@nextlyhq/module-specifiers": patch
-"nextly": patch
+"@nextlyhq/ui": patch
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
 "@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-mcp": patch
 "@nextlyhq/plugin-page-builder": patch
-"@nextlyhq/plugin-sdk": patch
 "@nextlyhq/plugin-seo": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
 "@nextlyhq/prettier-config": patch
-"@nextlyhq/storage-s3": patch
-"@nextlyhq/storage-uploadthing": patch
-"@nextlyhq/storage-vercel-blob": patch
 "@nextlyhq/telemetry": patch
 "@nextlyhq/tsconfig": patch
-"@nextlyhq/ui": patch
+"@nextlyhq/builder": patch
+"@nextlyhq/module-specifiers": patch
 ---
 
 A component the editor offers, and one the canvas draws, are now judged
diff --git a/.changeset/a-plugin-can-answer-a-widgets-question.md b/.changeset/a-plugin-can-answer-a-widgets-question.md
new file mode 100644
index 0000000000..9165791bd9
--- /dev/null
+++ b/.changeset/a-plugin-can-answer-a-widgets-question.md
@@ -0,0 +1,72 @@
+---
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/admin": patch
+"@nextlyhq/admin-css": patch
+"@nextlyhq/blocks-engine": patch
+"@nextlyhq/blocks-react": patch
+"@nextlyhq/builder": patch
+"create-nextly-app": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
+"@nextlyhq/module-specifiers": patch
+"nextly": patch
+"@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-mcp": patch
+"@nextlyhq/plugin-page-builder": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/plugin-seo": patch
+"@nextlyhq/prettier-config": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
+"@nextlyhq/telemetry": patch
+"@nextlyhq/tsconfig": patch
+"@nextlyhq/ui": patch
+---
+
+A plugin can contribute a dashboard-widget DATA SOURCE. `contributes.widgetSources`
+takes a source and the server-side function that answers it, together: the
+source declares its queryable fields and supported ops the way every other
+source does, and the resolver is handed the query, the caller, and its own
+plugin context to read through.
+
+What the validation bounds is the SHAPE of the question -- field names,
+operators and operand shapes, all against the source's own declaration. It does
+not constrain operand VALUES, so a resolver must treat every value in a query
+as caller-controlled and must not use one as an outbound URL, a path, or a
+table or column name without checking it against a closed set of its own.
+
+Both halves travel in one value, so a source that nothing can answer is not a
+state a plugin can reach. A contributed id must sit in the `plugin:` namespace;
+`collection:`, `single:` and `system:` are refused at boot, as is a duplicate id
+or a missing resolver, each naming the plugin that declared it. A disabled
+plugin contributes nothing, and a boot starts from an empty store, so a source
+never outlives the plugin that published it.
+
+The dashboard query endpoint now bounds each slot. The batch answers with
+`Promise.all`, so it was only ever as fast as its slowest query: one that never
+settled held every other card behind it and the reader saw nothing at all. A
+slot that exceeds its budget now fails on its own and its siblings still answer.
+
+`WidgetSourceResolver`, `PluginWidgetSource` and `ReadCaller` are published from
+`@nextlyhq/plugin-sdk`, so a resolver can be written as a named function rather
+than only inline. They are `@experimental` on the same ladder as the rest of the
+widget contract.
+
+A contributed resolver is handed its plugin's own context, so it can read data
+to answer with. A plugin's services are reachable through nothing else, so the
+first shape of this contract could return constants and little more.
+
+The resolver type a plugin author writes against is published as
+`PluginSourceResolver`. The existing `WidgetSourceResolver` is core's own
+two-argument shape and rejects the context parameter a contributed resolver
+needs, so typing one with it made the contract reachable only inline.
+
+A plugin's managed read keeps the claims the caller's token proved. The
+identity was rebuilt from id, name, email and roles alone, so a collection's
+code-defined access rule reading a tenant, plan or entitlement was judged on a
+different caller than the request authenticated -- denying a positive check,
+and granting an absence-tolerant one.
diff --git a/.changeset/a-plugin-can-update-many-entries-at-once.md b/.changeset/a-plugin-can-update-many-entries-at-once.md
new file mode 100644
index 0000000000..79339160ea
--- /dev/null
+++ b/.changeset/a-plugin-can-update-many-entries-at-once.md
@@ -0,0 +1,30 @@
+---
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/admin": patch
+"@nextlyhq/admin-css": patch
+"@nextlyhq/blocks-engine": patch
+"@nextlyhq/blocks-react": patch
+"@nextlyhq/builder": patch
+"create-nextly-app": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
+"@nextlyhq/module-specifiers": patch
+"nextly": patch
+"@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-page-builder": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/plugin-seo": patch
+"@nextlyhq/prettier-config": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
+"@nextlyhq/telemetry": patch
+"@nextlyhq/tsconfig": patch
+"@nextlyhq/ui": patch
+"@nextlyhq/plugin-mcp": patch
+---
+
+A plugin can update many entries in one call. `ctx.services.collections` ended at `createMany`: plugin code could write many rows in one call and then had no way to change them in one, elevated or not, so the only batch update available to it was a loop of `updateEntry` calls, each with its own transaction, its own access pass and its own cache flush. `updateMany(slug, entries, opts?)` takes one `{ id, data }` per row, so a single call can apply a different patch to each row, and returns the same `BatchOperationResult` `createMany` returns: partial success, with `errors[].index` indexing the array the caller passed. There is deliberately no by-filter form; `listEntries` and this method compose to the same thing with the rows named, and a filter that matches more than its author meant is the failure a batch write cannot take back. A `locale` is refused by name, as on `createMany`, because the bulk pipeline writes in one pass and cannot store a translation. `@experimental` on the plugin surface until a first-party plugin exercises it.
diff --git a/.changeset/a-single-answers-as-one-row.md b/.changeset/a-single-answers-as-one-row.md
index fda0ced3ed..1430418b3e 100644
--- a/.changeset/a-single-answers-as-one-row.md
+++ b/.changeset/a-single-answers-as-one-row.md
@@ -1,29 +1,30 @@
 ---
-"@nextlyhq/adapter-drizzle": patch
-"@nextlyhq/adapter-mysql": patch
-"@nextlyhq/adapter-postgres": patch
-"@nextlyhq/adapter-sqlite": patch
+"nextly": patch
+"create-nextly-app": patch
 "@nextlyhq/admin": patch
 "@nextlyhq/admin-css": patch
 "@nextlyhq/blocks-engine": patch
 "@nextlyhq/blocks-react": patch
-"@nextlyhq/builder": patch
-"create-nextly-app": patch
-"@nextlyhq/eslint-config": patch
-"@nextlyhq/eslint-plugin": patch
-"@nextlyhq/module-specifiers": patch
-"nextly": patch
+"@nextlyhq/ui": patch
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
 "@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-mcp": patch
 "@nextlyhq/plugin-page-builder": patch
-"@nextlyhq/plugin-sdk": patch
 "@nextlyhq/plugin-seo": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
 "@nextlyhq/prettier-config": patch
-"@nextlyhq/storage-s3": patch
-"@nextlyhq/storage-uploadthing": patch
-"@nextlyhq/storage-vercel-blob": patch
 "@nextlyhq/telemetry": patch
 "@nextlyhq/tsconfig": patch
-"@nextlyhq/ui": patch
+"@nextlyhq/builder": patch
+"@nextlyhq/module-specifiers": patch
 ---
 
 A `single:<slug>` widget source is executable.
diff --git a/.changeset/a-single-publish-revalidates-its-draft.md b/.changeset/a-single-publish-revalidates-its-draft.md
new file mode 100644
index 0000000000..1bd8fc7182
--- /dev/null
+++ b/.changeset/a-single-publish-revalidates-its-draft.md
@@ -0,0 +1,40 @@
+---
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/admin": patch
+"@nextlyhq/admin-css": patch
+"@nextlyhq/blocks-engine": patch
+"@nextlyhq/blocks-react": patch
+"@nextlyhq/builder": patch
+"create-nextly-app": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
+"@nextlyhq/module-specifiers": patch
+"nextly": patch
+"@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-page-builder": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/plugin-seo": patch
+"@nextlyhq/prettier-config": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
+"@nextlyhq/telemetry": patch
+"@nextlyhq/tsconfig": patch
+"@nextlyhq/ui": patch
+"@nextlyhq/plugin-mcp": patch
+---
+
+Publishing a Single now re-judges the pending change it is about to promote, against the schema and the permissions as they stand at that moment.
+
+A Single's publish folds its held draft into the live row. Both gates ran when the caller's payload arrived, and for a publish that payload is just the new status, so the draft's own content reached the live row having been judged only when it was SAVED. Two things could have changed since. The publisher may not be the author, and a field rule can deny them a value the author was allowed to write. And the schema can have tightened under a value that was legal when it was held.
+
+BEHAVIOUR CHANGE, and it is visible. A draft written under an older, looser schema is now REFUSED at the moment someone hits Publish, having raised no complaint when it was saved. The refusal names each field and carries the rule's own message, so the author can see what to fix. Publishing content that violates the current contract is the worse outcome.
+
+A pending change that edits a field the PUBLISHER may not write is refused too, rather than being quietly dropped from the write. A successful publish consumes the pending change, so dropping the value would have published everything else, deleted the draft, and destroyed the author's edit with it. Refusing keeps the draft intact for someone who can write that field. Only a field whose promoted value actually differs from the live row counts: a draft snapshot is a full copy of the document, so a denied field appears in every one of them.
+
+Both gates run over the snapshot being promoted and never over the live document, so a schema change cannot block someone from fixing and republishing unrelated content. They run over that snapshot in its logical shape, so a Single that merely HAS a group, repeater or JSON field is not refused for holding one.
+
+Both publish paths are covered by one gate: the ordinary publish and `publishAllLocales`, which promotes every language's pending change in its own loop and had no such check at all.
diff --git a/.changeset/a-step-offered-is-a-step-finishable.md b/.changeset/a-step-offered-is-a-step-finishable.md
new file mode 100644
index 0000000000..c96ef1343b
--- /dev/null
+++ b/.changeset/a-step-offered-is-a-step-finishable.md
@@ -0,0 +1,38 @@
+---
+"nextly": patch
+"create-nextly-app": patch
+"@nextlyhq/admin": patch
+"@nextlyhq/admin-css": patch
+"@nextlyhq/blocks-engine": patch
+"@nextlyhq/blocks-react": patch
+"@nextlyhq/ui": patch
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
+"@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-mcp": patch
+"@nextlyhq/plugin-page-builder": patch
+"@nextlyhq/plugin-seo": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
+"@nextlyhq/prettier-config": patch
+"@nextlyhq/telemetry": patch
+"@nextlyhq/tsconfig": patch
+"@nextlyhq/builder": patch
+"@nextlyhq/module-specifiers": patch
+---
+
+The setup checklist offers "create your first collection" only to a reader who
+would be able to READ what they create. A new collection's permissions are
+seeded to the super-admin role alone, so a caller holding the definition grant
+and nothing else created the collection, gained no read on it, and found the
+step outstanding permanently -- with the card pinned to their dashboard.
+
+An API key stamped with a read grant is offered the step it can finish: a key
+never gains a permission, but a pre-seeded `read-<slug>` lets it create that
+collection and read it afterwards.
diff --git a/.changeset/a-super-admins-key-copies-the-catalogue.md b/.changeset/a-super-admins-key-copies-the-catalogue.md
index 28b9351557..edeedd3025 100644
--- a/.changeset/a-super-admins-key-copies-the-catalogue.md
+++ b/.changeset/a-super-admins-key-copies-the-catalogue.md
@@ -1,29 +1,30 @@
 ---
-"@nextlyhq/adapter-drizzle": patch
-"@nextlyhq/adapter-mysql": patch
-"@nextlyhq/adapter-postgres": patch
-"@nextlyhq/adapter-sqlite": patch
+"nextly": patch
+"create-nextly-app": patch
 "@nextlyhq/admin": patch
 "@nextlyhq/admin-css": patch
 "@nextlyhq/blocks-engine": patch
 "@nextlyhq/blocks-react": patch
-"@nextlyhq/builder": patch
-"create-nextly-app": patch
-"@nextlyhq/eslint-config": patch
-"@nextlyhq/eslint-plugin": patch
-"@nextlyhq/module-specifiers": patch
-"nextly": patch
+"@nextlyhq/ui": patch
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
 "@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-mcp": patch
 "@nextlyhq/plugin-page-builder": patch
-"@nextlyhq/plugin-sdk": patch
 "@nextlyhq/plugin-seo": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
 "@nextlyhq/prettier-config": patch
-"@nextlyhq/storage-s3": patch
-"@nextlyhq/storage-uploadthing": patch
-"@nextlyhq/storage-vercel-blob": patch
 "@nextlyhq/telemetry": patch
 "@nextlyhq/tsconfig": patch
-"@nextlyhq/ui": patch
+"@nextlyhq/builder": patch
+"@nextlyhq/module-specifiers": patch
 ---
 
 An API key created by a Super Admin copies the permission catalogue rather
diff --git a/.changeset/an-instance-can-be-shown-and-pointed-elsewhere.md b/.changeset/an-instance-can-be-shown-and-pointed-elsewhere.md
new file mode 100644
index 0000000000..64e2c555d2
--- /dev/null
+++ b/.changeset/an-instance-can-be-shown-and-pointed-elsewhere.md
@@ -0,0 +1,38 @@
+---
+"nextly": patch
+"create-nextly-app": patch
+"@nextlyhq/admin": patch
+"@nextlyhq/admin-css": patch
+"@nextlyhq/blocks-engine": patch
+"@nextlyhq/blocks-react": patch
+"@nextlyhq/ui": patch
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
+"@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-mcp": patch
+"@nextlyhq/plugin-page-builder": patch
+"@nextlyhq/plugin-seo": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
+"@nextlyhq/prettier-config": patch
+"@nextlyhq/telemetry": patch
+"@nextlyhq/tsconfig": patch
+"@nextlyhq/builder": patch
+"@nextlyhq/module-specifiers": patch
+---
+
+The instance inspector now edits two more of a component's exposed properties.
+A link is edited as the address its property holds, keyed for an address, and
+clears the property when emptied rather than pointing it at an empty string. A
+visibility property is a checkbox: checked serves the component's node on this
+page, unchecked hides it, and an inherited row reads as shown because that is
+the component's own rule until the definition gates the node itself. Rich text
+and image rows still show their value and source without a control: a passage
+is edited on the canvas, and an image needs a picker the builder cannot reach
+yet.
diff --git a/.changeset/an-instance-shows-what-it-exposes.md b/.changeset/an-instance-shows-what-it-exposes.md
index 9a33505582..5bce041e9e 100644
--- a/.changeset/an-instance-shows-what-it-exposes.md
+++ b/.changeset/an-instance-shows-what-it-exposes.md
@@ -1,29 +1,30 @@
 ---
-"@nextlyhq/adapter-drizzle": patch
-"@nextlyhq/adapter-mysql": patch
-"@nextlyhq/adapter-postgres": patch
-"@nextlyhq/adapter-sqlite": patch
+"nextly": patch
+"create-nextly-app": patch
 "@nextlyhq/admin": patch
 "@nextlyhq/admin-css": patch
 "@nextlyhq/blocks-engine": patch
 "@nextlyhq/blocks-react": patch
-"@nextlyhq/builder": patch
-"create-nextly-app": patch
-"@nextlyhq/eslint-config": patch
-"@nextlyhq/eslint-plugin": patch
-"@nextlyhq/module-specifiers": patch
-"nextly": patch
+"@nextlyhq/ui": patch
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
 "@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-mcp": patch
 "@nextlyhq/plugin-page-builder": patch
-"@nextlyhq/plugin-sdk": patch
 "@nextlyhq/plugin-seo": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
 "@nextlyhq/prettier-config": patch
-"@nextlyhq/storage-s3": patch
-"@nextlyhq/storage-uploadthing": patch
-"@nextlyhq/storage-vercel-blob": patch
 "@nextlyhq/telemetry": patch
 "@nextlyhq/tsconfig": patch
-"@nextlyhq/ui": patch
+"@nextlyhq/builder": patch
+"@nextlyhq/module-specifiers": patch
 ---
 
 Selecting a component instance in the builder now opens its own inspector in
diff --git a/.changeset/bulk-writes-carry-the-localized-split.md b/.changeset/bulk-writes-carry-the-localized-split.md
new file mode 100644
index 0000000000..8af58a2f60
--- /dev/null
+++ b/.changeset/bulk-writes-carry-the-localized-split.md
@@ -0,0 +1,36 @@
+---
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/admin": patch
+"@nextlyhq/admin-css": patch
+"@nextlyhq/blocks-engine": patch
+"@nextlyhq/blocks-react": patch
+"@nextlyhq/builder": patch
+"create-nextly-app": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
+"@nextlyhq/module-specifiers": patch
+"nextly": patch
+"@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-page-builder": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/plugin-seo": patch
+"@nextlyhq/prettier-config": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
+"@nextlyhq/telemetry": patch
+"@nextlyhq/tsconfig": patch
+"@nextlyhq/ui": patch
+---
+
+A bulk write now reaches a localized collection. `createMany` failed every row
+on a collection with `localized: true` — the shared create implementation wrote
+the translatable values to the main table, which has no columns for them, so
+the driver's own message ("no column named …") came back per row. It performs
+the same split as a single create and writes the companion row for the write's
+locale, inside the same transaction; the shared update implementation, which
+had the identical gap, upserts that row. Both refuse a named locale as before:
+these paths write the default language.
diff --git a/.changeset/the-checklist-offers-what-a-reader-can-do.md b/.changeset/the-checklist-offers-what-a-reader-can-do.md
index 6368e0aa1d..00d0e8f477 100644
--- a/.changeset/the-checklist-offers-what-a-reader-can-do.md
+++ b/.changeset/the-checklist-offers-what-a-reader-can-do.md
@@ -24,6 +24,7 @@
 "@nextlyhq/telemetry": patch
 "@nextlyhq/tsconfig": patch
 "@nextlyhq/ui": patch
+"@nextlyhq/plugin-mcp": patch
 ---
 
 The setup checklist offers a reader only the steps they could actually finish.
diff --git a/.changeset/the-promote-gate-judges-the-locked-draft.md b/.changeset/the-promote-gate-judges-the-locked-draft.md
new file mode 100644
index 0000000000..d17ec31e90
--- /dev/null
+++ b/.changeset/the-promote-gate-judges-the-locked-draft.md
@@ -0,0 +1,40 @@
+---
+"@nextlyhq/adapter-drizzle": patch
+"@nextlyhq/adapter-mysql": patch
+"@nextlyhq/adapter-postgres": patch
+"@nextlyhq/adapter-sqlite": patch
+"@nextlyhq/admin": patch
+"@nextlyhq/admin-css": patch
+"@nextlyhq/blocks-engine": patch
+"@nextlyhq/blocks-react": patch
+"@nextlyhq/builder": patch
+"create-nextly-app": patch
+"@nextlyhq/eslint-config": patch
+"@nextlyhq/eslint-plugin": patch
+"@nextlyhq/module-specifiers": patch
+"nextly": patch
+"@nextlyhq/plugin-form-builder": patch
+"@nextlyhq/plugin-page-builder": patch
+"@nextlyhq/plugin-sdk": patch
+"@nextlyhq/plugin-seo": patch
+"@nextlyhq/prettier-config": patch
+"@nextlyhq/storage-s3": patch
+"@nextlyhq/storage-uploadthing": patch
+"@nextlyhq/storage-vercel-blob": patch
+"@nextlyhq/telemetry": patch
+"@nextlyhq/tsconfig": patch
+"@nextlyhq/ui": patch
+"@nextlyhq/plugin-mcp": patch
+---
+
+The promote gate judges the draft the write actually commits.
+
+The gate that re-judges a Single's pending change before it is published ran before the write transaction, where it could only judge a copy of the world as it was. It now runs inside that transaction, on the draft the transaction has locked, which closes what a pre-flight check could not: a draft saved by another writer between the check and the commit is now the draft that is judged; a `beforeChange` hook that turns a status-less edit into a publish no longer slips past a check that ran before the hooks; and `publishAllLocales`, which applies every language's snapshot to one row, now judges the combined result rather than each language against its own shared values. Resolving the caller's grants is the one thing that cannot happen inside a transaction, since it queries the pooled connection that transaction holds, so it is resolved beforehand and handed in.
+
+A field rule on a child of a group or a repeater row is enforced. The check copied the snapshot shallowly, so the rules deleted a denied nested value from the copy and the original alike and the comparison then saw an unchanged container. A denied child is now found at its own depth and named at its own path.
+
+A publish is no longer refused over a field nobody touched. The comparison read the live document through a read that expands an upload or a relationship into the document behind it, while the snapshot holds the identifier, so an untouched field of either kind looked like an edit. Both sides now go through one conversion.
+
+A draft older than a newly required field is refused rather than published. The check judged the promoted document as a patch, which skips absent properties by design, so a snapshot written before a field became required reported nothing and published a document that violates the contract.
+
+An API key is judged on the grants stamped on the key, not on the database roles of whoever owns it.
diff --git a/docs/plugins/services.mdx b/docs/plugins/services.mdx
index 3732e325f5..47f0ed5efb 100644
--- a/docs/plugins/services.mdx
+++ b/docs/plugins/services.mdx
@@ -109,6 +109,7 @@ read and is refused on a write, and a selector is refused on both.
 | `deleteEntry(slug, id, opts?)` | Delete one. Returns `{ message, item: { id }, warnings? }`. |
 | `count(slug, where?, opts?)` | Count matching rows. |
 | `createMany(slug, rows, opts?)` | Bulk insert → `BatchOperationResult`. |
+| `updateMany(slug, entries, opts?)` | Bulk update, one `{ id, data }` per row → `BatchOperationResult`. |
 
 `ctx.services` also exposes `users`, `media`, and `email` services.
 
@@ -138,14 +139,75 @@ populating relations and is cheaper.
 
 ## Bulk operations
 
-`createMany` returns a `BatchOperationResult` with index-keyed errors, so a partial
-failure tells you exactly which rows failed:
+`createMany` and `updateMany` return a `BatchOperationResult`, so a partial failure
+tells you exactly which rows failed and leaves the rest committed:
 
 ```ts
 const res = await ctx.services.collections.createMany(slug, rows, { as: "system" });
 // { successful, failed, ids: string[], errors: [{ index, error }] }
 ```
 
+`updateMany` takes one `{ id, data }` per row, so a single call can apply a
+**different** patch to each row. Applying the same patch to many rows is the same
+call with the patch repeated:
+
+```ts
+const res = await ctx.services.collections.updateMany(
+  slug,
+  [
+    { id: "post-1", data: { status: "published" } },
+    { id: "post-2", data: { status: "archived", pinned: false } },
+  ],
+  { as: "system" }
+);
+```
+
+`errors[].index` indexes **the array you passed**, so the row a failure is about is
+`entries[index].id`. The result shape is shared with `createMany`, which has no
+caller-supplied ids to key its failures by.
+
+To update every row matching a filter, list them first and map the ids. There is no
+by-filter batch update, deliberately: a filter that matches more than the author meant
+is the failure this surface has no way to take back.
+
+`listEntries` returns one page, so page through it. The loop below re-reads page 1
+each time on purpose: every updated row leaves the `draft` filter, so the rows that
+still match move up into it.
+
+```ts
+let updated = 0;
+for (;;) {
+  const page = await ctx.services.collections.listEntries(
+    slug,
+    { where: { status: "draft" }, pagination: { limit: 100 }, depth: 0 },
+    { as: "system" }
+  );
+  if (page.data.length === 0) break;
+
+  const res = await ctx.services.collections.updateMany(
+    slug,
+    page.data.map((row: { id: string }) => ({
+      id: row.id,
+      data: { status: "published" },
+    })),
+    { as: "system" }
+  );
+  updated += res.successful;
+  // Nothing moved: the rest are failing rather than draining, so stop rather
+  // than read the same page forever.
+  if (res.successful === 0) break;
+}
+```
+
+When the patch does NOT change what the filter matches, page with
+`pagination: { page: n }` instead and stop when `pagination.hasMore` is false, or the
+loop above would re-read the same rows.
+
+Neither takes a `locale`: the bulk pipeline writes in one pass and cannot store a
+translation, so both refuse one by name rather than filing every row under the default
+language. Write the rows one at a time with `createEntry` or `updateEntry` when a
+language matters.
+
 ## Writes return an envelope
 
 `createEntry`, `updateEntry` and `deleteEntry` resolve to
diff --git a/packages/builder/src/instance-inspector-panel.test.tsx b/packages/builder/src/instance-inspector-panel.test.tsx
index 86f8ff2f68..8ff37a46a9 100644
--- a/packages/builder/src/instance-inspector-panel.test.tsx
+++ b/packages/builder/src/instance-inspector-panel.test.tsx
@@ -383,6 +383,206 @@ describe("a choice with an empty option", () => {
   });
 });
 
+describe("a link and a visibility exposure", () => {
+  const linked = () =>
+    header({
+      nodes: [
+        {
+          id: "h1",
+          type: "acme/cta",
+          version: 1,
+          props: { text: "Read more", href: "/docs" },
+        },
+      ],
+      exposed: [
+        {
+          id: "cta",
+          label: "Call to action",
+          nodeId: "h1",
+          propPath: "href",
+          type: "link",
+        },
+        {
+          id: "shown",
+          label: "Newsletter form",
+          nodeId: "h1",
+          propPath: "visibility",
+          type: "visibility",
+        },
+      ],
+    });
+
+  it("edits a link as the address it holds, and clears it when emptied", () => {
+    // The same field a url prop gets in the block inspector, keyed for an
+    // address. Emptied, it clears rather than writing "" — an href of ""
+    // points at the page itself.
+    const editor = mount(instance(), linked());
+    const field = screen.getByRole("textbox", {
+      name: "Call to action",
+    }) as HTMLInputElement;
+
+    expect(field.value).toBe("/docs");
+    expect(field.inputMode).toBe("url");
+    fireEvent.change(field, { target: { value: "https://example.test/go" } });
+    fireEvent.blur(field);
+
+    expect(appliedProps(editor)).toEqual({
+      componentId: "header",
+      overrides: { cta: "https://example.test/go" },
+    });
+    cleanup();
+
+    const emptied = mount(instance({ overrides: { cta: "/go" } }), linked());
+    const again = screen.getByRole("textbox", { name: "Call to action" });
+    fireEvent.change(again, { target: { value: "" } });
+    fireEvent.blur(again);
+    expect(appliedProps(emptied)).toEqual({
+      componentId: "header",
+      overrides: { cta: { $unset: true } },
+    });
+  });
+
+  it("still offers a SELECT's options when its stored value is structured", () => {
+    // Unlike a text field, a select does not carry the old value into what it
+    // writes: choosing an option replaces it outright. So a junk value there is
+    // repairable by using the control, and hiding it would strand the property.
+    mount(instance({ overrides: { tone: { unexpected: true } } }), header());
+
+    expect(screen.getByRole("combobox", { name: "Tone" })).toBeDefined();
+  });
+
+  it("still offers the field for a CLEARED text row, so the author can put a value back", () => {
+    // A clear is a blank the field is meant to show, not a value the control
+    // cannot hold — read as unrepresentable, clearing a property would make it
+    // permanently uneditable.
+    mount(instance({ overrides: { cta: { $unset: true } } }), linked());
+
+    expect(
+      screen.getByRole("textbox", { name: "Call to action" })
+    ).toBeDefined();
+  });
+
+  it("shows a STRUCTURED value rather than offering to overwrite it with text", () => {
+    /*
+     * `OverrideValue` is unconstrained, so a host block may declare a link prop
+     * as an object. A text control renders one as an empty field — there is no
+     * string to show — and the first edit replaces the whole value with
+     * whatever was typed into that blank, losing the rest of it silently.
+     *
+     * Shown read-only instead, through the same note a type this panel cannot
+     * edit yet uses: the author sees what is there and nothing overwrites it.
+     */
+    const editor = mount(
+      instance({ overrides: { cta: { href: "/docs", rel: "nofollow" } } }),
+      linked()
+    );
+
+    expect(
+      screen.queryByRole("textbox", { name: "Call to action" })
+    ).toBeNull();
+    expect(screen.getByText(/nofollow/)).toBeDefined();
+    // Nothing to type into means nothing written: the value is intact.
+    expect(editor.apply).not.toHaveBeenCalled();
+  });
+
+  it("shows an inherited visibility row as shown, and hides it by writing false", () => {
+    // Inherited is the component's own rule, which is shown unless the
+    // definition gates the node itself; the resolver reads `false` as hidden
+    // and `true` as shown, and nothing else.
+    const editor = mount(instance(), linked());
+    const box = screen.getByRole("checkbox", { name: "Newsletter form" });
+
+    expect(box.getAttribute("aria-checked")).toBe("true");
+    fireEvent.click(box);
+
+    expect(appliedProps(editor)).toEqual({
+      componentId: "header",
+      overrides: { shown: false },
+    });
+  });
+
+  it("shows a row the DEFINITION gates as not shown, and turns it on by writing true", () => {
+    /*
+     * The component's own rule is not always "shown". A definition node
+     * carrying entry-field conditions is withheld by the renderer's
+     * hidden-node pass, and the resolver keeps the gate for it to act on — so
+     * a checkbox drawn from "no override written" told the author the node was
+     * on this page while the canvas did not draw it.
+     *
+     * Clicking it writes `true`, which is the one thing that removes the
+     * component's gate for this instance.
+     */
+    const gated = () =>
+      header({
+        nodes: [
+          {
+            id: "h1",
+            type: "acme/cta",
+            version: 1,
+            props: { text: "Read more", href: "/docs" },
+            visibility: {
+              conditions: [[{ field: "tier", op: "eq", value: "pro" }]],
+            },
+          } as never,
+        ],
+        exposed: [
+          {
+            id: "shown",
+            label: "Newsletter form",
+            nodeId: "h1",
+            propPath: "visibility",
+            type: "visibility",
+          },
+        ],
+      });
+    const editor = mount(instance(), gated());
+    const box = screen.getByRole("checkbox", { name: "Newsletter form" });
+
+    expect(box.getAttribute("aria-checked")).toBe("false");
+    // And not as the author's own doing: there is nothing of theirs to reset.
+    expect(screen.queryByRole("button", { name: /reset/i })).toBeNull();
+
+    fireEvent.click(box);
+
+    expect(appliedProps(editor)).toEqual({
+      componentId: "header",
+      overrides: { shown: true },
+    });
+  });
+
+  it("shows a hidden row unchecked — cleared included, which the page reads as hidden — and shows it again by writing true", () => {
+    const hidden = mount(instance({ overrides: { shown: false } }), linked());
+    const box = screen.getByRole("checkbox", { name: "Newsletter form" });
+    expect(box.getAttribute("aria-checked")).toBe("false");
+    fireEvent.click(box);
+    expect(appliedProps(hidden)).toEqual({
+      componentId: "header",
+      overrides: { shown: true },
+    });
+    cleanup();
+
+    mount(instance({ overrides: { shown: { $unset: true } } }), linked());
+    expect(
+      screen
+        .getByRole("checkbox", { name: "Newsletter form" })
+        .getAttribute("aria-checked")
+    ).toBe("false");
+    expect(screen.getByText("Cleared")).toBeDefined();
+  });
+
+  it("offers the reset on a visibility override, which returns it to the component's rule", () => {
+    const editor = mount(instance({ overrides: { shown: false } }), linked());
+
+    fireEvent.click(
+      screen.getByRole("button", {
+        name: "Reset Newsletter form to the component's value",
+      })
+    );
+
+    expect(appliedProps(editor)).toStrictEqual({ componentId: "header" });
+  });
+});
+
 /**
  * A select offering `""` and `"\u0000"`: both are legal option values, and a
  * spelling that gave `""` a sentinel of its own made the two one item value.
diff --git a/packages/builder/src/instance-inspector-panel.tsx b/packages/builder/src/instance-inspector-panel.tsx
index 49bc61b006..6104401cce 100644
--- a/packages/builder/src/instance-inspector-panel.tsx
+++ b/packages/builder/src/instance-inspector-panel.tsx
@@ -37,6 +37,7 @@ import {
 } from "@nextlyhq/blocks-engine";
 import {
   Button,
+  Checkbox,
   Input,
   Label,
   Select,
@@ -313,7 +314,14 @@ function ExposedControl({
       </p>
     );
   }
-  if (!row.supported) {
+  // A type this panel has no control for, OR a value its control could not
+  // represent. The second is not a shape problem to report: `OverrideValue` is
+  // unconstrained and a host block may declare a text or link prop as an
+  // object, which a text field renders as a blank — and the first edit then
+  // replaces the whole value with what was typed into that blank. Shown rather
+  // than offered for editing, so nothing is lost to a control that cannot hold
+  // it.
+  if (!row.supported || !representable(row)) {
     const shown = valueSummary(row.value);
     return (
       <p className="nx-inspector__note">
@@ -322,6 +330,9 @@ function ExposedControl({
       </p>
     );
   }
+  if (row.type === "visibility") {
+    return <ExposedVisibilityField id={id} row={row} onSet={onSet} />;
+  }
   if (row.type === "select") {
     return (
       <Select
@@ -397,6 +408,27 @@ function dataOf(value: object): string {
   }
 }
 
+/**
+ * Whether this row's control can hold the value in force.
+ *
+ * Only the TEXT controls can fail this, and only on a structured value: a
+ * blank is what the field is meant to show, and a boolean or a number reads
+ * back as itself. A CLEARED row is a blank too and needs no case of its own —
+ * the resolver normalises a cleared value to `undefined` rather than handing
+ * the sentinel on, which is the contract `instanceExposure` states.
+ *
+ * A select and a visibility row always pass. Neither carries the old value into
+ * what it writes — choosing an option or ticking a box replaces it outright —
+ * so a value they cannot show is repairable by using the control, and hiding it
+ * would strand the property instead.
+ */
+function representable(row: ExposedRow): boolean {
+  if (row.type === "visibility" || row.type === "select") return true;
+  const { value } = row;
+  if (value === undefined || value === null) return true;
+  return typeof value !== "object";
+}
+
 /** A value as editable text, or empty when it is not representable. */
 function storedText(value: OverrideValue): string {
   if (value === undefined || value === null) return "";
@@ -441,6 +473,9 @@ function ExposedTextField({
     <Input
       id={id}
       value={draft}
+      // Keyed for an address when the exposure is one, as the block inspector
+      // keys a url prop: the value is the same string either way.
+      inputMode={row.type === "link" ? "url" : undefined}
       onChange={event => setDraft(event.target.value)}
       onBlur={send}
       // Enter commits as well as blur, as every single-line field here does.
@@ -454,6 +489,39 @@ function ExposedTextField({
   );
 }
 
+/**
+ * A visibility exposure: whether the node it aims at is served on this page.
+ *
+ * A checkbox, committed at once — there is nothing to coalesce. It writes
+ * `true` or `false` and nothing else, because those are the two values the
+ * resolver reads there: a cleared override hides, and anything else is
+ * ignored with the component's own rule left in force. So checked means
+ * "shown", and an INHERITED row reads as shown: the component's rule is to
+ * serve the node unless the definition gates it itself, and the source badge
+ * beside the box says which it is.
+ */
+function ExposedVisibilityField({
+  id,
+  row,
+  onSet,
+}: {
+  id: string;
+  row: ExposedRow;
+  onSet: (id: string, value: OverrideValue) => void;
+}): React.JSX.Element {
+  const shown = row.value !== false && !row.cleared;
+  return (
+    <div className="nx-inspector__field--inline">
+      <Checkbox
+        id={id}
+        checked={shown}
+        onCheckedChange={checked => onSet(row.id, checked === true)}
+      />
+      <span className="nx-inspector__note">Shown on this page</span>
+    </div>
+  );
+}
+
 /**
  * Values this instance stores for properties the definition no longer
  * exposes.
diff --git a/packages/builder/src/instance-inspector.test.ts b/packages/builder/src/instance-inspector.test.ts
index ff46a12cf1..561f4a0363 100644
--- a/packages/builder/src/instance-inspector.test.ts
+++ b/packages/builder/src/instance-inspector.test.ts
@@ -220,7 +220,56 @@ describe("the rows", () => {
       ["select", true],
       ["image", false],
     ]);
-    expect([...EDITABLE_EXPOSED_TYPES]).toEqual(["text", "select"]);
+    expect([...EDITABLE_EXPOSED_TYPES]).toEqual([
+      "text",
+      "select",
+      "link",
+      "visibility",
+    ]);
+  });
+
+  it("carries a link and a visibility row as editable, and a rich text row as not", () => {
+    // A link exposure holds what its url prop holds, a string, and a
+    // visibility exposure a boolean the resolver reads as shown or hidden;
+    // both have a control. Rich text is edited on the canvas, not here.
+    const more = header({
+      exposed: [
+        {
+          id: "cta",
+          label: "Call to action",
+          nodeId: "h1",
+          propPath: "href",
+          type: "link",
+        },
+        {
+          id: "shown",
+          label: "Shown",
+          nodeId: "h1",
+          propPath: "visibility",
+          type: "visibility",
+        },
+        {
+          id: "body",
+          label: "Body",
+          nodeId: "h1",
+          propPath: "body",
+          type: "richText",
+        },
+      ],
+    });
+    const rows =
+      inspectInstance(
+        pageOf(instance()),
+        "i1",
+        lookupOf(["header", more]),
+        LIBRARY
+      )?.rows ?? [];
+
+    expect(rows.map(row => [row.id, row.supported])).toEqual([
+      ["cta", true],
+      ["shown", true],
+      ["body", false],
+    ]);
   });
 
   it("reports a cleared row as cleared, with no value", () => {
diff --git a/packages/builder/src/instance-inspector.ts b/packages/builder/src/instance-inspector.ts
index be3ce38800..b4ff9f1888 100644
--- a/packages/builder/src/instance-inspector.ts
+++ b/packages/builder/src/instance-inspector.ts
@@ -44,12 +44,20 @@ import type { BuilderOp, NodePatch } from "./ops";
  *
  * Named as a set rather than inferred from what the switch happens to handle,
  * for the reason `SUPPORTED_PROP_TYPES` is: an exposed type with no control is
- * a KNOWN gap the row states, never a silent fallthrough. Rich text, images,
- * links and visibility have no control yet; a row of one of those still shows
- * its value and its source, and still offers a reset, because withholding the
- * row would present a component as exposing less than it does.
+ * a KNOWN gap the row states, never a silent fallthrough. A link is edited as
+ * the address its prop holds and visibility as shown-or-hidden; rich text and
+ * images have no control here yet — a passage is edited on the canvas, and an
+ * image needs a picker this package cannot reach — and a row of either still
+ * shows its value and its source, and still offers a reset, because
+ * withholding the row would present a component as exposing less than it
+ * does.
  */
-export const EDITABLE_EXPOSED_TYPES = ["text", "select"] as const;
+export const EDITABLE_EXPOSED_TYPES = [
+  "text",
+  "select",
+  "link",
+  "visibility",
+] as const;
 
 /** One exposed property, with everything a row needs to draw itself. */
 export interface ExposedRow {
diff --git a/packages/nextly/src/api/widget-query.test.ts b/packages/nextly/src/api/widget-query.test.ts
index 314f74dadf..6c059c875c 100644
--- a/packages/nextly/src/api/widget-query.test.ts
+++ b/packages/nextly/src/api/widget-query.test.ts
@@ -938,3 +938,170 @@ describe("a body that is not JSON at all", () => {
     expect(executeWidgetQuery).not.toHaveBeenCalled();
   });
 });
+
+describe("a slot that never settles", () => {
+  /**
+   * A source answered by a resolver, registered the way boot registers one.
+   *
+   * The kind matters to the assertion rather than to the timer: a
+   * resolver-answered source is the one that can make a network call, and a
+   * dead outbound connection does not reject -- it hangs. That is the shape
+   * the bound exists for.
+   */
+  function registerHangingSource(id: string): void {
+    registerSystemSource(
+      {
+        id,
+        label: "Slow",
+        kind: "system",
+        supports: ["count"],
+        fields: [{ name: "total", type: "number" }],
+      },
+      () => new Promise<never>(() => {})
+    );
+  }
+
+  afterEach(() => {
+    vi.useRealTimers();
+  });
+
+  it("fails the hung slot alone, and the rest of the batch still answers", async () => {
+    // 🔴 The defect: the batch aggregates with `Promise.all`, so it is only as
+    // fast as its slowest slot. One query that never settles held every other
+    // card behind it and the reader saw NOTHING -- not seven cards and one
+    // error, which is what the per-slot shape exists to produce.
+    vi.useFakeTimers();
+    registerHangingSource("system:slow");
+    executeWidgetQuery.mockImplementation((query: { source: string }) =>
+      query.source === "system:slow"
+        ? new Promise(() => {})
+        : Promise.resolve({ op: "count", total: 7 })
+    );
+
+    const pending = postWidgetQuery(
+      makeReq({
+        queries: [
+          { source: "system:slow", op: "count" },
+          { source: "collection:posts", op: "count" },
+        ],
+      })
+    );
+
+    // Past the bound. `Async` because the race settles on a microtask that a
+    // synchronous timer advance would never let run.
+    await vi.advanceTimersByTimeAsync(31_000);
+    const slots = await slotsOf(await pending);
+
+    expect(slots[0].ok).toBe(false);
+    expect(slots[0].error).toMatch(/took too long/i);
+    // The control, and the whole point: the sibling was not held behind it.
+    expect(slots[1].ok).toBe(true);
+  });
+
+  it("names the source in the log, where an operator can act on it", async () => {
+    // The caller is told their card timed out; only the log says WHICH source
+    // is hanging, which is the half an operator needs.
+    vi.useFakeTimers();
+    registerHangingSource("system:slow");
+    executeWidgetQuery.mockImplementation(() => new Promise(() => {}));
+
+    const pending = postWidgetQuery(
+      makeReq({ queries: [{ source: "system:slow", op: "count" }] })
+    );
+    await vi.advanceTimersByTimeAsync(31_000);
+    await pending;
+
+    expect(
+      logged.some(
+        entry =>
+          JSON.stringify(entry).includes("widget-slot-timeout") &&
+          JSON.stringify(entry).includes("system:slow")
+      )
+    ).toBe(true);
+  });
+
+  it("does not fail a slot that answers within the bound", async () => {
+    // The must-differ half. Without it a bound of zero -- or one that fired
+    // unconditionally -- satisfies both cases above.
+    vi.useFakeTimers();
+    registerHangingSource("system:slow");
+    executeWidgetQuery.mockResolvedValue({ op: "count", total: 4 });
+
+    const pending = postWidgetQuery(
+      makeReq({ queries: [{ source: "system:slow", op: "count" }] })
+    );
+    await vi.advanceTimersByTimeAsync(29_000);
+    const slots = await slotsOf(await pending);
+
+    expect(slots[0].ok).toBe(true);
+  });
+});
+
+describe("a resolver that returns something the response cannot encode", () => {
+  it("fails that slot alone, and the rest of the batch still answers", async () => {
+    // 🔴 `respondData` calls `JSON.stringify` over the WHOLE results array,
+    // after `Promise.all` and outside every slot's catch. So a value the
+    // encoder refuses used to throw at the response and answer 500 with every
+    // sibling's rows discarded -- one plugin's bad row blanking the dashboard,
+    // which is the outcome the per-slot shape exists to prevent.
+    // Both slots name the SAME registered source, dispatching on the op. An
+    // earlier revision used a second, unregistered source for the bad slot --
+    // which failed as "unavailable source" before the executor ran at all, so
+    // the case passed with this guard removed.
+    executeWidgetQuery.mockImplementation((query: { op: string }) => {
+      if (query.op === "list") {
+        const cyclic: Record<string, unknown> = { name: "loop" };
+        cyclic.self = cyclic;
+        return Promise.resolve({ op: "list", items: [cyclic] });
+      }
+      return Promise.resolve({ op: "count", total: 5 });
+    });
+
+    const res = await postWidgetQuery(
+      makeReq({
+        queries: [
+          { source: "collection:posts", op: "list" },
+          { source: "collection:posts", op: "count" },
+        ],
+      })
+    );
+
+    // A 200 with slots, not a request-level failure.
+    expect(res.status).toBe(200);
+    const slots = await slotsOf(res);
+    expect(slots[0].ok).toBe(false);
+    // The control, and the whole point: the sibling was not blanked.
+    expect(slots[1].ok).toBe(true);
+  });
+
+  it("says so in the log, naming the source", async () => {
+    executeWidgetQuery.mockImplementation(() =>
+      Promise.resolve({ op: "list", items: [{ big: BigInt(1) }] })
+    );
+
+    await postWidgetQuery(
+      makeReq({ queries: [{ source: "collection:posts", op: "list" }] })
+    );
+
+    expect(
+      logged.some(entry =>
+        JSON.stringify(entry).includes("widget-result-unserialisable")
+      )
+    ).toBe(true);
+  });
+
+  it("passes an ordinary result through unchanged", async () => {
+    // The must-differ half. Without it a guard that failed every slot -- or
+    // one that quietly emptied results -- satisfies both cases above.
+    executeWidgetQuery.mockResolvedValue({ op: "count", total: 11 });
+
+    const res = await postWidgetQuery(
+      makeReq({ queries: [{ source: "collection:posts", op: "count" }] })
+    );
+    const body = (await res.json()) as {
+      results: Array<{ ok: boolean; result?: { total?: number } }>;
+    };
+    expect(body.results[0].ok).toBe(true);
+    expect(body.results[0].result?.total).toBe(11);
+  });
+});
diff --git a/packages/nextly/src/api/widget-query.ts b/packages/nextly/src/api/widget-query.ts
index 3091fa3f26..f38486400e 100644
--- a/packages/nextly/src/api/widget-query.ts
+++ b/packages/nextly/src/api/widget-query.ts
@@ -30,7 +30,7 @@ import {
   resolveWidgetSource,
   validateReadWidgetQuery,
 } from "../domains/widgets/query";
-import type { WidgetSlot } from "../domains/widgets/result";
+import type { WidgetResult, WidgetSlot } from "../domains/widgets/result";
 import { failUnavailableSourceOrOp } from "../domains/widgets/sources";
 import { NextlyError } from "../errors/nextly-error";
 import { getCachedNextly } from "../init";
@@ -350,6 +350,104 @@ async function warmReadDecisions(
 }
 
 /** Authorizes, validates and runs one already-prepared query. */
+/**
+ * How long one slot may take before the batch stops waiting for it.
+ *
+ * 🔴 The batch aggregates with `Promise.all`, so it is only as fast as its
+ * SLOWEST slot: one query that never settles holds every other card on the
+ * dashboard behind it, and the reader sees nothing at all rather than the
+ * seven cards that answered. That is the failure this bound exists for, and it
+ * is not hypothetical for a source answered by a resolver -- a resolver may
+ * make a network call, and a dead outbound connection does not reject, it
+ * hangs for whatever the socket's own timeout is.
+ *
+ * Thirty seconds, following Grafana's `[dataproxy] timeout` default for the
+ * same kind of call. Generous on purpose: the bound is here to stop a hang
+ * becoming an outage, not to police a slow-but-working query, and cutting off
+ * a large but legitimate aggregate would be a worse card than a slow one.
+ */
+const SLOT_TIMEOUT_MS = 30_000;
+
+/**
+ * Runs `work`, giving up on it after {@link SLOT_TIMEOUT_MS}.
+ *
+ * 🔴 A race ABANDONS rather than cancels, and it cannot do otherwise: a
+ * promise has no cancellation, so the work goes on running after this returns.
+ * Two consequences are handled here rather than left to surprise someone.
+ *
+ * The abandoned promise may reject later, with nobody awaiting it -- an
+ * unhandled rejection, which crashes the process under Node's default policy.
+ * So a no-op handler is attached to the ORIGINAL promise, which marks it
+ * handled without changing what the race sees.
+ *
+ * And the timer must not hold the event loop open: a slot that answered in a
+ * millisecond would otherwise keep the process alive for the remaining thirty
+ * seconds, which in a test run means a suite that will not exit.
+ */
+async function withinSlotBudget<T>(
+  work: Promise<T>,
+  onTimeout: () => never
+): Promise<T> {
+  let timer: ReturnType<typeof setTimeout> | undefined;
+  const timedOut = Symbol("widget-slot-timeout");
+  try {
+    // Attached to `work` itself, not to the race's result: the race settles on
+    // whichever arm wins, so on a timeout nothing would ever observe `work`.
+    void work.catch(() => undefined);
+
+    const deadline = new Promise<typeof timedOut>(resolve => {
+      timer = setTimeout(() => resolve(timedOut), SLOT_TIMEOUT_MS);
+      timer.unref?.();
+    });
+
+    const outcome = await Promise.race([work, deadline]);
+    // `onTimeout` returns `never`, so the compiler narrows `outcome` to `T`
+    // past this line without an assertion.
+    if (outcome === timedOut) onTimeout();
+    return outcome;
+  } finally {
+    if (timer) clearTimeout(timer);
+  }
+}
+
+/**
+ * The result, proven to survive the response encoder, inside the slot's own
+ * boundary.
+ *
+ * 🔴 `respondData` calls `JSON.stringify` over the WHOLE results array, after
+ * `Promise.all` has assembled it and outside every slot's `catch`. So a value
+ * the encoder refuses does not fail its own slot -- it throws at the response,
+ * and the endpoint answers 500 with every sibling's rows discarded. One
+ * plugin's bad row blanks the dashboard, which is the precise outcome the
+ * per-slot shape exists to prevent.
+ *
+ * `WidgetResult`'s rows are `Record<string, unknown>`, so a `bigint`, a cycle
+ * or a throwing `toJSON` all satisfy the type. A resolver is third-party code;
+ * it is not the host's business to trust that it returned something encodable,
+ * and the type system cannot say so.
+ *
+ * Encoded HERE, where a failure is caught and becomes this slot's error. The
+ * cost is one serialization of a payload that is about to be serialized
+ * anyway, and the parse back is what keeps the encoder from doing it twice on
+ * a value it has already refused once.
+ */
+function serialisable(result: WidgetResult, source: string): WidgetResult {
+  try {
+    return JSON.parse(JSON.stringify(result)) as WidgetResult;
+  } catch (error) {
+    throw new NextlyError({
+      code: "INTERNAL_ERROR",
+      publicMessage: "This widget returned something that could not be sent",
+      logMessage: `widget source "${source}" returned an unserialisable result`,
+      logContext: {
+        reason: "widget-result-unserialisable",
+        source,
+        err: error instanceof Error ? error.message : String(error),
+      },
+    });
+  }
+}
+
 async function runPrepared(
   entry: Extract<PreparedQuery, { ok: true }>,
   caller: ReadCaller,
@@ -362,8 +460,27 @@ async function runPrepared(
       entry.parsed,
       entry.executable.source
     );
-    const result = await executeWidgetQuery(query, caller);
-    return { ok: true, result };
+    const result = await withinSlotBudget(
+      executeWidgetQuery(query, caller),
+      () => {
+        // A `NextlyError`, so `failedSlot` puts THIS sentence on the wire
+        // rather than the generic one: a card that timed out is worth telling
+        // its reader about, and the source id is already known to them --
+        // they placed the card. The slug travels in `logContext` for the
+        // operator, who needs to know WHICH source is hanging.
+        throw new NextlyError({
+          code: "INTERNAL_ERROR",
+          publicMessage: "This widget took too long to answer",
+          logMessage: `widget source "${query.source}" exceeded ${SLOT_TIMEOUT_MS}ms`,
+          logContext: {
+            reason: "widget-slot-timeout",
+            source: query.source,
+            timeoutMs: SLOT_TIMEOUT_MS,
+          },
+        });
+      }
+    );
+    return { ok: true, result: serialisable(result, query.source) };
   } catch (error) {
     return failedSlot(error);
   }
diff --git a/packages/nextly/src/auth/new-entity-access-policy.ts b/packages/nextly/src/auth/new-entity-access-policy.ts
new file mode 100644
index 0000000000..d313ab490c
--- /dev/null
+++ b/packages/nextly/src/auth/new-entity-access-policy.ts
@@ -0,0 +1,70 @@
+/**
+ * Who can end up able to READ a collection they create, declared once.
+ *
+ * 🔴 Two places need this answer and they must not each carry it. The SEEDER
+ * assigns a new collection's freshly created CRUD permissions to one role. The
+ * dashboard's onboarding checklist asks the mirror question -- would THIS
+ * reader be able to read a collection they create -- to decide whether to offer
+ * the "create your first collection" step at all.
+ *
+ * Restated in the second, the two drift silently and in both directions: if
+ * creation began granting the creator, the checklist would go on hiding a step
+ * that had become finishable; if the assignment moved to another role, it would
+ * offer one that had stopped being. Neither shows up as a failure anywhere --
+ * the reader just sees a checklist that is wrong about them.
+ *
+ * So the recipient is named ONCE below and the predicate is computed FROM it.
+ * Sharing only the literal was not enough: a previous revision kept the
+ * membership test hard-coded as `isSuperAdmin` beside the constant, so moving
+ * the recipient would have moved the seeder and left the predicate behind.
+ *
+ * @module auth/new-entity-access-policy
+ */
+
+import { listRoleSlugsForUser } from "../services/lib/permissions";
+
+/**
+ * The role slug a newly seeded entity's permissions are assigned to.
+ *
+ * `PermissionSeedService.assignNewPermissionsToSuperAdmin` selects the role by
+ * it, and {@link wouldReadOwnNewCollection} tests membership of it.
+ */
+export const NEW_ENTITY_PERMISSION_ROLE = "super-admin";
+
+/** How the caller a widget resolver holds is described to this policy. */
+export interface NewEntityAccessCaller {
+  userId: string;
+  /** An API key is judged on the scope stamped into it, never on its owner's roles. */
+  isApiKey: boolean;
+  /** The key's own stamped permission slugs. Empty for a session caller. */
+  permissions: readonly string[];
+}
+
+/**
+ * Whether this caller could end up reading a collection they create.
+ *
+ * Two routes, because two things can make a not-yet-existing collection
+ * readable, and only one of them is the seeding.
+ *
+ * A SESSION caller reaches it through the seeding: they hold
+ * {@link NEW_ENTITY_PERMISSION_ROLE}, so the permissions the seeder assigns
+ * land on a role they are in. Membership is read from their role slugs rather
+ * than through a named super-admin test, so the constant above is genuinely
+ * the single point of change.
+ *
+ * An API KEY reaches it a different way and must not be refused outright. A
+ * key never GAINS a grant -- it is judged on the scope stamped into it when it
+ * was minted -- but a permission may be pre-seeded, and `canReadEntity` accepts
+ * a key's exact `read-<slug>` grant once that collection exists. So a key
+ * stamped `read-reports` can finish the step by creating `reports`, and the
+ * step is finishable exactly when it carries some read grant to create into.
+ */
+export async function wouldReadOwnNewCollection(
+  caller: NewEntityAccessCaller
+): Promise<boolean> {
+  if (caller.isApiKey) {
+    return caller.permissions.some(slug => slug.startsWith("read-"));
+  }
+  const roles = await listRoleSlugsForUser(caller.userId);
+  return roles.includes(NEW_ENTITY_PERMISSION_ROLE);
+}
diff --git a/packages/nextly/src/di/__tests__/register-widgets.test.ts b/packages/nextly/src/di/__tests__/register-widgets.test.ts
index 673f322fa5..446e1e2a29 100644
--- a/packages/nextly/src/di/__tests__/register-widgets.test.ts
+++ b/packages/nextly/src/di/__tests__/register-widgets.test.ts
@@ -118,6 +118,43 @@ describe("resetWidgetRegistries", () => {
     expect(systemResolver(RELEASES_SOURCE_ID)).toBeDefined();
   });
 
+  it("does NOT register a plugin's contributed source, which needs a context this runs before", () => {
+    // 🔴 An ordering fact, not a preference. This function runs before
+    // `initializePlugins` has built any plugin context, and a contributed
+    // resolver without its context can answer nothing -- a plugin's data
+    // services are reachable through nothing else. Registering here would
+    // publish a source whose resolver could only return constants.
+    //
+    // They register from `initializePlugins`, each bound to its own plugin's
+    // context, which `plugin-widget-source.integration.test.ts` exercises
+    // through a real boot.
+    resetWidgetRegistries([
+      {
+        name: "@acme/stripe",
+        contributes: {
+          widgetSources: [
+            {
+              source: {
+                id: "plugin:stripe/revenue",
+                label: "Revenue",
+                kind: "plugin",
+                supports: ["count"],
+                fields: [{ name: "total", type: "number" }],
+              },
+              resolve: () =>
+                Promise.resolve({ op: "count" as const, total: 3 }),
+            },
+          ],
+        },
+      } as never,
+    ]);
+
+    expect(getSource("plugin:stripe/revenue")).toBeUndefined();
+    // The control: core's own sources DID register in the same call, so this
+    // cannot pass by registering nothing at all.
+    expect(getSource(RELEASES_SOURCE_ID)).toBeDefined();
+  });
+
   it("leaves the deferral store alone, because it has not synced anything yet", () => {
     // 🔴 The reset runs BEFORE the boot syncs any metadata, so clearing here
     // would publish "nothing is withheld" on the strength of work that has not
diff --git a/packages/nextly/src/di/register.ts b/packages/nextly/src/di/register.ts
index 706f3bf825..582289db33 100644
--- a/packages/nextly/src/di/register.ts
+++ b/packages/nextly/src/di/register.ts
@@ -95,6 +95,7 @@ import type { WebhookDeliveryQueryService } from "../domains/webhooks/services/w
 import type { WebhookEndpointService } from "../domains/webhooks/services/webhook-endpoint-service";
 import { publishStoredWebhookRecordingPolicies } from "../domains/webhooks/stored-recording-policy";
 import type { DeferrableEntityKind } from "../domains/widgets/deferred-entities";
+import { registerResolvedSource } from "../domains/widgets/resolved-sources";
 import { NextlyError } from "../errors/nextly-error";
 import { getEventBus } from "../events/event-bus";
 import type { FieldGroupConfig } from "../field-groups/config/types";
@@ -147,6 +148,7 @@ import { clearPluginSubscriptions } from "../plugins/subscription-tracker";
 import { assertAdminWidgets } from "../plugins/validate-admin-widgets";
 import { validatePluginMenus } from "../plugins/validate-menus";
 import { validatePluginSlugs } from "../plugins/validate-slugs";
+import { collectWidgetSources } from "../plugins/widgets/collect-widget-sources";
 import { setBootedConfig } from "../route-handler/auth-handler";
 import type {
   CollectionSource,
@@ -2911,6 +2913,11 @@ async function initializePlugins(
     [];
   const contexts = new Map<string, PluginContext>();
 
+  // Folded once, across every plugin, so a duplicate source id or a reserved
+  // namespace is a boot failure naming BOTH owners. Done before any
+  // registration so a refusal writes no store at all.
+  const contributedSources = collectWidgetSources(plugins);
+
   // PASS 1 — build every enabled plugin's context, register its contributed
   // services (D64) and declared event names. Services register BEFORE any init
   // runs, so a plugin's `init` can resolve any other plugin's service lazily via
@@ -2946,6 +2953,30 @@ async function initializePlugins(
       registerPluginService(plugin.name, svcName, () => factory(pluginContext));
     }
 
+    // Contributed widget SOURCES, bound the same way and for the same reason.
+    // They cannot register with the other widget stores in
+    // `resetWidgetRegistries`: that runs before any context is built, and a
+    // resolver without its context can answer nothing -- a plugin's data
+    // services are reachable through nothing else.
+    //
+    // Per plugin rather than in one sweep afterwards, so each resolver closes
+    // over ITS OWN context. One shared context would hand every plugin the
+    // first one's `ctx.self`, which is how a plugin would come to read another
+    // plugin's entities while believing they were its own.
+    //
+    // Validated across ALL plugins before the loop (`contributedSources`), so a
+    // duplicate id or a reserved namespace is refused naming both owners rather
+    // than discovered halfway through registration.
+    for (const contributed of contributedSources) {
+      if (contributed.owner !== plugin.name) continue;
+      // The source goes through AS DECLARED. The fold has already refused any
+      // kind but `plugin`, so rewriting it here would only be able to hide a
+      // contribution the fold would have caught.
+      registerResolvedSource(contributed.source, (query, caller) =>
+        contributed.resolve(query, caller, pluginContext)
+      );
+    }
+
     // Register contributed email providers (C2/D65) — fail-fast on type collision.
     for (const provider of plugin.contributes?.emailProviders ?? []) {
       // Already erased by defineEmailProvider at the plugin's own boundary, so
diff --git a/packages/nextly/src/di/registrations/register-widgets.ts b/packages/nextly/src/di/registrations/register-widgets.ts
index 77073481c1..30079efc89 100644
--- a/packages/nextly/src/di/registrations/register-widgets.ts
+++ b/packages/nextly/src/di/registrations/register-widgets.ts
@@ -91,4 +91,17 @@ export function resetWidgetRegistries(
   // most of the codebase in order to offer a card.
   registerReleasesWidgetSource();
   registerVersionsWidgetSource();
+
+  // 🔴 A plugin's sources are NOT registered here, and the reason is a hard
+  // ordering fact rather than a preference: this runs before any plugin
+  // context exists (`initializePlugins` builds them later in the same boot),
+  // and a contributed resolver is useless without its context -- a plugin's
+  // data services are reachable through nothing else.
+  //
+  // They register from `initializePlugins`, bound to their own plugin's
+  // context, exactly as contributed services already do. That keeps the
+  // ordering this function's own registrations rely on: core publishes its
+  // sources HERE, first, so a plugin naming a built-in id is refused by
+  // `registerSource` on the PLUGIN's registration -- naming the plugin an
+  // operator can act on, rather than dying inside core's own publication.
 }
diff --git a/packages/nextly/src/domains/auth/services/permission-seed-service.ts b/packages/nextly/src/domains/auth/services/permission-seed-service.ts
index 3b65d26593..dc5f39dfa0 100644
--- a/packages/nextly/src/domains/auth/services/permission-seed-service.ts
+++ b/packages/nextly/src/domains/auth/services/permission-seed-service.ts
@@ -3,6 +3,7 @@ import { sql, eq, and } from "drizzle-orm";
 
 import type { RBACDatabaseInstance } from "@nextly/types/rbac-operations";
 
+import { NEW_ENTITY_PERMISSION_ROLE } from "../../../auth/new-entity-access-policy";
 import type { CollectedPermission } from "../../../plugins/permissions/collect-permissions";
 import { ADOPTED_LIFECYCLE_ACTIONS } from "../../../plugins/permissions/collect-permissions";
 import { SYSTEM_RESOURCES, permissionSlug } from "../../../schemas/_zod/rbac";
@@ -920,7 +921,7 @@ export class PermissionSeedService extends BaseService {
       const superAdminRole = await this.db
         .select({ id: roles.id })
         .from(roles)
-        .where(eq(roles.slug, "super-admin"))
+        .where(eq(roles.slug, NEW_ENTITY_PERMISSION_ROLE))
         .limit(1)
         .then(
           (rows: unknown[]) => (rows[0] as { id: unknown } | undefined) ?? null
diff --git a/packages/nextly/src/domains/collections/__tests__/bulk-writes-localized.integration.test.ts b/packages/nextly/src/domains/collections/__tests__/bulk-writes-localized.integration.test.ts
new file mode 100644
index 0000000000..f5784fa5b4
--- /dev/null
+++ b/packages/nextly/src/domains/collections/__tests__/bulk-writes-localized.integration.test.ts
@@ -0,0 +1,942 @@
+/**
+ * A bulk write reaches a localized collection's companion table.
+ *
+ * A localized collection keeps its translatable values in `<table>_locales`
+ * and the migrated main table has no columns for them. `createEntry` splits a
+ * write accordingly; the shared bulk implementation did not, so `createMany`
+ * failed EVERY row with the driver's own message ("table dc_x has no column
+ * named y") and the batch update had the same gap one function down.
+ *
+ * Asserted against the real companion row rather than the API's answer alone:
+ * a read that resolved through the fallback chain would look identical whether
+ * the translation was stored or not.
+ */
+import { afterEach, describe, expect, it } from "vitest";
+
+import { defineCollection, number, richText, text } from "../../../config";
+import { createAdapter } from "../../../database/factory";
+import {
+  createTestNextly,
+  type TestNextly,
+} from "../../../plugins/test-nextly";
+import type { CollectionEntryService } from "../../../services/collections/collection-entry-service";
+
+let current: TestNextly | undefined;
+afterEach(async () => {
+  await current?.destroy();
+  current = undefined;
+});
+
+interface CompanionRow {
+  _parent: string;
+  _locale: string;
+  _updated_at?: unknown;
+  title?: unknown;
+  kind?: unknown;
+}
+
+async function boot(): Promise<TestNextly> {
+  process.env.DB_DIALECT = "sqlite";
+  const adapter = await createAdapter({
+    type: "sqlite",
+    memory: true,
+  } as Parameters<typeof createAdapter>[0]);
+  current = await createTestNextly({
+    adapter,
+    collections: [
+      defineCollection({
+        slug: "pages",
+        localized: true,
+        access: {
+          create: () => true,
+          read: () => true,
+          update: () => true,
+        },
+        versions: true,
+        // `metaTitle` becomes `meta_title` in the companion: the column and the
+        // field name differ, which is where a reattachment by column shows.
+        fields: [
+          text({ name: "title" }),
+          text({ name: "kind" }),
+          text({ name: "metaTitle" }),
+        ],
+      }),
+    ],
+    localization: { locales: ["en", "de"], defaultLocale: "en" },
+  });
+  return current;
+}
+
+/** The companion rows as the database holds them, not as a read resolves them. */
+async function companionRows(handle: TestNextly): Promise<CompanionRow[]> {
+  return handle.adapter.executeQuery<CompanionRow>(
+    'SELECT "_parent", "_locale", "_updated_at", "title", "kind" FROM "dc_pages_locales" ORDER BY "title"'
+  );
+}
+
+describe("a bulk write on a localized collection", () => {
+  it("creates every row and stores each one's translatable values in the companion", async () => {
+    const handle = await boot();
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    const result = await entries.createEntries(
+      { collectionName: "pages", overrideAccess: true },
+      [
+        { title: "first", kind: "one" },
+        { title: "second", kind: "two" },
+      ]
+    );
+
+    expect(result.errors).toEqual([]);
+    expect(result.successful).toBe(2);
+
+    const rows = await companionRows(handle);
+    expect(rows.map(r => [r.title, r.kind])).toEqual([
+      ["first", "one"],
+      ["second", "two"],
+    ]);
+    // Every row in the write's language, which is the default: these paths
+    // refuse a named locale.
+    expect([...new Set(rows.map(r => r._locale))]).toEqual(["en"]);
+    expect(new Set(rows.map(r => r._parent)).size).toBe(2);
+    // Each new translation carries the staleness stamp. Without it the row
+    // reads as UNKNOWN age and is never reported stale — a signal that never
+    // fires for new content is invisible, so the create must not skip it.
+    expect(
+      rows.every(r => r._updated_at !== null && r._updated_at !== undefined)
+    ).toBe(true);
+
+    // And the values come back out through an ordinary read.
+    const listed = await handler.listEntries({
+      collectionName: "pages",
+      overrideAccess: true,
+    });
+    const docs = (listed.data as { docs: Array<Record<string, unknown>> }).docs;
+    expect(docs.map(d => d.kind).sort()).toEqual(["one", "two"]);
+  });
+
+  it("writes a batch update's translatable values to the companion row", async () => {
+    const handle = await boot();
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    await entries.createEntries(
+      { collectionName: "pages", overrideAccess: true },
+      [{ title: "first", kind: "one" }]
+    );
+    const [created] = await companionRows(handle);
+
+    // A second language for the same entry. Without one, every assertion below
+    // is satisfied by a write that ignores its locale entirely: one row cannot
+    // show whether the upsert matched on the language or merely on the parent,
+    // nor whether the read-back filtered by it.
+    await handle.adapter.executeQuery(
+      `INSERT INTO "dc_pages_locales" ("_parent", "_locale", "title", "kind") ` +
+        `VALUES ('${created._parent}', 'de', 'erste', 'eins')`
+    );
+
+    const updated = await entries.updateEntries(
+      { collectionName: "pages", overrideAccess: true },
+      [{ id: created._parent, data: { kind: "edited" } }]
+    );
+
+    expect(updated.errors).toEqual([]);
+    expect(updated.successful).toBe(1);
+
+    const rows = await companionRows(handle);
+    expect(rows).toHaveLength(2);
+    const byLocale = Object.fromEntries(rows.map(r => [r._locale, r]));
+    // The patched field moved in the write's language; the one the patch did
+    // not name stayed.
+    expect(byLocale.en.kind).toBe("edited");
+    expect(byLocale.en.title).toBe("first");
+    // And the other language is untouched: this write named one locale, and a
+    // write that matched only on the parent would have overwritten this row.
+    expect(byLocale.de.kind).toBe("eins");
+    expect(byLocale.de.title).toBe("erste");
+  });
+
+  it("carries the whole locale, the field's own name and the write's locale into what it records", async () => {
+    const handle = await boot();
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    await entries.createEntries(
+      { collectionName: "pages", overrideAccess: true },
+      [{ title: "first", kind: "one", metaTitle: "meta" }]
+    );
+    const [created] = await companionRows(handle);
+
+    // A patch naming ONE translatable field. What is recorded must still be
+    // the whole document in this language, not the one field that moved.
+    await entries.updateEntries(
+      { collectionName: "pages", overrideAccess: true },
+      [{ id: created._parent, data: { kind: "edited" } }]
+    );
+
+    const events = await handle.adapter.select<{
+      type: string;
+      payload: unknown;
+    }>("nextly_events");
+    const documents = events
+      .filter(e => e.type === "entry.created" || e.type === "entry.updated")
+      .map(e => {
+        const envelope = (
+          typeof e.payload === "string" ? JSON.parse(e.payload) : e.payload
+        ) as {
+          resource?: { id?: string; locale?: string };
+          data?: Record<string, unknown>;
+        };
+        return {
+          id: envelope.resource?.id,
+          locale: envelope.resource?.locale,
+          doc: envelope.data ?? {},
+        };
+      })
+      .filter(d => d.id === created._parent);
+    expect(documents).toHaveLength(2);
+    for (const { doc } of documents) {
+      // Under the FIELD's name, not the column's.
+      expect(doc).toHaveProperty("metaTitle", "meta");
+      expect(doc).not.toHaveProperty("meta_title");
+    }
+    // The update's document carries the fields its patch never named.
+    const afterUpdate = documents[1].doc;
+    expect(afterUpdate.kind).toBe("edited");
+    expect(afterUpdate.title).toBe("first");
+
+    // Every event names the language it describes: a receiver reads the
+    // locale from the resource, and a localized write that omits it is
+    // delivered as belonging to no translation in particular.
+    expect(documents.map(d => d.locale)).toEqual(["en", "en"]);
+
+    // Both versions are tagged with the language their values belong to;
+    // untagged, a restore reads them as shared and drops them.
+    const versions = await handle.adapter.select<{
+      locale: unknown;
+      entry_id?: string;
+      entryId?: string;
+    }>("nextly_versions");
+    const mine = versions.filter(
+      v => (v.entry_id ?? v.entryId) === created._parent
+    );
+    expect(mine.length).toBeGreaterThanOrEqual(2);
+    expect([...new Set(mine.map(v => v.locale))]).toEqual(["en"]);
+  });
+
+  it("rolls the batch back when the companion write fails, rather than committing a parent without it", async () => {
+    const handle = await boot();
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    // One write first, so readiness is remembered as it is in production;
+    // then the companion goes out from under it — schema drift, which is the
+    // shape this guard is for.
+    await entries.createEntries(
+      { collectionName: "pages", overrideAccess: true },
+      [{ title: "first", kind: "one" }]
+    );
+    await handle.adapter.executeQuery('DROP TABLE "dc_pages_locales"');
+    const before = await handle.adapter.executeQuery<{ n: number }>(
+      'SELECT COUNT(*) AS n FROM "dc_pages"'
+    );
+
+    const result = await entries
+      .createEntries({ collectionName: "pages", overrideAccess: true }, [
+        { title: "second", kind: "two" },
+      ])
+      .catch((error: unknown) => ({
+        successful: 0,
+        errors: [{ error: String((error as Error)?.message ?? error) }],
+      }));
+
+    expect(result.successful).toBe(0);
+    // The batch aborted as a write-integrity failure, which is the only
+    // reading under which the row count below means anything. This exact
+    // message is emitted ONLY on the integrity-abort path; the same count is
+    // produced by the MAIN insert failing first — a refusal that never wrote a
+    // parent, reported as an ordinary per-item error — so the message is what
+    // separates a rollback from a write that never happened.
+    expect(JSON.stringify(result.errors)).toContain(
+      "could not be completed and was rolled back"
+    );
+    // The parent row did not survive: a document whose translations never
+    // landed must not be committed as though it had.
+    const after = await handle.adapter.executeQuery<{ n: number }>(
+      'SELECT COUNT(*) AS n FROM "dc_pages"'
+    );
+    expect(after[0].n).toBe(before[0].n);
+  });
+
+  it("rolls a batch update back when the companion write fails", async () => {
+    // The create's twin. A companion write that fails AFTER the main row is
+    // updated must abort the batch rather than report a soft per-item failure:
+    // with `stopOnError` false the transaction would otherwise commit a main
+    // row whose translation never landed, reporting the item as failed.
+    //
+    // The failure is injected at the WRITE rather than by dropping the table,
+    // so the prior-translation read still succeeds and the upsert is the only
+    // thing that can fail — which is what this pins.
+    process.env.DB_DIALECT = "sqlite";
+    const adapter = await createAdapter({
+      type: "sqlite",
+      memory: true,
+    } as Parameters<typeof createAdapter>[0]);
+    current = await createTestNextly({
+      adapter,
+      collections: [
+        defineCollection({
+          slug: "mixed2",
+          localized: true,
+          access: {
+            create: () => true,
+            read: () => true,
+            update: () => true,
+          },
+          fields: [text({ name: "title" }), number({ name: "rank" })],
+        }),
+      ],
+      localization: { locales: ["en", "de"], defaultLocale: "en" },
+    });
+    const handle = current;
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    const created = await entries.createEntries(
+      { collectionName: "mixed2", overrideAccess: true },
+      [{ title: "before", rank: 1 }]
+    );
+    expect(created.errors).toEqual([]);
+    const [row] = await handle.adapter.executeQuery<{ id: string }>(
+      'SELECT "id" FROM "dc_mixed2" LIMIT 1'
+    );
+    await handle.adapter.executeQuery(
+      `CREATE TRIGGER refuse_companion BEFORE INSERT ON "dc_mixed2_locales" ` +
+        `BEGIN SELECT RAISE(ABORT, 'companion write refused'); END`
+    );
+
+    // `rank` is shared and lands on the main row; `title` is translatable and
+    // goes to the companion the trigger refuses.
+    const result = await entries
+      .updateEntries({ collectionName: "mixed2", overrideAccess: true }, [
+        { id: row.id, data: { title: "after", rank: 2 } },
+      ])
+      .catch((error: unknown) => ({
+        successful: 0,
+        errors: [{ error: String((error as Error)?.message ?? error) }],
+      }));
+
+    expect(result.successful).toBe(0);
+    // The integrity-abort path, not a soft per-item failure: unmarked, the
+    // trigger's error is reported per item and the transaction still commits.
+    expect(JSON.stringify(result.errors)).toContain(
+      "could not be completed and was rolled back"
+    );
+    // The main row's shared field did not survive the failed companion write.
+    const after = await handle.adapter.executeQuery<{ rank: number }>(
+      `SELECT "rank" FROM "dc_mixed2" WHERE "id" = '${row.id}'`
+    );
+    expect(after[0].rank).toBe(1);
+  });
+
+  it("leaves a collection that is not localized writing to its own table", async () => {
+    // The control: the split must not divert a write that has no companion.
+    //
+    // Configured WITH localization, and the collection simply not localized.
+    // Without it the split returns at its first statement — before the
+    // companion lookup, before the readiness branch, before anything this
+    // exercise is about — so the case would pass on any implementation. The
+    // risk worth controlling is a plain collection inside a localized app,
+    // which reaches the split and must still be left alone.
+    process.env.DB_DIALECT = "sqlite";
+    const adapter = await createAdapter({
+      type: "sqlite",
+      memory: true,
+    } as Parameters<typeof createAdapter>[0]);
+    current = await createTestNextly({
+      adapter,
+      collections: [
+        defineCollection({
+          slug: "notes",
+          access: { create: () => true, read: () => true },
+          fields: [text({ name: "title" })],
+        }),
+      ],
+      localization: { locales: ["en", "de"], defaultLocale: "en" },
+    });
+    const handler = current.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    const result = await entries.createEntries(
+      { collectionName: "notes", overrideAccess: true },
+      [{ title: "plain" }]
+    );
+
+    expect(result.errors).toEqual([]);
+    expect(result.successful).toBe(1);
+    const rows = await current.adapter.executeQuery<{ title: string }>(
+      'SELECT "title" FROM "dc_notes"'
+    );
+    expect(rows.map(r => r.title)).toEqual(["plain"]);
+  });
+
+  it("stores a localized rich-text value the companion column can hold", async () => {
+    // The headline case this change exists for, on the commonest translatable
+    // field there is. A rich-text value arrives as an object and its column is
+    // text-backed, so it has to be serialized BEFORE the split copies it into
+    // the companion payload — otherwise the driver is handed an object to bind
+    // and refuses it, and `createMany` fails every row exactly as it did
+    // before any of this.
+    process.env.DB_DIALECT = "sqlite";
+    const adapter = await createAdapter({
+      type: "sqlite",
+      memory: true,
+    } as Parameters<typeof createAdapter>[0]);
+    current = await createTestNextly({
+      adapter,
+      collections: [
+        defineCollection({
+          slug: "articles",
+          localized: true,
+          access: {
+            create: () => true,
+            read: () => true,
+            update: () => true,
+          },
+          fields: [text({ name: "title" }), richText({ name: "body" })],
+        }),
+      ],
+      localization: { locales: ["en", "de"], defaultLocale: "en" },
+    });
+    const handle = current;
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    const body = { root: { children: [{ type: "p", text: "hello" }] } };
+    // The second row is what discriminates. An OBJECT is encoded the same way
+    // by either route, because the SQLite adapter JSON-stringifies any object
+    // on its way to the driver — so an object alone cannot tell a shaped write
+    // from an unshaped one, and a test using only one would pass with the
+    // shaping removed. A BARE STRING can tell them apart: the field's own
+    // encoder makes it the JSON document `"plain"`, while the adapter's
+    // sanitizer passes a string straight through as `plain`, which is not a
+    // JSON document and which PostgreSQL and MySQL refuse for a json column.
+    const result = await entries.createEntries(
+      { collectionName: "articles", overrideAccess: true },
+      [
+        { title: "one", body },
+        { title: "two", body: "plain" },
+      ]
+    );
+
+    expect(result.errors).toEqual([]);
+    expect(result.successful).toBe(2);
+
+    // Stored in the companion, as text the column can actually hold.
+    const rows = await handle.adapter.executeQuery<{
+      title: string;
+      body: unknown;
+      _locale: string;
+    }>(
+      'SELECT "title", "body", "_locale" FROM "dc_articles_locales" ORDER BY "title"'
+    );
+    expect(rows).toHaveLength(2);
+    expect(rows.map(r => r._locale)).toEqual(["en", "en"]);
+    expect(typeof rows[0].body).toBe("string");
+    expect(JSON.parse(rows[0].body as string)).toEqual(body);
+    // The discriminating one: a JSON document, not the bare characters.
+    expect(rows[1].body).toBe('"plain"');
+    expect(JSON.parse(rows[1].body as string)).toBe("plain");
+
+    // And a batch UPDATE of the same field has the same requirement.
+    const [created] = await handle.adapter.executeQuery<{ id: string }>(
+      `SELECT "id" FROM "dc_articles" WHERE "id" = '${
+        (
+          await handle.adapter.executeQuery<{ _parent: string }>(
+            `SELECT "_parent" FROM "dc_articles_locales" WHERE "title" = 'one'`
+          )
+        )[0]._parent
+      }'`
+    );
+    const edited = { root: { children: [{ type: "p", text: "edited" }] } };
+    const updated = await entries.updateEntries(
+      { collectionName: "articles", overrideAccess: true },
+      [{ id: created.id, data: { body: edited } }]
+    );
+    expect(updated.errors).toEqual([]);
+    const after = await handle.adapter.executeQuery<{ body: unknown }>(
+      `SELECT "body" FROM "dc_articles_locales" WHERE "_parent" = '${created.id}'`
+    );
+    expect(JSON.parse(after[0].body as string)).toEqual(edited);
+  });
+
+  it("runs a translated field's hook only when the write touched that field", async () => {
+    // The whole language is overlaid onto the updated row, because the
+    // snapshot and the event describe a translation rather than one field of
+    // it. A field hook fires for every key PRESENT in the row it is handed,
+    // though, so carrying the untouched siblings would run their afterChange
+    // handlers for values this write never changed — and those send mail,
+    // re-index, and call out.
+    const fired: string[] = [];
+    const record =
+      (name: string) =>
+      ({ value }: { value: unknown }) => {
+        fired.push(name);
+        return value;
+      };
+    process.env.DB_DIALECT = "sqlite";
+    const adapter = await createAdapter({
+      type: "sqlite",
+      memory: true,
+    } as Parameters<typeof createAdapter>[0]);
+    current = await createTestNextly({
+      adapter,
+      collections: [
+        defineCollection({
+          slug: "hooked",
+          localized: true,
+          access: {
+            create: () => true,
+            read: () => true,
+            update: () => true,
+          },
+          fields: [
+            {
+              ...text({ name: "title" }),
+              hooks: { afterChange: [record("title")] },
+            },
+            {
+              ...text({ name: "metaTitle" }),
+              hooks: { afterChange: [record("metaTitle")] },
+            },
+          ] as unknown as Parameters<typeof defineCollection>[0]["fields"],
+        }),
+      ],
+      localization: { locales: ["en", "de"], defaultLocale: "en" },
+    });
+    const handle = current;
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    await entries.createEntries(
+      { collectionName: "hooked", overrideAccess: true },
+      [{ title: "one", metaTitle: "meta" }]
+    );
+    const [row] = await handle.adapter.executeQuery<{ _parent: string }>(
+      'SELECT "_parent" FROM "dc_hooked_locales" LIMIT 1'
+    );
+    fired.length = 0;
+
+    // Only `title`. `metaTitle` is untouched and must stay that way.
+    await entries.updateEntries(
+      { collectionName: "hooked", overrideAccess: true },
+      [{ id: row._parent, data: { title: "two" } }]
+    );
+
+    expect(fired).toEqual(["title"]);
+
+    // And the untouched translation still comes back on the row, which is
+    // what makes the exclusion above a hook-phase concern rather than a loss.
+    const after = await handle.adapter.executeQuery<{ meta_title: unknown }>(
+      `SELECT "meta_title" FROM "dc_hooked_locales" WHERE "_parent" = '${row._parent}'`
+    );
+    expect(after[0].meta_title).toBe("meta");
+  });
+
+  it("reports the prior translation as what changed, not the untranslated row", async () => {
+    // The main table of a migrated localized collection holds no translatable
+    // columns, so a `previous` built from it alone describes none of the values
+    // the patch is about: a receiver diffing it sees every translation appear
+    // from nothing, and the old value of the field that did change is lost.
+    const handle = await boot();
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    await entries.createEntries(
+      { collectionName: "pages", overrideAccess: true },
+      [{ title: "first", kind: "one" }]
+    );
+    const [created] = await companionRows(handle);
+
+    await entries.updateEntries(
+      { collectionName: "pages", overrideAccess: true },
+      [{ id: created._parent, data: { kind: "edited" } }]
+    );
+
+    const events = await handle.adapter.select<{
+      type: string;
+      payload: unknown;
+    }>("nextly_events");
+    const updates = events
+      .filter(e => e.type === "entry.updated")
+      .map(e => {
+        const envelope = (
+          typeof e.payload === "string" ? JSON.parse(e.payload) : e.payload
+        ) as {
+          resource?: { id?: string };
+          previous?: Record<string, unknown> | null;
+        };
+        return { id: envelope.resource?.id, previous: envelope.previous ?? {} };
+      })
+      .filter(u => u.id === created._parent);
+
+    expect(updates).toHaveLength(1);
+    // The value this patch replaced, as it was.
+    expect(updates[0].previous).toHaveProperty("kind", "one");
+    // And a translation the patch never named still describes the prior state.
+    expect(updates[0].previous).toHaveProperty("title", "first");
+  });
+});
+
+/**
+ * A localized collection whose status is kept per language: the companion row
+ * carries `_status`, so the main row and a translation can disagree about
+ * whether that language is published.
+ */
+async function bootPerLocaleStatus(
+  access: Record<string, () => boolean> = {}
+): Promise<TestNextly> {
+  process.env.DB_DIALECT = "sqlite";
+  const adapter = await createAdapter({
+    type: "sqlite",
+    memory: true,
+  } as Parameters<typeof createAdapter>[0]);
+  current = await createTestNextly({
+    adapter,
+    collections: [
+      defineCollection({
+        slug: "posts",
+        localized: true,
+        status: true,
+        access: {
+          create: () => true,
+          read: () => true,
+          update: () => true,
+          publish: () => true,
+          unpublish: () => true,
+          ...access,
+        },
+        fields: [text({ name: "title", localized: true })],
+      }),
+    ],
+    localization: { locales: ["en", "de"], defaultLocale: "en" },
+  });
+  return current;
+}
+
+describe("a bulk write that moves a localized collection's published state", () => {
+  it("refuses to publish a translation for a caller who cannot publish", async () => {
+    // The state a reconcile leaves: the main row is published while this
+    // language's companion `_status` is still draft. Judged against the main
+    // row alone the write reads `published -> published` — a no-op needing no
+    // grant — while the companion write it authorizes publishes the
+    // translation.
+    const handle = await bootPerLocaleStatus({ publish: () => false });
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    const created = await entries.createEntries(
+      { collectionName: "posts", overrideAccess: true },
+      [{ title: "t", status: "published" }]
+    );
+    expect(created.successful).toBe(1);
+    const [row] = await handle.adapter.executeQuery<{ _parent: string }>(
+      'SELECT "_parent" FROM "dc_posts_locales" LIMIT 1'
+    );
+    await handle.adapter.executeQuery(
+      `UPDATE "dc_posts_locales" SET "_status" = 'draft' WHERE "_parent" = '${row._parent}'`
+    );
+
+    const result = await entries
+      .updateEntries({ collectionName: "posts", user: { id: "editor" } }, [
+        { id: row._parent, data: { status: "published" } },
+      ])
+      .catch(() => ({ successful: 0, failed: 1, errors: [{}] }));
+
+    expect(result.successful).toBe(0);
+    // The translation was not published behind the gate's back.
+    const after = await handle.adapter.executeQuery<{ _status: string }>(
+      `SELECT "_status" FROM "dc_posts_locales" WHERE "_parent" = '${row._parent}'`
+    );
+    expect(after[0]._status).toBe("draft");
+  });
+
+  it("lets the same write through for a caller who can publish", async () => {
+    // The control: the gate is enforcing a missing permission, not refusing
+    // every localized status write.
+    const handle = await bootPerLocaleStatus();
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    await entries.createEntries(
+      { collectionName: "posts", overrideAccess: true },
+      [{ title: "t", status: "published" }]
+    );
+    const [row] = await handle.adapter.executeQuery<{ _parent: string }>(
+      'SELECT "_parent" FROM "dc_posts_locales" LIMIT 1'
+    );
+    await handle.adapter.executeQuery(
+      `UPDATE "dc_posts_locales" SET "_status" = 'draft' WHERE "_parent" = '${row._parent}'`
+    );
+
+    const result = await entries.updateEntries(
+      { collectionName: "posts", user: { id: "editor" } },
+      [{ id: row._parent, data: { status: "published" } }]
+    );
+
+    expect(result.errors).toEqual([]);
+    expect(result.successful).toBe(1);
+    const after = await handle.adapter.executeQuery<{ _status: string }>(
+      `SELECT "_status" FROM "dc_posts_locales" WHERE "_parent" = '${row._parent}'`
+    );
+    expect(after[0]._status).toBe("published");
+  });
+
+  it("announces no publication when a content-only patch leaves the translation a draft", async () => {
+    // The main row is published while this language's companion `_status` is
+    // still draft — the state a reconcile leaves — and the patch names no
+    // status at all. Nothing publishes the translation, so nothing may say it
+    // did: the status this write reports must come from the same row its prior
+    // status came from.
+    const handle = await bootPerLocaleStatus();
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    await entries.createEntries(
+      { collectionName: "posts", overrideAccess: true },
+      [{ title: "t", status: "published" }]
+    );
+    const [row] = await handle.adapter.executeQuery<{ _parent: string }>(
+      'SELECT "_parent" FROM "dc_posts_locales" LIMIT 1'
+    );
+    await handle.adapter.executeQuery(
+      `UPDATE "dc_posts_locales" SET "_status" = 'draft' WHERE "_parent" = '${row._parent}'`
+    );
+    const before = await handle.adapter.select<{ type: string }>(
+      "nextly_events"
+    );
+
+    // Translated content only. No status named anywhere in the patch.
+    const result = await entries.updateEntries(
+      { collectionName: "posts", overrideAccess: true },
+      [{ id: row._parent, data: { title: "neu" } }]
+    );
+    expect(result.errors).toEqual([]);
+    expect(result.successful).toBe(1);
+
+    const after = await handle.adapter.select<{
+      type: string;
+      payload: unknown;
+    }>("nextly_events");
+    const added = after.slice(before.length);
+    // No lifecycle event: this write moved no publication state.
+    expect(added.map(e => e.type).sort()).toEqual(["entry.updated"]);
+
+    // And what it recorded describes a draft translation, not a published one.
+    const envelope = (
+      typeof added[0].payload === "string"
+        ? JSON.parse(added[0].payload)
+        : added[0].payload
+    ) as { data?: Record<string, unknown> };
+    expect(envelope.data?.status).toBe("draft");
+
+    // The companion row is still a draft, which is what makes the above right.
+    const companion = await handle.adapter.executeQuery<{ _status: string }>(
+      `SELECT "_status" FROM "dc_posts_locales" WHERE "_parent" = '${row._parent}'`
+    );
+    expect(companion[0]._status).toBe("draft");
+  });
+
+  it("still announces a main-row publication when the translation was already published", async () => {
+    // The mirror of the case above, and the one a single collapsed event gets
+    // wrong in the other direction. The main row really does move draft ->
+    // published — the entry becomes publicly visible — while this locale's
+    // companion was published already, so the companion move is a no-op.
+    // Reading both ends from the translation would read published ->
+    // published and announce nothing at all.
+    const handle = await bootPerLocaleStatus();
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    await entries.createEntries(
+      { collectionName: "posts", overrideAccess: true },
+      [{ title: "t", status: "draft" }]
+    );
+    const [row] = await handle.adapter.executeQuery<{ _parent: string }>(
+      'SELECT "_parent" FROM "dc_posts_locales" LIMIT 1'
+    );
+    await handle.adapter.executeQuery(
+      `UPDATE "dc_posts_locales" SET "_status" = 'published' WHERE "_parent" = '${row._parent}'`
+    );
+    const before = await handle.adapter.select<{ type: string }>(
+      "nextly_events"
+    );
+
+    const result = await entries.updateEntries(
+      { collectionName: "posts", overrideAccess: true },
+      [{ id: row._parent, data: { status: "published" } }]
+    );
+    expect(result.errors).toEqual([]);
+
+    const after = await handle.adapter.select<{ type: string }>(
+      "nextly_events"
+    );
+    const added = after.slice(before.length).map(e => e.type);
+    // The entry became publicly visible, and the lifecycle says so.
+    expect(added).toContain("entry.published");
+    expect(added).toContain("entry.status_changed");
+  });
+
+  it("reports a translation created by the write as the draft it is", async () => {
+    // A locale with no companion row yet, patched with content only. The
+    // upsert creates the row, and `_status` lands on its column default — so
+    // the translation this write just made is a draft. Reporting the main
+    // row's status instead tells receivers a brand-new translation is already
+    // published.
+    const handle = await bootPerLocaleStatus();
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    await entries.createEntries(
+      { collectionName: "posts", overrideAccess: true },
+      [{ title: "t", status: "published" }]
+    );
+    const [row] = await handle.adapter.executeQuery<{ _parent: string }>(
+      'SELECT "_parent" FROM "dc_posts_locales" LIMIT 1'
+    );
+    // The locale goes back to having no row at all, which is the state a
+    // never-translated language is in.
+    await handle.adapter.executeQuery(
+      `DELETE FROM "dc_posts_locales" WHERE "_parent" = '${row._parent}'`
+    );
+    const before = await handle.adapter.select<{ type: string }>(
+      "nextly_events"
+    );
+
+    const result = await entries.updateEntries(
+      { collectionName: "posts", overrideAccess: true },
+      [{ id: row._parent, data: { title: "neu" } }]
+    );
+    expect(result.errors).toEqual([]);
+
+    const after = await handle.adapter.select<{
+      type: string;
+      payload: unknown;
+    }>("nextly_events");
+    const updates = after
+      .slice(before.length)
+      .filter(e => e.type === "entry.updated");
+    expect(updates).toHaveLength(1);
+    const envelope = (
+      typeof updates[0].payload === "string"
+        ? JSON.parse(updates[0].payload)
+        : updates[0].payload
+    ) as { data?: Record<string, unknown> };
+    expect(envelope.data?.status).toBe("draft");
+    // And that is what the row the upsert created actually holds.
+    const companion = await handle.adapter.executeQuery<{ _status: string }>(
+      `SELECT "_status" FROM "dc_posts_locales" WHERE "_parent" = '${row._parent}'`
+    );
+    expect(companion[0]._status).toBe("draft");
+  });
+
+  it("names the language on every event a localized create derives", async () => {
+    // A create landing on `published` emits a lifecycle event beside
+    // `entry.created`. A receiver reads the language from the resource, so one
+    // event carrying it and its siblings not leaves them describing no
+    // translation in particular — and disagreeing about the same write.
+    const handle = await bootPerLocaleStatus();
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    await entries.createEntries(
+      { collectionName: "posts", overrideAccess: true },
+      [{ title: "t", status: "published" }]
+    );
+
+    const events = await handle.adapter.select<{
+      type: string;
+      payload: unknown;
+    }>("nextly_events");
+    const locales = events
+      .filter(e => e.type === "entry.created" || e.type === "entry.published")
+      .map(e => {
+        const envelope = (
+          typeof e.payload === "string" ? JSON.parse(e.payload) : e.payload
+        ) as { resource?: { locale?: string } };
+        return { type: e.type, locale: envelope.resource?.locale };
+      });
+
+    // Both events exist, and both name the language the values went into.
+    expect(locales.map(l => l.type).sort()).toEqual([
+      "entry.created",
+      "entry.published",
+    ]);
+    expect(locales.every(l => l.locale === "en")).toBe(true);
+  });
+
+  it("writes nothing to the main row when the prior translation cannot be read", async () => {
+    // A patch naming only a SHARED field writes no companion row at all, so the
+    // companion-write guard never runs — but the prior translation still has to
+    // be read, to say what this write changed. Read AFTER the main-table UPDATE,
+    // a failure there leaves a committed row with no version and no event while
+    // the item is reported as failed. Read before it, there is nothing to roll
+    // back. `rank` is a number, which is shared rather than translatable, so
+    // this patch reaches the read and nothing else.
+    process.env.DB_DIALECT = "sqlite";
+    const adapter = await createAdapter({
+      type: "sqlite",
+      memory: true,
+    } as Parameters<typeof createAdapter>[0]);
+    current = await createTestNextly({
+      adapter,
+      collections: [
+        defineCollection({
+          slug: "mixed",
+          localized: true,
+          access: {
+            create: () => true,
+            read: () => true,
+            update: () => true,
+          },
+          fields: [text({ name: "title" }), number({ name: "rank" })],
+        }),
+      ],
+      localization: { locales: ["en", "de"], defaultLocale: "en" },
+    });
+    const handle = current;
+    const handler = handle.getService("collectionsHandler");
+    const entries = handler.getEntryService() as CollectionEntryService;
+
+    const created = await entries.createEntries(
+      { collectionName: "mixed", overrideAccess: true },
+      [{ title: "t", rank: 1 }]
+    );
+    expect(created.errors).toEqual([]);
+    const [row] = await handle.adapter.executeQuery<{
+      id: string;
+      rank: number;
+    }>('SELECT "id", "rank" FROM "dc_mixed" LIMIT 1');
+    // The shared field really is on the main table, so the patch below names
+    // nothing translatable.
+    expect(row.rank).toBe(1);
+
+    // Schema drift under a warm readiness verdict, which is the shape this
+    // guards: the split still routes to the companion, and the read fails.
+    await handle.adapter.executeQuery('DROP TABLE "dc_mixed_locales"');
+
+    const result = await entries
+      .updateEntries({ collectionName: "mixed", overrideAccess: true }, [
+        { id: row.id, data: { rank: 2 } },
+      ])
+      .catch(() => ({ successful: 0, failed: 1, errors: [{}] }));
+
+    expect(result.successful).toBe(0);
+    // The shared field the patch named did not land.
+    const after = await handle.adapter.executeQuery<{ rank: number }>(
+      `SELECT "rank" FROM "dc_mixed" WHERE "id" = '${row.id}'`
+    );
+    expect(after[0].rank).toBe(1);
+  });
+});
diff --git a/packages/nextly/src/domains/collections/services/collection-mutation-service.ts b/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
index cd647a641f..bbd4440edb 100644
--- a/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
+++ b/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
@@ -117,6 +117,7 @@ import {
   COMPANION_LOCALE_COLUMN,
   COMPANION_PARENT_COLUMN,
   COMPANION_STATUS_COLUMN,
+  resolveEffectiveLocaleStatus,
 } from "../../i18n/companion-columns";
 import {
   companionRowExists,
@@ -890,6 +891,12 @@ export class CollectionMutationService extends BaseService {
         manyToMany: Record<string, string[]>;
       };
       fields: FieldDefinition[];
+      /**
+       * The locale this snapshot's translatable values belong to, when the
+       * write put any there. Absent means the snapshot carries no per-locale
+       * parent state and the component rule below decides.
+       */
+      localeTag?: string;
     }
   ): Promise<void> {
     if (!args.versionsConfig?.enabled) {
@@ -907,15 +914,18 @@ export class CollectionMutationService extends BaseService {
         // event carries, and that payload is read shape.
         parts: await this.snapshotPartsFor(args.documentParts, args.fields, tx),
         createdBy: args.createdBy,
-        // The component subtrees were read at the default locale (these paths
-        // pass no write locale); tag the version with it so a localized
-        // component can be restored, exactly as the interactive create/update
-        // paths do. Null when the snapshot has no component state, since there is
-        // then one set of values and nothing to disambiguate.
+        // The locale this snapshot belongs to: the one the write put
+        // translatable parent values in, when it did. Otherwise the component
+        // rule — the subtrees were read at the default locale (these paths
+        // pass no write locale), so tag the version with it when there are
+        // any, exactly as the interactive create/update paths do. Null when
+        // the snapshot carries neither, since there is then one set of values
+        // and nothing to disambiguate.
         locale:
-          Object.keys(args.documentParts.components ?? {}).length > 0
+          args.localeTag ??
+          (Object.keys(args.documentParts.components ?? {}).length > 0
             ? this.componentSnapshotLocale(undefined)
-            : null,
+            : null),
         maxPerDoc: args.versionsConfig.maxPerDoc,
       });
     } catch (err) {
@@ -970,6 +980,8 @@ export class CollectionMutationService extends BaseService {
       manyToManyData: Record<string, string[]>;
       user?: UserContext;
       actor?: RequestActor;
+      /** The locale this create's translatable values were written in, if any. */
+      localeTag?: string;
     }
   ): Promise<{
     eventRecorded: boolean;
@@ -1027,6 +1039,10 @@ export class CollectionMutationService extends BaseService {
       versionsConfig,
       documentParts: createdParts,
       fields: args.fields,
+      // See `captureTxVersion`: a create that wrote translatable values put
+      // them in one language, and an untagged snapshot of them reads as
+      // shared.
+      localeTag: args.localeTag,
     });
     const eventFields = await this.webhookFieldTreeIfRecording(
       args.collectionName,
@@ -1040,6 +1056,9 @@ export class CollectionMutationService extends BaseService {
         kind: "entry",
         collection: args.collectionName,
         id: entryId,
+        // The language this create's translatable values went into, as the
+        // interactive create reports it.
+        ...(args.localeTag ? { locale: args.localeTag } : {}),
       },
       data: createdDocument,
       previous: null,
@@ -1055,7 +1074,13 @@ export class CollectionMutationService extends BaseService {
       entryId,
       createdDocument,
       eventActor,
-      args.fields
+      args.fields,
+      // Every side effect of this create describes the same language the values
+      // were written in. A receiver reads the locale from the resource, so one
+      // that omits it is delivered as belonging to no translation in
+      // particular — and they must not disagree with each other about which
+      // translation they are reporting.
+      args.localeTag
     );
     eventRecorded = eventRecorded || curatedCreateRecorded;
     // A create landing directly on `published` is also a publish lifecycle
@@ -1066,6 +1091,7 @@ export class CollectionMutationService extends BaseService {
       const createdStatusRecorded = await this.recordStatusEvents(tx, {
         collection: args.collectionName,
         id: entryId,
+        ...(args.localeTag ? { locale: args.localeTag } : {}),
         from: null,
         to: args.entry.status as string | null | undefined,
         isCreate: true,
@@ -1085,6 +1111,9 @@ export class CollectionMutationService extends BaseService {
         {
           id: entryId,
           slug: readStringField(args.entry, "slug"),
+          // Without it the locale-specific tag for this id is never flushed,
+          // so the new translation stays behind a cached miss.
+          ...(args.localeTag ? { locale: args.localeTag } : {}),
         }
       ),
     };
@@ -1296,6 +1325,43 @@ export class CollectionMutationService extends BaseService {
     return resolveRequestedLocale(this.localization, requested);
   }
 
+  /**
+   * The companion row a CREATE writes: the new parent, the write's locale, the
+   * translatable values, and the staleness stamp. An insert rather than an
+   * upsert, because a parent this transaction has just created has no row to
+   * conflict with — the update paths upsert instead.
+   *
+   * The stamp is not optional and not restated per caller: a create that
+   * forgot it leaves every new document's translations reading as UNKNOWN
+   * until each locale is rewritten, and a staleness signal that never fires
+   * for new content is invisible. Both create paths call this, so they cannot
+   * come to disagree about what a new translation carries.
+   */
+  private async insertCompanionRow(
+    tx: TransactionContext,
+    localizedWrite: {
+      companionTableName: string;
+      writeLocale: string;
+      companionData: Record<string, unknown>;
+    },
+    parentId: unknown
+  ): Promise<void> {
+    await tx.insert(
+      localizedWrite.companionTableName,
+      {
+        _parent: parentId,
+        _locale: localizedWrite.writeLocale,
+        ...localizedWrite.companionData,
+        ...companionContentStamp(
+          localizedWrite.companionData,
+          localizedWrite.companionTableName,
+          this.dialect
+        ),
+      },
+      {}
+    );
+  }
+
   private async splitLocalizedWriteData(
     collectionName: string,
     entryData: Record<string, unknown>,
@@ -1336,11 +1402,34 @@ export class CollectionMutationService extends BaseService {
     // Resolved here, before the transaction opens. Everything downstream — including the read-back
     // that runs inside it — reads the answer rather than asking again.
     const mainTableName = companion.companionTableName.replace(/_locales$/, "");
-    const readiness = await resolveCompanionReadiness(this.adapter, {
-      companionTableName: companion.companionTableName,
-      mainTableName,
-      localizedColumns: companion.localizedFields.map(f => f.column),
-    });
+    // Inside a caller's transaction the verdict may only be REMEMBERED, never
+    // resolved: resolving issues a pooled query, which waits for the
+    // connection this transaction holds, and on PostgreSQL a query against a
+    // missing relation marks the whole transaction aborted — after which the
+    // real write dies naming an innocent statement.
+    //
+    // What that costs, stated rather than assumed: the cached read answers
+    // `ready` or nothing at all, so a verdict nobody warmed is indistinguishable
+    // here from a collection that was never migrated, and both take the
+    // pre-migration fallback below. The entry points that open their OWN
+    // transaction warm it first (`warmLocalizedReadiness` in the batch
+    // services), so they always have an answer. The `*InTransaction` entry
+    // points cannot: the transaction is the caller's and already open, and
+    // warming inside it is the very thing this avoids. A caller that opens its
+    // own transaction without warming therefore gets the fallback, which is
+    // right for a collection whose values still live on the main table and
+    // fatal for one localized from creation — the driver rejects the write, as
+    // it did before any of this. Refusing on an unknown verdict instead would
+    // turn the first case into an error to buy a better message for the
+    // second. Unknown is handled below as any other
+    // not-ready answer is, which is the same fallback as before.
+    const readiness = executor
+      ? cachedCompanionReadiness(this.adapter, companion.companionTableName)
+      : await resolveCompanionReadiness(this.adapter, {
+          companionTableName: companion.companionTableName,
+          mainTableName,
+          localizedColumns: companion.localizedFields.map(f => f.column),
+        });
     if (readiness !== "ready") {
       // The main table carries no language of its own, so anything written there
       // while the companion is missing is later read as the DEFAULT language —
@@ -1608,12 +1697,7 @@ export class CollectionMutationService extends BaseService {
       }
     });
 
-    // Serialize JSON fields (richtext, blocks, array, group, json)
-    fields.forEach(field => {
-      if (isJsonFieldType(field.type, field) && data[field.name] != null) {
-        data[field.name] = toJsonColumnValue(data[field.name]);
-      }
-    });
+    this.serializeJsonFieldValues(data, fields);
 
     this.serializeHasManyRelationships(data, fields);
 
@@ -2407,6 +2491,114 @@ export class CollectionMutationService extends BaseService {
    * Mutates `finalData` in place. Idempotent: arrays become strings; existing
    * strings (e.g. when the caller pre-serialized) are not double-encoded.
    */
+  /**
+   * Put every JSON-backed value (rich text, blocks, array, group, json) into
+   * the form its column stores, in place.
+   *
+   * Its own method because more than one write path needs it and they must not
+   * each decide which field types count: a path that serializes only some of
+   * them hands the driver an object for a text-backed column, and SQLite
+   * rejects the bind outright rather than coercing it. The localized split in
+   * particular copies these values into the companion payload, so anything
+   * unserialized here fails at the companion write instead of the main one,
+   * where the cause is much harder to read.
+   */
+  /**
+   * Everything a CREATE does to its payload between the last hook and the
+   * write, and the three things it takes OUT of it.
+   *
+   * One implementation for the interactive create and the batch worker, which
+   * ran the same eleven steps in the same order in two places. That is the
+   * shape a step goes missing from: the JSON conversion was present in one and
+   * absent in the other for exactly as long as the two lists were maintained
+   * by hand, and a localized rich-text value reached its column unconverted as
+   * a result.
+   *
+   * The three values come back rather than staying on `finalData` because none
+   * of them has a column on the parent row — many-to-many links live in a
+   * junction table and field groups in their own `comp_` tables — so leaving
+   * any of them in place fails the insert.
+   *
+   * Generic in the field type so callers keep theirs: they go on to read
+   * relationship properties off the returned list.
+   */
+  private async prepareCreateWritePayload<
+    T extends {
+      type: string;
+      name: string;
+      options?: { relationType?: string };
+    },
+  >(
+    finalData: Record<string, unknown>,
+    fields: T[]
+  ): Promise<{
+    manyToManyFields: T[];
+    manyToManyData: Record<string, string[]>;
+    componentFieldData: Record<string, unknown>;
+  }> {
+    await hashPasswordFieldValues(finalData, fields);
+
+    // AFTER every mutating hook has run. A field-level
+    // beforeValidate/beforeChange hook can (re)introduce an own
+    // `status: undefined`, which names no status change but would otherwise be
+    // sanitized to SQL NULL on the raw-parameter path — silently unpublishing
+    // a published row, or nulling a create's draft default — without passing
+    // the publish/unpublish gate. The last status-touching step before the
+    // transition classification and the write, so the payload and the gate
+    // agree even when a hook set the undefined.
+    stripUndefinedStatus(finalData);
+
+    // Before the many-to-many extraction and the JSON conversion, and walking
+    // containers too: a reference left populated inside a group or repeater is
+    // serialized into the row as JSON and never read back as a reference.
+    normalizeRelationshipFields(finalData, fields as unknown as FieldConfig[]);
+    normalizeUploadFields(
+      finalData,
+      fields as unknown as Parameters<typeof normalizeUploadFields>[1]
+    );
+
+    // Only a UI-built many-to-many routes through a junction table. Code-first
+    // `hasMany: true` is a JSON array on the parent column, and is converted
+    // with the other JSON values instead.
+    const manyToManyFields = fields.filter(
+      f => f.type === "relationship" && f.options?.relationType === "manyToMany"
+    );
+    const manyToManyData: Record<string, string[]> = {};
+    for (const field of manyToManyFields) {
+      if (finalData[field.name]) {
+        manyToManyData[field.name] = Array.isArray(finalData[field.name])
+          ? (finalData[field.name] as string[])
+          : [finalData[field.name] as string];
+        delete finalData[field.name];
+      }
+    }
+
+    const componentFieldData = this.extractComponentFieldData(
+      finalData,
+      fields as unknown as Parameters<typeof this.extractComponentFieldData>[1]
+    );
+    return { manyToManyFields, manyToManyData, componentFieldData };
+  }
+
+  private serializeJsonFieldValues(
+    data: Record<string, unknown>,
+    // `hasMany`/`relationTo` are what tell a relationship that stores an array
+    // apart from one that stores a single id, which decides whether its value
+    // is JSON-backed at all.
+    fields: {
+      type: string;
+      name: string;
+      hasMany?: boolean;
+      relationTo?: unknown;
+    }[]
+  ): void {
+    for (const field of fields) {
+      if (isJsonFieldType(field.type, field) && data[field.name] != null) {
+        data[field.name] = toJsonColumnValue(data[field.name]);
+      }
+    }
+  }
+
   private serializeHasManyRelationships(
     finalData: Record<string, unknown>,
     fields: { type: string; name: string; hasMany?: boolean }[]
@@ -3102,58 +3294,8 @@ export class CollectionMutationService extends BaseService {
       // re-sanitize once more so the stored value stays URL-safe.
       await this.reSanitizeSlug(finalData, isSlugTaken);
 
-      await hashPasswordFieldValues(finalData, fields);
-
-      // Strip an explicit `status: undefined` AFTER every mutating hook has run.
-      // A field-level beforeValidate/beforeChange hook can (re)introduce an own
-      // `status: undefined`, which names no status change but would otherwise be
-      // sanitized to SQL NULL on the raw-parameter path — silently unpublishing a
-      // published row, or nulling a create's draft default — without passing the
-      // publish/unpublish gate. Placed here, the last status-touching step before
-      // the transition classification and the write, so the write payload and the
-      // gate agree even when a hook set the undefined.
-      stripUndefinedStatus(finalData);
-
-      // Normalize relationship field values (extract IDs from objects with display properties)
-      // This must happen before many-to-many extraction and JSON serialization
-      // Walks containers too: a reference left populated inside a group or
-      // repeater is serialized to JSON as the row and never read back as a
-      // reference.
-      normalizeRelationshipFields(
-        finalData,
-        fields as unknown as FieldConfig[]
-      );
-
-      // Normalize upload field values (extract IDs from populated media objects)
-      normalizeUploadFields(finalData, fields);
-
-      // Separate regular fields from many-to-many relations
-      const manyToManyFields = fields.filter(
-        f =>
-          f.type === "relationship" &&
-          // Only UI-built manyToMany routes through a junction table.
-          // Code-first `hasMany: true` is stored as a JSON array on the
-          // parent column (see field-column-descriptor.ts kind="json")
-          // and is serialized later in the same finalData pass.
-          f.options?.relationType === "manyToMany"
-      );
-      const manyToManyData: Record<string, string[]> = {};
-
-      // Extract many-to-many data from finalData (after hooks)
-      manyToManyFields.forEach(field => {
-        if (finalData[field.name]) {
-          manyToManyData[field.name] = Array.isArray(finalData[field.name])
-            ? (finalData[field.name] as string[])
-            : [finalData[field.name] as string];
-          delete finalData[field.name]; // Remove from main insert
-        }
-      });
-
-      // Field-group values go to their own comp_{slug} tables, not this row.
-      const componentFieldData = this.extractComponentFieldData(
-        finalData,
-        fields
-      );
+      const { manyToManyFields, manyToManyData, componentFieldData } =
+        await this.prepareCreateWritePayload(finalData, fields);
 
       this.serializeHasManyRelationships(finalData, fields);
 
@@ -3201,15 +3343,7 @@ export class CollectionMutationService extends BaseService {
         }
       });
 
-      // Serialize JSON fields (richtext, blocks, array, group, json)
-      fields.forEach(field => {
-        if (
-          isJsonFieldType(field.type, field) &&
-          finalData[field.name] != null
-        ) {
-          finalData[field.name] = toJsonColumnValue(finalData[field.name]);
-        }
-      });
+      this.serializeJsonFieldValues(finalData, fields);
 
       // Convert date-field strings into `Date` objects so Drizzle can bind
       // them to `timestamp` columns. See `coerceDateFieldsToDate` for the
@@ -3366,26 +3500,7 @@ export class CollectionMutationService extends BaseService {
         // i18n M5: write the translatable values to the companion `_locales` row for the
         // write's locale (same transaction → rolls back with the main insert).
         if (localizedWrite) {
-          await tx.insert(
-            localizedWrite.companionTableName,
-            {
-              _parent: entry.id,
-              _locale: localizedWrite.writeLocale,
-              ...localizedWrite.companionData,
-              // i18n B2: this is the THIRD companion write path, and it does not go through
-              // `upsertCompanionRow` -- it inserts a brand-new row on a parent this transaction
-              // has just created, where there is no conflict to resolve. The stamp rule is shared
-              // rather than restated, because a create that forgot it would leave every new
-              // document's translations reading as UNKNOWN until each locale was rewritten, and a
-              // staleness signal that never fires for new content is invisible.
-              ...companionContentStamp(
-                localizedWrite.companionData,
-                localizedWrite.companionTableName,
-                this.dialect
-              ),
-            },
-            {}
-          );
+          await this.insertCompanionRow(tx, localizedWrite, entry.id);
           // The localized values were split out of the main insert, so the
           // returned main row lacks them. Merge them back (camelCase keys) so
           // afterCreate hooks, events, and the response include them. `_status`
@@ -5064,17 +5179,37 @@ export class CollectionMutationService extends BaseService {
       }
       lockedStatus = (lockedRow.status as string | undefined) ?? null;
     }
-    const op = resolvePublishTransition(lockedStatus, args.nextStatus);
+    return this.denyIfTransitionUngranted(
+      lockedStatus,
+      args.nextStatus,
+      args.auth
+    );
+  }
+
+  /**
+   * The denial a status move earns, or `null` when it needs no grant.
+   *
+   * A write can move the published state in more than one place — the main row's
+   * `status`, and, on a localized collection, the write locale's companion
+   * `_status` — and each has to be judged against the status THAT place
+   * currently holds. One implementation answers for both: asking the question
+   * twice would let the two readings drift, and a gate that drifts toward
+   * permissive is a gate that stops gating.
+   *
+   * Permission is pre-resolved and read here without a query, so a caller
+   * lacking publish-<slug> / unpublish-<slug> is denied regardless of ownership.
+   * That is the whole decision: there is no document-dependent rule to judge
+   * against the row-locked document, so a transition is admitted or refused on
+   * the caller's grant alone.
+   */
+  private denyIfTransitionUngranted(
+    currentStatus: string | null,
+    nextStatus: unknown,
+    auth: TransitionAuthorization
+  ): CollectionServiceResult | null {
+    const op = resolvePublishTransition(currentStatus, nextStatus);
     if (!op) return null;
-    // Permission first (pre-resolved, no DB read): a caller lacking publish-<slug>
-    // / unpublish-<slug> is denied regardless of ownership.
-    const permissionDenied =
-      op === "publish" ? args.auth.publishDenied : args.auth.unpublishDenied;
-    if (permissionDenied) return permissionDenied;
-    // The permission check above is the whole decision. There is no
-    // document-dependent rule to judge against the row-locked document, so a
-    // transition is admitted or refused on the caller's grant alone.
-    return null;
+    return op === "publish" ? auth.publishDenied : auth.unpublishDenied;
   }
 
   /**
@@ -6980,13 +7115,12 @@ export class CollectionMutationService extends BaseService {
               const writesCompanionRow =
                 !!localizedUpdate &&
                 Object.keys(localizedUpdate.companionData).length > 0;
-              const effectiveLocaleStatus =
-                typeof companionStatus === "string"
-                  ? companionStatus
-                  : (committedLocaleStatus ??
-                    (localizedUpdate?.hasStatus && writesCompanionRow
-                      ? COMPANION_DEFAULT_STATUS
-                      : null));
+              const effectiveLocaleStatus = resolveEffectiveLocaleStatus({
+                hasStatus: localizedUpdate?.hasStatus === true,
+                writesCompanionRow,
+                requestedStatus: companionStatus,
+                committedStatus: committedLocaleStatus,
+              });
               // A partial translatable update only carries the *changed*
               // localized values in `localizedFieldValues`; the write locale's
               // other companion fields (set by a prior write, untouched here)
@@ -8438,65 +8572,13 @@ export class CollectionMutationService extends BaseService {
         await this.reSanitizeSlug(finalData, isSlugTaken);
       }
 
-      await hashPasswordFieldValues(finalData, fields);
-
-      // Strip an explicit `status: undefined` AFTER every mutating hook has run.
-      // A field-level beforeValidate/beforeChange hook can (re)introduce an own
-      // `status: undefined`, which names no status change but would otherwise be
-      // sanitized to SQL NULL on the raw-parameter path — silently unpublishing a
-      // published row, or nulling a create's draft default — without passing the
-      // publish/unpublish gate. Placed here, the last status-touching step before
-      // the transition classification and the write, so the write payload and the
-      // gate agree even when a hook set the undefined.
-      stripUndefinedStatus(finalData);
-
-      // Normalize relationship field values (extract IDs from objects with display properties)
-      // This must happen before many-to-many extraction and JSON serialization
-      // Walks containers too: a reference left populated inside a group or
-      // repeater is serialized to JSON as the row and never read back as a
-      // reference.
-      normalizeRelationshipFields(
-        finalData,
-        fields as unknown as FieldConfig[]
-      );
-
-      // Normalize upload field values (extract IDs from populated media objects)
-      normalizeUploadFields(finalData, fields);
-
-      // Separate regular fields from many-to-many relations
-      const manyToManyFields = fields.filter(
-        f =>
-          f.type === "relationship" &&
-          // Only UI-built manyToMany routes through a junction table.
-          // Code-first `hasMany: true` is stored as a JSON array on the
-          // parent column (see field-column-descriptor.ts kind="json")
-          // and is serialized later in the same finalData pass.
-          f.options?.relationType === "manyToMany"
-      );
-      const manyToManyData: Record<string, string[]> = {};
-
-      manyToManyFields.forEach(field => {
-        if (finalData[field.name]) {
-          manyToManyData[field.name] = Array.isArray(finalData[field.name])
-            ? (finalData[field.name] as string[])
-            : [finalData[field.name] as string];
-          delete finalData[field.name];
-        }
-      });
-
-      // Field-group values live in their own comp_{slug} tables and have no
-      // column on the main row; left in place, the insert fails on the first
-      // one. Written after the row exists, below.
-      const componentFieldData = this.extractComponentFieldData(
-        finalData,
-        fields
-      );
+      const { manyToManyFields, manyToManyData, componentFieldData } =
+        await this.prepareCreateWritePayload(finalData, fields);
 
+      // Before the localized split below, which copies these values into the
+      // companion payload for the row this create is about to insert.
+      this.serializeJsonFieldValues(finalData, fields);
       this.serializeHasManyRelationships(finalData, fields);
-
-      // Convert date-field strings into `Date` objects so Drizzle can bind
-      // them to `timestamp` columns. See `coerceDateFieldsToDate` for the
-      // failure mode this guards against.
       coerceDateFieldsToDate(finalData, fields);
 
       // Prepare entry data
@@ -8566,11 +8648,60 @@ export class CollectionMutationService extends BaseService {
         return transitionDenied;
       }
 
+      // A localized collection keeps its translatable values in the companion
+      // `_locales` table, and the migrated main table has no columns for them:
+      // unsplit, this insert names columns the table does not have and every
+      // row of a bulk create fails with the driver's own message. Split here,
+      // as `createEntry` does, so the two create paths write a localized
+      // collection the same way rather than one of them not at all. No locale
+      // is named — the bulk entry points refuse one — so this is the default
+      // language's write, which is what `undefined` resolves to. The metadata
+      // read is bound to this transaction's connection; a pooled one would
+      // wait for a connection this transaction is holding.
+      const localizedWrite = await this.splitLocalizedWriteData(
+        params.collectionName,
+        entryData,
+        undefined,
+        true,
+        tx.getDrizzle()
+      );
+
       // Insert using transaction context
       const entry = await tx.insert<unknown>(tableName, entryData, {
         returning: "*",
       });
 
+      // The companion row for this write's locale, on the same transaction, so
+      // it rolls back with the main row. A brand-new parent has no row to
+      // conflict with, which is why this inserts where the update path upserts.
+      if (localizedWrite) {
+        // A failure here is a write-integrity failure: the parent row is
+        // already written. Reported as a soft per-item failure, a batch under
+        // `stopOnError: false` would carry on and commit a document whose
+        // translations never landed — the row would exist with no content in
+        // any language. Marked, the batch loop aborts and the transaction
+        // rolls back, exactly as a failed component save does.
+        try {
+          await this.insertCompanionRow(
+            tx,
+            localizedWrite,
+            (entry as { id: string }).id
+          );
+        } catch (error: unknown) {
+          throw markWriteIntegrityFailure(error);
+        }
+        // Split out of the insert, so the returned row lacks them: merge them
+        // back for the hooks, the event and the response. Under the FIELD's
+        // name rather than the column's — a field whose column differs
+        // (`metaTitle` -> `meta_title`) would otherwise reach hooks and the
+        // durable snapshot under a key no field has.
+        for (const [field, value] of Object.entries(
+          localizedWrite.localizedFieldValues
+        )) {
+          (entry as Record<string, unknown>)[field] = value;
+        }
+      }
+
       await this.saveComponentFieldDataInTx(tx, {
         parentId: (entry as { id: string }).id,
         tableName,
@@ -8591,6 +8722,9 @@ export class CollectionMutationService extends BaseService {
         manyToManyData,
         user: params.user,
         actor: params.actor,
+        // The language this create's translatable values went into, so the
+        // version snapshot is tagged with it rather than reading as shared.
+        localeTag: localizedWrite?.writeLocale,
       });
       const eventRecorded = createEffects.eventRecorded;
       revalidationIntent = createEffects.revalidationIntent;
@@ -9012,11 +9146,11 @@ export class CollectionMutationService extends BaseService {
         fields
       );
 
+      // Before the localized split below. The upsert writes these straight
+      // into an existing translation, so an unconverted value fails there
+      // rather than on the main row, where the cause reads plainly.
+      this.serializeJsonFieldValues(finalData, fields);
       this.serializeHasManyRelationships(finalData, fields);
-
-      // Convert date-field strings into `Date` objects so Drizzle can bind
-      // them to `timestamp` columns. See `coerceDateFieldsToDate` for the
-      // failure mode this guards against.
       coerceDateFieldsToDate(finalData, fields);
 
       // Update using transaction context
@@ -9092,6 +9226,92 @@ export class CollectionMutationService extends BaseService {
         liveStatus: existingEntry.status,
       });
 
+      // The same split the single-entry update performs, for the same reason
+      // the create path above needs one: a localized collection's translatable
+      // values belong in the companion row, and the migrated main table has no
+      // columns for them. Skipped for a held edit, which writes no live row at
+      // all. No locale is named on this path, so it is the default language's.
+      const localizedUpdate = storeAsWorkingDraft
+        ? null
+        : await this.splitLocalizedWriteData(
+            params.collectionName,
+            finalData,
+            undefined,
+            false,
+            tx.getDrizzle()
+          );
+
+      // This locale's committed status, and its translations, as they stand
+      // BEFORE anything is written. Both describe the prior state, so both have
+      // to be read before the write that replaces it — read afterwards they
+      // would describe the result and silently agree with it.
+      //
+      // Read under the row lock the transition gate above already took, so the
+      // values are the committed ones and a concurrent writer cannot slip
+      // between the two.
+      let previousCompanionStatus: string | null = null;
+      const previousLocalizedValues = localizedUpdate
+        ? await this.readCompanionLocalizedValues(
+            tx,
+            params.collectionName,
+            entryId,
+            localizedUpdate.writeLocale
+          )
+        : {};
+      if (localizedUpdate?.hasStatus) {
+        // Gated on `hasStatus`: companion `_status` exists only on collections
+        // migrated for per-locale status, and querying it otherwise fails the
+        // whole write.
+        previousCompanionStatus = await this.readCompanionStatus(
+          tx,
+          localizedUpdate.companionTableName,
+          entryId,
+          localizedUpdate.writeLocale
+        );
+        // A write moves the published state in two places, and the gate must
+        // fire if EITHER makes a transition the caller cannot make. The main
+        // row was judged above; this judges the write locale's companion
+        // `_status`, which the upsert below writes. Checking only the main row
+        // misses the state a reconcile can leave — a draft `_status` under a
+        // published entry — where the main-row reading is `published ->
+        // published`, a no-op needing no grant, while the companion write
+        // publishes the translation.
+        const companionDenied = this.denyIfTransitionUngranted(
+          previousCompanionStatus,
+          localizedUpdate.companionData._status,
+          transitionAuth
+        );
+        // Before the UPDATE, so a denial leaves nothing written for this row.
+        if (companionDenied) return companionDenied;
+      }
+
+      // Where this language's publication state lives, before and after this
+      // write. On a collection that keeps status per language the companion row
+      // owns it, so BOTH readings have to come from there: what it held, and
+      // what this write leaves it holding — the value the patch set, or the one
+      // already there when the patch named no status.
+      //
+      // Taking one from the companion and the other from the main row reports a
+      // move no statement performed. A patch changing only translated content,
+      // under an entry whose main row is published while this translation is
+      // still a draft, would read `draft -> published` and announce
+      // `entry.published` for a translation nothing published.
+      const perLocaleStatus = localizedUpdate?.hasStatus === true;
+      // Whether a companion row is written at all decides whether this locale
+      // ends the write with a status of its own: a patch naming only shared
+      // fields writes none, and the locale keeps having none.
+      const writesCompanionRow =
+        !!localizedUpdate &&
+        Object.keys(localizedUpdate.companionData).length > 0;
+      const localeStatusAfter = perLocaleStatus
+        ? resolveEffectiveLocaleStatus({
+            hasStatus: true,
+            writesCompanionRow,
+            requestedStatus: localizedUpdate.companionData._status,
+            committedStatus: previousCompanionStatus,
+          })
+        : null;
+
       // Skip the live-row UPDATE for a held edit; the pending change is stored
       // below instead.
       const [updated] = storeAsWorkingDraft
@@ -9121,16 +9341,115 @@ export class CollectionMutationService extends BaseService {
         };
       }
 
+      // The translatable values, into the companion row for this write's
+      // locale, on the same transaction. An upsert rather than an insert: the
+      // parent already exists and may or may not have a row in this language.
+      // Nothing is written when the patch touched no translatable field —
+      // inventing a row there would claim a translation nobody made.
+      if (
+        localizedUpdate &&
+        Object.keys(localizedUpdate.companionData).length > 0
+      ) {
+        // Write-integrity, as in the create path: the main row is already
+        // written, and a soft per-item failure here would let the batch commit
+        // a row whose translation never landed.
+        try {
+          await upsertCompanionRow(
+            companionWriteVia(tx, this.dialect),
+            localizedUpdate.companionTableName,
+            entryId,
+            localizedUpdate.writeLocale,
+            localizedUpdate.companionData
+          );
+        } catch (error: unknown) {
+          throw markWriteIntegrityFailure(error);
+        }
+      }
+
+      // The whole of this locale, not only what the patch named. A partial
+      // translatable update carries just the changed values, and the main row
+      // holds no translatable ones at all — so a snapshot built from those two
+      // would record a document missing every field this write did not touch,
+      // and a restore from it would drop them.
+      //
+      // Derived from the values read BEFORE the write rather than read back
+      // after it. The upsert writes exactly the fields this write set, so the
+      // row it leaves is the prior row overlaid with those values — which is
+      // what this composes, field for field, without a second query. Deriving
+      // it also means no read stands between the write and the commit: a
+      // read-back that failed here would leave the main row already updated,
+      // and a caller that tolerates per-item failures would commit it without
+      // the version or the event that describe it. Keyed by field name.
+      const localizedDocument = localizedUpdate
+        ? {
+            ...previousLocalizedValues,
+            ...localizedUpdate.localizedFieldValues,
+          }
+        : {};
+      for (const [field, value] of Object.entries(localizedDocument)) {
+        if (field === "id") continue;
+        (updated as Record<string, unknown>)[field] = value;
+      }
+      // Whether this write put anything into one language in particular, named
+      // once because both the version and the events ask it.
+      //
+      // A status-only write looks like it should need a second clause and does
+      // not: `readCompanionLocalizedValues` resolves an absent translation to
+      // `null` rather than omitting it, so this map carries an entry for every
+      // localized field whenever there is a companion at all — including for a
+      // locale with no row yet. Adding `|| a status was written` would be
+      // unreachable.
+      const capturedLocaleState = Object.keys(localizedDocument).length > 0;
+      // The status the MAIN row now holds, read before the overlay below
+      // replaces it. The main row and a translation can move independently, so
+      // the two transitions are recorded separately and each needs its own
+      // pair of endpoints.
+      const mainStatusAfter = (updated as { status?: unknown }).status as
+        | string
+        | undefined;
+
+      // And this language's own status, for the same reason its values are
+      // overlaid: what is recorded describes one translation, and the main
+      // row's status describes the entry. Without it the snapshot and the
+      // event report a translation as published while its companion row still
+      // reads draft.
+      if (typeof localeStatusAfter === "string") {
+        (updated as Record<string, unknown>).status = localeStatusAfter;
+      }
+
+      // The row as it stood before this write, in the language this write
+      // describes. The main row carries no translatable values and, for a
+      // per-locale status, no current status either — both live in the
+      // companion — so `existingEntry` alone describes the prior state of a
+      // localized entry only in the fields that are not translated. Everything
+      // below that reports on the PREVIOUS state reads this rather than the
+      // main row: what a receiver is told changed, and which URL stops being
+      // valid, are both claims about the translation.
+      const previousEntry: Record<string, unknown> = {
+        ...existingEntry,
+        ...previousLocalizedValues,
+        ...(previousCompanionStatus !== null
+          ? { status: previousCompanionStatus }
+          : {}),
+      };
+
       // Compute the intent from the updated row and the pre-update row, before
       // the after-hooks run or redaction can strip the slug. The previous slug
-      // (from existingEntry) lets a batch rename bust the old slug tag too.
+      // lets a batch rename bust the old slug tag too — taken from the prior
+      // translation, since a localized `slug` lives in the companion and the
+      // main row's copy would leave the old URL cached.
       revalidationIntent = buildEntryRevalidationIntent(
         params.collectionName,
         readRevalidateConfig(collection),
         {
           id: entryId,
           slug: readStringField(updated as Record<string, unknown>, "slug"),
-          previousSlug: readStringField(existingEntry, "slug"),
+          previousSlug: readStringField(previousEntry, "slug"),
+          // The language this write describes, so the locale-specific tag is
+          // busted rather than only the unqualified one.
+          ...(localizedUpdate?.writeLocale
+            ? { locale: localizedUpdate.writeLocale }
+            : {}),
         }
       );
 
@@ -9173,7 +9492,7 @@ export class CollectionMutationService extends BaseService {
           collectionName: params.collectionName,
           tableName,
           entryId,
-          parentRow: this.readShapeEventDocument(existingEntry, fields),
+          parentRow: this.readShapeEventDocument(previousEntry, fields),
           fields,
           manyToManyFields,
           // A held edit needs the live relations regardless of what is being
@@ -9285,6 +9604,13 @@ export class CollectionMutationService extends BaseService {
           versionsConfig,
           documentParts: updatedParts,
           fields,
+          // The snapshot carries this locale's translatable values, so the
+          // version is tagged with it. Untagged, history reads the snapshot as
+          // shared and a restore drops every per-locale field — or refuses,
+          // on a collection where they all are.
+          localeTag: capturedLocaleState
+            ? localizedUpdate?.writeLocale
+            : undefined,
         });
       }
       const eventFields = await this.webhookFieldTreeIfRecording(
@@ -9299,6 +9625,14 @@ export class CollectionMutationService extends BaseService {
           kind: "entry",
           collection: params.collectionName,
           id: entryId,
+          // The language this event describes. A receiver reads it from the
+          // resource alone, so a localized write that omits it is delivered as
+          // belonging to no translation in particular. A write that moved only
+          // this locale's STATUS counts: it carries no field value, and
+          // counting field values alone would leave it unattributed.
+          ...(capturedLocaleState && localizedUpdate?.writeLocale
+            ? { locale: localizedUpdate.writeLocale }
+            : {}),
         },
         data: updatedDocument,
         previous: previousDocument,
@@ -9306,21 +9640,68 @@ export class CollectionMutationService extends BaseService {
         actor: eventActor,
       });
       if ((collection as { status?: boolean }).status === true) {
-        const statusRecorded = await this.recordStatusEvents(tx, {
-          collection: params.collectionName,
-          id: entryId,
-          from: readStringField(existingEntry, "status") ?? null,
-          to: (updated as { status?: unknown }).status as
-            | string
-            | null
-            | undefined,
-          isCreate: false,
-          data: updatedDocument,
-          previous: previousDocument,
-          fields: eventFields,
-          actor: eventActor,
-        });
-        eventRecorded = eventRecorded || statusRecorded;
+        // A write can move the published state in two places that move
+        // independently, so each is recorded on its own terms — the same
+        // routing the single-entry update performs. Collapsing them into one
+        // event gets a case wrong in each direction: a content-only patch on a
+        // draft translation under a published entry announces a publication
+        // nothing performed, and a patch that really does publish the main row
+        // while the default translation was already published announces
+        // nothing at all.
+        const mainFrom = readStringField(existingEntry, "status") ?? null;
+        const companionStatusWritten =
+          typeof localizedUpdate?.companionData._status === "string";
+        const companionNext = companionStatusWritten
+          ? (localizedUpdate.companionData._status as string)
+          : undefined;
+        // The default locale's status lives on BOTH the main row and its
+        // companion, so an ordinary default-locale write records the same
+        // transition twice. Suppress the main-row event only when the
+        // companion write encodes that identical move — same from AND same to.
+        const companionEncodesMainTransition =
+          companionStatusWritten &&
+          previousCompanionStatus === mainFrom &&
+          companionNext === mainStatusAfter;
+
+        if (!companionEncodesMainTransition) {
+          // Described in main-row terms: the documents carry this locale's
+          // status overlaid, which is the other transition, not this one.
+          const mainStatusRecorded = await this.recordStatusEvents(tx, {
+            collection: params.collectionName,
+            id: entryId,
+            from: mainFrom,
+            to: mainStatusAfter,
+            isCreate: false,
+            data:
+              mainStatusAfter !== undefined
+                ? { ...updatedDocument, status: mainStatusAfter }
+                : updatedDocument,
+            previous:
+              previousDocument !== null
+                ? { ...previousDocument, status: mainFrom }
+                : previousDocument,
+            fields: eventFields,
+            actor: eventActor,
+          });
+          eventRecorded = eventRecorded || mainStatusRecorded;
+        }
+
+        if (companionStatusWritten) {
+          // This translation's own move, tagged with the language it describes.
+          const localeStatusRecorded = await this.recordStatusEvents(tx, {
+            collection: params.collectionName,
+            id: entryId,
+            locale: localizedUpdate?.writeLocale,
+            from: previousCompanionStatus,
+            to: companionNext,
+            isCreate: false,
+            data: updatedDocument,
+            previous: previousDocument,
+            fields: eventFields,
+            actor: eventActor,
+          });
+          eventRecorded = eventRecorded || localeStatusRecorded;
+        }
       }
 
       // Execute afterUpdate hooks (unless skipped)
@@ -9368,14 +9749,45 @@ export class CollectionMutationService extends BaseService {
       // Field-level afterChange hooks observe the saved values (before the
       // password strip so they can see the full stored row).
       if (options.runHooks) {
-        await runFieldHooks({
-          kind: "collection",
-          slug: params.collectionName,
-          phase: "afterChange",
-          data: updated as Record<string, unknown>,
-          operation: "update",
-          user: params.user,
-        });
+        // A field hook fires for every key PRESENT in the row it is given, so
+        // the untouched translations overlaid above — needed by the snapshot
+        // and the event, which describe the whole language — would run their
+        // `afterChange` handlers for values this write never changed. Those
+        // handlers send mail, re-index and call out, so firing them for an
+        // unchanged sibling is not a harmless extra pass.
+        //
+        // Taken off for the hook phase and put back after it, rather than
+        // handed a copy: a handler's return value is written back into the
+        // row, and a copy would drop the transformations belonging to the
+        // fields this write DID set. The same remove-then-restore the field
+        // registry performs around its own snapshots.
+        const untouched = localizedUpdate
+          ? Object.keys(localizedDocument).filter(
+              name => !(name in localizedUpdate.localizedFieldValues)
+            )
+          : [];
+        const held = untouched.map(
+          name => [name, (updated as Record<string, unknown>)[name]] as const
+        );
+        for (const [name] of held) {
+          delete (updated as Record<string, unknown>)[name];
+        }
+        try {
+          await runFieldHooks({
+            kind: "collection",
+            slug: params.collectionName,
+            phase: "afterChange",
+            data: updated as Record<string, unknown>,
+            operation: "update",
+            user: params.user,
+          });
+        } finally {
+          // Restored even when a handler throws, so the response and anything
+          // read from the row afterwards still carry the whole language.
+          for (const [name, value] of held) {
+            (updated as Record<string, unknown>)[name] = value;
+          }
+        }
       }
 
       await this.redactResponseFields(
diff --git a/packages/nextly/src/domains/collections/services/collection-service.ts b/packages/nextly/src/domains/collections/services/collection-service.ts
index cb6faad3cc..e5a2bf8b45 100644
--- a/packages/nextly/src/domains/collections/services/collection-service.ts
+++ b/packages/nextly/src/domains/collections/services/collection-service.ts
@@ -73,7 +73,7 @@ import { BaseService } from "../../../shared/base-service";
 import type { WhereFilter } from "../query/query-operators";
 
 import type { CollectionMetadataService } from "./collection-metadata-service";
-import type { BatchOperationResult } from "./collection-types";
+import type { BatchOperationResult, BulkUpdateEntry } from "./collection-types";
 import { forwardedFromContext } from "./forwarded-context";
 
 /**
@@ -673,6 +673,65 @@ export class CollectionService extends BaseService {
     );
   }
 
+  /**
+   * Bulk-update entries in a single transaction.
+   *
+   * Each entry names the row it patches, so one call can apply a DIFFERENT
+   * patch per row. Applying the SAME patch to several rows is the same call
+   * with the patch repeated, which is why there is one method rather than two:
+   * a by-filter variant could express only the second, and would need its own
+   * access, hook and revalidation pass to do it.
+   *
+   * Partial success, like `createMany`: a failed entry does not stop the rest,
+   * and the ones that committed are reported in `ids`.
+   *
+   * 🔴 `errors[].index` indexes the `entries` array THIS caller passed, so the
+   * row a failure is about is `entries[index].id`. The result shape is shared
+   * with the creates, which have no caller-supplied ids to key failures by.
+   *
+   * @param collectionName - Name of the collection
+   * @param entries - `{ id, data }` per row; `data` is a partial patch
+   * @param context - Request context (carries `overrideAccess` for elevation)
+   * @returns Per-batch result: counts, updated ids, and index-keyed failures
+   *
+   * @experimental Graduates per D55 once a first-party plugin exercises it in
+   *   production; `packages/plugin-sdk/STABILITY.md` is the authority.
+   */
+  async updateMany(
+    collectionName: string,
+    entries: BulkUpdateEntry[],
+    context: RequestContext
+  ): Promise<BatchOperationResult> {
+    // Refused for the same reason `createMany` refuses it: the bulk pipeline
+    // takes no locale at all, so one accepted here would be dropped on the way
+    // in and every row written to the default language while the call reported
+    // success. A caller told nothing is worse off than a caller told no.
+    if (context.locale !== undefined) {
+      throw NextlyError.invalidInput({
+        message:
+          "updateMany cannot write in a locale; update the rows one at a time with updateEntry.",
+        logContext: {
+          reason: "update-many-locale-unsupported",
+          collectionName,
+          locale: context.locale,
+        },
+      });
+    }
+
+    this.logger.debug("Updating entries (bulk)", {
+      collectionName,
+      count: entries.length,
+    });
+
+    return this.entryService.updateEntries(
+      {
+        collectionName,
+        ...forwardedFromContext(context),
+      },
+      entries
+    );
+  }
+
   /**
    * List entries in a collection
    *
diff --git a/packages/nextly/src/domains/i18n/companion-columns.ts b/packages/nextly/src/domains/i18n/companion-columns.ts
index 48fd3c12e8..599f1f97fd 100644
--- a/packages/nextly/src/domains/i18n/companion-columns.ts
+++ b/packages/nextly/src/domains/i18n/companion-columns.ts
@@ -19,6 +19,42 @@
  */
 export const COMPANION_DEFAULT_STATUS = "draft";
 
+/**
+ * What a locale's publication status IS once this write has been applied.
+ *
+ * Three answers, in order, and the third is the one that is easy to miss: the
+ * status the write assigns; failing that the status the locale already had;
+ * failing that the column default — because a locale being translated for the
+ * first time has no companion row, and the upsert that creates one leaves
+ * `_status` on its DDL default.
+ *
+ * `null` means this write leaves the locale with no status of its own: either
+ * the entity keeps no per-locale status at all, or it writes no companion row,
+ * in which case the locale still has none. Claiming the default there would
+ * invent a draft nothing committed.
+ *
+ * One implementation because more than one write path needs the answer and a
+ * path that stops at the second case reports a brand-new translation with the
+ * MAIN row's status — telling receivers a translation is published when the
+ * row just written is a draft.
+ */
+export function resolveEffectiveLocaleStatus(args: {
+  /** Whether the companion carries a per-locale `_status` column at all. */
+  hasStatus: boolean;
+  /** Whether this write actually writes a companion row. */
+  writesCompanionRow: boolean;
+  /** The `_status` this write assigns, when it assigns one. */
+  requestedStatus: unknown;
+  /** The status this locale already had, or `null` when it had no row. */
+  committedStatus: string | null;
+}): string | null {
+  if (typeof args.requestedStatus === "string") return args.requestedStatus;
+  if (args.committedStatus !== null) return args.committedStatus;
+  return args.hasStatus && args.writesCompanionRow
+    ? COMPANION_DEFAULT_STATUS
+    : null;
+}
+
 /** Per-locale draft/publish state; present only when the entity has one. */
 export const COMPANION_STATUS_COLUMN = "_status";
 
diff --git a/packages/nextly/src/domains/singles/__tests__/single-publish-revalidates-its-draft.integration.test.ts b/packages/nextly/src/domains/singles/__tests__/single-publish-revalidates-its-draft.integration.test.ts
new file mode 100644
index 0000000000..77bd875572
--- /dev/null
+++ b/packages/nextly/src/domains/singles/__tests__/single-publish-revalidates-its-draft.integration.test.ts
@@ -0,0 +1,415 @@
+/**
+ * Publishing a Single re-judges the pending change it is about to promote.
+ *
+ * A Single's publish folds its held draft into the live row. Both the field
+ * rules and the schema's rules ran when the caller's payload arrived, and for
+ * a publish that payload is just `{ status: "published" }` — so the draft's
+ * own content reached the live row having been judged only when it was SAVED.
+ *
+ * Two things can have changed since. The publisher may not be the author: a
+ * field rule can deny them a value the author was allowed to write. And the
+ * schema can have tightened under a value that was legal when it was held.
+ * The collection publish path gates its promotion for both reasons; this is
+ * the same gate on the Singles path.
+ */
+import { mkdtempSync, rmSync } from "node:fs";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+
+import { afterEach, beforeEach, describe, expect, it } from "vitest";
+
+import { defineSingle, group, text } from "../../../config";
+import type { HookContext } from "../../../hooks/types";
+import { createAdapter } from "../../../database/factory";
+import {
+  createTestNextly,
+  type TestNextly,
+} from "../../../plugins/test-nextly";
+import type { SingleEntryService } from "../services/single-entry-service";
+
+const SLUG = "prefs";
+const BOSS = { id: "boss", email: "boss@x.test" };
+const CLERK = { id: "clerk", email: "clerk@x.test" };
+
+let dir: string;
+let dbPath: string;
+let current: TestNextly | undefined;
+let previousDialect: string | undefined;
+
+beforeEach(() => {
+  previousDialect = process.env.DB_DIALECT;
+  dir = mkdtempSync(join(tmpdir(), "nextly-single-promote-"));
+  dbPath = join(dir, "test.db");
+});
+
+afterEach(async () => {
+  await current?.destroy();
+  current = undefined;
+  if (previousDialect === undefined) delete process.env.DB_DIALECT;
+  else process.env.DB_DIALECT = previousDialect;
+  rmSync(dir, { recursive: true, force: true });
+});
+
+/**
+ * `strict` decides whether `checked` carries a rule. Booting twice against one
+ * database file, once without it and once with, is how a draft held under an
+ * older schema is reproduced: the value was legal when it was saved.
+ */
+async function boot(
+  strict: boolean,
+  /** Turns any write into a publish, deciding the status after the gate's old
+   * pre-hook position and before the promotion. */
+  publishFromHook = false
+): Promise<SingleEntryService> {
+  process.env.DB_DIALECT = "sqlite";
+  const adapter = await createAdapter({
+    type: "sqlite",
+    url: `file:${dbPath}`,
+  } as Parameters<typeof createAdapter>[0]);
+  current = await createTestNextly({
+    adapter,
+    singles: [
+      defineSingle({
+        slug: SLUG,
+        status: true,
+        versions: { drafts: true },
+        access: { read: () => true, update: () => true },
+        hooks: {
+          beforeChange: [
+            (ctx: HookContext) => {
+              const data = ctx.data as Record<string, unknown>;
+              // Only in the case that asks for it, and only on the write under
+              // test, so every other write here still holds its edit.
+              return publishFromHook && data.siteName === "Edited"
+                ? { ...data, status: "published" }
+                : data;
+            },
+          ],
+        },
+        fields: [
+          text({ name: "siteName" }),
+          // A JSON-backed field, so every case here also proves the gate reads
+          // a snapshot in its logical shape. A snapshot stores this as the
+          // string that was written; judged as-is, the validator calls it an
+          // invalid type and an ordinary publish is refused.
+          group({ name: "seo", fields: [text({ name: "metaTitle" })] }),
+          // A denied field NESTED in a group. The rules remove it from inside
+          // the container, which leaves the container itself present.
+          group({
+            name: "ops",
+            fields: [
+              text({
+                name: "runbook",
+                access: {
+                  update: ({ req }) => req.user?.email === BOSS.email,
+                },
+              }),
+            ],
+          }),
+          text({
+            name: "guarded",
+            access: { update: ({ req }) => req.user?.email === BOSS.email },
+          }),
+          text({
+            name: "checked",
+            ...(strict
+              ? {
+                  validate: (v: unknown) =>
+                    v === undefined ||
+                    v === null ||
+                    v === "ok" ||
+                    "checked must be ok",
+                }
+              : {}),
+          }),
+        ],
+      }),
+    ],
+  });
+  return current.getService("singleEntryService");
+}
+
+async function reboot(strict: boolean): Promise<SingleEntryService> {
+  await current?.destroy();
+  current = undefined;
+  return boot(strict);
+}
+
+describe("a Single's publish re-judges the draft it promotes", () => {
+  it("refuses to publish a change the PUBLISHER may not write, and keeps it", async () => {
+    const singles = await boot(false);
+    await singles.update(
+      SLUG,
+      { siteName: "Live", status: "published" },
+      { overrideAccess: true }
+    );
+    // The author may write `guarded`, so the held draft carries their edit.
+    const held = await singles.update(
+      SLUG,
+      { guarded: "secret" },
+      { routeAuthorized: true, user: BOSS }
+    );
+    expect(held.success, JSON.stringify(held)).toBe(true);
+
+    // Someone else publishes. The field rule denies THEM that field.
+    const published = await singles.update(
+      SLUG,
+      { status: "published" },
+      { routeAuthorized: true, user: CLERK }
+    );
+
+    expect(published.success).toBe(false);
+    const issues = (
+      published as {
+        publicData?: { errors?: Array<{ path: string; code: string }> };
+      }
+    ).publicData?.errors;
+    expect(issues?.map(i => i.path)).toEqual(["guarded"]);
+    expect(issues?.[0]?.code).toBe("FORBIDDEN");
+
+    // Refused rather than stripped, because a successful publish CONSUMES the
+    // draft: stripping would have published the rest, deleted the pending
+    // change and destroyed the author's edit with it. The draft is still here.
+    const drafts = await current!.adapter.select<{ snapshot: unknown }>(
+      "nextly_versions",
+      {
+        where: {
+          and: [
+            { column: "scopeKind", op: "=", value: "single" },
+            { column: "scopeSlug", op: "=", value: SLUG },
+            { column: "versionNo", op: "IS NULL" },
+            { column: "status", op: "=", value: "draft" },
+          ],
+        },
+      }
+    );
+    expect(drafts).toHaveLength(1);
+    expect((drafts[0].snapshot as { guarded?: unknown }).guarded).toBe(
+      "secret"
+    );
+  });
+
+  it("publishes normally when the draft changes nothing the publisher is denied", async () => {
+    const singles = await boot(false);
+    await singles.update(
+      SLUG,
+      { siteName: "Live", status: "published" },
+      { overrideAccess: true }
+    );
+    // The draft edits only a field this publisher may write. `guarded` is in
+    // the snapshot too, as it is in every snapshot, but it is unchanged.
+    await singles.update(
+      SLUG,
+      { siteName: "Edited" },
+      { routeAuthorized: true, user: CLERK }
+    );
+
+    const published = await singles.update(
+      SLUG,
+      { status: "published" },
+      { routeAuthorized: true, user: CLERK }
+    );
+    expect(published.success, JSON.stringify(published)).toBe(true);
+
+    const live = await singles.get(SLUG, { overrideAccess: true });
+    expect((live.data as { siteName?: unknown }).siteName).toBe("Edited");
+  });
+
+  it("still promotes it for a publisher who MAY write it", async () => {
+    const singles = await boot(false);
+    await singles.update(
+      SLUG,
+      { siteName: "Live", status: "published" },
+      { overrideAccess: true }
+    );
+    await singles.update(
+      SLUG,
+      { guarded: "secret" },
+      { routeAuthorized: true, user: BOSS }
+    );
+
+    const published = await singles.update(
+      SLUG,
+      { status: "published" },
+      { routeAuthorized: true, user: BOSS }
+    );
+    expect(published.success, JSON.stringify(published)).toBe(true);
+
+    const live = await singles.get(SLUG, { overrideAccess: true });
+    expect((live.data as { guarded?: unknown }).guarded).toBe("secret");
+  });
+
+  it("refuses a draft the schema has since made invalid, naming the field", async () => {
+    let singles = await boot(false);
+    await singles.update(
+      SLUG,
+      { siteName: "Live", status: "published" },
+      { overrideAccess: true }
+    );
+    // Legal under the schema as it stands: no rule on `checked` yet.
+    const held = await singles.update(
+      SLUG,
+      { checked: "anything" },
+      { overrideAccess: true }
+    );
+    expect(held.success, JSON.stringify(held)).toBe(true);
+
+    // The schema tightens while the draft is held.
+    singles = await reboot(true);
+    const published = await singles.update(
+      SLUG,
+      { status: "published" },
+      { overrideAccess: true }
+    );
+
+    expect(published.success).toBe(false);
+    expect(published.statusCode).toBe(400);
+    // The author cannot fix what they are not told: the refusal names the
+    // field and carries the rule's own message.
+    const issues = (
+      published as {
+        publicData?: { errors?: Array<{ path: string; message: string }> };
+      }
+    ).publicData?.errors;
+    expect(issues?.map(i => i.path)).toContain("checked");
+    expect(issues?.map(i => i.message).join(" ")).toContain("must be ok");
+
+    // And nothing was published: the live row still holds what it held.
+    const live = await singles.get(SLUG, { overrideAccess: true });
+    expect((live.data as { checked?: unknown }).checked ?? null).toBeNull();
+  });
+  it("publishes a draft that holds a group value", async () => {
+    const singles = await boot(false);
+    await singles.update(
+      SLUG,
+      {
+        siteName: "Live",
+        seo: { metaTitle: "Title" },
+        status: "published",
+      },
+      { overrideAccess: true }
+    );
+    await singles.update(
+      SLUG,
+      { siteName: "Edited" },
+      { overrideAccess: true }
+    );
+
+    const published = await singles.update(
+      SLUG,
+      { status: "published" },
+      { overrideAccess: true }
+    );
+
+    expect(published.success, JSON.stringify(published)).toBe(true);
+    const live = await singles.get(SLUG, { overrideAccess: true });
+    expect((live.data as { siteName?: unknown }).siteName).toBe("Edited");
+    // The group survived the round trip as an object, not as its stored text.
+    expect((live.data as { seo?: unknown }).seo).toEqual({
+      metaTitle: "Title",
+    });
+  });
+  it("gates publishAllLocales too, not only the ordinary publish", async () => {
+    let singles = await boot(false);
+    await singles.update(
+      SLUG,
+      { siteName: "Live", status: "published" },
+      { overrideAccess: true }
+    );
+    // Legal under the schema as it stands.
+    await singles.update(
+      SLUG,
+      { checked: "anything" },
+      { overrideAccess: true }
+    );
+
+    // The schema tightens while the change is held.
+    singles = await reboot(true);
+    // The other publish path: it promotes every language's pending change in
+    // its own loop, and had no gate of its own at all. `overrideAccess` waives
+    // the field rules, so what this proves is that the SCHEMA gate runs here.
+    // This path reports a refusal by throwing, where `update` returns a
+    // result; both carry the same validation issues.
+    let issues: Array<{ path: string; message: string }> | undefined;
+    await expect(
+      singles.publishAllLocales(SLUG, { overrideAccess: true }).catch(error => {
+        issues = (
+          error as {
+            publicData?: {
+              errors?: Array<{ path: string; message: string }>;
+            };
+          }
+        ).publicData?.errors;
+        throw error;
+      })
+    ).rejects.toMatchObject({ code: "VALIDATION_ERROR" });
+    expect(issues?.map(i => i.path)).toContain("checked");
+    expect(issues?.map(i => i.message).join(" ")).toContain("must be ok");
+
+    // And it did not consume the pending change on its way out.
+    const drafts = await current!.adapter.select("nextly_versions", {
+      where: {
+        and: [
+          { column: "scopeSlug", op: "=", value: SLUG },
+          { column: "versionNo", op: "IS NULL" },
+          { column: "status", op: "=", value: "draft" },
+        ],
+      },
+    });
+    expect(drafts).toHaveLength(1);
+  });
+  it("catches a denied field NESTED inside a group", async () => {
+    const singles = await boot(false);
+    await singles.update(
+      SLUG,
+      { siteName: "Live", status: "published" },
+      { overrideAccess: true }
+    );
+    await singles.update(
+      SLUG,
+      { ops: { runbook: "internal" } },
+      { routeAuthorized: true, user: BOSS }
+    );
+
+    const published = await singles.update(
+      SLUG,
+      { status: "published" },
+      { routeAuthorized: true, user: CLERK }
+    );
+
+    expect(published.success).toBe(false);
+    const issues = (
+      published as { publicData?: { errors?: Array<{ path: string }> } }
+    ).publicData?.errors;
+    // Named at its own depth, so the author can see which child is at fault.
+    expect(issues?.map(i => i.path)).toEqual(["ops.runbook"]);
+  });
+
+  it("gates a publish a beforeChange hook decides on", async () => {
+    // The caller sends no status; the hook turns the write into a publish. A
+    // gate placed before the hooks would never see this one.
+    const singles = await boot(false, true);
+    await singles.update(
+      SLUG,
+      { siteName: "Live", status: "published" },
+      { overrideAccess: true }
+    );
+    await singles.update(
+      SLUG,
+      { guarded: "secret" },
+      { routeAuthorized: true, user: BOSS }
+    );
+
+    const published = await singles.update(
+      SLUG,
+      { siteName: "Edited" },
+      { routeAuthorized: true, user: CLERK }
+    );
+
+    expect(published.success).toBe(false);
+    const issues = (
+      published as { publicData?: { errors?: Array<{ path: string }> } }
+    ).publicData?.errors;
+    expect(issues?.map(i => i.path)).toEqual(["guarded"]);
+  });
+});
diff --git a/packages/nextly/src/domains/singles/services/promote-gate.ts b/packages/nextly/src/domains/singles/services/promote-gate.ts
new file mode 100644
index 0000000000..31998a3fa6
--- /dev/null
+++ b/packages/nextly/src/domains/singles/services/promote-gate.ts
@@ -0,0 +1,310 @@
+/**
+ * Judging a Single's pending change before it is published.
+ *
+ * A publish folds a held draft into the live row. Field access and validation
+ * run when the caller's payload arrives, and for a publish that payload is
+ * just the new status, so without this the draft's content reaches the live
+ * row having been judged only when it was SAVED. Two things can have changed
+ * since: the publisher may not be the author, so a field rule can deny them a
+ * value the author was allowed to write; and the schema can have tightened
+ * under a value that was legal when it was held.
+ *
+ * One module because there are two publish paths. `SingleMutationService`
+ * promotes one language's draft on an ordinary publish, and
+ * `SinglePublishAllService` promotes every language's in its own loop. Two
+ * gates would be two answers to one question, and the second would be the one
+ * nobody remembered to update.
+ *
+ * Called INSIDE the write transaction, on the draft that transaction has
+ * locked. Judged before it, the gate can only judge a copy of the world as it
+ * was: another writer saving a draft in between, a `beforeChange` hook
+ * rewriting the status, or the fold merging several languages onto one row all
+ * make the checked document and the written document different documents. The
+ * one thing that cannot be done inside the transaction is resolve the caller's
+ * grants, which queries the pooled connection the transaction is holding, so
+ * that is resolved by the caller beforehand and handed in.
+ *
+ * @module domains/singles/services/promote-gate
+ */
+
+import { isDeepStrictEqual } from "node:util";
+
+import type { AuthenticatedScope } from "../../../auth/authenticated-scope";
+import type { FieldConfig } from "../../../collections/fields/types";
+import { NextlyError } from "../../../errors";
+import { detachData } from "../../../shared/lib/detach";
+import { validateEntryData } from "../../../shared/lib/entry-validation";
+import {
+  applyFieldWriteAccess,
+  attachFieldValidators,
+  type CallerGrants,
+} from "../../../shared/lib/field-level-registry";
+import { relationshipValidationView } from "../../../shared/lib/field-transform";
+
+/** One language's pending change, as the versions repository stores it. */
+export interface PromotableDraft {
+  /** The language it is keyed under; `null` for an unlocalized Single. */
+  locale: string | null;
+  /** The stored snapshot, in write shape. */
+  snapshot: unknown;
+}
+
+/** What judging a promotion needs from the service that performs it. */
+export interface PromoteGateContext {
+  slug: string;
+  entryId: string;
+  fields: FieldConfig[];
+  user?: Record<string, unknown>;
+  overrideAccess?: boolean;
+  /**
+   * The caller's grants, resolved on the pooled connection BEFORE the
+   * transaction opened.
+   *
+   * Resolving them here would issue queries while the transaction holds a
+   * connection, and on a small pool those queries wait for the connection the
+   * transaction is holding: the publish hangs rather than fails.
+   */
+  grants?: () => Promise<CallerGrants>;
+  /**
+   * The scope an API key arrived with, so a key is judged on ITS grants rather
+   * than on the database roles of whoever owns it. There is no request-local
+   * scope to inherit on the Direct API, so it travels as an argument.
+   */
+  authenticatedScope?: AuthenticatedScope;
+  /**
+   * A stored document in the logical shape the rules are written against.
+   *
+   * A snapshot holds JSON-backed values (a group, a repeater, `chips`, `json`)
+   * as the strings that were written, and a validator for those fields expects
+   * the object or the array. Judged without this, an ordinary publish of a
+   * Single that merely HAS a group field is refused as an invalid type.
+   */
+  toLogical: (doc: Record<string, unknown>) => Record<string, unknown>;
+  /**
+   * The live row for one language, as STORED, used to decide whether promoting
+   * a denied field would change anything. It goes through `toLogical` here, as
+   * the snapshot does, so both sides of the comparison are one representation.
+   *
+   * A read's expanded document is the wrong source: it turns an upload or a
+   * relationship into the document behind the identifier, so an untouched
+   * field reads as an edit and a publish nobody objected to is refused.
+   */
+  liveStoredFor: (
+    locale: string | null
+  ) => Promise<Record<string, unknown> | undefined>;
+  /**
+   * The caller's own payload, which wins over the draft. Already judged by the
+   * gates that run over what the caller sent, and folded in here because the
+   * document that gets written is the draft with this on top.
+   */
+  callerData?: Record<string, unknown>;
+  localizedFieldNames: Set<string>;
+  enforceLocalizedRequired: boolean;
+}
+
+/**
+ * Refuse the publish unless the pending changes may be promoted as they stand.
+ *
+ * The drafts are judged as ONE outcome, not one at a time. `publishAllLocales`
+ * applies every language's snapshot to the same main row, so the shared values
+ * that survive are the last writer's: judged separately, each draft can pass
+ * against its own shared values while the document that actually lands holds
+ * another language's. What is judged here is the state the write produces.
+ *
+ * Throws on the first problem, so nothing is written: a publish applies the
+ * whole pending change or none of it.
+ */
+export async function assertDraftsMayBePromoted(
+  drafts: readonly PromotableDraft[],
+  ctx: PromoteGateContext
+): Promise<void> {
+  if (drafts.length === 0) return;
+
+  // The shared half of what the write produces, in the order the write applies
+  // it, so the last value to land is the one judged.
+  let shared: Record<string, unknown> = {};
+  for (const draft of drafts) {
+    shared = { ...shared, ...ctx.toLogical(asRecord(draft.snapshot)) };
+  }
+
+  for (const draft of drafts) {
+    // This language's own values over the shared outcome, then the caller's
+    // payload over both: the document this language ends up with.
+    const promoted = {
+      ...shared,
+      ...ctx.toLogical(asRecord(draft.snapshot)),
+      ...(ctx.callerData ?? {}),
+    };
+    await assertNoDeniedChange(
+      ctx.toLogical(asRecord(draft.snapshot)),
+      draft.locale,
+      ctx
+    );
+    await assertSchemaStillAccepts(promoted, ctx);
+  }
+}
+
+function asRecord(value: unknown): Record<string, unknown> {
+  return value && typeof value === "object"
+    ? (value as Record<string, unknown>)
+    : {};
+}
+
+/**
+ * Refuse a promotion that would change a field this publisher may not write.
+ *
+ * Refused rather than stripped, which is the opposite of what a denied field
+ * gets on an ordinary write. There, the value is the caller's own input and
+ * dropping it costs them nothing they did not already have. Here the value
+ * belongs to whoever saved the draft, and a successful publish CONSUMES the
+ * pending change: stripping would publish everything else, delete the draft,
+ * and take that author's edit with it, reporting success. Refusing keeps the
+ * draft for someone who can write the field.
+ *
+ * Judged in STORED shape, on both sides, and on what would CHANGE rather than
+ * on what the snapshot holds: a snapshot is a full copy of the document, so a
+ * denied field appears in every one of them, and only a value that differs
+ * from what is live is a change being made.
+ */
+async function assertNoDeniedChange(
+  logicalSnapshot: Record<string, unknown>,
+  locale: string | null,
+  ctx: PromoteGateContext
+): Promise<void> {
+  // A deep copy, because the rules delete a denied value in place and a
+  // shallow one shares every nested group, repeater row and component with the
+  // original: the deletion would land on both, and the comparison below would
+  // then see a container still present and report nothing denied while the
+  // write persisted the forbidden nested edit.
+  const permitted = detachData(logicalSnapshot);
+  await applyFieldWriteAccess({
+    kind: "single",
+    slug: ctx.slug,
+    data: permitted,
+    operation: "update",
+    user: ctx.user,
+    authenticatedScope: ctx.authenticatedScope,
+    overrideAccess: ctx.overrideAccess,
+    grants: ctx.grants,
+    id: ctx.entryId,
+  });
+
+  const denied = deniedPaths(logicalSnapshot, permitted, "");
+  if (denied.length === 0) return;
+
+  // Both sides through the same conversion, so a JSON-backed value is an
+  // object on both and an upload or a relationship is the identifier it is
+  // stored as on both. Compared across representations, an untouched field
+  // reads as an edit and a publish nobody objected to is refused.
+  const live = ctx.toLogical(asRecord(await ctx.liveStoredFor(locale)));
+  const deniedChanges = denied.filter(
+    path =>
+      !isDeepStrictEqual(valueAt(logicalSnapshot, path), valueAt(live, path))
+  );
+  if (deniedChanges.length === 0) return;
+
+  throw NextlyError.validation({
+    errors: deniedChanges.map(path => ({
+      path,
+      code: "FORBIDDEN",
+      message:
+        "The pending change edits this field and you do not have permission to write it, so it cannot be published. The change is kept.",
+    })),
+    logContext: {
+      cause: "promote-denied-field",
+      slug: ctx.slug,
+      locale,
+      fields: deniedChanges,
+    },
+  });
+}
+
+/**
+ * Every path the rules removed, at any depth.
+ *
+ * A field rule can sit on a child of a group or of a repeater row, and the
+ * removal there leaves the container in place: comparing only the top level
+ * reports nothing denied and lets the forbidden nested edit through.
+ */
+function deniedPaths(
+  before: unknown,
+  after: unknown,
+  prefix: string
+): string[] {
+  if (Array.isArray(before)) {
+    if (!Array.isArray(after)) return [prefix];
+    return before.flatMap((row, index) =>
+      deniedPaths(row, after[index], `${prefix}[${index}]`)
+    );
+  }
+  if (!isRecord(before)) return [];
+  if (!isRecord(after)) return [prefix];
+  const out: string[] = [];
+  for (const key of Object.keys(before)) {
+    const path = prefix ? `${prefix}.${key}` : key;
+    if (!Object.prototype.hasOwnProperty.call(after, key)) {
+      out.push(path);
+      continue;
+    }
+    out.push(...deniedPaths(before[key], after[key], path));
+  }
+  return out;
+}
+
+/** Read a dotted/bracketed path the way {@link deniedPaths} writes one. */
+function valueAt(root: unknown, path: string): unknown {
+  let current: unknown = root;
+  for (const step of path.split(/\.|\[(\d+)\]/).filter(Boolean)) {
+    if (Array.isArray(current) && /^\d+$/.test(step)) {
+      current = current[Number(step)];
+      continue;
+    }
+    if (!isRecord(current)) return undefined;
+    current = current[step];
+  }
+  return current;
+}
+
+function isRecord(value: unknown): value is Record<string, unknown> {
+  return typeof value === "object" && value !== null && !Array.isArray(value);
+}
+
+/**
+ * Refuse a promotion the schema no longer accepts, naming every field at
+ * fault so the author can see what to fix.
+ *
+ * Judged as a CREATE would be, not as a patch. A patch checks the keys it
+ * carries and skips the ones it does not, which is right for a caller sending
+ * a few fields and wrong here: a snapshot older than a newly required field
+ * simply has no property for it, so patch semantics report nothing and publish
+ * a document that violates the contract. The promoted document is the whole
+ * document, so it is judged whole.
+ *
+ * Judged on the snapshot being promoted and never on the live document: a
+ * schema change must not block someone from fixing and republishing content
+ * that has nothing to do with it.
+ */
+async function assertSchemaStillAccepts(
+  promoted: Record<string, unknown>,
+  ctx: PromoteGateContext
+): Promise<void> {
+  const issues = await validateEntryData(
+    relationshipValidationView(promoted, ctx.fields),
+    attachFieldValidators("single", ctx.slug, ctx.fields),
+    {
+      mode: "create",
+      req: ctx.user ? { user: ctx.user } : {},
+      localizedFieldNames: ctx.localizedFieldNames,
+      enforceLocalizedRequired: ctx.enforceLocalizedRequired,
+    }
+  );
+  if (issues.length > 0) {
+    throw NextlyError.validation({
+      errors: issues,
+      logContext: {
+        cause: "promote-invalid-under-current-schema",
+        slug: ctx.slug,
+      },
+    });
+  }
+}
diff --git a/packages/nextly/src/domains/singles/services/single-entry-service.ts b/packages/nextly/src/domains/singles/services/single-entry-service.ts
index 8d3b46b707..6260ed7d8b 100644
--- a/packages/nextly/src/domains/singles/services/single-entry-service.ts
+++ b/packages/nextly/src/domains/singles/services/single-entry-service.ts
@@ -141,7 +141,13 @@ export class SingleEntryService extends BaseService {
       singleRegistryService,
       fieldGroupDataService,
       rbacAccessControlService,
-      localization
+      localization,
+      // Publishing every language promotes every language's pending change,
+      // and judging one before it is promoted means reading: the stored
+      // snapshot in its logical shape, and the live document of the language
+      // it belongs to. The read service is the one that answers both, and
+      // this path is built here where it already exists.
+      this.queryService
     );
   }
 
diff --git a/packages/nextly/src/domains/singles/services/single-mutation-service.ts b/packages/nextly/src/domains/singles/services/single-mutation-service.ts
index a040aa9896..2debb49966 100644
--- a/packages/nextly/src/domains/singles/services/single-mutation-service.ts
+++ b/packages/nextly/src/domains/singles/services/single-mutation-service.ts
@@ -59,6 +59,7 @@ import {
   applyFieldWriteAccess,
   attachFieldValidators,
   runFieldHooks,
+  writeAccessGrants,
 } from "../../../shared/lib/field-level-registry";
 import {
   coerceDateFieldsToDate,
@@ -128,6 +129,7 @@ import {
   writeCompanionValues,
 } from "./apply-pending-change";
 import { resolveSingleForRequest } from "./ensure-runtime-table";
+import { assertDraftsMayBePromoted } from "./promote-gate";
 import {
   SingleQueryService,
   buildSingleHookContext,
@@ -649,6 +651,17 @@ export class SingleMutationService extends BaseService {
         }
       }
 
+      // 6.3. A publish promotes the held pending change, and that content has
+      // been judged only once, when it was SAVED. The gate that judges it
+      // again runs inside the write transaction, on the draft that transaction
+      // has locked. The one thing it cannot do there is resolve the caller's
+      // grants, which queries the pooled connection the transaction is
+      // holding, so that is resolved here and handed in.
+      const promoteGrants = writeAccessGrants(
+        options.user,
+        options.authenticatedScope
+      );
+
       // 6.25. Single-level beforeChange hooks, on data the validation gate has
       // just passed. The declaration used to register onto `beforeUpdate`,
       // which runs above at step 5 -- before validation -- so the hook that
@@ -1320,6 +1333,52 @@ export class SingleMutationService extends BaseService {
                 singleDraftLocale
               );
               if (pendingDraft) {
+                // Judged here, on the draft this transaction has LOCKED, and
+                // after the hooks that decide the status. Before the
+                // transaction the gate could only judge a copy of the world as
+                // it was: another writer saving a draft in between, or a
+                // `beforeChange` hook turning a status-less edit into a
+                // publish, would both leave the checked document and the
+                // written document different documents.
+                // Narrowed once for the gate's arguments; the fold below
+                // already runs under the same non-null condition.
+                const promotedInto = existingDoc;
+                await assertDraftsMayBePromoted(
+                  [
+                    {
+                      locale: singleDraftLocale ?? null,
+                      snapshot: pendingDraft.snapshot,
+                    },
+                  ],
+                  {
+                    slug,
+                    entryId: promotedInto.id,
+                    fields: fieldConfigs,
+                    user: options.user,
+                    overrideAccess: options.overrideAccess,
+                    authenticatedScope: options.authenticatedScope,
+                    // Resolved on the pooled connection before this
+                    // transaction opened.
+                    grants: promoteGrants,
+                    // A snapshot belongs to this document, so its identity is
+                    // this document's. Supplying both ahead of the spread
+                    // satisfies the stored-document shape without asserting
+                    // one, and lets the snapshot's own values win.
+                    toLogical: doc =>
+                      this.queryService.deserializeJsonFields(
+                        {
+                          id: promotedInto.id,
+                          updatedAt: promotedInto.updatedAt,
+                          ...doc,
+                        },
+                        singleMeta.fields
+                      ),
+                    liveStoredFor: () => Promise.resolve(promotedInto),
+                    callerData: currentData,
+                    localizedFieldNames,
+                    enforceLocalizedRequired,
+                  }
+                );
                 // The caller's own payload wins over the pending change: a
                 // publish that also sets a field is saying something about that
                 // field now.
diff --git a/packages/nextly/src/domains/singles/services/single-publish-all.ts b/packages/nextly/src/domains/singles/services/single-publish-all.ts
index 5bd11e8393..17afc99039 100644
--- a/packages/nextly/src/domains/singles/services/single-publish-all.ts
+++ b/packages/nextly/src/domains/singles/services/single-publish-all.ts
@@ -32,6 +32,10 @@ import type { DynamicSingleRecord } from "../../../schemas/dynamic-singles/types
 import type { FieldGroupDataService } from "../../../services/field-groups/field-group-data-service";
 import { BaseService } from "../../../shared/base-service";
 import { convertTimestampsToCamelCase } from "../../../shared/lib/case-conversion";
+import {
+  writeAccessGrants,
+  type CallerGrants,
+} from "../../../shared/lib/field-level-registry";
 import type { Logger } from "../../../shared/types";
 import { readComponentSubtrees } from "../../field-groups/read-component-subtrees";
 import { readCompanionLocaleStatusAll } from "../../i18n/companion-join";
@@ -69,7 +73,11 @@ import {
   writeCompanionValues,
 } from "./apply-pending-change";
 import { resolveSingleForRequest } from "./ensure-runtime-table";
-import { checkSingleAccess } from "./single-query-service";
+import { assertDraftsMayBePromoted } from "./promote-gate";
+import {
+  checkSingleAccess,
+  type SingleQueryService,
+} from "./single-query-service";
 import type { SingleRegistryService } from "./single-registry-service";
 import {
   buildSingleWebhookDoc,
@@ -128,7 +136,9 @@ export class SinglePublishAllService extends BaseService {
     private readonly singleRegistryService: SingleRegistryService,
     private readonly fieldGroupDataService?: FieldGroupDataService,
     private readonly rbacAccessControlService?: RBACAccessControlService,
-    private readonly localization?: SanitizedLocalizationConfig
+    private readonly localization?: SanitizedLocalizationConfig,
+    /** Reads the promote gate needs: the logical shape, and the live document. */
+    private readonly queryService?: SingleQueryService
   ) {
     super(adapter, logger);
   }
@@ -159,8 +169,18 @@ export class SinglePublishAllService extends BaseService {
       const denial = await this.authorizePublish(plan, options);
       if (denial) return denial;
 
+      // Resolved here because the gate that uses them runs inside the write
+      // transaction, and resolving grants queries the pooled connection that
+      // transaction is holding.
+      const promoteGrants = writeAccessGrants(
+        options.user,
+        options.authenticatedScope
+      );
+
       const outcome = await withVersionConflictRetry(() =>
-        this.adapter.transaction(tx => this.commitPublish(tx, plan, options))
+        this.adapter.transaction(tx =>
+          this.commitPublish(tx, plan, options, promoteGrants)
+        )
       );
 
       // The document was deleted out from under the publish: nothing was
@@ -372,7 +392,9 @@ export class SinglePublishAllService extends BaseService {
   private async commitPublish(
     tx: TransactionContext,
     plan: PublishPlan,
-    options: PublishAllSingleLocalesOptions
+    options: PublishAllSingleLocalesOptions,
+    /** Resolved before this transaction opened; see `publishAllLocales`. */
+    promoteGrants?: () => Promise<CallerGrants>
   ): Promise<PublishOutcome> {
     const { slug, singleMeta, existingDoc, hasMainStatus } = plan;
 
@@ -406,7 +428,9 @@ export class SinglePublishAllService extends BaseService {
       tx,
       plan,
       lockedRow,
-      priorCompanionStatuses
+      priorCompanionStatuses,
+      options,
+      promoteGrants
     );
 
     if (singleMeta.versions?.enabled) {
@@ -454,7 +478,10 @@ export class SinglePublishAllService extends BaseService {
     tx: TransactionContext,
     plan: PublishPlan,
     lockedRow: Record<string, unknown>,
-    priorCompanionStatuses: Map<string, string | null>
+    priorCompanionStatuses: Map<string, string | null>,
+    options: PublishAllSingleLocalesOptions,
+    /** Resolved before this transaction opened; see `publishAllLocales`. */
+    promoteGrants?: () => Promise<CallerGrants>
   ): Promise<{
     publishedRow: Record<string, unknown>;
     mainRowTransitioned: boolean;
@@ -489,7 +516,13 @@ export class SinglePublishAllService extends BaseService {
     // the statuses would all say published while the content each author was
     // holding stayed unapplied — the document would report itself fully
     // published and show none of the work being published.
-    await this.promotePendingChanges(tx, plan, publishNow);
+    await this.promotePendingChanges(
+      tx,
+      plan,
+      publishNow,
+      options,
+      promoteGrants
+    );
 
     if (companion && plan.companionPublishable) {
       // Every stored translation moves in ONE statement, through the adapter's
@@ -514,6 +547,72 @@ export class SinglePublishAllService extends BaseService {
     };
   }
 
+  /**
+   * Judge every pending change this publish would promote, and refuse the
+   * whole publish if any of them may not be.
+   *
+   * Refusing all-or-nothing matches what the write does: `promotePendingChanges`
+   * applies every language's change and then deletes them all in one
+   * transaction, so publishing some and refusing others would leave a caller
+   * with no way to say what happened.
+   */
+  /**
+   * Judge every pending change this publish would promote, and refuse the
+   * whole publish if any of them may not be.
+   *
+   * All-or-nothing matches the write it guards: `promotePendingChanges`
+   * applies every language's change and deletes them all together, so
+   * publishing some and refusing others would leave a caller with no way to
+   * say what happened.
+   */
+  private async assertPendingChangesMayBePromoted(
+    plan: PublishPlan,
+    pending: ReadonlyArray<{ locale: string | null; snapshot: unknown }>,
+    options: PublishAllSingleLocalesOptions,
+    promoteGrants?: () => Promise<CallerGrants>
+  ): Promise<void> {
+    const { slug, singleMeta, existingDoc, companion, fieldConfigs } = plan;
+    const reader = this.queryService;
+    // Constructed without a reader only by a caller that built this service
+    // directly. The gate cannot run blind, and silently skipping it would make
+    // this the unjudged path again, so say so rather than pass.
+    if (!reader) {
+      throw NextlyError.internal({
+        logContext: {
+          cause: "publish-all-without-reader",
+          slug,
+          detail:
+            "Publishing every language needs the read service to judge each pending change.",
+        },
+      });
+    }
+
+    await assertDraftsMayBePromoted(pending, {
+      slug,
+      entryId: existingDoc.id,
+      fields: fieldConfigs,
+      user: options.user,
+      overrideAccess: options.overrideAccess,
+      authenticatedScope: options.authenticatedScope,
+      grants: promoteGrants,
+      toLogical: doc =>
+        reader.deserializeJsonFields(
+          { id: existingDoc.id, updatedAt: existingDoc.updatedAt, ...doc },
+          singleMeta.fields
+        ),
+      // The stored row, in the shape a snapshot holds, so an untouched upload
+      // or relationship is compared identifier with identifier rather than
+      // identifier with the document a read would have expanded it into.
+      liveStoredFor: () => Promise.resolve(existingDoc),
+      localizedFieldNames: new Set(
+        (companion?.localizedFields ?? []).map(f => f.name)
+      ),
+      // Every language goes live here, so none of them is falling back to
+      // another and each one's required values are enforced.
+      enforceLocalizedRequired: true,
+    });
+  }
+
   /**
    * Apply every language's pending change, then consume it.
    *
@@ -524,7 +623,9 @@ export class SinglePublishAllService extends BaseService {
   private async promotePendingChanges(
     tx: TransactionContext,
     plan: PublishPlan,
-    publishNow: Date
+    publishNow: Date,
+    options: PublishAllSingleLocalesOptions,
+    promoteGrants?: () => Promise<CallerGrants>
   ): Promise<void> {
     const { slug, singleMeta, existingDoc, companion } = plan;
     if (singleMeta.versions?.drafts?.enabled !== true) return;
@@ -538,6 +639,18 @@ export class SinglePublishAllService extends BaseService {
     const pending = await repo.findAllWorkingDrafts(ref);
     if (pending.length === 0) return;
 
+    // Judged here, on the drafts this transaction has read under its lock, and
+    // as ONE outcome: the loop below applies every language's snapshot to the
+    // same main row, so the shared values that survive are the last writer's.
+    // Judged one at a time, each draft can pass against its own shared values
+    // while the document that actually lands holds another language's.
+    await this.assertPendingChangesMayBePromoted(
+      plan,
+      pending,
+      options,
+      promoteGrants
+    );
+
     for (const draft of pending) {
       // The pending change carries no lifecycle of its own; the statuses this
       // publish writes are the ones that count.
diff --git a/packages/nextly/src/domains/widgets/__tests__/onboarding.integration.test.ts b/packages/nextly/src/domains/widgets/__tests__/onboarding.integration.test.ts
index 56461c4eb3..e4ab7c2183 100644
--- a/packages/nextly/src/domains/widgets/__tests__/onboarding.integration.test.ts
+++ b/packages/nextly/src/domains/widgets/__tests__/onboarding.integration.test.ts
@@ -245,19 +245,20 @@ describe("onboarding steps against a real instance", () => {
     expect(await onboardingIsIncomplete(conditionProbe(admin))).toBe(false);
   });
 
-  it("offers a builder the collection step and NOT the entry step", async () => {
-    // 🔴 Creating a collection is not being able to write a row in it.
-    // `seedPermissionsForCollection` assigns a new collection's CRUD
-    // permissions to `super_admin` alone, so this caller would not acquire
-    // `create-<new-slug>` -- and might not even be able to read what they
-    // made. Offering the entry step on the strength of the definition grant
-    // hands them a step they still cannot finish, which is the defect this
-    // predicate exists to prevent, moved one collection later.
+  it("offers a stamped key NEITHER step, because it could finish neither", async () => {
+    // 🔴 Holding the definition grant is not being able to finish the
+    // collection step. `seedPermissionsForCollection` assigns a new
+    // collection's CRUD permissions to `super_admin` alone, so this caller
+    // creates the collection, gains no `read-<slug>` for it, and finds the
+    // step still outstanding -- permanently. Offering it moved the defect one
+    // action later rather than fixing it.
     //
-    // The caller is a KEY stamped with the definition grant and no read grant,
-    // which is the shape that separates the two predicates: its readable set
-    // is empty while its collection answer is unambiguously yes. A session
-    // caller answers no to both and could not tell them apart.
+    // The entry step is withheld for the reason it always was: nothing
+    // readable is in reach, and the definition grant is not a substitute.
+    //
+    // A KEY is the discriminating caller: a session super admin holds the same
+    // grant AND would read what it creates, so it is still offered the step --
+    // the case below.
     await createTestNextly({
       collections: [
         defineCollection({
@@ -273,11 +274,74 @@ describe("onboarding steps against a real instance", () => {
 
     const steps = await stepsFor(builder);
 
-    expect(steps.collection).toBe(false);
+    expect(steps.collection).toBeUndefined();
     expect(steps.entry).toBeUndefined();
-    // Still incomplete: there IS something this reader can do, and the card
-    // stays until they have done it.
-    expect(await onboardingIsIncomplete(conditionProbe(builder))).toBe(true);
+    // Only the account remains, and it is already done -- so nothing is
+    // offered and the card stays off their dashboard entirely.
+    expect(Object.keys(steps)).toEqual(["account"]);
+    expect(await onboardingIsIncomplete(conditionProbe(builder))).toBe(false);
+  });
+
+  it("offers it to a KEY already stamped with a read grant to create into", async () => {
+    // 🔴 A key never GAINS a grant -- it is judged on the scope stamped into
+    // it when it was minted -- but a permission may be pre-seeded, and the
+    // read decision accepts a key's exact `read-<slug>` once that collection
+    // exists. So a key holding `read-reports` finishes this step by creating
+    // `reports`, and refusing every key hid a step that WAS finishable.
+    await createTestNextly({ collections: [] }).then(t => {
+      current = t;
+      return refreshCollectionSources();
+    });
+
+    const stampedToRead: ReadCaller = {
+      user: { id: "key-2", roles: [] },
+      authenticatedScope: {
+        actorType: "apiKey",
+        permissions: ["manage-settings", "read-reports"],
+      },
+    };
+
+    expect((await stepsFor(stampedToRead)).collection).toBe(false);
+  });
+
+  it("DOES offer it to a super admin, who would read what they create", async () => {
+    // The must-differ half, and without it "offered to nobody" satisfies the
+    // case above. The instance's FIRST user is its super admin, so this is the
+    // one caller for whom creating a collection also makes it readable -- and
+    // it is exactly the reader a fresh install has.
+    // NO collections, which is the only way the step is INCOMPLETE for a super
+    // admin: they can read every collection that exists, so any fixture with
+    // one completes the step and completion short-circuits the predicate --
+    // the test would pass without exercising it at all.
+    const t = await createTestNextly({ collections: [] });
+    current = t;
+    await refreshCollectionSources();
+
+    const users = (
+      t.nextly as unknown as {
+        users: {
+          create: (a: { data: Record<string, unknown> }) => Promise<{
+            item: { id: string };
+          }>;
+        };
+      }
+    ).users;
+    const owner = await users.create({
+      data: {
+        email: "owner@example.com",
+        password: "Password123!",
+        name: "Owner",
+        isActive: true,
+      },
+    });
+
+    const superAdmin: ReadCaller = {
+      user: { id: owner.item.id, roles: [] },
+    };
+    const steps = await stepsFor(superAdmin);
+
+    expect(steps.collection).toBe(false);
+    expect(await onboardingIsIncomplete(conditionProbe(superAdmin))).toBe(true);
   });
 
   it("offers nothing to a reader with no collection in reach and no way to make one", async () => {
diff --git a/packages/nextly/src/domains/widgets/__tests__/plugin-sources.test.ts b/packages/nextly/src/domains/widgets/__tests__/plugin-sources.test.ts
new file mode 100644
index 0000000000..919cd2dfa0
--- /dev/null
+++ b/packages/nextly/src/domains/widgets/__tests__/plugin-sources.test.ts
@@ -0,0 +1,168 @@
+/**
+ * A source a PLUGIN publishes: that it is reachable at all, and what the host
+ * hands its resolver.
+ *
+ * The chain this covers is the one that was broken by construction before
+ * Phase 5.1: `registerSource` has always accepted `kind: "plugin"`, so such a
+ * source was discoverable and passed query validation, and
+ * `resolveExecutableSource` then refused it as "not executable yet". A plugin
+ * could describe a source nobody could ever query.
+ */
+import { beforeEach, describe, expect, it, vi } from "vitest";
+
+const find = vi.fn();
+const count = vi.fn();
+
+// The collection path's collaborator, stubbed so the control below exercises a
+// real dispatch rather than falling over on a missing Direct API.
+vi.mock("../../../direct-api/nextly", () => ({
+  requireNextly: () => ({ find, count }),
+}));
+
+import { executeWidgetQuery } from "../execute";
+import { validateWidgetQuery } from "../query";
+import {
+  clearResolvers,
+  registerResolvedSource,
+  sourceResolver,
+} from "../resolved-sources";
+import { clearSources, registerSource } from "../sources";
+
+const caller = { user: { id: "user-1", roles: ["editor"] } };
+
+const revenueSource = {
+  id: "plugin:stripe/revenue",
+  label: "Revenue",
+  kind: "plugin" as const,
+  supports: ["count"] as const,
+  fields: [{ name: "total", type: "number" as const }],
+};
+
+beforeEach(() => {
+  vi.clearAllMocks();
+  find.mockResolvedValue({ items: [] });
+  count.mockResolvedValue({ total: 0 });
+  clearSources();
+  clearResolvers();
+});
+
+describe("a plugin's widget source", () => {
+  it("is answered by the resolver registered with it", async () => {
+    const resolve = vi
+      .fn()
+      .mockResolvedValue({ op: "count" as const, total: 42 });
+    registerResolvedSource(revenueSource, resolve);
+
+    const result = await executeWidgetQuery(
+      validateWidgetQuery({ source: revenueSource.id, op: "count" }),
+      caller
+    );
+
+    expect(result).toEqual({ op: "count", total: 42 });
+    expect(resolve).toHaveBeenCalledTimes(1);
+  });
+
+  it("hands the resolver the caller, unchanged", async () => {
+    // 🔴 The whole authorization story for a plugin source. The host does not
+    // filter for the resolver and cannot: it passes the caller through, and
+    // the plugin decides. A host that dropped the caller would leave every
+    // plugin unable to scope its own rows, with nothing to say so -- the
+    // resolver would simply answer the same rows to everyone.
+    const resolve = vi
+      .fn()
+      .mockResolvedValue({ op: "count" as const, total: 1 });
+    registerResolvedSource(revenueSource, resolve);
+
+    const query = validateWidgetQuery({
+      source: revenueSource.id,
+      op: "count",
+    });
+    await executeWidgetQuery(query, caller);
+
+    expect(resolve).toHaveBeenCalledWith(query, caller);
+  });
+
+  it("refuses a query naming a field the source never declared", async () => {
+    // The resolver is never reached. Validation runs against the plugin's OWN
+    // declared field list first, which is what makes the resolver signature a
+    // boundary: by the time it is called, no string in the query is one the
+    // caller invented.
+    const resolve = vi.fn();
+    registerResolvedSource(revenueSource, resolve);
+
+    expect(() =>
+      validateWidgetQuery({
+        source: revenueSource.id,
+        op: "count",
+        where: { secret: { equals: 1 } },
+      })
+    ).toThrow();
+    expect(resolve).not.toHaveBeenCalled();
+  });
+
+  it("refuses a plugin source published with no resolver", async () => {
+    // Reachable only by going around `registerResolvedSource` -- which is why
+    // that function takes both halves at once. Asserted anyway, because the
+    // generic `registerSource` door is public and a source registered through
+    // it is discoverable and passes validation.
+    registerSource(revenueSource);
+    expect(sourceResolver(revenueSource.id)).toBeUndefined();
+
+    await expect(
+      executeWidgetQuery(
+        validateWidgetQuery({ source: revenueSource.id, op: "count" }),
+        caller
+      )
+    ).rejects.toThrow();
+  });
+
+  it("refuses a resolver offered for a collection id", async () => {
+    // 🔴 The dangerous registration, and the reason the kind is checked at
+    // runtime rather than left to the type. A resolver under a `collection:`
+    // id answers a question the access-controlled Direct API is supposed to
+    // answer, diverting that collection's rows away from every rule that
+    // governs them -- and such a source is well-formed by every other check,
+    // since its kind and its namespace agree.
+    expect(() =>
+      registerResolvedSource(
+        {
+          id: "collection:posts",
+          label: "Posts",
+          kind: "collection",
+          supports: ["count"],
+          fields: [{ name: "title", type: "string" }],
+        } as never,
+        vi.fn()
+      )
+    ).toThrow(/may only be registered for a "system:" or "plugin:" source/);
+    // Neither store was written: a refusal that registered the source first
+    // would leave it discoverable and unanswerable.
+    expect(sourceResolver("collection:posts")).toBeUndefined();
+  });
+
+  it("still answers a system source from the same store", async () => {
+    // The control for sharing one store between the two kinds: a change that
+    // keyed resolvers by kind, or that gave plugins a store of their own,
+    // would break this while every plugin case above still passed.
+    const resolve = vi
+      .fn()
+      .mockResolvedValue({ op: "count" as const, total: 9 });
+    registerResolvedSource(
+      {
+        id: "system:releases",
+        label: "Releases",
+        kind: "system",
+        supports: ["count"],
+        fields: [{ name: "title", type: "string" }],
+      },
+      resolve
+    );
+
+    const result = await executeWidgetQuery(
+      validateWidgetQuery({ source: "system:releases", op: "count" }),
+      caller
+    );
+
+    expect(result).toEqual({ op: "count", total: 9 });
+  });
+});
diff --git a/packages/nextly/src/domains/widgets/__tests__/plugin-widget-source.integration.test.ts b/packages/nextly/src/domains/widgets/__tests__/plugin-widget-source.integration.test.ts
new file mode 100644
index 0000000000..16e23799f0
--- /dev/null
+++ b/packages/nextly/src/domains/widgets/__tests__/plugin-widget-source.integration.test.ts
@@ -0,0 +1,213 @@
+/**
+ * A plugin's widget source through a real boot.
+ *
+ * The unit tests around the fold and the executor each cover one seam with the
+ * other stubbed. What neither can show is the thing that actually broke: the
+ * resolver reaching DATA. A plugin's services are reachable only through its
+ * `PluginContext`, that context does not exist when the widget stores are
+ * reset, and a resolver holding `(query, caller)` alone could answer from
+ * constants and nothing else -- which every mocked test would have reported as
+ * working perfectly.
+ *
+ * So this boots an instance with a plugin that contributes a source, and reads
+ * rows through it. Nothing here stubs the context, the registry or the read.
+ *
+ * @module domains/widgets/__tests__/plugin-widget-source.integration.test
+ */
+
+process.env.NEXTLY_SECRET =
+  process.env.NEXTLY_SECRET ??
+  "test-secret-must-be-at-least-32-characters-long!!";
+
+import { afterEach, describe, expect, it } from "vitest";
+
+import { defineCollection, text } from "../../../config";
+import type { PluginContext } from "../../../plugins/plugin-context";
+import {
+  createTestNextly,
+  type TestNextly,
+} from "../../../plugins/test-nextly";
+import type { ReadCaller } from "../../../services/dashboard/readable-resources";
+import { executeWidgetQuery } from "../execute";
+import { validateWidgetQuery } from "../query";
+import { getSource } from "../sources";
+
+const NOTES = "notes";
+const SOURCE_ID = "plugin:acme/note-count";
+
+/** An admin caller, the reader a dashboard actually meets. */
+const admin: ReadCaller = { user: { id: "admin-1", roles: ["admin"] } };
+
+let current: TestNextly | undefined;
+/** What the resolver was handed, captured so the assertions can read it. */
+let handed: { ctx?: PluginContext; caller?: ReadCaller } = {};
+
+afterEach(async () => {
+  await current?.destroy();
+  current = undefined;
+  handed = {};
+});
+
+/**
+ * A plugin contributing one source whose resolver COUNTS ROWS.
+ *
+ * Counting is the point: it can only be done through `ctx.services`, so a
+ * resolver that never received a usable context cannot produce this number at
+ * all.
+ */
+function acmePlugin(): unknown {
+  return {
+    name: "@acme/notes",
+    version: "1.0.0",
+    nextly: ">=0.0.0",
+    contributes: {
+      widgetSources: [
+        {
+          source: {
+            id: SOURCE_ID,
+            label: "Notes",
+            kind: "plugin",
+            supports: ["count"],
+            fields: [{ name: "total", type: "number" }],
+          },
+          resolve: async (
+            _query: unknown,
+            caller: ReadCaller,
+            ctx: PluginContext
+          ) => {
+            handed = { ctx, caller };
+            const services = ctx.services as unknown as {
+              collections: {
+                count: (
+                  slug: string,
+                  args: unknown,
+                  opts: unknown
+                ) => Promise<{ total: number } | number>;
+              };
+            };
+            const counted = await services.collections.count(
+              NOTES,
+              {},
+              {
+                as: "user",
+                user: caller.user,
+                // The key's own stamped scope travels too. Without it a key
+                // would be judged on the roles of whoever minted it, which is
+                // the defect this whole read path is shaped to avoid.
+                authenticatedScope: caller.authenticatedScope,
+              }
+            );
+            const total = typeof counted === "number" ? counted : counted.total;
+            return { op: "count" as const, total };
+          },
+        },
+      ],
+    },
+  };
+}
+
+async function boot(plugins: unknown[]): Promise<TestNextly> {
+  const t = await createTestNextly({
+    collections: [
+      defineCollection({
+        slug: NOTES,
+        access: { read: () => true, create: () => true, update: () => true },
+        fields: [text({ name: "title" })],
+      }),
+    ],
+    plugins: plugins as never,
+  });
+  current = t;
+  return t;
+}
+
+async function write(t: TestNextly, title: string): Promise<void> {
+  const handler = t.getService("collectionsHandler") as unknown as {
+    createEntry: (
+      p: Record<string, unknown>,
+      data: Record<string, unknown>
+    ) => Promise<{ success: boolean }>;
+  };
+  const result = await handler.createEntry(
+    { collectionName: NOTES, overrideAccess: true },
+    { title }
+  );
+  // A failed insert would leave the count at zero, which is the state the
+  // assertion is trying to move away from -- so a broken fixture would report
+  // the resolver working perfectly.
+  expect(result.success).toBe(true);
+}
+
+describe("a plugin's widget source, booted", () => {
+  it("is registered and answers a query with rows it read itself", async () => {
+    const t = await boot([acmePlugin()]);
+    await write(t, "first");
+    await write(t, "second");
+
+    // Registered by the boot, not by this test.
+    expect(getSource(SOURCE_ID)).toBeDefined();
+
+    const result = await executeWidgetQuery(
+      validateWidgetQuery({ source: SOURCE_ID, op: "count" }),
+      admin
+    );
+
+    // 🔴 The number is the evidence. It could not have been produced without a
+    // context that reaches the collection service, so this fails outright on
+    // the two-argument resolver the contract shipped with.
+    expect(result).toEqual({ op: "count", total: 2 });
+  });
+
+  it("hands the resolver its OWN plugin's context, and the caller unchanged", async () => {
+    const t = await boot([acmePlugin()]);
+    await write(t, "only");
+
+    await executeWidgetQuery(
+      validateWidgetQuery({ source: SOURCE_ID, op: "count" }),
+      admin
+    );
+
+    expect(handed.caller).toBe(admin);
+    // `ctx.self` is what makes a context this plugin's OWN rather than some
+    // shared one: bound wrongly, every plugin would read the first plugin's
+    // entities while believing they were its own.
+    expect((handed.ctx as unknown as { self?: unknown }).self).toBeDefined();
+    expect(handed.ctx?.services).toBeDefined();
+  });
+
+  it("publishes nothing for a DISABLED plugin", async () => {
+    // The boot skips a disabled plugin's context entirely, so its resolver
+    // would have nothing to be bound to. Asserted through the source store
+    // rather than the fold, because this is the seam where the two agree.
+    await boot([{ ...(acmePlugin() as object), enabled: false }]);
+
+    expect(getSource(SOURCE_ID)).toBeUndefined();
+  });
+
+  it("refuses a boot whose plugin claims a reserved namespace", async () => {
+    // A `collection:` id would put a resolver where the access-controlled
+    // Direct API is supposed to answer. The refusal is the BOOT's, so the
+    // instance never comes up -- which is the outcome that gets noticed.
+    const shadow = {
+      name: "@acme/shadow",
+      version: "1.0.0",
+      nextly: ">=0.0.0",
+      contributes: {
+        widgetSources: [
+          {
+            source: {
+              id: `collection:${NOTES}`,
+              label: "Not notes",
+              kind: "plugin",
+              supports: ["count"],
+              fields: [{ name: "total", type: "number" }],
+            },
+            resolve: () => Promise.resolve({ op: "count" as const, total: 0 }),
+          },
+        ],
+      },
+    };
+
+    await expect(boot([shadow])).rejects.toThrow(/reserved/);
+  });
+});
diff --git a/packages/nextly/src/domains/widgets/caller-read-options.ts b/packages/nextly/src/domains/widgets/caller-read-options.ts
new file mode 100644
index 0000000000..744f5e6112
--- /dev/null
+++ b/packages/nextly/src/domains/widgets/caller-read-options.ts
@@ -0,0 +1,58 @@
+/**
+ * Turning the caller a resolver is handed into the options a read takes.
+ *
+ * 🔴 The two shapes do not meet, and a plugin cannot bridge them. A resolver
+ * receives `ReadCaller`, whose `user` is a `UserContext` -- a plain string id
+ * and an OPTIONAL email. `ServiceOpts.user`, which the managed collection and
+ * single services take, is an `AuthUser`: a BRANDED id and a required email.
+ * So the caller-scoped read the contract tells a plugin to make did not
+ * type-check, and the only way through was an assertion in every plugin.
+ *
+ * One assertion in the host is better than one in each plugin, and this is the
+ * place that can justify it: the `ReadCaller` was built by the host from a
+ * request it authenticated, so its id IS an authenticated user's id. A plugin
+ * has no standing to make that claim about a value it was handed.
+ *
+ * It also carries the half an author would most easily forget.
+ * `authenticatedScope` is what makes an API key judged on the scope stamped
+ * into it rather than on the roles of whoever minted it -- omit it and a
+ * read-only key inherits its owner's reach. Building the options here means it
+ * cannot be left out by accident.
+ *
+ * @module domains/widgets/caller-read-options
+ */
+
+import type { ServiceOpts } from "../../plugins/service-opts";
+import type { ReadCaller } from "../../services/dashboard/readable-resources";
+import type { AuthUser } from "../../types/auth";
+
+/**
+ * The `ServiceOpts` a resolver should pass to read as its caller.
+ *
+ * `as: "user"` rather than `"system"`, always: a widget answers what THIS
+ * reader may see, and a resolver that read as the system would answer every
+ * reader with the whole install.
+ *
+ * @example
+ * ```ts
+ * const rows = await ctx.services.collections.count(
+ *   "posts",
+ *   { where: { status: { equals: "draft" } } },
+ *   callerReadOptions(caller)
+ * );
+ * ```
+ */
+export function callerReadOptions(caller: ReadCaller): ServiceOpts {
+  return {
+    as: "user",
+    // The one assertion, and the reason it is sound is above: this identity
+    // came from a request the host authenticated. `email` is absent from a
+    // `UserContext` and unused by the access decision, which reads the id and
+    // the roles -- so widening it here would add a field no caller supplies
+    // and nothing consults.
+    user: caller.user as unknown as AuthUser,
+    ...(caller.authenticatedScope
+      ? { authenticatedScope: caller.authenticatedScope }
+      : {}),
+  };
+}
diff --git a/packages/nextly/src/domains/widgets/condition-probe.ts b/packages/nextly/src/domains/widgets/condition-probe.ts
index 994f10e515..d9c18055e1 100644
--- a/packages/nextly/src/domains/widgets/condition-probe.ts
+++ b/packages/nextly/src/domains/widgets/condition-probe.ts
@@ -33,6 +33,7 @@ import {
   COLLECTION_DEFINITION_ACTION,
   COLLECTION_DEFINITION_RESOURCE,
 } from "../../auth/collection-definition-policy";
+import { wouldReadOwnNewCollection } from "../../auth/new-entity-access-policy";
 import type { ReadCaller } from "../../services/dashboard/readable-resources";
 
 import {
@@ -63,10 +64,11 @@ export interface ConditionProbe {
   /**
    * Whether this reader could create a COLLECTION, resolved at most once.
    *
-   * The grant is `auth/collection-definition-policy`'s, which is what the
-   * schema route and the dispatcher's definition branch both enforce, asked
-   * through the same door they ask through -- so this cannot drift from the
-   * refusal a reader would actually meet.
+   * Two halves: may they DEFINE one (the grant
+   * `auth/collection-definition-policy` names, which the schema route and the
+   * dispatcher both enforce), and would they be able to READ the result. The
+   * second is what makes the step finishable -- a new collection's permissions
+   * are seeded to `super_admin` alone.
    */
   mayCreateCollection(): Promise<boolean>;
 }
@@ -84,14 +86,35 @@ export function conditionProbe(caller: ReadCaller): ConditionProbe {
   };
 
   const mayCreateCollection = (): Promise<boolean> => {
-    // Through the same decision the entry predicate uses, and for the same
-    // reason: a key's stamped grant alone is not what a route enforces.
-    createCollection ??= callerMayPerform(
-      caller.authenticatedScope,
-      COLLECTION_DEFINITION_ACTION,
-      COLLECTION_DEFINITION_RESOURCE,
-      caller.user
-    );
+    // 🔴 May create AND would be able to READ what they created. Both halves,
+    // because the step completes when this reader can read a collection, and
+    // `seedPermissionsForCollection` assigns a new collection's CRUD
+    // permissions to `super_admin` alone. A caller holding the definition
+    // grant and nothing else creates the collection, gains no `read-<slug>`
+    // for it, and finds the step still outstanding -- permanently, which is
+    // the defect this predicate exists to prevent, moved one action later.
+    //
+    // The readability half is DERIVED from the seeding policy rather than
+    // restated here. `wouldReadOwnNewCollection` lives beside the declaration
+    // the seeder assigns by, so if creation ever begins granting the creator --
+    // or the assignment moves to another role -- this follows instead of
+    // silently disagreeing. Asserted in one place, the two could only drift in
+    // ways nothing reports: a step hidden after it became finishable, or
+    // offered after it stopped being.
+    createCollection ??= (async () => {
+      const mayDefine = await callerMayPerform(
+        caller.authenticatedScope,
+        COLLECTION_DEFINITION_ACTION,
+        COLLECTION_DEFINITION_RESOURCE,
+        caller.user
+      );
+      if (!mayDefine) return false;
+      return wouldReadOwnNewCollection({
+        userId: caller.user.id,
+        isApiKey: caller.authenticatedScope?.actorType === "apiKey",
+        permissions: caller.authenticatedScope?.permissions ?? [],
+      });
+    })();
     return createCollection;
   };
 
diff --git a/packages/nextly/src/domains/widgets/executable-source.ts b/packages/nextly/src/domains/widgets/executable-source.ts
index a92fbb89a9..c34546b938 100644
--- a/packages/nextly/src/domains/widgets/executable-source.ts
+++ b/packages/nextly/src/domains/widgets/executable-source.ts
@@ -21,13 +21,13 @@
  * @module domains/widgets/executable-source
  */
 
+import { sourceResolver, type SourceResolver } from "./resolved-sources";
 import {
   failUnavailableSourceOrOp,
   getSource,
   sourceTarget,
   type WidgetSource,
 } from "./sources";
-import { systemResolver, type SystemSourceResolver } from "./system-sources";
 
 /**
  * A resolved source together with HOW it is answered.
@@ -42,7 +42,8 @@ import { systemResolver, type SystemSourceResolver } from "./system-sources";
  * branch makes the disagreement unrepresentable rather than merely unlikely.
  */
 export type ExecutableSource =
-  | { kind: "system"; source: WidgetSource; resolve: SystemSourceResolver }
+  | { kind: "system"; source: WidgetSource; resolve: SourceResolver }
+  | { kind: "plugin"; source: WidgetSource; resolve: SourceResolver }
   | { kind: "collection"; source: WidgetSource }
   | { kind: "single"; source: WidgetSource };
 
@@ -57,6 +58,12 @@ const READS_AN_ENTITY: Record<ExecutableSource["kind"], boolean> = {
   collection: true,
   single: true,
   system: false,
+  // A plugin source's rows are not an entity the permission table names, for
+  // the same reason a system source's are not: whatever they are, they are the
+  // plugin's own, and the `read-<slug>` gate would be asking about a collection
+  // that does not exist. Its `requiredPermission` stays advisory, as every
+  // source's is.
+  plugin: false,
 };
 
 /**
@@ -95,28 +102,42 @@ export function resolveExecutableSource(sourceId: string): ExecutableSource {
   if (!source) {
     failUnavailableSourceOrOp(`unknown source "${sourceId}" at execution`);
   }
-  // A SYSTEM source is executable exactly when something registered a resolver
-  // for it. The two halves are published together, so a source with no
-  // resolver means a registration that never completed rather than a caller
-  // asking for something reasonable -- and it answers like every other dead
-  // end, because saying which is which would confirm the source exists.
-  if (source.kind === "system") {
-    const resolve = systemResolver(source.id);
+  // A RESOLVER-ANSWERED source -- core's own or a plugin's -- is executable
+  // exactly when something registered a resolver for it. The two halves are
+  // published together, so a source with no resolver means a registration that
+  // never completed rather than a caller asking for something reasonable --
+  // and it answers like every other dead end, because saying which is which
+  // would confirm the source exists. One branch for both kinds, because the
+  // question ("what answers this id") and the store are one.
+  if (source.kind === "system" || source.kind === "plugin") {
+    const resolve = sourceResolver(source.id);
     if (!resolve) {
       failUnavailableSourceOrOp(
-        `system source "${sourceId}" has no registered resolver`
+        `${source.kind} source "${sourceId}" has no registered resolver`
       );
     }
-    return { kind: "system", source, resolve };
+    return { kind: source.kind, source, resolve };
   }
   // A single is executable the way a collection is: its one document is read
   // through the Direct API with the caller, and the executor decides what
   // that read looks like.
   if (source.kind === "single") return { kind: "single", source };
-  if (source.kind !== "collection") {
-    failUnavailableSourceOrOp(
-      `source "${sourceId}" has kind "${source.kind}", which is not executable yet; only collections, singles and system sources are`
-    );
-  }
-  return { kind: "collection", source };
+  if (source.kind === "collection") return { kind: "collection", source };
+
+  // 🔴 Unreachable through the type, and kept anyway. Every member of
+  // `WIDGET_SOURCE_KINDS` is now executable, so the compiler narrows this to
+  // `never` -- which is a statement about TypeScript callers, not about the
+  // values that arrive. A source built by a plugin compiled separately, by
+  // JavaScript, or through a cast can still carry a kind this function has
+  // never heard of, and the alternative to refusing it is falling through to
+  // the collection arm with an id that names no collection.
+  //
+  // It costs nothing: the branch reads a value already in hand and never runs.
+  // Widened through a `string` local because a template literal cannot
+  // interpolate `never` -- the narrowing is what makes the cheap guard look
+  // impossible, so the widening says out loud that it is deliberate.
+  const unexpected: string = source.kind;
+  failUnavailableSourceOrOp(
+    `source "${sourceId}" has kind "${unexpected}", which is not executable; only collections, singles, system and plugin sources are`
+  );
 }
diff --git a/packages/nextly/src/domains/widgets/execute.ts b/packages/nextly/src/domains/widgets/execute.ts
index 4c6e3eebc3..51fd887436 100644
--- a/packages/nextly/src/domains/widgets/execute.ts
+++ b/packages/nextly/src/domains/widgets/execute.ts
@@ -386,7 +386,16 @@ export async function executeWidgetQuery(
   // `ReleasesService.find` asks its own `authorize` before it reads -- so a
   // filter applied here would be a second implementation of a rule this module
   // cannot see, agreeing on the day it is written and drifting afterwards.
-  if (executable.kind === "system") {
+  if (executable.kind === "system" || executable.kind === "plugin") {
+    // One arm for both, because the contract is one. A plugin's resolver is
+    // handed exactly what core's is and is trusted exactly as far.
+    //
+    // 🔴 The query reaching it is VALIDATED, not SANITISED. Its field names,
+    // operators and operand shapes were checked against the source's own
+    // declaration; the operand VALUES were not, and a caller who may place a
+    // widget chooses them. A resolver that uses one as a destination is
+    // exploitable, which is why `resolved-sources` states that as the
+    // contract's rule rather than implying the host removed the possibility.
     return executable.resolve(query, caller);
   }
 
diff --git a/packages/nextly/src/domains/widgets/index.ts b/packages/nextly/src/domains/widgets/index.ts
index 5e91e953c2..cb99efccfb 100644
--- a/packages/nextly/src/domains/widgets/index.ts
+++ b/packages/nextly/src/domains/widgets/index.ts
@@ -104,3 +104,34 @@ export {
   TIMESERIES_INTERVALS,
   type TimeseriesInterval,
 } from "../collections/query/timeseries-interval";
+
+/**
+ * The contract a plugin's widget source is written against.
+ *
+ * Published because `contributes.widgetSources` names it, and every contract a
+ * published shape names travels with it. Inference covers the common case --
+ * an author writing the resolver inline inside `definePlugin` gets `query` and
+ * `caller` typed from the contextual type, and needs none of these names. What
+ * inference cannot do is let them declare the resolver as a standalone
+ * function, or hand it to a helper, which is exactly how a plugin with more
+ * than one source ends up written.
+ *
+ * 🔴 TWO resolver types, and a plugin author wants the second.
+ * `WidgetSourceResolver` is the two-argument shape core's own system sources
+ * use. `PluginSourceResolver` is what `contributes.widgetSources` takes: the
+ * same two plus the plugin's own `PluginContext`, which is how a resolver
+ * reaches any data. Typing a contributed resolver as the former rejects the
+ * `ctx` parameter it needs, so both are published and the names say which is
+ * which.
+ *
+ * `ReadCaller` travels with them for the same reason: it is one of the
+ * arguments, so without it the parameter has no name to annotate.
+ */
+export type { SourceResolver as WidgetSourceResolver } from "./resolved-sources";
+export type { PluginSourceResolver } from "../../plugins/widgets/collect-widget-sources";
+export type { ReadCaller } from "../../services/dashboard/readable-resources";
+export { callerReadOptions } from "./caller-read-options";
+export type {
+  PluginWidgetSource,
+  CollectedWidgetSource,
+} from "../../plugins/widgets/collect-widget-sources";
diff --git a/packages/nextly/src/domains/widgets/resolved-sources.ts b/packages/nextly/src/domains/widgets/resolved-sources.ts
new file mode 100644
index 0000000000..0758186b28
--- /dev/null
+++ b/packages/nextly/src/domains/widgets/resolved-sources.ts
@@ -0,0 +1,169 @@
+/**
+ * Sources answered by a FUNCTION, and the one store that holds those functions.
+ *
+ * Two kinds are answered this way and they share everything except who may
+ * publish them. A `system:` source is core's own — a release is not a row in a
+ * collection table, so the releases service answers it. A `plugin:` source is a
+ * third party's, contributed through `contributes.widgetSources`. Neither is a
+ * table the Direct API can compile a query against, which is the whole reason a
+ * resolver exists.
+ *
+ * 🔴 ONE store, keyed by id, because a second one is a second answer to "what
+ * answers this id". The invariant that matters is not which kind a resolver
+ * belongs to but which kinds may carry a resolver AT ALL: a resolver stored
+ * under a `collection:` or `single:` id would answer a question the
+ * access-controlled Direct API is supposed to answer, diverting that entity's
+ * rows away from it. {@link RESOLVER_ANSWERED_KINDS} states that rule once, and
+ * both doors below go through it.
+ *
+ * ## What a resolver is handed, and what it is not
+ *
+ * `(query, caller)` and nothing else. No request, no headers, no fetch-capable
+ * context — a plugin's resolver reaches whatever its own closure captured at
+ * registration, exactly as `releases-widget-source.ts` does today.
+ *
+ * 🔴 What that signature does and does NOT bound, stated exactly, because the
+ * difference is security-relevant and the generous reading is wrong.
+ *
+ * BOUNDED: the SHAPE of the question. `validateReadWidgetQuery` refuses a field
+ * name the source never declared, an operator outside the vocabulary, and an
+ * operand that is a plain object. So a resolver is never asked about a column
+ * its own source did not publish, and never handed a structure where a scalar
+ * belongs.
+ *
+ * NOT BOUNDED: the operand VALUES. `where: { total: { equals: "http://..." } }`
+ * validates cleanly and arrives at the resolver verbatim, because nothing
+ * constrains what a legal string contains. A caller who may place a widget can
+ * therefore choose those bytes.
+ *
+ * So a resolver MUST NOT use any value out of `query` as an outbound URL, a
+ * filesystem path, a table or column name, or anything else that names a
+ * destination. Treat every operand as caller-controlled input and validate it
+ * against a closed set before it decides where a request goes. The contract
+ * hands over a question, not a trusted one.
+ *
+ * Why that is a rule rather than a validator here: Directus mitigated an
+ * import-endpoint SSRF with an IP denylist (CVE-2022-23080) and the denylist
+ * was itself bypassed by DNS rebinding (CVE-2023-26492). A host-side filter
+ * over a value the plugin then uses as a destination is one round of research
+ * from being no filter at all, so the host declines to imply one.
+ *
+ * ## What this contract does NOT promise
+ *
+ * That a resolver consults `caller`. It cannot: the host hands over the caller
+ * and the resolver decides what to do with it. Pairing the source and the
+ * resolver in one call makes "registered but unanswerable" unrepresentable, and
+ * the signature forecloses SSRF — neither proves a third party authorized
+ * anything. WordPress has required a `permission_callback` on every REST route
+ * since 5.5 and plugins still ship `__return_true` for it (CVE-2026-4019,
+ * CVE-2026-4020); Payload's Local API disables access control by default. A
+ * required field is not an enforced check.
+ *
+ * This is the same trust boundary a plugin's `init()`, hooks and services
+ * already cross — a Nextly plugin is an ordinary npm dependency, as trusted as
+ * the code that imports it — not a new, narrower one. The documentation says so
+ * rather than implying a guarantee the shape cannot make.
+ *
+ * @module domains/widgets/resolved-sources
+ */
+
+import { NextlyError } from "../../errors/nextly-error";
+import type { ReadCaller } from "../../services/dashboard/readable-resources";
+
+import type { WidgetQuery } from "./query";
+import type { WidgetResult } from "./result";
+import { registerSource, type WidgetSource } from "./sources";
+
+/**
+ * Answers one source's query, for one caller.
+ *
+ * Returns the same `WidgetResult` a collection query does, so the archetypes
+ * that draw a count or a list need no branch for where the rows came from.
+ */
+export type SourceResolver = (
+  query: WidgetQuery,
+  caller: ReadCaller
+) => Promise<WidgetResult>;
+
+/**
+ * The source kinds a resolver may be registered for.
+ *
+ * An allowlist, checked at runtime rather than left to the type. `registerSource`
+ * validates that a source's kind agrees with its namespace and nothing more, so
+ * a well-formed `collection:` source satisfies it completely — and the type
+ * states this rule only for a TypeScript caller, not for a plugin compiled
+ * separately, for JavaScript, or for a cast.
+ */
+const RESOLVER_ANSWERED_KINDS: ReadonlySet<string> = new Set([
+  "system",
+  "plugin",
+]);
+
+/** A source this registry may answer. */
+export type ResolvedWidgetSource = WidgetSource & { kind: "system" | "plugin" };
+
+/**
+ * The resolvers, pinned where every other boot-time widget store is.
+ *
+ * On `globalThis` so they survive the module re-evaluation Next.js and
+ * Turbopack perform, matching the source store beside them.
+ */
+const globalForResolvers = globalThis as unknown as {
+  __nextly_systemResolvers?: Map<string, SourceResolver>;
+};
+
+function resolvers(): Map<string, SourceResolver> {
+  globalForResolvers.__nextly_systemResolvers ??= new Map();
+  return globalForResolvers.__nextly_systemResolvers;
+}
+
+/**
+ * Publish a resolver-answered source and the function that answers it, together.
+ *
+ * 🔴 One call, because the two halves are useless apart and dangerous apart in
+ * one direction: a source registered without a resolver is discoverable, passes
+ * validation, and fails only when a reader puts the card on their dashboard.
+ * Registering them separately makes that state reachable through ordinary
+ * refactoring; this signature makes it unrepresentable.
+ *
+ * Refused BEFORE `registerSource`, so a rejected registration writes neither
+ * store. Checking afterwards would leave the source published and unanswerable,
+ * which is the exact state this function's signature exists to prevent.
+ *
+ * The source then goes through `registerSource`, the same door a collection
+ * source uses, so its shape is validated by the same rules and a duplicate id
+ * is refused the same way.
+ */
+export function registerResolvedSource(
+  source: ResolvedWidgetSource,
+  resolve: SourceResolver
+): void {
+  if (!RESOLVER_ANSWERED_KINDS.has(source?.kind)) {
+    // `invalidInput`, matching `sources.ts`: a source registered by core or by
+    // a plugin is developer input, not a reader's, so the message is safe to
+    // surface verbatim and says what to change.
+    throw NextlyError.invalidInput({
+      message:
+        `Invalid widget source: ${String(source?.id)}: a resolver may only be ` +
+        `registered for a "system:" or "plugin:" source, not kind ` +
+        `"${String(source?.kind)}"`,
+    });
+  }
+  registerSource(source);
+  resolvers().set(source.id, resolve);
+}
+
+/** The resolver for `sourceId`, or `undefined` when nothing answers it. */
+export function sourceResolver(sourceId: string): SourceResolver | undefined {
+  return resolvers().get(sourceId);
+}
+
+/**
+ * Forget every registered resolver.
+ *
+ * Paired with `clearSources`: clearing one and not the other leaves a resolver
+ * addressable under an id no source claims, or a source nothing can answer.
+ */
+export function clearResolvers(): void {
+  resolvers().clear();
+}
diff --git a/packages/nextly/src/domains/widgets/system-sources.ts b/packages/nextly/src/domains/widgets/system-sources.ts
index e356550121..0e16feff12 100644
--- a/packages/nextly/src/domains/widgets/system-sources.ts
+++ b/packages/nextly/src/domains/widgets/system-sources.ts
@@ -1,5 +1,5 @@
 /**
- * A source whose rows are not a collection's, and the function that answers it.
+ * CORE's own resolver-answered sources: the `system:` door.
  *
  * ## Why a resolver rather than a query compiler
  *
@@ -24,108 +24,85 @@
  * offer a card, and would make a domain unable to ship a source without editing
  * a file it does not own. The collection sources already work this way.
  *
+ * ## Why this is a door rather than a store
+ *
+ * The store, the resolver signature and the rule about which kinds may carry a
+ * resolver all live in `resolved-sources.ts`, because `plugin:` sources are
+ * answered exactly the same way and two stores would be two answers to "what
+ * answers this id". What survives here is the one thing that is genuinely
+ * system-specific: a caller reaching for THIS function is publishing core's own
+ * source, and a `plugin:` id arriving at it is a mistake worth refusing by name
+ * rather than quietly accepting through the generic door.
+ *
  * @module domains/widgets/system-sources
  */
 
 import { NextlyError } from "../../errors/nextly-error";
-import type { ReadCaller } from "../../services/dashboard/readable-resources";
 
-import type { WidgetQuery } from "./query";
-import type { WidgetResult } from "./result";
-import { registerSource, type WidgetSource } from "./sources";
+import {
+  clearResolvers,
+  registerResolvedSource,
+  sourceResolver,
+  type SourceResolver,
+} from "./resolved-sources";
+import type { WidgetSource } from "./sources";
 
 /**
  * Answers one system source's query, for one caller.
  *
- * Returns the same `WidgetResult` a collection query does, so the archetypes
- * that draw a count or a list need no branch for where the rows came from.
+ * An alias rather than a second declaration: a plugin's resolver and core's are
+ * handed the same two values and return the same result, and spelling that
+ * twice is how the two would come to differ.
  */
-export type SystemSourceResolver = (
-  query: WidgetQuery,
-  caller: ReadCaller
-) => Promise<WidgetResult>;
+export type SystemSourceResolver = SourceResolver;
 
 /**
- * The resolvers, pinned where every other boot-time widget store is.
+ * A source this door may publish: one whose kind is literally `"system"`.
  *
- * On `globalThis` so they survive the module re-evaluation Next.js and
- * Turbopack perform, matching the source store beside them.
- */
-const globalForResolvers = globalThis as unknown as {
-  __nextly_systemResolvers?: Map<string, SystemSourceResolver>;
-};
-
-function resolvers(): Map<string, SystemSourceResolver> {
-  globalForResolvers.__nextly_systemResolvers ??= new Map();
-  return globalForResolvers.__nextly_systemResolvers;
-}
-
-/**
- * A source this registry may answer: one whose kind is literally `"system"`.
- *
- * Narrower than `WidgetSource` on purpose. The resolver store is keyed by id
- * alone, so a resolver accepted under any other kind would sit in the map
- * beside sources answered by an entirely different path.
+ * Narrower than `WidgetSource` on purpose, and narrower than the generic
+ * registrar accepts: the resolver store is keyed by id alone, so core
+ * publishing under a `plugin:` id would put its source where a plugin fold is
+ * entitled to replace it.
  */
 export type SystemWidgetSource = WidgetSource & { kind: "system" };
 
 /**
  * Publish a system source and the function that answers it, together.
  *
- * 🔴 One call, because the two halves are useless apart and dangerous apart in
- * one direction: a source registered without a resolver is discoverable, passes
- * validation, and fails only when a reader puts the card on their dashboard.
- * Registering them separately makes that state reachable through ordinary
- * refactoring; this signature makes it unrepresentable.
- *
  * 🔴 And only a SYSTEM source, checked at runtime rather than left to the type.
- * `registerSource` validates that a source's kind agrees with its namespace and
- * nothing more, so a well-formed `collection:` source satisfies it completely --
- * and a resolver stored under a collection id would be an answer to a question
- * the access-controlled Direct API is supposed to answer. The type states the
- * rule for a TypeScript caller; this states it for a plugin author compiling
- * separately, for JavaScript, and for a cast.
- *
- * Refused BEFORE `registerSource`, so a rejected registration writes neither
- * store. Checking afterwards would leave the source published and unanswerable,
- * which is the exact state this function's signature exists to prevent.
- *
- * The source then goes through `registerSource`, the same door a collection
- * source uses, so its shape is validated by the same rules and a duplicate id
- * is refused the same way.
+ * The type states the rule for a TypeScript caller; this states it for
+ * JavaScript and for a cast. Refused BEFORE the generic registrar, so a
+ * rejected registration writes neither store.
  */
 export function registerSystemSource(
   source: SystemWidgetSource,
   resolve: SystemSourceResolver
 ): void {
   if (source?.kind !== "system") {
-    // `invalidInput`, matching `sources.ts`: a source registered by core or by
-    // a plugin is developer input, not a reader's, so the message is safe to
-    // surface verbatim and says what to change.
     throw NextlyError.invalidInput({
       message:
         `Invalid widget source: ${String(source?.id)}: a resolver may only be ` +
         `registered for a "system:" source, not kind "${String(source?.kind)}"`,
     });
   }
-  registerSource(source);
-  resolvers().set(source.id, resolve);
+  registerResolvedSource(source, resolve);
 }
 
 /** The resolver for `sourceId`, or `undefined` when nothing answers it. */
 export function systemResolver(
   sourceId: string
 ): SystemSourceResolver | undefined {
-  return resolvers().get(sourceId);
+  return sourceResolver(sourceId);
 }
 
 /**
  * Forget every registered resolver.
  *
- * For tests, which register sources into a store that outlives a single file.
- * Paired with `clearSources`: clearing one and not the other leaves a resolver
- * addressable under an id no source claims, or a source nothing can answer.
+ * For tests, which register sources into a store that outlives a single file,
+ * and for the boot reset. Clears EVERY resolver rather than the system ones
+ * alone: they share a store, and a reset that took one kind would leave the
+ * other answering for a boot that is over.
  */
 export function clearSystemResolvers(): void {
-  resolvers().clear();
+  clearResolvers();
 }
diff --git a/packages/nextly/src/index.ts b/packages/nextly/src/index.ts
index 51f0fa843f..f59a4c708b 100644
--- a/packages/nextly/src/index.ts
+++ b/packages/nextly/src/index.ts
@@ -524,6 +524,9 @@ export {
 // inferred but never annotated: `WidgetDefinition.defaultHeight` is a
 // `WidgetHeight`, and `WidgetSource` is built out of `WidgetSourceField`,
 // `WidgetSourceKind` and `WidgetOp`.
+// The last three are the data SOURCE contract that `contributes.widgetSources`
+// names: inference covers a resolver written inline, and these are what let an
+// author declare one as a named function instead.
 export {
   WIDGET_SIZES,
   WIDGET_CHROME,
@@ -568,6 +571,11 @@ export {
   type TimeseriesInterval,
   type WidgetLifecycle,
   type WidgetCondition,
+  callerReadOptions,
+  type WidgetSourceResolver,
+  type PluginSourceResolver,
+  type PluginWidgetSource,
+  type ReadCaller,
 } from "./domains/widgets";
 
 // Value exports for the email provider contract. A plugin calls
@@ -672,7 +680,13 @@ export type {
 // `ctx.services.collections.createMany`. Rich-query options (`QueryOptions`
 // with where/sort/depth/select) + `PaginatedResult` are exported with the other
 // shared service types above.
-export type { BatchOperationResult } from "./domains/collections/services/collection-types";
+export type {
+  BatchOperationResult,
+  // The input half of the batch update, beside the result half: a plugin
+  // typing an array it builds before calling `updateMany` has to be able to
+  // name the contract rather than restate its shape.
+  BulkUpdateEntry,
+} from "./domains/collections/services/collection-types";
 
 // Whether a collection stores a working draft beside its published row.
 //
diff --git a/packages/nextly/src/plugins/__tests__/service-d56.integration.test.ts b/packages/nextly/src/plugins/__tests__/service-d56.integration.test.ts
index f2060a2516..f2a808dc4a 100644
--- a/packages/nextly/src/plugins/__tests__/service-d56.integration.test.ts
+++ b/packages/nextly/src/plugins/__tests__/service-d56.integration.test.ts
@@ -2,14 +2,13 @@
  * D56 end-to-end — the new `ctx.services.collections` surface (the
  * ServiceOpts-wrapped facade) against a live in-memory SQLite boot.
  *
- * Harness scope (mirrors the P3-D35/P4 posture): the in-memory `createTestNextly`
- * boot wires the high-level `nextly.create` path but NOT the lower entry-service
- * hook seam that the facade's doc-read (`listEntries`) and bulk-create
- * (`createMany`) paths call — both surface `hookRegistry.executeBeforeOperation
- * is not a function` / an INTERNAL_ERROR there. That is a pre-existing harness
- * limitation, not a P7a regression (a plain `listEntries` fails identically).
- * So those two are covered by the focused facade/wrapper UNIT tests
- * (`collection-service-d56.test.ts`, `service-opts-wrapper.test.ts`).
+ * The harness limitation this file was written around is gone: the in-memory
+ * `createTestNextly` boot reaches the entry-service hook seam, so `createMany`
+ * and the bulk update run end to end through the wrapper. Measured in
+ * `service-update-many.integration.test.ts`, which seeds with `createMany` and
+ * patches the result with `updateMany`. The focused facade and wrapper unit
+ * tests (`collection-service-d56.test.ts`, `service-opts-wrapper.test.ts`)
+ * still cover the translation itself.
  *
  * What this file proves end-to-end through the wrapper:
  *  - `count` with a `where` filter actually reaches the query layer (the filter
diff --git a/packages/nextly/src/plugins/__tests__/service-update-many.integration.test.ts b/packages/nextly/src/plugins/__tests__/service-update-many.integration.test.ts
new file mode 100644
index 0000000000..d55de0affc
--- /dev/null
+++ b/packages/nextly/src/plugins/__tests__/service-update-many.integration.test.ts
@@ -0,0 +1,190 @@
+/**
+ * `ctx.services.collections.updateMany` through a live boot.
+ *
+ * The plugin facade ended at `createMany`: a plugin could write many rows and
+ * then had no way to change them in one call, elevated or not, so the only
+ * batch update available to plugin code was a loop of `updateEntry` calls,
+ * each with its own transaction.
+ *
+ * What this pins: one call carries a DIFFERENT patch per row; `{as:'system'}`
+ * reaches rows an unprivileged caller cannot; `{as:'user'}` is still judged;
+ * a failed row does not stop the rest and is reported by the index of the
+ * entry the caller passed; and a locale is refused by name rather than
+ * dropped.
+ */
+import { afterEach, describe, expect, it } from "vitest";
+
+import { defineCollection, text } from "../../config";
+import { definePlugin, type PluginContext } from "../plugin-context";
+import { createTestNextly, type TestNextly } from "../test-nextly";
+import type { AuthUserId } from "../../types/auth";
+
+let current: TestNextly | undefined;
+afterEach(async () => {
+  await current?.destroy();
+  current = undefined;
+});
+
+/**
+ * The real context type, not a loose one: the point of an end-to-end suite over
+ * this surface is that the PUBLISHED signature carries the method. Typed `any`,
+ * every call here would compile whether or not `PluginCollectionService`
+ * declares `updateMany`, and the suite would stay green while the surface it
+ * exists to pin disappeared.
+ */
+type Services = PluginContext["services"];
+
+async function boot(): Promise<{ services: Services; handle: TestNextly }> {
+  let services: Services | undefined;
+  const probe = definePlugin({
+    name: "@test/update-many",
+    version: "1.0.0",
+    nextly: ">=0.0.0",
+    init: ctx => {
+      services = ctx.services;
+    },
+  });
+  current = await createTestNextly({
+    collections: [
+      defineCollection({
+        slug: "widgets",
+        fields: [text({ name: "title" }), text({ name: "kind" })],
+      }),
+    ],
+    plugins: [probe],
+  });
+  if (!services) throw new Error("the plugin's init never ran");
+  return { services, handle: current };
+}
+
+async function seed(handle: TestNextly, titles: string[]): Promise<string[]> {
+  const ids: string[] = [];
+  for (const title of titles) {
+    const created = await handle.nextly.create({
+      collection: "widgets",
+      data: { title, kind: "draft" },
+    });
+    ids.push((created.item as { id: string }).id);
+  }
+  return ids;
+}
+
+describe("ctx.services.collections.updateMany", () => {
+  it("applies a different patch to each row under {as:'system'}", async () => {
+    const { services, handle } = await boot();
+    const [a, b] = await seed(handle, ["one", "two"]);
+
+    const result = await services.collections.updateMany(
+      "widgets",
+      [
+        { id: a, data: { kind: "published" } },
+        { id: b, data: { title: "renamed" } },
+      ],
+      { as: "system" }
+    );
+
+    expect(result.failed, JSON.stringify(result.errors)).toBe(0);
+    expect(result.successful).toBe(2);
+    expect([...result.ids].sort()).toEqual([a, b].sort());
+
+    const first = (await handle.nextly.findByID({
+      collection: "widgets",
+      id: a,
+    })) as { kind?: string; title?: string };
+    const second = (await handle.nextly.findByID({
+      collection: "widgets",
+      id: b,
+    })) as { kind?: string; title?: string };
+    // Each row took its own patch, and neither took the other's.
+    expect(first.kind).toBe("published");
+    expect(first.title).toBe("one");
+    expect(second.title).toBe("renamed");
+    expect(second.kind).toBe("draft");
+  });
+
+  it("reports a failed row by the index of the entry passed, and commits the rest", async () => {
+    const { services, handle } = await boot();
+    const [a] = await seed(handle, ["one"]);
+
+    const result = await services.collections.updateMany(
+      "widgets",
+      [
+        { id: "missing-id", data: { kind: "published" } },
+        { id: a, data: { kind: "published" } },
+      ],
+      { as: "system" }
+    );
+
+    expect(result.successful).toBe(1);
+    expect(result.failed).toBe(1);
+    expect(result.ids).toEqual([a]);
+    // The index is into the array THIS caller passed, so the row a failure is
+    // about is `entries[index].id`.
+    expect(result.errors.map((e: { index: number }) => e.index)).toEqual([0]);
+  });
+
+  it("refuses a locale by name rather than writing the default language", async () => {
+    const { services, handle } = await boot();
+    const [a] = await seed(handle, ["one"]);
+
+    await expect(
+      services.collections.updateMany(
+        "widgets",
+        [{ id: a, data: { kind: "published" } }],
+        { as: "system", locale: "fr" }
+      )
+    ).rejects.toThrow(/locale/);
+  });
+
+  it("is judged as the caller under {as:'user'}", async () => {
+    const { services, handle } = await boot();
+    const [a] = await seed(handle, ["one"]);
+
+    const result = await services.collections.updateMany(
+      "widgets",
+      [{ id: a, data: { kind: "published" } }],
+      {
+        as: "user",
+        user: { id: "nobody" as AuthUserId, email: "nobody@x.test" },
+      }
+    );
+
+    // Not elevated: the collection gate judges an unprivileged caller, so the
+    // row is not written.
+    expect(result.successful).toBe(0);
+    expect(result.failed).toBe(1);
+    const after = (await handle.nextly.findByID({
+      collection: "widgets",
+      id: a,
+    })) as { kind?: string };
+    expect(after.kind).toBe("draft");
+  });
+  it("pairs with createMany: seed a batch, then patch the batch", async () => {
+    const { services, handle } = await boot();
+
+    const created = await services.collections.createMany(
+      "widgets",
+      [
+        { title: "a", kind: "draft" },
+        { title: "b", kind: "draft" },
+      ],
+      { as: "system" }
+    );
+    expect(created.failed, JSON.stringify(created.errors)).toBe(0);
+
+    const result = await services.collections.updateMany(
+      "widgets",
+      created.ids.map((id: string) => ({ id, data: { kind: "published" } })),
+      { as: "system" }
+    );
+    expect(result.failed, JSON.stringify(result.errors)).toBe(0);
+
+    for (const id of created.ids) {
+      const row = (await handle.nextly.findByID({
+        collection: "widgets",
+        id,
+      })) as { kind?: string };
+      expect(row.kind).toBe("published");
+    }
+  });
+});
diff --git a/packages/nextly/src/plugins/contributions.ts b/packages/nextly/src/plugins/contributions.ts
index 3b8bb86f6f..fecbd4c8db 100644
--- a/packages/nextly/src/plugins/contributions.ts
+++ b/packages/nextly/src/plugins/contributions.ts
@@ -18,6 +18,7 @@ import type {
 import type { PluginAuthContributions } from "./auth-contributions";
 import type { PluginContext } from "./plugin-context";
 import type { PluginRoute } from "./routes/route-types";
+import type { PluginWidgetSource } from "./widgets/collect-widget-sources";
 
 /**
  * @public A plugin-declared custom permission. CRUD permissions are
@@ -560,6 +561,33 @@ export interface PluginContributions {
    * app mounts the Nextly handler (`/admin/api` in a scaffolded project).
    */
   routes?: PluginRoute[];
+  /**
+   * @experimental Dashboard-widget DATA SOURCES: a queryable source this plugin
+   * publishes, paired with the server-side function that answers it.
+   *
+   * Server-side, and therefore not under `admin`: a source is answered in the
+   * Nextly process against the caller's identity, while `admin.widgets` is
+   * about what the dashboard DRAWS. A plugin can contribute either without the
+   * other — a card over `collection:orders` needs no source, and a source is
+   * useful to any card that names it.
+   *
+   * Each entry declares the source's queryable fields and supported ops up
+   * front, so a query is validated against them before the resolver is ever
+   * called. The resolver receives `(query, caller, ctx)` -- its own plugin's
+   * context, which is how it reads data at all.
+   *
+   * 🔴 That validation checks field names, operators and operand SHAPES. It
+   * does not constrain operand VALUES: `where: { total: { equals: "http://..." } }`
+   * is a legal query, and a caller who may place a widget chooses those bytes.
+   * A resolver must never use a value out of `query` as an outbound URL, a
+   * path, or a table or column name without validating it against a closed set
+   * of its own.
+   *
+   * The host cannot prove a resolver consults `caller` — it hands the caller
+   * over and the plugin decides. That is the trust boundary this plugin's
+   * `init()`, hooks and services already cross, not a new one.
+   */
+  widgetSources?: PluginWidgetSource[];
   /**
    * @public Admin UI contributions: menu, pages +
    * settings, per-collection view overrides. `widgets` is
diff --git a/packages/nextly/src/plugins/service-opts.test.ts b/packages/nextly/src/plugins/service-opts.test.ts
index 8bb257c315..dec90a7af8 100644
--- a/packages/nextly/src/plugins/service-opts.test.ts
+++ b/packages/nextly/src/plugins/service-opts.test.ts
@@ -328,3 +328,44 @@ describe("resolveServiceOpts — the caller's own scope", () => {
     ).toEqual({ overrideAccess: true });
   });
 });
+
+describe("verified claims on the supplied identity", () => {
+  it("survive into the identity the access rule is judged on", async () => {
+    // 🔴 `readCaller` spreads `auth.claims` onto the user it builds, so a
+    // caller handed to a plugin carries what the token proved. Rebuilt from
+    // id/name/email/roles alone, a code-defined `access` rule reading one of
+    // those claims saw a DIFFERENT caller than the endpoint authenticated --
+    // and an absence-tolerant rule like `user.plan !== "suspended"` then
+    // GRANTS where it should deny.
+    const resolved = await resolveServiceOpts({
+      as: "user",
+      user: {
+        id: "user-1",
+        email: "a@example.com",
+        tenant: "acme",
+        plan: "suspended",
+      } as never,
+    });
+
+    const judged = resolved.user as unknown as Record<string, unknown>;
+    expect(judged.tenant).toBe("acme");
+    expect(judged.plan).toBe("suspended");
+    // The declared fields still come from the identity, not from the spread.
+    expect(judged.id).toBe("user-1");
+    expect(judged.email).toBe("a@example.com");
+  });
+
+  it("adds nothing for an identity carrying only the declared fields", async () => {
+    // The must-differ half: without it, a version that attached some fixed
+    // object to every caller would satisfy the case above.
+    const resolved = await resolveServiceOpts({
+      as: "user",
+      user: { id: "user-2", email: "b@example.com" } as never,
+    });
+
+    const judged = resolved.user as unknown as Record<string, unknown>;
+    expect(judged.tenant).toBeUndefined();
+    expect(judged.plan).toBeUndefined();
+    expect(judged.id).toBe("user-2");
+  });
+});
diff --git a/packages/nextly/src/plugins/service-opts.ts b/packages/nextly/src/plugins/service-opts.ts
index efe59bccb4..87f3e51c5c 100644
--- a/packages/nextly/src/plugins/service-opts.ts
+++ b/packages/nextly/src/plugins/service-opts.ts
@@ -245,7 +245,31 @@ export async function resolveServiceOpts(
         logContext: { reason: "service-opts-user-missing" },
       });
     }
+    // 🔴 The verified CLAIMS travel with the identity, and dropping them is a
+    // security defect rather than a tidiness one. `readCaller` spreads
+    // `auth.claims` onto the user it builds, so a caller handed to a plugin
+    // carries whatever the token proved -- a tenant, a plan, an entitlement --
+    // and a collection's code-defined `access` rule may read exactly those.
+    // Rebuilt from id/name/email/roles alone, the rule received a DIFFERENT
+    // caller than the endpoint authenticated: a positive check on a claim
+    // denies wrongly, and an absence-tolerant one like
+    // `user.plan !== "suspended"` GRANTS wrongly.
+    //
+    // Taken as "whatever else the supplied identity carried", so a caller
+    // passing a plain `AuthUser` contributes nothing and is unaffected.
+    const {
+      id: _id,
+      name: _name,
+      email: _email,
+      roles: _roles,
+      role: _role,
+      ...claims
+    } = user as typeof user & {
+      roles?: string[];
+      role?: string;
+    };
     const identity = buildUserContext({
+      claims,
       id: user.id,
       name: user.name ?? undefined,
       email: user.email,
@@ -283,7 +307,8 @@ type AccessMethod =
   | "updateEntry"
   | "deleteEntry"
   | "count"
-  | "createMany";
+  | "createMany"
+  | "updateMany";
 
 const CONTEXT_INDEX: Record<AccessMethod, number> = {
   createEntry: 2,
@@ -294,6 +319,9 @@ const CONTEXT_INDEX: Record<AccessMethod, number> = {
   // D56 additions — trailing context at arg index 2.
   count: 2,
   createMany: 2,
+  // The entries carry their own ids, so the context stays at index 2 as on
+  // `createMany` rather than moving out to make room for one.
+  updateMany: 2,
 };
 
 /**
diff --git a/packages/nextly/src/plugins/widgets/__tests__/collect-widget-sources.test.ts b/packages/nextly/src/plugins/widgets/__tests__/collect-widget-sources.test.ts
new file mode 100644
index 0000000000..8e98511034
--- /dev/null
+++ b/packages/nextly/src/plugins/widgets/__tests__/collect-widget-sources.test.ts
@@ -0,0 +1,156 @@
+/**
+ * The plugin widget-source seam.
+ *
+ * Every refusal here is a BOOT failure rather than a warning, and the reason is
+ * the same one the jobs fold gives: which resolver owned an id would otherwise
+ * be decided by plugin load order, and the loser would simply never answer with
+ * nothing anywhere to say so. So the cases below assert that each refusal
+ * happens AT THE FOLD, before anything reaches a store — the point at which an
+ * operator can still be told which plugin to fix.
+ */
+
+import { describe, expect, it } from "vitest";
+
+import type { WidgetResult } from "../../../domains/widgets/result";
+import {
+  collectWidgetSources,
+  type PluginWidgetSource,
+} from "../collect-widget-sources";
+
+const answer = (): Promise<WidgetResult> =>
+  Promise.resolve({ op: "count" as const, total: 0 });
+
+function source(id: string): PluginWidgetSource {
+  return {
+    source: {
+      id,
+      label: "Revenue",
+      kind: "plugin",
+      supports: ["count"],
+      fields: [{ name: "total", type: "number" }],
+    },
+    resolve: answer,
+  };
+}
+
+const plugin = (
+  name: string,
+  widgetSources: PluginWidgetSource[],
+  enabled?: boolean
+) =>
+  ({
+    name,
+    ...(enabled === undefined ? {} : { enabled }),
+    contributes: { widgetSources },
+  }) as never;
+
+describe("collectWidgetSources", () => {
+  it("collects a source a plugin contributes, with its owner", () => {
+    // Provenance travels with it because a collision message is not actionable
+    // without both names.
+    const collected = collectWidgetSources([
+      plugin("@acme/stripe", [source("plugin:stripe/revenue")]),
+    ]);
+
+    expect(collected.map(c => c.source.id)).toEqual(["plugin:stripe/revenue"]);
+    expect(collected.map(c => c.owner)).toEqual(["@acme/stripe"]);
+    expect(collected[0].resolve).toBe(answer);
+  });
+
+  it("takes nothing from a DISABLED plugin", () => {
+    // `initializePlugins` skips a disabled plugin's init, services, hooks and
+    // events, so admitting its resolver would publish a function closed over a
+    // setup that deliberately never ran.
+    const collected = collectWidgetSources([
+      plugin("@acme/off", [source("plugin:off/one")], false),
+      // The control: an enabled plugin in the same fold still contributes, so
+      // this cannot pass by collecting nothing at all.
+      plugin("@acme/on", [source("plugin:on/one")]),
+    ]);
+
+    expect(collected.map(c => c.source.id)).toEqual(["plugin:on/one"]);
+  });
+
+  it("collects from a plugin that does not mention `enabled`", () => {
+    // Absent means enabled, so the check is for an explicit `false` rather than
+    // for a truthy value -- which is the reading that would have dropped every
+    // ordinary plugin.
+    expect(
+      collectWidgetSources([plugin("@acme/quiet", [source("plugin:quiet/a")])])
+    ).toHaveLength(1);
+  });
+
+  it("refuses two plugins declaring one id, naming both", () => {
+    expect(() =>
+      collectWidgetSources([
+        plugin("@acme/first", [source("plugin:shared/id")]),
+        plugin("@acme/second", [source("plugin:shared/id")]),
+      ])
+    ).toThrow(/@acme\/first.*@acme\/second|@acme\/second.*@acme\/first/);
+  });
+
+  it.each(["collection:posts", "single:site-settings", "system:releases"])(
+    "refuses the reserved id %s",
+    id => {
+      // 🔴 `collection:` and `single:` are the dangerous half. A resolver under
+      // one of those answers a question the access-controlled Direct API is
+      // supposed to answer, which diverts that entity's rows away from it --
+      // and such a source is well-formed by every check downstream, since its
+      // kind and namespace agree.
+      expect(() =>
+        collectWidgetSources([plugin("@acme/x", [source(id)])])
+      ).toThrow(/reserved/);
+    }
+  );
+
+  it("refuses an id in no namespace at all", () => {
+    // Not covered by the reserved list: `revenue` starts with none of those
+    // prefixes, and admitting it would publish a source whose id says nothing
+    // about who owns it.
+    expect(() =>
+      collectWidgetSources([plugin("@acme/x", [source("revenue")])])
+    ).toThrow(/must begin with "plugin:"/);
+  });
+
+  it("refuses a source declaring any kind but plugin", () => {
+    // 🔴 The host must not CORRECT this. The boot used to spread
+    // `{ ...source, kind: "plugin" }`, which erased a declared `"collection"`
+    // before `registerSource` could run its kind/namespace agreement check --
+    // so a malformed contribution booted successfully under semantics its
+    // author never wrote.
+    const wrongKind = {
+      ...source("plugin:acme/a"),
+      source: { ...source("plugin:acme/a").source, kind: "collection" },
+    } as unknown as PluginWidgetSource;
+
+    expect(() =>
+      collectWidgetSources([plugin("@acme/x", [wrongKind])])
+    ).toThrow(/must declare kind "plugin"/);
+  });
+
+  it("refuses a source with no resolver", () => {
+    // The half that fails latest if it is not caught here: the source is
+    // discoverable, passes query validation, and only a reader who places the
+    // card finds that nothing answers it.
+    const withoutResolver = {
+      source: source("plugin:acme/a").source,
+    } as unknown as PluginWidgetSource;
+
+    expect(() =>
+      collectWidgetSources([plugin("@acme/x", [withoutResolver])])
+    ).toThrow(/without a resolver/);
+  });
+
+  it("refuses a source with no id, naming the plugin", () => {
+    const withoutId = { resolve: answer } as unknown as PluginWidgetSource;
+
+    expect(() =>
+      collectWidgetSources([plugin("@acme/x", [withoutId])])
+    ).toThrow(/"@acme\/x" contributes a widget source with no id/);
+  });
+
+  it("collects nothing when no plugin contributes any", () => {
+    expect(collectWidgetSources([])).toEqual([]);
+    expect(collectWidgetSources([{ name: "@acme/bare" } as never])).toEqual([]);
+  });
+});
diff --git a/packages/nextly/src/plugins/widgets/collect-widget-sources.ts b/packages/nextly/src/plugins/widgets/collect-widget-sources.ts
new file mode 100644
index 0000000000..88b3891ef0
--- /dev/null
+++ b/packages/nextly/src/plugins/widgets/collect-widget-sources.ts
@@ -0,0 +1,207 @@
+/**
+ * Folding every plugin's `contributes.widgetSources` into one list boot registers.
+ *
+ * ## Why this seam exists
+ *
+ * A source and the function that answers it are useless apart, and the failure
+ * of registering one without the other is invisible until a reader puts the
+ * card on their dashboard: the source is discoverable, it passes query
+ * validation, and only execution finds that nothing answers it. So they travel
+ * as one value from the plugin's declaration all the way to `registerResolvedSource`,
+ * which writes both stores in one call.
+ *
+ * ## Why a fold rather than letting plugins register directly
+ *
+ * A plugin COULD call `registerResolvedSource` from its `init()`, and that is
+ * precisely the arrangement this replaces. Registration order would then be
+ * plugin load order, a duplicate id would be decided by whoever ran last with
+ * nothing anywhere to say so, and a disabled plugin whose `init` is skipped
+ * would contribute nothing while an enabled one that forgot to call it would
+ * look identical. Declaring the sources in `contributes` makes the set readable
+ * before anything executes, which is what lets the collisions below be boot
+ * failures instead of silent losses.
+ *
+ * @module plugins/widgets/collect-widget-sources
+ */
+
+import type { SourceResolver } from "../../domains/widgets/resolved-sources";
+import type { WidgetSource } from "../../domains/widgets/sources";
+import { NextlyError } from "../../errors/nextly-error";
+import type { PluginContext, PluginDefinition } from "../plugin-context";
+
+/**
+ * Answers one contributed source's query, for one caller.
+ *
+ * 🔴 The third argument is the plugin's OWN context, and without it this
+ * contract answers nothing: a plugin's data services are reachable only
+ * through `PluginContext`, so a resolver holding `(query, caller)` alone can
+ * return constants and nothing else. Every other contributed FUNCTION on this
+ * surface is handed the context for the same reason -- `jobs.handler(ctx)`,
+ * `services[name](ctx)` -- and this one was the exception by oversight.
+ *
+ * It is the LAST argument rather than the first because the first two are the
+ * question and who is asking, which is what a resolver is about; the context is
+ * how it goes and looks. That also leaves a resolver needing no data free to
+ * ignore it.
+ *
+ * What it is NOT handed is a request, headers, or anything fetch-capable of its
+ * own. The context is the same one the plugin's `init` receives, bounded by
+ * `createPluginContext` — see `domains/widgets/resolved-sources` for why that
+ * boundary is structural.
+ */
+export type PluginSourceResolver = (
+  query: Parameters<SourceResolver>[0],
+  caller: Parameters<SourceResolver>[1],
+  ctx: PluginContext
+) => ReturnType<SourceResolver>;
+
+/**
+ * One source a plugin contributes, and the function that answers it.
+ *
+ * The SOURCE half stays a plain object rather than anything computed, so
+ * `contributes` remains readable without executing the plugin -- which is what
+ * lets `generate:types` and the admin's own tooling work from config alone.
+ * Only the resolver is a function, and only it receives the context.
+ */
+export interface PluginWidgetSource {
+  /**
+   * 🔴 Narrowed to `kind: "plugin"`, so a contribution declaring any other
+   * kind is a compile error at the plugin rather than something the host
+   * quietly rewrites. The boot used to spread `{ ...source, kind: "plugin" }`,
+   * which erased a declared `"collection"` before `registerSource` could run
+   * its kind/namespace agreement check -- so a malformed contribution booted
+   * successfully under semantics its author never wrote.
+   */
+  source: WidgetSource & { kind: "plugin" };
+  resolve: PluginSourceResolver;
+}
+
+/** A contributed source resolved to what boot needs, plus its provenance. */
+export interface CollectedWidgetSource extends PluginWidgetSource {
+  /** The declaring plugin's name, for logs and collisions. */
+  owner: string;
+}
+
+/**
+ * Namespaces a plugin may not publish into.
+ *
+ * `collection:` and `single:` belong to the Direct API, and a resolver under
+ * one of those ids would answer a question the access-controlled read path is
+ * supposed to answer — diverting that entity's rows away from it. `system:` is
+ * core's own. Held as prefixes so a namespace core adds later is reserved
+ * without anyone remembering to come back here; core's registrations bypass
+ * this fold entirely, so nothing legitimate is refused.
+ */
+const RESERVED_SOURCE_PREFIXES = ["collection:", "single:", "system:"];
+
+/** The namespace a plugin source must declare, matching its `kind`. */
+const PLUGIN_PREFIX = "plugin:";
+
+/**
+ * Fold every enabled plugin's `contributes.widgetSources` into one list.
+ *
+ * Pure — no database access, no registry, no registration. The caller decides
+ * when these reach the stores, which is what keeps built-in sources ahead of
+ * them.
+ *
+ * A DISABLED plugin contributes nothing, for the reason the jobs fold gives:
+ * `initializePlugins` skips a disabled plugin's init, services, hooks and
+ * events, so admitting its resolver would publish a function whose setup
+ * deliberately never ran, closed over whatever it expects to exist.
+ *
+ * Throws on a duplicate id and on an id outside the `plugin:` namespace. Both
+ * are boot failures rather than warnings: which resolver won would otherwise
+ * depend on plugin load order, and the loser would simply never answer with
+ * nothing anywhere to say so.
+ */
+export function collectWidgetSources(
+  plugins: readonly PluginDefinition[]
+): CollectedWidgetSource[] {
+  const seen = new Map<string, string>();
+  const out: CollectedWidgetSource[] = [];
+
+  for (const plugin of plugins) {
+    // `enabled` is optional and absent means enabled, so this tests for an
+    // explicit `false` rather than for a truthy value.
+    if (plugin.enabled === false) continue;
+    for (const contributed of plugin.contributes?.widgetSources ?? []) {
+      consider(contributed, plugin.name, seen, out);
+    }
+  }
+
+  return out;
+}
+
+/**
+ * Admit one contributed source, or refuse it by name.
+ *
+ * Its own function rather than a closure in the loop: the checks below are the
+ * substance of this module, and folding them into the iteration put every
+ * refusal one indent deeper than the rule it enforces.
+ */
+function consider(
+  contributed: PluginWidgetSource,
+  owner: string,
+  seen: Map<string, string>,
+  out: CollectedWidgetSource[]
+): void {
+  const id = contributed?.source?.id;
+  if (typeof id !== "string" || id === "") {
+    throw NextlyError.invalidInput({
+      message: `NEXTLY_WIDGET_SOURCE_INVALID: "${owner}" contributes a widget source with no id.`,
+      logContext: { owner },
+    });
+  }
+
+  // Checked here rather than left to `registerSource`'s own kind/namespace
+  // agreement rule. That rule would refuse a `plugin:` id declaring kind
+  // `"collection"`, but it has nothing to say about a `collection:` id
+  // declaring kind `"collection"` — which is exactly what a plugin must not be
+  // able to publish, and which is well-formed by every check downstream.
+  const reserved = RESERVED_SOURCE_PREFIXES.find(prefix =>
+    id.startsWith(prefix)
+  );
+  if (reserved !== undefined) {
+    throw NextlyError.invalidInput({
+      message: `NEXTLY_WIDGET_SOURCE_RESERVED: "${owner}" contributes widget source "${id}", but the "${reserved}" namespace is reserved.`,
+      logContext: { id, owner, reserved },
+    });
+  }
+  if (!id.startsWith(PLUGIN_PREFIX)) {
+    throw NextlyError.invalidInput({
+      message: `NEXTLY_WIDGET_SOURCE_NAMESPACE: "${owner}" contributes widget source "${id}", but a contributed source's id must begin with "${PLUGIN_PREFIX}".`,
+      logContext: { id, owner },
+    });
+  }
+
+  // The runtime half of the narrowing above, for a plugin compiled separately,
+  // for JavaScript, and for a cast. Refused rather than corrected: the host
+  // rewriting a declared kind is how a malformed contribution came to boot.
+  if (contributed.source.kind !== "plugin") {
+    throw NextlyError.invalidInput({
+      message: `NEXTLY_WIDGET_SOURCE_KIND: "${owner}" contributes widget source "${id}" with kind "${String(contributed.source.kind)}"; a contributed source must declare kind "plugin".`,
+      logContext: { id, owner, kind: String(contributed.source.kind) },
+    });
+  }
+
+  if (typeof contributed.resolve !== "function") {
+    // The half that fails latest if it is not caught here: a source with no
+    // resolver is discoverable and passes validation, and only a reader who
+    // places the card finds out that nothing answers it.
+    throw NextlyError.invalidInput({
+      message: `NEXTLY_WIDGET_SOURCE_INVALID: "${owner}" contributes widget source "${id}" without a resolver function.`,
+      logContext: { id, owner },
+    });
+  }
+
+  const previous = seen.get(id);
+  if (previous !== undefined) {
+    throw NextlyError.invalidInput({
+      message: `NEXTLY_WIDGET_SOURCE_COLLISION: widget source "${id}" is declared by both "${previous}" and "${owner}". Source ids must be unique.`,
+      logContext: { id, owner, previous },
+    });
+  }
+
+  seen.set(id, owner);
+  out.push({ ...contributed, owner });
+}
diff --git a/packages/nextly/src/shared/lib/field-level-registry.ts b/packages/nextly/src/shared/lib/field-level-registry.ts
index 043eb63478..65e459df42 100644
--- a/packages/nextly/src/shared/lib/field-level-registry.ts
+++ b/packages/nextly/src/shared/lib/field-level-registry.ts
@@ -68,7 +68,7 @@ type FieldAccessFn = (args: {
  * the single source for the string, so this carries what it returns rather
  * than re-deriving it.
  */
-interface CallerGrants {
+export interface CallerGrants {
   permissions: string[];
   roles: string[];
 }
diff --git a/packages/plugin-sdk/STABILITY.md b/packages/plugin-sdk/STABILITY.md
index 73c68e92c2..fe917587a2 100644
--- a/packages/plugin-sdk/STABILITY.md
+++ b/packages/plugin-sdk/STABILITY.md
@@ -59,46 +59,47 @@ in any release.
 These ship today but are **not yet stable** — no first-party plugin has exercised them in
 production, or they are intentionally held back. Use them, but expect change.
 
-| Surface                                                 | Exports                                                                                                                                                                                                                                                                                                                                                                                                                                                                   | Why still experimental                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
-| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Booted instance (`@nextlyhq/plugin-sdk`)                | `getCachedNextly`                                                                                                                                                                                                                                                                                                                                                                                                                                                         | New. Plugin server work that runs OUTSIDE a route has no `ctx.services` and no config in scope: a field reader resolved at mint time, a scheduled task. This reads the already-booted instance and awaits the boot-migration gate. Exercised by `plugin-page-builder`, which was reaching core's root entry for it; graduates per D55 once that import moves and ships in a release.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
-| Route responses (`@nextlyhq/plugin-sdk`)                | `respondList`, `respondDoc`, `respondAction`, `respondMutation`, `PaginationMeta`, `trustedClientIp`                                                                                                                                                                                                                                                                                                                                                                      | New. The envelopes a contributed route answers in, plus the client address resolved under the deployment's proxy-trust settings. A plugin owning a top-level route needs both: a hand-built body drifts from the canonical shape and drops the post-commit warnings `respondAction` carries, and an author without the resolver reads `x-forwarded-for`, which is the forgeable value it exists to replace. Exercised by `plugin-form-builder`'s public form routes; graduates per D55 once those ship in a release.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
-| Singles registry read (`ctx.services.singles`)          | `PluginSinglesService`, `ctx.services.singles.list`                                                                                                                                                                                                                                                                                                                                                                                                                       | Read-only listing of DECLARED Singles and their fields — the counterpart to `collections`, which had no equivalent, so a plugin sweeping the app's documents silently covered only half of it. Registry only: it returns no Single's content and creates nothing, which matters because a read-shaped call on the Single path is not free of side effects in general. Addressed by slug, since a Single's row may not exist until something writes to it. First consumed by `plugin-page-builder`'s class-usage index; graduates when that ships.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
-| Raw DB escape hatch                                     | `ctx.db`                                                                                                                                                                                                                                                                                                                                                                                                                                                                  | D56 — kept experimental on purpose; prefer `ctx.services`. Aggregations beyond `count` are the only intended use.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
-| Plugin-registered hooks                                 | `ctx.hooks`, `PluginHookRegistry`, `HookType`, `HookHandler`                                                                                                                                                                                                                                                                                                                                                                                                              | No first-party plugin registers a hook via `ctx.hooks` yet (seo/form-builder use collection-level hooks + events instead).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
-| Filters & actions (D63)                                 | `ctx.filters`, `ctx.actions`, `FilterSeams`, `Filter`, `Action`, `CoreFilterSeam`, `PluginFilterRegistry`, `PluginActionRegistry`, `EmailPayloadFilterValue`, `EmailFilterContext`, `EmailAfterSendValue`, `NavCollectionItem`, `NavFilterContext`, `ListQueryWhere`, `ListQueryFilterContext`                                                                                                                                                                            | No first-party plugin contributes a filter/action through this surface yet.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
-| Secrets (D37)                                           | `secret`, `Secret`, `isSecret`                                                                                                                                                                                                                                                                                                                                                                                                                                            | No first-party plugin wraps a secret yet. The redaction contract is solid but unexercised.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
-| Client UX (`@nextlyhq/plugin-sdk/client`)               | `useCan`, `Can`, `CanProps`                                                                                                                                                                                                                                                                                                                                                                                                                                               | No first-party plugin's admin UI calls `useCan`/`<Can>` yet. Graduates when one does.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| Admin dashboard widgets                                 | `PluginAdminWidget`, `contributes.admin.widgets`                                                                                                                                                                                                                                                                                                                                                                                                                          | D22/C9 — now **rendered** by `PluginWidgetGrid` on the dashboard, permission-gated. No first-party plugin contributes one yet; graduates per D55.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
-| Widget component types (`@nextlyhq/plugin-sdk/widgets`) | `WidgetComponentProps`, `WidgetSlot`, `WidgetResult`, `WidgetResultField`, `WidgetQueryBatchResponse`                                                                                                                                                                                                                                                                                                                                                                     | Types only, no runtime. Published with the widget contract they describe, so they stay `@experimental` for as long as `contributes.admin.widgets` does — D55 requires a first-party plugin source (5.4) before that graduates.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-| Dashboard widget registry & query contract              | `registerWidget`, `registerSource`, `WidgetDefinition`, `WidgetQuery`, `WidgetSource`, `WidgetSourceField`, `WIDGET_SIZES`, `WIDGET_HEIGHTS`, `WIDGET_ARCHETYPES`, `WIDGET_OPS`, `WIDGET_SOURCE_KINDS`, `WIDGET_SOURCE_FIELD_TYPES`, and the `WidgetSize` / `WidgetHeight` / `WidgetArchetype` / `WidgetSourceKind` / `WidgetSourceFieldType` / `WidgetOp` vocabularies                                                                                                   | D22/C9 — the other half of `PluginAdminWidget`: what a widget IS and what it may read. Forwarded from core because a plugin imports only from this package, so a registry exported from the `nextly` root alone was unreachable to an author following the documented surface. Graduates with `PluginAdminWidget`, per D55.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
-| Admin header slot (C9)                                  | `contributes.admin.headerSlot`                                                                                                                                                                                                                                                                                                                                                                                                                                            | New in Phase 3. A component rendered in the admin top bar (self-gated). No first-party plugin contributes one yet.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
-| Per-field admin override (D24)                          | `FieldAdminOptions.component` (`field.admin.component`)                                                                                                                                                                                                                                                                                                                                                                                                                   | New in Phase 3. Overrides a field's admin editor by component path. No first-party plugin uses it yet.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
-| Plugin nav placement                                    | `PluginNavSection` (also on `contributes.admin.pages[].section` / `menu[].section`)                                                                                                                                                                                                                                                                                                                                                                                       | New. Lets a plugin place its pages and menu items in any sidebar section (deferring to its own `placement`). No first-party plugin declares a `section` yet; graduates per D55.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
-| Admin chrome suppression                                | `useSuppressAdminChrome`, `AdminChromeLayer`                                                                                                                                                                                                                                                                                                                                                                                                                              | New. An immersive surface requests which chrome layers to hide while mounted; the page builder is the first consumer, in production use but not yet a release behind it.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
-| Field-UI kit: numeric bounds                            | `ValidationNumberField`, `ValidationNumberFieldProps`                                                                                                                                                                                                                                                                                                                                                                                                                     | New. The shared control for count/value bounds, consumed by the schema builder and `plugin-form-builder`; graduates with the rest of the field-UI kit.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
-| Validation rules editor (`@nextlyhq/plugin-sdk/admin`)  | `ValidationRulesEditor`, `drawsAnyValidationRule`, `EDITABLE_VALIDATION_RULES`, `ValidationRulesEditorProps`, `ValidationRuleValues`                                                                                                                                                                                                                                                                                                                                      | The whole set of validation rules a field accepts. Takes the ALLOWED RULES rather than a field type: a list of type names cannot see a type it was not written to know about, and both surfaces that drew this independently had that defect — a plugin-contributed type was offered nothing. Ask `validationRulesForFieldType` from `nextly/field-catalog`. Neutral about storage, as `ConditionRow` is: the schema builder stores the custom message as `message` and the form builder as `errorMessage`, so the component names the rule as core does and each surface maps its own key, since silently reconciling them would make every stored value under one of them wrong. `drawsAnyValidationRule` answers whether it would render anything, so no surface restates which types have no options. Composed by the schema builder's field-editor sheet and `plugin-form-builder`'s `FieldEditor`; graduates per D55 once a third-party plugin composes one.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
-| Single document read/write                              | `useSingleDocument`, `useUpdateSingleDocument`, `SingleDocument`, `ApiError`, `ValidationIssue`, `isApiError`, `validationIssues`, `apiErrorMessage`, `toastMutationResult`                                                                                                                                                                                                                                                                                               | New. The same client the admin's own Single form uses, so a plugin that owns a Single does not build a second answer to how that document caches and when it invalidates. The page builder is the first consumer (the Site Style document behind the four style studios); graduates per D55 once that ships in a release. Two contract notes a consumer must know: a write is PARTIAL, so several surfaces owning different fields of one Single can each send only their own; and a refused write REJECTS rather than resolving — the fetcher raises an `ApiError` whose `data` carries `{ errors: [{ path, code, message }] }`, keyed by `path`. Reach that payload with `validationIssues(reason)`, which answers with an empty array for anything that is not a validation failure; the mutation's error is typed `Error` because a request failing before a response exists rejects with the native error and carries no `status`, and `isApiError` is what separates the two. `apiErrorMessage` is the third of the set and the one most surfaces want: a sentence to put in front of a person, assembled from the per-field reasons when there are any and from the top-level message when there are not, with a caller-supplied fallback for a rejection carrying no message at all. Published because rebuilding it is how a plugin comes to show "Validation failed." -- which is true, and silent about which field -- while the admin's own screens show the reasons. `toastMutationResult` is the other half, for the write that COMMITTED and then partly failed: a post-commit hook cannot un-save the row, so the server answers success and carries the failures alongside, and the array holds two different things -- a `failure` is something that did not happen and a `notice` is something the caller should merely know. One message for both reports a successful advisory as a failure and throws away its public text, so the split, the headline and the per-warning detail are published rather than left to be rebuilt. |
-| Media upload (`@nextlyhq/plugin-sdk/admin`)             | `useUploadMedia`                                                                                                                                                                                                                                                                                                                                                                                                                                                          | New. The one route a plugin has to put bytes on this site, and the same mutation the admin's own dropzone uses. It exists because several things a plugin may author cannot reference a file anywhere else: `validateFontFace` refuses a `src` carrying a scheme or an authority, so a plugin offering a font has to store the file here and point at the id it gets back. `mutateAsync({ file })` resolves to the stored `Media`, whose `mimeType` is the type upload validation SETTLED on rather than the one the browser guessed — that is the value to carry into anything naming a format, since the two disagree for exactly the types a picker cannot identify. The page builder's fonts panel is the first consumer; graduates per D55 once a second one exists. Held experimental for a second reason as well: the return shape is the admin's `Media` record, and which of its fields a plugin may rely on is not yet decided.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
-| Plugin route read (`@nextlyhq/plugin-sdk/admin`)        | `usePluginRoute`, `PluginRouteRead`, `PluginRouteRequest`                                                                                                                                                                                                                                                                                                                                                                                                                 | New. A plugin's admin components reading a route that same plugin contributed. The two halves of a plugin could not reach each other: a plugin may serve an HTTP route and may render admin components, and there was no client for the second to call the first with — measured, the one first-party plugin whose UI needed one contained no `fetch` at all, so an author's choice was to hand-roll the session, its refresh and the error envelope, or to read something else instead. Goes through the same `protectedApi` and TanStack Query the admin's own reads use, so a plugin does not build a second answer to how its data caches and when it invalidates. Three contract notes a consumer must know. The plugin names ITSELF, because there is no ambient plugin identity in the admin — a component is rendered through a registry by string path, so nothing in its React context says which plugin contributed it, which is why `usePluginClientConfig` takes the name too. The path is built from that name through the dispatcher's own `pluginRouteFullPath` (shared via `nextly/config`), so a caller cannot address a namespace the server does not serve — a mistake that does not raise, because a request to a path nothing serves answers with nothing and reads as an empty result. And `pending` is a REAL third state beside the data: `undefined` is both "the route answered nothing" and "the route has not answered", and a surface that cannot separate them draws its empty state over a read in flight. The page builder is the first consumer (the saved-pattern library behind the insert panel); graduates per D55 once that ships in a release.                                                                                                                                                                                                                                                                                                                                                                |
-| Plugin route write (`@nextlyhq/plugin-sdk/admin`)       | `usePluginRouteMutation`, `PluginRouteMethod`, `PluginRouteWrite`, `PluginRouteWriter`                                                                                                                                                                                                                                                                                                                                                                                    | New, and the other half of the read above. A plugin could read its own contributed route and had nothing to write to one with, so any feature that saved something went back to hand-rolling the session, its refresh and the error envelope — the problem the read hook was added to remove, left standing on the other side of the same seam. Goes through the same `protectedApi` and TanStack Query the admin's own writes use. Four contract notes. The plugin names ITSELF, for the reason the read does. `invalidates` names the plugin's own read paths so a write refreshes the list it belongs in — named rather than inferred, because nothing in the admin knows which reads a write affects, and each is resolved through the CALLING plugin's name so one plugin cannot invalidate another's cached reads however it spells a path. `write` RESOLVES on failure rather than rejecting, answering `undefined`, and reports the cause on `error`: a rejecting promise is the idiomatic TanStack shape and a footgun on a surface handed to plugin authors, and this matches the read hook so there is one shape to learn. And nothing is toasted from the hook — the admin's own mutations toast because they own the surface that follows, and a plugin owns its own. The verbs are `Exclude<RouteMethod, "GET">` rather than a second list, so a method added to the route contract cannot leave this unable to call it. Graduates per D55 once a first-party plugin ships a write through it; the page builder's save-as-pattern is the intended first consumer.                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
-| Plugin identity & classification                        | `PLUGIN_CATEGORIES`, `isPluginCategory`, `pluginAdminSlug`                                                                                                                                                                                                                                                                                                                                                                                                                | The same implementations the admin routes and filters on, re-exported so a plugin author does not restate them. No first-party plugin consumes them yet; graduates per D55 once one does.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
-| Locale selectors (`@nextlyhq/plugin-sdk`)               | `isLocaleSelector`                                                                                                                                                                                                                                                                                                                                                                                                                                                        | New. Which `locale` values the core reads as instructions rather than languages (`*`, `all`), so a route forwarding `?locale=` into `ctx.services` can treat a wildcard as "no language" without keeping a list that agrees with the core's only until one of them gains an entry; `ServiceOpts.locale` refuses the same spellings with this function. Exercised by `plugin-form-builder`'s submission redirect; graduates per D55 once that ships in a release.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
-| Auth extensibility (D71/D57)                            | `AuthStrategy`, `AuthInput`, `AuthOutcome`, `Challenge`, `ChallengeDefinition`, `AuthHooks`, `AuthHookName`, `contributes.auth`, `auth.strategies`                                                                                                                                                                                                                                                                                                                        | New in M7. The whole surface is unexercised by a first-party plugin; graduates per D55 once one does.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| Role bundles (D67)                                      | `PluginRole`, `contributes.roles`                                                                                                                                                                                                                                                                                                                                                                                                                                         | New in Phase 2. Seeded role bundles; unexercised by a first-party plugin in production — graduates per D55 once one is.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
-| Custom services (D64/D66)                               | `contributes.services`, `ctx.services.plugins.<name>.<svc>`, `nextly.plugins.<name>.<svc>`                                                                                                                                                                                                                                                                                                                                                                                | Exercised by `plugin-page-builder`, which contributes its block registry through it — a plugin adding blocks resolves that service rather than importing the engine, which is what makes the registration timing safe. The namespace is still typed `unknown` at the call site, so a contributing plugin should export a typed accessor for its own service as the page builder does with `blockRegistry(ctx)`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
-| Scheduled tasks (D61)                                   | `ScheduledTask`, `contributes.schedules`                                                                                                                                                                                                                                                                                                                                                                                                                                  | **RESERVED, not executed.** Shape published so the gap isn't silent; a real scheduler needs durable jobs (D51). Use external cron + route handlers, or event-driven work, meanwhile.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
-| Email providers + templates (D65)                       | `contributes.emailProviders`, `contributes.emailTemplates`, `PluginEmailProvider`, `PluginEmailTemplate`, `defineEmailProvider`, `MAX_EMAIL_PROVIDER_TYPE_LENGTH`, `EmailProviderDefinition`, `EmailProviderConfigField`, `EmailProviderCapabilities`, `EmailProviderDescriptor`, `ProviderAvailability`, `RegisteredEmailProvider`                                                                                                                                       | New in Phase 2, widened since. A provider is now a DEFINITION rather than a bare factory: it declares its config fields, which of them are secret, and how to validate them, so the registry can validate at the API boundary and an admin can render a form for a provider core was never compiled against. `PluginEmailProvider` is the erased value `defineEmailProvider()` returns — authors keep their own config type and erasure happens once at registration. A definition may also declare `checkAvailability`, which reports whether the install can run it at all -- distinct from `testConnection`, which asks whether a CONFIGURATION works -- so a provider needing an optional peer dependency is described as needing it rather than offered and failing at send time. Still unexercised by a first-party plugin; graduates per D55 once one ships.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
-| Plugin client config                                    | `contributes.admin.clientConfig`, `usePluginClientConfig`, `JsonObject`, `JsonValue`                                                                                                                                                                                                                                                                                                                                                                                      | A plugin's own configuration, declared on the server where the host builds its config and read in the browser by the plugin's admin components, delivered through `/api/admin-meta`. That endpoint needs no authentication, so the value reaches anonymous callers and must hold nothing secret. Rejected at boot when it does not survive JSON, rather than delivered mangled. `plugin-page-builder` exercises it for `remotePatterns`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
-| Custom field types (D16/M9a)                            | `contributes.fieldTypes`, `PluginFieldType` (incl. `surfaces`, `label`, `codegen` with `PluginFieldCodegen` / `PluginFieldCodegenImport`, `description`, `icon`, `category`, `validate`), `PluginFieldValidateArgs`, `PluginFieldInstance`, `PluginFieldIssue`, `PluginFieldValidationResult`, `FieldSurface`, `isPluginFieldTypeOnSurface`                                                                                                                               | Storage primitive + server-side value validation (`validate`) + config-validation acceptance + admin rendering now all land: a plugin type appears in the field pickers (surface-filtered), is accepted by the entry/user/form validators, and renders via its admin component. `plugin-form-builder` exercises the forms surface. Graduates per D55 once a third-party plugin ships one.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
-| Validating values against declarations                  | `validateFieldValues`, `ValidateFieldValuesOptions`, `FieldValueDeclaration`, `FieldValueDeclarationInput`, `ValidationIssue`                                                                                                                                                                                                                                                                                                                                             | New seam. Core's block props are the only caller; no first-party plugin depends on it yet, so it graduates per D55 once the page builder owns block props.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
-| Route path derivation (`@nextlyhq/plugin-sdk/routing`)  | `slugToStaticParam`                                                                                                                                                                                                                                                                                                                                                                                                                                                       | The content route's single answer to what path a stored slug renders at, so anything emitting a URL for an entry derives it instead of rebuilding the rule — a second opinion names a path the route does not serve. Returns the catch-all segments, or `null` when the route would refuse the slug (reserved path, `.`/`..` segment, or a normalization that changed it). It judges the value Next hands the route, which EXCLUDES the static mount prefix, so a caller mounting a collection under a prefix supplies that itself. `plugin-seo` exercises it for sitemap `<loc>` values, which starts the D55 clock rather than ending it.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
-| Field-UI kit (`@nextlyhq/plugin-sdk/admin`)             | `FieldTypePicker`, `FieldOptionsEditor`, `withOptionIds`, `FieldOption`, `FieldDefaultValueInput`, `FieldDefaultOption`, `usePluginFieldTypeEntries`, `FieldTypePickerProps`, `FieldOptionsEditorProps`, `FieldDefaultValueInputProps`, `ConditionRow`, `operatorsForType`, `operatorTakesValue`, `ConditionRowProps`, `ConditionSource`, `ConditionSourceOption`, `ConditionValue`, `ConditionOperatorName`, `ConditionRange`                                            | Controlled, form-library-agnostic field-building components rendered from `nextly/field-catalog`. Each has a narrow, storage-agnostic contract that never exposes admin internals. `plugin-form-builder` composes `FieldTypePicker`, `usePluginFieldTypeEntries`, `FieldOptionsEditor`, and `withOptionIds` (its `FieldEditor`); `FieldDefaultValueInput` awaits a first-party exerciser. `ConditionRow` is composed by both the schema builder's `ConditionBuilder` and `plugin-form-builder`'s `ConditionalLogicEditor`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
-| Control primitives (`@nextlyhq/plugin-sdk/admin`)       | `Button`, `Input`, `Textarea`, `Checkbox`, `Switch`, `Label`, `Select` (+ `SelectContent`, `SelectGroup`, `SelectItem`, `SelectLabel`, `SelectSeparator`, `SelectTrigger`, `SelectValue`), `Dialog` (+ `DialogClose`, `DialogContent`, `DialogDescription`, `DialogFooter`, `DialogHeader`, `DialogTitle`, `DialogTrigger`), `FieldShell`, `FormSection`, `FormActions`, `FieldShellProps`, `FieldShellRenderProps`, `FieldWidth`, `FormSectionProps`, `FormActionsProps` | The controls a settings form is assembled from. Layout primitives alone left an author with a `Card` and nothing to put inside it, so the documented escalation — layout, then the Layer-2 safelist, then the plugin's own `admin.styles` — sent every plugin needing a button to its last step, which is the one surface the design linter cannot see. Payload, Strapi and Directus all give extension authors the real library; the curated subset was the outlier. Scoped to what an ordinary form cannot be built without rather than the whole set, because exporting a component makes its props public API and a name added later is a smaller event than a name withdrawn. Routed through `@nextlyhq/admin` like every other block here — `plugin-sdk` has no `@nextlyhq/ui` dependency and `ui`'s root barrel carries a `"use client"` banner. Held experimental: no first-party plugin composes a form from these yet, so D55's bar is unmet.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
-| Block authoring (`@nextlyhq/plugin-sdk/blocks`)         | `defineBlock`, `AnyBlockDefinition`, `BlockDefinition`, `BlockRenderArgs`, `BlockRenderResult`, `BlockSupports`, `InferBlockProps`, `PropSchema`, `SupportDefinition`                                                                                                                                                                                                                                                                                                     | The contracts for authoring a block the page builder can render, re-exported from `@nextlyhq/blocks-engine`. A subpath so a plugin unrelated to blocks never pulls the engine into its type graph. The definition shape settles at the end of the engine phase, so a contributed block may need changes until then; the registration side is not here — it is `blockRegistry(ctx)` from `@nextlyhq/plugin-page-builder/blocks`, since the registry belongs to that plugin rather than to core. Graduates per D55 once a third-party plugin ships a block.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
-| Schema traversal                                        | `addressableFields`, `AddressableFieldsOptions`, `AddressableField`, `UnvalidatedAddressableField`                                                                                                                                                                                                                                                                                                                                                                        | New. Flattens presentational groups so a caller can find where a value is actually stored — an unnamed container keeps its children at its own level, a named one keeps them under itself. `descendInto` chooses which containers count as transparent, and that choice has to be made DURING the walk: the result holds the flattened children themselves, so a field reached through an unnamed repeater is the same object as one reached through an unnamed group, and no filter over the returned list can separate them. Held experimental until a first-party plugin consumes it in production and deletes its own walk; core's five call sites do not count toward that bar, since they are the caller it already had.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-| Draft/publish eligibility                               | `collectionDraftSplit`, `AuthoredDraftSplitCollection`, `DraftSplitEligibility`, `DraftSplitDisabledReason`                                                                                                                                                                                                                                                                                                                                                               | New. Answers whether a collection stores a working draft beside its published row — five conditions together, of which `status: true` alone is not one. A plugin storing anything per published/draft cannot work this out and must not guess. Held experimental until a second first-party plugin consumes it. **First consumer present, second still absent.** The page-builder's class-usage save hook now resolves `hasDrafts` through this export - `class-usage-hook.ts` calls the injected `draftSplit` and takes `hasDrafts` from the verdict's `eligible` - so the first half of the bar below is met. Contract tests do not count toward the second-consumer bar: promoting on them would graduate an API that the claimed first plugin never exercised. The bar is met when a SECOND plugin consumes it. `resolvedCollectionDraftSplit` and `ResolvedDraftSplitCollection` are the same question for a Schema Builder collection, whose registry record stores `versions` already resolved and which the authored form therefore cannot answer for; they carry the same experimental status and the same bar. `resolvedCollectionView` projects a registry record onto that input, and is published because it is the only way from the documented producer (`ctx.services.collections.getCollection`, declared to return `Collection`) to the documented consumer without an assertion - `Collection` states no root-level `fields`, `status` or `versions` while the object it returns carries all three.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
-| Background jobs (R-2)                                   | `defineJob`, `MAX_JOB_SLUG_LENGTH`, `JobContext`, `JobDefinition`, `JobDefinitionInput`, `JobRetryPolicy`, `JobSlug`, `JobInputFor`, `QueueJobArgs`, `QueueJobResult`, and `nextly.jobs.queue`                                                                                                                                                                                                                                                                            | No first-party PLUGIN has declared a job type yet — the release drain is core's own. `JobSlug` and `JobInputFor` resolve through `GeneratedTypes`, and nothing generates a `jobs` key yet, so a project augments it by hand; that is the part most likely to change.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| Surface                                                 | Exports                                                                                                                                                                                                                                                                                                                                                                                                                                                                          | Why still experimental                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Booted instance (`@nextlyhq/plugin-sdk`)                | `getCachedNextly`                                                                                                                                                                                                                                                                                                                                                                                                                                                                | New. Plugin server work that runs OUTSIDE a route has no `ctx.services` and no config in scope: a field reader resolved at mint time, a scheduled task. This reads the already-booted instance and awaits the boot-migration gate. Exercised by `plugin-page-builder`, which was reaching core's root entry for it; graduates per D55 once that import moves and ships in a release.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| Route responses (`@nextlyhq/plugin-sdk`)                | `respondList`, `respondDoc`, `respondAction`, `respondMutation`, `PaginationMeta`, `trustedClientIp`                                                                                                                                                                                                                                                                                                                                                                             | New. The envelopes a contributed route answers in, plus the client address resolved under the deployment's proxy-trust settings. A plugin owning a top-level route needs both: a hand-built body drifts from the canonical shape and drops the post-commit warnings `respondAction` carries, and an author without the resolver reads `x-forwarded-for`, which is the forgeable value it exists to replace. Exercised by `plugin-form-builder`'s public form routes; graduates per D55 once those ship in a release.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| Singles registry read (`ctx.services.singles`)          | `PluginSinglesService`, `ctx.services.singles.list`                                                                                                                                                                                                                                                                                                                                                                                                                              | Read-only listing of DECLARED Singles and their fields — the counterpart to `collections`, which had no equivalent, so a plugin sweeping the app's documents silently covered only half of it. Registry only: it returns no Single's content and creates nothing, which matters because a read-shaped call on the Single path is not free of side effects in general. Addressed by slug, since a Single's row may not exist until something writes to it. First consumed by `plugin-page-builder`'s class-usage index; graduates when that ships.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| Batch update (`ctx.services.collections`)               | `ctx.services.collections.updateMany`                                                                                                                                                                                                                                                                                                                                                                                                                                            | New. The facade ended at `createMany`, so plugin code could write many rows in one call and then had no way to change them in one: the only batch update was a loop of `updateEntry` calls, each with its own transaction. Takes one `{ id, data }` per row, so one call can apply a different patch to each row, and returns the `BatchOperationResult` `createMany` already returns. There is deliberately no by-filter form: a filter that matches more than its author meant is the failure this surface cannot take back, and `listEntries` plus this method compose to the same thing with the rows named. Refuses a `locale` by name, as `createMany` does. `PluginCollectionService` is `@public`, so this member is called out here rather than the type: it graduates per D55 once a first-party plugin exercises it in production. No consumer yet.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| Raw DB escape hatch                                     | `ctx.db`                                                                                                                                                                                                                                                                                                                                                                                                                                                                         | D56 — kept experimental on purpose; prefer `ctx.services`. Aggregations beyond `count` are the only intended use.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| Plugin-registered hooks                                 | `ctx.hooks`, `PluginHookRegistry`, `HookType`, `HookHandler`                                                                                                                                                                                                                                                                                                                                                                                                                     | No first-party plugin registers a hook via `ctx.hooks` yet (seo/form-builder use collection-level hooks + events instead).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
+| Filters & actions (D63)                                 | `ctx.filters`, `ctx.actions`, `FilterSeams`, `Filter`, `Action`, `CoreFilterSeam`, `PluginFilterRegistry`, `PluginActionRegistry`, `EmailPayloadFilterValue`, `EmailFilterContext`, `EmailAfterSendValue`, `NavCollectionItem`, `NavFilterContext`, `ListQueryWhere`, `ListQueryFilterContext`                                                                                                                                                                                   | No first-party plugin contributes a filter/action through this surface yet.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| Secrets (D37)                                           | `secret`, `Secret`, `isSecret`                                                                                                                                                                                                                                                                                                                                                                                                                                                   | No first-party plugin wraps a secret yet. The redaction contract is solid but unexercised.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
+| Client UX (`@nextlyhq/plugin-sdk/client`)               | `useCan`, `Can`, `CanProps`                                                                                                                                                                                                                                                                                                                                                                                                                                                      | No first-party plugin's admin UI calls `useCan`/`<Can>` yet. Graduates when one does.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| Admin dashboard widgets                                 | `PluginAdminWidget`, `contributes.admin.widgets`                                                                                                                                                                                                                                                                                                                                                                                                                                 | D22/C9 — now **rendered** by `PluginWidgetGrid` on the dashboard, permission-gated. No first-party plugin contributes one yet; graduates per D55.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| Widget component types (`@nextlyhq/plugin-sdk/widgets`) | `WidgetComponentProps`, `WidgetSlot`, `WidgetResult`, `WidgetResultField`, `WidgetQueryBatchResponse`                                                                                                                                                                                                                                                                                                                                                                            | Types only, no runtime. Published with the widget contract they describe, so they stay `@experimental` for as long as `contributes.admin.widgets` does — D55 requires a first-party plugin source (5.4) before that graduates.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| Dashboard widget registry & query contract              | `registerWidget`, `registerSource`, `WidgetDefinition`, `WidgetQuery`, `WidgetSource`, `WidgetSourceField`, `WIDGET_SIZES`, `WIDGET_HEIGHTS`, `WIDGET_ARCHETYPES`, `WIDGET_OPS`, `WIDGET_SOURCE_KINDS`, `WIDGET_SOURCE_FIELD_TYPES`, `WidgetSourceResolver`, `PluginSourceResolver`, `PluginWidgetSource`, `ReadCaller`, `callerReadOptions`, and the `WidgetSize` / `WidgetHeight` / `WidgetArchetype` / `WidgetSourceKind` / `WidgetSourceFieldType` / `WidgetOp` vocabularies | D22/C9 — the other half of `PluginAdminWidget`: what a widget IS and what it may read. Forwarded from core because a plugin imports only from this package, so a registry exported from the `nextly` root alone was unreachable to an author following the documented surface. Graduates with `PluginAdminWidget`, per D55. `WidgetSourceResolver` / `PluginWidgetSource` / `ReadCaller` are the DATA SOURCE half — what `contributes.widgetSources` is written against — and graduate on the same ladder, once a first-party plugin has shipped a source (Phase 5.4).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| Admin header slot (C9)                                  | `contributes.admin.headerSlot`                                                                                                                                                                                                                                                                                                                                                                                                                                                   | New in Phase 3. A component rendered in the admin top bar (self-gated). No first-party plugin contributes one yet.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| Per-field admin override (D24)                          | `FieldAdminOptions.component` (`field.admin.component`)                                                                                                                                                                                                                                                                                                                                                                                                                          | New in Phase 3. Overrides a field's admin editor by component path. No first-party plugin uses it yet.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| Plugin nav placement                                    | `PluginNavSection` (also on `contributes.admin.pages[].section` / `menu[].section`)                                                                                                                                                                                                                                                                                                                                                                                              | New. Lets a plugin place its pages and menu items in any sidebar section (deferring to its own `placement`). No first-party plugin declares a `section` yet; graduates per D55.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| Admin chrome suppression                                | `useSuppressAdminChrome`, `AdminChromeLayer`                                                                                                                                                                                                                                                                                                                                                                                                                                     | New. An immersive surface requests which chrome layers to hide while mounted; the page builder is the first consumer, in production use but not yet a release behind it.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| Field-UI kit: numeric bounds                            | `ValidationNumberField`, `ValidationNumberFieldProps`                                                                                                                                                                                                                                                                                                                                                                                                                            | New. The shared control for count/value bounds, consumed by the schema builder and `plugin-form-builder`; graduates with the rest of the field-UI kit.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| Validation rules editor (`@nextlyhq/plugin-sdk/admin`)  | `ValidationRulesEditor`, `drawsAnyValidationRule`, `EDITABLE_VALIDATION_RULES`, `ValidationRulesEditorProps`, `ValidationRuleValues`                                                                                                                                                                                                                                                                                                                                             | The whole set of validation rules a field accepts. Takes the ALLOWED RULES rather than a field type: a list of type names cannot see a type it was not written to know about, and both surfaces that drew this independently had that defect — a plugin-contributed type was offered nothing. Ask `validationRulesForFieldType` from `nextly/field-catalog`. Neutral about storage, as `ConditionRow` is: the schema builder stores the custom message as `message` and the form builder as `errorMessage`, so the component names the rule as core does and each surface maps its own key, since silently reconciling them would make every stored value under one of them wrong. `drawsAnyValidationRule` answers whether it would render anything, so no surface restates which types have no options. Composed by the schema builder's field-editor sheet and `plugin-form-builder`'s `FieldEditor`; graduates per D55 once a third-party plugin composes one.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| Single document read/write                              | `useSingleDocument`, `useUpdateSingleDocument`, `SingleDocument`, `ApiError`, `ValidationIssue`, `isApiError`, `validationIssues`, `apiErrorMessage`, `toastMutationResult`                                                                                                                                                                                                                                                                                                      | New. The same client the admin's own Single form uses, so a plugin that owns a Single does not build a second answer to how that document caches and when it invalidates. The page builder is the first consumer (the Site Style document behind the four style studios); graduates per D55 once that ships in a release. Two contract notes a consumer must know: a write is PARTIAL, so several surfaces owning different fields of one Single can each send only their own; and a refused write REJECTS rather than resolving — the fetcher raises an `ApiError` whose `data` carries `{ errors: [{ path, code, message }] }`, keyed by `path`. Reach that payload with `validationIssues(reason)`, which answers with an empty array for anything that is not a validation failure; the mutation's error is typed `Error` because a request failing before a response exists rejects with the native error and carries no `status`, and `isApiError` is what separates the two. `apiErrorMessage` is the third of the set and the one most surfaces want: a sentence to put in front of a person, assembled from the per-field reasons when there are any and from the top-level message when there are not, with a caller-supplied fallback for a rejection carrying no message at all. Published because rebuilding it is how a plugin comes to show "Validation failed." -- which is true, and silent about which field -- while the admin's own screens show the reasons. `toastMutationResult` is the other half, for the write that COMMITTED and then partly failed: a post-commit hook cannot un-save the row, so the server answers success and carries the failures alongside, and the array holds two different things -- a `failure` is something that did not happen and a `notice` is something the caller should merely know. One message for both reports a successful advisory as a failure and throws away its public text, so the split, the headline and the per-warning detail are published rather than left to be rebuilt. |
+| Media upload (`@nextlyhq/plugin-sdk/admin`)             | `useUploadMedia`                                                                                                                                                                                                                                                                                                                                                                                                                                                                 | New. The one route a plugin has to put bytes on this site, and the same mutation the admin's own dropzone uses. It exists because several things a plugin may author cannot reference a file anywhere else: `validateFontFace` refuses a `src` carrying a scheme or an authority, so a plugin offering a font has to store the file here and point at the id it gets back. `mutateAsync({ file })` resolves to the stored `Media`, whose `mimeType` is the type upload validation SETTLED on rather than the one the browser guessed — that is the value to carry into anything naming a format, since the two disagree for exactly the types a picker cannot identify. The page builder's fonts panel is the first consumer; graduates per D55 once a second one exists. Held experimental for a second reason as well: the return shape is the admin's `Media` record, and which of its fields a plugin may rely on is not yet decided.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
+| Plugin route read (`@nextlyhq/plugin-sdk/admin`)        | `usePluginRoute`, `PluginRouteRead`, `PluginRouteRequest`                                                                                                                                                                                                                                                                                                                                                                                                                        | New. A plugin's admin components reading a route that same plugin contributed. The two halves of a plugin could not reach each other: a plugin may serve an HTTP route and may render admin components, and there was no client for the second to call the first with — measured, the one first-party plugin whose UI needed one contained no `fetch` at all, so an author's choice was to hand-roll the session, its refresh and the error envelope, or to read something else instead. Goes through the same `protectedApi` and TanStack Query the admin's own reads use, so a plugin does not build a second answer to how its data caches and when it invalidates. Three contract notes a consumer must know. The plugin names ITSELF, because there is no ambient plugin identity in the admin — a component is rendered through a registry by string path, so nothing in its React context says which plugin contributed it, which is why `usePluginClientConfig` takes the name too. The path is built from that name through the dispatcher's own `pluginRouteFullPath` (shared via `nextly/config`), so a caller cannot address a namespace the server does not serve — a mistake that does not raise, because a request to a path nothing serves answers with nothing and reads as an empty result. And `pending` is a REAL third state beside the data: `undefined` is both "the route answered nothing" and "the route has not answered", and a surface that cannot separate them draws its empty state over a read in flight. The page builder is the first consumer (the saved-pattern library behind the insert panel); graduates per D55 once that ships in a release.                                                                                                                                                                                                                                                                                                                                                                |
+| Plugin route write (`@nextlyhq/plugin-sdk/admin`)       | `usePluginRouteMutation`, `PluginRouteMethod`, `PluginRouteWrite`, `PluginRouteWriter`                                                                                                                                                                                                                                                                                                                                                                                           | New, and the other half of the read above. A plugin could read its own contributed route and had nothing to write to one with, so any feature that saved something went back to hand-rolling the session, its refresh and the error envelope — the problem the read hook was added to remove, left standing on the other side of the same seam. Goes through the same `protectedApi` and TanStack Query the admin's own writes use. Four contract notes. The plugin names ITSELF, for the reason the read does. `invalidates` names the plugin's own read paths so a write refreshes the list it belongs in — named rather than inferred, because nothing in the admin knows which reads a write affects, and each is resolved through the CALLING plugin's name so one plugin cannot invalidate another's cached reads however it spells a path. `write` RESOLVES on failure rather than rejecting, answering `undefined`, and reports the cause on `error`: a rejecting promise is the idiomatic TanStack shape and a footgun on a surface handed to plugin authors, and this matches the read hook so there is one shape to learn. And nothing is toasted from the hook — the admin's own mutations toast because they own the surface that follows, and a plugin owns its own. The verbs are `Exclude<RouteMethod, "GET">` rather than a second list, so a method added to the route contract cannot leave this unable to call it. Graduates per D55 once a first-party plugin ships a write through it; the page builder's save-as-pattern is the intended first consumer.                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| Plugin identity & classification                        | `PLUGIN_CATEGORIES`, `isPluginCategory`, `pluginAdminSlug`                                                                                                                                                                                                                                                                                                                                                                                                                       | The same implementations the admin routes and filters on, re-exported so a plugin author does not restate them. No first-party plugin consumes them yet; graduates per D55 once one does.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
+| Locale selectors (`@nextlyhq/plugin-sdk`)               | `isLocaleSelector`                                                                                                                                                                                                                                                                                                                                                                                                                                                               | New. Which `locale` values the core reads as instructions rather than languages (`*`, `all`), so a route forwarding `?locale=` into `ctx.services` can treat a wildcard as "no language" without keeping a list that agrees with the core's only until one of them gains an entry; `ServiceOpts.locale` refuses the same spellings with this function. Exercised by `plugin-form-builder`'s submission redirect; graduates per D55 once that ships in a release.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
+| Auth extensibility (D71/D57)                            | `AuthStrategy`, `AuthInput`, `AuthOutcome`, `Challenge`, `ChallengeDefinition`, `AuthHooks`, `AuthHookName`, `contributes.auth`, `auth.strategies`                                                                                                                                                                                                                                                                                                                               | New in M7. The whole surface is unexercised by a first-party plugin; graduates per D55 once one does.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| Role bundles (D67)                                      | `PluginRole`, `contributes.roles`                                                                                                                                                                                                                                                                                                                                                                                                                                                | New in Phase 2. Seeded role bundles; unexercised by a first-party plugin in production — graduates per D55 once one is.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
+| Custom services (D64/D66)                               | `contributes.services`, `ctx.services.plugins.<name>.<svc>`, `nextly.plugins.<name>.<svc>`                                                                                                                                                                                                                                                                                                                                                                                       | Exercised by `plugin-page-builder`, which contributes its block registry through it — a plugin adding blocks resolves that service rather than importing the engine, which is what makes the registration timing safe. The namespace is still typed `unknown` at the call site, so a contributing plugin should export a typed accessor for its own service as the page builder does with `blockRegistry(ctx)`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| Scheduled tasks (D61)                                   | `ScheduledTask`, `contributes.schedules`                                                                                                                                                                                                                                                                                                                                                                                                                                         | **RESERVED, not executed.** Shape published so the gap isn't silent; a real scheduler needs durable jobs (D51). Use external cron + route handlers, or event-driven work, meanwhile.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| Email providers + templates (D65)                       | `contributes.emailProviders`, `contributes.emailTemplates`, `PluginEmailProvider`, `PluginEmailTemplate`, `defineEmailProvider`, `MAX_EMAIL_PROVIDER_TYPE_LENGTH`, `EmailProviderDefinition`, `EmailProviderConfigField`, `EmailProviderCapabilities`, `EmailProviderDescriptor`, `ProviderAvailability`, `RegisteredEmailProvider`                                                                                                                                              | New in Phase 2, widened since. A provider is now a DEFINITION rather than a bare factory: it declares its config fields, which of them are secret, and how to validate them, so the registry can validate at the API boundary and an admin can render a form for a provider core was never compiled against. `PluginEmailProvider` is the erased value `defineEmailProvider()` returns — authors keep their own config type and erasure happens once at registration. A definition may also declare `checkAvailability`, which reports whether the install can run it at all -- distinct from `testConnection`, which asks whether a CONFIGURATION works -- so a provider needing an optional peer dependency is described as needing it rather than offered and failing at send time. Still unexercised by a first-party plugin; graduates per D55 once one ships.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
+| Plugin client config                                    | `contributes.admin.clientConfig`, `usePluginClientConfig`, `JsonObject`, `JsonValue`                                                                                                                                                                                                                                                                                                                                                                                             | A plugin's own configuration, declared on the server where the host builds its config and read in the browser by the plugin's admin components, delivered through `/api/admin-meta`. That endpoint needs no authentication, so the value reaches anonymous callers and must hold nothing secret. Rejected at boot when it does not survive JSON, rather than delivered mangled. `plugin-page-builder` exercises it for `remotePatterns`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| Custom field types (D16/M9a)                            | `contributes.fieldTypes`, `PluginFieldType` (incl. `surfaces`, `label`, `codegen` with `PluginFieldCodegen` / `PluginFieldCodegenImport`, `description`, `icon`, `category`, `validate`), `PluginFieldValidateArgs`, `PluginFieldInstance`, `PluginFieldIssue`, `PluginFieldValidationResult`, `FieldSurface`, `isPluginFieldTypeOnSurface`                                                                                                                                      | Storage primitive + server-side value validation (`validate`) + config-validation acceptance + admin rendering now all land: a plugin type appears in the field pickers (surface-filtered), is accepted by the entry/user/form validators, and renders via its admin component. `plugin-form-builder` exercises the forms surface. Graduates per D55 once a third-party plugin ships one.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
+| Validating values against declarations                  | `validateFieldValues`, `ValidateFieldValuesOptions`, `FieldValueDeclaration`, `FieldValueDeclarationInput`, `ValidationIssue`                                                                                                                                                                                                                                                                                                                                                    | New seam. Core's block props are the only caller; no first-party plugin depends on it yet, so it graduates per D55 once the page builder owns block props.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
+| Route path derivation (`@nextlyhq/plugin-sdk/routing`)  | `slugToStaticParam`                                                                                                                                                                                                                                                                                                                                                                                                                                                              | The content route's single answer to what path a stored slug renders at, so anything emitting a URL for an entry derives it instead of rebuilding the rule — a second opinion names a path the route does not serve. Returns the catch-all segments, or `null` when the route would refuse the slug (reserved path, `.`/`..` segment, or a normalization that changed it). It judges the value Next hands the route, which EXCLUDES the static mount prefix, so a caller mounting a collection under a prefix supplies that itself. `plugin-seo` exercises it for sitemap `<loc>` values, which starts the D55 clock rather than ending it.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| Field-UI kit (`@nextlyhq/plugin-sdk/admin`)             | `FieldTypePicker`, `FieldOptionsEditor`, `withOptionIds`, `FieldOption`, `FieldDefaultValueInput`, `FieldDefaultOption`, `usePluginFieldTypeEntries`, `FieldTypePickerProps`, `FieldOptionsEditorProps`, `FieldDefaultValueInputProps`, `ConditionRow`, `operatorsForType`, `operatorTakesValue`, `ConditionRowProps`, `ConditionSource`, `ConditionSourceOption`, `ConditionValue`, `ConditionOperatorName`, `ConditionRange`                                                   | Controlled, form-library-agnostic field-building components rendered from `nextly/field-catalog`. Each has a narrow, storage-agnostic contract that never exposes admin internals. `plugin-form-builder` composes `FieldTypePicker`, `usePluginFieldTypeEntries`, `FieldOptionsEditor`, and `withOptionIds` (its `FieldEditor`); `FieldDefaultValueInput` awaits a first-party exerciser. `ConditionRow` is composed by both the schema builder's `ConditionBuilder` and `plugin-form-builder`'s `ConditionalLogicEditor`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
+| Control primitives (`@nextlyhq/plugin-sdk/admin`)       | `Button`, `Input`, `Textarea`, `Checkbox`, `Switch`, `Label`, `Select` (+ `SelectContent`, `SelectGroup`, `SelectItem`, `SelectLabel`, `SelectSeparator`, `SelectTrigger`, `SelectValue`), `Dialog` (+ `DialogClose`, `DialogContent`, `DialogDescription`, `DialogFooter`, `DialogHeader`, `DialogTitle`, `DialogTrigger`), `FieldShell`, `FormSection`, `FormActions`, `FieldShellProps`, `FieldShellRenderProps`, `FieldWidth`, `FormSectionProps`, `FormActionsProps`        | The controls a settings form is assembled from. Layout primitives alone left an author with a `Card` and nothing to put inside it, so the documented escalation — layout, then the Layer-2 safelist, then the plugin's own `admin.styles` — sent every plugin needing a button to its last step, which is the one surface the design linter cannot see. Payload, Strapi and Directus all give extension authors the real library; the curated subset was the outlier. Scoped to what an ordinary form cannot be built without rather than the whole set, because exporting a component makes its props public API and a name added later is a smaller event than a name withdrawn. Routed through `@nextlyhq/admin` like every other block here — `plugin-sdk` has no `@nextlyhq/ui` dependency and `ui`'s root barrel carries a `"use client"` banner. Held experimental: no first-party plugin composes a form from these yet, so D55's bar is unmet.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
+| Block authoring (`@nextlyhq/plugin-sdk/blocks`)         | `defineBlock`, `AnyBlockDefinition`, `BlockDefinition`, `BlockRenderArgs`, `BlockRenderResult`, `BlockSupports`, `InferBlockProps`, `PropSchema`, `SupportDefinition`                                                                                                                                                                                                                                                                                                            | The contracts for authoring a block the page builder can render, re-exported from `@nextlyhq/blocks-engine`. A subpath so a plugin unrelated to blocks never pulls the engine into its type graph. The definition shape settles at the end of the engine phase, so a contributed block may need changes until then; the registration side is not here — it is `blockRegistry(ctx)` from `@nextlyhq/plugin-page-builder/blocks`, since the registry belongs to that plugin rather than to core. Graduates per D55 once a third-party plugin ships a block.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
+| Schema traversal                                        | `addressableFields`, `AddressableFieldsOptions`, `AddressableField`, `UnvalidatedAddressableField`                                                                                                                                                                                                                                                                                                                                                                               | New. Flattens presentational groups so a caller can find where a value is actually stored — an unnamed container keeps its children at its own level, a named one keeps them under itself. `descendInto` chooses which containers count as transparent, and that choice has to be made DURING the walk: the result holds the flattened children themselves, so a field reached through an unnamed repeater is the same object as one reached through an unnamed group, and no filter over the returned list can separate them. Held experimental until a first-party plugin consumes it in production and deletes its own walk; core's five call sites do not count toward that bar, since they are the caller it already had.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| Draft/publish eligibility                               | `collectionDraftSplit`, `AuthoredDraftSplitCollection`, `DraftSplitEligibility`, `DraftSplitDisabledReason`                                                                                                                                                                                                                                                                                                                                                                      | New. Answers whether a collection stores a working draft beside its published row — five conditions together, of which `status: true` alone is not one. A plugin storing anything per published/draft cannot work this out and must not guess. Held experimental until a second first-party plugin consumes it. **First consumer present, second still absent.** The page-builder's class-usage save hook now resolves `hasDrafts` through this export - `class-usage-hook.ts` calls the injected `draftSplit` and takes `hasDrafts` from the verdict's `eligible` - so the first half of the bar below is met. Contract tests do not count toward the second-consumer bar: promoting on them would graduate an API that the claimed first plugin never exercised. The bar is met when a SECOND plugin consumes it. `resolvedCollectionDraftSplit` and `ResolvedDraftSplitCollection` are the same question for a Schema Builder collection, whose registry record stores `versions` already resolved and which the authored form therefore cannot answer for; they carry the same experimental status and the same bar. `resolvedCollectionView` projects a registry record onto that input, and is published because it is the only way from the documented producer (`ctx.services.collections.getCollection`, declared to return `Collection`) to the documented consumer without an assertion - `Collection` states no root-level `fields`, `status` or `versions` while the object it returns carries all three.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| Background jobs (R-2)                                   | `defineJob`, `MAX_JOB_SLUG_LENGTH`, `JobContext`, `JobDefinition`, `JobDefinitionInput`, `JobRetryPolicy`, `JobSlug`, `JobInputFor`, `QueueJobArgs`, `QueueJobResult`, and `nextly.jobs.queue`                                                                                                                                                                                                                                                                                   | No first-party PLUGIN has declared a job type yet — the release drain is core's own. `JobSlug` and `JobInputFor` resolve through `GeneratedTypes`, and nothing generates a `jobs` key yet, so a project augments it by hand; that is the part most likely to change.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 
 ## Field-UI kit and field-type surfaces
 
diff --git a/packages/plugin-sdk/src/__snapshots__/plugin-surface.test.ts.snap b/packages/plugin-sdk/src/__snapshots__/plugin-surface.test.ts.snap
index 2349482d1b..2ef3ce947d 100644
--- a/packages/plugin-sdk/src/__snapshots__/plugin-surface.test.ts.snap
+++ b/packages/plugin-sdk/src/__snapshots__/plugin-surface.test.ts.snap
@@ -196,6 +196,7 @@ exports[`plugin-sdk public export surface > \`.\` (index) surface is unchanged 1
   "BeforeOperationArgs (type)",
   "BeforeOperationContext (type)",
   "BeforeOperationHandler (type)",
+  "BulkUpdateEntry (type)",
   "Challenge (type)",
   "ChallengeDefinition (type)",
   "ComponentPath (type)",
@@ -294,11 +295,14 @@ exports[`plugin-sdk public export surface > \`.\` (index) surface is unchanged 1
   "PluginSingleRecord (type)",
   "PluginSinglesResult (type)",
   "PluginSinglesService (type)",
+  "PluginSourceResolver (type)",
+  "PluginWidgetSource (type)",
   "ProviderAvailability (type)",
   "QueryOptions (type)",
   "QuerylessWidgetArchetype (type)",
   "QueueJobArgs (type)",
   "QueueJobResult (type)",
+  "ReadCaller (type)",
   "RegisteredEmailProvider (type)",
   "RequestContext (type)",
   "ResolvedDraftSplitCollection (type)",
@@ -336,7 +340,9 @@ exports[`plugin-sdk public export surface > \`.\` (index) surface is unchanged 1
   "WidgetSourceField (type)",
   "WidgetSourceFieldType (type)",
   "WidgetSourceKind (type)",
+  "WidgetSourceResolver (type)",
   "addressableFields (value)",
+  "callerReadOptions (value)",
   "checkbox (value)",
   "collectionDraftSplit (value)",
   "defineEmailProvider (value)",
diff --git a/packages/plugin-sdk/src/index.ts b/packages/plugin-sdk/src/index.ts
index 07194a4246..bce31cfb05 100644
--- a/packages/plugin-sdk/src/index.ts
+++ b/packages/plugin-sdk/src/index.ts
@@ -247,7 +247,8 @@ export { NextlyError } from "nextly";
 /**
  * Managed data access (D56) — the `ctx.services.collections` surface: rich
  * queries (filters/sort/pagination/relations via QueryOptions), `count`, and
- * `createMany`. Aggregations beyond `count` use the raw `ctx.db` escape hatch
+ * `createMany`, and the batch update `updateMany` takes `BulkUpdateEntry[]`.
+ * Aggregations beyond `count` use the raw `ctx.db` escape hatch
  * (D33), which stays `@experimental`.
  *
  * @public Graduated in P9 — `plugin-form-builder` depends on it
@@ -258,6 +259,7 @@ export type {
   QueryOptions,
   PaginatedResult,
   BatchOperationResult,
+  BulkUpdateEntry,
 } from "nextly";
 
 /**
@@ -534,6 +536,22 @@ export type {
  * Held `@experimental` alongside `PluginAdminWidget`, which is the same feature
  * seen from the contributions side: the widget contract graduates per D55 once a
  * first-party plugin ships one. See STABILITY.md.
+ *
+ * `PluginSourceResolver`, `PluginWidgetSource` and `ReadCaller` are the data
+ * SOURCE contract, which `contributes.widgetSources` names. Inference covers a
+ * resolver written inline inside `definePlugin`; these are what let an author
+ * declare one as a named function instead, which is how a plugin publishing
+ * more than one source ends up written.
+ *
+ * Type a contributed resolver as `PluginSourceResolver`, not
+ * `WidgetSourceResolver`: the latter is core's own two-argument shape and
+ * rejects the `PluginContext` parameter a plugin needs to read any data.
+ *
+ * `callerReadOptions(caller)` turns the caller a resolver is handed into the
+ * `ServiceOpts` a managed read takes. Use it rather than assembling them: the
+ * two identity shapes do not meet without an assertion, and it also carries
+ * the `authenticatedScope` that keeps an API key judged on its OWN stamped
+ * grants instead of the roles of whoever minted it.
  */
 export {
   WIDGET_SIZES,
@@ -567,4 +585,9 @@ export {
   type WidgetSourceKind,
   type WidgetOp,
   type TimeseriesInterval,
+  callerReadOptions,
+  type WidgetSourceResolver,
+  type PluginSourceResolver,
+  type PluginWidgetSource,
+  type ReadCaller,
 } from "nextly";
diff --git a/packages/plugin-sdk/src/widget-source-exports.test-d.ts b/packages/plugin-sdk/src/widget-source-exports.test-d.ts
new file mode 100644
index 0000000000..f62901dbe5
--- /dev/null
+++ b/packages/plugin-sdk/src/widget-source-exports.test-d.ts
@@ -0,0 +1,56 @@
+/**
+ * The data-source contract, typed the way a plugin author writes it.
+ *
+ * The defect this pins is a DX one and it compiles away silently: the SDK
+ * published `WidgetSourceResolver` as the name for "a widget source's
+ * resolver", and that alias is core's own TWO-argument shape. An author
+ * following the export and typing a standalone resolver with it had the
+ * `PluginContext` parameter rejected -- the one parameter through which a
+ * contributed resolver can read any data at all. The contract was reachable
+ * only by writing the function inline and letting inference do it.
+ *
+ * Asserted with `expectTypeOf` rather than `@ts-expect-error`, because a
+ * directive suppresses ANY error on the line beneath it: it would keep passing
+ * if the rejection stopped happening, and keep passing if the line started
+ * failing for an unrelated reason. These assertions are evaluated.
+ */
+
+import { expectTypeOf } from "vitest";
+
+import type {
+  PluginContext,
+  PluginSourceResolver,
+  PluginWidgetSource,
+  ReadCaller,
+  WidgetQuery,
+  WidgetSourceResolver,
+} from "@nextlyhq/plugin-sdk";
+
+// The shape an author writes: the question, who is asking, and the plugin's
+// own context to answer from.
+declare const named: (
+  query: WidgetQuery,
+  caller: ReadCaller,
+  ctx: PluginContext
+) => Promise<{ op: "count"; total: number }>;
+
+// 🔴 The assertion the export exists for. A named resolver taking `ctx` is
+// assignable to the published type, so an author can declare one outside
+// `definePlugin` and hand it to `contributes.widgetSources`.
+expectTypeOf(named).toMatchTypeOf<PluginSourceResolver>();
+expectTypeOf<
+  PluginWidgetSource["resolve"]
+>().toEqualTypeOf<PluginSourceResolver>();
+
+// The context is genuinely the third parameter rather than an optional extra:
+// its absence is what made the contract unusable.
+expectTypeOf<Parameters<PluginSourceResolver>>().toMatchTypeOf<
+  [WidgetQuery, ReadCaller, PluginContext]
+>();
+
+// The two names are NOT interchangeable, which is the whole reason both are
+// published. Core's own shape takes two arguments; a plugin's takes three, so
+// the parameter lists differ and an author reaching for the wrong name finds
+// out at the point of use.
+expectTypeOf<Parameters<WidgetSourceResolver>["length"]>().toEqualTypeOf<2>();
+expectTypeOf<Parameters<PluginSourceResolver>["length"]>().toEqualTypeOf<3>();
diff --git a/scripts/doc-samples-baseline.json b/scripts/doc-samples-baseline.json
index bb4bdd96fd..db40432070 100644
--- a/scripts/doc-samples-baseline.json
+++ b/scripts/doc-samples-baseline.json
@@ -1,8 +1,8 @@
 {
   "coverage": {
     "pages": 70,
-    "samples": 389,
-    "compiled": 245
+    "samples": 391,
+    "compiled": 246
   },
   "samplesPerPage": {
     "docs/admin/branding.mdx": {
@@ -186,8 +186,8 @@
       "compiled": 4
     },
     "docs/plugins/services.mdx": {
-      "samples": 5,
-      "compiled": 0
+      "samples": 7,
+      "compiled": 1
     },
     "docs/plugins/testing.mdx": {
       "samples": 1,
@@ -299,7 +299,8 @@
     "packages/builder/README.md": 1,
     "packages/plugin-seo/README.md": 2,
     "docs/database/mysql.mdx": 3,
-    "docs/guides/isr-caching.mdx": 1
+    "docs/guides/isr-caching.mdx": 1,
+    "docs/plugins/services.mdx": 4
   },
   "findings": {
     "docs/getting-started/quick-start.mdx": {
@@ -374,6 +375,12 @@
       "#4 error TS18004: No value exists in scope for the shorthand property 'data'. Either declare one or provide an initializer.": 1,
       "reader-file #2 error TS2307: Cannot find module '../../../../nextly.config' or its corresponding type declarations.": 1
     },
+    "docs/plugins/services.mdx": {
+      "#5 error TS2304: Cannot find name 'ctx'.": 2,
+      "#5 error TS2304: Cannot find name 'slug'.": 2,
+      "context #4 error TS2304: Cannot find name 'ctx'.": 1,
+      "context #4 error TS2304: Cannot find name 'slug'.": 1
+    },
     "docs/api-reference/direct-api.mdx": {
       "suppressed #36 error TS2322: Type 'unknown' is not assignable to type 'Key | null | undefined'.": 1,
       "suppressed #36 error TS2322: Type 'unknown' is not assignable to type 'ReactNode'.": 1,

From 71e6d9c35a2fa4c4090b440b88710376c0f89614 Mon Sep 17 00:00:00 2001
From: Mobeen Abdullah <mobeenabdullah@gmail.com>
Date: Sun, 13 Sep 2026 01:38:40 +0300
Subject: [PATCH 5/6] fix(nextly): one grants resolver, one required-value
 rule, one registry install

Seven review findings.

The pre-default access view was a SHALLOW copy, so the rules deleted a denied
nested value through a reference the record still shared: the copy protected
the top level and lost the data one level down, which is the failure the copy
exists to prevent. It is a deep copy now, the same `detachData` the read path
uses on anything handed to app code.

The view did not follow the defaults as they were applied, so a function
default reading an earlier default got `undefined` from a document that
visibly held the value. Each applied default is written to the view as well.
The view is threaded only where a caller supplied one: passing the record's own
containers down as a view would write child defaults into the caller's payload,
which the mutation tests pin.

`writeAccessGrants` was a second spelling of `readAccessGrants`. They answer
the same question of the same authority, and a change to how an anonymous
caller or an API key resolves would have landed on one and left the other
judging differently. One `callerAccessGrants` now, used by both.

`missesARequiredChild` decided emptiness with a nullish check while the write
validator treats a whitespace string and an empty array as empty too, so a
group whose required child defaulted to an empty string was invented, stored,
and refused by the next write. Both now ask `isEmptyRequiredValue`.

`attachValidators` did not descend an unnamed group, so a validator the
registry captured by flattening one never reached validation and a value it
should have rejected was accepted. It descends with the same rule the
registration uses.

The field functions were installed inside the schema-registry gate, which has
a supported path where the registry is absent. Access rules, hooks, validators
and defaults silently did not exist whenever it took that path. They are
installed unconditionally now, from the whole config, through the same
`replaceFieldFunctions` the reload uses, so boot and reload agree.

The two changesets this branch carried are one.
---
 .../a-default-cannot-read-a-denied-field.md   | 16 +++++++
 ...ld-group-child-takes-a-function-default.md | 32 -------------
 ...he-promote-gate-judges-the-locked-draft.md | 40 ----------------
 packages/nextly/src/di/register.ts            | 47 +++++++++++--------
 .../services/collection-mutation-service.ts   | 11 +++--
 .../services/single-mutation-service.ts       |  4 +-
 .../singles/services/single-publish-all.ts    |  4 +-
 .../singles/services/single-query-service.ts  | 14 ++++--
 .../__tests__/field-level-registry.test.ts    |  4 +-
 .../nextly/src/shared/lib/entry-validation.ts | 13 +++++
 .../nextly/src/shared/lib/field-defaults.ts   | 15 ++++--
 .../src/shared/lib/field-level-registry.ts    | 43 +++++++++--------
 12 files changed, 113 insertions(+), 130 deletions(-)
 delete mode 100644 .changeset/a-field-group-child-takes-a-function-default.md
 delete mode 100644 .changeset/the-promote-gate-judges-the-locked-draft.md

diff --git a/.changeset/a-default-cannot-read-a-denied-field.md b/.changeset/a-default-cannot-read-a-denied-field.md
index 33c672cbc2..b5ab92bd7b 100644
--- a/.changeset/a-default-cannot-read-a-denied-field.md
+++ b/.changeset/a-default-cannot-read-a-denied-field.md
@@ -36,3 +36,19 @@ An access rule declared inside an unnamed container is captured. The registry ke
 A Single's first read no longer invents an incomplete group. Filling a group for the sake of one defaulted child, while a required sibling has no default and no value, stored a document the next create or update would refuse; that insert runs no validation pass of its own. The group is left absent instead.
 
 The documentation no longer claims a field group's children take their defaults before the entry's hooks. They are written in their own pass afterwards, so the parent's hooks see such a child as absent.
+
+A `defaultValue` written as a function now works on a reusable field group's children. A field group's fields are read from its stored definition on every write, and a function does not survive being stored, so only constants applied there: a function default on a field-group child was silently dropped on every write. Field groups now get the same live-config capture collections and Singles have, so the function form resolves from the config at boot, and it is re-read when the dev server reloads the config. It resolves against the instance being built, so a child may compute from a sibling defaulted before it.
+
+Only the default is wired. The same capture holds a field's `access` rules, hooks and `validate`, and nothing reads those for a field group, so registering them changes nothing about whether they are enforced.
+
+The promote gate judges the draft the write actually commits.
+
+The gate that re-judges a Single's pending change before it is published ran before the write transaction, where it could only judge a copy of the world as it was. It now runs inside that transaction, on the draft the transaction has locked, which closes what a pre-flight check could not: a draft saved by another writer between the check and the commit is now the draft that is judged; a `beforeChange` hook that turns a status-less edit into a publish no longer slips past a check that ran before the hooks; and `publishAllLocales`, which applies every language's snapshot to one row, now judges the combined result rather than each language against its own shared values. Resolving the caller's grants is the one thing that cannot happen inside a transaction, since it queries the pooled connection that transaction holds, so it is resolved beforehand and handed in.
+
+A field rule on a child of a group or a repeater row is enforced. The check copied the snapshot shallowly, so the rules deleted a denied nested value from the copy and the original alike and the comparison then saw an unchanged container. A denied child is now found at its own depth and named at its own path.
+
+A publish is no longer refused over a field nobody touched. The comparison read the live document through a read that expands an upload or a relationship into the document behind it, while the snapshot holds the identifier, so an untouched field of either kind looked like an edit. Both sides now go through one conversion.
+
+A draft older than a newly required field is refused rather than published. The check judged the promoted document as a patch, which skips absent properties by design, so a snapshot written before a field became required reported nothing and published a document that violates the contract.
+
+An API key is judged on the grants stamped on the key, not on the database roles of whoever owns it.
diff --git a/.changeset/a-field-group-child-takes-a-function-default.md b/.changeset/a-field-group-child-takes-a-function-default.md
deleted file mode 100644
index be93854735..0000000000
--- a/.changeset/a-field-group-child-takes-a-function-default.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-"@nextlyhq/adapter-drizzle": patch
-"@nextlyhq/adapter-mysql": patch
-"@nextlyhq/adapter-postgres": patch
-"@nextlyhq/adapter-sqlite": patch
-"@nextlyhq/admin": patch
-"@nextlyhq/admin-css": patch
-"@nextlyhq/blocks-engine": patch
-"@nextlyhq/blocks-react": patch
-"@nextlyhq/builder": patch
-"create-nextly-app": patch
-"@nextlyhq/eslint-config": patch
-"@nextlyhq/eslint-plugin": patch
-"@nextlyhq/module-specifiers": patch
-"nextly": patch
-"@nextlyhq/plugin-form-builder": patch
-"@nextlyhq/plugin-page-builder": patch
-"@nextlyhq/plugin-sdk": patch
-"@nextlyhq/plugin-seo": patch
-"@nextlyhq/prettier-config": patch
-"@nextlyhq/storage-s3": patch
-"@nextlyhq/storage-uploadthing": patch
-"@nextlyhq/storage-vercel-blob": patch
-"@nextlyhq/telemetry": patch
-"@nextlyhq/tsconfig": patch
-"@nextlyhq/ui": patch
-"@nextlyhq/plugin-mcp": patch
----
-
-A `defaultValue` written as a function now works on a reusable field group's children. A field group's fields are read from its stored definition on every write, and a function does not survive being stored, so only constants applied there: a function default on a field-group child was silently dropped on every write. Field groups now get the same live-config capture collections and Singles have, so the function form resolves from the config at boot, and it is re-read when the dev server reloads the config. It resolves against the instance being built, so a child may compute from a sibling defaulted before it.
-
-Only the default is wired. The same capture holds a field's `access` rules, hooks and `validate`, and nothing reads those for a field group, so registering them changes nothing about whether they are enforced.
diff --git a/.changeset/the-promote-gate-judges-the-locked-draft.md b/.changeset/the-promote-gate-judges-the-locked-draft.md
deleted file mode 100644
index d17ec31e90..0000000000
--- a/.changeset/the-promote-gate-judges-the-locked-draft.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-"@nextlyhq/adapter-drizzle": patch
-"@nextlyhq/adapter-mysql": patch
-"@nextlyhq/adapter-postgres": patch
-"@nextlyhq/adapter-sqlite": patch
-"@nextlyhq/admin": patch
-"@nextlyhq/admin-css": patch
-"@nextlyhq/blocks-engine": patch
-"@nextlyhq/blocks-react": patch
-"@nextlyhq/builder": patch
-"create-nextly-app": patch
-"@nextlyhq/eslint-config": patch
-"@nextlyhq/eslint-plugin": patch
-"@nextlyhq/module-specifiers": patch
-"nextly": patch
-"@nextlyhq/plugin-form-builder": patch
-"@nextlyhq/plugin-page-builder": patch
-"@nextlyhq/plugin-sdk": patch
-"@nextlyhq/plugin-seo": patch
-"@nextlyhq/prettier-config": patch
-"@nextlyhq/storage-s3": patch
-"@nextlyhq/storage-uploadthing": patch
-"@nextlyhq/storage-vercel-blob": patch
-"@nextlyhq/telemetry": patch
-"@nextlyhq/tsconfig": patch
-"@nextlyhq/ui": patch
-"@nextlyhq/plugin-mcp": patch
----
-
-The promote gate judges the draft the write actually commits.
-
-The gate that re-judges a Single's pending change before it is published ran before the write transaction, where it could only judge a copy of the world as it was. It now runs inside that transaction, on the draft the transaction has locked, which closes what a pre-flight check could not: a draft saved by another writer between the check and the commit is now the draft that is judged; a `beforeChange` hook that turns a status-less edit into a publish no longer slips past a check that ran before the hooks; and `publishAllLocales`, which applies every language's snapshot to one row, now judges the combined result rather than each language against its own shared values. Resolving the caller's grants is the one thing that cannot happen inside a transaction, since it queries the pooled connection that transaction holds, so it is resolved beforehand and handed in.
-
-A field rule on a child of a group or a repeater row is enforced. The check copied the snapshot shallowly, so the rules deleted a denied nested value from the copy and the original alike and the comparison then saw an unchanged container. A denied child is now found at its own depth and named at its own path.
-
-A publish is no longer refused over a field nobody touched. The comparison read the live document through a read that expands an upload or a relationship into the document behind it, while the snapshot holds the identifier, so an untouched field of either kind looked like an edit. Both sides now go through one conversion.
-
-A draft older than a newly required field is refused rather than published. The check judged the promoted document as a patch, which skips absent properties by design, so a snapshot written before a field became required reported nothing and published a document that violates the contract.
-
-An API key is judged on the grants stamped on the key, not on the database roles of whoever owns it.
diff --git a/packages/nextly/src/di/register.ts b/packages/nextly/src/di/register.ts
index 582289db33..30745a74ba 100644
--- a/packages/nextly/src/di/register.ts
+++ b/packages/nextly/src/di/register.ts
@@ -183,7 +183,7 @@ import type { UserFieldDefinitionService } from "../services/users/user-field-de
 import type { UserService } from "../services/users/user-service";
 import { assertNoLegacyFieldGroupKey } from "../shared/legacy-field-group-key";
 import { assertPluginFieldDeclarations } from "../shared/lib/assert-plugin-field-declarations";
-import { registerFieldFunctions } from "../shared/lib/field-level-registry";
+import { replaceFieldFunctions } from "../shared/lib/field-level-registry";
 import type {
   AdminConfig,
   AuthConfig,
@@ -828,6 +828,32 @@ export async function registerServices(
     }
   }
 
+  // The function-bearing half of the live config, installed the same way a
+  // reload installs it: one replacement built from the whole config.
+  //
+  // Outside the resolver gate above, deliberately. That gate is about runtime
+  // TABLES, and it has a supported failure path where the registry is absent;
+  // registering in there meant a caller's `access` rules, hooks, validators
+  // and function defaults silently did not exist whenever it took that path.
+  // None of this needs a schema registry to be true.
+  replaceFieldFunctions([
+    ...(transformedConfig.collections ?? []).map(entity => ({
+      kind: "collection" as const,
+      slug: (entity as { slug?: string }).slug ?? "",
+      fields: (entity as { fields?: unknown[] }).fields ?? [],
+    })),
+    ...(transformedConfig.singles ?? []).map(entity => ({
+      kind: "single" as const,
+      slug: (entity as { slug?: string }).slug ?? "",
+      fields: (entity as { fields?: unknown[] }).fields ?? [],
+    })),
+    ...(transformedConfig.fieldGroups ?? []).map(entity => ({
+      kind: "fieldGroup" as const,
+      slug: (entity as { slug?: string }).slug ?? "",
+      fields: (entity as { fields?: unknown[] }).fields ?? [],
+    })),
+  ]);
+
   // Finalize the deferred Builder-lane targets now the DB is reachable (P8/D3).
   // Builder/UI entities live in the dynamic_* registry tables (loaded by
   // `loadDynamicTables` above), not in `config`, so their slugs weren't knowable
@@ -1736,11 +1762,6 @@ async function registerConfigTablesInResolver(
       const dbName = (collection as { dbName?: string }).dbName;
       const fields = (collection as { fields?: unknown[] }).fields ?? [];
       if (!slug || !Array.isArray(fields) || fields.length === 0) continue;
-      // Capture function-bearing field configs (validate/access/hooks)
-      // from the LIVE config: the DB-backed registry serializes fields,
-      // which drops functions, so the write/read services resolve them
-      // through the field-level registry instead.
-      registerFieldFunctions("collection", slug, fields);
       const baseTableName = dbName ?? slug.replace(/-/g, "_");
       const tableName = baseTableName.startsWith("dc_")
         ? baseTableName
@@ -1802,8 +1823,6 @@ async function registerConfigTablesInResolver(
       const dbName = (single as { dbName?: string }).dbName;
       const fields = (single as { fields?: unknown[] }).fields ?? [];
       if (!slug || !Array.isArray(fields) || fields.length === 0) continue;
-      // Same live-config capture as the collections branch above.
-      registerFieldFunctions("single", slug, fields);
       const tableName = resolveSingleTableName({ slug, dbName });
       // Why: forward the code-first `status: true` flag for singles too —
       // mirrors the collection branch above. Same Draft/Published runtime
@@ -1825,18 +1844,6 @@ async function registerConfigTablesInResolver(
       );
     }
   }
-
-  // Field groups: no table to resolve here (a field group's own table is
-  // provisioned by the field-group services), only the live config to capture.
-  // Its fields are read from the stored definition on every write, the same
-  // place a collection's are, so a `defaultValue` written as a function is
-  // dropped there and can only come from here.
-  for (const fieldGroup of config.fieldGroups ?? []) {
-    const slug = (fieldGroup as { slug?: string }).slug;
-    const fields = (fieldGroup as { fields?: unknown[] }).fields;
-    if (!slug || !Array.isArray(fields) || fields.length === 0) continue;
-    registerFieldFunctions("fieldGroup", slug, fields);
-  }
 }
 
 function logStorageConfiguration(
diff --git a/packages/nextly/src/domains/collections/services/collection-mutation-service.ts b/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
index bbd4440edb..648cc29da2 100644
--- a/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
+++ b/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
@@ -78,12 +78,13 @@ import {
   rehydrateSystemTimestamps,
   SYSTEM_TIMESTAMP_KEYS,
 } from "../../../shared/lib/case-conversion";
+import { detachData } from "../../../shared/lib/detach";
 import { validateEntryData } from "../../../shared/lib/entry-validation";
 import { applyFieldDefaults } from "../../../shared/lib/field-defaults";
 import {
   applyFieldReadAccess,
   applyFieldWriteAccess,
-  writeAccessGrants,
+  callerAccessGrants,
   attachFieldValidators,
   getFieldFunctions,
   runFieldHooks,
@@ -3099,7 +3100,7 @@ export class CollectionMutationService extends BaseService {
       // One resolver for both write-access passes over this record, so the
       // caller's roles and permissions are read once and both judge with one
       // authority.
-      const writeGrants = writeAccessGrants(
+      const writeGrants = callerAccessGrants(
         params.user,
         params.authenticatedScope
       );
@@ -3119,7 +3120,11 @@ export class CollectionMutationService extends BaseService {
       // `public`), and judging that rule before the defaults exist denies it.
       // Deleting the value then would lose it for good, since the pass that
       // decides correctly runs after the defaults and has nothing left to keep.
-      const readableByDefaults: Record<string, unknown> = { ...seededBody };
+      // A DEEP copy. The rules delete a denied value in place, and a shallow
+      // copy shares every nested group, repeater row and component with the
+      // record: the deletion would land on the record too, which is the data
+      // loss this whole arrangement exists to avoid, one level down.
+      const readableByDefaults = detachData(seededBody);
       await applyFieldWriteAccess({
         kind: "collection",
         slug: params.collectionName,
diff --git a/packages/nextly/src/domains/singles/services/single-mutation-service.ts b/packages/nextly/src/domains/singles/services/single-mutation-service.ts
index 2debb49966..5fc276fc41 100644
--- a/packages/nextly/src/domains/singles/services/single-mutation-service.ts
+++ b/packages/nextly/src/domains/singles/services/single-mutation-service.ts
@@ -59,7 +59,7 @@ import {
   applyFieldWriteAccess,
   attachFieldValidators,
   runFieldHooks,
-  writeAccessGrants,
+  callerAccessGrants,
 } from "../../../shared/lib/field-level-registry";
 import {
   coerceDateFieldsToDate,
@@ -657,7 +657,7 @@ export class SingleMutationService extends BaseService {
       // has locked. The one thing it cannot do there is resolve the caller's
       // grants, which queries the pooled connection the transaction is
       // holding, so that is resolved here and handed in.
-      const promoteGrants = writeAccessGrants(
+      const promoteGrants = callerAccessGrants(
         options.user,
         options.authenticatedScope
       );
diff --git a/packages/nextly/src/domains/singles/services/single-publish-all.ts b/packages/nextly/src/domains/singles/services/single-publish-all.ts
index 17afc99039..603d8f5892 100644
--- a/packages/nextly/src/domains/singles/services/single-publish-all.ts
+++ b/packages/nextly/src/domains/singles/services/single-publish-all.ts
@@ -33,7 +33,7 @@ import type { FieldGroupDataService } from "../../../services/field-groups/field
 import { BaseService } from "../../../shared/base-service";
 import { convertTimestampsToCamelCase } from "../../../shared/lib/case-conversion";
 import {
-  writeAccessGrants,
+  callerAccessGrants,
   type CallerGrants,
 } from "../../../shared/lib/field-level-registry";
 import type { Logger } from "../../../shared/types";
@@ -172,7 +172,7 @@ export class SinglePublishAllService extends BaseService {
       // Resolved here because the gate that uses them runs inside the write
       // transaction, and resolving grants queries the pooled connection that
       // transaction is holding.
-      const promoteGrants = writeAccessGrants(
+      const promoteGrants = callerAccessGrants(
         options.user,
         options.authenticatedScope
       );
diff --git a/packages/nextly/src/domains/singles/services/single-query-service.ts b/packages/nextly/src/domains/singles/services/single-query-service.ts
index 9391368fd6..092fcd488a 100644
--- a/packages/nextly/src/domains/singles/services/single-query-service.ts
+++ b/packages/nextly/src/domains/singles/services/single-query-service.ts
@@ -66,14 +66,17 @@ import type { CollectionsHandler } from "../../../services/collections-handler";
 import type { FieldGroupDataService } from "../../../services/field-groups/field-group-data-service";
 import { BaseService } from "../../../shared/base-service";
 import { convertTimestampsToCamelCase } from "../../../shared/lib/case-conversion";
-import type { ValidatableField } from "../../../shared/lib/entry-validation";
+import {
+  isEmptyRequiredValue,
+  type ValidatableField,
+} from "../../../shared/lib/entry-validation";
 import {
   applyFieldDefaults,
   cloneDefault,
 } from "../../../shared/lib/field-defaults";
 import {
   applyFieldReadAccess,
-  readAccessGrants,
+  callerAccessGrants,
   runFieldHooks,
   type ReadAccessRedactions,
 } from "../../../shared/lib/field-level-registry";
@@ -447,7 +450,10 @@ function missesARequiredChild(
       continue;
     }
     const value = filled[child.name];
-    if (child.required && (value === undefined || value === null)) return true;
+    // The same question the write validator will ask of this document later.
+    // A nullish check calls a whitespace string or an empty array present, so
+    // the group would be stored and the next write would reject it.
+    if (child.required && isEmptyRequiredValue(value)) return true;
     if (value !== undefined && missesARequiredChild(child.fields, value)) {
       return true;
     }
@@ -1140,7 +1146,7 @@ export class SingleQueryService extends BaseService {
         overrideAccess: skipFieldRules,
         // One grants resolver for both passes, so the caller's roles and
         // permissions are read once and both passes judge with one authority.
-        grants: readAccessGrants(fieldAccessUser),
+        grants: callerAccessGrants(fieldAccessUser),
       };
       const sourceRedactions: ReadAccessRedactions = new WeakMap();
       await applyFieldReadAccess(fieldAccess, sourceRedactions);
diff --git a/packages/nextly/src/shared/lib/__tests__/field-level-registry.test.ts b/packages/nextly/src/shared/lib/__tests__/field-level-registry.test.ts
index 61346feeaf..ff47c655a6 100644
--- a/packages/nextly/src/shared/lib/__tests__/field-level-registry.test.ts
+++ b/packages/nextly/src/shared/lib/__tests__/field-level-registry.test.ts
@@ -27,7 +27,7 @@ import {
   attachFieldValidators,
   clearFieldFunctions,
   getFieldFunctions,
-  readAccessGrants,
+  callerAccessGrants,
   type ReadAccessRedactions,
   registerFieldFunctions,
   runFieldHooks,
@@ -138,7 +138,7 @@ describe("field access can ask what the caller is granted", () => {
         },
       },
     ]);
-    const grants = readAccessGrants({ id: "u1" });
+    const grants = callerAccessGrants({ id: "u1" });
     const entry: Record<string, unknown> = { secret: "s" };
     await applyFieldReadAccess({
       kind: "collection",
diff --git a/packages/nextly/src/shared/lib/entry-validation.ts b/packages/nextly/src/shared/lib/entry-validation.ts
index 7e5a3148e1..0800b46c1c 100644
--- a/packages/nextly/src/shared/lib/entry-validation.ts
+++ b/packages/nextly/src/shared/lib/entry-validation.ts
@@ -146,6 +146,19 @@ function requiredIsEnforced(
   return true;
 }
 
+/**
+ * What "no value" means for a required field, in one place.
+ *
+ * Exported because a caller deciding whether a document it assembled would
+ * satisfy the schema has to ask the same question this validator will ask of
+ * it later. A narrower second implementation (a nullish check, say) calls a
+ * whitespace string or an empty array present, stores the document, and the
+ * next write rejects it.
+ */
+export function isEmptyRequiredValue(value: unknown): boolean {
+  return isEmpty(value);
+}
+
 function isEmpty(value: unknown): boolean {
   return (
     value === undefined ||
diff --git a/packages/nextly/src/shared/lib/field-defaults.ts b/packages/nextly/src/shared/lib/field-defaults.ts
index 23becbc6f5..552657d631 100644
--- a/packages/nextly/src/shared/lib/field-defaults.ts
+++ b/packages/nextly/src/shared/lib/field-defaults.ts
@@ -107,11 +107,17 @@ export function applyFieldDefaults(
     if (declared !== undefined && supplied === undefined) {
       // Resolved against the data built so far, so a default may read the
       // values the caller did supply, and earlier defaults in this same pass.
-      data[field.name] = cloneDefault(
+      const filled = cloneDefault(
         typeof declared === "function"
           ? (declared as (d: Record<string, unknown>) => unknown)(readFrom)
           : declared
       );
+      data[field.name] = filled;
+      // The view follows what has been filled, so a later function default
+      // reading an earlier one sees it. Without this the view stays the
+      // pre-default record and a default computed from a defaulted sibling
+      // gets `undefined` from a document that visibly holds the value.
+      if (readFrom !== data) readFrom[field.name] = filled;
     }
 
     if (!field.fields) continue;
@@ -120,9 +126,12 @@ export function applyFieldDefaults(
     // before it runs or a required child fails on an entry the caller could
     // not have satisfied.
     if (field.type === "group") {
-      fillGroup(data, field.name, field.fields, own?.fields, readFrom);
+      // `view`, not `readFrom`: with no explicit view the recursion must
+      // read the copy it fills, or it would write defaults into the caller's
+      // own nested container.
+      fillGroup(data, field.name, field.fields, own?.fields, view);
     } else if (field.type === "repeater") {
-      fillRepeaterRows(data, field.name, field.fields, own?.fields, readFrom);
+      fillRepeaterRows(data, field.name, field.fields, own?.fields, view);
     }
   }
 }
diff --git a/packages/nextly/src/shared/lib/field-level-registry.ts b/packages/nextly/src/shared/lib/field-level-registry.ts
index 65e459df42..360a1c7323 100644
--- a/packages/nextly/src/shared/lib/field-level-registry.ts
+++ b/packages/nextly/src/shared/lib/field-level-registry.ts
@@ -366,7 +366,16 @@ function attachValidators(
   fns: Record<string, FieldFunctions>
 ): ValidatableField[] {
   return fields.map(field => {
-    const entry = field.name ? fns[field.name] : undefined;
+    // An unnamed container holds no entry of its own, and its children are
+    // registered at THIS level because that is where their values are stored.
+    // Descending with the same map is what makes the two agree; returning it
+    // untouched left a validator captured at registration unattached, so a
+    // value it should have rejected was accepted.
+    if (!field.name) {
+      if (!field.fields || !storedAtThisLevel(field)) return field;
+      return { ...field, fields: attachValidators(field.fields, fns) };
+    }
+    const entry = fns[field.name];
     if (!entry) return field;
     const next: ValidatableField = { ...field };
     if (entry.validate) next.validate = entry.validate;
@@ -514,7 +523,7 @@ export async function applyFieldWriteAccess(opts: {
   /**
    * A resolver shared with another pass over the same write, so the caller's
    * roles and permissions are read once and both passes judge with one
-   * authority. Build it with {@link writeAccessGrants}. Omitted, this pass
+   * authority. Build it with {@link callerAccessGrants}. Omitted, this pass
    * builds its own, which is right for a write judged only once.
    */
   grants?: () => Promise<CallerGrants>;
@@ -755,26 +764,16 @@ async function applyReadAccessRec(
 }
 
 /**
- * The caller's grants resolver for a read, to hand to every field-access pass
- * over one document so roles and permissions are read once. Memoised on first
- * use, like the resolver each pass would otherwise build for itself.
- */
-export function readAccessGrants(
-  user: Record<string, unknown> | undefined,
-  authenticatedScope?: AuthenticatedScope
-): () => Promise<CallerGrants> {
-  return grantsResolver(
-    typeof user?.id === "string" ? user.id : undefined,
-    authenticatedScope
-  );
-}
-
-/**
- * The caller's grants resolver for a write, to hand to every field-access pass
- * over one record so roles and permissions are read once. The counterpart to
- * {@link readAccessGrants}, for the write path's two passes.
+ * The caller's grants resolver, to hand to every field-access pass over one
+ * document or record so roles and permissions are read once.
+ *
+ * One function for reads and writes, because they ask the same question of the
+ * same authority. Two constructors of it drifted apart the moment either was
+ * changed: a fix to how an anonymous caller or an API key resolves would land
+ * on one side and leave the other judging by different rules, which is the
+ * shape of an access bug nobody sees until it is exploited.
  */
-export function writeAccessGrants(
+export function callerAccessGrants(
   user: Record<string, unknown> | undefined,
   authenticatedScope?: AuthenticatedScope
 ): () => Promise<CallerGrants> {
@@ -807,7 +806,7 @@ export async function applyFieldReadAccess(
     /**
      * A resolver shared with another pass over the same document, so the two
      * passes read the caller's roles and permissions once and judge with one
-     * authority; see {@link readAccessGrants}.
+     * authority; see {@link callerAccessGrants}.
      */
     grants?: () => Promise<CallerGrants>;
   },

From 19fa55244d728484801df9c2fc81bc1b1c59f83b Mon Sep 17 00:00:00 2001
From: Mobeen Abdullah <mobeenabdullah@gmail.com>
Date: Sun, 13 Sep 2026 02:34:43 +0300
Subject: [PATCH 6/6] fix(nextly): a denied field's own default cannot reach a
 field the caller may write

---
 .../a-default-cannot-read-a-denied-field.md   |  2 +
 ...ot-read-a-denied-field.integration.test.ts | 41 +++++++++++++++++++
 .../services/collection-mutation-service.ts   | 34 ++++++++++++++-
 .../nextly/src/shared/lib/field-defaults.ts   | 24 +++++++++--
 4 files changed, 96 insertions(+), 5 deletions(-)

diff --git a/.changeset/a-default-cannot-read-a-denied-field.md b/.changeset/a-default-cannot-read-a-denied-field.md
index b5ab92bd7b..23c4d63f8b 100644
--- a/.changeset/a-default-cannot-read-a-denied-field.md
+++ b/.changeset/a-default-cannot-read-a-denied-field.md
@@ -29,6 +29,8 @@
 
 A function default cannot read a field the caller may not write. A `defaultValue` written as a function receives the data built so far, and that data still held every value the caller sent, including one a field rule denies them, so a default could read the forbidden value and carry it into a field the caller IS allowed to write: the denied field was stripped and its value persisted anyway, one column across. The rules are now applied to a COPY, and the copy is what the functions read. The record itself is left alone until the pass that decides what is stored, because a rule may depend on a sibling the caller omitted precisely BECAUSE it has a default, and judging that rule before the defaults exist would deny it and lose the value for good.
 
+That copy is now defaulted and judged a second time before the record reads it. A field the caller may not write still takes its own declared default, and the pass that runs before the defaults has no key to judge because nothing supplied one; left in the copy, a later function default read it and carried it into a field the caller CAN write, so the rule was defeated one column across by the field's own default rather than by the caller's input.
+
 A config reload installs the live config's field functions, replacing them wholesale at the point the reload commits. Replacing rather than adding, so an entity the new config no longer declares stops deciding anything: a collection dropped from the config keeps its registry row and its table so an orphan sweep can find them, so it stays addressable. At the commit point rather than when the config is read, so a reload whose DDL succeeds and whose later sync fails does not leave a rule from a config the process refused deciding writes. The field-level registry holds every field's `access` rules, hooks, `validate` and function `defaultValue`, none of which survive being stored, and a reload never went back through service registration: an edit to any of them kept running the version from process start until the dev server was restarted. That is wrong in the direction that matters most for an access rule, since a rule tightened in the config was not the one being enforced. Applied on the same optimistic terms as the field-type registry, and restored by the same undo when a reload is abandoned.
 
 An access rule declared inside an unnamed container is captured. The registry keyed only named entries, so every rule, hook and validator inside an unnamed presentational group was dropped. `defineCollection` refuses a field with no name, but a plugin contributing raw config is checked on its field TYPES and not their names, so the shape reaches the live config.
diff --git a/packages/nextly/src/collections/__tests__/default-cannot-read-a-denied-field.integration.test.ts b/packages/nextly/src/collections/__tests__/default-cannot-read-a-denied-field.integration.test.ts
index b38346a428..e63f428d12 100644
--- a/packages/nextly/src/collections/__tests__/default-cannot-read-a-denied-field.integration.test.ts
+++ b/packages/nextly/src/collections/__tests__/default-cannot-read-a-denied-field.integration.test.ts
@@ -91,6 +91,47 @@ describe("a function default cannot read a field the caller may not write", () =
     expect(row.secret).toBe("system-value");
     expect(row.derived).toBe("saw:system-value");
   });
+  it("hides a denied field's OWN default from a later default", async () => {
+    current = await createTestNextly({
+      collections: [
+        defineCollection({
+          slug: "defaulted",
+          fields: [
+            text({ name: "title" }),
+            // Denied AND defaulted. Nothing the caller sends fills it, so the
+            // pass that runs before the defaults has no key to judge.
+            text({
+              name: "secret",
+              defaultValue: "s3cret",
+              access: { create: () => false },
+            }),
+            text({
+              name: "copy",
+              defaultValue: d => `saw:${String(d.secret)}`,
+            }),
+          ],
+        }),
+      ],
+    });
+    const handler = current.getService<"collectionsHandler">(
+      "collectionsHandler"
+    ) as unknown as CollectionsHandler;
+
+    const created = await handler.createEntry(
+      { collectionName: "defaulted", routeAuthorized: true, user: CALLER },
+      { title: "t" }
+    );
+
+    expect(created.success, JSON.stringify(created)).toBe(true);
+    const row = created.data as Record<string, unknown>;
+    // The denied field takes no value, exactly as when the caller sends one.
+    expect(row.secret ?? null).toBeNull();
+    // And the field the caller MAY write did not become a copy of it. Stored
+    // the other way round, the document would describe a `secret` it does not
+    // hold, and the rule guarding it would be defeated one column across.
+    expect(row.copy).toBe("saw:undefined");
+  });
+
   it("keeps a value whose permission a DEFAULT establishes", async () => {
     current = await createTestNextly({
       collections: [
diff --git a/packages/nextly/src/domains/collections/services/collection-mutation-service.ts b/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
index 31af9e1225..4120f51ad8 100644
--- a/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
+++ b/packages/nextly/src/domains/collections/services/collection-mutation-service.ts
@@ -3125,6 +3125,38 @@ export class CollectionMutationService extends BaseService {
       // record: the deletion would land on the record too, which is the data
       // loss this whole arrangement exists to avoid, one level down.
       const readableByDefaults = detachData(seededBody);
+      const fieldFunctions = getFieldFunctions(
+        "collection",
+        params.collectionName
+      );
+      await applyFieldWriteAccess({
+        kind: "collection",
+        slug: params.collectionName,
+        data: readableByDefaults,
+        operation: "create",
+        user: params.user,
+        authenticatedScope: params.authenticatedScope,
+        overrideAccess: params.overrideAccess,
+        grants: writeGrants,
+      });
+      // The view is defaulted BEFORE it is judged a second time, and both
+      // halves matter.
+      //
+      // Defaulted, because a rule may depend on a sibling the caller omitted
+      // because it has a default, and a view judged without it hides a value
+      // the caller may in fact write.
+      //
+      // Judged again, because a default of its own is a value like any other:
+      // a field the caller may not write still takes its declared default
+      // here, and left in the view a later function default would read it and
+      // carry it into a field they CAN write. The pass below removes the field
+      // it came from and keeps the copy, so the rule is defeated one column
+      // across.
+      //
+      // These fill the view only. The record is filled from it afterwards, so
+      // a default the rules removed here is one the record's own pass will not
+      // put back.
+      applyFieldDefaults(readableByDefaults, fields, fieldFunctions);
       await applyFieldWriteAccess({
         kind: "collection",
         slug: params.collectionName,
@@ -3140,7 +3172,7 @@ export class CollectionMutationService extends BaseService {
       applyFieldDefaults(
         seededBody,
         fields,
-        getFieldFunctions("collection", params.collectionName),
+        fieldFunctions,
         readableByDefaults
       );
 
diff --git a/packages/nextly/src/shared/lib/field-defaults.ts b/packages/nextly/src/shared/lib/field-defaults.ts
index 552657d631..c5e084d9e7 100644
--- a/packages/nextly/src/shared/lib/field-defaults.ts
+++ b/packages/nextly/src/shared/lib/field-defaults.ts
@@ -74,6 +74,11 @@ export function applyFieldDefaults(
    * remove. Filtering the record itself instead would delete the value before
    * the defaults that decide whether it is allowed have run at all.
    *
+   * The view arrives ALREADY DEFAULTED and already judged: its caller fills it
+   * with this same function and then runs the field rules over it, so what it
+   * holds is what this caller may store, defaults included. That is what makes
+   * a default the rules remove from it stay removed here.
+   *
    * Defaults to the record, which is right wherever there is nothing to hide.
    */
   view?: Record<string, unknown>
@@ -114,10 +119,21 @@ export function applyFieldDefaults(
       );
       data[field.name] = filled;
       // The view follows what has been filled, so a later function default
-      // reading an earlier one sees it. Without this the view stays the
-      // pre-default record and a default computed from a defaulted sibling
-      // gets `undefined` from a document that visibly holds the value.
-      if (readFrom !== data) readFrom[field.name] = filled;
+      // reading an earlier one sees the value the record will actually store
+      // rather than `undefined` from a document that visibly holds it.
+      //
+      // Only a key the view still HOLDS is refreshed. The view was defaulted
+      // and judged before this pass, so a default missing from it is one the
+      // rules removed, and writing the record's copy back would hand a later
+      // default a value this caller may not write. It would then be carried
+      // into a field they can, stored there, and survive the access pass that
+      // removes only the field it came from.
+      if (
+        readFrom !== data &&
+        Object.prototype.hasOwnProperty.call(readFrom, field.name)
+      ) {
+        readFrom[field.name] = filled;
+      }
     }
 
     if (!field.fields) continue;