Observation-class finding — documentation drift only, no behavioural defect. Filed unassigned for triage.
What
#7807 (PR #8097) narrowed the business_unit sharing-rule recipient to expand exactly one unit's members, per the maintainer ruling of 2026-08-12. The subtree walk is now unit_and_subordinates' own semantics, resolved through BusinessUnitGraphService.expandUsers; business_unit resolves through the new expandUnitMembers.
Two docstrings still say the subtree expansion drives the business_unit recipient:
packages/spec/src/contracts/sharing-service.ts:565 — the IBusinessUnitGraphService docstring: "Walks parent_business_unit_id to expand a department into the union of its members and all descendant members. Drives: recipient_type='business_unit' sharing rules".packages/platform-objects/src/identity/sys-business-unit.object.ts:17 — the same bullet, same wording.
Both should name unit_and_subordinates as the subtree consumer, and may mention business_unit as the narrow one.
Why it was not fixed in PR #8097
The #7807 ruling scoped packages/spec/** explicitly out of surface — the spec's authoring declaration (ShareRecipientType) was already correct and the ruling was that the runtime, not the declaration, was wrong. These two lines are a different thing from that declaration: they are prose on the graph-service contract and on the object definition, describing which recipient the resolver drives. Correcting them would have meant editing spec in a PR forbidden to, so they are recorded here instead of silently absorbed.
Severity
Low and stated plainly rather than graded: nothing reads these strings, and the authoring enum plus the lint red-line table — the two places an author or a linter actually consults — were correct throughout and remain correct. The cost is that a future reader of the contract can conclude business_unit is the subtree kind, which is exactly the confusion #7807 existed to end.
Backlink: #7807, PR #8097.
Observation-class finding — documentation drift only, no behavioural defect. Filed unassigned for triage.
What
#7807 (PR #8097) narrowed the
business_unitsharing-rule recipient to expand exactly one unit's members, per the maintainer ruling of 2026-08-12. The subtree walk is nowunit_and_subordinates' own semantics, resolved throughBusinessUnitGraphService.expandUsers;business_unitresolves through the newexpandUnitMembers.Two docstrings still say the subtree expansion drives the
business_unitrecipient:packages/spec/src/contracts/sharing-service.ts:565— theIBusinessUnitGraphServicedocstring: "Walksparent_business_unit_idto expand a department into the union of its members and all descendant members. Drives:recipient_type='business_unit'sharing rules".packages/platform-objects/src/identity/sys-business-unit.object.ts:17— the same bullet, same wording.Both should name
unit_and_subordinatesas the subtree consumer, and may mentionbusiness_unitas the narrow one.Why it was not fixed in PR #8097
The #7807 ruling scoped
packages/spec/**explicitly out of surface — the spec's authoring declaration (ShareRecipientType) was already correct and the ruling was that the runtime, not the declaration, was wrong. These two lines are a different thing from that declaration: they are prose on the graph-service contract and on the object definition, describing which recipient the resolver drives. Correcting them would have meant editing spec in a PR forbidden to, so they are recorded here instead of silently absorbed.Severity
Low and stated plainly rather than graded: nothing reads these strings, and the authoring enum plus the lint red-line table — the two places an author or a linter actually consults — were correct throughout and remain correct. The cost is that a future reader of the contract can conclude
business_unitis the subtree kind, which is exactly the confusion #7807 existed to end.Backlink: #7807, PR #8097.