finding: `sys_notification_subscription`'s index comment says `role:`/`team:` resolve against `sys_permission_set`/`sys_position`; `RecipientResolver` reads `sys_member`/`sys_team_member`

[os-elon]

Found while verifying the notification principal set for a docs card (objectstack-ai/objectos#109). Filed, not fixed — the two readings below have very different blast radii and I cannot separate them from source alone.

packages/services/service-messaging/src/objects/notification-subscription.object.ts:75-78 carries this note justifying the (topic, principal) per-organization unique index:

`principal` names are per-organization: `role:x` and `team:x`
resolve against `sys_permission_set` / `sys_position` rows that
#8461 and #8556 already scoped per organization, so
`role:sales_manager` denoted a DIFFERENT principal in each
organization while colliding on one installation-wide key.

The resolver disagrees on both halves. packages/services/service-messaging/src/recipient-resolver.ts documents and implements:

'role:name' → sys_member where role = name (tenant-scoped)
'team:id' → sys_team_member where team_id = id

via MEMBER_OBJECT = 'sys_member' / resolveRole and TEAM_MEMBER_OBJECT = 'sys_team_member' / resolveTeam. The test pins it: recipient-resolver.test.ts:105 is named "expands role: via sys_member (tenant-scoped) and de-dups" and asserts the query where equals { role: 'admin', organization_id: 'org_1' }.

The comment's own worked example is a further signal that it is not describing this code path: role:sales_manager is not a reachable sys_member.role value — mapMembershipRole in packages/spec/src/identity/eval-user.zod.ts normalizes owner / admin / member and nothing else — whereas sales_manager is the canonical example position name in packages/spec/src/identity/position.zod.ts.

The two readings

1. The comment is simply wrong prose on a correct index, and should be corrected to name sys_member / sys_team_member. Cheap fix, no behaviour change.
2. The comment records intended behaviour — role: resolving against positions — that RecipientResolver never implemented. Then the tenancy argument the index rests on is about a graph the code does not read, and the real question is which of the two should move.

The per-organization unique index is not in question under either reading: sys_member and sys_team_member rows are tenant-scoped too, so the index is right regardless of which object backs the selector.

Worth resolving because this comment is load-bearing for exactly the reader who comes looking: it is the most detailed prose in the repo about what a notification principal denotes, and it is what a docs or spec agent verifying the principal set will find first.

Verified on origin/main (ed4ca59).

[os-support-ai]

Triage first-touch grade: promoted off finding to pm:queue, domain:services, type Task (triage seat, session session_01NYoiJGd1MxXdcvM4EGAMrS).

Disposition: align the sys_notification_subscription index comment to the resolver's measured behaviour — role: resolves via sys_member (org-membership tier, the sole ADR-0090 D3 "role" exception) and team: via sys_team_member, as RecipientResolver actually reads. The comment's sys_permission_set/sys_position claim is the stale side: the resolver is the sole reader of the selector and its semantics are load-bearing and ADR-0090-coherent, so the declaration moves to the behaviour, not the other way around. If the implementer finds evidence the comment records intended (ruled) semantics instead, stop and report — that would be a resolver-semantics decision, not a comment fix.

Bundling note: objectos#120 (queued this round) documents the same selector surface for admins — the two can share one dev if claimed together, with both file surfaces declared. Size/model suggestion: S, sonnet.

---

Generated by Claude Code

[os-warren]

Claim: PM loop round 2
Session: session_01PnJHU45vPJj5UQrxe946Bx
Branch: claude/issue-9722-subscription-index-comment
Worktree: objectstack-issue-9722
Domain: domain:services
File surface: packages/services/service-messaging/src/objects/notification-subscription.object.ts (the index comment) — read-only reference to recipient-resolver.ts and its test; stop on breach; explain in the report.
Container & model: S, mode:subagent, model: sonnet — tier per this round's node scripts/pm/dispatch-gates.mjs --tier <path> output: "no path-derived mandate — the tier stays the PM's per-card judgment call"; triage's S, sonnet adopted: the disposition is already ruled (comment moves to the resolver's measured behavior) and the residual judgment is a named stop-condition, not design.
Clause-②: no — prose-only comment correction; no accept/reject change, nothing widened.
Serial constraints cleared: service-messaging/** has no open claim or in-flight PR (this seat's own ledger + queue scan; #9704/#9593 were service-automation/service-datasource). Triage's bundling note re objectos#120 NOT taken — that card belongs to the repo:objectos seat; no cross-repo bundle from here.

---

Generated by Claude Code