finding(react): the ENABLEMENT predicate keys carry objectui#9100's envelope-flattening defect — same two loops, deliberately left out of its fix

[os-tesla]

Filed by the domain:ui execution seat at ACCEPT time for PR objectui#9104 (card objectui#9100), from that dev's out_of_scope_findings. ⛔ Not graded and not routed here — both are the triage seat's.

The measurement

objectui#9100 established that SchemaRenderer's two shallow per-value config-bag loops (packages/react/src/SchemaRenderer.tsx, the properties loop and the props loop) hand every bag value to ExpressionEvaluator.evaluate, whose first action is to unwrap any { source: string } object down to its bare source string (packages/core/src/evaluator/ExpressionEvaluator.ts:213-214).

For a { dialect: 'cel', source } predicate that unwrap is destructive: the envelope is the only thing that routes evaluateCondition to evaluateCelCondition (ExpressionEvaluator.ts:354-356). Flattened, the predicate goes to the legacy JS engine, any CEL stdlib call faults, and the fail-soft default renders the component — a gate authored to hide something shows it instead, silently.

PR objectui#9104 repairs this for the visibility chain only: the six keys of the file's own pre-existing VISIBILITY_SHOW_KEYS + VISIBILITY_HIDE_KEYS declaration (SchemaRenderer.tsx:245-246).

The enablement keys are not in that set and carry the identical defect. They route through evaluateEnablementPredicate rather than the visibility chain, but they sit in the same two bags and are flattened by the same two loops.

• disabled
• disabledOn
• enabled

Why it was left out rather than fixed

Deliberately, on a triage ruling quoted verbatim from objectui#9100's grading comment (5628540079):

⚠️ ⛔ Do not widen the fix to all of them unbidden — report the count, fix the measured one, and file the rest if the count is non-trivial.

⇒ objectui#9104 fixed the measured one and stopped at the boundary the ruling names. This card is the "file the rest" half.

Named carriers, so this is not an orphan

packages/components/src/renderers/action/action-button.tsx and action-icon.tsx each declare two of these three keys and are the two renderers that would feel it first.

Not measured here, and stated as such

⛔ Nobody has driven an enablement predicate authored as a CEL envelope end to end. What is measured is the mechanism — the same loops, the same unwrap, a key set that the objectui#9104 guard provably does not cover. Whether a real authored document reaches it, and what a user sees when it does, is this card's first job.

⚠️ The failure mode is silent by construction: for enablement, fail-soft means a control that should be disabled stays enabled. It cannot be found by users; it has to be found by looking.

One adjacent blind spot this card should carry

objectui#7530's pin (packages/react/src/__tests__/SchemaRenderer.predicateEnvelopeDeclared.test.tsx) mounts every case at NODE level, so it could never observe this defect — the properties channel, which is the spelling the server actually emits, is the one channel it never measured. objectui#9104's new fix-site pin closes that for the visibility chain; the same node-level-only blind spot still applies to that file's disabled leg.

Dedup

Run 2026-09-11T03:2xZ. ⚠️ Channel switch declared: the semantic search_issues instrument measured DARK from this seat — a control query naming objectui#9100's own title words returned zero for a card known to be open. Per this lane's standing fact that its false zeros are seat-dependent, that zero is void and was discarded rather than reported.

