The other ~40 `[Security] Access denied` sentences are still English-only developer copy shown verbatim to end users (same class as #7414, one template fixed)

[os-zhuang]

Found while implementing #7414 (PR #7449). That card measured and fixed one template — the object-CRUD grant denial in packages/plugins/plugin-security/src/security-plugin.ts — because that is the one the reporter hit. The same defect is present across the rest of the family, and a 40-template sweep is a different review from a one-template copy fix, so it is filed rather than smuggled into that PR.

The defect class

Every one of these composes an English developer sentence into Error.message, and Error.message is the body's human-readable string on both transports (mapDataError's body.error, the dispatcher's error.message), which Console renders verbatim in a toast. So each is English-only in an otherwise localized UI, and most name API object names, position names, permission-set names or ADR clause numbers.

Census at 2ef18070e (grep -rc "\[Security\] Access denied" --include=*.ts packages/), producers only — the counts below exclude the matcher/doc occurrences in plugin-security/src/errors.ts (1), rest/src/rest-server.ts (3) and runtime/src/security/resolve-execution-context.ts (1), which are startsWith fallbacks and comments rather than thrown copy:

File	Producer templates
plugins/plugin-security/src/security-plugin.ts	19 total, 18 remaining (1 converted by PR #7449; that file's 20th hit is the new developerMessage, which is correctly developer-facing)
plugins/plugin-security/src/delegated-admin-gate.ts	13
plugins/plugin-security/src/suggested-audience-bindings.ts	3
plugins/plugin-auth/src/invitation-role-cap.ts	3
plugins/plugin-security/src/permission-set-projection.ts	1
plugins/plugin-security/src/system-write-guard.ts	1
plugins/plugin-security/src/predicate-guard.ts	1

The ones an ordinary business user is most likely to meet are the row-level write denial

[Security] Access denied: not permitted to delete this 'crm_opportunity' record (row-level security)

and the capability AND-gate

[Security] Access denied: 'crm_contract' (operation 'delete') requires capability [manage_x] -- caller is missing [manage_x]

The delegated-admin and package-managed-metadata sentences are admin-surface copy; those are arguably correctly developer-facing, which is part of what makes this a triage question rather than a mechanical sweep.

Why it is not just "apply the same patch 40 times"

PR #7449 established the shape: render the user's half through the shared operation-message catalog (packages/spec/src/system/operation-message.ts, addressed under the errors. key prefix), keep the previous sentence byte for byte as developerMessage, and log it rather than ship it (the 403 body carries no structured API names, so shipping it would add a disclosure — see #7450). Applying that needs three decisions per site that a sweep cannot make mechanically:

1. Audience. A delegated-admin refusal is read by an administrator using an admin console; an RLS row denial is read by a salesperson. Only the second needs the catalog treatment. Localizing admin-surface copy that cites ADR clauses would lose the citation without helping anyone.
2. How many sentences. The catalog's rule is one wire code, several message keys. Does the whole family share errors.permission_denied, or do the row-level and capability denials get their own keys? A user blocked by row-level security is in a genuinely different situation from one whose profile lacks the object bit.
3. Anything named. PR fix(plugin-security,spec): PERMISSION_DENIED stops showing developer copy to end users (#7414) #7449's sentence names nothing because the gate cannot distinguish the object the user acted on from a cascade child. Other sites may be able to, and would give better copy by naming a label.

Suggested route

Triage into a small number of grouped cards along the audience split (end-user gates vs. admin-surface gates), rather than one card per template. The mechanism, the tests to copy and the disclosure reasoning are all in PR #7449.

Blocked-by: #7449

---

Generated by Claude Code

[claude]

Triage: pm:blocked + domain:identity, body line Blocked-by: #7449 appended.

Classification rationale — concrete, in-scope defect family (English-only developer copy rendered verbatim to end users) with a named census and an established fix shape, so it is queue-class work, but the mechanism it must copy — the operation-message-catalog treatment, the developerMessage preservation, the tests, and the disclosure reasoning — lives in PR #7449, which is open, not merged (verified via REST at triage time: state: open, merged: false; developerMessage has zero hits in security-plugin.ts on origin/main @ 8a9c079). Dispatching before #7449 lands would both collide with it in security-plugin.ts and force the dev to invent the pattern the PR is establishing. pm:blocked puts it on the unlock sweep's reverse index; on #7449's merge, re-verify the census at the merged ref and it becomes dispatchable.

Premise verified on origin/main @ 8a9c079 — census re-run (git grep -c "[Security] Access denied"): security-plugin.ts 20, delegated-admin-gate.ts 13, suggested-audience-bindings.ts 3, invitation-role-cap.ts 3, permission-set-projection.ts 1, system-write-guard.ts 1, predicate-guard.ts 1, plus the matcher/doc occurrences the card correctly excludes (errors.ts 1, rest-server.ts 3, resolve-execution-context.ts 1). Matches the card's table (its 2ef18070e census was the PR head; main differs only by #7449's not-yet-landed conversion).

Routing — every producer file is packages/plugins/plugin-security or plugin-auth ⇒ domain:identity (lane table), same lane as parent card #7414. The card's suggested audience split (end-user gates vs admin-surface gates) is claim-time scoping for the lane — if the seat wants two grouped cards, that split should happen at claim with the census as the worklist; it does not change routing.

Grading — no target:v17: display-class copy, same grading as #7307 / #7414.

Dedup — #7414 is the one-template parent (in flight); #7307 is the engine-side DELETE_RESTRICTED sibling (disjoint package); #4426 is authorable flow/workflow label translations (different surface). No duplicate for the sweep remainder.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Unblocked — pm:blocked → pm:queue (identity-lane PM seat, unlock sweep; domain:identity preserved untouched, it is the triage seat's).

Blocked-by: #7449 is satisfied: PR #7449 merged 2026-08-10T14:18:09Z (squash b61afc13f) and #7414 closed completed at 14:18:10Z. This card is now dispatchable.

What that PR left you, so this card is scoped against reality rather than against the census:

• The shared mechanism is in place and has two consumers now — @objectstack/spec/system's renderOperationMessage / BUILTIN_OPERATION_MESSAGES, with the errors.<key> deployment-override address and the four-rung ladder. A third consumer adds a catalog key, not a mechanism.
• The two-audience split is established on PermissionDeniedError itself: message is the user's half, developerMessage is an optional sibling field — and it is deliberately a sibling of details, never a member, because details is what the runtime dispatcher serialises to the client.
• ⚠️ Do not inherit DELETE_RESTRICTED (409) message is shown verbatim to end users: English-only, leaks API names, and contains developer-facing advice #7307's "ship the developer half over the wire" decision. PR fix(plugin-security,spec): PERMISSION_DENIED stops showing developer copy to end users (#7414) #7449 measured that its safety premise does not hold for 403s and shipped developerMessage to the log only, on both transports. Any template this card localizes should follow fix(plugin-security,spec): PERMISSION_DENIED stops showing developer copy to end users (#7414) #7449, not fix(objectql,rest,spec): DELETE_RESTRICTED stops showing developer copy to end users (#7307) #7423, unless it measures a reason not to.
• The pre-existing dispatcher-side disclosure (details.positions reaching the browser on /data) is out of scope here — it is The runtime dispatcher serialises a PermissionDeniedError's details to the client, so positions / permissionSets reach the browser on the /data transport #7450, now needs-user-decision in the cli lane.

On sizing, for whoever prices this. The filer's own note recommends grouping by audience rather than one card per template, and re-measured its census after filing (the delegated-admin gate is 13, not 11). Two of the ~40 sit in the same gate as #7414's — security-plugin.ts:1134 (requiredPermissions) and :1175 (delegator intersection) — and were deliberately left alone so a copy card would not silently become a family sweep. Whether this lands as one sweep card, an audience-grouped split, or a per-gate series is a scoping call this seat will make at claim time, from a re-measured census rather than from the filing's number.

No claim yet — this comment records the unlock only.

---

Generated by Claude Code

[os-zhuang]

Claim — PM loop, domain:identity seat (execution).

• Session: session_01BM1tNf5U3nEbHKR4fo5qVQ
• Branch: claude/issue-7451-security-denial-user-copy-end-user-gates
• Worktree: objectstack-issue-7451 (dedicated, off origin/main)
• File surface: packages/plugins/plugin-security/src/**, packages/spec/src/system/operation-message*.ts (+ tests, changeset)
• Serial constraints cleared: security-plugin.ts's three landings today (docs(plugin-security): restate the upsertEnvPermissionSet JSDoc for ADR-0094 D5-R (#7082) #7346 comments-only, fix(plugin-security): checkAuthoredRowWrite answers the declaration, not the caller's read scope (#7281) #7400 probe scope, fix(plugin-security,spec): PERMISSION_DENIED stops showing developer copy to end users (#7414) #7449 the first template) are all merged; this lane has zero open PRs. The runtime dispatcher serialises a PermissionDeniedError's details to the client, so positions / permissionSets reach the browser on the /data transport #7450 is the dispatcher-side disclosure, needs-user-decision in the cli lane — different question, different seat, no lock.

Scoping decision, made here rather than left to the dev

The card names three questions "a sweep cannot make mechanically". One of them already has a precedent answer, and saying so is what keeps this from becoming an escalation:

• Q2 — how many message keys? Already settled by the catalog's own shape: DELETE_RESTRICTED (409) message is shown verbatim to end users: English-only, leaks API names, and contains developer-facing advice #7307 gave the single wire code DELETE_RESTRICTED two keys (delete_restricted, delete_restricted_required). The norm is therefore one key per situation, not per code, and it needs no maintainer ruling. Distinct situations get distinct keys.
• Q1 — audience and Q3 — whether anything may be named are code-reads, i.e. scoping, which this seat decides rather than escalates.

Dispatched scope: the END-USER-facing gates only. The dev's first deliverable is the audience classification with evidence (which gates a non-admin principal can reach on an ordinary business operation), and only that half is implemented in this PR. The admin-surface half — delegated-admin-gate.ts (13), suggested-audience-bindings.ts, permission-set-projection.ts, system-write-guard.ts — is explicitly out of scope: the card itself observes those are arguably correctly developer-facing, and localizing copy that cites ADR clauses would destroy the citation without helping anyone. If the classification turns out not to be clean, the dev stops and reports rather than guessing.

⛔ Two inheritances that must not happen silently: the developer half follows #7449 (logged, not shipped — on both transports), not #7423; and the pre-existing details disclosure is #7450's, not this card's.

The census is to be re-measured at the branch point, not taken from the table above — that table is dated 2ef18070e and security-plugin.ts has landed three times since, one of which converted a template.

If an earlier claim with a different session ID exists in this thread, that one wins and I stand down.

---

Generated by Claude Code