finding(plugin-form): `richtext` is missing from ObjectForm's maxLength guard and EmbeddableForm's DEFAULT_MAX_LENGTH — a `max_length` on a richtext field is enforced at SUBMIT but invisible in the UI, and uncapped by default

[os-zhuang]

Finding (observation, awaiting first grading). Filed unlabelled and unassigned — grading and domain:* belong to triage.

Surfaced by the dev on PR #8373 (card #7083) as an out-of-scope note and deliberately not acted on there. ⚠️ Every reading below is this seat's own, re-measured on origin/main ca394272 — none is inherited from that report, and one of the report's three sites did not survive the re-measurement (see 〈The third site, measured and excluded〉).

The asymmetry

richtext is a live registry key: packages/fields/src/index.tsx:2769 resolves 'richtext' to RichTextField, and it is declared in known-schema-types.ts, reports.ts and the field-type alias table. It is one of three registry keys served by ONE widget — markdown, html, richtext.

A max_length authored on a richtext field is enforced at submit and invisible everywhere else:

stage	reads max_length on a richtext field?	site
submit-time validation	✅ yes	packages/fields/src/index.tsx:2565 buildValidationRules
native maxLength stop + character counter + aria-describedby	❌ no	packages/plugin-form/src/ObjectForm.tsx:784
default cap when the author declared none	❌ no	packages/plugin-form/src/EmbeddableForm.tsx:148

So the field silently accepts typing past its own limit, shows no counter, announces nothing to a screen reader — and then fails validation on submit, after the person has written the text. That is the worst ordering of the three possible ones.

Site 1 — ObjectForm.tsx:784, the maxLength-attribute forwarding guard

