Repository navigation
record:details 分区标题存在 title/label 双拼写:三个消费方都读 title ?? label,但 spec 只声明 label #5730
Description
实施 #5611(RecordDetailsProps.sections 改对象形式)时实测到的范围外问题,只记录不修。
实测
record:details 分区的标题有两个拼写,三个消费方都做了 title ?? label 或 label ?? title 的容忍读取:
| 消费方 | 位置 | 读法 |
|---|---|---|
| objectui 渲染器 | plugin-detail/src/renderers/record-details.tsx:193 |
s.title ?? s.label |
| 仓内 i18n 抽取 | packages/cli/src/utils/i18n-extract.ts:401 |
s.label ?? s.title |
| 仓内 lint | packages/lint/src/validate-translatable-sections.ts:329 |
strName(section.label) ?? strName(section.title) |
而授权侧只有一种拼写:
- 仓内全部 5 个真实 section(3 个 showcase 页 +
sys-user.page.ts)都写label,零处写title; - objectui 的类型镜像
RecordDetailsComponentProps.sections[]只声明label; - objectui 的 Studio 区块设计器
block-config.ts:312的itemFields也只产出label。
唯一写 title 的地方是一个合成测试夹具:packages/cli/test/i18n-section-coverage.test.ts:220({ name: 'timeline', title: 'Timeline', fields: [...] })。
#5611 的 PR 据此把 sections[].label 声明为 I18nLabelSchema.optional()、不声明 title —— 按 Prime Directive #12,授权侧的事实拼写是 label,title 属于消费方容忍,不应写进契约固化成第二套正名。
为什么今天不痛、但值得记
今天没有作者写 title,所以没有用户会踩到 —— 故打 finding 不进队列。
值得记的是方向:#5611 之后 title 成为 spec 明确不认的拼写,而三个消费方仍然优先读它(objectui 甚至把 title 排在 ?? 链前面)。这正是 Prime Directive #12 说的"消费方容忍把错误约定化石化成第二套事实契约":一个照着 objectui 源码而不是照着 spec 写元数据的作者,会得到一个 spec 拒绝、渲染器却正常显示的页面。#5068 闸门落地后,这类页面会在 publish 期硬失败,而错误信息指向的是作者从渲染器里学来的拼写。
修复方向
按 #5611 已确立的方向清掉容忍侧,而不是补声明:
- 仓内两处(
i18n-extract.ts:401、validate-translatable-sections.ts:329)去掉?? title分支; packages/cli/test/i18n-section-coverage.test.ts:220的夹具改写为label(该夹具用title正是为了覆盖这条容忍分支,分支去掉后夹具应一并改拼写);- objectui 侧
record-details.tsx:193去掉s.title ??(跨仓,需单独 PR)。
注意第 2 条是 #5046 记下的"夹具三分法"里的整体替换类:那个夹具钉的正是要删的那条分支,分支删掉后它会因为"什么都没产生"而继续通过,而不是因为逻辑正确。
Activity
claude commentedon Aug 6, 2026
发现分诊轮判级(#4949 纪律):持有(
finding留)。为什么还留着:方向上没有疑问 —— 授权侧事实拼写是
label(仓内 5 个真实 section 全写label,objectui 类型镜像与 Studio 区块设计器也只产出label),唯一写title的是一个合成测试夹具;#5611 的 PR 已按 PD #12 只声明label、不把消费方容忍写进契约。剩下的是清掉三处title ?? label容忍读法,但它跨三个车道:objectui 渲染器(repo:objectui)、packages/cli的 i18n 抽取(domain:cli)、packages/lint(domain:devx)。为一个零用户影响的清理做 contract-first 拆分(父单 + 三个 sub-issue +Blocked-by:),拆分成本明显大于收益。重启条件:① 上述任一车道的 PM 下次因别的单动到这三个文件时顺带收(本评论即为那时的依据,三处位置已逐一锚定:
plugin-detail/src/renderers/record-details.tsx:193、packages/cli/src/utils/i18n-extract.ts:401、packages/lint/src/validate-translatable-sections.ts:329,外加合成夹具packages/cli/test/i18n-section-coverage.test.ts:220);或 ②title拼写首次出现在真实授权面(而非测试夹具)时立即晋级 —— 那意味着容忍读法已经开始生产第二套方言,正是 PD #12 要防的东西。本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
claude commentedon Aug 7, 2026
Findings triage — re-check of the least-recently-reviewed hold. Verdict: HOLD stands (
findingkept). Both restart cells re-verified as NOT triggered.Reading method matters here. The natural check ("has anyone touched those three files since 08-06?") was attempted with
git log --sinceand discarded: this checkout is shallow, and the log returns the same single boundary commit for every path — the false-reading shape Operational note 6 warns about. The reliable check is presence of the code itself onorigin/main, which is what is recorded below.Cell ① — "a lane collects it while passing through": not triggered. All three tolerance reads are still present verbatim at their anchored positions:
packages/cli/src/utils/i18n-extract.ts:401—addSection(index, objectName, s.name, s.label ?? s.title);packages/lint/src/validate-translatable-sections.ts:329—const heading = strName(section.label) ?? strName(section.title);packages/cli/test/i18n-section-coverage.test.ts:220— the synthetic fixture still authors{ name: 'timeline', title: 'Timeline', ... }.Cell ② — "⚠️ Note the issue body's figure of "5 real sections" is now stale — the authoring surface roughly doubled since filing and still produced no
titleappears on a real authoring surface": not triggered, and the evidence got stronger. Everyrecord:detailssections:array onorigin/mainwas re-read:examples/app-showcase/src/ui/pages/project-detail.page.ts(3),settings.page.ts(2),task-detail.page.ts(3),packages/platform-objects/src/pages/sys-user.page.ts(4). All ~12 section entries writelabel; zero writetitle.title. That cuts in favour of holding: the tolerant reads are not, in practice, breeding the second dialect PD #12 warns about — which is precisely what cell ② was written to detect.One false-positive trap for whoever checks this next: a bare
title:grep over*.page.tshits plenty of lines (page:headertitles, related-list titles,sys-user.page.ts:160/:200). Those are different properties. Cell ② is only abouttitleinside arecord:detailssections[]entry — check the enclosing array, not the keyword.Hold reason unchanged: the cleanup spans three lanes (
repo:objectuirenderer,domain:cliextractor,domain:devxlint) for zero user impact today, so a contract-first split costs more than it returns. Restart conditions carry forward verbatim.本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
os-project-manager commentedon Aug 8, 2026
Findings sweep (maintainer-authorized one-off, 2026-08-07 — registered on #6015): promoted to the queue.
title/labeldual spelling with three tolerant readers while spec declareslabelonly — the maintainer's standing family default (silently-tolerated second spelling → converge on the declared one); all real authoring already useslabel, so the fix is dropping the tolerant reads, zero migration.finding→pm:queue.Generated by Claude Code