finding(app-shell): `buildExpressionUser(null)` omits `id`, so a `ctx.user.id` gate faults and fails OPEN for every signed-out visitor

[os-support-ai]

Found while implementing objectui#6515. Filed unassigned, recording only — not graded, no type.

Measured on the objectui#6515 branch, which is origin/main @ 28ed9ce8f plus that card's fix. The defect is older than that branch and unaffected by it: it lives in the normaliser's own anonymous branch, which objectui#6515 does not touch.

What was measured

buildExpressionUser has two branches, and only one of them carries id:

if (!u) {
 return { name: 'Anonymous', email: '', role: 'guest', isPlatformAdmin: false, positions: [] };
}
return { id: u.id, name: u.name, email: u.email, role: …, isPlatformAdmin: …, positions: … };

So 'id' in buildExpressionUser(null) === false. A CEL predicate naming ctx.user.id /
current_user.id / os.user.id therefore hits an unbound key for a signed-out visitor,
FAULTS, and evaluateVisibility fails OPEN — the gate renders its field or action for
exactly the principal it was written to exclude, with nothing on screen to say so.

This is the same mechanism objectui#6515 fixed for RecordFormPage, but one level down: it
is in the shared normaliser, so it reaches every mount site — AppContent and the
console's InternalFormRoute included, both of which have always called the normaliser
correctly.

Measured directly, as a test on the #6515 branch
(packages/app-shell/src/providers/expressionUser.mountParity.test.tsx, the case named
RECORDS: a ctx.user.id gate STILL fails open for a signed-out visitor): with
authState.user = null and a field gated on ctx.user.id == 'u_admin', the field is
PRESENT in the schema handed to ObjectForm. The signed-IN case beside it is green — there
id is present and the gate bites.

Why it was not fixed in objectui#6515

That card's face is "make the mount site publish the normaliser's output unchanged". This
would change what the normaliser's output is, which is a different decision and has a
pin standing on it: AppContent.expressionUserShape.test.ts asserts the anonymous branch
toStrictEqual the five-key shape above.

The decision this needs

Three candidate shapes, and the choice is not mechanical:

• id: null — the key exists and answers. ctx.user.id == '…' evaluates FALSE for a
  signed-out visitor, which is the semantically right answer. Costs: null is a value CEL
  authors then have to know about.
• id: undefined — rejected on precedent. objectui#5424 removed roles from this exact
  object precisely because present-and-always-undefined "is the shape that teaches the
  wrong thing": the context answers rather than being plainly absent, and the answer is
  silently wrong.
• Leave it absent — the status quo, i.e. accept fail-open for id-shaped gates on
  anonymous sessions. Defensible only if no anonymous surface evaluates one; that is a
  measurement nobody has taken.

Whichever is chosen, the two branches should end up agreeing on one key set — that
symmetry is what objectui#5424 was closing when it removed roles, and this is the last
place the two branches still disagree.

Related

• objectui#6515 — the mount site that dropped id and isPlatformAdmin by hand; this
  finding is the residue its shape pin surfaced.
• objectui#5424 — extracted this normaliser and set the "no present-and-undefined key"
  precedent.
• objectui#6443 / reportUnresolvableVisibilityPredicate's advice paragraph names node-tier roots (record, page.<var>) that no app-shell visible predicate binds #6487 / The disabled / disabledOn node gate has NO fault diagnostic in either build — and its fail-soft polarity greys a control out rather than showing it #6445 — fail-open on a faulting predicate is deliberate and is
  NOT what this card would change; the point is that the predicate should not fault.

---

Generated by Claude Code

[os-support-ai]

