Skip to content

[Decision] spec(ui): the five ComponentPropsMap members #21464's last stage stopped on — object-metric drillDown.report, object-form customFields, form sections, object-timeline items, action:group / action:menu members #21704

Description

@objectstack-fleet

Ruled: 5979239990 · forks 4 and 5 letters B, A (batch #277) — all five forks ruled: 1 B, 2 B, 3 B, 4 B, 5 A · 2026-10-04T10:58Z
Ruled: 5978663135 · forks 1, 2, 3 letters B, B, B (batch #276); forks 4 and 5 pending batch #277 · 2026-10-04T09:50Z

Filing gate: ② decisions only the maintainer can make. Each fork picks the published shape of a page-component member, and no existing ruling decides it. Filed by the director seat, summon #32 (session_016tKoy8NJa35Yih1FdzrVmn), holder of #21464's S-objectui-held claim 5976829576, from that stage's dev report 5977481177 (open_questions 1–5). The at-tier contract review of record on #21699 (5977620713, PASS) judges each a genuine fork, not owed work skipped, and takes no position among the options. PR #21699 records all five in the enumeration pin's new fork stage (component-props-unknown-members.pin.test.ts), each with its shapes. The five are folded into one card under the filing quota: they belong to one card, and the ruled letters ship as one more #21464 stage. ⛔ Not a claim.

Reader who acts: the maintainer, one letter per fork (five letters). Then the director seat dispatches one #21464 stage carrying the ruled shapes. Fork 1's B waits on #21702.

维护者速读

Measured (the dev's census, read as claims; the contract review on #21699 judges them)

  • Corpora: objectstack 7d0781482d, objectui pin ab1879721595 and main 94985a92ba, hotcrm 4054ec2680, cloud b2d7a7f6f8. The instrument is a TypeScript-AST walk over code and fenced docs. It reproduces stage 5's drillDown population exactly.
  • Fork 1, drillDown.report: 3 objectui values. 1 is drawn and parses ReportSchema. 2 are it.each probes, not drawn, both refused by ReportSchema. objectstack 0, hotcrm 0, cloud 0.
  • Fork 2, customFields: 27 values, 31 entries, all objectui. Each is { name, label, type } plus a few draw keys. 0 snake_case grid keys. 2 keys outside objectui's 45 (group, defaultValue), in two tests.
  • Fork 3, sections, inline "shape 3" entry: written 7 times, all in plugin-form's README wizard and its submit-target tests. Form-view writers author none.
  • Fork 4, timeline items: 14 values, all objectui tests (8 feed entries, 5 gantt rows), 0 with content. objectstack 1 (a spec test), hotcrm 0, cloud 0.
  • Fork 5, action group/menu members: 21 static members. They use only name, label, type, locations, target, bodyExtra, bodyShape and objectName, plus one host auto-trigger test. None uses an undecided key.

Governing text


分叉 1:指标卡下钻的报表 object-metric drillDown.report

一句话问题: 指标卡点开下钻时,能挂一张报表;平台该按「报表」的正式契约来校验它,还是另写一套只给下钻用的规则?

选项 做什么 客户可感知的后果
A 直接引用现有报表契约 现在就按 ReportSchema 校验 「各分块都没绑数据集」的联合报表能通过校验,打开下钻却只列出记录,不画报表,没有任何提示(实测)
B 先修报表契约,再引用 先做 #21702:联合报表的每个分块必须绑数据集。再按 ReportSchema 校验 校验通过就一定画得出来。实测唯一的联合报表(showcase 的 TaskOverviewReport)每块都绑了数据集,不受影响
C 下钻专用形状 另写一个只看下钻抽屉两条判断的形状 下钻能用,但平台多出第二种「报表」方言,和报表元数据的校验各说各话

业务含义直译:

  • A 等于收货单上写着「每箱都要有货」,验货却只数箱子。
  • B 等于先把验货规则改成真的开箱看,然后下钻和报表共用同一个验货员。
  • C 等于给下钻单独雇一个验货员,标准和仓库的不一样。

四轴(业务立场):

  • 实际业务需求: 实测 1 个真实画出的写法,A 和 B 下都能通过。B 的收紧不拒绝任何实测写法。
  • 项目长远合理性: B 只留一份报表契约,在生产端修。A 把「收了却画不出」固化成契约。C 是第二种报表方言。
  • 防 AI 犯错: 出错时谁看到什么?A 下,AI 写出没绑数据集的联合报表能通过校验,用户打开下钻只看到记录列表。B 下,objectstack validate 当场报错。
  • 创业阶段不扩散: B 不加新 schema,只在已有 schema 上加一条校验。C 加一个 schema。

os-decision-facets

  • ① 项目长远合理性:B 一份报表契约、在生产端修;A 固化「收了画不出」,C 增一种报表方言。
  • ② 实际业务拉动:1 个实测画出的写法,B 下照样通过;第二种形状零拉动。偏 B。
  • ③ 防 AI 犯错:B 在校验时响亮拒绝;A 静默列记录。偏 B。
  • ④ 创业阶段不扩散:B 只加一条校验;C 加 schema。偏 B。

推荐:B。 两年后的样子:下钻、仪表盘、报表页都引用同一份报表契约,「能通过校验」就等于「画得出来」。参照 Salesforce:仪表盘组件引用的是同一份报表定义,不另立格式。
回退:A。 先引用现有契约,未绑数据集的漏洞留给 #21702 单独修。
自检: 只看①选 B;②③④ 是否翻转:否。
置信缺口: hotcrm 和 cloud 的联合报表还没普查,#21702 的认领会先普查。

裁后执行:


分叉 2:表单的自定义字段 object-form customFields

一句话问题: 不绑对象的表单可以直接写一组字段。平台该怎么声明「一个字段」?

选项 做什么 客户可感知的后果
A 照搬 objectui 的 FormField 45 个成员加任意键,包括 8 个蛇形命名的表格控件键 什么都能通过,写错键名也不报错;spec 里第一次出现蛇形命名的配置键
B 平台写一份封闭的字段定义 只收表单真正会画的成员,驼峰命名。表格控件的 8 个键等 objectui 改成驼峰再收 实测 27 个写法全部通过;写错或没声明的键当场报错
C 复用表单视图的 FormFieldSchema 把按对象字段覆盖的那套定义改成按 name 索引 一个词汇两用,但「覆盖已有字段」和「定义新字段」被混成一件事,objectui 的合并逻辑也得改键

业务含义直译:

  • A 等于报名表留了「其他:____」一栏,写什么都收。
  • B 等于报名表只印真正会处理的栏目,填错栏会被退回。
  • C 等于拿「修改已有档案」的表格,去登记新人。

四轴(业务立场):

  • 实际业务需求: 实测 27 个值、31 个条目,都是 { name, label, type } 加少量绘制键。零个蛇形表格键。开放字段袋和表格键都没有拉动。
  • 项目长远合理性: 封闭、驼峰、声明过的契约才能长期维护。A 把蛇形键写进 spec,还留着「任意键」这个静默丢弃的漏洞。C 混淆了两件不同的事。
  • 防 AI 犯错: B 下,AI 拼错或编造的键当场报错。A 下静默丢弃。
  • 创业阶段不扩散: B 只声明有写法的成员,表格键等 objectui 改名再进。代价是在 spec 里写一份四十多个成员的定义,一次写完。

os-decision-facets

  • ① 项目长远合理性:B 封闭、驼峰、可维护;A 引入蛇形键与任意键,C 混淆覆盖与定义。
  • ② 实际业务拉动:27 个实测写法 B 下全过;开放袋与表格键零拉动。偏 B。
  • ③ 防 AI 犯错:B 响亮拒绝拼错的键;A 静默丢弃。偏 B。
  • ④ 创业阶段不扩散:B 只声明有写法的成员;A 声明 45 个加任意键。偏 B。

推荐:B。 两年后的样子:无对象表单的字段和对象字段一样有封闭契约,Studio 能据此做字段面板。参照 Salesforce Screen Flow:屏幕组件有固定、具名的属性表。
回退:C。
自检: 只看①选 B;②③④ 是否翻转:否。
置信缺口: 私有客户可能用了表格控件的蛇形键。B 下这些写法会被拒绝,需要等 objectui 改名后再收进来。

裁后执行:

  • B: 下一段在 spec 里声明一份封闭的运行时表单字段,驼峰命名,按收紧规范发版。objectui 那边另开一张卡,把表格控件的 8 个键改成驼峰。
  • A / C: 按所选形状写进下一段。

分叉 3:表单分区 object-form / object-master-detail-form sections

一句话问题: 表单分区里除了字段名,还可以直接内嵌一个完整的字段定义(objectui#11550 保留了这种写法)。平台的分区形状要不要连「已存储的表单视图」一起放宽?

选项 做什么 客户可感知的后果
A 引用表单视图的 FormSectionSchema,并放宽其字段条目 页面块和已存储的表单视图都接受内嵌字段定义 已存储的视图元数据多出第三种字段写法,这本身是另一份契约变更
B 页面块自己的分区形状 FormSectionSchema 的键,加上表单实际读取的三种条目,只收规范写法;表单视图不动 实测 7 个内嵌写法全部通过;视图元数据不受影响;已废弃的写法会被拒绝

业务含义直译:

  • A 等于为了一个临时表单,改了公司档案柜的归档规则。
  • B 等于临时表单用自己的格式,档案柜规则不变。

四轴(业务立场):

  • 实际业务需求: 内嵌写法实测 7 次,全在 plugin-form 的 README 向导和它的测试里。表单视图的写法零次。没有放宽视图的拉动。
  • 项目长远合理性: 内嵌字段是页面块的能力。放进已存储的视图元数据,是一份单独的契约变更,分诊已说过那需要另裁。
  • 防 AI 犯错: B 把分区封闭在页面块上,不教视图第三种写法。已废弃的拼法也会当场被拒,而不是原样交给渲染器。
  • 创业阶段不扩散: B 不放宽任何其他契约。

os-decision-facets

  • ① 项目长远合理性:B 把内嵌字段留在页面块;A 顺带改了存储视图的契约。
  • ② 实际业务拉动:7 个内嵌写法都在 objectui 自己的向导与测试;视图端零拉动。偏 B。
  • ③ 防 AI 犯错:B 封闭且拒绝废弃拼法;A 让视图多一种写法。偏 B。
  • ④ 创业阶段不扩散:B 不放宽其他契约。偏 B。

推荐:B,排在分叉 2 之后。 内嵌条目引用分叉 2 选出的字段定义。两年后的样子:存储的视图只引用对象字段,临时表单的内嵌字段只在页面块上出现。
回退:A。
自检: 只看①选 B;②③④ 是否翻转:否。
置信缺口: 如果分叉 2 选 A,B 的内嵌条目也是开放的,封闭的好处就打折扣。

裁后执行:

  • B: 与分叉 2 同一段落地,内嵌条目引用分叉 2 的字段定义。
  • A: 放宽 FormSectionSchema,另开一张存储视图的契约卡,先于本段。

分叉 4:时间线条目 object-timeline items

一句话问题: 时间线有「动态流」和「甘特条」两种条目,由父组件的 variant 决定是哪种。平台要不要校验条目和 variant 对得上?动态条目里的子内容 content 怎么处理?

选项 做什么 客户可感知的后果
A 两种封闭,content 作为插槽,按 variant 配对 页面遍历器把 content 当作子组件位置去检查 子内容也会被检查;但为一个没人填的成员,改动每一次页面遍历
B 两种封闭,content 先不透明,按 variant 配对 校验条目与 variant 匹配;content 暂不深入检查 实测 14 个写法都通过;写错种类当场报错
C 两种封闭,content 不透明,不配对 条目只要符合任一种即可 动态流里混进甘特条也能通过,objectui 已裁定的配对规则被丢掉

业务含义直译:

  • A 等于为一个还没人用的抽屉,重新设计整栋楼的巡检路线。
  • B 等于先检查抽屉标签和柜子类型对得上,抽屉里面以后有人放东西再查。
  • C 等于只要是抽屉就收,不管放进了哪个柜子。

四轴(业务立场):

  • 实际业务需求: 实测 14 个值都是 objectui 的测试,零个带 content。插槽机制零拉动。
  • 项目长远合理性: 两种条目和配对规则是 objectui#6356 已裁定的契约,原样接过来。为没人填的成员新增插槽位置,会改变每一次页面遍历。
  • 防 AI 犯错: B 和 A 都在种类混用时响亮报错。C 不报错。
  • 创业阶段不扩散: B 不加插槽位置。等出现带 content 的写法,再把它升级成插槽。

os-decision-facets

  • ① 项目长远合理性:B 原样承接 objectui#6356 的裁定;A 为零写法的成员改动页面遍历,C 丢掉配对。
  • ② 实际业务拉动:14 个实测写法零个带 content;插槽零拉动。偏 B。
  • ③ 防 AI 犯错:B、A 在种类混用时响亮报错;C 静默接受。偏 B。
  • ④ 创业阶段不扩散:B 不加插槽位置。偏 B。

推荐:B。 两年后的样子:等有人真的往动态条目里放子内容,再把 content 升级成插槽。到那时有写法可测,形状是测出来的。
回退:A。
自检: 只看①选 B;②③④ 是否翻转:否。
置信缺口: 「content 暂不检查」意味着里面写错也不会报错,直到升级成插槽为止。今天这里零写法。

裁后执行:

  • B: 下一段落地两种封闭条目,加上按 variant 的配对校验。content 在台账里记为不透明成员,写明原因。
  • A / C: 按所选形状写进下一段。

分叉 5:操作组和操作菜单的成员 action:group / action:menu actions[]

一句话问题: 操作组和操作菜单里的每个成员,就是一个内联操作。平台按哪套词汇校验它?

选项 做什么 客户可感知的后果
A 沿用按钮的已测词汇 和 action:button 同一套键;未决的键(outcomeMessages、成员 className、properties.params)先拒绝,endpoint 按既有提示改写到 target 实测 21 个成员全部通过;写了未决键会被拒绝并提示
B A 加三个未决键 再声明 outcomeMessages、成员 className、properties: { params } 三个键都没有实测写法,声明后就是长期义务
C 直接引用对象元数据的 ActionSchema 按「已注册操作」的契约校验内联成员 这是另一种声明(必须有名字、按名字注册),本文件的分节说明已经排除了它

业务含义直译:

  • A 等于菜单里的每一项,和单独的按钮用同一份说明书。
  • B 等于为了还没人用的三个功能,先把它们写进说明书。
  • C 等于把临时按钮当成正式注册的流程来审批。

四轴(业务立场):

  • 实际业务需求: 21 个实测成员只用 8 个键,零个用到未决键。B 没有拉动。
  • 项目长远合理性: 内联操作只保留一套词汇,就是按钮那套实测出来的。C 混淆了两种声明。
  • 防 AI 犯错: A 封闭,并带着按钮那几行的改写提示。
  • 创业阶段不扩散: B 声明三个零写法的键。

os-decision-facets

  • ① 项目长远合理性:A 一套内联操作词汇;C 混淆已注册操作与内联操作。
  • ② 实际业务拉动:21 个实测成员零个用到未决键。偏 A。
  • ③ 防 AI 犯错:A 封闭且带改写提示。偏 A。
  • ④ 创业阶段不扩散:B 声明三个零写法的键。偏 A。

推荐:A。 outcomeMessages 是四个操作块(按钮、图标、组、菜单)共同的问题。A 下四块都暂不声明,等出现内联写法再一次性声明。两年后的样子:内联操作和按钮共用一套封闭词汇,新增键四块一起进。
回退:B。
自检: 只看①选 A;②③④ 是否翻转:否。
置信缺口: objectui#11344 已经在渲染端转发 outcomeMessages,并注明等 spec 的行声明后再公开输入。A 下这个公开会继续等。如果你希望现在就让四个操作块都接受 outcomeMessages,回 5A+,四块一起声明。

裁后执行:

  • A: 下一段落地封闭成员形状,与 action:button 同一套键和提示。
  • 5A+: 同上,另在四个操作块上一起声明 outcomeMessages,按 ActionSchema 引用。
  • B / C: 按所选形状写进下一段。

Related

#21464 · PR #21699 · #21702 · objectui#11550 · objectui#6356 · objectui#11344 · #21005 · ADR-0021 · ADR-0087.

Dedupe words: drillDown.report, customFields, FormField, sections inline field, timeline items variant, action:group members, action:menu members, outcomeMessages, UIActionSchema. Searches are listed under Governing text.


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions