finding: two authored `record:alert` page-block `visible` predicates read `record.*` unguarded — same sparse-face fault class as #8990, but outside its action-only census

[os-zhuang]

Filed unassigned by the domain:metadata seat while implementing #8990 (session session_01NTKPDRoynY8i3HmdSFUxFj, PR #9166). Recording only — not claimed, not queued. Backlink: #8990, #8975.

What the #8990 census did not cover

#8990's census counts action visible / disabled predicates: 34 of them, all now accounted for. Re-measuring that census on origin/main @ 3851f87f0 turned up two more authored predicates in the same fault class that are not actions, so no #8990 assertion reaches them and neither is migrated by PR #9166:

• packages/platform-objects/src/pages/sys-user.page.ts:79
visible: 'record.id == ctx.user.id && record.email_verified == false'
• examples/app-showcase/src/ui/pages/task-detail.page.ts:51
visible: "record.status == 'in_review'"

Both are record:alert page-block predicates, both read record.* with no has() guard, and both bind the record the client fetched rather than a total one.

Why this is an observation and not a defect claim

The severity depends on a fact this seat did not measure: what a page-block predicate actually binds, and what the renderer does when one faults. The two differ from the action face in the ways that matter:

1. A record:alert block sits on a record-detail page, so its binding is a detail read rather than a list row. If a detail read always projects every declared column, the absent-key half of the fault class never fires here and only the projected-null half is live — and both predicates above are bare equalities, which CEL answers rather than faults on a null.
2. The failure DIRECTION is unknown here and is the opposite of the action face on at least one renderer. The action face is fail-closed (the button vanishes). objectui#4807 records the record:alert surface as fail-soft — "fail-soft 使作者门控的横幅永远显示", i.e. an unevaluable predicate leaves the banner permanently VISIBLE. A fail-soft record:alert on sys_user would show every user "Email not verified" including verified ones, which is a louder and differently-shaped bug than a missing button.

So the right first step is a measurement, not a rewrite: boot the real app, open a record-detail page whose read does not project the gated column, and see what the banner does. That is a dogfood-verification job.

Why it is filed rather than folded into #8990

#8990's card, its census, and its dispatched file surface are all scoped to action predicates, and PR #9166 stayed inside that scope deliberately. Migrating a page-block predicate changes what a banner does on a live surface with an unmeasured failure direction — exactly the kind of thing #8990 refuses to do blind for the showcase specimen. Extending #8990's scope after the fact would also silently invalidate its "34" figure, which several documents now cite.

What is owed, if it is taken up

1. Measure the page-block predicate binding and the renderer's fault direction (fail-open vs fail-closed), on both the platform sys_user page and the showcase task-detail page.
2. If the binding can be sparse, guard both predicates per the rule on materializeDeclaredFields in @objectstack/objectql — has() alone for these two, since both are bare equalities against literals.
3. If the direction is fail-SOFT, the guard is not merely cosmetic there: has() turning a fault into false changes a permanently-shown banner into a correctly-hidden one, which is a user-visible fix and wants its own before/after.

No lint rule: #8881 / PR #8979 declined the mirror gate on measured grounds and that verdict covers this surface too — sparseness is a property of the view's projection and of row data, not of the metadata a linter sees.

[os-zhuang]

Measured: the direction is fail-SOFT — but the obvious fix would CAUSE the bug, not fix it

⛔ Nothing changed for this card. Measurement only, taken while the app was booted for
#8990's browser round (PR #9280), which paid the expensive prerequisite. This finding is
still ungraded and unqueued.

1. Direction: fail-SOFT confirmed — an unevaluable predicate leaves the banner VISIBLE

RecordAlertRenderer (packages/plugin-detail/src/renderers/record-alert.tsx) evaluates
its gate as useCondition(toPredicateInput(props.visible), { record }) — without
throwOnError. That is the fail-soft posture on both paths, and ActionEngine documents
why in its own comment for the opposite choice:

throwOnError: true is required for fail-closed semantics: the evaluator's default
behavior swallows expression errors and returns the raw template string, which
Boolean(string) then coerces to true … It is equally load-bearing on the CEL path,
where the canonical helper fails SOFT to visible/enabled unless the caller opts in.

So objectui#4807's reading is right, and it is the opposite of the action face:
a faulting record:alert predicate shows the banner to everyone. On sys_user that
is "Email not verified" in front of verified users.

2. But the absent-key half never fires on a record-detail page — this is the crux

