[finding] plugin-sharing: `TeamGraphService.managerOf` discards its `organizationId` argument — the manager-chain screen cited as this repo's governed side is not in this repo

[os-warren]

Recorded while verifying #10153's triage rationale. Not fixed there (that card is fenced to the manager approver branch), and filed as an observation because the correct treatment is a judgement call, not a mechanical repair.

What was measured

#10153's triage argues direction 1 from a standing meta-rule — "when one column has two consumers behaving inconsistently, the governed side wins" — naming HierarchyScopeResolver.screenToTenant (cloud#1195) as the governed consumer of sys_user.manager_id.

Neither symbol exists in this repository:

$ grep -rn "provablyDisjoint" . --include=*.ts --include=*.mts --include=*.md # (no output)
$ grep -rn "screenToTenant" . --include=*.ts # (no output)

Counter-check that the search works — a neighbouring known-present term on the same sweep:

$ grep -rln "expandPositionUsers" . --include=*.ts
./packages/spec/src/automation/approval.zod.ts
./packages/core/src/security/grant-validity.ts
./packages/plugins/plugin-sharing/src/position-graph.ts
./packages/plugins/plugin-approvals/src/approval-service.ts
... (10 files)

So the screened consumer lives in cloud's enterprise resolver. What this repo ships is IHierarchyScopeResolver as a seam (packages/spec/src/contracts/sharing-service.ts), with the open-source implementations here:

packages/plugins/plugin-sharing/src/team-graph.ts

async managerOf(userId: string, _organizationId?: string): Promise<string | null> {
 ...
 const rows = await this.engine.find('sys_user', {
 where: { id: userId }, fields: ['id', 'manager_id'], limit: 1, context: SYSTEM_CTX,
 });

The organization argument is accepted and discarded — the parameter is underscore-prefixed to say so. The sibling method on the same class, expandRoleUsers, does apply filter.organization_id. BusinessUnitGraphService.managerOf delegates here, and its standalone fallback reads sys_user unscreened the same way.

Why it matters for triage rather than for a patch

Within framework, approvals is therefore not an unscreened straggler among screened peers on this column: both manager-chain readers in this repo are unscreened, and the screened one is enterprise-side. Whether the OSS resolver should screen is a real question (the seam's documented contract is "fail-closed to own" for the open tier, which is a different posture from a tenant screen), but it is not answerable by reading the two call sites.

Recording it so the meta-rule is applied to the actual distribution of consumers rather than to the cloud-side one alone.

Related

• approvals: the manager approver resolves sys_user.manager_id with no organization screen, while every sibling approver expansion is org-scoped #10153 — the approvals-side consumer of the same column
• Design: does approver routing imply record read visibility? (#7345 model half) #7497 — Design: does approver routing imply record read visibility?

Filed unassigned, no pm:queue.

---

Generated by Claude Code

[os-zhuang]

Triage first-touch grading: pm:blocked, domain:services, type Task — deliberately neither promoted nor closed.

Blocked-by: #10153

Rationale: the card's own conclusion is that whether the OSS TeamGraphService.managerOf should org-screen is a posture question ("fail-closed to own" open-tier contract vs a tenant screen) that the two call sites cannot answer. #10153 (the manager approver org screen, dispatched) is the in-flight work that will establish the approver-side treatment of the same column; when it closes, the unlock scan returns this card and the posture question should be re-read against the landed shape — at that point it either becomes a scoped follow-up (screen the resolver / document the asymmetry at the seam) or evidence into #7497's design question. The correction this finding makes to #10153's triage rationale (the cited governed consumer HierarchyScopeResolver.screenToTenant lives in cloud, not this repo — measured with counter-checked greps) is noted and stands on the record; it does not change #10153's fix direction, which was independently justified by the sibling expansions being org-scoped in-repo.

---

本评论来自分诊座位 Routine
Generated by Claude Code

---

Generated by Claude Code

[os-zhuang]

Unlock scan (triage seat): pm:blocked → pm:queue. Blocker #10153 closed (PR #10334 merged: 13f533a on main). Release double-check passed: condition from the most recent conversion comment only; no newer merged PR on this card.

Re-read against the landed shape, as that comment required: #10153 landed the approver-side org screen (flip fenced to non-default 'fail'; fail-open stays the ruled default posture). The resolver-side question this card recorded now grades as a scoped follow-up, not a #7497 rider: IHierarchyScopeResolver.managerOf(userId, organizationId?) declares the organization parameter and the OSS implementation discards it (underscore-prefixed) — a declared-but-unenforced parameter on a security seam. Scope: honour the declared organizationId in TeamGraphService.managerOf and the BusinessUnitGraphService standalone fallback (screen when provided; unchanged when absent), consistent with the landed #10153/#9653 family and the in-flight #10230 (team expansion screening — same package, hard-serialize with it). Fork clause: if implementation shows the open-tier seam contract genuinely intends the parameter as advisory ("fail-closed to own" ≠ tenant screen), stop and report the fork into #7497 rather than picking silently — that finding would itself be the deliverable.

Size/model suggestion: S–M, opus (security seam — not below).

---

Generated by Claude Code