发现于 #4982 的实施(同一张 CONSOLE_VALUE_ZH 表的邻组)。不在那个 PR 内修复 —— 超出该卡范围,按 Prime Directive #10 立卡,未认领。
事实(逐条 file:line,基线 origin/main = 85fdb0612)
词表 —— packages/app-shell/src/views/metadata-admin/i18n.ts:4124:
lock: { draft: '草稿', locked: '已锁定', published: '已发布', none: '无' }
唯一调用点能送的值 —— packages/app-shell/src/views/metadata-admin/AuditPanel.tsx:191 / :193:第 191 行的三元条件是 ev.lockState && ev.lockState !== 'none',只有为真时第 193 行才调 translateConsoleValue('lock', ev.lockState, locale);为假走 —。
该字段的类型 —— packages/data-objectstack/src/metadata-client.ts:311:
lockState: 'none' | 'no-overlay' | 'no-delete' | 'full' | null;
(MetadataAuditEntry,ADR-0010 §3.6 的 4 态锁)
三者对齐后是完全错位:
draft / locked / published 三条对不上 lockState 的任何可能值 —— 那是一套草稿状态词表,不是 4 态锁的词表;- 唯一对得上的
none,被调用点第 191 行显式排除,所以这一条永远不会被命中; - 实际能到
translateConsoleValue('lock', …) 的三个值 no-overlay / no-delete / full一条都没有条目 → zh-CN 下 CONSOLE_VALUE_ZH[group]?.[value] ?? value 恒返回原值。
命中率 0/3,且表里 4 条中有 3 条是死条目、第 4 条不可达。translateConsoleValue 的签名把 value 声明为 string,所以类型检查对此毫无意见 —— 与 #4982 里 overlayScope 被声明成 string 的同一个原因。
用户可见后果
zh-CN 管理员打开元数据编辑页的「审计」面板,凡是带锁的审计行,锁状态列显示裸英文 no-overlay / no-delete / full。
与 #4982 的关系:同一失败类,但修法不同,故单独立卡
#4982(消费侧词表与生产者 enum 漂移)的词表在 @objectstack/spec 有 z.enum 可派生,已按派生方式修好并附了以 spec union 为键的 LAYER_SCOPE_ZH。这里的 4 态锁在本仓是手写 union(MetadataLayered['lock'] / MetadataAuditEntry['lockState']),spec 是否该拥有这套词表是另一个问题 —— 所以键类型该绑到哪个来源需要判断,不能照抄 #4982 的形状。不作为 #4982 的子任务,因为它的修复不落在那张卡的完成范围内。
建议(交维护者定,不预设)
未打 finding 标签:zh-CN 管理员今天打开任一带锁审计记录就看得到裸值,属具体缺陷,定级交 PM triage。
发现于 #4982 的实施(同一张
CONSOLE_VALUE_ZH表的邻组)。不在那个 PR 内修复 —— 超出该卡范围,按 Prime Directive #10 立卡,未认领。事实(逐条 file:line,基线
origin/main=85fdb0612)词表 ——
packages/app-shell/src/views/metadata-admin/i18n.ts:4124:lock: { draft: '草稿', locked: '已锁定', published: '已发布', none: '无' }唯一调用点能送的值 ——
packages/app-shell/src/views/metadata-admin/AuditPanel.tsx:191/:193:第 191 行的三元条件是ev.lockState && ev.lockState !== 'none',只有为真时第 193 行才调translateConsoleValue('lock', ev.lockState, locale);为假走—。该字段的类型 ——
packages/data-objectstack/src/metadata-client.ts:311:lockState: 'none' | 'no-overlay' | 'no-delete' | 'full' | null;(
MetadataAuditEntry,ADR-0010 §3.6 的 4 态锁)三者对齐后是完全错位:
draft/locked/published三条对不上lockState的任何可能值 —— 那是一套草稿状态词表,不是 4 态锁的词表;none,被调用点第 191 行显式排除,所以这一条永远不会被命中;translateConsoleValue('lock', …)的三个值no-overlay/no-delete/full一条都没有条目 → zh-CN 下CONSOLE_VALUE_ZH[group]?.[value] ?? value恒返回原值。命中率 0/3,且表里 4 条中有 3 条是死条目、第 4 条不可达。
translateConsoleValue的签名把value声明为string,所以类型检查对此毫无意见 —— 与 #4982 里overlayScope被声明成string的同一个原因。用户可见后果
zh-CN 管理员打开元数据编辑页的「审计」面板,凡是带锁的审计行,锁状态列显示裸英文
no-overlay/no-delete/full。与 #4982 的关系:同一失败类,但修法不同,故单独立卡
#4982(消费侧词表与生产者 enum 漂移)的词表在
@objectstack/spec有z.enum可派生,已按派生方式修好并附了以 spec union 为键的LAYER_SCOPE_ZH。这里的 4 态锁在本仓是手写 union(MetadataLayered['lock']/MetadataAuditEntry['lockState']),spec 是否该拥有这套词表是另一个问题 —— 所以键类型该绑到哪个来源需要判断,不能照抄 #4982 的形状。不作为 #4982 的子任务,因为它的修复不落在那张卡的完成范围内。建议(交维护者定,不预设)
CONSOLE_VALUE_ZH.lock补no-overlay/no-delete/full三条中文;LAYER_SCOPE_ZH,把键类型绑到MetadataAuditEntry['lockState'],使「漏一条」在type-check处变红而不是在界面上漏英文;translateConsoleValue扩到 zh 以外仍是独立决定,同样不要顺手改。未打
finding标签:zh-CN 管理员今天打开任一带锁审计记录就看得到裸值,属具体缺陷,定级交 PM triage。