@@ -0,0 +1,24 @@
+---
+'@objectstack/plugin-security': minor
+---
+
+feat(plugin-security)!: the boot writes no `sys_permission_set` row — the declared-permission seeder and the platform-default materialization are deleted
+
+Clause-②: yes (narrowing)
+
+<!-- adr-0087: not-required (no-migration-prescription) A runtime change on a platform object's rows and on TypeScript surfaces, not on any metadata schema: no key of any spec schema is removed, renamed or re-shaped, so there is nothing for `objectstack migrate meta` to rewrite and no tombstone. The rows the retired seeders wrote stay in the table until a later ADR-0131 stage; nothing reads them for authorization. The package publishes (not unpublished); no ADR-0087 id covers this rule and this diff adds none (not registered / already-registered). -->
+
+**BREAKING**, shipped as `minor` under the repo's launch-window convention for breaking changes.
+
+`SecurityPlugin` no longer writes a `sys_permission_set` row for any permission set: not for the platform defaults (`admin_full_access`, `member_default`, …), not for a set a package declares, not for an organization's copy, and not on a package-door publish, a metadata reload or an organization's creation. Permission sets are served by the security catalog (ADR-0131 D3), and since the grant names its set (`sys_user_permission_set.permission_set`), no grant path needs a row. A fresh database still promotes its first platform administrator, grants organization administrators and self-registered members, and grants every principal what it was granted before. On a database that was already seeded, the existing rows stay as they are; they are no longer refreshed at boot.
+
+- **Accepted package defaults follow every publish.** The `everyone` anchor is derived again after every landed `permission` mutation (publish, direct save or delete, through any door), so an accepted set whose new body no longer qualifies stops granting at once. Before this release the re-derivation ran only inside the publish materializer, and only when the published body carried an `isDefault` key.
+- **`drift_status` and `drift_detail` are gone from `sys_permission_set`**, with the **Needs Attention** list view that listed them. Nothing computes them any more: the declared-versus-enforced diagnostic retired with the rows it compared. A Studio overlay that shadows a packaged set is still named at boot.
+- `bootstrapPlatformAdmin` no longer takes the `resync` option and no longer reports `seeded`, `resynced` or `resyncSkipped`. A refused read of the legacy `admin_full_access` row (the restrict-only reach to a grant written before the name column existed) withholds the promotion and says so once.
+
+Removed from `@objectstack/plugin-security`'s public exports, with no replacement:
+
+- `bootstrapDeclaredPermissions`
+- `normalizeManagedByVocab`
+- `computePermissionSetDriftDiagnostics`, `persistPermissionSetDriftDiagnostics`, `runPermissionSetDriftDiagnostics`, and the types `PermissionSetDriftStatus`, `PermissionSetDriftDiagnostic`, `DriftDiagnosticsOptions`
+- `CAPABILITY_DECLARATION_UNOWNED`, `CAPABILITY_PLATFORM_NAME_REFUSED`, `PERMISSION_SET_DECLARATION_UNOWNED`, `capabilityDeclarationUnownedDiagnostic`, `capabilityPlatformNameRefusedDiagnostic`, `permissionSetDeclarationUnownedDiagnostic`, `reportCapabilityDeclarationUnowned`, `reportCapabilityPlatformNameRefused`, `reportPermissionSetDeclarationUnowned`, and the types `CapabilityDeclarationUnownedDiagnostic`, `CapabilityPlatformNameRefusedDiagnostic`, `PermissionSetDeclarationUnownedDiagnostic`
@@ -0,0 +1,46 @@
+---
+'@objectstack/plugin-security': minor
+'@objectstack/platform-objects': minor
+'@objectstack/spec': minor
+'@objectstack/core': minor
+'@objectstack/metadata-protocol': minor
+'@objectstack/cloud-connection': patch
+'@objectstack/objectql': patch
+'@objectstack/plugin-sharing': patch
+'@objectstack/lint': patch
+'@objectstack/service-settings': patch
+---
+
+feat(plugin-security)!: the four security-catalog row objects are retired — `sys_position`, `sys_permission_set`, `sys_position_permission_set` and `sys_capability` (ADR-0131 D3)
+
+Clause-②: yes (narrowing)
+
+<!-- adr-0087: registered catalog-row-objects-retired -->
+
+**BREAKING**, shipped as `minor` under the repo's launch-window convention for breaking changes.
+
+Positions, permission sets and capabilities live in the security catalog — the environment registry, fed by package declarations and by environment metadata saved through `/api/v1/meta` (ADR-0131 D3). The four row objects that mirrored them are no longer registered, so their data and REST routes and their Setup object pages are gone. No table is dropped and no row is deleted.
+
+FROM → TO:
+
+- `GET|POST|PATCH|DELETE /api/v1/data/sys_permission_set` → `GET|PUT|DELETE /api/v1/meta/permission/:name`; to copy a set, `POST /api/v1/security/permission-sets/:name/clone` with `{ name, label }`.
+- `… /api/v1/data/sys_position` → `/api/v1/meta/position/:name`. A position's permission sets are its definition's `permissionSets`.
+- `… /api/v1/data/sys_position_permission_set` → the position definition's `permissionSets` (`PUT /api/v1/meta/position/:name`).
+- `… /api/v1/data/sys_capability` → read-only `GET /api/v1/meta/capability`; a package declares a capability with `defineCapability` (`stack.capabilities`).
+- Setup → Access Control → Positions / Capabilities / Permission Sets now open Setup's catalog lists (`/apps/setup/metadata/<type>?scope=environment`) instead of the object pages; the `sys_position` record page (`SysPositionDetailPage`) is removed.
+- An object permission on one of the four names in a permission set grants nothing and can be deleted.
+
+What else changes:
+
+- `sys_user_permission_set.permission_set_id` is a plain text column now, not a lookup: same column, same stored ids, same indexes. It is not written and grants nothing; a grant names its set by `permission_set`.
+- A permission set saved through the metadata door is written to no row: the `permission` mutation projector, the `sys_permission_set` and `sys_position` data-door write-throughs and the row-only position backfill are no longer registered.
+- On a fresh `single`-posture database the first human is promoted to platform administrator without reading any catalog row. An unscoped grant written before `sys_user_permission_set.permission_set` existed (it names no set) still withholds the promotion until the organization-ownership migration names it.
+- Uninstalling a package revokes every grant naming a permission set the package declared. The uninstalling door reads those names off the package before withdrawing it and hands them to each uninstall cleanup as `declared` (`UninstallCleanup`, `@objectstack/metadata-protocol`; `declaredCatalogItemsOf` is exported).
+- `capability-reference-unknown` no longer counts a `sys_capability` seed row as a declared capability — no runtime reader consults one. Declare the capability with `defineCapability`.
+
+Removed exports, no replacement:
+
+- `@objectstack/plugin-security`: the object definitions `SysPosition`, `SysPermissionSet`, `SysPositionPermissionSet`, `SysCapability` (from `./objects`); `securityObjects` lists the remaining three.
+- `@objectstack/platform-objects/pages`: `SysPositionDetailPage`.
+- `@objectstack/spec`: `SystemObjectName.POSITION`, `SystemObjectName.PERMISSION_SET`; the four names leave `PLATFORM_OBJECTS_BY_PACKAGE['plugin-security']` and `PLATFORM_PROVIDED_OBJECT_NAMES`.
+- `@objectstack/core`: `isRowActive` and `ActivatableRow` — a catalog row's `active` column decides nothing; deactivation is the activation ledger's (`sys_metadata_activation`).
@@ -152,13 +152,11 @@ them, and treat "sensitive field on a public object" as a review smell.
 The metadata↔config boundary follows one line: **definitions travel with the
 package (metadata); subject bindings and env-specific values stay as config.**
 
