@@ -2219,7 +2219,7 @@
         "on that surface, INVOKE showcase_zoo_perm_held (requires showcase.export_data) as the GRANTED member holding OpsPermissionSet, then as a NON-granted member: granted executes, non-granted is refused with the actionPermissionError text naming the action and the missing capability",
         "REGRANT leg: showcase_ops is sealed (PUT /api/v1/meta/permission/showcase_ops → 403 NOT_OVERRIDABLE), so clone it (fixtures.requires[1]) and grant the CLONE to a fresh member through a sys_user_permission_set row; invoke showcase_zoo_perm_held as that member → executes; withdraw showcase.export_data from the CLONE's systemPermissions (PUT /api/v1/meta/permission/<clone> with the read-back item minus that entry), re-invoke → refused; restore it, re-invoke → executes again",
         "invoke showcase_zoo_perm_missing (requires showcase.restricted_ops, granted to nobody) as EVERY persona incl. the OpsPermissionSet holder → refused for all; and showcase_zoo_perm_empty (requiredPermissions:[]) → executes for all, since 'declares nothing' is not 'denies everything'",
-        "author a scratch package declaring a capability whose name is in PLATFORM_CAPABILITY_NAMES; boot/validate. The runtime door is closed to the same attempt: PUT /api/v1/meta/capability/<a platform name> answers 403 NOT_OVERRIDABLE (capability is a code-only type)",
+        "author a scratch package declaring a capability whose name is in PLATFORM_CAPABILITY_NAMES and BOOT it: os validate and os build both pass the declaration (the name is lexically valid), and the refusal is the registry's one-holder check at boot, which stops the process. The runtime door is closed to the same attempt: PUT /api/v1/meta/capability/<a platform name> answers 403 NOT_OVERRIDABLE (capability is a code-only type)",
         "the capability write doors validate before anything reaches the authorization namespace (the #5961 concern): author a scratch capability with a malformed shape (e.g. scope 'galaxy') in source and run os validate — refused at parse; the runtime metadata door refuses the type outright, PUT /api/v1/meta/capability/<new name> → 403 NOT_CREATABLE (capability is allowRuntimeCreate:false and allowEnvironmentOverlay:false, packages/spec/src/kernel/metadata-plugin.zod.ts); and there is no sys_capability table to upsert into (step 1's 404)"
       ],
       "acceptance": [
@@ -2284,7 +2284,7 @@
           "ref": "claude/issue-7680-package-capability-doctrine"
         },
         { "revision": 3, "date": "2026-08-18", "change": "named the specimens' object correctly: showcase_field_zoo, not `zoo`. The fixture block quoted the local TS const from predicate-matrix.action.ts (const zoo = 'showcase_field_zoo'), so an invoke keyed on `zoo` answers 'Action ... not found on object zoo' — which reads like a missing specimen rather than a wrong object name (#9453 CF-6)", "ref": "#9386" },
-        { "revision": 4, "date": "2026-10-16", "change": "re-pointed against main c91af8ed6 (#23878 checklist-accuracy findings, #23879 out_of_scope_findings). (1) sys_capability is retired (GET /api/v1/data/sys_capability → 404 OBJECT_NOT_FOUND), so the title, step 1, clause 1 and the old steps 7-8 no longer describe a sys_capability row or upsert; clause 4 now states the doors that exist: source parsed by os validate, the runtime metadata door refusing the code-only type (403 NOT_CREATABLE), and no table. (2) The dispatcher /actions domain IS mounted on the stock dev server and enforces actionPermissionError (measured: held 200 for the ops holder, 403 PERMISSION_DENIED naming the missing capability for a plain member; missing and and refused, empty executes), so step 3 and the knownGap name it as the surface; /api/v1/data/:object/:id/actions/... stays the routing 404. (3) showcase_ops is sealed (PUT → 403 NOT_OVERRIDABLE, ADR-0126), so the REGRANT leg withdraws and restores the capability on a clone made through POST /api/v1/security/permission-sets/showcase_ops/clone (label mandatory); measured 200 → 403 → 200. The clause still fails if a non-holder executes, a withdrawn grant keeps executing or a holder is refused", "ref": "#24036" }
+        { "revision": 4, "date": "2026-10-16", "change": "re-pointed against main c91af8ed6 (#23878 checklist-accuracy findings, #23879 out_of_scope_findings). (1) sys_capability is retired (GET /api/v1/data/sys_capability → 404 OBJECT_NOT_FOUND), so the title, step 1, clause 1 and the old steps 7-8 no longer describe a sys_capability row or upsert; clause 4 now states the doors that exist: source parsed by os validate, the runtime metadata door refusing the code-only type (403 NOT_CREATABLE), and no table. (2) The dispatcher /actions domain IS mounted on the stock dev server and enforces actionPermissionError (measured: held 200 for the ops holder, 403 PERMISSION_DENIED naming the missing capability for a plain member; missing and and refused, empty executes), so step 3 and the knownGap name it as the surface; /api/v1/data/:object/:id/actions/... stays the routing 404. (3) showcase_ops is sealed (PUT → 403 NOT_OVERRIDABLE, ADR-0126), so the REGRANT leg withdraws and restores the capability on a clone made through POST /api/v1/security/permission-sets/showcase_ops/clone (label mandatory); measured 200 → 403 → 200. The clause still fails if a non-holder executes, a withdrawn grant keeps executing or a holder is refused. The build-oracle clauses re-run on a minimal scratch stack: a capability with scope 'galaxy' → os validate exit 1 \"capabilities.0.scope: Invalid value 'galaxy'. Expected one of: platform, org.\"; a capability named manage_platform_settings → os validate and os build exit 0, and os dev refused to boot with '✗ Security catalog name conflict: package \"com.qa.caps\" cannot register a name another holder already holds — capability \"manage_platform_settings\" is already held by the platform …' (step 6 now says the refusal is at boot); the runtime door answered both a platform name and the malformed body 403 (sealed / code-only type)", "ref": "#24036" }
       ]
     },
     {