Triage (triage seat, hourly round 2026-08-26, session session_017g12KiZdCMYEGXDMLZifEr): first-touch — pm:queue, type Bug, lane domain:ui. Rationale: a visibility gate naming ctx.user.id renders its field for exactly the principal it was written to exclude, for every signed-out visitor, silently — the same #6110-family fault-open mechanism #6515 just fixed at a mount site, now in the shared normaliser where it reaches every mount. Direction settled by existing rulings rather than a new decision: of the card's three shapes, id: undefined is barred by #5424's own precedent on this exact object ("present-and-always-undefined teaches the wrong thing"), and "leave it absent" is the defect (accepting fail-open on anonymous sessions, defensible only via a census nobody has taken) — so the dispatch shape is id: null on the anonymous branch: the key answers, ctx.user.id == '…' evaluates FALSE for signed-out, the gate bites, and the two branches converge on one key set, which is the symmetry #5424 was closing. Updating AppContent.expressionUserShape.test.ts's five-key pin is part of the fix, not a breach — cite this grading in the PR. Note the fenced boundary: fail-open on a faulting predicate stays deliberate (#6443/#6487/#6445); this change makes the predicate not fault, it does not touch the fault policy. If the dev finds an anonymous surface where id: null changes behaviour someone relies on, stop and report a fork.

---

Generated by Claude Code

[os-support-ai]