-- A package ships **its own permission sets** (Shape B), recorded with
-  `managedBy: 'package'` + owning `packageId` on `sys_permission_set`
-  (`package_id` / `managed_by` columns). `bootstrapDeclaredPermissions`
-  (`packages/plugins/plugin-security/src/bootstrap-declared-permissions.ts`)
-  seeds `stack.permissions` at boot — idempotent, re-seeded on upgrade, and it
-  **never clobbers** env-authored (`platform`/`user`/legacy) rows. A package
-  never writes into a foreign record.
+- A package ships **its own permission sets** (Shape B): its
+  `stack.permissions` are registry items stamped with the owning package
+  (`_packageId`), served by name from the security catalog (ADR-0131 D3). The
+  boot writes no `sys_permission_set` row for them, and a package never
+  writes into a foreign definition.
 - The environment admin **assigns** sets to positions/users; the runtime unions
   them. One shared set with hand-picked cross-package grants remains an
   env-admin-only construct.
 
@@ -161,8 +161,9 @@ the anchor decides *which* unit `unit*` means.
 
 ## Built-in permission sets
 
-Auto-seeded on boot by `plugin-security`
-(`objects/default-permission-sets.ts`):
+Declared by `plugin-security` on its own manifest
+(`objects/default-permission-sets.ts`) and served from the security catalog —
+the boot writes no row for them:
 
 | Name | Scope | What it unlocks | Notes |
 |:--|:--|:--|:--|
