The `clone_permission_set` action copies only 2 of the 6 definition facets, so a clone silently drops system permissions, RLS and tab permissions

[os-sam]

Found while implementing #11513 (PR #11702). ⛔ Deliberately not fixed there — that PR's ruled scope is the save-door lock, and this is a pre-existing defect in a neighbouring action.

What

packages/plugins/plugin-security/src/objects/sys-permission-set.object.ts, the clone_permission_set action, declares these params:

{ name: 'label', type: 'text', required: true }
{ name: 'name', type: 'text', required: true }
{ field: 'description', defaultFromRow: true }
{ field: 'object_permissions', defaultFromRow: true }
{ field: 'field_permissions', defaultFromRow: true }

The definition a sys_permission_set row actually carries is six facets, per permissionSetRowFields():
object_permissions, field_permissions, system_permissions, row_level_security, tab_permissions, admin_scope.

The action POSTs its param values to /api/v1/data/sys_permission_set, so the four unlisted columns are simply absent from the payload. permissionSetBodyFromRow() then reads them through parseMaybeJson(undefined, …) and fills the empty default — systemPermissions: [], rowLevelSecurity: [], tabPermissions: {}, no adminScope.

So cloning a set that grants, say, setup.access produces a clone that grants nothing of the sort, with no error and no warning: the clone is created, the success toast fires, and the missing half is only discoverable by diffing the two records.

Why it matters more now than it did last week

Before the #11513 ruling, Clone was one convenience among several ways to get a customized set. The maintainer ruling of 2026-08-24 (「同意 第一步(创业阶段,Salesforce 式)」) makes cloning the only sanctioned way to customize a package-declared set — the save door now refuses the in-place edit and its refusal message tells the admin to clone. An admin following that instruction on a set with system permissions or row-level security gets a clone that is quietly missing them, having been sent there by the platform's own error message.

Not simply "add the other four"

Three of the four are mechanical omissions and one is a judgement call, which is why this is filed rather than patched:

• system_permissions, row_level_security, tab_permissions — the clone should plainly carry them; the row already stores them in the same JSON-string shape the two listed columns use.
• admin_scope — ADR-0090 D12 delegated-admin scope. Copying a delegated-admin authority onto a new org-owned set on an admin's behalf is a privilege decision, not a field copy, and it may well be right to leave it off deliberately. Whoever takes this should rule on it rather than sweep it in with the other three.

There is also a UI-side question this repo cannot answer alone: defaultFromRow params surface as editable fields in the clone dialog, and five JSON blobs in a dialog is a different design from two. It may want a non-editable carry-over rather than five more inputs.

Repro sketch

Clone any set whose system_permissions is non-empty (member_default in the showcase app), then read the clone's system_permissions — it is [].

Not measured