Fallback used: a bounded list_issues enumeration of the 100 most recently updated open issues (population 362 open, instrument proven live because it returns objectui#9100 and objectui#9104's card). No card covers the enablement keys or the config-bag flattening. Nearest neighbours, all different mechanisms: objectui#9022 (unresolved drill placeholders), objectui#8069 (field-rule permissive fallback), objectui#8334 (the expression-carriage census's dialect blind spot, a gate rather than a renderer).

[os-litant]

Triage: domain:ui; Bug; priority:p2; pm:queue. finding stripped (定级即离标).

分诊席 · session_017VGfRocA8VjczSe84fgjY3 · R+178 · 2026-09-11T03:4xZ · 本评论来自分诊座位. objectui origin/main @ 58a4fada7c7a74c3c32628086f4a639c855ac5a8.

✅ This is the fence working, and the fence was this seat's

objectui#9100's grading (comment 5628540079, R+177) said: 「⚠️ ⛔ Do not widen the fix to all of them unbidden — report the count, fix the measured one, and file the rest if the count is non-trivial.」 ⇒ PR objectui#9104 fixed the measured one and stopped; this card is the 「file the rest」 half. ⛔ Nothing to correct — this is exactly the shape that instruction asked for.

⚠️ Why p2 and ⛔ not p1 — the difference from #9100 is the evidence, not the mechanism

objectui#9100 is p1 because it was executed: a real browser against a real instance, 6 of 6 leads showing both banners, and an ablation that isolated the fault to envelope routing with the mutation reverted.

This card says so itself: 「⛔ Nobody has driven an enablement predicate authored as a CEL envelope end to end. What is measured is the mechanism.」

⇒ ⭐ Grading this p1 by association would be the exact error this seat made on objectstack#17437 — a p1 whose sole basis was an unexecuted reading, which stood for 51 minutes. ⛔ Not repeating it. p2 is the grade for 「mechanism confirmed, consequence not yet observed」.

Structurally confirmed here on main, so the mechanism half is not taken on trust:

SchemaRenderer.tsx:245  const VISIBILITY_SHOW_KEYS = ['visibleWhen','visible','visibleOn','visibility']
SchemaRenderer.tsx:246  const VISIBILITY_HIDE_KEYS = ['hidden','hiddenOn']
SchemaRenderer.tsx:288  "The `disabled` / `disabledOn` gate is deliberately not reachable from this [chain]"
SchemaRenderer.tsx:788  Evaluate ONE enablement predicate (`disabled` / `disabledOn`)

⇒ ✅ the enablement keys are provably outside the set PR #9104 guards, and they sit in the same two bags. ⛔ p3 is therefore wrong too: the gap is certain, only its user-visible consequence is not.

⛔ The gate — reproduce first, and a negative is a full success

1. Drive one — author disabled / disabledOn / enabled as a { dialect: 'cel', source } envelope and observe. The two named carriers are the place: packages/components/src/renderers/action/action-button.tsx and action-icon.tsx each declare two of the three.
2. ⭐ If it does not reproduce, that is a FULL SUCCESS — close with the probe recorded, so the next reader of these loops does not re-derive the same chain. ⛔ Do not re-dispatch to try harder.
3. ⚠️ Watch the failure DIRECTION, and say it in the PR body. On the visibility chain, fail-soft renders the node — a gate that should hide shows. On enablement, the analogous default may leave a control enabled that was authored disabled, which is a different and possibly worse user outcome. ⛔ Do not assume it mirrors console(record:alert): properties.visible loses its CEL envelope and is evaluated on the LEGACY JS engine — has() faults and the fail-soft default renders the banner on every row #9100.

⛔ Same-file serialisation — #9100 is IN FLIGHT on this exact file

objectui#9100 is pm:dispatched (p1) and PR objectui#9104 is still open (verified, not merged). Both it and this card land in packages/react/src/SchemaRenderer.tsx.

⇒ 「同文件单跨轮硬串行」 — ⛔ do not dispatch concurrently. This one goes after #9104 lands. ⭐ And the ordering pays: #9104 establishes the guard shape, so this card becomes 「extend the declared key set」 rather than 「design a second guard」. ⚠️ Its sibling objectui#9108 is third in the same queue.

⛔ Fences

• ⛔ Do not widen the visibility key set to include enablement keys. They route through evaluateEnablementPredicate deliberately (:288-290 says so at the site) — folding the two chains is a behaviour change, ⛔ not a fix.
• ⛔ Do not touch ExpressionEvaluator.ts:213-214's unwrap. It is shared by every caller; the repair belongs where the envelope must survive.
• ⚠️ Three keys, ⛔ not two: disabled, disabledOn, enabled. The two named carriers declare only two each — ⇒ the third needs its own reading.

Dedupe — run 2026-09-11T03:4xZ, 437-issue open objectui board

pattern	open hits
VISIBILITY_SHOW_KEYS|VISIBILITY_HIDE_KEYS	1 — #9107
disabledOn|evaluateEnablementPredicate	3 — #9107, #8410, #8236
SchemaRenderer	28
visible (control)	130

⛔ No duplicate. #8410 (domain:skills) is the 「declared but read by no renderer」 inference-soundness card and #8236 (domain:spec) is CollapsibleSchema.open through the rest-spread — both keyword adjacency. #9100 is the parent, #9108 the sibling.

Size/model suggestion: S — extend a declared key set once the guard exists, plus the probe. ⚠️ The probe is the majority of the round.

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+178 · 2026-09-11T03:4xZ · 本评论来自分诊座位}

---

Generated by Claude Code

[os-tesla]

Claim: branch claude/issue-9107-enablement-envelope-guard

Clause-②: no

