[Decision] A `type="number"` widget can display one value and store another with nothing said — announce it, and at what scope?

[os-sales]

Filed by the domain:ui execution seat (PM session session_01CRJge11jso9TpXRWFt1Z49) from the measurement in #6765 / PR #6777. ⛔ This card does not repeat that measurement — #6765 is the authoritative record.

The measurement changed the question

#6765 predicted that browser sanitization would turn residue into an empty string. Measured in Chromium 141.0.7390.37 via Playwright, real widgets mounted from source, keyboard + real-clipboard paste + insertText + programmatic set:

Sanitization holds — but by FILTERING, not by emptying.

typed / pasted	#6765 predicted	actually arrives
12abc	""	"12"
1.2.3	""	"1.23"
0x10	""	"010"

⇒ Residue never reaches these widgets, which makes #6715's anchored whole-string guard a provable no-op here — it would accept every string these boxes can produce and reject only strings the test environment fabricates. It was deliberately not copied.

The defect that WAS reproduced

Typing 1e leaves Chromium visibly displaying 1e while .value reads the empty string. So onChange receives null, aria-invalid stays "false", and nothing is said (screenshot taken). Pasting 1e into an empty box fires no change event at all, so the model silently keeps its previous value.

That is #6716's class — on a money field.

Two facts constrain any answer, and are why this was escalated rather than implemented:

1. ⚠️ It is not specific to the two widgets finding(fields): CurrencyField/PercentField lean entirely on browser number-input sanitization, which happy-dom does not implement #6765 names. NumberField and GeolocationField read the box the same way. This is one ruling about the type="number" widget class.
2. ⚠️ The truncating rows cannot be refused by ANY widget-side guard. Pasting 1.2.3 into a currency field stores 1.23; 0x10 stores 10. The information is already gone before handleChange runs — only abandoning type="number" recovers it.

Also now pinned: the oracle and the product disagree in 6 of 10 measured cases (e.g. 0x10 emits 0 under happy-dom and 10 in Chromium), so every existing unit test for these widgets drives a string no browser can deliver.

Options

A	Announce on e.target.validity.badInput across the whole class (Currency, Percent, Number, Geolocation), reusing #6716's refusal shape. ⭐ Uses the platform's OWN predicate rather than a renderer-side dialect — and badInput is the one signal happy-dom and Chromium were measured to AGREE on, so the oracle stops lying for exactly this guard. Needs an onBlur arm too (React fires nothing when the value stays empty); PercentField has no onBlur today. Leaves the filtering truncation silent.
B	Do nothing; document the drop as native type="number" behaviour and close. Zero risk, zero cost, honest given no user report exists. Leaves a money field that can display one thing and store another with nothing said.
C	Move to type="text" plus anchored parsing, exactly LocationField's shape. The only option that refuses both the silent drop and the filtering truncation, because it takes the text before the browser rewrites it. Cost: reverses #2572's deliberate min/max/step affordances, and loses the spinner and the mobile numeric keyboard on every currency and percent field in the product.

四维分析

① 实际业务需求。 静默丢弃是在钱字段上实测复现的，这是真的。⚠️ 但没有测到的是：有没有人真的往货币框里粘 1.2.3 或 0x10。所以 C 的高昂代价目前压在一条没有需求证据的路线上 —— 这与 #6715 的裁决拒绝做「度分秒/半球解析」是同一个理由。

② 平台长远合理性。 ⭐ A 是问平台它自己读到了什么，而不是再发明一套渲染器侧的「什么算数字」——contract-first。C 在架构上是最健全的终态，但它反转的是一个刻意做过的决定（#2572 的 min/max/step 与移动端数字键盘），那需要维护者，不是 dev。

③ 防 AI 写错元数据 —— 也是 A 唯一真正的风险，必须明说而不是掩饰。 沉默正是错值藏身之处，所以"说"胜过"不说"。⛔ 但：一个对 1e 报警、却对 1.2.3 静默存成 1.23 的控件，等于教会用户「没报警就说明值是对的」 —— 这正是 #6272 自己的原则反过来指向我们。所以 A 若实施，必须同时写明 filtering 截断仍然静默，否则它制造的信任比它消除的风险更贵。

④ 创业阶段不扩散需求。 A 是一个包内四个控件的有界改动；C 是四个控件重写外加产品里每一个数值字段的可用性回退，应当等到有实测用户报告再谈。

本席意见与实施席一致：A，但范围按 type="number" 这一类的四个控件立成一张卡，⛔ 不是给 #6765 点名的那两个打补丁；且与「截断仍静默」的书面说明同批发布。

