@@ -169,7 +169,8 @@ export const MetadataTypeSchema = lazySchema(() => z.enum([
   // `declared ≠ enforced` that #5271 closed for `api`. `PLURAL_TO_SINGULAR`
   // has mapped `capabilities` → `capability` since #5870, `AppPlugin`
   // registers stack-declared capabilities under that exact name, and
-  // `bootstrapDeclaredCapabilities` reads them back — but the kind was absent
+  // the declared-capability seeder (since retired, ADR-0131 D3) read them back —
+  // but the kind was absent
   // from this enum, from `BUILTIN_METADATA_TYPE_SCHEMAS` and from
   // `DEFAULT_METADATA_TYPE_REGISTRY`, so it resolved no schema and
   // `PUT /api/v1/meta/capability/:name` stored ANY JSON on an authorization
@@ -1134,9 +1135,9 @@ export const DEFAULT_METADATA_TYPE_REGISTRY: MetadataTypeRegistryEntryParsed[] =
   //
   // The package-declaration channel is untouched: `AppPlugin` registers stack
   // `capabilities[]` through `registerInMemory`, and the filesystem loader
-  // globs `filePatterns` — neither goes through `saveMetaItem`, so
-  // `bootstrapDeclaredCapabilities` still seeds `sys_capability` exactly as
-  // before. `OS_METADATA_WRITABLE=capability` remains the ONE documented
+  // globs `filePatterns` — neither goes through `saveMetaItem`, so a package's
+  // declarations still reach the registry, their one home (ADR-0131 D3).
+  // `OS_METADATA_WRITABLE=capability` remains the ONE documented
   // operator escape hatch (ADR-0005), and behind it the write is now judged by
   // `CapabilityDeclarationSchema` (422) instead of being stored unvalidated.
   //
 
@@ -169,8 +169,8 @@ const BUILTIN_METADATA_TYPE_SCHEMAS: Partial<Record<MetadataType, z.ZodType>> =
   // authorization capabilities (ADR-0066 D1). The kind was produced and read
   // back long before it resolved a schema: `PLURAL_TO_SINGULAR` maps
   // `capabilities` → `capability` (#5870), `AppPlugin` registers stack-declared
-  // ones under that name, and `bootstrapDeclaredCapabilities` reads them back to
-  // seed `sys_capability`. Yet `getMetadataTypeSchema('capability')` answered
+  // ones under that name, and the declared-capability seeder (since retired,
+  // ADR-0131 D3) read them back to seed `sys_capability`. Yet `getMetadataTypeSchema('capability')` answered
   // `undefined`, so `saveMetaItem` took its documented "unregistered type →
   // store without validation" branch and `PUT /meta/capability/:name` accepted
   // ANY JSON — on an AUTHORIZATION surface, where `systemPermissions` /
 
@@ -76,8 +76,8 @@ export const PLURAL_TO_SINGULAR: Record<string, string> = {
   positions: 'position',
   permissions: 'permission',
   // [ADR-0066 D1, #5870] Package-declared authorization capabilities. The
-  // singular form is what `bootstrapDeclaredCapabilities` reads back
-  // (`readDeclared(ql, 'capability')`) and what `AppPlugin` already registers
+  // singular form is what the registry and the security catalog read back
+  // (`listItems('capability')`) and what `AppPlugin` already registers
   // under; without the mapping the registration seam stored them as
   // `'capabilities'`, a store nothing reads.
   capabilities: 'capability',
 
@@ -93,9 +93,8 @@ export const PLATFORM_CAPABILITY_NAMES: ReadonlySet<string> = new Set(
  * capability of its own — the counterpart, on the declaration side, of the
  * curated {@link PLATFORM_CAPABILITIES}. Authored via {@link defineCapability}
  * and collected on a stack's `capabilities` array, these declarations flow
- * EXPLICITLY into the `sys_capability` registry at boot with `managed_by:
- * 'package'` + `package_id` provenance (seeded by
- * `@objectstack/plugin-security`'s `bootstrapDeclaredCapabilities`).
+ * EXPLICITLY into the registry at boot under their owning package (ADR-0131
+ * D3); no `sys_capability` row is written for them.
  *
  * This replaces the old implicit "derive an untitled capability from whatever a
  * permission set happens to reference in `systemPermissions[]`" back-door: a
@@ -127,8 +126,8 @@ export const PLATFORM_CAPABILITY_NAMES: ReadonlySet<string> = new Set(
  *  - **The shape is `.strict()`.** Unlike `api` (which is on that suite's
  *    `STILL_STRIP` list because `ApiEndpointSchema` doubles as the parser for
  *    STORED rows carrying `packageId` / `state`), nothing re-parses a stored
- *    `sys_capability` row through this schema — `bootstrapDeclaredCapabilities`
- *    reads named fields off the body (`capabilityRowFields`). So closing it
+ *    `sys_capability` row through this schema — no row is written for a
+ *    declared capability (ADR-0131 D3). So closing it
  *    costs nothing and buys the declared = enforced posture an AUTHORIZATION
  *    surface should have had from the start.
  */
 
@@ -31,23 +31,16 @@ function coerceRecord(v: unknown): Record<string, unknown> | undefined {
  * The predicates are pure and synchronous — they read one permission-set
  * definition and nothing else — so the one fact they cannot discover for
  * themselves is which capability names this stack DECLARED. The caller holds
- * it: at boot from the stack's own `capabilities:` DECLARATIONS — and from
- * the `sys_capability` rows carrying `managed_by: 'package'` provenance only
- * ONCE THE SEEDER HAS WRITTEN THEM — at authoring time from the stack's own
- * `capabilities` array.
+ * it: at boot from the stack's own `capabilities:` DECLARATIONS in the
+ * registry, at authoring time from the stack's own `capabilities` array.
  *
- * ⚠️ [#18603] Why the boot half names the DECLARATIONS and not the rows: the
- * ADR-0090 D5 anchor binding (`bindBaselineToEveryone` in
- * `@objectstack/plugin-security`) runs BEFORE `bootstrapDeclaredCapabilities`,
- * the seeder that WRITES those `managed_by: 'package'` rows, and that order is
- * fixed by two other constraints — the binding must follow the seeding of the
- * `everyone` anchor it binds to, and precede the audience-binding suggestion
- * reconciliation. On a first boot the table is therefore EMPTY at the bind
- * moment, and "omission refuses" below turns that emptiness into a silent
- * refusal of every declared token. A boot caller reads the declarations
- * through the seeder's own two-step — the ObjectQL registry first, the
- * metadata service as the fallback — as `readDeclaredCapabilityContext`
- * (`@objectstack/plugin-security`) does.
+ * ⚠️ [#18603] Why the boot half names the DECLARATIONS and not the rows: no
+ * `sys_capability` row is written for a declared capability — the registry is
+ * its one home (ADR-0131 D3) — so a row read would find nothing, and
+ * "omission refuses" below would turn that emptiness into a silent refusal of
+ * every declared token. A boot caller reads the declarations from the ObjectQL
+ * registry first, the metadata service as the fallback, as
+ * `readDeclaredCapabilityContext` (`@objectstack/plugin-security`) does.
  *
  * ⛔ Never synthesize this from the set under test. The point of the input is
  * that a set cannot vouch for its own tokens; a "declared" list derived from