docs(approvals): name delegated_admin in the org-membership tier vocabulary

[claude]

Fixes #131

content/docs/build/automation/approvals.mdx spelled the org-membership tier as a three-value set in two places. sys_member.role enforces four. A reader who set someone to Delegated Admin in Setup and came here to route an approval to that tier did not find it.

The fork in the card is resolved as drift — measured, not inherited

The card left one question open: whether the table row at :77 was correct as the approver picker's narrower vocabulary, with only the parenthetical (which describes the column) wrong. That rested on APPROVER_VALUE_BINDINGS.org_membership_level sourcing its options from a three-value constant.

It no longer does. On objectstack origin/main (072d072d2):

// packages/spec/src/automation/approval.zod.ts:153
export const ORG_MEMBERSHIP_LEVELS = BUILTIN_MEMBERSHIP_ROLES;

// :169
org_membership_level: { source: 'enum', values: ORG_MEMBERSHIP_LEVELS },

BUILTIN_MEMBERSHIP_ROLES is [owner, admin, delegated_admin, member] — "the WHOLE vocabulary, in display order (ADR-0108)". So the picker's vocabulary and the column's vocabulary are the same four values, by derivation rather than by a copy that can drift. The declaration's own comment records why:

A hand-spelled copy here carried the stale three-value list, so the one tier the column enforces but the copy omitted could not be authored as an approver. Deriving makes the drift unrepresentable.

Both sites are therefore wrong in the same way, and both take the fourth value.

Changes

Both in content/docs/build/automation/approvals.mdx, the only file touched:

• :77 — the approvers type table row now reads (`owner` / `admin` / `delegated_admin` / `member`).
• :88 — the position-vs-tier warning callout now reads owner`/`admin`/`delegated_admin`/`member. The role deprecated-alias note is preserved verbatim; the callout is reflowed to the file's ~80-column prose wrap, which is why six lines show in the diff for one inserted value.

Values are in ADR-0108 display order at both sites.

No gloss and no link, deliberately

The fourth value is listed, not explained. Three reasons:

1. content/docs/configure/notifications.mdx:137 — the page ruled correct, and the reference this card is bringing approvals.mdx up to — lists the same four tiers bare. Matching it is the consistency fix.
2. The one anchor that looks right, permissions/permission-sets#delegated-administration, documents the permission-set adminScope mechanism, which is a different thing. Upstream is explicit that the tier carries no authority by construction and that the two must not be merged ("Three facts that look like one — do not merge them", membership-role.ts). A link there would teach the conflation the spec warns against.
3. Defining the tier is a corpus-wide gap, not an approvals-page gap — filed separately rather than half-answered in a callout about a different confusion.

Verification

Gate union re-run at 955c359, the final commit, with a clean working tree:

Gate	Result
build (required) — turbo run type-check build test	Tasks: 3 successful, 3 total · Cached: 0 cached, 3 total
Node floor	✅ Every declared floor clears what the dependency tree requires, and the declarations agree.
Node floor self-test	✓ self-test: 14 rule case(s) and 18 range case(s)
Ownership & freshness — ownership	This PR touches 0 translation artifact(s) and 1 other file(s).
Ownership & freshness — freshness	✓ translations gate passed

Every turbo task ran under --force (cache bypass, force executing, 0 cached): AGENTS.md warns the turbo cache is shared across worktrees in this container, so a replayed green could have come from a sibling tree. None of these greens is replayed.

Rendered output, not just a green build. The prerendered HTML at .next/server/app/en/docs/build/automation/approvals.html reads:

An org-membership tier (owner / admin / delegated_admin / member)

The org-membership tier (sys_member.role: owner/admin/delegated_admin/member) is addressed as type: 'org_membership_level' since 16.0; the old spelling role is a deprecated alias for one release …

Per AGENTS.md §2 I should say so plainly: this was verified against the built HTML, not by driving a browser. For a prose-only MDX change with no component involved, the prerendered output is the stronger check, but it is not a browser run.

The stale locale sibling is intentional

content/docs/build/automation/approvals.zh-Hans.mdx:63 carries the identical wrong three-value list and is not touched here. AGENTS.md reserves locale files for the translation account; the freshness gate reports them non-blockingly. That file was already stale on main before this PR, so nothing new is broken — it is now stale for one more reason, and the next translation pass fixes it.

No changeset: this repo has no changeset flow.

---

Generated by Claude Code