@@ -337,9 +338,10 @@ tenant-level.
 
 ## Provenance — package vs environment sets (ADR-0086)
 
-A package ships its own sets (`managedBy: 'package'` + `packageId`), seeded
-idempotently at boot and re-seeded on upgrade; environment-authored sets
-(`platform`/`user`) are never clobbered. The data layer refuses forging package
+A package ships its own sets as registry items stamped with the owning package
+(`packageId`), served from the security catalog — the boot writes no row for
+them, and an upgrade is served as soon as the package registers its new
+version; environment-authored sets are never clobbered. The data layer refuses forging package
 provenance through the admin door (two-doors separation, evolved by ADR-0094 —
 an edit of a set shipped in code is refused; clone it instead, see below), which
 is what makes package uninstall well-defined — and enforced: uninstalling a
@@ -423,47 +425,21 @@ it was copied from, so changes to the source never reach the copy.
 
 ### Declared ≠ enforced — diagnosing a frozen package set
 
-A package-declared set's *enforced* grants (what `sys_permission_set` stores
-and what the evaluator resolves) can diverge from its shipped *artifact*
-(what the package currently declares) through two independent mechanisms —
-either can be live on one row, and they need different remedies:
+A package-declared set's *enforced* grants (what the security catalog serves
+and the evaluator resolves) can diverge from its shipped *artifact* (what the
+package currently declares) in one way:
 
 - **Overlay shadow.** An active `sys_metadata` overlay for the set's name
   (from a Studio save made while overlaying was still permitted, or through
-  the `OS_METADATA_WRITABLE` escape hatch) is re-projected onto the record on
-  every boot, unconditionally — the overlay wins forever, regardless of what
-  the package ships next. No door creates such an overlay any more: the
-  metadata door refuses a save over a packaged set, and so does the data door
-  (clone the set instead). **Remedy:** delete the overlay row. From the
-  release that adds ADR-0048's cold-boot check, a deployment that still holds
-  one does not boot: `os migrate security-catalog-overlays` lists every such
-  row with no server running, and `--apply` deletes them, after which the
-  package's definition is served again.
-- **Provenance skip.** The record's `managed_by` column predates package
-  provenance tracking (a legacy insert without `managed_by: 'package'` —
-  typically a database first initialized on an older release line), so boot
-  seeding treats it as environment-authored and never reconciles it with the
-  package — permanently. There is currently no automated adoption path for
-  this case (boot-time auto-adoption and a bulk `os meta
-  adopt-permission-sets` command were both deliberately deferred as migration
-  machinery for a customer population that does not yet exist — see the
-  discussion on the tracking issue for this section). The manual recovery is
-  the same one-time SQL a field remediation used, run against the
-  environment's database with a backup first:
-
-  ```sql
-  UPDATE sys_permission_set
-  SET managed_by = 'package', package_id = '<owning package id>'
-  WHERE name = '<permission set name>';
-  ```
-
-  Restart the environment afterward so boot seeding re-adopts the row as
-  package-owned and reconciles its grants to the shipped artifact.
-
-Both mechanisms are surfaced on the record itself: `drift_status`
-(`'overlay_shadow'` / `'provenance_skip'`) and `drift_detail` name the cause,
-recomputed every boot, and the **Needs Attention** list view collects every
-currently drifted set — an in-sync set is never listed there.
+  the `OS_METADATA_WRITABLE` escape hatch) answers ahead of the package's
+  definition — the overlay wins forever, regardless of what the package ships
+  next. No door creates such an overlay any more: the metadata door refuses a
+  save over a packaged set, and so does the data door (clone the set instead).
+  The boot names every such set in its log. **Remedy:** delete the overlay
+  row. From the release that adds ADR-0048's cold-boot check, a deployment
+  that still holds one does not boot: `os migrate security-catalog-overlays`
+  lists every such row with no server running, and `--apply` deletes them,
+  after which the package's definition is served again.
 
 ---
 
 