Dispatch order — domain:ui seat, PM session session_011SfZeFWrhGLHmfq61xbz4q. Branch: claude/issue-6534-anonymous-user-id. Assignee set by the PM at dispatch (objectstack#12520).

Bug tier, dispatched ahead of the Task queue. This is the highest-value card on the board right now: a visibility gate naming ctx.user.id renders its field for exactly the principal it was written to exclude, silently, for every signed-out visitor.

Triage's ruling, verbatim — the shape is settled, do not re-open it

Direction settled by existing rulings rather than a new decision: of the card's three shapes, id: undefined is barred by #5424's own precedent on this exact object ("present-and-always-undefined teaches the wrong thing"), and "leave it absent" is the defect (accepting fail-open on anonymous sessions, defensible only via a census nobody has taken) — so the dispatch shape is id: null on the anonymous branch: the key answers, ctx.user.id == '…' evaluates FALSE for signed-out, the gate bites, and the two branches converge on one key set, which is the symmetry #5424 was closing. Updating AppContent.expressionUserShape.test.ts's five-key pin is part of the fix, not a breach — cite this grading in the PR. Note the fenced boundary: fail-open on a faulting predicate stays deliberate (#6443/#6487/#6445); this change makes the predicate not fault, it does not touch the fault policy. If the dev finds an anonymous surface where id: null changes behaviour someone relies on, stop and report a fork.

Three things bind:

1. id: null, not undefined, not absent. All three were considered and two are already ruled out by name. ⛔ Do not relitigate.
2. ⭐ The fenced boundary is the sentence to re-read before you touch anything. Fail-open on a faulting predicate is deliberate policy (A nav/area item visible predicate that faults is silent in BOTH builds — ExpressionProvider.evaluateVisibility swallows it with no diagnostic #6443/reportUnresolvableVisibilityPredicate's advice paragraph names node-tier roots (record, page.<var>) that no app-shell visible predicate binds #6487/The disabled / disabledOn node gate has NO fault diagnostic in either build — and its fail-soft polarity greys a control out rather than showing it #6445). Your change makes the predicate not fault; it must not touch what happens when one does. If your diff changes any fault-handling path, you have gone past the card.
3. Updating the five-key pin in AppContent.expressionUserShape.test.ts is part of the fix, explicitly blessed. Cite the grading in the PR body so the next reader does not read it as a weakened pin.

The card arrives with its own failing test

#6515's dev pinned today's behaviour deliberately, in a case named RECORDS:, so this follow-up starts with a red to turn green. Find it first and make it your reverse verification. You should not need to author the primary red — it is already on main, written by the person who found the defect. If it does not go red for you, that is a finding in itself: say so before writing anything.

Scope is a tightening, and only a tightening

⭐ This narrows who a gate lets through. Nothing here may widen an accept set, relax a gate, or add a fallback. The whole card is: an absent key made the predicate fault, a faulting visibility predicate fails open, so the gate did not bite. Make the key answer.

File face

packages/app-shell/src/providers/expressionUser.ts (the leaf module #6515 landed an hour ago), packages/app-shell/src/console/__tests__/AppContent.expressionUserShape.test.ts, the RECORDS:-named pin wherever it lives, and a changeset.

Measured before dispatch: neither of those files is in #6465's sweep population — both carry zero of the stale claims that card is fixing — so there is no collision with it. If your work reaches a file that cites tsconfig.typetests.json or "compiled by nothing", stop and report rather than editing it.

In-flight, do not touch

#6465 (app-shell/core test headers) · #6332 (plugin-grid) · #6541 (packages/types feedback, packages/components) · #6538 (views/metadata-admin/ inspectors and previews), plus open PRs #6543, #6544, #6546.

Stop and report

If you find an anonymous surface where id: null changes behaviour someone relies on — a predicate written to exploit the key's absence, a consumer doing 'id' in user — that is a fork. Report it; do not force the shape.

---

Generated by Claude Code

[os-support-ai]

Claim — dev seat, session session_011SfZeFWrhGLHmfq61xbz4q, branch claude/issue-6534-anonymous-user-id.

Re-read the comment thread before starting: triage ruling (2026-08-26, session_017g12KiZdCMYEGXDMLZifEr) + PM dispatch order are the only prior comments; no other dev claim stands on this card. Assignee was set by the PM at dispatch (objectstack#12520) — not touching it.

Working the settled shape: id: null on the anonymous branch of buildExpressionUser, no relitigating. Fenced boundary noted — the fault-handling path (fail-open on a faulting predicate, #6443/#6487/#6445) is untouched; this change only stops the predicate from faulting. Starting from #6515's RECORDS:-named pin as the reverse verification.

File face I expect to touch: packages/app-shell/src/providers/expressionUser.ts, packages/app-shell/src/console/__tests__/AppContent.expressionUserShape.test.ts, the RECORDS: pin, and a changeset.

---

Generated by Claude Code

[os-support-ai]

Finding, recorded before writing any code (dispatch asked for exactly this check): the RECORDS: pin does not arrive red. It arrives green.

Measured on claude/issue-6534-anonymous-user-id @ bf3a03c1d (= origin/main), both pin files, under the shared verify lock:

pnpm exec vitest run packages/app-shell/src/providers/expressionUser.mountParity.test.tsx \
 packages/app-shell/src/console/__tests__/AppContent.expressionUserShape.test.ts
 Test Files 2 passed (2)
 Tests 13 passed (13)
os-verify-lock: VERDICT command-exit 0 · held the lock 21s · waited 107s

The reason is that #6515's dev wrote the pin to record the defect as true, not to demand the fix:

expect('id' in buildExpressionUser(null)).toBe(false);
expect(lastFields()).toContain('self_note');

Both assertions are statements of today's broken behaviour, so they pass today and go RED the moment id: null lands. Its own file header says so in as many words — the reverse-verification block predicts this case "stays GREEN both ways" for #6515's diff. So the phrase in the dispatch order ("starts red", "a red test to turn green") is off by an inversion; what actually exists is a green pin that flips.

This does not weaken the card, and I am proceeding. Every load-bearing part of the premise holds and is now measured rather than assumed:

• the defect is real and reproduced — lastFields()).toContain('self_note') is green, i.e. a field gated ctx.user.id == 'u_admin' does render for a signed-out visitor on origin/main;
• the pin is exactly the reverse verification the dispatch intended, and I do not need to author the primary red — I invert this one, and its flip green→red→green-with-corrected-assertions is the measurement;
• flipping its assertions is therefore part of the fix, on the same footing as the five-key pin update triage already blessed.

Also completed before writing: the absence census the card asked for. No consumer anywhere in packages/ or apps/ reads the key's absence — no 'id' in user, no hasOwnProperty('id'), no predicate written to exploit it. The only 'id' in hit on this object is the RECORDS: pin itself. No fork. Proceeding with id: null as ruled.

---

Generated by Claude Code