@@ -8,7 +8,7 @@ The Setup catalog for positions and permission sets reads the registry. It is bu
 
 - **The environment scope (`?scope=environment`).** `…/metadata/position` and `…/metadata/permission` with this parameter list every item the registry serves for the type, including the platform's own sets. Without it, the list shows one project package's items, as Studio does. Every link the pages emit keeps the scope: the item links, the create link and the editor's breadcrumb. `ENVIRONMENT_SCOPE_QUERY` is exported for hosts that route their own URLs onto it.
 - **Gated for Setup.** A caller without `manage_metadata` gets no create affordance on the list and a read-only editor, and the page says why. Under `single`, the reason is that the platform administrator defines these items and the caller's organization assigns them. Under a wall, it is that the operator defines them for every organization. The generic editor and the permission-set editor now apply this caller gate wherever they render. The metadata door refuses that caller's save anyway; this states the refusal before the click.
-- **The active switch.** The catalog list has an active column and an active/inactive filter. The switch writes the catalog row's `active` flag through the data door, which is today's behaviour on the Setup object pages. Only `catalog-activation.ts` reads and writes catalog rows, and it is what changes when the server's activation ledger accepts these types. An item with no catalog row shows a dash with the reason.
-- **Holders.** In the environment scope, the permission-set editor shows who holds the set under its definition, and the position editor shows who holds the position. A set's holders are read by name: grants come from the `permission_set` column, and the positions that distribute the set come from the registry's position definitions (`permissionSets`). They are no longer read from `sys_position_permission_set` or `sys_position` rows. A new grant still carries `permission_set_id`, because the server does not accept a grant by name alone yet. A position is assigned by its name.
+- **The active switch.** The catalog list has an active column and an active/inactive filter. The switch writes the catalog row's `active` flag through the data door, as the Setup object pages' Activate and Deactivate actions do. On a framework whose authorization resolver reads deactivation from the activation ledger (objectstack's ADR-0131 stage 1 onward), that flag no longer switches a grant off, so there the switch changes the flag and nothing else until the ledger accepts these types. Only `catalog-activation.ts` reads and writes catalog rows, and it is what moves onto the ledger then. An item with no catalog row shows a dash with the reason.
+- **Holders.** In the environment scope, the permission-set editor shows who holds the set under its definition, and the position editor shows who holds the position. A set's holders are read by name: grants come from the `permission_set` column, and the positions that distribute the set come from the registry's position definitions (`permissionSets`). They are no longer read from `sys_position_permission_set` or `sys_position` rows, so on a framework from before objectstack's ADR-0131 stage 1, where positions declare no `permissionSets`, a set lists no holders through a position. A new grant still carries `permission_set_id`, because the server does not accept a grant by name alone yet. A position is assigned by its name.
 - **The sharing-rule recipient picker lists the `position` registry** through the console's metadata store. It no longer reads `sys_position` rows. Without a metadata store mounted, the `position` kind falls back to the plain text input.
 - **The console's `system/roles`, `system/positions` and `system/permissions`** now go to the catalog list, not to the object pages.
@@ -504,9 +504,12 @@ family for them: it uses the same metadata-admin list and editors at
 The list has an active switch and an active/inactive filter. Both read the
 catalog row's `active` flag through `catalog-activation.ts`, which is the only
 module on these pages that reads or writes a catalog row. They do so until the
-server's activation ledger accepts `permission` and `position`. Capabilities
-are not in this scope yet: `GET /api/v1/meta/capability` serves the
-capabilities that packages declare, but not the platform's own.
+server's activation ledger accepts `permission` and `position`. On a framework
+whose authorization resolver already reads deactivation from that ledger
+(objectstack's ADR-0131 stage 1 onward), the row flag no longer switches a
+grant off, so until the ledger door lands the switch changes the flag and
+nothing else. Capabilities are not in this scope yet: the Capabilities page
+and the capability picker still read `sys_capability` rows.
 
 ### Package-less flows (`/studio/~org/automations`)
 
 
@@ -26,8 +26,8 @@ describe('catalog-activation (objectui#7611)', () => {
   it('offers a switch for permission sets and positions, never for capabilities', () => {
     expect(hasCatalogActivation('permission')).toBe(true);
     expect(hasCatalogActivation('position')).toBe(true);
-    // The capability registry is incomplete (it serves package capabilities
-    // only), so Setup does not list it at all — and has no switch for it.
+    // Capabilities are not in the Setup catalog scope (objectui#7611's
+    // follow-up moves them), and ADR-0126 §3 gives a capability no switch.
     expect(hasCatalogActivation('capability')).toBe(false);
   });
 
 
@@ -10,21 +10,31 @@
  * ("disable + clone", landed machinery that converges later — §8) and
  * pre-charts `position` there: disabling is one `active` bit of
  * deployment-level state in the tenant-less activation ledger
- * `sys_metadata_activation`, written by the enable/disable doors. Measured on
- * objectstack `main` for objectui#7611: the ledger has exactly two write
- * doors, `POST /automation/:name/toggle` and
- * `POST /actions/_activation/:object/:action`, and each fixes its own
- * `metadata_type` (`flow`, `action`), so neither accepts `permission` or
- * `position`; and the authorization resolver still reads the row's flag
- * (`isRowActive`). Until the server opens a ledger door for the two types and
- * moves its consult point onto it, a switch wired to the ledger would flip a
- * bit nothing reads.
+ * `sys_metadata_activation`, written by the enable/disable doors.
  *
- * So the switch keeps TODAY's behaviour: the row's `active` column through
- * the data door, which is exactly what the Setup object pages' Activate and
- * Deactivate actions write (`PATCH /api/v1/data/<object>/<id>` with
- * `{ active }`). The data door decides who may write it — measured: the
- * platform administrator may, an organization administrator is refused.
+ * The two halves of that move land separately on the server, and this seam
+ * sits between them:
+ *
+ *  - **The reader has moved.** From objectstack's ADR-0131 stage 1
+ *    (objectstack#15204) the authorization resolver reads a position's or a
+ *    permission set's deactivation from the ledger only, and reads neither
+ *    catalog row's `active` column. On such a framework the flag this module
+ *    writes no longer switches a grant off (measured for objectui#7611 on a
+ *    stage-1 showcase: a holder's resolved grants were unchanged after the
+ *    switch). On a framework from before stage 1, the resolver reads the row
+ *    flag and the switch takes effect.
+ *  - **The write door has not.** No ledger door accepts `permission` or
+ *    `position` yet: the two that exist, `POST /automation/:name/toggle` and
+ *    `POST /actions/_activation/:object/:action`, each fix their own
+ *    `metadata_type` (`flow`, `action`). The door for these two types is
+ *    objectstack#15204 stage 2c.
+ *
+ * So the switch keeps the behaviour of the Setup object pages' Activate and
+ * Deactivate actions: the row's `active` column through the data door
+ * (`PATCH /api/v1/data/<object>/<id>` with `{ active }`). The data door
+ * decides who may write it — measured: the platform administrator may, an
+ * organization administrator is refused. When the ledger door lands, this
+ * module moves onto it (objectui#7611's follow-up).
  *
  * ## Why this is a seam and not a second list
  *
 
@@ -60,10 +60,12 @@ export function environmentScopeSuffix(search: QueryLike): string {
 /**
  * The catalog types Setup administers through this scope, with the data
  * object that still holds each one's ACTIVE flag (see `catalog-activation.ts`).
- * `capability` is deliberately absent: `GET /api/v1/meta/capability` serves the
- * package-declared capabilities only, not the platform's own (objectui#7611
- * measured 2 of 11 on the showcase), so a Setup page reading it would show
- * less than the page it replaces.
+ * `capability` is absent: the Capabilities page and the capability picker
+ * still read `sys_capability` rows, and moving them onto the registry is
+ * objectui#7611's follow-up. (The registry serves the platform's own
+ * capabilities since objectstack#22669, #15204 stage 6b-1a; before it, it
+ * served the package-declared ones only.) A capability has no switch either
+ * (ADR-0126 §3).
  */
 export const SETUP_CATALOG_TYPES: Readonly<Record<string, { rowObject: string }>> = {
   permission: { rowObject: 'sys_permission_set' },