@@ -0,0 +1,30 @@
+---
+'@objectstack/plugin-security': minor
+'@objectstack/spec': patch
+'@objectstack/objectql': patch
+'@objectstack/runtime': patch
+'@objectstack/lint': patch
+---
+
+feat(plugin-security): a package's declared capabilities are served by the registry alone — the declared-capability seeder and its collision diagnostic are deleted
+
+Clause-②: no
+
+`SecurityPlugin` no longer seeds a `sys_capability` row for a capability a package declares (`defineCapability` / a stack's `capabilities`). The registry is that capability's one home (ADR-0131 D3): the security catalog read (`createSecurityCatalogReader`), `GET /api/v1/meta/capability` and the anchor predicates' declared-capability context read the declaration there, as they already did. This change does not alter how the platform's curated capabilities are served.
+
+A capability name declared by two packages, or a package declaring a curated platform capability name, is refused at boot by the registry's one-holder rule (`SecurityCatalogNameConflictError`, `422`), which already refused it before the deleted runtime diagnostic could run.
+
+In `@objectstack/spec`, `@objectstack/objectql`, `@objectstack/runtime` and `@objectstack/lint`, the shipped comments and the capability liveness evidence (`liveness/capability.json`) now name the registry instead of the retired declared-capability seeder. Their behaviour is unchanged.
+
+Removed from `@objectstack/plugin-security`'s public exports, with no replacement:
+
+- `CAPABILITY_NAME_COLLISION`
+- `capabilityNameCollisionDiagnostic`
+- `formatCapabilityNameCollisionDiagnostic`
+- `reportCapabilityNameCollisions`
+- `CapabilityNameCollisionDiagnostic` (type)
+
+FROM → TO:
+
+- FROM a package's declared capability materialized as a `managed_by: 'package'` `sys_capability` row at boot → TO the declaration served by the registry, with no row written. Read it with `GET /api/v1/meta/capability/:name` or the security catalog read, not from `sys_capability`.
+- FROM a name collision reported at boot through `reportCapabilityNameCollisions` → TO the same collision refused by the registry's one-holder rule. Delete any import of the five names above; there is nothing to call in their place.
@@ -31,7 +31,7 @@ The user spellings are told to write `current_user`, with the guard for a flow t
   - a `type: 'flow'` action launching the flow on an undeclared object;
   - a `map` node feeding the flow whose `itemObject` is undeclared or absent;
   - a `subflow` or `map` parent that is itself such a flow.
-- **The runtime publish gate:** a flow write there is not judged for unbound roots yet. Its per-write snapshot carries no actions or other flows, so it cannot see those entrances. Every other expression verdict at that door is unchanged.
+- **The runtime publish gate:** a flow write there is not judged for unbound roots, by design (rulings `5791822697` item 3 and `6104584601`). Its per-write snapshot carries no actions or other flows, so it cannot see those entrances. Every other expression verdict at that door is unchanged.
 
 A `$` name has no CEL spelling (`$runId == "x"` does not parse), so the `$` roots stay the text-slot rule's.
 
 
@@ -0,0 +1,13 @@
+---
+'@objectstack/lint': minor
+---
+
+A flow whose `record-*` trigger names no start `config.objectName` is no longer judged for unbound flow CEL roots by `objectstack validate`. With no object named, the record-change trigger registers its hook with no object filter, so it fires on a write to any object, one the stack does not declare included, and hands that row to the run as `record`, its fields flattened beside it. The build door cannot know that record's keys, so it leaves the flow unjudged, as it already does for a record trigger on an object the stack does not declare. The trigger shape itself is not refused.
+
+Clause-②: yes (widening: a flow whose `record-*` trigger names no start `config.objectName` opens, so `validate` no longer reports an unbound flow CEL root there)
+
+**What changes.** On such a flow, `expression-invalid` no longer reports a root the flow does not bind (`user.id`, `foo.bar`, a field name no declared object has). The same flow with a declared `config.objectName` is judged exactly as before.
+
+**The runtime publish gate, by design.** That gate does not judge unbound flow CEL roots on a flow write, and is not going to: who launches a flow and what record it is handed are read from other items of the stack, which makes this a whole-stack judgment that belongs to `objectstack validate`, and the gate's per-write snapshot is not widened to carry flows and actions. The stand-down there is the intended boundary, not a gap waiting on a wider snapshot.
+
+**Who is affected.** Every shipped `record-*` trigger names its object, so no example app changes: `objectstack validate` over `app-crm`, `app-todo`, `app-multi-package` and `app-showcase` reports the same findings before and after.
@@ -17,7 +17,7 @@ Clause-②: no (narrowing)
 
 A start `config.objectName` alone is no entrance: with no `record-*` trigger nothing hands the run a row. A parent's own `record` variable is not handed on either: a child gets its parent's context, not its variables. Everywhere else `record.X` is refused as `expression-invalid`, `error`, with the remedy below.
 
-**Not judged.** The stand-downs of the unbound-root rule are unchanged. At the runtime publish gate this judgment still stands down: its per-write snapshot carries no actions and no other flows, so it cannot see an entrance, and a flow write there is not refused for `record` until that snapshot carries them.
+**Not judged.** The stand-downs of the unbound-root rule are unchanged. At the runtime publish gate this judgment still stands down: its per-write snapshot carries no actions and no other flows, so it cannot see an entrance, and a flow write there is not refused for `record`, by design (rulings `5791822697` item 3 and `6104584601`).
 
 ## FROM → TO
 
 
@@ -0,0 +1,27 @@
+---
+'@objectstack/rest': patch
+---
+
+fix(rest): twenty more REST write routes answer a sandboxed hook's refusal in the hook's own words (#22719)
+
+Clause-②: no
+
+**What was wrong.** When a sandboxed hook refuses a write (`throw new Error('Locked rows cannot be changed here.')`), the error that reaches the route carries the QuickJS debug wrapper on `.message` (`hook 'guard' threw: Error: …`) and the sentence on `.innerMessage`. Twenty write routes built their error answer by hand from `.message`, so they shipped the wrapper, while the other write doors answer the sentence. Sixteen of them also answered the refusal as a server fault (`500`).
+
+**What changes on the wire, for a sandboxed hook's refusal.**
+
+| routes | before | after |
+| --- | --- | --- |
+| `POST /sharing/rules`, `DELETE /sharing/rules/:idOrName`, `POST /sharing/rules/:idOrName/evaluate` | `500 RULE_*_FAILED`, flat `{ code, error }`, the wrapper | `400 VALIDATION_ERROR`, nested `{ success: false, error: { code, message } }`, the sentence |
+| `POST /security/suggested-bindings/:id/confirm` and `/dismiss`, `POST /security/permission-sets/:id/discard-overlay` | `500 SUGGESTION_*_FAILED` / `500 INTERNAL`, the wrapper | `400 VALIDATION_ERROR`, same nested `{ error: { code, message } }` shape, the sentence |
+| the nine `POST /approvals/requests/:id/*` writes (`approve`, `reject`, `recall`, `revise`, `resubmit`, `reassign`, `remind`, `request-info`, `comment`) | `500 APPROVAL_*_FAILED`, flat `{ code, error }`, the wrapper | `400 VALIDATION_ERROR`, nested, the sentence |
+| `POST /packages/publish` | `500 INTERNAL_ERROR`, the wrapper | `400 VALIDATION_ERROR`, the sentence |
+| `POST /datasources/:name/external/tables/:remote/draft` and `/import`, `/external/refresh-catalog`, `/external/validate` | `400 EXTERNAL_DATASOURCE_ERROR` / `400 EXTERNAL_IMPORT_ERROR`, the wrapper | the same status and code, the sentence |
+
+A refusal that declares its own `code` keeps it (an unregistered spelling rides `declaredCode`), a refusal that declares its own `status` is answered at that status, and a `userMessage` the hook set rides the answer, as on every other write door.
+
+**Also moved, on the sharing-rule, suggested-binding and approval routes.** These routes now ask the same classification as the `/data` door before their `500` arm. So a refusal from the service that declares its own `status` (or `statusCode`) and `code`, and that no route-specific arm reads, is answered at that status, in the nested envelope, instead of `500` with the route's own code. The external-datasource routes keep answering every refusal at `400` with their own code, and `POST /packages/publish` already answered a declared status.
+
+**Unchanged.** A plain fault keeps each route's own `500` answer and code. The route-specific refusals (`VALIDATION_FAILED`, `PERMISSION_DENIED`, `RULE_NOT_FOUND`, `SHARING_NOT_ENABLED`, the approval prefixes, the typed security errors) answer exactly as before.
+
+**Upgrading.** A client that reads both envelopes, as `@objectstack/client` does, needs no change. A client of the sharing-rule or approval routes that reads a string `body.error` reads `body.error.message` for these answers.
@@ -195,20 +195,19 @@ export default defineStack({
 });
 ```
 
-At boot `bootstrapDeclaredCapabilities`
-(`packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts`) seeds
-each declaration into `sys_capability` with **`managed_by: 'package'` + `package_id`**
-provenance — idempotent, re-seeded on upgrade, and it **never clobbers**
-admin-authored rows, refuses to hijack a curated platform capability, and refuses
-to write into another package's capability.
+At boot each declaration becomes a registry item owned by its package — the
+capability's one home (ADR-0131 D3). No `sys_capability` row is written for it.
+The registry's one-holder rule refuses a second holder of a name at boot with a
+`422`, so a package can neither take a curated platform capability nor take
+over another package's.
 
 This **replaces the implicit back-door** where a capability existed only as an
 untitled placeholder derived from whatever a permission set happened to reference
 in `systemPermissions[]`. That derivation is retired: a reference with no
 declaration still matches by name at runtime but gets no `sys_capability` row.
-An explicit `defineCapability` takes precedence and — for a derived placeholder
-an older database still holds — **claims** it, upgrading the row to package
-provenance with the authored label/description/scope. This is the ADR-0066 D1
+An explicit `defineCapability` is the attributable form: its label,
+description, scope and owning package live on the registry item, and it gets
+no row either. This is the ADR-0066 D1
 direction: retire the implicit `managed_by`-guessing back-doors in favour of
 explicit, attributable declarations.
 
@@ -557,8 +556,8 @@ The complete, prioritized gap map lives in issue **#2561** (the production
   `sys_capability` row.
   A **package** now DEFINES its own capabilities explicitly via
   [`defineCapability` / `stack.capabilities`](#package-capability-declaration-adr-0066-d1),
-  seeded with `managed_by:'package'` + `package_id` provenance by
-  `bootstrap-declared-capabilities.ts` — replacing the implicit
+  served by the registry with owning-package provenance (no row is written for
+  it) — replacing the implicit
   derive-from-`systemPermissions` back-door (now retired).
   The authoring lint (ADR-0066 ⑨) is also **landed**: `validateCapabilityReferences`
   (`@objectstack/lint`) warns at author time (`os validate` / `os lint`) when a
 
@@ -49,8 +49,8 @@ capability name travels through five stations:
   ② REGISTER         AppPlugin → metadata.registerInMemory('capability', name)
         │                                     (also: **/*.capability.ts files)
         ▼
-  ③ SEED             bootstrapDeclaredCapabilities → sys_capability row
-        │                        managed_by: 'package' + package_id provenance
+  ③ SERVE            registry item (capability kind) → catalog read, /meta door
+        │                 owning-package provenance, one holder per name
         ▼
   ④ GRANT            permission set: systemPermissions: ['export_data']
         │                                       assigned to positions / users
@@ -62,12 +62,13 @@ capability name travels through five stations:
 1. **Declare** — `defineCapability(...)` on the stack's `capabilities` array,
    or a `*.capability.ts` / `*.capability.yml` file the filesystem loader globs.
 2. **Register** — at boot, `AppPlugin` puts each stack-declared capability into
-   the metadata registry under the `capability` kind, so boot seeders and
-   runtime resolvers can list it.
-3. **Seed** — `bootstrapDeclaredCapabilities` (in `@objectstack/plugin-security`)
-   reads them back and upserts each one into `sys_capability` with
-   `managed_by: 'package'` and `package_id` provenance. This is what makes the
-   capability *attributable* and package uninstall well-defined.
+   the metadata registry under the `capability` kind, so the security catalog
+   and runtime resolvers can list it.
+3. **Serve** — the registry is the capability's one home. It records the
+   owning package as provenance, which is what makes the capability
+   *attributable*. The security catalog read and
+   `GET /api/v1/meta/capability/:name` answer its definition. No
+   `sys_capability` row is written for it.
 4. **Grant** — an administrator (or a permission set your package ships) lists
    the name in [`systemPermissions`](/docs/permissions/permission-metadata#system-permissions).
 5. **Check** — a resource lists the name in `requiredPermissions`, and the
@@ -157,7 +158,8 @@ plain names. Three consequences worth internalising before you pick one:
 
 You cannot take a platform name. A declaration whose `name` collides with a
 curated platform capability (`manage_users`, `manage_metadata`,
-`setup.access`, …) is refused loudly at boot — those are platform-owned.
+`setup.access`, …) is refused at boot by the registry's one-holder rule
+(`422`) — those are platform-owned, and the platform declares them itself.
 
 ## "Or" is one capability, granted twice
 
@@ -193,36 +195,29 @@ the same way; a user who may edit the object still reads all of its list views,
 so a save of what they loaded keeps them.
 </Callout>
 
-## What the seeder does, and what it refuses
+## One holder per name
 
-`bootstrapDeclaredCapabilities` runs on `kernel:ready` and is idempotent: it
-re-seeds on every boot, so the row always reflects the shipped declaration. Four
-outcomes are refusals rather than writes, and each one leaves the capability
-behaving differently:
+Each capability name has exactly one holder in the registry. When a package
+registers a declaration, the registry records that package as its owner.
+Package uninstall then removes it with the rest of the package. Two cases are
+refused at boot, with a `422` that names the name and both holders:
 
 | Situation | Outcome |
 |:--|:--|
-| No resolvable owning package (`_packageId` and `packageId` both absent) | **Refused — no row is written.** The declaration is inert |
-| Name collides with a curated platform capability | Refused; the platform keeps its own definition |
-| A row already exists owned by a **different** package | Skipped loudly; a package never writes into a foreign record |
-| A row was authored by an administrator (`managed_by: 'admin'`) | Never clobbered |
-
-A pre-existing `managed_by: 'platform'` row for a *non-curated* name is a
-different case: that is the untitled placeholder the old implicit back-door
-derived from whatever a permission set happened to reference, and an explicit
-declaration **claims** it — upgrading the row to package provenance with your
-authored label, description and scope. The provenance and composition rules
-behind that behaviour are set out in
-[Package capability declaration](/docs/permissions/authorization#package-capability-declaration-adr-0066-d1).
+| The name is a curated platform capability | Refused; the platform holds its own definition |
+| Another installed package already declares the name | Refused; a package never takes over another package's capability |
+
+Declaring a capability writes no `sys_capability` row. Its label, description,
+scope and provenance live on the registry item, and that is what the catalog
+read and the metadata door serve.
 
 <Callout type="info">
-**The `sys_capability` row is a catalogue, not a gate.** It carries the label,
-the scope and the provenance that make a capability reviewable, attributable and
-uninstallable — but no authorization check reads it. Permission-set grants and
-resource `requiredPermissions` match capability names **as strings**; the only
-production reader of the table is the declared-capability boot seeder. The row's `active`
-flag is a catalogue/visibility flag with no authorization effect: clearing it
-revokes nothing. Withdraw a capability by withdrawing the **grant**.
+**No authorization check reads a `sys_capability` row.** Permission-set grants
+and resource `requiredPermissions` match capability names **as strings**. The
+boot writes no row for a capability, declared or curated: both are served by
+the registry. A row an older database still holds is a catalogue only, and
+clearing its `active` flag revokes nothing. Withdraw a capability by
+withdrawing the **grant**.
 </Callout>
 
 ## `capability` is code-only
@@ -267,7 +262,7 @@ to store arbitrary JSON on the authorization surface.
 - [ ] `label` and `description` are written for the administrator who will grant it in Setup
 - [ ] `scope` is `org` unless the privilege really is platform-wide
 - [ ] The declaration is reachable from the stack (`capabilities: [...]`) or a `*.capability.ts` file
-- [ ] The package resolves an owning package id — otherwise the seeder writes no row
+- [ ] No other installed package declares the same name — the registry refuses a second holder at boot
 - [ ] Something actually **requires** the name (`requiredPermissions`), and something **grants** it (`systemPermissions`)
 
 ## See also
 
@@ -150,9 +150,9 @@ the anchor decides *which* unit `unit*` means.
 - **Capabilities** are named privileges such as `manage_users`,
   `manage_metadata`, `setup.access`, `studio.access`. The platform's curated
   ones are declared `capability` metadata served by the registry
-  (`GET /api/v1/meta/capability`) and have no `sys_capability` row; a
-  capability a package declares with `defineCapability` is also seeded as a
-  `sys_capability` row.
+  (`GET /api/v1/meta/capability`); a capability a package declares with
+  `defineCapability` is served the same way, under its owning package. Neither
+  has a `sys_capability` row.
   Grant them via `systemPermissions`; declare them as prerequisites via an
   object/field/app `requiredPermissions` (an **AND**-gate checked before any
   CRUD grant).