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]

Blocked-by: objectstack-ai/objectui#5401

⛔⛔ STOP — steps 2 and 3 of "What is owed" below are STRUCK. Do not execute them.

A browser round on 2026-08-20 measured them to break both banners. Applying has() to these two predicates takes a banner that is currently correctly hidden and makes it permanently visible: on a todo task the "Awaiting review" banner appears; on a verified user "Email not verified" appears next to the page's own chip reading "Email Verified: Yes". Screenshot-confirmed, both pages, in the real console at the pinned objectui SHA.

They are struck because they are the instruction a future agent would mechanically follow. Evidence: report comment on this issue, 2026-08-20. The rest of this body is the original filing and is preserved.

Status: pm:blocked on objectstack-ai/objectui#5401, which carries the ruled fix (record:alert must consume the declared visibleWhen gate). ⛔ The follow-up here — moving these two predicates to visibleWhen with has() guards — must not start before that lands and the objectui pin advances. Today it breaks both banners.

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

⚠️ The title's attribution is also falsified

"same sparse-face fault class as #8990" is not true of these two predicates. Measured: both are served as bare strings, so both run on objectui's legacy JS evaluator, where a missing key is undefined and undefined == 'in_review' is plain false — not a fault. The absent-key fault class does not reach this surface at all. What the card found is real; what it named it is wrong.

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.

⚠️ Both are bare strings. An earlier PM note claimed sys-user.page.ts:79 carried a {dialect:'cel'} envelope while only task-detail.page.ts:51 was bare; that was wrong — it mis-attributed a count taken over defineAction-normalized action predicates in the built artifact. Measured three ways (authored source, built dist, served /api/v1/meta/page) the two pages are identical on every dimension tested. ⛔ They are one case, not two, and that correction is not to be re-inherited.

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.

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.

✅ That measurement has now been done (2026-08-20, real console at pinned objectui 9a3daf8d, Playwright/chromium). Both hypotheses resolved: fail-soft confirmed by observation; the detail read does project every declared column (25/26 and 25/25, the only absent key being the __search companion objectql withholds by rule #7642); and the forced-sparse case does not fault — it evaluates to false and hides, because the predicate never reaches CEL.

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. 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, on both the platform sys_user page and the showcase task-detail page. — ✅ DONE 2026-08-20.
2. If the binding can be sparse, guard both predicates per the rule on materializeDeclaredFields in @objectstack/objectql — has() alone for these two. ⛔ STRUCK — measured harmful. has() throws on the legacy evaluator these predicates actually run on, and on a fail-soft surface a throw means VISIBLE.
3. If the direction is fail-SOFT, the guard is not merely cosmetic: it changes a permanently-shown banner into a correctly-hidden one, and wants its own before/after. ⛔ STRUCK — the polarity is backwards. The banners are currently correctly hidden in the sparse case; the guard is what makes them wrongly shown. The before/after was run and it runs the other way.

The real finding, and where it now lives

record:alert silently ignores the declared, spec-normalized visibleWhen gate that the sibling block on the same page honours — page.zod.ts:189 declares visibleWhen: ExpressionInputSchema, while properties is an opaque z.record(z.string(), z.unknown()) bag whose visible key nothing normalizes. That is declared ≠ enforced on the objectui side, and it is the same pair of defects already closed on the record-header face (objectui#3521, #4213, #4419). Ruled 2026-08-20 and filed as objectstack-ai/objectui#5401.

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

[os-zhuang]

Unlock-scan release (triage seat, session session_012XVwvSDo9v5TFLgc8hFfLC): pm:on-hold → pm:queue. The hold's restart condition (closed #9281) fired — #9281 closed 2026-08-20T01:39Z and its dev report explicitly names this card as the consumer of its measurement. Release double-checks passed: condition is from the most recent hold transition; no newer merged PR on this card.

Scope caveat carried from #9281's report: that run measured the header/action face speaking CEL — it supplies this card's input, it does NOT answer this card's question. The page-block record:alert face (binding sparseness + fault direction, fail-open vs fail-soft) is still unmeasured on both named pages (sys-user.page.ts:79, task-detail.page.ts:51), and the three-step "what is owed" in the body stands as the spec. Dispatch shape: browser/dogfood measurement job (mode:cloud, same form as #9281's run), measurement before any rewrite.

---

Generated by Claude Code

[os-zhuang]

Unlock sweep: blocker cleared AND the pin precondition is measured satisfied. pm:blocked → pm:queue (paired write, same stroke).

This card set a two-part release condition, not one — quoting its own body:

⛔ The follow-up here … must not start before that lands and the objectui pin advances.

Both halves measured:

half	reading
blocker objectstack-ai/objectui#5401 lands	CLOSED 2026-08-22T12:05:11Z — closed as satisfied by objectui#5505, whose binding commit is c86185eb5 "Bind record into node-level visibleWhen, and stop visible swallowing it", merged 2026-08-21 08:09:49Z
the objectui pin advances	.objectui-sha on origin/main = 190fbd01d0615e2e168faf9e08b8ad7844bc039d (2026-08-22 20:42:50Z). git merge-base --is-ancestor c86185eb5 190fbd01d → true — the pin contains the binding

The ancestry was measured, not inferred from dates (the local checkout was shallow and answered "not a valid object" first; re-run at --depth=800 before the test).

⚠️ Read this before acting on the struck steps

Steps 2 and 3 of "What is owed" are struck with ⛔ because a 2026-08-20 browser round measured them harmful — applying has() guards turned two correctly-hidden banners into permanently-visible ones.

That measurement was taken under pre-binding physics. At the time, node-level visibleWhen bound no record at all, so a record.* predicate could not resolve and fail-softed to visible. c86185eb5 is precisely the commit that changed that. The strike may therefore be stale — but ⛔ do not un-strike it on this comment's say-so. Re-run the measurement first; the strike stands until something measures it false, and this card's whole history is a record of what reasoning-instead-of-measuring cost here.

Useful prior art for whoever takes it: objectui#5401's retrospective survey (comment 5380283415) found 2 authored record.* sites reaching the node gate, 0 verdict changes from the binding — and the two sites it names are exactly this card's two predicates.

Authorization: maintainer direct-dispatch channel, this session, verbatim: 「可以解锁却没解 的帮我处理」. PM session session_0124Qg8rLvpXnQDwCmpKUmaJ.

⛔ Assignee untouched · scope untouched · domain:* untouched · struck steps left struck.

---

Generated by Claude Code