docs(pages): fix the component visibility example to read a key EvalUser has

[os-elon]

Fixes#119

One line, in content/docs/build/interface/pages.mdx:

- visibility: "os.user.profile == 'sales_manager'",+ visibility: "'sales_manager' in os.user.positions",

The defect

os.user is bound by buildScope (packages/formula/src/stdlib.ts on objectstack@origin/main) to the canonical EvalUser, and that object is exactly:

{ id, name?, email?, positions, isPlatformAdmin?, organizationId? }

There is no profile key — so the published example was not merely using an old word, it read a key that is never bound, and the predicate could not evaluate to what the example demonstrates. Same defect class as the Tier 1 half of #109, which corrected the equivalent line in reference/cel.mdx.

Why this expression, and not a guess

The card was explicit that the corrected expression needs an inference about author intent, so the evidence is set out rather than asserted.

What the example has to demonstrate is fixed by its surroundings. The snippet sits directly above the component property table, and the visibility row in that table reads "CEL visibility predicate". The example's job is to show a component gated on who the signed-in user is. Nothing in the prose teaches a profile concept, or any other identity model — there is no second thing it could be teaching.

Exactly one expressible form satisfies that.positions is the only membership field on EvalUser (ADR-0068 D1; renamed from roles by ADR-0090 D3, whose doc comment records that a singular membership field is deliberately not part of the contract). The docs' own key table already says so: reference/cel.mdx:69 documents os.user as { id, name, email, positions: string[], organizationId }.

The literal was already a position name.sales_manager is verbatim the first entry under "Good position names" in packages/spec/src/identity/position.zod.ts. The example did not need a new literal chosen for it; only the access path was wrong.

The corpus already spells this predicate, twice.reference/cel.mdx:124 has 'manager' in os.user.positions — the same os.user root this line uses — and build/interface/apps.mdx:110 has 'org_admin' in current_user.positions. The corrected line matches an established spelling instead of inventing one. os.user was kept over current_user because it is the root the line already used and the aliases are the same object.

The competing reading, and why it does not change the answer

profile is not a word the author invented: assignedProfiles is a real page-level key (packages/spec/src/ui/page.zod.ts), and the spec's own page.test.ts fixtures spell assignedProfiles: ['admin', 'sales_manager', 'sales_rep'] — so sales_manager appears as a profile name too. The author may well have been reaching for that.

It does not change the correction, because that reading has no expressible form here. Profiles are not bound into the CEL scope at all, there is no sys_profile object anywhere under packages/, and assignedProfiles gates the whole page, not a component inside a region. Writing the example that way would mean deleting the component-level predicate the property table documents. Both readings of intent therefore converge on the same corrected line — which is what made this a recoverable inference rather than a needs_decision.

Scope

One file, one line. Two things deliberately left alone:

• The key is still spelled visibility, which ADR-0089 deprecated in favour of visibleWhen. Different defect class (a deprecated-but-normalized alias, not an absent key), so it is filed separately as build/interface/pages.mdx is the last page teaching the deprecated component key visibility instead of visibleWhen #129 and is not addressed here.
• pages.zh-Hans.mdx still carries the old expression. Translations are the translation account's, never hand-edited; the freshness gate treats stale as non-blocking by design.

Gates

All run on 4353b8d, Node v22.22.2, in this worktree, with --force to bypass the shared turbo cache.

Gate	Exit
pnpm install --frozen-lockfile	0
pnpm turbo run type-check --continue --force	0
pnpm turbo run build --force	0
pnpm turbo run test --force	0
node .github/scripts/check-translations.mjs	0
node .github/scripts/check-translation-ownership.mjs --actor os-elon --files changed.txt	0 (inert — TRANSLATION_BOT_LOGIN unset, per #68; 0 translation artifacts touched)
node .github/scripts/check-translation-output.mjs --self-test	0
node .github/scripts/check-translation-output.mjs --files changed.txt	0 (133 pre-existing findings reported, none in this diff)

Measured against an origin/main baseline worktree: pages.zh-Hans.mdx already carried one fence finding before this change (fence #5). After it, the file still carries exactly one, now reported at fence #3 — the components example. The count is unchanged and the finding is non-blocking.

---

Generated by Claude Code