Decision needed: should the `sys_comment` parent gates run the parent's owner-match at the caller's real write DEPTH, or stay at `own`?

[os-zhuang]

Split out of #7141 (PR #7143) rather than decided there, because it is a widening and the two candidate shapes that card named diverge here — on nothing else.

The fact

ISharingService.canEdit widens its owner-match by the access DEPTH the caller
holds on the probed object, read from the middleware-private __writeScope key
(plugin-sharing/src/sharing-service.ts — matchesOwnerScope, and
if (writeScope === 'org') return true). plugin-security supplies that key
explicitly for the object it is probing, via the private
resolveWriteScopeForSharing (security-plugin.ts:2516).

The sys_comment gates in plugin-audit supply no depth. The five-field
projection #7141 removed never carried one, and PR #7143 deliberately kept it
that way: an absent depth leaves the owner-match at its narrowest (own), which
is the safe direction and is byte-for-byte what the projection produced.

The consequence, stated as behaviour

A caller whose write depth on the PARENT object is unit / unit_and_below /
org can edit that parent record directly through the CRUD path (where the
middleware stamps the depth for that object) but is refused when they try to
edit or delete a comment on it, because this gate asks the same service the same
question with the depth omitted. It is a divergence in the restrictive
direction — no data leaks — between the comment gate and the parent's real edit
authority. Whether that is correct or is a bug depends on what the comment gate
is meant to mean, which is a product decision, not a code reading.

Why it was not simply fixed in #7143

The tool a package outside plugin-security has for this is the published
ISecurityService.resolveWriteScope. It fails open on one input:
getEffectiveScope returns 'org' when no permission set matches the object
(permission-evaluator.ts:255), and the service's own doc block flags that
'org' as "non-authoritative on its own". Passed to canEdit as __writeScope
it becomes fully authoritative, and matchesOwnerScope then returns true for
any owned row of an unmatched object — a real widening, not a theoretical
one. Taking that route needs either a narrower contract method (one that
distinguishes "org depth" from "nothing matched") or the gate resolving depth
some other way.

Note this is the same question for service-storage's attachment kit, which
gates on canEdit the same way.

What a decision would look like

1. Keep own (today, and fix(plugin-audit): forward the caller's execution envelope to the sys_comment sharing gates (#7141) #7143's behaviour) — the comment gate is
   deliberately tighter than the parent's edit authority. Then say so in the
   contract's doc block, so the next reader does not "fix" it.
2. Resolve the parent's depth — the comment gate inherits the parent's real
   edit authority. Needs a depth primitive that does not fail open on an
   unmatched object before it can be wired.

Related: #7141, PR #7143, #6523, #6206, ADR-0057 D1, ADR-0111 D1.

[claude]

Triage: needs-user-decision + domain:identity.

• Classification: product-semantics fork, not a code defect. The card asks what the sys_comment parent gate is meant to mean (deliberately tighter than the parent's edit authority, vs. inheriting it), and explicitly documents that today's behaviour is the safe/restrictive direction. Both candidate resolutions require a maintainer call — option 2 additionally needs a new depth primitive because ISecurityService.resolveWriteScope fails open ('org') on an unmatched object. No prior ruling found in body or thread (0 comments, fresh split from plugin-audit's callerContext rebuilds a 5-field subset of the execution envelope, dropping onBehalfOf before the sharing gates that are documented to fail closed on it #7141 / PR fix(plugin-audit): forward the caller's execution envelope to the sys_comment sharing gates (#7141) #7143), so this is a pending decision, not an executed one.
• Routing: domain:identity — whichever option wins, the change lands in packages/plugins/plugin-audit (gate call sites), plugin-sharing (matchesOwnerScope), and/or plugin-security (depth primitive), all identity-domain packages.
• Premise check at origin/main @ 3e8e669 (the fix(plugin-audit): forward the caller's execution envelope to the sys_comment sharing gates (#7141) #7143 merge itself): __writeScope read at plugin-sharing/src/sharing-service.ts:376 and in matchesOwnerScope (:414, :428); resolveWriteScopeForSharing private at security-plugin.ts:2530; the fail-open if (!matched) return 'org' present in permission-evaluator.ts (getEffectiveScope). All facts hold; cited line numbers drifted slightly (2516→2530) but anchors are live.
• Dedup: repo-scoped sweep over open issues/PRs for matchesOwnerScope / __writeScope / sys_comment — ADR-0057 hierarchy DEPTH: the resolver's tenant isolation never engages — plugin-sharing passes organizationId: null while the active org rides in tenantId #5852 (depth resolver tenant isolation, repo:cloud) and [engine][设计卡] 多态弱引用挂靠表的平台级删除级联 —— sys_record_share/attachment/comment 一族的统一清理机制 #5180 (delete-cascade design, on hold) are adjacent but neither covers this gate-depth question; no open PR touches it. Clean.
• target:v17: not applied — divergence is in the restrictive direction (refusals, not leaks); an RC can ship with the comment gate at own.
• Related: the same question applies to service-storage's attachment kit (service-storage's attachment kit carries the same 5-field callerContext projection #7141 fixed for comments #7145, queued separately for the projection fix; its fix deliberately keeps own-depth behaviour, so it does not block on this decision).

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

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling (2026-08-10, directed in session session_01BPWqbmEFU8gJepBJTHESXd): Option 1 — the comment gate stays at own.

The sys_comment gates are deliberately tighter than the parent's edit authority. Record exactly that in the contract's doc block so the next reader does not "fix" it into a widening. Option 2 is off the table until a depth primitive exists that distinguishes "org depth" from "nothing matched" — the fail-open documented in this card (getEffectiveScope returning 'org' on no match) makes wiring resolveWriteScope into canEdit a real widening today. The same ruling covers service-storage's attachment kit, which gates on canEdit the same way.

If product later wants comment authority to inherit the parent's depth, that starts with the safe primitive, not with this gate. needs-user-decision → pm:queue (doc-block card).

---

Generated by Claude Code