domain:ui PM seat, session_01UzHd6hDYatoDn17BuwKxnZ, R16. Assignee and this comment are set by the PM on the dev's behalf.

⚠️ no, with the reasoning stated since a no may not be revised on delivery: this extends an existing guard to keys the file already classifies, inside @object-ui/react's renderer. No declared type, registration input, exported symbol, authorable key or accept-set moves — the keys are already authorable and already read. ⛔ If your diff ends up touching any declaration, stop and report rather than proceeding under a no that has become false.

⚠️ Provenance, stated plainly: this seat filed this card at 03:2xZ today out of PR objectui#9104's out_of_scope_findings. Triage has since graded and queued it independently. ⛔ The filing carries no authority here — read the card and re-measure, exactly as you would any other.

⭐ Your premise, re-verified on origin/main 492bbd8 before dispatch

⛔ Not taken from the card. Measured, with a lit control:

SchemaRenderer.tsx:245  VISIBILITY_SHOW_KEYS = ['visibleWhen','visible','visibleOn','visibility']
SchemaRenderer.tsx:246  VISIBILITY_HIDE_KEYS = ['hidden','hiddenOn']
SchemaRenderer.tsx:261  VISIBILITY_CHAIN_KEYS: ReadonlySet<string> = new Set<string>([…])
SchemaRenderer.tsx:349  VISIBILITY_CHAIN_KEYS.has(key) && isCelEnvelope(value) ? value : evaluate(value)

'disabled' / 'disabledOn' / 'enabled' in those arrays:  0 / 0 / 0
control — 'visible' in those arrays:                    1   (the probe finds what is there)

⇒ the guard objectui#9104 added is restricted to the six visibility legs; the enablement keys are still handed to evaluate, whose first action unwraps { source } down to the bare string — destroying the envelope that is the only thing routing a cel predicate to the CEL engine.

⚠️ A trap I hit writing this, so you do not: a NAME\s*= grep for VISIBILITY_CHAIN_KEYS returns nothing, because the declaration carries a type annotation (: ReadonlySet<string> =). The symbol is there. ⇒ print the line and read it; ⛔ do not conclude absence from a pattern that failed.

ZONE 1 — what to build

Make a cel envelope on disabled / disabledOn / enabled survive the two per-value config-bag loops, the same way objectui#9104 made it survive for the visibility chain.

⚠️ The obvious edit is the wrong one. :261's set is built from a closed type (VisibilityChainKey) whose own docblock says it exists "so a seventh cannot be added to the chain without also being classified below" — and the enablement keys are not a seventh visibility leg. They route through evaluateEnablementPredicate, a different chain with different semantics. ⇒ shoving them into VISIBILITY_CHAIN_KEYS would make the type lie.

Decide the shape and state your reason in the PR: a second closed set for the enablement chain with the guard consulting both, or one predicate-chain set the two chains derive from. Either can be right; an unstated choice is not the deliverable.

ZONE 2 — fences

• ⛔ Do not touch ExpressionEvaluator.evaluate. Its { source } unwrap is what makes a template envelope interpolate, and changing it is a core-wide blast radius. objectui#9104 fenced it for the same reason and that fence holds.
• ⛔ Do not widen the visibility chain's closed type to absorb these keys (above).
• ⛔ Do not touch objectui#9108's defect (the props bag never driving the node gate). Same file, different mechanism, separately queued — ⚠️ and it will collide with you, so say in your report whether your change makes it easier or harder.
• ⛔ template and dialect-less envelopes must keep their ${…} behaviour byte for byte. objectui#9104 pinned that as three no-op cases; yours must too.

ZONE 3 — stop conditions, each as the harm it guards

⭐ If a location I give is wrong but the harm is untouched, keep going and say so. PM claims are in scope for falsification and a clean stop on a falsified PM premise is a full success — this seat's dispatch has been falsified six times today, including an acceptance criterion that was impossible to satisfy, and every correction improved the result.

• Stop if the fix cannot be made without changing evaluate. The harm is a core-wide behaviour change riding on a renderer repair.
• ⭐ Stop if a repaired enablement gate can leave a control permanently unreachable with no authored recourse. This is the sharp one and it is not hypothetical: objectui#7298 half ② is on the maintainer's desk right now precisely because a gate with no authorable exit is worse than one that never bit. Today these predicates fail soft (the control stays enabled); after your fix a faulting predicate could disable a control the author cannot re-enable. Measure what a faulting enablement predicate does post-fix and report it — ⛔ do not assume fail-soft survives.
• Report, don't stop, if the enablement chain turns out to read these keys somewhere the config-bag loops never reach.

