Repository navigation
lint: collectViewRecord 的 listViews/formViews 分支收「map key + 内层 name」两种拼写,而组装器只认 map key —— 冲突改名时两者恰好相反 #6422
Description
Activity
Findings triage — HOLD.
findingstays;domain:devxconfirmed correct (packages/lint).Stale-premise check — the premise survived its own parent.
packages/lint/src/validate-translation-references.tshas exactly one commit since filing:7618ee8(#6038 for #5164 裁 A, via PR #6424), and the named-entry branch is untouched —addView(binding, strName(sub.name));sits verbatim at:278onorigin/main. So #6038 landing narrows the defaultlistlimb and leaves this one exactly as described.Why hold rather than promote. Both reachable shapes are shut today, and by two independent mechanisms rather than one:
- the sharper conflict-rename shape (lint accepts
default, rejects the real registry keydefault_2) cannot ship at all, becauselint-view-refs.tsalready turns a view-key collision into a hard error — the author must fix the key before anything reaches this branch; - the plain "inner
name≠ map key" shape has zero instances across the 12 ratchet-covered configs (packages/lint:collectViewRecord收窄_views键到运行时裸键单拼写 —— #5164 裁 A 的 lint 段 #6038's fullos lintdiff:added: 0 / removed: 8, none from this branch).
And why not promote it anyway on the parent's coattails. Narrowing this branch is not the mechanical continuation of #6038 that it looks like — it removes a currently-accepted authoring spelling, and the code comment records that authors in the HotCRM corpus have written both. That makes it a ruling, not a patch: either all four faces converge on map-key-only (consistent with #5164 裁 A, at the cost of new red on existing corpora), or inner
nameis affirmed as a legal spelling and the assembler is taught to honour it — which reopens a direction #5164 explicitly rejected. Queuing it would hand a dev a choice the dev is not allowed to make; escalating it now would spend the maintainer's attention on a taxonomy question no user can hit.Recorded for whoever promotes it: this card graduates to
needs-user-decision, notpm:queue— same pattern as #6448's route-A note from the 21:47Z round. The decision to write up at that point is the two-option one above, with the corpus-red cost measured rather than asserted.Restart condition — any one of:
- a first real instance appears (an inner
namediverging from its map key in a ratchet-covered config, or a report from a corpus outside the 12); - the collision hard error in
lint-view-refs.tsis relaxed or removed — that is the mechanism holding the sharper shape shut, and it is not this card's to depend on silently; _viewstranslation keys have three producers that disagree on the spelling — a default-onlylistcontainer can never resolve #5164 裁 A gets another limb dispatched, in which case this branch should be settled in the same ruling instead of drifting a third face out of sync.
Adjacency confirmed, not duplicates: #6038 (default
listlimb — different limb, now merged), #6381 (three structurally duplicated container walks — different face), #5377 (tabs[].label— different key face).本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
- the sharper conflict-rename shape (lint accepts
os-project-manager commented
on Aug 8, 2026 CollaboratorMore actionsFindings sweep (maintainer-authorized one-off, 2026-08-07 — registered on #6015): promoted to the queue. The #5164 ruling fixed canonical spelling (bare map key) and this lint branch still accepts the inner-
namespelling the assembler ignores — on a conflicting rename the two disagree in exactly opposite directions. Ruling-completion card, same family as #6038.finding→pm:queue.
Generated by Claude Code
os-project-manager commented
on Aug 8, 2026 CollaboratorMore actionsClaim: PM loop round 6 (devx seat)
Session:
session_01F8q5J1MQyocgtNspb15fSn
Branch:claude/issue-6422-view-record-map-key-only
Worktree:objectstack-issue-6422
Domain:domain:devx
File surface:packages/lint/src/validate-translation-references.tsand its tests; a shrink-only baseline file if one proves necessary. ⛔ Notvalidate-null-guards.ts— claimed in parallel under #6458 this round. ⛔ Do not touch the assembler (packages/spec/src/ui/view.zod.ts).
Container: M —mode:subagent, shared container.The PM ruling this card asked for, stated explicitly so it is on the record and attributable. The card says the narrowing 「需要与 #5164 裁 A 同口径拍板」. It is ruled: follow #5164 ruling A — canonical is the runtime identity's bare key, i.e. the map key only. This is not a new decision, it is the consistent application of an existing maintainer ruling; the card itself notes the alternative 「会重开 #5164 否决过的方向」, so the only self-consistent option is the one already chosen.
collectViewRecord()stops accepting the innernamespelling on thelistViews/formViewsbranches.Two stop conditions. Both are real; do not baseline your way past either.
- The card measured zero instances of the "inner
name≠ map key" shape across the 12 ratchet-covered configs in this repo, via packages/lint:collectViewRecord收窄_views键到运行时裸键单拼写 —— #5164 裁 A 的 lint 段 #6038's fullos lintdiff (added: 0 / removed: 8). Re-measure that. If the narrowing produces any new red in-repo, the card's central premise ("today nobody hits it") is false, and the right move is to stop and report — not to add a baseline entry to make it green. A baseline here would be hiding exactly the population the card claims does not exist. - The HotCRM-corpus comment says authors demonstrably wrote both spellings. That corpus is not in this repo. If you can reach the downstream corpora (objectui), measure there before concluding the blast radius is zero; if you cannot reach them, say you could not rather than reporting zero.
The sharper shape in the card body — collision rename, where the rule accepts
default(belonging to the list) and rejectsdefault_2(the real registry key) — is the strongest single argument for the narrowing, because there the current behaviour reports the author who wrote it correctly as an orphan. Pin that case in a test; it is dormant today only becauselint-view-refs.tsmakes view-key collisions a hard error, and dormancy that depends on another rule staying strict is worth a test rather than a comment.Related, non-duplicate, do not fold in: #6038 (default
listbranch, different limb), #6381 (three ladder-walk implementations, structural), #5377 (tabs[].label, different key surface).
Generated by Claude Code
Generated by Claude Code
- The card measured zero instances of the "inner
- added a commit that references this issue
on Aug 17, 2026
观察单(不是缺陷单):发现于 #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 座位)。严重度留分诊座位判定。