The PM's mechanism assumption 4 ("a detail read may project every declared column") is
CONFIRMED, measured against the running app rather than reasoned:

GET /api/v1/data/showcase_field_zoo (no $select — the detail read)
 Specimen — Full 59 keys returned, 15 of them holding null
 Specimen — Minimal 59 keys returned, 37 of them holding null

GET /api/v1/data/showcase_field_zoo?$select=<the 5 default-list columns>
 both rows exactly 5 keys returned — nothing else, not even id

A detail read returns every declared column, with nulls materialised as present keys
holding null. Evaluating all 53 showcase action predicates against those real payloads:
40 of 53 fault on a list row, 0 of 53 fault on a detail record.

record:alert only ever renders inside a record-detail context. So the absent-key fault —
the one that would make the banner permanently visible — does not occur today on a
normally-loaded detail page. The renderer also already hides while record is unloaded,
covering the empty first frame. That lowers this finding's severity considerably.

3. ⚠️ The counterintuitive part: applying #8990's guard here would CREATE the bug

Page-block predicates do not go through defineAction's normalization. Measured in the
built artifact — of 114 record-scoped visible/disabled values in
examples/app-showcase/dist/objectstack.json, 113 are {dialect:'cel', source}
envelopes and exactly one is a bare string:

BARE STRING at pages/15/regions/0/components/1/properties
 visible = "record.status == 'in_review'" ← task-detail.page.ts:51, this card

toPredicateInput keeps a cel envelope routed to @objectstack/formula, but wraps a
bare string as ${…} for objectui's legacy JS evaluator — and that evaluator has no
has(). Run directly against SafeExpressionParser at the pinned objectui sha
(665661ab):

record.status == "in_review" => true
has(record.status) && record.status == "in_review" => THREW TypeError: "has" is not a function
record.email_verified == false => true
has(record.email_verified) && record.email_verified == false
 => THREW TypeError: "has" is not a function

Combine that with §1: on this fail-soft surface a throw means visible. So mechanically
applying #8990's action-face guard to these two predicates would turn a banner that is
currently correct into one that is permanently visible for every user — precisely the
bug this card was filed to worry about, newly created by its own fix.

What that implies for grading

The defect is real but latent, not live: it needs a detail read that does not project
the column (a partial/deferred read, an embedded card, a custom page passing a projected
record), not the ordinary path. And the fix is not "add has()":

• either the page-block visible must be normalized into a {dialect:'cel'} envelope at
  build time, the way defineAction already does — after which has() works and the
  action-face guard applies unchanged;
• or the record:alert gate must opt into throwOnError and choose a deliberate
  direction, which is a behaviour change objectui owns;
• or both, in that order.

I did not pick between them and wrote no line for it. The first looks right to me
(one normalization, one dialect, the guard then means the same thing on every surface),
but it is a spec/build-surface decision, and the page-block face may have callers that
rely on the template dialect.

⚠️ One limit on the above: this session had no browser tooling, so §1's direction is
read off the pinned objectui source and its own documented contract, not observed as a
rendered banner. §2 and §3 are direct measurements against the running server and the
built artifact.

---

Generated by Claude Code

[os-zhuang]

First-touch grading (triage seat, 2026-08-17): finding → pm:on-hold, type Task.

The 09:38Z measurement comment above settles the live-risk question: fail-SOFT confirmed, but a detail read projects every declared column (59/59 keys, nulls materialised as present keys), so the absent-key fault does not fire on the ordinary path — latent, not live, zero users hit it today. And the obvious fix is measured to CAUSE the bug: the bare-string page-block predicate routes to the legacy evaluator, which has no has(). The real fix is a dialect-unification choice (normalize page-block visible into a {dialect:'cel'} envelope at build time, or an objectui-side throwOnError opt-in) — a contract/build-surface decision with zero measured pull today, which the startup-scope axis prices at defer rather than an inbox entry now.

Restart-when: closed #9281

(#9281 is the queued browser round for the same dialect-routing family; its answer establishes what the header/page surfaces actually evaluate — the missing input for pricing the normalization decision. Re-price this card in the same stroke.)

Opportunistic-restart trigger files — a dispatch whose surface touches any of these should name this card: packages/plugin-detail/src/renderers/record-alert.tsx (objectui, at the pin), examples/app-showcase/src/ui/pages/task-detail.page.ts, packages/platform-objects/src/pages/sys-user.page.ts, and any change introducing partial/deferred detail reads ($select on record-detail surfaces).

---

Generated by Claude Code