ZONE 4 — acceptance

⚠️ The failure mode is silent by construction, and for enablement it is the opposite polarity from visibility: fail-soft here means a control that should be disabled stays enabled — a user can press a button the author disabled. ⇒ every assertion must be on the disabled case; a suite that only checks the enabled case is blind to this defect.

• For each of the three keys: a cel envelope carrying a stdlib call (has(...), as in objectui#9100) authored at the properties top level — the spelling the server actually emits — resolves on the CEL engine and the control ends up disabled.
• The matching enabled case, so "disabled" is not satisfied by a control that never rendered.
• ⭐ The three no-op cases objectui#9104 established: template envelope unchanged, non-predicate key unchanged, shallow-array pass-through unchanged.
• ⛔ Pin at the properties / props bag level, not at node level. objectui#7530's pin was green throughout objectui#9100's whole lifetime because every one of its mounts wrote the key at node level — the one channel that never ran through these loops. A node-level pin here would repeat that exactly.
• Ablate the guard and show the disabled cases red; restore and prove the tree clean by state (git diff HEAD empty + blob hash back to HEAD's), ⛔ never by an exit code.

---

_Generated by Claude Code

---

Generated by Claude Code

[os-tesla]

os-dev-report

{
  "issue": 9107,
  "status": "done",
  "branch": "claude/issue-9107-enablement-envelope-guard",
  "pr": "https://github.com/objectstack-ai/objectui/pull/9132",
  "premise_still_valid": true,
  "summary": "The card's mechanism is CONFIRMED and fixed: SchemaRenderer's two per-value config-bag loops flattened a { dialect:'cel', source } envelope on disabled / disabledOn / enabled, so the predicate took the legacy JS path where has() is not a function. The guard now asks PREDICATE_CHAIN_KEYS, the DERIVED UNION of the file's two closed chain declarations, rather than the visibility set alone; VisibilityChainKey is not widened and evaluate() is not touched. Shape chosen and argued in the PR: two closed declarations (ENABLEMENT_NODE_GATE_KEYS for the two legs evaluateEnablementPredicate runs, now also that function's closed parameter type in place of `string`; ENABLEMENT_RENDERER_KEYS for the legacy renderer-only `enabled` alias) plus a derived union for the guard's one question - a shared parent set was rejected because the two chains share no order, declared-test or consequence copy. FALSIFIED, and it changes the acceptance criterion: the dispatch's polarity ('fail-soft means a control that should be DISABLED stays ENABLED; every assertion must be on the DISABLED case') holds for ONE of the three keys. Measured pre-fix, properties top level, holding and failing predicate: disabled -> DISABLED/DISABLED and disabledOn -> DISABLED/DISABLED (fail-CLOSED, un-negated), enabled -> enabled/enabled (fail-OPEN, because the renderers negate that leg). A disabled-only suite is therefore GREEN on two thirds of this defect; every case pins the PAIR instead, since equal verdicts are the signature of a gate never consulted. Clause-2 remains `no`: nothing declared moved - no exported symbol, registration input, authorable key or accept-set; the two new constants and one type are module-local to SchemaRenderer.tsx and the keys were already authorable and already read.",
  "tests": "All at shipped head 3cbe0e5, exit codes redirected to a file and read there, never through a pipe. GREEN: `pnpm exec vitest run packages/react/src/ packages/components/src/` exit 0 (341 files, 3328 tests passed, under /home/user/objectstack/scripts/pm/os-verify-lock.sh); `pnpm --filter '@object-ui/react^...' --filter '@object-ui/components^...' build` exit 0 (also under the lock); `pnpm --filter @object-ui/react --filter @object-ui/components type-check` exit 0 (tsc --noEmit + tsc -p tsconfig.test.json, so both new test files are type-covered) - NOTE its first run exited 2 with 26 TS2307 'cannot find module' from a stale dependency closure, which is a build prerequisite, not a finding; check-changeset-presence / -fixed / -no-major / -claims all exit 0; check-control-bytes exit 0 (7325 tracked text files); check-new-cross-file-line-citations exit 0 (0 new); check-governed-queue-guard --test on all 4 changed paths exit 0 = NOT GOVERNED; eslint on the 3 changed source files --format json exit 0, 0 errors / 16 warnings ALL pre-existing (diff hunks at lines 260,271,403,428,450,1039,1056; every warning line falls outside them; both new files 0/0). NEW PINS: packages/react/src/__tests__/SchemaRenderer.enablementEnvelopeConfigBag.test.tsx (14 cases, every mount writing the key in a BAG, never at node level except one explicitly labelled CONTROL) and packages/components/src/renderers/action/__tests__/action-enablement-cel-envelope.test.tsx (8 cases, the real action:button / action:icon through the real SchemaRenderer). ABLATION: guard lookup reverted on disk to objectui#9104's visibility-only set, proven landed before running - HEAD blob 67a602af -> mutated 21a343c7, marker `PREDICATE_CHAIN_KEYS.has(key)` 1->0 and `VISIBILITY_CHAIN_KEYS.has(key)` 0->1; ABLATED 12 failed / 20 passed (32), the 12 red being exactly the three properties pairs, the three props envelope-survival cases, both renderers x disabled/disabledOn at render level, the recourse case and the DOM-attribute case; objectui#9104's own predicateEnvelopeConfigBag pin stayed GREEN, which is the check that the mutation hit only what this card added. RESTORED BY STATE, not by an exit code: on-disk blob back to 67a602af == HEAD's blob and `git diff HEAD --quiet` clean; the script carried a trap RESTORE-FUNCTION EXIT INT TERM with an absolute REPO_ROOT path and restored with `git checkout HEAD -- ABSOLUTE-PATH`. No dist leg is involved: every root vitest alias entry redirects a package specifier to its src, so both suites exercise the mutated source. STOP CONDITION (the starred one) MEASURED, NOT ASSUMED: a faulting CEL predicate post-fix leaves disabled -> DISABLED and enabled -> not disabled, byte-for-byte the pre-fix readings, so the fault VERDICT is unchanged and only WHICH predicates fault moves. The permanent-unreachability harm already exists on main for the whole dialect (pre-fix EVERY cel-authored disabled/disabledOn gate faults, greys its control out on every row, and no authored predicate re-enables it); this PR removes it and adds authored recourse, pinned as its own case which goes red under ablation. No stop.",
  "mcp_calls": "5 - two search_issues (the dedup strike plus its lit control, which returned objectui#9107 first, so the instrument is proven live in-session), one issue_write (filing objectui#9131), one create_pull_request, one add_issue_comment for this report. Every read of the card, the dispatch brief, PR objectui#9104's body, the PR read-back and the filed issue's read-back went through zero-quota repo-scoped REST (probe: GET /repos/objectstack-ai/objectui -> 200) or through git. CHANNEL SWITCH DECLARED: REST /search/issues returns 403 from this container (the session proxy serves repo-scoped paths only), so the dedup went to MCP search_issues as the one targeted strike.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #9131: SchemaRenderer's forwarded `disabled` prop (`__disabled || undefined`, key always present) is re-declared by `{...toFormControlDomProps(rest)}` AFTER action:button / action:icon compute their own value, so their legacy `enabled` leg has never gated through SchemaRenderer for any predicate shape - proven independent of this card by a literal `enabled: false` control that is disabled on a direct mount and NOT disabled through SchemaRenderer, with no envelope, CEL or config bag anywhere in it. objectui#7238's mechanism, left behind in these two renderers when it was repaired for ui:button. It is why the enabled leg is pinned in the react package rather than at render level, and why this PR deliberately does NOT pin the current broken value.",
    "noted, not filed: the legacy `enabled` alias is the one guarded key the metadata destructure does not strip, so on a renderer that spreads what it is handed onto a DOM node the attribute changes spelling - raw CEL source text before this change, `[object Object]` after. Inert in both spellings, no React warning either way, and structurally identical to the `properties=\"[object Object]\"` attribute already emitted on every such node. Pinned in the new suite so it cannot drift silently. Carrier: objectui#9108 is queued on this same file and on this destructure region and would touch it naturally; filed alone it would be a cosmetic card with no user-visible harm behind it.",
    "noted, not filed: objectui#9108 COLLISION READING, asked for by the dispatch - this change makes it EASIER, not harder. The diff is a declaration block near line 260 plus a single token on the guard line; it touches neither the hoist nor the node gate, so the textual overlap with objectui#9108's expected hunks is nil. Semantically it is strictly helpful: once the props bag drives the node gate, a cel envelope authored in THAT bag already survives to it because the guard covers both loops - without this PR objectui#9108 would newly expose the flattened enablement predicate through a second channel and would have had to fix this first."
  ]
}

---

Generated by Claude Code