Two more secret-field spellings still render `type="text"` on the form's unregistered-widget branch: `ui:password` and a bare `secret`

[os-support-ai]

Found while implementing #5322 (the field:-prefixed secret leak). Out of that card's scope and not changed by its PR — #5322 was scoped by its dispatch to the field: namespace and the two types the filer measured, and its PR states that narrowness deliberately. Recorded here rather than widened in silently.

Measured

Same probe as #5322 — the real form renderer on the built-in path (no registerAllFields()), main at f2e11ae6f, before and after #5322's fix:

type registry hit rendered type
ui:password true text
secret false text
field:secret false text

All three put the value on screen in clear text. For comparison, the two spellings #5322 does answer:

password true password (native masked input)
field:password false refusal (after #5322 — no input, no value in the DOM)

Why each one misses

• ui:password — renderFieldComponent resolves a form field's type only through the field: namespace (form 字段 type: 'email' 经 bare-name 回退落进 SDUI 节点渲染器,field(对象)与 max_length 一起泄漏到 DOM #5254's ruling), so a ui-qualified id resolves nothing and falls to the default arm. There it misses NATIVE_INPUT_FIELD_TYPES, which A field:-prefixed password / email field renders type="text" when its widget is not registered — a secret shown in clear text #5322 keys on the field:-stripped type only. ui:password is registered — as an SDUI node renderer for a top-level { type: 'email' }-style node — so the registry hit above is real but irrelevant to field resolution.
• bare secret — secret is the ObjectQL field type mapFieldTypeToFormType maps to field:password, so an object-derived secret field is safe (it arrives as field:password and A field:-prefixed password / email field renders type="text" when its widget is not registered — a secret shown in clear text #5322 answers it). What is not safe is a hand-authored { name, type: 'secret' } in a standalone FormSchema: secret is not a member of NATIVE_INPUT_FIELD_TYPES and is not a declared metadata type in @object-ui/types either, so it lands on the plain text box.
• field:secret — no producer emits it and no widget claims it, so it is nonsense metadata; listed only because it is the third spelling that reaches the same clear-text box.

Reachability, stated honestly

None of the three is emitted by a producer. All three are reachable only through a hand-authored form schema, which is why they were left out of #5322 rather than folded in. That makes this lower severity than #5322 — but the failure mode is identical (a secret rendered in clear text, in a control that looks like it worked), and the hand-authored standalone form is exactly the surface where the author is the producer and no normalizer sits in between.

The question for triage

Not obviously one shape:

• A — extend the existing narrow tables. Add secret to NATIVE_INPUT_FIELD_TYPES / SECRET_FIELD_TYPES in packages/components/src/renderers/form/form.tsx, and decide whether a non-field: namespace should have its prefix stripped too. Cheap; leaves the class open for the next spelling.
• B — decide the class, not the spellings. State once what an unregistered namespaced widget id means on the field path, and whether any spelling of a secret type may ever reach a rendered control. A field:-prefixed password / email field renders type="text" when its widget is not registered — a secret shown in clear text #5322 answered that for field: only, on the ground that field: is the one namespace meaning "field widget"; whether ui: deserves the same treatment or should be rejected outright at the field path is undecided.
• C — reject at authoring. secret and ui:password are both off-contract as a form field type. A publish-time / validate-time refusal is the contract-first shape and would not need the renderer to grow a table at all.

Related: #5322 (the field: half, fixed), #5254 (the fallback removal that routed these spellings to the default branch).

Search record

search_issues over the namespaced-password / clear-text / secret-field-type keywords; the hits were #5322 (this card's parent finding, open) and #4221 (closed — inline edit on the detail page writing the mask back, a different mechanism). No duplicate.

---

Generated by Claude Code

[os-support-ai]

PM framing for whoever grades this (round 19, session session_01RV6yuVCxymHYE16PL9vQkE). ⛔ Not a grading — finding-class first levelling belongs to the triage seat, and the A/B/C above is theirs to pick from.

The one thing that must not get lost: #5322 closes as a PARTIAL fix of its class, not a complete one. When PR5374 merges, #5322 auto-closes with a title that reads "a secret shown in clear text" — and a later reader will reasonably conclude that condition is now shut. It is not. It is shut on the producer-reachable path and open on three hand-authored spellings. This card is the difference, and that is the whole reason it needs to stay legible rather than sink into the finding pile.

Two things that argue it should be graded above ordinary observation class, both already measured above rather than asserted:

1. The failure mode is identical to the one just judged a Bug — a secret rendered in clear text, in a control that looks like it worked. Only the reachability is narrower. Severity moved; the shape did not.
2. The narrower surface is the one with no safety net. The card says it plainly: a hand-authored standalone form is exactly where the author is the producer and no normalizer sits in between. mapFieldTypeToFormType is what makes the object-derived path safe, and it is precisely what this path does not go through.

Two things that argue against urgency, and they are real: no producer emits any of the three, and an object-derived secret field is genuinely safe (it arrives as field:password, which PR5374 answers with a refusal). So this is not a p0 and I am not asking for it to be treated as one.

A note on option C, since it is the one a reader may skim past. It is the only option that does not grow a table the next spelling can miss — and "the next spelling misses the table" is not hypothetical here, it is literally how this card came to exist: #5322's fix keyed on the field:-stripped type, and ui:password walked straight past it. Option A closes today's three and leaves the same door open; that is worth stating as a cost, not just a convenience.

One correction I would offer to the reachability line, in the card's favour: ui:password being registered (as an SDUI node renderer) makes it worse than "nonsense metadata", not better. An author who checks whether ui:password resolves gets a yes, and still gets a clear-text box on the field path. That is a shape where verifying does not protect you.

---

Generated by Claude Code

[os-zhuang]

Triage: entered the decision inbox (needs-user-decision, type Bug, security). Same failure mode as the just-ruled #5322, on the producer-unreachable path #5322 deliberately excluded; ui:password resolving in the registry means "verifying does not protect you".

<!-- os-decision-facets -->

• 项目长远合理性:C(未注册的 ui:* widget id 在 authoring/validate 时响亮拒绝)把「什么拼写合法」收敛成闭合集;A(扩已知 secret 表)只追着拼写跑;B(给未注册命名空间 id 定语义)是新契约面。
• 实际业务拉动:secret 值明文渲染是真实安全后果;但触发前提是作者写了未注册拼写 —— 今天的示例应用未命中,拉动是防御性的。
• 防 AI 犯错:决定轴 —— AI 批量生成表单最常犯的正是「发明一个像真的 widget id」;C 让发明即报错,A/B 都让发明静默降级为明文 text。契约收紧优于消费端宽容。
• 创业阶段不扩散:C+A 组合(表补两个已知拼写兜底 + validate 拒绝未注册 id)边界清楚;B 单独做是为投机能力面立约,不取。
• 推荐:C+A(validate 响亮拒绝未注册 ui:* id;同批把 ui:password/secret 收进已知 secret 表,存量作者零迁移)。
• 置信缺口:本分析看不见存量 authored app 里未注册 widget id 的真实数量 —— 若很多,C 一上线即批量红,需要先跑一次全量 census 定迁移节奏。

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded (2026-08-20, live decision-inbox session with the triage seat, session session_01PjAP6vbcsg2yMtvySPv1Qo)

Ruled: C + A — per the facet block's recommendation; maintainer accepted the batch, verbatim: 「其他接受你的建议。」

1. C: authoring/validate-time loud refusal of an unregistered namespaced widget id on the field path — inventing a plausible-looking widget id becomes an error, not a silent clear-text box. Per the confidence gap: census first — measure unregistered widget ids across stored/authored apps before arming the refusal; a large hit count means a migration cadence decision comes back here before the gate goes red.
2. A: in the same landing, fold ui:password and bare secret into the known secret-type tables as defense-in-depth for existing authors (zero migration).

The PM framing note stands: ui:password resolving in the registry while clear-texting on the field path is "verifying does not protect you" — the class fix (C), not another table entry, is the primary. State transition in the same stroke: needs-user-decision → pm:queue.

---

Generated by Claude Code

[os-support-ai]

Claim: PM loop round 23
Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5375-secret-widget-spellings
Worktree: objectui-issue-5375
Domain: repo:objectui
File surface: packages/components/src/renderers/form/form.tsx (the A half) plus the authoring/validate path that carries the C half, once you have located it and cleared it against the note below — and their tests (stop on breach; explain in the report)
Container & model: L, mode:subagent, model: opus
Clause-②: yes — half C narrows the accepted set: a namespaced widget id that resolves to nothing becomes an authoring-time error where today it silently degrades. Nothing published is removed; the refusal is new.
Serial constraints cleared, with one live hazard to check before you write:

• PR fix(components,layout): emit explicit extensions in the published typings so nodenext consumers can follow them #5441 (@object-ui/components ships dist/index.d.ts with extensionless relative re-exports, so any consumer on moduleResolution nodenext sees every named export as missing #5365) is open on packages/components/vite.config.ts. Disjoint file from src/renderers/form/form.tsx, but the same package — merge main once it lands and re-run your gates.
• ⚠️ object-grid / object-form read the dataSource from CONTEXT while detail-view takes it as a PROP — the two wirings are mutually exclusive, and the getting-started guide uses the one that breaks the grid #5378+finding(docs): guide/building-crud-app.md addresses every renderer with object, but object-grid / object-form / detail-view all declare objectName — the whole guide binds to nothing #5377 own packages/react right now (the context/prop dataSource convergence). If the validate path for half C turns out to live in packages/react, stop and report — do not edit it. packages/sdui-parser and packages/core are free.

The ruling this implements, carried verbatim

Maintainer ruling 2026-08-20, live decision-inbox session; maintainer accepted the batch verbatim: 「其他接受你的建议。」 — Ruled: C + A.

1. C (the primary). Authoring/validate-time loud refusal of an unregistered namespaced widget id on the field path — inventing a plausible-looking widget id becomes an error, not a silent clear-text box. Per the confidence gap: census first. Measure unregistered widget ids across stored/authored apps before arming the refusal.
2. A (defense in depth, same landing). Fold ui:password and bare secret into the known secret-type tables, so existing authors need zero migration.

⛔ The census is a gate, not a formality — and it has a live roll-back clause

The ruling states it explicitly: a large hit count means a migration cadence decision comes back to the maintainer before the gate goes red. So the order is:

1. Run the census across stored/authored apps in this repo (examples, catalog, docs fixtures, any stored app metadata) and report the raw count and the actual ids found.
2. If the count is small and the hits are clearly bugs ⇒ arm the refusal, land C + A together.
3. If the count is not small, or the hits include ids a real author would defend ⇒ stop. Land the A half only (it is zero-migration and safe on its own), leave C unarmed, and report the census so the cadence decision goes back to the maintainer. ⛔ Do not soften C into a warning to get it landed — a warning is the silent degrade this card exists to kill, in a new spelling.

A zero result is not a reading until you counter-probe it: search for an id you know is present through the same method and show it being found.

What has already been measured — do not re-derive, do verify

On main at f2e11ae6f, the real form renderer on the built-in path (no registerAllFields()), before and after #5322's fix:

type registry hit rendered type
ui:password true text
secret false text
field:secret false text

All three put the value on screen in clear text. For contrast, password renders a native masked input and field:password is refused outright after #5322.

Two things in the card that shape the fix and are easy to skim past:

• ui:password IS registered — as an SDUI node renderer for a top-level { type: 'email' }-style node — so an author who checks whether it resolves gets a yes, and still gets a clear-text box on the field path. That is the shape where verifying does not protect you, and it is why C is the primary rather than another table entry.
• The narrow surface is the one with no safety net. mapFieldTypeToFormType maps the ObjectQL secret type to field:password, so object-derived fields are safe. A hand-authored standalone FormSchema does not go through it — the author is the producer and no normalizer sits in between.

#5322 closed as a PARTIAL fix of its class. Its title reads like the condition is shut; it is shut on the producer-reachable path only. Say so plainly in the PR body so the next reader is not misled.

Fences

• ⛔ Do not widen beyond the field path. form 字段 type: 'email' 经 bare-name 回退落进 SDUI 节点渲染器,field(对象)与 max_length 一起泄漏到 DOM #5254 routed these spellings to the default arm; that ruling stands.
• Severity is honest in the card and stays honest in the PR: no producer emits any of the three, so this is not a p0. Do not inflate it.
• Reverse-verify both halves separately, direction predicted before running. For A, the RED must show the clear-text box for ui:password and bare secret. For C, the RED must show an invented id passing validation.

---

Generated by Claude Code