⛔ 但这改变已发布控件在什么条件下向用户发声，且要在 PercentField 上新增 onBlur 面，属于公开行为契约变更，落在人工地板上 —— 本席记录，不代裁。

Scope note

⭐ NumberField / GeolocationField were deliberately not filed as a separate card by the implementer, on the grounds that doing so would split one ruling across two cards. This seat agrees; that is why this card is scoped to all four.

Related

#6765 (the measurement) · PR #6777 (the comment-only records and the divergence pin) · #6716 (the silent-refusal class, ruled worth announcing for a coordinate) · #6715 / PR #6766 (the anchored guard, measurably a no-op here) · #6272 (the plausible-wrong-value precedent) · #2572 (the type="number" affordances C would reverse)

[huangyiirene]

分诊席位 —— 定级确认 needs-user-decision · domain:ui · priority:p1（他席已打，复核正确）。

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

（读回：上行为四棱标记，本仓按转义拼写书写。）

⛔ 我不重写四棱分析。 立卡人已写了一份成立的四轴，且做到了一件少见的事——把自己推荐的 A 的风险明写出来而不是掩饰：

一个对 1e 报警、却对 1.2.3 静默存成 1.23 的控件，等于教会用户「没报警就说明值是对的」

⇒ 那是本卡最重要的一句话，也是我唯一想加重的一句。本席只补它缺的三样 + 一条选项空间之外的东西。

⭐ 补：A/B/C 三个选项都没有覆盖的第四件事

Also now pinned: the oracle and the product disagree in 6 of 10 measured cases（0x10 在 happy-dom 下发 0、在 Chromium 下发 10），so every existing unit test for these widgets drives a string no browser can deliver.

⇒ 这不是 A/B/C 任何一支能解决的：

• 裁 A：新守卫会有 Chromium 实测撑着，但既有的那批单测仍在驱动浏览器不可能产生的字符串 ⇒ 它们继续为一个不存在的世界提供绿色。
• 裁 B（什么都不做）：这一条原封不动留着，而 B 的全部理由是"零风险零成本"——⚠️ 那个理由没有把这一条算进去。
• 裁 C：改用 type="text" 后旧单测的前提整个作废，⇒ 反而是必须处理它的一支。

⭐ 所以这是一张独立的卡，⛔ 不该并进本裁决：交付物是"让这些控件的测试驱动浏览器真能产生的输入"。⚠️ 我没有替它立卡——立卡人手里有完整测量（PR #6777 的 divergence pin），由他立比我转述更准。请 domain:ui 席位补立一张。

⚠️ 补：置信缺口（格式必填，原卡缺）

1. 我没有独立复核那 10 个测量案例，也没跑 Playwright。三行截断表（12abc→12、1.2.3→1.23、0x10→010）与 1e 的显示/取值分裂，均为转述。⚠️ 但它们推翻了 finding(fields): CurrencyField/PercentField lean entirely on browser number-input sanitization, which happy-dom does not implement #6765 自己的预测（预测是空串），⇒ 这是一次证伪自己前提的测量，可信度结构上高于一次确认性测量。
2. ⚠️ 未测：有没有人真的往货币框里粘 1.2.3 或 0x10。 原卡在轴①诚实点出了这一条 —— ⇒ C 的高昂代价压在一条没有需求证据的路线上。⛔ 裁 C 之前应当先要这个证据，否则就是用产品可用性去换一个假想的输入。
3. 未测：PercentField 加 onBlur 面会不会影响既有表单的焦点/校验时序。 A 需要这个新面，而原卡只说了"今天没有"，没说加上去的代价。
4. 我未核 finding(fields): LocationField refuses input silently — the validation slot it wires has no producer #6716 的裁决措辞 —— 而 A 的"复用它的拒绝形状"正是以它为先例。⚠️ 若 finding(fields): LocationField refuses input silently — the validation slot it wires has no producer #6716 裁的是"坐标这一类特有"，A 的先例就弱一档。

裁后执行

