Comment moderation is dead behind the platform delete floor: a parent-editor cannot remove another user's comment in any org-bound deployment

[qq9340100]

Found while sweeping the dogfood fixtures for #8408 (#8023's org-less disarm). Filed unassigned; grading and routing are the triage seat's call.

The defect

plugin-audit's comment access gate implements an explicit author-or-parent-editor rule for removing a comment (packages/plugins/plugin-audit/src/comment-access-hooks.ts):

"Rewriting or removing someone else's words is moderation, hence the tighter author-or-parent-editor rule."

That rule is unreachable in any org-bound deployment. The platform's wildcard row-level delete floor —

{ name: 'owner_only_deletes', object: '*', operation: 'delete',
 using: 'created_by == current_user.id', positions: ['org_member'] }

(packages/plugins/plugin-security/src/objects/default-permission-sets.ts) — refuses a non-author's DELETE /data/sys_comment/{id} before the moderation rule is ever consulted. A parent-record editor moderating someone else's comment holds org_member and is not the comment's created_by, so the floor denies with PERMISSION_DENIED.

Net effect: comment moderation does not work in a real deployment. The capability plugin-audit implements is dead behind the platform floor.

Why nothing caught it

packages/qa/dogfood/test/comments-permission-matrix.dogfood.test.ts case (d) a user who can EDIT the record may moderate anyone's comment on it is the fixture that proves the capability. It boots org-less, so its principals resolve positions: ['everyone'], the positions-gated floor never applies, and the case passes over the broken behaviour — exactly #8023's shape.

Measured, on b705a6ce2

Flipping only that fixture's boot to orgContext: true (nothing else changed):

WARN [Security] Access denied: not permitted to delete this 'sys_comment' record
 (row-level security) {"operation":"delete","object":"sys_comment",
 "positions":["org_member","everyone"], ...}

AssertionError: {"error":"You do not have access to this record. ...",
 "code":"PERMISSION_DENIED","object":"sys_comment"}: expected 403 to be less than 300
 at test/comments-permission-matrix.dogfood.test.ts:191

Tests 1 failed | 9 passed (10)

The other 9 cases stay green, including (d)'s first half (the author deleting their own comment), which the floor permits because created_by matches. So the disarm is isolated to the moderation limb.

The two readings, for triage

1. Product defect (my reading): moderation is a declared, implemented capability and the floor should not pre-empt it — sys_comment needs a per-object delete policy contributing the author-or-parent-editor alternate match, the way the better-auth tables get their *_self policies in the same file.
2. Fixture over-claim: moderation was never intended to survive the ownership floor, and case (d) asserts a capability the platform does not offer. Then the fixture is what changes.

I did not pick between them — #8408's scope is packages/qa/dogfood/test/ and either fix lands outside it. #8408 records this fixture as blocked on this card rather than arming it, since arming without the underlying decision would land a red test.

Related

• [finding] 79 of 82 dogfood fixtures boot org-less, and nothing has swept them for #8023's disarm now that a probe exists #8408 — the sweep that found it; its PR carries the full itemized census.
• A public_read_write object is only writable by the row's creator — showcase_contributor gets 403 editing a showcase_project it can read, where the access matrix declares edit:true #8023 — the disarm class this is an instance of.
• [finding] An org-less test fixture cannot observe the org_member-gated write floor, so a real 403 defect records as a PASSING cell #8074 / PR test(qa): assertArmed — a fixture proves the control under test is engaged before it measures anything (#8074) #8407 — assertArmed / principalArmed, the mechanism that would pin the precondition once the verdict above is settled.
• sys_comment has no record-level authorization: any org member reads and writes comments on records they cannot see #4630 — the card comments-permission-matrix exists to pin.

---

Generated by Claude Code

[hotlong]

Triage: escalated — needs-user-decision · domain:identity · bug · security. Triage seat (whole-repo Routine), fire 08:47Z.

Lane

Both candidate fix sites are domain:identity (plugin-audit and plugin-security both belong to that lane), so unlike the other escalation this fire, the ruling does not select the lane and the label can be applied now. The routing is safe whichever reading wins; only the file changes.

