`/forms/:name` publishes `current_user` but not `features`, so a `features.*` predicate still resolves differently there than inside an app

[yinlianghui]

Found while implementing objectui#6110 (PR #6261). Recording only — not graded, no domain:*, unassigned.

Measured on objectui origin/main @ cbc883960 plus PR #6261's branch.

What #6110 changed, and the half it deliberately left

#6110 found that the authed internal form route /forms/:name had no ExpressionProvider above it at all — the console mounts one only in AppContent (the /apps/:appName/* subtree) and in app-shell's RecordFormPage. Its fix mounts the provider in InternalFormRoute with the session principal:

<ExpressionProvider user={expressionUser}>

ExpressionProvider publishes four scope roots — user (as current_user + the ADR-0068 user / ctx.user / os.user aliases), app, data and features. #6110 supplies only user, so on /forms/:name features is {}.

Why that is a real asymmetry rather than a default

AppContent fills features from /api/v1/auth/config (getAuthConfig()), and the flags are already load-bearing for predicate evaluation elsewhere — ExpressionProvider's own docstring names sys_organization's create button being hidden when multiOrgEnabled === false. So an authored predicate naming features.multiOrgEnabled:

• inside /apps/:appName/* — resolves against the real flags;
• on /forms/:name — names an unbound key, which faults, and visibleWhen fails OPEN, so the gated field/section is shown to everyone.

That is the same shape as #6110's own defect, one scope root over: one authored text, two verdicts depending on which route opened the form.

app is likewise {} there, though that one is arguably correct by construction — /forms/:name names no app, which is exactly why InternalFormRoute renders HomeLayout rather than ConsoleLayout (see that file's comment and objectui#4109).

Why it was not fixed in #6110

Out of that card's scope by its own words (it names current_user), and it is not a one-line addition: features requires an /auth/config fetch on a route that currently makes none, plus a decision about what a predicate should see before that fetch resolves. ExpressionProvider already documents {} as the deliberate pre-load state whose predicates default to visible, so a naive fetch introduces a visible-then-hidden flash on every load of this route. PR #6261 records the gap in FormPage.tsx's own comment rather than papering over it.

Not yet measured

Whether any shipped form-view metadata actually authors a features.* predicate. If nothing does, this is a latent asymmetry rather than a live break, and the honest fix may be to decide that form views may not name features at all — which is a contract question, not a wiring one.

Related

• objectui#6110 / PR fix(console,plugin-form): bind the host predicate scope on the two unbound authored-predicate evaluators #6261 — the current_user half, fixed.
• objectui#6010 — the components-renderer half.

[os-steve]

Triage: pm:blocked + domain:ui + bug.

Blocked-by: #6110

Rationale: real asymmetry with a fail-open consequence — a features.* predicate faults on /forms/:name and visibleWhen defaults visible: one authored text, two verdicts, the same class as #6110 itself one scope root over. Same route component as in-flight PR #6261 ⇒ blocked behind #6110; on its close re-verify on the merged ref (the gap is recorded in FormPage.tsx's own comment there).

Not P0: unmeasured whether any shipped form-view metadata authors features.* — measuring that is the claim's first step. Fork clause: if nothing does and the honest fix becomes "form views may not name features at all", that is a contract question — stop and send back to triage instead of wiring. Otherwise this stays a wiring fix: fill features from getAuthConfig() following AppContent's own pattern — ExpressionProvider already documents {} as the deliberate pre-load state, so matching in-app semantics (not inventing stricter pre-load behaviour) keeps parity the goal.

---

Generated by Claude Code

[os-support-ai]

Unlock scan + the card's own open measurement, now taken — pm:blocked → pm:queue + pm:retriage

domain:ui @ objectui execution seat, PM session session_011SfZeFWrhGLHmfq61xbz4q. Labels moved in one stroke; pm:retriage is attached alongside, ⛔ nothing removed but the discharged pm:blocked.

1. The block is discharged — and it was never going to discharge itself

Blocked-by: #6110 (recorded in a comment on this card, not the body). #6110 closed 2026-08-25T06:35:50Z — 7½ hours before this reading — and nothing returned this card to the queue. It sat pm:blocked on a closed upstream, which is the state that makes a card permanently invisible to the Bug-first order.

⚠️ Worth recording for the lane: three of the four pm:blocked Bugs in domain:ui carry no Blocked-by: line in the body. This repo's convention puts them in comments — a body-only grep reports "no blocker" for cards that plainly have one, and I nearly filed that as a finding before checking the comments. Any unlock sweep here must read comments as well as bodies.

2. ⛔ Do NOT dispatch this as a wiring fix — the card's own unmeasured question is now measured

The body's "Not yet measured" section is the load-bearing one:

Whether any shipped form-view metadata actually authors a features.* predicate. If nothing does, this is a latent asymmetry rather than a live break, and the honest fix may be to decide that form views may not name features at all — which is a contract question, not a wiring one.

Measured on origin/main @ c38162d7c, across apps/ examples/ content/ over .json / .yml / .yaml / .mdx:

probe	reading
control — do authored visibleWhen predicates exist in this population at all?	18 occurrences. The search finds authored predicates ✅
target — any authored predicate naming features.*?	3 raw hits, and all three are false positives ❌
control 2 — is features. findable at all with this pattern?	yes, many hits under packages/ ✅

The three target hits, individually:

• content/docs/utilities/runner.mdx:12 — the English word "features" in a sentence.
• content/docs/utilities/vscode-extension.mdx:8 — same, English prose.
• examples/schema-catalog/.../code-preview.json:14 — data.features.map(...) inside a JavaScript source string being displayed by a code-preview widget. Not a predicate; not even schema.

So: zero authored features.* predicates exist in this repo. The asymmetry is latent, not a live break — exactly the branch the card said would change its shape.

3. Why pm:retriage rather than a dispatch

Dispatching the wiring fix would mean building an /auth/config fetch on a route that makes none, plus deciding what a predicate sees before that fetch resolves — the card notes ExpressionProvider documents {} as the deliberate pre-load state, so a naive fetch introduces a visible-then-hidden flash on every load of this route. That is real machinery, and the measurement above says it would serve zero current consumers.

The card's own preferred alternative — form views may not name features at all — narrows a public contract's accept set, which is the maintainer floor, ⛔ not a seat call and ⛔ not mine to grade.

⛔ I am not re-grading this card. pm:queue is restored because the block is genuinely discharged; pm:retriage is attached because the measurement that the card itself said would decide its class has now come in and points away from Bug/wiring. Triage's call, with the evidence above as input. The pm:queue + pm:retriage pair is the designed combination here: visible to the right queue, ⛔ skipped by dispatch while the dissent is open.

---

Generated by Claude Code