@@ -83,7 +83,7 @@ what moved this page's population from 225 to 227; nothing about the two sites
 changed, only whether this instrument could see them.
 
 **The expensive failure direction is a keyword.** Sites whose receiver the author
-typed `any` have no type to read, and there are 44 of them — just under a fifth
+typed `any` have no type to read, and there are 42 of them — just under a fifth
 of the population, concentrated in exactly the seed and bootstrap paths this
 control exists for. Scoring an unreadable receiver as "not an engine" would have
 dropped every one of them silently, with a clean exit and a smaller number that
@@ -122,7 +122,7 @@ are reported as `undecidable` rather than assumed either way.
 
 The same holds twice over for the context. An options argument spelled as a
 literal can be read; one spelled `options`, `{ ...opts }`, or handed through a
-forwarding shim cannot, and **53 of the 227 sites are spelled that way**. A
+forwarding shim cannot, and **53 of the 225 sites are spelled that way**. A
 context resolved from an inline literal or a local `const` can be tested for
 `isSystem`; one arriving from a helper call cannot.
 
@@ -187,10 +187,10 @@ reproduce them. Where it disagrees, it disagrees on the page:
 
 | carried figure | where it survives | this census |
 | :--- | :--- | ---: |
-| 175 write call sites | quoted in the merged changeset | **227** |
+| 175 write call sites | quoted in the merged changeset | **225** |
 | 24 carrying no tenant context | quoted in the merged changeset | **2** provable and tenancy-enabled; **32** more whose options argument is unreadable |
-| 127 of 175 statically decidable, 48 runtime-parameter-name sites | restated on the `isSystem`-scoping card | **155 of 227** decidable, **72** undecidable |
-| 135 (77%) silenced by the `isSystem` guard before the posture gate | the lost issue body — **no surviving corroboration** | **not reproduced**: 122 decidably elevated, 0 decidably not, 97 undecidable |
+| 127 of 175 statically decidable, 48 runtime-parameter-name sites | restated on the `isSystem`-scoping card | **155 of 225** decidable, **70** undecidable |
+| 135 (77%) silenced by the `isSystem` guard before the posture gate | the lost issue body — **no surviving corroboration** | **not reproduced**: 120 decidably elevated, 0 decidably not, 97 undecidable |
 | 141 and 132, two independent re-derivations | the card that filed this work | — |
 
 **The differences are not reconciled, and deliberately so.** The old census's
@@ -200,18 +200,18 @@ be stated is what this instrument counts, which is written above and re-runnable
 at any commit.
 
 Two structural facts do plausibly widen this reading against any hand or regex
