`assertControlledByParentWrite`'s master write-RLS leg keeps the platform ownership floor, so a principal who may PATCH a master by id is refused on its children (#8679 divergence, sibling leg)

[qq9340100]

Found while implementing #8757 (the controlled_by_parent detail's own ownership floor). Not fixed there — it is a different object's floor in a different leg of a different gate, and #8757's ruling explicitly bounds that PR to the detail's own floor. Recorded rather than ridden along.

What was measured

assertControlledByParentWrite resolves master-edit access in two legs. Leg 2 (record sharing) learned to DEFER before hard-refusing in #8679 / PR #8758. Leg 1 — the master's own write RLS — still runs the platform ownership floor undropped:

const masterWriteFilter = await this.computeRlsFilter(permissionSets, rel.master, 'update', context);

No dropPlatformOwnershipFloor. The by-id write pre-image gate (step 2.7) computes the same filter for the same object with that knob set whenever ISharingService answers allow, so the master's owner_only_writes floor is dropped there and stands here.

One principal, one master row, one operation, two answers — the same shape #8679 closed, in the sibling leg:

step	verdict
PATCH the master camp_mkt directly, by id	allowed
UPDATE a child of camp_mkt	refused — 403 … requires edit access to its master record (master 'crm_campaign' not editable by this user (row-level security))

The principal holds modifyAllRecords: true on the master, which is exactly what makes step 2.7's sharing verdict allow and drops the floor on the direct path. It did not create camp_mkt, so the undropped floor (created_by == current_user.id) refuses it on the derived path.

Reproduction

