Setup › Advanced › Signing Keys (JWKS) is a dead nav entry — `sys_jwks` is API-disabled and a `requiredPermissions` gate cannot prune it

[huangyiirene]

Symptom

Setup › Advanced › Signing Keys (JWKS) can never load, for any persona.

sys_jwks declares enable.apiEnabled: false / apiMethods: [], so the list request answers OBJECT_API_DISABLED (404) — and the console masks that as a generic "No identity records" empty state, so the surface reads as "you have no signing keys" rather than "this page cannot work".

Control from the same run: nav_api_keys → sys_api_key rides the same machinery and returns no 4xx, so this is specific to the API-disabled object, not to the nav mechanism.

Root cause

The nav entry is contributed with only a requiredPermissions gate, and a permission gate cannot prune an API-disabled object. The two conditions are independent: every persona passes the permission check (or fails it for unrelated reasons) while the object's own enable.apiEnabled: false makes the destination unreachable regardless. There is no signal on the entry that the server could use to drop it.

Worth deciding as part of the fix: whether the general answer is a requiresObject-style declaration that also consults enable.apiEnabled, or whether an API-disabled object should never be nav-contributable in the first place. Note the sibling defect from the same run (the Account app served whole to a member denied every backing object) is the other half of the same gap — there the entries do use requiresObject and the server still has no pruning signal.

Reproduction

1. Boot the showcase and sign in as admin (the defect is persona-independent; admin is simply the easiest).
2. Navigate to Setup › Advanced › Signing Keys (JWKS).
3. Observe the list request answer OBJECT_API_DISABLED, while the page renders an empty state reading as "No identity records".
4. Control: Setup › Advanced › API Keys (nav_api_keys → sys_api_key) loads normally with no 4xx.

Source

Extracted from the QA run #7514 (builtin-apps-nav-render, framework a86db175, vendored console 09987b68).

Body restored 2026-08-11 after the filing agent overwrote it with a probe string and was interrupted before restoring it; content is unchanged from the source run.

[os-zhuang]

Not dispatched — the card has no body to implement against. domain:metadata seat, recording rather than guessing.

The whole Symptom section reads PROBE-A only. There is no observed behaviour, no root cause, no reproduction, and no control. The title carries a real and specific claim — sys_jwks is API-disabled and a requiredPermissions gate cannot prune it — but a title is not a specification, and the sibling cards extracted from the same sweep (#7529, #7531, #7532, #7534, #7539, #7541) all carry the full structure, so this one reads as a truncated extraction rather than a deliberately terse card.

What would make it dispatchable, drawn from what the title already asserts:

1. The observed symptom — what the nav entry does when clicked (404, empty state, permission error?), and what a user sees.
2. Why a requiredPermissions gate cannot prune it. This is the interesting half and the reason the card is not simply "delete the nav entry". If the entry is pruned by a mechanism that consults something sys_jwks cannot express because it is API-disabled, that mechanism is the actual subject.
3. The reproduction and the source run's evidence — the card cites QA run QA run · platform-core (FULL area) · a86db175 · 2026-08-11 · 3 PASS / 1 PARTIAL / 7 FAIL #7514 (framework a86db175, console 09987b68), so the material presumably exists there.

Left pm:queue and unassigned deliberately: it is supply that needs completing, not work that needs a ruling. Whoever ran #7514 can fill it from the run record faster than a dev could re-derive it, and re-deriving it is precisely how a card gets implemented against a guess at what it meant.

---

Generated by Claude Code

[os-zhuang]

Deferred to a later round by the domain:metadata seat — batch-independence, not priority. Recording it here so a later sweep does not read this card as simply unpicked.

Why deferred: #7531 (System Overview tile labels) is dispatched this round in packages/platform-objects/src/apps/, and its dev is under an explicit ⛔ not to touch setup-nav.contributions.ts — which is this card's primary file. The two serialize; this one rides in the next round.

What is already known, so the next dispatch does not re-derive it: the surface spans two files that must be decided together — packages/platform-objects/src/apps/setup-nav.contributions.ts (the nav entry) and packages/platform-objects/src/identity/sys-jwks.object.ts (the object that is API-disabled and carries a requiredPermission). The nav entry is dead because of the object's state, not because the entry is malformed.

That makes this a fork, not a repair, and it should be dispatched as a ruling rather than "fix the dead link":

• Remove the nav entry — correct if JWKS is not meant to be an operator-facing surface, in which case the entry was aspirational and the honest state is that it does not exist.
• Enable the surface — correct if signing-key inspection is meant to be reachable in Setup, in which case the object's API-disabled state and the requiredPermission are what need to change, and that is a security-surface decision with its own review.

The two produce opposite products, and the card as filed does not settle which. Whoever dispatches it should either rule with a falsifiable premise (e.g. check whether any other declared surface reads sys_jwks, and whether the permission it names is one that exists and is grantable) or escalate — ⛔ but not leave the dev to pick, since "the nav entry is dead" is true under both readings.

---

Generated by Claude Code