`sys_capability.active` is read by nothing — the Deactivate action tells the admin grants stop resolving, and they do not

[os-zhuang]

Found while implementing #8470, which required establishing whether any runtime path resolves a sys_capability row (as opposed to the bare capability name string). The answer is no — and that answer has a consequence beyond #8470.

The claim the product makes

sys-capability.object.ts ships a deactivate_capability record action whose confirmation dialog reads, verbatim:

Deactivate this capability? Grants and resource requirements that reference it stop resolving until re-activated.

The active field is also surfaced in all three list views and in highlightFields, so deactivation presents as a first-class administrative control.

What actually happens

Nothing reads it. Measured on origin/main at 30f1b7488d:

• The AND-gate that enforces requiredPermissions compares string sets. PermissionEvaluator.getSystemPermissions() unions permissionSets[].systemPermissions (strings); normalizeRequiredPermissions reads the resource's own declared strings. Neither loads a row.
• A repo-wide search for row reads of the object — find/findOne/count/aggregate against 'sys_capability', plus every consumer of the platform-object-names entry — returns exactly two production call sites, both seeders: bootstrap-system-capabilities.ts and bootstrap-declared-capabilities.ts. Both read name, managed_by, package_id. Neither reads active, and neither is on an authorization path.
• validateCapabilityReferences (the authoring lint) resolves against PLATFORM_CAPABILITY_NAMES, stack declarations and seed-data records — the spec constant and the config, never the table.

So active: false changes no authorization decision, no lint verdict, and no runtime resolution. It changes a column value and a badge in Setup.

Why this is worth a card rather than a shrug

The direction of the falsehood is the bad one. An admin who wants to withdraw a capability is offered a control that states, in a confirmation dialog, that withdrawing it takes effect — and the withdrawal silently does not happen. That is a security-relevant misstatement about a security surface even though it is not itself a privilege escalation: the escalation is what the admin believes they prevented.

This is also an ADR-0049 enforce-or-remove shape: a declared field with a declared meaning and no enforcement.

The two directions, not a recommendation

I am deliberately not choosing here, because the choice is a contract decision:

1. Enforce it — capability resolution consults the row and an inactive capability stops satisfying requiredPermissions. This makes the registry load-bearing on the authorization hot path, which is a real architectural change (every gate needs the row, with the caching and fail-closed questions that implies) and it gives an org-authored row influence over a platform capability unless the ownership scoping from bootstrapSystemCapabilities reconciles an arbitrary row when a curated capability name exists in more than one organization — find(..., limit: 1) has no ORDER BY, so the platform's own row can be left unseeded #8470 is carried through.
2. Remove the claim — drop the action and the field, or reword the dialog to say what deactivation actually does (a catalogue/visibility flag). Cheapest, and honest.

Filed unassigned. Related to #8470, which fixes a different defect in the same seeder and does not touch this.

---

Generated by Claude Code

[hotlong]

Triage → needs-user-decision + security + domain:metadata (likeliest landing: sys-capability.object.ts in packages/platform-objects; the enforce option would instead land across the authz gates). Type: Bug — a shipped confirmation dialog declares behaviour ("grants … stop resolving") that no code path enforces: declared ≠ enforced.

Human floor, not auto-adjudicable: security/permission boundary, and the cheap option removes a published capability — both are hard floors regardless of prism alignment.

Premises (re-check before ruling):

• No reader of active: git grep -n "'sys_capability'" origin/main -- packages → two seeders only, neither on an authz path (filer measured on 30f1b7488d).
• Dialog text still ships: git grep -n "stop resolving" origin/main -- packages/platform-objects.
• bootstrapSystemCapabilities reconciles an arbitrary row when a curated capability name exists in more than one organization — find(..., limit: 1) has no ORDER BY, so the platform's own row can be left unseeded #8470 (same seeder, different defect) is in flight — re-check its landed shape before implementing either direction.

Question: enforce sys_capability.active on the authorization path, or remove/reword the Deactivate claim?

Options:

• A — Enforce. Capability resolution consults the row; an inactive capability stops satisfying requiredPermissions. Makes the registry load-bearing on the authz hot path — caching, fail-closed semantics, and org-authored-row influence over platform capabilities (needs bootstrapSystemCapabilities reconciles an arbitrary row when a curated capability name exists in more than one organization — find(..., limit: 1) has no ORDER BY, so the platform's own row can be left unseeded #8470's ownership scoping carried through) all become live questions.
• B — Remove/reword the claim. Drop the deactivate_capability action + active field, or reword dialog/field to what it is (a catalogue/visibility flag). Honest and cheap; authz stays string-set based.

Four prisms:

1. Platform long-term coherence: B shrinks a false surface; A adds a second authorization source of truth alongside string sets — a real architecture change that deserves its own ADR if ever wanted, not a bug-fix rider.
2. Measured business pull: zero — nothing reads active, and the failure is silent by construction, so no one has hit it. Pull for A is speculative capability-lifecycle management.
3. AI-agent error-resistance: today's shape is the canonical trap — a declared control the runtime does not honour. B restores declared = enforced by deleting the declaration; A restores it by building enforcement. Both beat the status quo; B is structurally harder to get wrong.
4. Startup scope discipline: B removes; A is declare-and-maintain on the hottest path in the system.

Recommendation: B — remove the action and the active field (or reword to an explicit catalogue flag if Setup wants the badge), per ADR-0049 enforce-or-remove. If enforcement is ever wanted, it arrives as its own ADR with the fail-closed/caching questions answered, on top of #8470's ownership scoping.

Dependency note: finding #8536's re-grade is gated on this ruling (its unseeded-platform-bucket severity flips with the direction chosen).

---

Generated by Claude Code

[hotlong]

Maintainer ruling recorded — option B: remove the false claim (ADR-0049 enforce-or-remove). Provenance: maintainer live session, 2026-08-13 ~23:50Z, verbatim 「接受你的全部建议」, accepting this seat's four-prism briefing of the full decision box (this card's briefed recommendation was B).

The ruling, spelled out for dispatch:

1. Withdraw the Deactivate action's promise. Default implementation shape: reword the confirmation dialog and field semantics to what active actually is today (a catalogue/visibility flag with no authorization effect), and demote it from highlightFields/list-view prominence accordingly. Full removal of the action + field is the alternative shape — if the lane prefers it, it goes through the spec-property-retirement playbook (ADR-0049/0087 discipline), not an ad-hoc delete.
2. Option 1 (enforce) is rejected for now: putting the registry on the authorization hot path is an architectural change (caching, fail-closed, org-authored rows influencing platform capabilities) that must arrive as a designed feature with its own card if capability lifecycle management ever earns real pull — not as a side effect of wiring up one field.
3. Either shape must leave no surface claiming deactivation affects grant resolution — dialog text, field description, and generated reference pages all checked at fix time.

Label transition: needs-user-decision → pm:queue. Type Bug stands (a published claim contradicting enforced behaviour).

Consequence for #8536: its first named re-grade trigger (this ruling) has fired — re-graded in a separate comment there.

Recorded by the triage seat on the maintainer's direct channel.

---

Generated by Claude Code