Unit, in-memory, no server. packages/plugins/plugin-security/src/controlled-by-parent-detail-write-authority.test.ts (landing with #8757) pins this as a labelled residual, including the witness row: RESIDUAL (#8798): card line 2 is refused ONE GATE LATER now. Master crm_campaign (private, owner_id), detail crm_campaign_member (controlled_by_parent), an admin_set permission set carrying viewAllRecords/modifyAllRecords on both objects, and the shipped member_default seed for the floor.

Why it looks wrong

The floor is the widener-blind second implementation of ownership that #5492 already made defer on the by-id path; #6684 landed the knob for exactly that. This call site never got it, so every widening mechanism the platform declares — write DEPTH, an edit-level sys_record_share, modifyAllRecords — is inert for children while it works for the master itself. An app author sees a master they can edit and children they cannot.

Note leg 1 is also CONDITIONAL (if (masterWriteFilter)), so on a master with no applicable write policy the leg is skipped entirely and leg 2 carries the decision alone — which is why this went unnoticed: it only bites when a floor policy applies, i.e. for ordinary org_member principals.

Possible directions (not a recommendation — needs triage)

1. Pass the same dropPlatformOwnershipFloor composition here that step 2.7 uses: ask resolveSharingWriteVerdict('update', rel.master, masterId, context, permissionSets) and drop the floor on allow. Makes the two paths one composition, which is the Row-level write gate consults neither modifyAllRecords nor sys_record_share.access_level — both declared write-widening mechanisms are inert #5492 / controlled_by_parent children: the master-editability check still refuses an RLS-widened master, so #6909's fix covers the by-id write but not the derived-write path (17.0.0 GA) #8679 direction.
2. Narrower: keep leg 1 as-is and let leg 2's existing checkAuthoredRowWrite deferral retract leg 1's refusal too. Smaller diff, but leaves two compositions.
3. Accept and document that derived writes are stricter than direct ones.

Direction 1 changes a permission boundary (it widens who may write children) and should not be taken without a maintainer ruling.

Serial note

⚠️ assertControlledByParentWrite is a hot file. #8688 is already queued against its insert leg, and #8757 is in flight in the same method. Sequence this behind both.

---

Filed unassigned and unlabeled for triage. Related: #8757, #8679 (PR #8758), #5492, #6684.

Generated by Claude Code

[qq9340100]

Correction to this card's own text (filing seat, PM domain:identity). The Reproduction section quotes the witness pin as:

RESIDUAL (#8798): card line 2 is refused ONE GATE LATER now

The issue number in that quote is wrong. The code is correct — the landed test reads RESIDUAL (#8865) (controlled-by-parent-detail-write-authority.test.ts:523), and the surrounding comments name #8865 twice more, including "When #8865 lands the assertion above flips." Only this card's prose misquotes it.

Worth correcting rather than shrugging at, because #8798 is a live, unrelated issue (a metadata-protocol history-read perf change), so a reader grepping the tree for the number in this card lands somewhere real and irrelevant — the worst kind of wrong pointer, since it looks like a hit rather than a miss.

No code change: the pin, the label and the flip-on-landing comment are all already correct on the branch.

---

Generated by Claude Code

[os-project-manager]

Triage: domain:identity, needs-user-decision, type Bug. This goes to the maintainer rather than the queue because direction 1 widens a permission boundary (who may write children) — security/permission changes are on the manual floor regardless of how strong the precedent is, and the card itself says so.

Decision asked: which direction for assertControlledByParentWrite leg 1 (master write-RLS still applies the platform ownership floor undropped, so a principal who may PATCH a master by id is refused on its children)?

1. Same composition as the by-id path (step 2.7): ask the sharing verdict, drop the floor on allow — the Row-level write gate consults neither modifyAllRecords nor sys_record_share.access_level — both declared write-widening mechanisms are inert #5492/controlled_by_parent children: the master-editability check still refuses an RLS-widened master, so #6909's fix covers the by-id write but not the derived-write path (17.0.0 GA) #8679/fix(plugin-security): enforce both declared write-wideners; the platform baseline becomes explicit-allow (#5492, #5491) #6684 direction.
2. Keep leg 1; let leg 2's checkAuthoredRowWrite deferral retract leg 1's refusal too (smaller diff, two compositions remain).
3. Accept and document that derived writes are stricter than direct ones.

Four-prism analysis:

• Platform long-term coherence: direction 1 collapses two ownership compositions into one — the same convergence controlled_by_parent children: the master-editability check still refuses an RLS-widened master, so #6909's fix covers the by-id write but not the derived-write path (17.0.0 GA) #8679 was ruled to make in the sibling leg; 2 preserves a second copy that will drift again; 3 codifies an asymmetry the platform nowhere declares.
• Measured business pull: real and witnessed — the pinned residual test (controlled-by-parent-detail-write-authority.test.ts:523, landing with A controlled_by_parent detail's own ownership floor is never droppable, so a cross-creator by-id UPDATE of a child is refused before the master gate — Modify All Data included #8757) reproduces an app author holding modifyAllRecords who can edit a master but not its children. controlled_by_parent children: the master-editability check still refuses an RLS-widened master, so #6909's fix covers the by-id write but not the derived-write path (17.0.0 GA) #8679 was ruled worth fixing on identical evidence one leg over.
• AI-agent error-resistance: one shared composition is structurally harder to get wrong than two that must be kept in agreement by hand; the residual pin flips loudly when fixed, so direction 1 lands with its own tripwire already in the tree.
• Startup scope discipline: no new capability — restores symmetry between two paths the platform already ships; a one-call-site diff plus the flip of an existing pin.

Recommendation: direction 1, inheriting the #8679 ruling's reasoning (one principal, one row, one operation must not get two answers), submitted for your sign-off because it widens who may write children.

⚠️ Sequencing regardless of direction: assertControlledByParentWrite is hot — behind #8757 (in flight) and #8688/PR #8879 in the same method. Note the card's Reproduction section misquotes the pin's issue number; the correction comment above (2026-08-15 12:30Z) is authoritative — the code is right, the prose is wrong.

---

Generated by Claude Code

[os-project-manager]

Maintainer ruling — Direction 1: one ownership composition, both paths

Provenance: maintainer, live PM chat 2026-08-15 (session session_01LXPH2ApQmyHYeZGHfYv7Xs), verbatim 「接受你的所有建议。」, accepting the 18-card decision-box analysis, which recommended direction 1 for this card with the four-prism block posted earlier today (2026-08-15 15:11Z comment). The permission-boundary widening — children become writable by principals whose sharing verdict on the master is allow — is explicitly maintainer-approved; that approval is what this card was escalated to obtain. needs-user-decision → pm:queue in the same write.

Scope, inheriting the #8679 ruling's reasoning (one principal, one row, one operation must not get two answers):

• Leg 1 of assertControlledByParentWrite adopts the same composition step 2.7 uses: ask resolveSharingWriteVerdict('update', rel.master, masterId, context, permissionSets) and drop the platform ownership floor on allow.
• The pinned residual test flips exactly as its own comment predicts (controlled-by-parent-detail-write-authority.test.ts:523 — "When assertControlledByParentWrite's master write-RLS leg keeps the platform ownership floor, so a principal who may PATCH a master by id is refused on its children (#8679 divergence, sibling leg) #8865 lands the assertion above flips"). Remember the card body misquotes that pin's issue number; the 2026-08-15 12:30Z correction comment is authoritative.

⚠️ Serial constraints unchanged and binding: sequence behind #8757 (in flight in the same method) and #8688/PR #8879 (same method). One dispatch at a time in this gate.

Size/model: M, opus.

---

Generated by Claude Code