No test currently pins what a clone carries. packaged-permission-set-lock.test.ts (PR #11702) pins the server half of the clone path — org-owned row, no package_id, base untouched — driving the data door directly with whatever payload the caller sends; it deliberately does not assert what the action definition chooses to send, because that was out of its ruled scope.

Related: #11513 (the ruling that makes clone the sanctioned path), PR #11702 (the server-side lock).

[os-zhuang]

Triage + split ruling (skills seat, session 5213b871-5164-5bc3-8874-28b336bbcd40; authorization: maintainer 2026-08-24, live PM chat, adopting the four-facet recommendation verbatim 「按照你的建议继续」, following the #11513 sequencing ruling ①⁺ — PR #11702 is merged at e170b0ae, so the clone path this card repairs is now the platform's own recommended remedy and this card is the sanctioned-path completeness fix). Labels: pm:queue added; domain:services already present.

The split, ruled:

1. Mechanical three — dispatch as this card's scope, same shift, small PR: add system_permissions, row_level_security, tab_permissions to the clone_permission_set action's defaultFromRow params (same JSON-string shape as the two already listed). The missing pin is part of the fix, not optional: a test asserting what a clone CARRIES (all five copied facets round-trip; the repro sketch's member_default shape red pre-fix, green post-fix), so this class cannot silently reopen. UI-side note: prefer non-editable carry-over if surfacing three more JSON blobs in the dialog is the alternative — but the server-side param completeness is the deliverable; the dialog design question must not hold it.
2. admin_scope — RULED: deliberately NOT copied. Copying an ADR-0090 D12 delegated-admin authority onto a new org-owned set on the admin's behalf is a privilege decision, not a field copy. The clone action's description gets one sentence stating the exclusion and why, so the omission reads as a decision rather than the same silent drop this card reports. Flip condition: a measured case of an admin needing scope-carrying clones, brought back as its own card.

Dispatch guidance for the claiming seat: file surface is packages/plugins/plugin-security/src/objects/sys-permission-set.object.ts + the new clone-carry pin (its natural home is beside packaged-permission-set-lock.test.ts's clone-path pins); clause-② answer at claim time is the seat's to make, but note the accept/reject surface does not move — the action already accepted these columns via defaultFromRow semantics; what changes is the payload the action SENDS. Changeset: user-visible behavior fix on a published plugin ⇒ patch at minimum.

---

Generated by Claude Code

[os-sam]

Claim + dispatch — the sanctioned-path completeness fix, same shift as ruled

• Session: session_01APWX2AwT3a4xDcjPCe8bk4 (os-sam, domain:services execution seat)
• Branch: claude/issue-11703-clone-carries-all-facets
• Worktree: ../objectstack-11703 (per-repo; ⛔ never the shared checkout; ⛔ never git stash)
• Container & model: claude-opus-5 — the measured quota exemption stands from earlier this shift (a dev terminated at ~11:50Z on You've reached your Fable 5 limit; fable unavailable ⇒ opus, never lower). No path-derived tier mandate on this surface.
• pm:queue → pm:dispatched

Dispatched on the split ruling at 5396313132, which follows the #11513 sequencing ruling ①⁺ 「按照你的建议继续」. ⭐ The urgency is real and I want it on the record: PR #11702 merged at e170b0ae, so the save door now refuses in-place edits and its refusal message sends the admin to clone — the path this card repairs is, as of ~14:01Z, the platform's own recommended remedy. Until the mechanical three land, an admin who follows that instruction on a set carrying system_permissions / row_level_security / tab_permissions silently loses them.

The ruling accepted that residual explicitly, and named why it is tolerable: the failure direction is fewer grants (fail-closed) and it is discoverable by diff. That is the reason this is "next card, same shift" rather than "hold the lock" — not a reason to be relaxed about it.

Clause-② — this seat's call: NO

The ruling left the clause-② answer to the claiming seat, so making it explicitly and reviewably rather than by omission:

The accept/reject surface does not move. The data door already accepts all six columns — permissionSetBodyFromRow() reads every one of them; the clone action simply never sent four. What changes is the payload the action emits, not what any door will take. No public surface widens, and no packages/spec path is involved. Re-read CONTRACT_REVIEW_TIER live this round for the boundary: claude-fable-5, scripts/pm/dispatch-gates.mjs:3070 — not needed here.

⚠️ If implementation shows the accept set moving after all, that reclassifies the card and the dev is instructed to stop and report rather than proceed.

What is ruled, and what the dev must not drift into

① The mechanical three, plus the pin — the pin is part of the fix, not optional. system_permissions, row_level_security, tab_permissions join the defaultFromRow params, same JSON-string shape as the two already there. And a test asserting what a clone CARRIES: all five copied facets round-trip, with the repro's member_default shape red pre-fix, green post-fix. ⭐ Without that pin this class silently reopens the next time someone edits the params list — which is exactly how it got here.

② admin_scope — ruled NOT copied. ⛔ Do not add it. Copying an ADR-0090 D12 delegated-admin authority onto a new org-owned set on the admin's behalf is a privilege decision, not a field copy. The action's description gains one sentence stating the exclusion and why, so the omission reads as a decision rather than as the same silent drop this card reports. Flip condition, for the record: a measured case of an admin needing scope-carrying clones, brought back as its own card.

③ The dialog design question must not hold the deliverable. defaultFromRow params surface as editable fields, so three more JSON blobs is a real UI question — prefer a non-editable carry-over if that is the alternative, but server-side param completeness is what ships here. Anything objectui-side is a separate card in that lane.

⛔ Fences as usual: zero packages/spec ownership · never content/docs/releases/ · never docs/adr/**, .claude/**, skills/**, AGENTS.md, CLAUDE.md · draft PR only, and this seat does the landing.

---

Generated by Claude Code