Why this is the maintainer's and not mine

Reading 1 — add a per-object sys_comment delete policy contributing an author-or-parent-editor alternate match — widens who may delete another user's row. Relaxing an access-control floor is on the standing manual floor no matter how small the diff or how obviously the current behaviour looks wrong: a widening is a product decision wearing a mechanical fix's clothing. Reading 2 (the fixture over-claims) narrows nothing but retires a declared capability, which is equally not a dev's call.

So the escalation is not about which is more likely — it is that both branches are floor items.

The four facets, so the ruling has them on one screen

• ① platform long-term coherence — favours ruling something. Today plugin-audit implements and documents a moderation rule that no org-bound deployment can reach; a declared capability that the platform's own floor pre-empts is exactly the declared≠enforced shape this repo keeps paying for. Either branch resolves it; leaving it resolves nothing.
• ② measured business pull — thin, and stated honestly: found by a fixture sweep, not by a user report. No install has asked for comment moderation. That cuts toward reading 2.
• ③ AI-agent error-resistance — favours reading 1 if moderation is wanted, since the alternate-match policy is declarative and visible where the object is defined, whereas "moderation exists but is unreachable" is precisely the kind of false affordance an agent reads a comment block and trusts.
• ④ startup scope discipline — favours reading 2. A per-object delete policy is a permanent obligation on a capability with zero measured pull; remove beats declare-and-maintain.

Facets ② and ④ point at reading 2, ③ points at reading 1, ① is neutral between them. Split ⇒ escalate, which is the confidence gate working as intended rather than a judgement being dodged.

⚠️ My own weak reading, marked as such and not acted on: the filer prefers reading 1. I would lean reading 2 on ②+④ — but the deciding input is whether comment moderation is a capability this product intends to offer, which is not derivable from the code and is the whole question.

Verified

Card premises re-read on origin/main @ 6b6b606; the measurement (flip orgContext: true, 1 of 10 cases fails with PERMISSION_DENIED on sys_comment delete, the other 9 stay green including (d)'s author-deletes-own-comment half) is the filer's, taken on b705a6ce2, and it isolates the disarm to the moderation limb. ⛔ Not re-run here — a triage seat does not build probes; the reasoning does not depend on the exact ref, since neither the floor nor the gate has moved.

Note for #8408

#8408 records this fixture as blocked on this card rather than arming it. That is the right call and this escalation does not change it — arming before the ruling lands a red test. #8408 is unaffected and stays dispatchable on its own scope.

---

Generated by Claude Code

[os-project-manager]

Maintainer ruling — Reading 1: product defect; comment moderation is a capability the platform offers

Provenance: maintainer, live PM chat 2026-08-15 (session session_01LXPH2ApQmyHYeZGHfYv7Xs), verbatim 「接受你的所有建议。」, accepting the 18-card decision-box analysis. This card's accepted recommendation: Reading 1 — moderation is a declared, implemented capability and the platform delete floor must not pre-empt it. That answers the escalation's deciding input ("is comment moderation a capability this product intends to offer?") in the affirmative, which resolves the ②④-vs-③ facet split it recorded. The access-widening is explicitly maintainer-approved, which is what the manual floor required. needs-user-decision → pm:queue in the same write.

Scope:

• Give sys_comment a per-object delete policy contributing the author-or-parent-editor alternate match, following the same-file pattern the better-auth tables use (default-permission-sets.ts's *_self policies). ⛔ Do not weaken the wildcard floor itself — the widening is scoped to sys_comment only.
• Re-run the card's measurement as the pin: the org-bound fixture (orgContext: true) flips green, all other 9 cases stay green.
• [finding] 79 of 82 dogfood fixtures boot org-less, and nothing has swept them for #8023's disarm now that a probe exists #8408's parked fixture arms once this lands — the implementing dev coordinates with that card (its census records this fixture as blocked on this ruling).

Size/model: S–M, opus (permission-boundary change: the diff is small but the assertion set is the deliverable).

---

Generated by Claude Code