观察单(不是缺陷单):发现于 #6038(#5164 裁 A 的 lint 段)实施过程,不在该单范围内,故另立。⛔ 未自我认领。
事实
packages/lint/src/validate-translation-references.ts 的 collectViewRecord() 对具名视图条目两种拼写都收:
for (const [subKey, sub] of Object.entries(container)) {
addView(binding, subKey);
addView(binding, strName(sub.name)); // ← 第二种拼写
}
注释给的理由是「authors write either」(来自 HotCRM 语料)。但组装器 expandViewContainerWithDiagnostics(packages/spec/src/ui/view.zod.ts)对 listViews / formViews 条目只用 map key构造运行时身份 —— v.name 被完全忽略:
for (const [k, v] of Object.entries(listViews)) {
const requested = `${object}.${k}`; // 只有 k,没有 v.name
按 #5164 的裁决(2026-08-06,canonical = 运行时身份的裸键),内层 name 与 map key 不同时,内层 name 那个键运行时解析不到,现在却被判为合法。
更尖锐的一种形状:冲突改名下两者恰好相反
组装器把冲突键改名(< object >.default 已被占用 ⇒ 后来者改名 < object >.default_2),而改名后的名字才是注册表键。实测(探针,expandViewContainer):
容器 { list: {type:'grid'}, formViews: { default: {type:'simple'} } }
=> crm_lead.default[list,default] | crm_lead.default_2[form,default]
此时本规则:
- 认
default(来自 formViews 的 map key)—— 但 default 属于那个 list,form 的译文写在这里解析不到;
- 拒
default_2(真正的注册表键)—— 作者写对了反而被报孤儿。
方向与 #6038 修掉的默认 list 那处完全同源,只是落在具名条目分支上。
为什么记为观察级、而非缺陷
目前休眠:packages/lint/src/lint-view-refs.ts 已把视图键冲突判为硬错误(ViewKeyCollision 的 doc 原话:「The build-time view-ref lint turns each collision into a hard error so the author fixes the key instead of shipping a broken reference」),所以带冲突改名的形状发不到线上;而「内层 name 与 map key 不同」的形状在本仓 12 个受棘轮覆盖的配置上零实例(#6038 实测 os lint 全量差分,added: 0 / removed: 8,无一条来自该分支)。今天没有用户会撞到。
⚠️ 但收窄它会给存量增红(HotCRM 语料的注释明说作者两种都写过),属改变已发布判定的取舍,不该由 dev 顺手做 —— 需要与 #5164 裁 A 同口径拍板:要么四面一致地只认 map key,要么明确把内层 name 记为允许的作者拼写并让组装器也认它(后者会重开 #5164 否决过的方向)。
相邻单(非重复)
发现会话:session_01BDmDsu2575gDxeMCxXhDE3(#6038 dev 座位)。严重度留分诊座位判定。
观察单(不是缺陷单):发现于 #6038(#5164 裁 A 的 lint 段)实施过程,不在该单范围内,故另立。⛔ 未自我认领。
事实
packages/lint/src/validate-translation-references.ts的collectViewRecord()对具名视图条目两种拼写都收:注释给的理由是「authors write either」(来自 HotCRM 语料)。但组装器
expandViewContainerWithDiagnostics(packages/spec/src/ui/view.zod.ts)对listViews/formViews条目只用 map key构造运行时身份 ——v.name被完全忽略:按 #5164 的裁决(2026-08-06,canonical = 运行时身份的裸键),内层
name与 map key 不同时,内层name那个键运行时解析不到,现在却被判为合法。更尖锐的一种形状:冲突改名下两者恰好相反
组装器把冲突键改名(
< object >.default已被占用 ⇒ 后来者改名< object >.default_2),而改名后的名字才是注册表键。实测(探针,expandViewContainer):此时本规则:
default(来自formViews的 map key)—— 但default属于那个 list,form 的译文写在这里解析不到;default_2(真正的注册表键)—— 作者写对了反而被报孤儿。方向与 #6038 修掉的默认
list那处完全同源,只是落在具名条目分支上。为什么记为观察级、而非缺陷
目前休眠:
packages/lint/src/lint-view-refs.ts已把视图键冲突判为硬错误(ViewKeyCollision的 doc 原话:「The build-time view-ref lint turns each collision into a hard error so the author fixes the key instead of shipping a broken reference」),所以带冲突改名的形状发不到线上;而「内层name与 map key 不同」的形状在本仓 12 个受棘轮覆盖的配置上零实例(#6038 实测os lint全量差分,added: 0 / removed: 8,无一条来自该分支)。今天没有用户会撞到。name记为允许的作者拼写并让组装器也认它(后者会重开 #5164 否决过的方向)。相邻单(非重复)
collectViewRecord收窄_views键到运行时裸键单拼写 —— #5164 裁 A 的 lint 段 #6038 —— 只动默认list的键收集,本条是具名条目分支,不同 limb;tabs[].label) have no translation key and no resolver — the list-page tab bar is untranslatable in every locale #5377 ——tabs[].label无翻译键,不同键面。发现会话:
session_01BDmDsu2575gDxeMCxXhDE3(#6038 dev 座位)。严重度留分诊座位判定。