docs(glossary): name the real Record Share recipient kinds

[os-zhuang]

Fixes#80

The glossary's Record Share entry named role and group. Neither is a recipient kind: ADR-0090 D3 renamed role to position and the pre-D3 group to team. It also omitted unit_and_subordinates and business_unit entirely — so of the five real kinds the entry named one, and taught two dead ones to the page a newcomer reads first.

The answer, from the schema

ShareRecipientType in packages/spec/src/security/sharing.zod.ts on objectstack@origin/main is exactly:

'user', 'team', 'position', 'unit_and_subordinates', 'business_unit'

The same file documents both renames and the removals in its own words (group renamed to team; guest dropped because anonymous access is the public-form grant / share-link surface; queue reserved and deliberately not authorable). sys_record_share.recipient_type is the column that carries these values — this site's own changelog already records the role to position migration at content/docs/resources/changelog.mdx:212 and :260, which the glossary contradicted.

Decision: all five kinds, not a readable subset

The card left open whether the entry should name all five or a subset. It names all five, for three reasons:

1. The defect being fixed is a subset — the entry named one real kind out of five. An entry that lists three of five is how this defect happened the first time; shipping another subset re-arms it.
2. Five fits in one readable clause, and that is not a guess: content/docs/configure/permissions/record-access.mdx:66 already enumerates the full set in house phrasing ("a user, team, position, business unit, or a unit and its subordinates"). The glossary now agrees with it rather than competing with it.
3. Each prose name is paired with its canonical recipient_type spelling. The stated cost in the card is a reader who authors recipient_type: 'role' and matches nothing — prose alone would still leave them guessing whether "a business unit and its subordinate units" is spelled unit_and_subordinates. Declared equals enforced only helps if the doc prints the declared spelling.

Nothing was left out, so there is no omission to justify.

Scope

One entry in one file. In particular the duplicated Console entry in this same file is untouched — it is #89's subject and governed by the #79 naming decision.

The locale siblings of glossary.mdx are left alone per AGENTS.md; they now report stale, which is by design and non-blocking.

Out-of-scope finding — reported, not edited

Filed as #91: content/docs/build/interface/actions.mdx:170 glosses the built-in share action as "Direct share with a user / role" — the identical retired-vocabulary pattern in a second file, outside this card's file surface. That issue also records two weaker adjacent observations for triage (index.mdx:43, record-access.mdx:15). No edits were made to any of them here; #91 is not addressed by this PR.

Verification — all at b091442, the pushed head

Check	Result
pnpm turbo run type-check --force	pass — cache bypass, force executing 4652eecd91dea0a7, not FULL TURBO
pnpm turbo run build --force	pass — cache bypass, force executing 50e5be14a3f9c414, Compiled successfully in 55s, 740/740 static pages
check-translation-ownership.mjs	pass — 0 translation artifacts touched, 1 other file
check-translations.mjs (freshness)	pass — translations gate passed; the six glossary.*.mdx siblings report stale, as designed
check-translation-output.mjs --self-test	pass — 20 cases, every rule demonstrated able to fail
check-translation-output.mjs --files	pass — blocking on 0 changed translations; 110 pre-existing corpus findings reported, none from this page

Rendered HTML was read, not just the diff: apps/docs/.next/server/app/en/docs/resources/glossary.html renders the entry with all five values as code spans, the #record-share anchor and its TOC link intact, and no occurrence of role or group as a recipient kind anywhere on the page.

---

Generated by Claude Code