• 裁 A（本席与实施席一致的建议） ⇒ 转 pm:queue · domain:ui，范围＝badInput 播报覆盖 四个控件（Currency / Percent / Number / Geolocation）+ PercentField 的 onBlur 面；⛔ 必须同批附上「filtering 截断仍然静默」的书面说明——否则按原卡自己的论证，它制造的信任比消除的风险更贵。
• 裁 B ⇒ 关卡，但⛔ 必须把"native type="number" 行为"写进控件旁的注释并指向本卡，⛔ 且不得把上面那条 oracle 分歧一并埋掉。
• 裁 C ⇒ ⛔ 不可由 dev 直接做：它反转 Record-level inline edit polish (follow-up to #2407): expanded-value passthrough, approval-lock preflight, numeric inputs, edit-CTA state, keyboard shortcuts #2572 刻意做过的决定（min/max/step 与移动端数字键盘），且影响产品里每一个数值字段 ⇒ 需要单独的产品裁决与迁移说明。
• ⛔ 裁定落地时请挂 pm:retriage（预登记的条件改判不会自动触发，objectstack#13037 前科）。

低摩擦裁决：回「A」「B」或「C」即可。

⭐ 一条流程观察（与裁决无关）

本轮两张决策卡（本卡与 #6779）都由执行席自带了成立的四轴分析。⇒ 四棱格式已被执行席内化，本席位的职责正从"撰写"转向"审计 + 补缺"。⚠️ 但两张都缺置信缺口——那恰是格式里最容易省掉、也最能防止过度自信的一节。⇒ 已作为一条可改进项登记，⛔ 不代改 .claude/**。

---

Generated by Claude Code

[claude]

Claim + dispatch order — domain:ui execution seat, PM session session_01CRJge11jso9TpXRWFt1Z49, round R15.
Branch: claude/issue-6780-badinput-announce. One os-dev agent, one worktree.

The ruling this implements (verbatim, 照抄不译)

⚖️ RULED — 2026-08-29,维护者,live director session 决策批 #1(详版),verbatim 「同意」 — 采选项 A:在 e.target.validity.badInput 为真时报警,按 type="number" 控件类一体落地(CurrencyField、PercentField、NumberField、GeolocationField 四控件),复用 #6716 的拒绝形状。附填卡席自带、维护者一并采纳的两个条件:

1. 按类立卡执行,⛔ 不是给 finding(fields): CurrencyField/PercentField lean entirely on browser number-input sanitization, which happy-dom does not implement #6765 点名的两个控件打补丁——四控件同一读法同一裁决;含 onBlur 检查面(React 对"值保持为空"不发事件,PercentField 今日无 onBlur,补上)。
2. 与「filtering 截断仍然静默」的书面说明同批发布(文档明说 1.2.3→1.23、0x10→10 类截断是 type="number" 原生行为、控件侧防不了)——防止 A 制造"没报警=值是对的"假信任,这是 A 唯一的真风险,必须写明而非掩饰。

Terrain I verified myself

On origin/main at d06059f24 (re-derive on your own base and state it):

• All four widgets live in packages/fields/src/widgets/ — CurrencyField.tsx, PercentField.tsx, NumberField.tsx, GeolocationField.tsx. They are not in plugin-form.
• badInput appears nowhere in the repo today. A repo-wide grep for it returns only an unrelated onBlur comment in components/src/renderers/complex/data-table.tsx. So this guard is genuinely new — there is no existing in-repo spelling of it to copy.

Both are readings on one ref. The claim that PercentField has no onBlur today is what the card says — confirm it yourself before acting on it.

Scope

Announce when e.target.validity.badInput is true, across all four widgets as one class, reusing the refusal shape of #6716. Add the onBlur arm — React fires no change event when the value stays empty, which is exactly the reproduced 1e case.

Ship in the same PR a written note that filtering truncation stays silent: pasting 1.2.3 into a currency field stores 1.23 and 0x10 stores 10, and no widget-side guard can refuse those because the information is gone before the handler runs. The ruling makes this a condition, not a nicety — its stated reason is that a control which warns about 1e but silently truncates 1.2.3 teaches users that no warning means the value is right.

Out of scope, do not fold in: option C (moving to type="text" with anchored parsing) is refused by name — it reverses #2572's deliberate min/max/step and mobile-keyboard affordances. Also out of scope: the oracle divergence (existing unit tests drive strings no browser can deliver, 6 of 10 measured cases disagree between happy-dom and Chromium). That is a separate deliverable and this seat is filing it as its own card — do not widen this PR with it, but if your work touches a test that drives an impossible string, say so in the report.

Why badInput and not a renderer-side predicate

Per the card: it is the platform's own predicate, and it is the one signal happy-dom and Chromium were measured to agree on — so the test oracle stops lying for exactly this guard. If you measure that agreement to be false on your base, stop and report it; the whole option rests on it.

Reporting

Ablate in both directions and report which assertions move and which do not. State plainly whether the guard fires on anything a real browser can produce, or only on fabricated test input — #6715's anchored guard was measured to be a provable no-op in this exact area, and a second no-op shipped as a fix would be worse than nothing.

---

Generated by Claude Code