-one, and both are counted in the generated tables below: the 44 sites reached
+one, and both are counted in the generated tables below: the 42 sites reached
 through an erased (`any`) receiver, and the 52 that name their object through a
 `const` rather than inline. An instrument that read either the way a person does
 would report a smaller number and would not say so.
 
 The fourth row is the one worth flagging to anyone citing it. **The 135 / 77%
 figure has no surviving corroboration anywhere in the tree.** This census reads
-122 of 227 (54%) as decidably elevated, with 97 more whose elevation is a
+120 of 225 (53%) as decidably elevated, with 97 more whose elevation is a
 run-time fact — so the claim is neither confirmed nor refuted, and the honest
 answer is that a static reading cannot settle it.
 
-⇒ **Cite `2 / 227`, and say what it is**: the sites whose options argument was
+⇒ **Cite `2 / 225`, and say what it is**: the sites whose options argument was
 READ and holds no tenant context, against a decidably tenancy-enabled object.
 That is the control's provable yield surface. ⛔ Do not cite it as "the sites
 without tenant context" — **32 further sites** have an options argument this
@@ -223,30 +223,30 @@ cannot read, and they are neither in nor out.
 
 | what | count |
 | :--- | ---: |
-| write call sites on the application surface | **227** |
+| write call sites on the application surface | **225** |
 | …whose object name is statically decidable | 155 |
-| …whose object name is chosen at run time | 72 |
-| …against an object with tenancy ENABLED | 154 |
+| …whose object name is chosen at run time | 70 |
+| …against an object with tenancy ENABLED | 151 |
 | …against an object that declares tenancy off | 1 |
-| threading a tenant context | 166 |
+| threading a tenant context | 164 |
 | PROVABLY carrying none (options read, no context key) | **8** |
 | …of those, against a decidably tenancy-enabled object | **2** |
 | options argument UNREADABLE — may or may not carry one | 53 |
 | …of those, against a decidably tenancy-enabled object | 32 |
-| threading a decidably ELEVATED (`isSystem`) context | 122 |
+| threading a decidably ELEVATED (`isSystem`) context | 120 |
 | threading a context that is decidably NOT elevated | 0 |
 | threading a context whose elevation is a run-time fact | 97 |
 
 | how the instrument reached the site | count |
 | :--- | ---: |
 | receiver carried a readable engine type | 183 |
-| receiver erased, placed by the object NAME | 30 |
-| receiver erased, placed by an `object: string` PARAMETER | 9 |
-| receiver erased, placed by an `UNTYPED_RECEIVERS` row | 5 |
+| receiver erased, placed by the object NAME | 27 |
+| receiver erased, placed by an `object: string` PARAMETER | 7 |
+| receiver erased, placed by an `UNTYPED_RECEIVERS` row | 8 |
 
 | object name spelled inline | 103 |
 | object name spelled through a `const` | 52 |
-| object name is an `object: string` parameter | 11 |
+| object name is an `object: string` parameter | 9 |
 | object name is some other run-time expression | 61 |
 
 ### Subtractions the census could NOT defend — enforced
@@ -297,13 +297,13 @@ holds still. They are required to be HERE and to say WHEN they were true;
 their values are not compared. The reasoning, and the measurement behind it,
 are in `scripts/check-tenant-audit-census.mjs`.
 
-Measured on 2026-10-11 at `be55432f6`.
+Measured on 2026-10-12 at `c9ef4fbce`.
 
 | corpus scale (not enforced) | count |
 | :--- | ---: |
-| tracked non-test sources scanned | 632 |
-| engine-shaped types recognised | 72 |
-| declared objects in the registry | 117 |
+| tracked non-test sources scanned | 624 |
+| engine-shaped types recognised | 71 |
+| declared objects in the registry | 113 |
 | same-named calls subtracted as non-engine | 161 |
 
 {/* END GENERATED: tenant-audit-census */}