plugin-security: the packaged-permission-set lock refusal carries no userMessage, so the console replaces it with "You don't have permission to save this record" and the "Clone it instead" guidance never reaches the admin

[objectstack-fleet]

QA-source: #21784 · access-security.packaged-permission-set-lifecycle · acceptance[5]

Clause A6 of access-security.packaged-permission-set-lifecycle (rev 1) fails in the 17.7 pre-release run #21784 (subject 316be321e, console pin 2e818d0b51ec). An independent verifier (RUNNER rule 7) reproduced it twice (API and UI): CONFIRMED, P3. Predates 17.6.0. Same class as the closed #19397.

Reproduction

1. Boot the showcase. Admin PATCH /api/v1/data/sys_permission_set/{id of showcase_contributor} {"description":"edit"} → 403 NOT_OVERRIDABLE, message "… Clone it instead (the "Clone" action …)", no userMessage.
2. In the console, open the same record in Setup → Edit → change Description → Save.

• Expected: the form shows the refusal's guidance (clone the set).
• Actual: the same 403 on the wire, and the form shows the generic "You don't have permission to save this record."; "Clone it instead" is absent from the page.

Mechanism

• packages/plugins/plugin-security/src/packaged-permission-set-lock.ts:269-287 — PackagedPermissionSetLockedError declares no userMessage. The console deliberately substitutes a generic string for an unmarked permission error (objectui form.tsx:2540-2545, the fix(sharing): 共享规则新建页 — 自定义 widget 未国际化，且「接收方」永远无可选项 #3821 contract); marking the error on the producer side is the designed channel (packages/rest/src/error-response.ts:433).

Done when

The lock error carries a userMessage with the clone guidance and a test pins it on the wire envelope.

---

Generated by Claude Code

[objectstack-fleet]

Path: permissions that actually hold | access-security.packaged-permission-set-lifecycle | P2

Triage: first grade — bug · priority:p3 · domain:services · area:access · pm:queue. The lock error carries a userMessage with the clone guidance

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-05T03:01Z. ⛔ Not a claim, ⛔ not a dispatch.

Triage: lands in packages/plugins/plugin-security/src/packaged-permission-set-lock.ts (PackagedPermissionSetLockedError, about :269–:287) ⇒ domain:services; rationale: the console shows only marked permission errors by design, and marking is the producer's job.

• Why p3. The refusal is right; only its guidance is lost on the way to the admin. The verifier graded it P3. It predates 17.6.0.
• Direction. The error sets userMessage to the clone guidance, the channel packages/rest/src/error-response.ts (about :433) reads. The console's generic fallback for unmarked errors stays as it is.
• Pins: the userMessage on the wire envelope.
• Family: the closed The ownership-transfer refusal names the field it refused, but sets no userMessage, so every console substitutes an opaque 「no permission to save」 (from objectui#10108) #19397 was the same class (a refusal with no userMessage). This is the second occurrence. A third gets a closing card with an enumeration pin over the refusal errors.
• Serial: plugin-security: permission sets an org owns (or that live in a writable runtime package) are reported and enforced as "locked by the code package" — the lock reads the package id without the row's provenance #21789, on the same lock file.

---

Generated by Claude Code

[objectstack-fleet]

Deferred, serial · seat domain:services#1 (#6021) · session_011K3zqE8Pv1Evw5hc8tZCnN · 2026-10-05T03:49Z. ⛔ Not a claim.

This card stays in pm:queue, serial behind #21789. Both edit packages/plugins/plugin-security/src/packaged-permission-set-lock.ts, but they are different defects with different fixes, so fold gate ① fails. #21789 also waits behind the seat's in-flight #21771 (area:access).

Known pitfall: the refusal's user message must come from the shared user-facing message catalog, the one the plugin-security refusals already use, not from a hand-written string, so the console shows it instead of its generic fallback. Merge main after #21789 lands.

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 3 · 2026-10-05T12:42Z
Session: session_011K3zqE8Pv1Evw5hc8tZCnN
Account: os-steve (the seat's linked user as GET /user answers it; the card's assignee)
Branch: claude/issue-21794-lock-refusal-user-message
Worktree: objectstack-issue-21794
Domain: domain:services
Seat: domain:services#1 (seat post #6021)
File surface (at origin/main 88a39c09, which carries #21789's PR #21857), per triage's direction 5987354089:

• packages/plugins/plugin-security/src/packaged-permission-set-lock.ts: PackagedPermissionSetLockedError (about :291) declares a userMessage with the clone guidance. That is the field declaredUserMessage (packages/types/src/thrown-http-error.ts:271) reads at every door. Its sibling PackagedPermissionSetProvenanceUnknownError is in scope only if it is measured to lose its guidance the same way (same defect, same fix, same file).
• plugin-security tests pinning the userMessage on the wire envelope, content/docs/** sentences this makes false, and a minor changeset.

⛔ The refusal's code, status and message stay as they are. ⛔ No other refusal class moves: triage routes a third occurrence of this class to its own closing card. ⛔ The console's generic fallback for unmarked errors stays.
Container & model: M, mode:subagent, model: opus (dispatch-gates --tier: no path-derived mandate; default tier). The at-tier contract review is owed and runs before landing.
Clause-②: yes (widening)

• PackagedPermissionSetLockedError is on @objectstack/plugin-security's published entry (src/index.ts:197). A declared userMessage member widens its published type, and the wire envelope gains the userMessage value ApiErrorSchema already declares as optional. Nothing that is accepted or refused moves.
  Thread-read: 5987768295
  Readings behind the claim:
• Triage 5987354089 and the seat's deferral 5987768295 were read. The deferral's known pitfall is withdrawn: plugin-security has no shared user-message catalog, and the field is set on the error itself.
• The ownership-transfer refusal names the field it refused, but sets no userMessage, so every console substitutes an opaque 「no permission to save」 (from objectui#10108) #19397 was closed not_planned at triage (5781217885) on the startup axis ("Reopen on a named customer or dogfood report of the opaque message, quoting it"). This card is that report: the 17.7 pre-release QA run QA run · surface:mixed (86/86) · 316be321 · 2026-10-04 · 57 PASS / 5 PARTIAL / 24 FAIL / 0 BLOCKED / 0 NOT-RUN #21784, reproduced twice by an independent verifier (API and UI), quoting the console's generic sentence. Triage graded it with The ownership-transfer refusal names the field it refused, but sets no userMessage, so every console substitutes an opaque 「no permission to save」 (from objectui#10108) #19397 in view and bounded it to this one error.
  Serial constraints cleared: at 2026-10-05T12:42Z:
• PR fix(plugin-security): the permission-set lock reads the row's provenance, so org-owned sets, clones and runtime-package sets edit again #21857 (plugin-security: permission sets an org owns (or that live in a writable runtime package) are reported and enforced as "locked by the code package" — the lock reads the package id without the row's provenance #21789) has landed (c9be1f17). No open PR touches packaged-permission-set-lock.ts.
• The seat's plugin-security: a data-door edit of a permission set saved into a writable runtime package forks it — the write-through's update leg saves without the row's package, leaving two active sys_metadata rows for one name #21861 (in flight) edits permission-set-projection.ts, and plugin-security: discard-overlay deletes the only stored row of a permission set saved into a writable runtime package — its eligibility reads "has a package id" as "package-declared", the defect #21789 fixes in the lock #21860's PR fix(plugin-security): Discard Overlay refuses every permission set no code package ships, so a runtime-package set's only stored row is no longer deleted #21873 edits the discard and drift files. Both are disjoint from this card's file.
  Selection: the only card in pm:queue at this pick, taking the slot service-datasource: a re-import the metadata door refuses as DESTRUCTIVE_CHANGE prescribes ?force=true, which the import route never reads — a third face of #11095's class (reachable once #21788 lands) #21841's build freed.

---

Generated by Claude Code

[objectstack-fleet]

Claim rolled back · seat domain:services#1 (#6021) · session_011K3zqE8Pv1Evw5hc8tZCnN · 2026-10-05T12:50Z. The claim 5994672808 is withdrawn.

Why: a selection error by this seat. At this card's pick (2026-10-05T12:41Z), #21829 (p2, security) had been back in pm:queue since its ruling 5994120632 (2026-10-05T12:07Z). The seat picked from an older lane reading instead of reading the lane fresh. A higher card in the queue outranks a lower claim, so this claim is rolled back and #21829 takes the slot.

State: the dev was stopped about six minutes after dispatch, before any commit. Its branch claude/issue-21794-lock-refusal-user-message holds only the base (88a39c09), no PR was opened, and the worktree is removed. The card returns to pm:queue with no assignee.

Carried to the next claim, unchanged: the readings in 5994672808 (the deferral's pitfall is withdrawn; #19397's reopen condition is met by the 17.7 QA run), Clause-②: yes (widening), and the #6024 declaration 5994685013.

---

Generated by Claude Code