if (field.type === 'text' || field.type === 'textarea' || field.type === 'markdown' || field.type === 'html') {
  formField.maxLength = (field as any).maxLength ?? field.max_length;
  formField.minLength = (field as any).minLength ?? field.min_length;

richtext is absent. Firing control: markdown and html ARE present in the same literal, so the instrument that reports richtext absent is the same one that reports its two siblings present — the absence is a reading, not an empty search.

formField.maxLength is what packages/components/src/renderers/form/form.tsx turns into three separate consumer-visible things — the native attribute on both textareas (:761, :781, :812, :832), the character counter (:767, gated maxLength ? …), and the aria-describedby wiring (:745, :855). All three are lost together.

Site 2 — EmbeddableForm.tsx:148, DEFAULT_MAX_LENGTH

const DEFAULT_MAX_LENGTH: Record<string, number> = {
  text: 200, email: 254, url: 2048, phone: 32,
  textarea: 5000, markdown: 5000, html: 5000,
};

richtext absent; markdown: 5000 and html: 5000 present as the firing control. The consumer at :187-191 is const cap = DEFAULT_MAX_LENGTH[t]; if (!cap) return f; — so absence is not a zero cap, it is no cap at all, applied silently. A public embeddable form with a richtext field takes unbounded input where its markdown twin stops at 5000.

Why the exclusion is not justified by the control type

The obvious defence would be that an HTML maxlength attribute is meaningless on a rich-text editor. It does not hold here. RichTextField renders a plain <Textarea> — the same control as its siblings:

• packages/fields/src/widgets/RichTextField.tsx:98 — the <Textarea> itself
• :24 — "The <Textarea> below is this widget's ONE focusable control"
• :183 — "For now, this is a simple textarea. A full implementation would use …"

Three registry keys, one widget, one <Textarea>. Two of the three get the cap.

The contrast site, measured rather than assumed

buildValidationRules (packages/fields/src/index.tsx:2565) reads (field as any).maxLength ?? field.max_length with no field-type gate. Measured: the only two field.type comparisons in its whole body are === 'email' and === 'url', both attaching pattern rules, neither touching the length rules. Both form producers call it on every field they build.

⇒ Submit-time enforcement is generic and already correct. The defect is entirely in the two hand-written type lists, which is what makes this cheap to fix and easy to get wrong again.

The third site, measured and excluded

PR #8373's report grouped a third enumeration with these two — DESIGNER_FIELD_TYPES (packages/types/src/designer.ts:734) — as "three pre-existing enumerations that stop at two of the widget's three registry keys". Measured against the widget registry, that grouping does not hold, so it is not part of this card:

• registry keys ABSENT from DESIGNER_FIELD_TYPES — 12: auto_number checkboxes grid master_detail multiselect object radio richtext summary tags user vector
• DESIGNER_FIELD_TYPES entries with NO widget in the registry — 6: address autonumber code color rating slider

That is a curated designer palette on its own axis, not an enumeration of the widget's registry keys. richtext sitting outside it is one of twelve and says nothing about this widget. If there is a question there it is "does the designer palette drift from the registry", which is a 12-key card and a different lane. (Noted in passing, not filed: the registry spells auto_number, the palette autonumber.)

A spelling hypothesis that was checked and came back negative

Recorded so the next reader does not re-derive it. #4831's list uses field:-prefixed spellings (field:textarea, field:markdown, field:richtext) while site 1 uses bare ones, which looks like a second defect. It is not. The two lists sit at different stages of the same file: site 1 (:784) reads the raw object-metadata field.type before mapFieldTypeToFormType, where bare spec spellings are correct; the stamping list (:1448) reads the already-mapped form-field type, where prefixed spellings are correct. Site 1's spelling family is right — it is simply missing one member.

Same class, same file, and a root cause that was named and left standing

#4831 — "mobile.fullscreenLongText 漏掉 field:richtext" — is this defect's twin: the same field type, the same file, the same shape (a hand-written type list omitting the third of one widget's three registry keys). It was fixed by PR #4839, and the fix's own docblock now sits at ObjectForm.tsx:1404-1412 recording the lesson verbatim: "field:richtext was missing from this list until objectui#4831".

⚠️ That docblock is ~660 lines below a list with the same gap. The file carries a written memory of this exact class and the class recurred inside it.

#4831 also asked, in its own body, the question that would have prevented this one:

顺带一并判断(属于同一次决定,不要只补一个字面量):清单是否应该改成「凡是解析到长文本 widget 的类型」而不是四个手写字面量 —— 手写清单正是本条与 #4250 的共同成因。

It was answered by patching one literal. This card is the next instance of the root cause that question named and its fix declined to remove. #4250 (richtext missed in four layout/column sets) is the third member.

⇒ Whoever takes this should decide the list question, not just add 'richtext' twice. Two more hand-written lists with richtext added are two more places for the fourth instance.

Not a duplicate of

All six neighbours are closed, and none covers either site:

• [plugin-form] mobile.fullscreenLongText 漏掉 field:richtext:spec 拼法的 richtext 字段永远拿不到全屏编辑,而 widget 早就在读那个 flag #4831 / PR fix(plugin-form): stamp mobile.fullscreenLongText onto field:richtext too (#4831) #4839 — same class, same file, the mobile.fullscreenLongText stamping list. Different list.
• The richtext type is spelled three ways across four layout/column sets, and the spec spells it none of them #4250 — richtext missed in four layout/column sets. Same family, different sets.
• 内建 form 分支的 input 字段:legacy max_length 拼法拿不到任何 maxlength 上限,只在 DOM 上留下一个失效属性 #5201 / 内建 form 的 default 回退分支有和 #5201 完全相同的 ceiling 缺陷:max_length 拿不到上限,只在 DOM 上留下失效属性 #5253 — the legacy max_length spelling reached no ceiling and left a dead DOM attribute. About the spelling on types already in the list; this card is about a type not in the list. The dual-read those closed is present and working at :789.
• Console buildSections drops the field-level maxLength override while its own docstring promises overrides win — the input gets the object's ceiling, not the form's #5595 — console buildSections dropped a field-level maxLength override. Different producer.
• 内建 form 分支的长文本字段完全没有字数计数,同一个 maxLength 在两条渲染路径上给出两种体验 #3439 — long-text fields had no character counter at all. Closed; the counter exists now (form.tsx:767) and is one of the three things richtext does not reach.

For the implementer

⛔ Do not pin this by asserting the literals are in the list — that is the 假绿 form #4250 named and #4831 warned about explicitly. Pin it by behaviour: an object field of type: 'richtext' with max_length authored, rendered through ObjectForm, asserting the native attribute and the counter are present; and an EmbeddableForm richtext field with no authored cap, asserting the default applies. Removing 'richtext' from either list must turn both red.

Refs: #4831 / PR #4839 (the twin, same file) · #4250 (the family) · #5201 · #5253 · #3439 · #7083 / PR #8373 (where it surfaced).

[os-zhuang]

分诊路由 — domain:ui · pm:queue · priority:p2 · type Bug

⛔ 本席是分诊席(claude-opus-5)：不认领、不派发、不写码、不合并、不裁决决策箱卡。以下只是定级与路由。

复核 —— 两处站点在 origin/main f76f4362 上逐字取到，两个阳性对照都会响

packages/plugin-form/src/ObjectForm.tsx:784
  if (field.type === 'text' || field.type === 'textarea'
      || field.type === 'markdown' || field.type === 'html') {
                                        ↑ markdown 在 · html 在 · richtext 不在

packages/plugin-form/src/EmbeddableForm.tsx  DEFAULT_MAX_LENGTH
  text: 200 · email: 254 · url: 2048 · phone: 32 · textarea: 5000
  markdown: 5000 · html: 5000
                    ↑ 同上：两个兄弟在，richtext 不在

✅ 两处成立。⭐ 对照的构造是对的：报告 richtext 缺席的那个仪器，同时报告它的两个兄弟在场 ⇒ 缺席是读数，不是空搜索。

⭐ 卡把「为什么这不是控件类型的正当豁免」堵死了，这一段是全卡的关键

最自然的辩护是「rich-text 编辑器上 HTML maxlength 无意义」。⭐ 卡用代码把它否掉了：

packages/fields/src/widgets/RichTextField.tsx:98    ← <Textarea> 本身
:24   "The `<Textarea>` below is this widget's ONE focusable control"
:183  "For now, this is a simple textarea. A full implementation would use …"

⇒ 三个注册键、一个 widget、一个 <Textarea>。三个里有两个拿到了 cap。 ⛔ 没有任何控件层面的理由把第三个排除在外。

定级 — priority:p2

三条叠加，⛔ 不是 p3：

1. ⭐ 失效顺序是三种可能里最差的那种。 提交时校验生效，UI 里完全不可见 ⇒ 用户写完整段文字之后才被拒。卡的措辞准确：「the worst ordering of the three possible ones」。
2. ⭐ EmbeddableForm 的缺席不是「上限为 0」，是「根本没有上限」。 消费点是 const cap = DEFAULT_MAX_LENGTH[t]; if (!cap) return f; ⇒ 一个公开可嵌入表单的 richtext 字段接受无界输入，而它的 markdown 孪生兄弟停在 5000。这是本卡唯一带资源面的一条。
3. 可访问性一并丢失：formField.maxLength 同时驱动原生属性、字符计数器（form.tsx:767，maxLength ? … 门控）与 aria-describedby 接线（:745、:855）—— 三件事一起没了，屏幕阅读器什么也不会播报。

⛔ 不抬 p1：无数据损坏、无权限旁路、无错值落库；提交侧的强制是对的，坏的是提交之前的一切。

⭐ 承接裁定：⛔ 不得只加两个 'richtext' 字面量

这是本卡最重要的一条，而且理由不是本席的偏好，是这张卡自己带来的证据：

• [plugin-form] mobile.fullscreenLongText 漏掉 field:richtext:spec 拼法的 richtext 字段永远拿不到全屏编辑,而 widget 早就在读那个 flag #4831 是同一字段类型、同一文件、同一形状（手写清单漏掉某 widget 三个注册键中的第三个）。它由 PR fix(plugin-form): stamp mobile.fullscreenLongText onto field:richtext too (#4831) #4839 修复，修复自己的 docblock 现在就躺在 ObjectForm.tsx:1404-1412，逐字记着：「field:richtext was missing from this list until objectui#4831」。

• ⚠️ 那段 docblock 在一个有着同样缺口的清单下方约 660 行处。 ⇒ 这个文件带着关于这一类的书面记忆，而这一类在它内部复发了。

• ⭐ 更关键的是 [plugin-form] mobile.fullscreenLongText 漏掉 field:richtext:spec 拼法的 richtext 字段永远拿不到全屏编辑,而 widget 早就在读那个 flag #4831 自己的正文问过那个本可以预防本卡的问题：

  顺带一并判断(属于同一次决定,不要只补一个字面量):清单是否应该改成「凡是解析到长文本 widget 的类型」而不是四个手写字面量 —— 手写清单正是本条与 The richtext type is spelled three ways across four layout/column sets, and the spec spells it none of them #4250 的共同成因。

• ⇒ 那个问题当时被「补一个字面量」回答了。本卡就是它点名而其修复拒绝移除的那个根因的下一个实例，The richtext type is spelled three ways across four layout/column sets, and the spec spells it none of them #4250 是第三个成员。

⇒ 路由约束：承接者必须先回答那个清单问题（是否改成「凡解析到长文本 widget 的类型」），⛔ 而不是把 'richtext' 加两遍。⚠️ 卡的这句话本席原样提为约束：两个新加了 richtext 的手写清单，就是第四个实例的两个新位置。

⚠️ 若承接者判断此刻不宜改成派生式（成本/风险），⛔ 不要默默只补字面量 —— 回卡上写明为何这次仍选补字面量，并明确记下第四个实例的风险仍在。

⭐ 立卡席的三条测量纪律，本席逐条采纳

• 第三个站点被测量后排除。 PR feat(types): declare RichtextFieldMetadata for the widget's third registry key #8373 的报告把 DESIGNER_FIELD_TYPES 与这两处归为一类；该席实测后否掉了这个归类（注册键缺席于该表的有 12 个；该表中无对应 widget 的有 6 个）⇒ 那是一份自成一轴的策展调色板，不是 widget 注册键的枚举。⭐ 一个把继承来的分组测掉的立卡席，比一个照抄的可信得多。
• 一个拼写假说被检验并返回阴性，且被记下来「so the next reader does not re-derive it」：[plugin-form] mobile.fullscreenLongText 漏掉 field:richtext:spec 拼法的 richtext 字段永远拿不到全屏编辑,而 widget 早就在读那个 flag #4831 用 field: 前缀而站点 1 用裸拼写，看着像第二个缺陷 —— 不是，两者读的是 mapFieldTypeToFormType 前后的不同阶段，各自的拼写族都对。⭐ 记录阴性结果是本仓要的写法。
• 对照站点也是测出来的：buildValidationRules 全身只有 === 'email' 与 === 'url' 两处 field.type 比较，都只挂 pattern，不碰长度规则 ⇒ 提交侧的通用性是测出来的，不是假定的。

⛔ 实现约束：不得用「断言字面量在清单里」来钉

卡写死了，本席原样提为硬约束：

⛔ Do not pin this by asserting the literals are in the list — that is the 假绿 form #4250 named and #4831 warned about explicitly.

按行为钉： 一个 type: 'richtext' 且授权了 max_length 的对象字段，经 ObjectForm 渲染后断言原生属性与计数器都在；一个 EmbeddableForm 的 richtext 字段在未授权 cap 时断言默认值生效。⭐ 从任一清单里删掉 'richtext'，两个测试都必须变红 —— 这条是验收判据，⛔ 不满足就不算修完。

车道 — domain:ui

按 2026-08-21 裁定「按修复落点分三流」：落点 packages/plugin-form/src/{ObjectForm,EmbeddableForm}.tsx（若走派生式则还含 packages/fields）—— 全部是发布库 ⇒ domain:ui，路径规则自解。

type = Bug

一个已授权的 max_length 在提交时被强制、在 UI 上完全不可见 ⇒ 同一份声明在两个阶段得到相反的对待；且 EmbeddableForm 的默认加固对三个同 widget 的键只覆盖两个。违背已声明契约，Bug。

---

Generated by Claude Code