# V4-2333 衍生轮 — Test Signal Parameters（LCD + Config-T 双端）设计规格
> 日期：2026-07-28 · Owner：Nancy · 状态：**设计已定案，mockup 未开建**
> 上游：`docs/specs/2026-07-09-v4-2333-transmission-test-design-record.md`（首轮传输测试设计记录）
> 本文件 = 下个 session 的续跑真源。所有决策已经 owner 拍板，**无需再问**。
> ✅ **2026-07-31 轮十：owner 的 4 条修订意见已全部落地**（Background 事实更正 / 未选 Receiver 改走 Go Live 导航引导 / Config-T 补 Receiver 显示与修改 / 补必要状态），并回填为下方 **D14 / D15 / D16**。落地明细、三项关键实测（Go Live 真实机制 / 8.3 Preset R 真源 / ①轮抓到派单遗漏的第 2 处旧措辞）见 handoff [`§1k-K`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-03 轮十一：线 C 流程线可读性重构 + Config-T 补 LCD 结果示意**，回填为 **D17**，并**推翻了 D15 中「底栏按进入场景区分两形态」那一段**（现为两态一致、每步都有 `OK` + `Test Signal`）。明细见 handoff [`§1k-L`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-03 轮十二：Config-T 组件库误用归正**（旧库 `button/no icon` 30 处 + 个人库输入框 9 处 → DS `Tab/Item` + `input box/filled`），回填为 **D18**，并重写 **§4 M0 映射表**（补「库」列 + Tx 选择器行）。明细见 handoff [`§1k-M`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-03 轮十三：Config-T 补「点 Start Test 之后」的全套反馈**（新增 `C1a · Starting` 中间态帧 + 常驻运行状态行 + DS `Message` 操作结果 toast），并按 owner 手动调整把 8 组分段统一为 `itemSpacing 16` + 未选态 `#353535`，回填为 **D19**。明细见 handoff [`§1k-N`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-03 轮十四：状态行撤除，运行/启动状态改由动作按钮承载**（`Stop Test` 变蓝并绑 DS `UX/Blue/Default`），并实测坐实 **LCD 的蓝渐变本就取自同两档 DS 蓝 token**，回填为 **D20**，同时**修订 D19 的 ② ③**。明细见 handoff [`§1k-O`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-03 轮十五（上半）：owner 就四条悬置项一次性拍板**（三条组件缺口打包提库维护者 / 分隔线只认 DS 真源库并收口 / 浮层位移检查改成一律实测比对 / 提示浮层单主题不立缺口），回填为 **D21**，落地在设计系统真源与交付文档层。
> ✅ **2026-08-03 轮十五（下半）：owner 中途三次追加派单 → Config-T 三处实体改动**（单选按钮归到 DS `radio` 20 处 / 禁用表达统一为「有变体切变体、无变体才降透明度」并撤掉 7 处双重处理 / Text Color 照 MicroApps 参考重建 5 个快捷色块并绑 DS 变量 8 处），回填为 **D22**，并**修订 §4 M0 表的 radio 行与 Text Color 行**。明细见 handoff [`§1k-P`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-03 轮十六：LCD 未选态改为「列表在、无选中项」**（撤 `---` 占位 + 隐藏列表里那个与「未选」自相矛盾的三角选中标记，LCD 交付层 6 处措辞同步）**+ Config-T 产出「Text Color 自定义色值」方案示意**（第 6 个当前色块，含未采用的替代方案与一处待拍板的边界），回填为 **D23**，并**修订 D15 与 §3.1 的 `---` 表述**。明细见 handoff [`§1k-Q`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-03 轮十七：Text Color 自定义色方案重新设计并经 owner 选型**（预设行退回纯快捷入口，当前色改由 hex 输入框内嵌色点承载），回填为 **D24**，并**替代被否的 D23 ③**。明细见 handoff [`§1k-R`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-03 轮十八：默认制式改为 `1080i5994`**（两端产品帧 + PRD + UX 卡 + annot 全量同步），并按 owner 要求附上「制式参数以开发提供的列表为准、图上为示例」的说明，回填为 **D25**，同时**修订 D6 与 D10**。
> ✅ **2026-08-04 轮十九：LCD 选项列表选中行文字色统一为绿 `#7ed321`**（C2 Receiver 列表，owner 同意推荐），回填为 **D26**；同轮实测发现 **C1 帧被外部改动**（待 owner 澄清）与 **Section 两两重叠属机检既有缺口**。明细见 handoff [`§1k-T`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-04 轮二十：真实视频信号接管测试信号**（2b/2c 就地改造为 Live 接管 + Config-T 新增 C4 + 两端动作按钮统一为红 `Stop`），回填为 **D27**，并**作废了「测试中接入视频源不自动切换」这条已交付的反向决策**。明细见 handoff [`§1k-U`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-04 轮二十一：线 C 拆为四步、未选态获得独立载体 `C0`**（C1 按 owner 拍板转为已选态；补 `C0` 未选态帧；线 C 重排 `C0 → C1 → C2 → C3`），回填为 **D28**，并**修订 D15 / D16 / D23 ①**（未选态描述的载体从 C1 迁到 C0）。明细见 handoff [`§1k-V`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> 🔍 **2026-08-05 轮二十二（核验轮，零 Figma 写入 · 无新决策）**：核 owner 本地两处 Verdana 改名 → **均未做**，D28 ⑦ 与 D23 ② 继续挂账；同轮实测把 **D23 ② 的改法落点收窄为「C2 被标记那一行 `PM_X7M → PM_X7L`」**（依据：线 A 四帧 + C3 的 Receiver 回显实测全为 `PM_X7L`），并发现 **机器总闸其实可跑**（`.env` 有 `FIGMA_TOKEN`、脚本读 `FIGMA_PERSONAL_ACCESS_TOKEN`，仅变量名不同 —— 更正 §1k-P 起多轮「缺 token」记录）+ **真源 `probeI2()` 双重收集 bug**（顶层 Section 与自己配对，致 I2 恒 FAIL）。明细见 handoff [`§1k-W`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> 🔍 **2026-08-05 轮二十三（核验轮，零 Figma 写入 · 零 DS repo 写入 · 无新决策）**：owner 本地两处 Verdana 改名**连续第 2 轮核为未做**（`9742:341` 仍 `XMM_X2L`、`9742:392` 仍 `PM_X7M`，机读 + 渲染图双证据）⇒ D28 ⑦ / D23 ② 继续挂账；同轮两条新发现 —— **① D26 ③ 里「因 C1 状态待澄清而暂缓」那处已自然闭合**（C1 被标记行 `9742:343` 实测 `#7ed321`，随 owner 本地改动一并带绿；双向探针确认非选中行仍白）⇒ **D26 对象全集 5 处全合规**；**② 两处改名从「字符不一致」升级为「已交付验收条目当前判 fail」**（UX 卡 Acceptance 已写「the matching row / 对应的那一行」，而 C1/C2 字段行值与标记行都不 match）⇒ 定稿发 Jira 前必须闭合。机检与轮二十二基线逐项复现（I3/I4 pass · I2 4 处仍为 `probeI2()` 自配对假阳性 · overlap 9 处全连线贴边 · 线 C 四帧 drift 0）。明细见 handoff [`§1k-X`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-05 轮二十四（落地轮，owner 四条新派单）**：**① 绿字唯一化已落地**（owner 判据「绿 = 当前保存的值，只可能有一个」；C0/C1/C2 三帧字段行值不再单独占格、候选列表整体上移一行占掉那一格、连体绿框各缩一行 ⇒ C0 零绿 / C1·C2 各唯一一处绿）→ 回填 **D29**，并使 **D28 ⑧⑨ 的旧判定作废**、**D28 ⑦ (a) 的改名需求消失**（只剩 C2 一处）；**② 测试中顶栏去掉 ` / 1kHz` 已落地**（音频按实际设置传输、不在顶栏呈现，与 Live 态一致；产品帧 3 处 + 交付层 5 处共 10 句）→ 回填 **D30**；**③ 制式清单重定 + Config-T 三项合一**（owner 与开发商定：10 项新清单、默认 `1080i59.94`、Config-T 用一个设置项）→ 登记 **D31，本轮未落地、派轮二十五**；**④ 「视频源丢失 → 自动回落测试信号」要补进流程图**（文字层早已全覆盖、缺主线时序线上那一格）→ 登记 **D32，本轮未落地、派轮二十五**。明细见 handoff [`§1k-Y`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-05 轮二十五（落地轮，两块结构改造 + DS repo 两条改动）**：**① D32 已落地** —— 补「视频源丢失 → 自动回落测试信号」帧 `AFTER 2d 9901:580`（线 A 列 (1120,2560)，clone `9359:678` 起步、源帧未动）+ 连线 `s4 9901:795`（x1352 y2427，锚定 dot −3 / tip 0）+ annot `9902:379`（(1620,2560)，仿 `9495:5` 三档样式）；**owner 选型 = 给 toast**（与 2b `Video input detected` 对称、合 M12），文案 `Video input lost — test signal resumed.`，从 2b 的 DS `Message`（`status=info`）clone 而来、textStyleId 保住。**② D31 已落地（两端）** —— LCD `L3` 浮层 `9593:942` **7 → 10 项**、选中行绿 + ▶ = `1080i59.94`（**排第 5 位 ⇒ 首屏 6 行内可见**，面板与连体绿框 **delta 0、无需扩容**，见 D33 ①）· LCD 产品帧 4 处制式回显改 `1080i59.94`（L1.5 摘要 / L2 / L3 字段行 / L4）· Config-T 五帧 `Resolution + Scan Type + Frame Rate` **三行合一为一个 `Format` 行**（h `1133 → 1077`、五帧仍等高）· `CT3` 展开态由 Resolution dropdown 改 **Format dropdown（10 radio 选项）**。**③ 帧编号消歧已落地** —— Config-T 一端加前缀 `CT1 / CT1a / CT2 / CT3 / CT4`（owner 选型），LCD `C0–C3` 不动 → 回填 **D33**。**④ DS repo 两条改动已落地并推送** —— `probeI2()` 双重收集 bug 修复 + 双向回归测试；硬约束 5 补第 ⑤ 条 + 更正 `:1090` 那句「不是真源脚本有 bug」→ 回填 **D34**。**⑤ owner 本地改名连续第 3 轮未做**（C2 `9742:392` 仍 `PM_X7M`）⇒ D23 ② / D28 ⑦ 继续挂账。明细见 handoff [`§1k-Z`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-05 轮二十五收尾（owner 三条决策一次给全，已全部落地）**：**① C2 改名已由 owner 完成** —— `9742:392` 实测 `PM_X7L`（Verdana 保住、零字体债），五重证据复核（机读 + 渲染图 + 三帧绿字全集 + 反向探针 + 取值链）⇒ **D23 ② / D28 ⑦ 正式闭合**；顺带清掉两处过期图层名（`9742:392` 名仍叫 `PM_X7M`、`9742:341` 名仍挂已失效的 `OWNER TODO`）。**② 两条候选规则 owner 拍板「如有需求则修改」⇒ 判为有需求、已回流 DS，且都并入既有条文未续新编号**：`clone()` 的 parent 不可假设 → `figma-technical-reference.md` **Q15 形态 C**；§I7 复位的执行强度 → **§I7 Acceptance 新增一条**。**③ DS `STATUS.md` owner 拍板「现在改，并行 Session 先暂停了」⇒ 已更新** —— 长叙述进 `STATUS-CHANGELOG.md` 新建 **session AA** 段，STATUS 顶部只留摘要 + 指针（`audit:doc-shape` S1 1782→2533 B / 上限 3000，四条文档闸全 PASS）。明细见 handoff [`§1k-Z ⑥ / ⑧ / ⑩`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-05 轮二十六（落地轮，交付层可读性重构 —— owner 走查两块结构改造后转向文案）**：owner 走查结论 = 两块结构改造 **OK**，但提出**新派单**：「PRD 的需求里面是否太过详尽了？包括 UX 交付等说明，现在的文案看起来像是 AI 读的，开发和测试来读的话显得内容太多了」⇒ 登记 **D35**，本轮全部落地。owner 三项选型：**精简力度 = B 中度重构** · **双语 = 保持全量双语**（体量靠结构精简降，不砍语言）· **范围 = 先 LCD 定形态、确认后套 Config-T**；追加拍板 **PRD §5 与 UX 卡 Acceptance 去重（方案 a）+ 规则回流 DS，后续需求都按此规则**。两端 20 + 16 个文本节点全部重写，**59,460 → 48,332 字符（−18.7%）**；同轮扫出并修掉一个**潜伏多轮的既有缺陷：56 处 `→ ▼ ①–⑤` 在 Roboto 段渲染为空白**（机读永远"在"、只有渲染图能发现）。规则已回流 DS（§M23.11 (B) 终态优先 · §M23.0 判据单一归属 · §M-TXT-ICON-AUDIT 注释层 glyph 例外，三条均并入既有条文、未续新编号）。明细见 handoff [`§1k-AA`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-05 轮二十七（落地轮，owner 四条派单：验收去重收口 + 新 Jira 单 + 控件统一 + 真源划分纠错）**：**① D36 交付层判据收口** —— owner 指出「不是说了 Acceptance 从 PRD 里面移除、只保留 UX 说明里面的吗？我看了下目前还是有重复的，UX 交付说明也很多」⇒ 轮二十六落地的是「分工去重」（PRD 留功能级 / UX 卡留界面级），**owner 要的是整段移除**。本轮：两端 PRD §5 → 一行指针（LCD 2147→**79** · Config-T 2025→**80**），验收**唯一归属 UX 卡**并吸收 PRD 的功能级判据（LCD 2425→3120 · Config-T 1827→2767）⇒ **验收总量 8424→6046（−28%）**；同轮按 owner 选定的**全面去重**档做横向唯一归属（Format 十档全串曾出现 6 次、Live 接管 12 次、锁定 9 次…），两端 48332→**41888（−13.3%）**，累计相对最初 59460 = **−29.5%**。**② D37 Config-T 端新 Jira 单 V4-2376** —— owner 新建（clone V4-2333、assignee Bonnie、priority High、parent V4-1676），两端 PRD §1 加真超链接 + Config-T 的 Jira 组件 instance 换挂 + 6 处单号同步。**③ D38 控件几何统一** —— owner 指出宽度/对齐/间距与其他页面不统一并给参考页，五帧 select/Overlay input 240·300→**480** · hex 120/148→**148** · CT3 展开面板→480 · 动作按钮包进按钮组容器（间距 20 · 右缘对齐**控件右缘 898**）。**④ 真源划分纠错 + 流程根因** —— owner 两次指出 AI 把项目资料写进了 DS，且追问「为什么规则没拦住、有设计走查吗、能不能规避」⇒ 查证后回流 DS 三条（**新立 §M-DISCIPLINE.SOURCE 回流三档判据** · §M17 泛化跨 surface · §M-DISCIPLINE.SCOPE 硬约束 6），DS commit `3fc468ad`。明细见 handoff [`§1k-AB`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-06 轮二十八（DS 侧落地轮 + 一处 page 改名，零 mockup 内容改动 · 零 Jira 发送）**：owner 四项拍板 —— **① `domain-tvu.md` §M17.1 的 LCD 规格表判为项目资料**（取值搬走 / DS 只留做法，与轮二十七对 Config-T 同口径）· **② 还没走查 ⇒ 本轮只做 DS 侧、Jira 一个都不发** · **③ Config-T page 名同步改 V4-2376**（已落地，**D37 ⑤ 挂账闭合**）· **④ DS 侧四项全做**。落地：**`CANONICAL-F101` 几何一致性闸**（`pnpm audit:mockup-geometry-consistency`，G1/G2/G3 三判据 + 18 单测；本 feature 实测 **G1=1 · G2=0 · G3=0**，G2/G3 归零**独立复现了 D38 终态**，唯一 G1 是 D38 ④ 的设计意图 ⇒ 走具名 allow 不抬 baseline）· **`CANONICAL-F102`** 两个 skill 回流表述改三分（含 frontmatter description）· **`CANONICAL-F103`** 全量判定表（A 表 10 条待搬 / B 表 9 类判留，**本轮不搬**）· 新立 **`CANONICAL-F104`**（LCD 手搓行栅格 —— F101 v1 对 LCD **0 control instances**，那边的「0 findings」是没有对象、不是通过）· DS STATUS 摘要 + session AF 归档（S1 2582→2118 B，未加豁免）。回填 **D39**。明细见 handoff [`§1k-AC`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-06 轮二十九（落地轮，owner 四条拍板 + 两条中途追加）—— 提交范式重做**：owner 走查效果图后判定「**Update 按钮完全没用**」，要求改为 `Apply` + 任何状态可编辑 + dirty 驱动 + Discard 弹窗兜底，**双端同步**。回填 **D40**，并**整体推翻 D1 的 2026-07-29 修订与 2026-07-30 轮七补记**（D1 正文已加 ⛔ 标注，保留仅作沿革）。中途追加两条：**① `Apply` 措辞属项目级约定须记进项目文档**；**② Discard 弹窗 owner 手动换成 `form=dialog, type=default` 并定稿文案，后续同类需求一律沿用（宽度可调）**。落地明细见 handoff [`§1k-AD`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。**一处未收口**：LCD 底栏 `OK` → `Apply` 因 Verdana 在本环境不可写、且文案硬编在 `LCD Button` 的 Type 变体里，**须 owner 手动改**（清单见 §1k-AD）。
> ✅ **2026-08-06 轮三十（落地轮，owner 三条拍板）—— 提交措辞改为「按端统一」 + LCD 撑 discard + 两端补提交结果双态**：owner 先手动把 LCD 5 处底栏改成 `Apply`（已核实），随后又改回 `OK` 并重申以设备实机为准 ⇒ **回填 D41**，并整体推翻 **D40 (d)**（LCD 底栏 `OK`→`Apply`）与 **D40 ⑤ 的 LCD 半边**（LCD 做 discard 确认面板）。三条拍板：**① 措辞按端** Config-T=`Apply` / LCD=`OK`（已呈报反证：6 个 LCD 页实测 `OK` 仅 2 处且非提交底栏，而同类表单页 `V4-1542` 有 `Apply` ×7；owner 重申后按 `OK` 执行并登记为已知偏差）· **② LCD 不做 discard 弹窗**（Config-T 保留）· **③ 两端补 Apply 结果提醒**（成功 + 失败）。新增四帧：LCD **L6**（成功）/ **L7**（失败）· Config-T **CT7**（成功）/ **CT8**（失败）。顺带坐实两处上一轮记录与实态不符（`Type=Primary` 默认文案是 `Start` 非 `OK`；LCD discard 面板 `9965:653` **从未存在**），及两处上一轮扫查真漏（LCD Journey `blocked while running`；Config-T Changes 卡残留 `form=pop confirm, type=danger`）。落地明细见 handoff [`§1k-AE`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-06 轮三十一（落地轮，owner 三条走查意见）—— 交付层双语样式合规 + 文案精简（中等档）+ 页脚版权年**：owner 指出「PRD、UX 状态和 UX 交付说明的**双语样式没有完全使用设计系统里面的**来，**中文应该有个透明度**」「说明文字**太复杂、不精简、人工可读性不强，看起来是给 AI 用的**」「底部 `© 2024` 改成 2026」⇒ 回填 **D42**。按 M23.14 (B) 立**canonical 角色样式表**并两端全域落地（Config-T 21 拆段 + 48 降透明度 · LCD 34 拆段 + 4 降透明度 + 119 处行距统一 · 两端 ZH 残留 0）；文案按 owner 选定的**中等档**精简（11 个节点 32 184 → 28 745 字符，**-10.7%**；⛔ 我原先给的 -40~50% 预算被实测推翻，见 handoff ④）；顺带抓出 **4 处非文案真缺陷**（**PRD req 9 与 D40/D41 正面互斥「运行中不可改接收机」** · LCD PRD 重号 13 · 两处 EN/ZH 不对齐 · Config-T `Changes` 归类错 + 孤立空行）与 **2 处机检可信度问题**（conformance `--report` 只落 exit code 无 node id ⇒ 上一轮的「按节点归属核验」是空洞的 · `bilingual-spacing` 对含 `🟡` 的节点因 UTF-16 下标错位出假阳性）。落地明细见 handoff [`§1k-AF`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-06 轮三十二（落地轮，owner 两条拍板 + 一条新事实）—— 激进档精简 + LCD 改名 Test Signal 落到交付层 + 六条机检盲区回流 DS**：owner 判定中等档不够（实测仅 -10.7%）⇒ **切激进档**，两端 Acceptance 合并至各 **14 条**（LCD 25→14、卡高 1204→**960**；Config-T 23→14、卡高 914→**714**）；同时拍板 §1k-AF ⑧ 的 **5 条 DS 回流全部执行**。中途 owner 追加新事实「**LCD 设置测试信号的页面名称和选项我改成了 Test Signal，不是 Start Test**」⇒ 交付层按**语义二分**同步（指页面/选项/参数集/信号本身 → `Test Signal` **23 处**；指按钮动作 → 保留 `Start Test` **10 处**），跨 surface 对照证实 Config-T 端**早已是该范式且零处需改**。DS 侧实际修了 **6 条**（新抓出一条更严重的：`ANNOTATION_RE` 匹配不到 `annot ·` ⇒ 整个 state-label 小卡族长期在机检 scope 外，此前「annot 零命中」全是假阴性），commit `1ae713f9`。回填 **D43**。落地明细见 handoff [`§1k-AG`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-07 轮三十三（定稿轮，owner 三条拍板）—— Verdana 墙边界被推翻 + 首次完整 F1 双端走查 + report 体积策略**：owner ① 两张 Acceptance 卡**定稿** ② conformance report **只入库 findingNodeIds** ③ 质疑「那两处你不可以帮我改吗？加也是你加的啊」。第 ③ 条**推翻 §1k-AG ⑦.3 的登记** —— 实测点名的 5 处全是 **Roboto**（DS `Message` instance + `LCD Button` 的文本 override），AI 一直就能改；Verdana 墙只挡「文本仍是组件默认 Verdana」的节点，按对象全集重推为 **491 Verdana（不可写、且本来就对）/ 152 Roboto（= 真字体债，旧记录 88 是轮五数）/ 9 段 PingFang SC**。随后跑完首次完整 F1：抓出 **F33-1**（两端参数对照表残留 `Update 提交`，与 D40②/D41① 冲突）与 **F33-8**（LCD UX 卡 `Changes` 缺「提交与结果反馈」段，Config-T 有 ⇒ 跨 surface 不对等），并按 owner 拍板补 **发起失败帧 A5** + Acceptance **拆条 14→15**；**撤回我自己给出的 F33-3**（overlap 闸 10 条经叶子级核验 = 6 条设计正确的连线锚点 + 4 条纯 bbox 假阳性 ⇒ 0 真缺陷，真问题在闸本身）。回填 **D44**。落地明细见 handoff [`§1k-AH`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> ✅ **2026-08-18 轮三十四（发单轮，owner 两条补充）—— Config-T 新增 CT1b「已接入视频源 ⇒ 不可开测」态，Start Test 与 Receiver 双锁**：owner 自建效果图 `8567:3436` 并补两条 —— ①「当前已有视频信号源时，Start Test 不可点击」②「不可测试状态下，Receiver 也不可更改，以免影响 Live 的 Receiver」。逐控件对照 CT1b vs CT1 实测差异**恰好两处**（Receiver `enable=off` · Start Test `clickable=no`，其余 12 个控件全可编辑）⇒ 与 owner 两条补充完全一致、控件层无需再动；AI 侧只做**帧名/层名归正 + 交付层六处同步**。过程中机检抓出一条**我引入的真重叠**（UX 卡增补后撞进 Journey Map 1000×127），已修。回填 **D45**。落地明细见 handoff [`§1k-AI`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
> 决策全集 = **D1–D45**，**全部已落地**（轮二九那项「LCD 底栏文案」已由 owner 手改收口，D41 ① 又把它改定为 `OK`）。**阻塞项已解除** —— owner 轮三十三定稿，轮三十四补 CT1b 后**进入发 Jira 阶段**。**Config-T 端主单 = V4-2376**，LCD 端仍 V4-2333。**⛔ 「2 类只能 owner 手改」的登记已被 D44 ① 推翻**（那 5 处实测全是 Roboto、AI 可改）；真正不可写的是 **491 个仍为组件默认 Verdana 的节点**，而 **152 个 Roboto 节点 = 待 owner 在本地 Figma 换回 Verdana 的字体债**。
---
## 1. 需求来源
Trevor（PM）在 V4-2333 追问「测试视频（循环图卡）的分辨率/帧率是什么，不同客户格式要求不同」→ 派生出「是否给用户开放测试信号参数设置、放哪个产品线」的范围问题。
Owner 2026-07-28 拍板：**两端都做** —— LCD 给精简流程，Config-T 新增一个 Tab 承载全量参数。
参考设计（参数项与默认值的取值来源）：
MicroApps「Parameters」面板 —
`https://www.figma.com/design/DtZcMkhNy6qh6jbQQnhreQ/Micro-Apps-20250923?node-id=83-9846`
参考面板完整项：
| 组 | 项 | 控件 |
|---|---|---|
| 信号 | Select Pattern | 下拉（Color Bars）|
| | Resolution | 下拉（1920 x 1080）|
| | Scan Type + Frame Rate | 双下拉同行（Progressive (p) · 30）|
| | Tone Mode | 单选（Beep every 1 sec / Beep every 2 sec / Continuous）|
| Timecode | Timecode 开关 + Local Time / Running Time + Text Color | switch + radio + 色块行/hex |
| Overlay | Overlay Text / Position（Bottom Left·Top Right·Top Left）/ Text Size（Small·Medium·Large）/ Text Color | 输入 + 分段 + 分段 + 色块行/hex |
| 底部 | Update（disabled 态）· Start Stream | 按钮 |
---
## 2. 已拍板的设计决策（全部 owner 确认，勿再动摇）
| # | 决策 | 内容 |
|---|---|---|
| D1 | **参数是「设置」不是「每次运行的选项」** | 一份参数两端共用；按 Transmitter 保存 + 重启不丢失。用户永不被强制在开测前做选择。
**2026-07-29 修订（owner 走查拍板）**：提交方式两端各自沿用其平台范式 —— LCD 由底栏 `OK` 提交，Config-T 由 `Update` 提交；不再表述为「改完即时生效、无保存步骤」。
**2026-07-30 轮七补记 —— 本修订的落地面 = 两个 surface 的全部交付层，不止 LCD**：轮六收尾只核了 D10 在 Config-T 的落地，本修订漏核 → Config-T 侧 PRD / UX 卡 / Journey 卡共 **17 处**残留「即时生效 / 无保存动作」，且与同卡内 `Update` 提交描述**正面互斥**（PRD `req 3` 同句自相矛盾；Journey `stage 3` 把「多一步保存」列为痛点，与交付形态相反）。轮七已全部改为：**编辑为待提交态 → 按 `Update` 提交才生效并自动保存 → 重启不丢；无独立 Save / Cancel 按钮对；LCD 由底栏 `OK` 提交同一份记录**。LCD 侧机检 0 处残留（轮六已落地）。详见 handoff §1k-G ②。
**2026-07-30 轮八回流（双向引用）**：本次漏核已作为 DS 通则 **§M-DISCIPLINE.SCOPE 实证表第 5 行**沉淀（「scope 的决策集维度缺席」）。核**任何带「修订」字样的决策**的落地面时，对象全集 = 全部带修订的决策 × 全部 surface × 全部交付层 —— 不是 owner 点名的那一条。
**⛔ 2026-08-06 轮二十九：本条 2026-07-29 修订与轮七补记的「提交才生效 / 运行中锁定」已被 D40 整体推翻。** 现行口径见 D40 —— 两端提交按钮统一 `Apply`、参数在任何状态都可编辑、`Apply` 仅在有未应用改动时可用、离开前用 Discard 确认兜底。本条正文保留仅作沿革，**不得再据此实现**。 |
| D2 | **LCD 暴露范围 = 精简三项** | `Pattern` / `Format`（Resolution+Scan Type+Frame Rate 合并成一个预设列表）/ `Tone Mode`。Timecode 组与 Overlay 组 **LCD 不可改**。 |
| D3 | **LCD 流程 = 默认直开 + 可选设置入口** | 保留 FB-9937 单入口：点 `Test Signal` 用当前生效值立即开测。
**2026-07-29 修订（owner 走查拍板，方案 A）**：**撤销「home 屏 Test Signal 按钮旁新增齿轮」**。设置入口改为复用**底栏既有设置齿轮 → `Settings` 二级列表新增 `Test Signal` 行 → 参数页**；home 屏零改动（右栏几何恢复已交付帧原值）。撤销理由见 D9。 |
| D4 | **Config-T 范围 = 全量照参考面板**（**制式项已于 2026-08-05 轮二十五按 D31 例外**）| 新 Tab `Test Signal`，插在 **IP Source 之后**（即此前作废的 NDI Source tab 所在槽位）。
**⚠️ 2026-08-05 D31 修订**：「全量照参考面板」**不再包括制式的控件拆分方式** —— 参考面板把制式拆成 `Resolution` + `Scan Type` + `Frame Rate` **三个下拉**，Config-T 现改为**一个 `Format` 下拉**（与 LCD 同一份 10 档清单），三行合一。**其余参数组仍全量照参考面板**（Pattern / Tone Mode / Timecode 组 / Overlay 组），故本条主体成立、只在制式这一项上有明确例外。**连带作废**：D10 轮七补记里那句「Config-T 暴露的是 Resolution / Scan Type / Frame Rate 三个独立下拉」及由它推出的「只允许提供彼此的合法组合」在 Config-T 侧已不再适用（合并成一个枚举后，非法组合结构上不可能出现）；两端交付层的对应措辞已同轮改写，全 page 残留探针 = 0。 |
| D5 | **运行中不可改参数** | 测试进行中，**两端参数全部置灰**，配 hint「Stop the test to change parameters」。不做「改参数自动重启流」。 |
| D6 | **默认值沿用 MicroApps 参考面板，但制式项已按 owner 拍板改为 `1080i59.94`**（2026-08-03 轮十八修订 · **2026-08-05 轮二十五按 D31 再修订写法与形态**）| **⚠️ 现行取值 = `1080i59.94`（写法带小数点），两端均为一个 `Format` 设置项**。~~Color Bars / 1920×1080 / Progressive (p) / 30~~ ~~→ `Interlaced (i)` / `59.94`（LCD 合并格式项即 `1080i5994`）~~ —— 轮十八那版写法 `1080i5994` 与「Config-T 拆三个下拉」的形态**已同时作废**：D31 规范化写法为 `1080i59.94`，且 Config-T 侧不再有 `1920×1080` / `Interlaced (i)` / `59.94` 三个独立默认值，只有 `Format = 1080i59.94` 一个。**其余默认值不变** · Tone = Beep every 1 sec · Timecode = ON · Local Time · 文字色 `#F8F8F8` · Overlay: Position `Top Left` · Size `Medium` · 色 `#F8F8F8`。**Overlay Text 本身默认为空**（参考图里 `Overlay Text 123` 是示例内容非默认值）。
**⚠️ 制式项不再与参考面板一致**：MicroApps 参考面板的原始值是 `Progressive (p) / 30`（§1 参考表仍如实记录该原值，**勿据本条去改它** —— 那是参考设计的事实记录）。本条改的是**本 feature 的默认值**，owner 2026-08-03 拍板。 |
| D7 | **LCD 上叠加组只读可见** | Config-T 开了 Timecode/Overlay 时，LCD 测试页信号行给只读提示，避免现场看不懂画面上的字哪来的。 |
| D8 | **LCD 设置页一律照既有设置页范式**（2026-07-29 owner 走查新增） | canonical 参考 = `0054ib0nLmt27bC3QlGDl7` 的 `8878:2`。布局、图标、按键行为全部沿用：42px 行 + 右对齐控件列 + 下向三角展开标记；**底栏只放 `OK` + `Home`，「返回上一级」由左上角返回箭头承担、不在底栏再放 `Back`**。此范式适用于 LCD 后续所有需求设计。 |
| D9 | **同屏可视线索唯一性：一个图标只指一个目的地**（2026-07-29 owner 走查二轮新增） | home 屏底栏已有全局设置齿轮（`TouchScreen/Icon/settings`，`9592:434`）。若在同屏右栏再放一个**同源同形**齿轮指向 Test Signal 参数页，两个视觉完全相同的图标就指向了不同目的地，现场无法区分 → 禁止。
**新入口一律先在既有导航树里找落点**（本例 = `Settings` 二级列表 `5802:1074` 新增一行，与 `Delay` / `VoIP & IFB` / `Slot` 同级）；只有确实没有落点时才引入新可视线索，且新线索必须与既有线索**形状上可区分**（换图标族，不是靠尺寸差 4px）。
连带教训：为塞下新图标而挤压既有布局（本例右栏左移 13px，把视频区与右栏之间**全部** 12.55px 间距吃光）属同一病灶的下游后果——**「容纳新元素」不构成压缩既有 sibling 间距的理由**。此规则适用于 LCD 后续所有需求设计。 |
| D10 | **参数选项集的权威来源 = Test Stream Generator 微服务现有版本**（2026-07-29 owner 走查四轮新增） | 选项集与既有 **Test Stream Generator 微服务**一一对应，且都是 **mediahub 已支持**的参数 —— 本需求不引入任何新后端能力。
**画在 mockup 上的档位清单是「常见类型」示例，不是穷举 spec**：owner 原话「常见的类型，主要以现有版本为主，所以用文字说明」→ 面板画常见档位（`720p50` / `720p60` / `1080i5994` / `1080p30` / `1080p50` / `1080p60` / `2160p30`），**权威清单以微服务现有版本为准、由 dev 对照 mediahub 核定**，这一口径必须写进 UX 交付说明与 PRD 的**文字**里，避免 dev 把图当穷举。
**交错格式保留**：交错格式仍要支持（owner 明确）；**2026-08-03 轮十八起该档位写作 `1080i5994` 并成为默认制式**（原写 `1080i60`）。
档位有 canonical 实证：选项列表范式 `5314:9564` 实测即 `720P50 / 720P60 / 108030 / 1080P50 / 1080P60`，故 720p 两档不是推测。
**每个设置项必须给推荐默认值并写进 UX 交付说明**（方便开发与测试查看）：LCD 三项 = `Color Bars` / `1080i5994` / `1 s`；Config-T 全量默认同源自 MicroApps 参考面板实测。
**枚举值文案不缩写**：`Continuous` 不写成 `Cont.`（owner 走查四轮指出）。
**2026-07-30 轮七补记 —— 两个 surface 的档位表述形态不同，不可互抄**：本条口径轮六时只写进了 LCD 侧（PRD + UX 卡 + L3 caption 共 23 处命中），**Config-T 侧 PRD 与 UX 卡两处都缺**（机检实测 `mediahub` / `Test Stream Generator` = 0），且 PRD `req 7` 还残留旧口径「以 **RPS One 硬件**支持的组合为准」。轮七补齐，两处均含权威来源 + 档位 + 「示例非穷举」。
**关键区分（轮七实证，AI 第一版就踩了）**：LCD 暴露的是**合并 Format 预设**（`720p50 / 1080i5994 / 2160p30` 这种），Config-T 暴露的是 **Resolution / Scan Type / Frame Rate 三个独立下拉**（帧内实画 Resolution = `1280 x 720` / `1920 x 1080` / `3840 x 2160`）。**把 LCD 的合并预设写法搬进 Config-T 的文字 = 与该 surface 的界面互斥**。Config-T 侧正确写法 = 三下拉各自取值 + 「只允许提供彼此的**合法组合**」+ 一句「LCD 侧把同一集合以合并的 Format 预设暴露」把两端接起来。
**这也坐实了「Config-T 比 LCD 更需要这句口径」**：三个独立下拉的笛卡尔积远大于合法组合数，不写这句 dev 无从判断哪些组合合法。详见 handoff §1k-G ④。
**2026-07-30 轮八回流（双向引用）**：本条的「两端不可互抄」已作为 DS 通则沉淀 —— **§M-DISCIPLINE.SYNC §2a ③ 轮**新增第三形态**「跨 surface」**（交付物文字 ↔ 该 surface 的界面本体，须 `use_figma` probe 实测）+ 判据 **d** + 实证 C，触发条件加「把一个 surface 的口径复用到另一个 surface 时」。 |
| D11 | **新设置项在 Settings 列表的落点 = Receiver 之后（第 2 位）**（2026-07-29 owner 走查四轮拍板） | canonical 列表 `5802:1074` 原顺序 = `Receiver / Encoder / Delay / NTP Host / VoIP & IFB / Slot`；**此前为凑「5 行精确贴合 210px 视口」把 `Receiver` / `Encoder` 两行裁掉了，这是错的** —— canonical 本身就是「内容 240 > 视口 210」的**可滚动裁切态**，不该为贴合而删既有行。
本轮已补回两行，`Test Signal` 插在 **Receiver 之后（第 2 行）**，列表 7 行、pad 恢复 canonical `6/24/6/24`、容器 FIXED 210 + `clipsContent`。
**判据（可客观论证，非偏好）**：放列表末尾时新行落在第 7 行 → 210px 视口里**默认不可见**，用户必须翻页才能发现新功能；放第 2 位则首屏完整可见 `Receiver / Test Signal / Encoder / Delay`。语义上 Test Signal 决定「发什么内容给该接收端」，紧邻 `Receiver` 也最近。
**推论（适用后续 LCD 需求）**：新功能入口行**不默认追加到列表末尾**，先算它在视口内是否可见；同时**面板 / 列表容器不得为容纳新增项而超出 canonical 尺寸**（本轮 Format 面板加行后 hug 到 246、实测压住底栏，已固定回 `240×176` + 裁切 + ▼▲ 翻页）。 |
| D12 | **一个 feature 只有一个 AFTER 流程图：共同起点 + 分支**（2026-07-29 owner 走查四轮拍板） | 同一 feature 出现两个平级 `AFTER` Section 时，dev / QA **不知道该看哪个**。若两个流程的起点屏本就是同一屏（本例 `9359:492` 与它的 clone），必须**合并成一个 Section**：一个共同起点帧 + 按 UX 交互流程线分出两条支线（本例线 A = 直接开测，线 B = 参数设置），**删掉重复的起点 clone**。
落地形态：起点帧居左上，两列纵向支线（线 A `x=40` / 线 B `x=1000`），caption 沿用「帧右侧」既有范式，连线从起点分叉（横向支线连线用 `RECTANGLE` 横段 + `POLYGON` 箭头拼装，**不要拉伸既有连线 VECTOR** —— 会把箭头拉变形）。
caption 编号体系随之改为 `①（共同起点）/ A1…An / B1…Bn`，让「哪条线的第几步」自解释。
**入口链路必须画全每一跳**：本例此前漏了齿轮与 Settings 列表之间的**主菜单页 `5802:819`**，导致文档写「3 跳」而实际是 **4 跳** —— 流程图缺一屏，PRD/UX/Journey 的跳数描述就全错。 |
| D13 | **canonical 尺寸不是硬上限，物理边界才是；关键档位必须进首屏**（2026-07-30 owner 走查五轮拍板，**修订 D11 推论**） | owner 原话：「增加一个选项 1080p60，绿框的高度根据内容来调整即可。」
**背景**：轮四按 D11 推论把 Format 面板固定回 canonical `240×176`，代价是首屏只剩 5 行（`720p50 / 720p60 / 1080i60 / 1080p30 / 1080p50`），`1080p60` 这个常见档位落在裁切线外、**在效果图上完全看不到** —— owner 看图时因此认为"列表里没有 1080p60"。
**修订后的口径**（替代 D11 推论里"不得超出 canonical 尺寸"的绝对表述）：
① **硬上限是物理边界，不是 canonical 数值** —— 容器底缘不得压住底栏、不得超出内容区。本例 LCD L3：内容区底 `274`、底栏 `y 279`，故面板底 ≤ 274 才合法。
② **在物理边界内，允许为"让关键档位进首屏"而扩容器**。6 行 = 211 高 → 面板底 `257` ✓；7 行 = 246 高 → 面板底 `292` ✗（压底栏，这就是轮四实测撞的墙）。**故 6 行是本例的物理上限**，第 7 行 `2160p30` 仍靠 `▼▲` 翻页。
③ **D11 推论中仍然有效的部分**：新功能入口行不默认追加列表末尾（先算它在视口内是否可见）· 不得为容纳新增项压缩既有 sibling 间距（D9）。**失效的部分**：把 canonical 数值当成不可逾越的上限。
④ **依附容器几何的手画装饰必须同步改**（§M-INTEGRITY §I7 第 ③ 项）：本例连体绿框 `Rectangle 1009` 随面板从 176→211 同步调整，绿框底 `258` vs 面板底 `257`（2px CENTER 描边贴合）。
**落地实测**：面板 `9593:942` = `240×211` + `clipsContent`；6 行 FULL 可见、`2160p30` HIDDEN；§I7 三项复测全 PASS。
**DS 侧已同步（2026-07-30 轮六，commit `9aad3820`）**：§I7 初版把「回到 canonical 尺寸」写成正解、与本条反向，已订正为「默认 / 例外 / 硬上限恒为物理边界」三层；`domain-tvu.md` §M17.1 的「面板 240×176」也改为「宽 240 + 高按内容算」，防规格表把 canonical 实测读成硬上限。详见 handoff §1k。 |
| D14 | **两端都要显示"发给哪个 Receiver"并可修改；取值 = 已交付的 8.3 Preset R 逻辑，不自造**（2026-07-31 owner 走查十轮拍板） | owner 原话：「Config-T 界面遗漏了 Receiver 的显示和修改，到时候发起 Test 都不知道 Receiver 是哪个，不合理，R 的显示同 T 发起 Live 时使用的 R 逻辑同理（默认用最新选择的 R，若无，则用最近一次 Live 的 R）」。
**先 probe 再落笔（§2a ③ 轮判据 d）**：Config-T page `8075:2` 全 page 搜 `[Rr]eceiver\|接收` 实测 **0 命中** —— 界面、PRD、UX 卡、Journey 卡全都没有，owner 的观察成立。
**取值逻辑不是新设计，而是引用既有交付**：同文件 `9257:2`「▲ 2026-07-03 · 8.3 Preset R 逻辑更新」卡（Jira V4-2309，target 8.3）已定义完整口径 —— `setPresetR`/`getPresetR`，**LCD / Config-T / Remote Control 共用同一个 Preset R**；回退优先级 ① preset 在线→用 preset ② 离线→回退 `lastliveR` ③ 都无→回显空 + 发起动作置灰、须手选在线 R；picker 只列 `link!=='0'` 的在线设备；Preset R 无清空、换 R 即覆盖；`T_INFO` 新增 `PRESET_R` 节点供界面回显。**owner 原话覆盖了 ①②，第 ③ 态属同一真源，一并写入两端。**
**落点判据（可客观论证，非偏好）**：Receiver 回答「这次测试**发给谁**」，逻辑上先于信号组回答的「**发什么**」；与 LCD / Go Live 的信息顺序一致。故 Config-T 置于 `Content` **index 0**，与信号组之间加 divider 独立成组（三组变四组：Receiver / Signal / Timecode / Overlay）。
**两端形态不同、规则相同**：Config-T 用 `select box/filled` 下拉（与其它参数同款，`Update` 提交，运行中随其余控件 `enable:off`）；LCD 用整页 picker。此对应关系句已写进 Config-T UX 卡 Interaction（判据 d 强制项）。 |
| D15 | **未选 Receiver 用「导航引导」而不是「提示弹窗」**（2026-07-31 owner 走查十轮拍板，**推翻此前的 no-receiver-selected prompt**） | owner 原话：「未选 Receiver 时，流程参考 Go Live 的流程，引导用户去选择接收机后再发起测试」。
**实测推翻了「prompt」这个前提**：probe `8062:8070`（page `8062:545`）后确认 Go Live 的真实机制**根本不弹提示** —— 未选 R 时 home 屏 Receiver 行显示 `- - -` + `icon/Arrow/Sorting`，**点 Live 按钮直接跳转**到「Please select a Receiver」页（连线注释原文 `home button --> Please select a Receiver`）。故本条不是"换一种提示样式"，是**用导航替代提示**。
~~**底栏形态按进入场景区分（照搬已交付范式）**：未选态进入 → 底栏只给发起动作（`8062:6873`）；已选态改选 → 底栏 `OK` + 发起动作（`8062:8004`）。~~
**⚠️ 2026-08-03 轮十一 owner 推翻上述区分**（原话：「实际上 C1 和 C2 的效果图应该一样，都需要同时显示 OK 和 Test Signal」）→ **两态底栏一致：每一步都同时提供 `OK` 与 `Test Signal`**，可只保存选择（OK）、也可在同一步直接开测（Test Signal）。**Go Live 源帧的两形态差异不照搬**；两帧的唯一差别退化为「未选态 vs 已选态」（**2026-08-03 轮十六 D23 ① 修订**：未选态 = 字段行无值 + 列表无三角选中标记；已选态 = 字段行绿字回显 + 被选项带标记。原表述「字段行 `---` vs 绿字当前值」已作废）
**⚠️ 2026-08-04 轮二十一 D28 再修订 —— 上句的「未选态」不再由 C1 承载**：owner 拍板 C1 转为**已选态**（字段行回显当前接收机），未选态的载体是新增的 **`C0` 帧**（`9866:338`）。线 C 由三步变**四步** `C0 未选 → C1 当前 R → C2 改选 → C3 运行中`。**未选态的形态定义本身不变**（字段行无值 + 列表无三角标记），变的只是它画在哪一帧上，这也让它们顺理成章成为同一条时序线的前后两步（见 D17）。
**Config-T 侧同规则不同形态**：web 端不做页面跳转，改为字段留空 + `Start Test` 保持置灰，直到选定一个在线接收机。
**该选择页恰好符合 §M17.1 LCD 选项列表 canonical**（绿框字段行 + 右对齐面板连成一体 + 当前值绿字 + 矢量 ▶ 选中标记 + `▼▲` 翻页），与本 feature 的 L3 Format 选项列表同一范式。
**连带作废**：Journey `9598:221` 原 🔴「本期未设计：链路失败 / 接收端全离线」已被本条与"补必要状态"共同推翻，已删除并改列为 🟡 文字描述态（§2a ③ 轮判据 b）。 |
| D16 | **状态粒度：只有"未选 Receiver"配效果图，其余三态用文字**（2026-07-31 owner 走查十轮拍板） | owner 原话：「这几个状态用文字描述，顶多补充选项一那个，这样既可以了解交互流程又能有效果图示意」。
四态定案 —— **未选 Receiver = 效果图**（LCD 线 C；**2026-08-04 轮二十一 D28 修订**：原写「线 C 两帧」，因当时 C1 兼作未选态。C1 现为已选态 ⇒ **未选态的效果图载体 = 新增的 `C0` 帧 `9866:338`**，本条据此仍然成立、未被削弱）**+ 文字**；**R 离线/不可用**、**发起失败/链路不通**、**无信号源** = **仅文字描述**，写进两端 PRD 功能需求 + 验收标准 + UX 卡 Acceptance + Journey State coverage，**不新增帧**。
**⚠️ 2026-08-03 轮十三边界澄清（§2a ③ 轮判据 b，防下轮误读）**：本条「仅文字、不新增帧」约束的是上面点名的**三个异常/边界态**，**不含主线时序态**。轮十三新增的 `C1a · Starting` 属「点 Start Test → 跑起来」这条主线的中间态（D19），与本条不冲突 —— 读到本条时**不要**据此认为「不该给 starting 加帧」。
**判据**：这三态要么已有既定逻辑真源（R 离线 → D14 的 8.3 Preset R 回退），要么已有承载帧（无信号源 = 起点帧 `9359:492`），要么是纯错误反馈（发起失败）——都不需要新画屏来说清，画了反而稀释流程图的主线。
**发起失败态的硬约束**：界面停留在空闲态并给出失败反馈，**不得呈现虚假的 LIVE / 运行中状态**（两端 PRD 均已写死）。 |
| D17 | **AFTER 流程图列序 = A · C · B；线 C 是三步时序线；Config-T 补 LCD 结果示意**（2026-08-03 owner 走查十一轮拍板） | owner 原话：「需要把 C1 和 C2 的位置重新调整一下，目前的流程线不容易看起来想要表达什么意思，包括点击 Test Signal 后的效果也需要显示」+「config-T 点击 Start Test 后的 Mockup 没有，最好可以在旁边贴上 LCD 的效果，这样可以看到示意」。
**① 线 C 补足为三步时序**：C1 进入选择页（**未选态：字段行无值 + 列表无选中标记**；~~字段行 `---`~~ 已由 2026-08-03 轮十六 **D23 ①** 修订）→ C2 选中（绿字回显 + 被选项带三角标记）→ **C3 点 Test Signal 后 = 测试运行中**（clone 线 A 已交付的 `9359:678`，源帧未动）。补 `C1→C2` / `C2→C3` 纵向连线，caption 改为步骤叙事。**关键语义：线 C 与线 A 汇合于同一结果屏**，caption 明写「两条路径在此汇合」。
**② 列序改为 A（直接开测）· C（先选接收机）· B（改参数）**。判据：线 C 与线 A 汇合，相邻才体现「殊途同归」；且线 C 是主按钮 `Test Signal` 的直接结果、应离起点最近，而线 B 入口是底栏齿轮、与起点关系本就更间接。位移 = 线 B 14 节点 `x+=960`、线 C 8 节点 `x-=960`。**两条分叉连线的几何恰好互换匹配（两列间距同为 960），只需互换命名、无需重画**。
**③ 两条分叉线加 cyan 标签**（「分支 C · 未选接收机 → 先选再开测」/「分支 B · 改参数」）—— 直接回应「看不出想表达什么意思」，长绕行线尤其需要。
**④ Config-T 在 C2 下方贴 LCD 运行态示意**（`upload_assets` 跨文件置入，承载帧 `8146:527`）+ 双语说明：「Config-T 是配置端，只显示测试正在进行、看不到信号本身」「仅作示意，LCD 界面在 LCD 文件交付、不属 Config-T 范围」。
**⑤ Config-T「同类问题」排查结论 = 不存在**：三帧是**状态清单**范式（idle / running / dropdown）而非时序流程图，无帧间连线是正确的；底栏 `Start Test` / `Stop Test` 的差异是**正确的状态差异**，不同于 LCD 那种「同一页两形态不一致」；未选态按 D16 属文字描述、无需补帧。 |
| D18 | **Config-T 全部交互控件归到 DS 真源库；`remote: true` 不再被当作库归属证据**（2026-08-03 owner 走查十二轮拍板） | owner 原话：「我发现 config-T 里面的 Button 你用错组件库了，应该是 TVU UX Design System，规则里面都说了，但是你还是找错其他组件库了，找找原样」+ 定位 `8079:886`「应该是 Tab，但是用到其他组件库了」。
**① 语义判断（owner）**：Position（`Top Left` / `Top Right` / `Bottom Left`）与 Text Size（`Small` / `Medium` / `Large`）是**在一组里选一个的互斥控件 → 语义是 Tab**，不是「触发动作」的 Button。
**② 三层偏差，逐层记清（别只修最外面那层）**：**(a)** §4 M0 表当时定的就不是最终正解（写 `Button/dark M` —— 组件族选错，但库是对的）；**(b)** 实际建成的与表不符，建成了旧库 `button/no icon`（`4c56b094…`，**表定 A、建成 B、且 B 连库都错**，当时无人复核）；**(c)** owner 拍板的正解是第三个答案 —— `Tab/Item`。
**③ 根因**：此前机检只统计 `instanceOrigin {remote, local}`，把 `remote: true` 当成了「库归属正确」。但产品文件可同时订阅多代库（本例 4 个：DS 真源 / 旧 `TVU UX Library` / `Config T ( Local UI )` 产品库 / `Nancy's Design Assets` 个人库），**`remote` 只说明「来自某个远端库」，不说明「来自哪个远端库」**。
**④ 落地（对象全集 = 全量核验推出的，不止 owner 点名处）**：分段 18 处 + **Tx `1 2 3 4` 选择器 12 处**（旧库，派单未列）→ `Tab/Item`；**Overlay Text / hex 输入框 9 处**（个人库 `WebUI/Form/Input*`，派单未列，与 (b) 同型偏差）→ DS `input box/filled`。核后旧库与个人库输入框在三帧内均 **归零**。
**⑤ 置灰态的口径**：DS `Tab/Item` 实测只有 6 个变体、**没有 disabled 轴**，而 C2 是运行中全禁用（D5）。owner 拍板 —— Figma 侧整组 `opacity 0.45` 示意，**Figma 组件库先不动**，把「补 disabled tab」**回流到 Code 组件层**实现；该口径已写进 Config-T UX 卡 Interaction + caption C2，明确要求 dev **不要照搬降透明度**。**DS 侧双向引用（§2a ③ 轮判据 c）**：已在 DS repo 立 backlog **`CANONICAL-F92`** + `figma-component-catalog.md` 的 `Tab/Item` 条目新增「Known gap — 无 disabled 态」与「分段控件就用它、别用 Button」两段，两处均反向引用本 D18。
**⑥ owner 明确要求**：Tx 选择器这类「继承自 canonical 全窗帧的 chrome」的改动，必须**在 UX 交付说明里写出来**，方便开发注意到（已落在 UX 卡 Changes）。
**⑦ 未改项（显式登记，非静默跳过）**：`CopyRight` 3 处属个人库、`line` 3 处 4 库检索均未命中 —— owner 拍板本轮不动，作产品级存量债；LCD 侧不适用本条（设备端自绘 UI，其 Tone 分段不是 DS 组件，此对应关系句已按 §2a ③ 轮判据 d 写进 Config-T UX 卡）。
**⑧ 通则**：判库归属只认 `search_design_system` 带 `includeLibraryKeys` 返回的 `libraryName`；机检不得只报 `remote/local`，须逐 instance 对照已坐实的 key→库白名单（Config T 产品库走显式白名单）。 |
| D19 | **Config-T 必须画出「点 Start Test 之后」的完整反馈：starting 中间态 + ~~常驻运行标识~~ + 操作结果 toast；分段统一 16px 间距 + 未选态抬色**（2026-08-03 owner 走查十三轮拍板）
**⚠️ 2026-08-03 轮十四 owner 推翻本条 ② ③ 中的「状态行 / Badge」部分**（见 **D20**）：两条 `row · Test status` 已删除，starting / running 状态改由**动作按钮**承载。本条其余部分（starting 中间态帧本身、toast、分段形态、`Tab List` 走不通的实测、未选态抬色）**全部仍然有效**。 | owner 原话（起手）：「config-T 点击 Start Test 按钮后，效果图没有更新，包括按钮状态、操作结果提示等，其他没啥问题」。
**① 判据（为什么 Config-T 比 LCD 更需要这个）**：LCD 点 Test Signal 后画面**立即**变彩条 + TEST 带，设备端的反馈就是画面本身；Config-T 是配置端、**永远看不到信号**，所以"已经发起 / 正在跑"只能靠文字与状态标识讲出来。**已 probe LCD 本体实测**（page `9343:2`）：LCD 分支帧只有 C1 未选 R / C2 已选 R / C3 运行中，**没有 starting 中间态**，两端形态不同处已按 §2a ③ 判据 d 在 Config-T UX 卡 Interaction 补对应关系句。
**② 三态时序定案**：`C1 idle` → **`C1a Starting`（新增帧）** → `C2 Running` → 点 `Stop Test` 回 idle。`C1a` = 蓝 `Badge/Starting` + 状态行 + 动作按钮 `Starting…`（`web button clickable=no`，防重复发起）+ 参数已锁 + hint 改为「Parameters are locked while the test is starting」；**此时不出 toast**。
**③ 运行态双件套**：`C2` 顶部常驻绿 `Badge/Running` + 状态行「Test signal is running · sending to PM_X7L」（**因为 toast 会自动消失，"仍在运行"必须有常驻载体**）+ DS `Message`（`status=success`、`Show close icon=false` 即自动消失）「Test signal started」作为操作结果。
**④ `Message` 无 dark-theme 轴**（只有 `status × size`，`Notification` 才有 theme）→ success 态在深色界面上呈浅色。**按发布原样使用、未改色**（改色即违反 binding-fidelity），已在 UX 卡明写「dev 不要自行改色」。跨 surface 实测坐实两端同源：**LCD 也在用 DS `Message`**（`status=info` 的「Video input detected」）。
**⑤ 编号策略**：新帧命名 **`C1a`** 而非重编号 C2/C3/C4 —— 避免 spec §3.2 表、PRD、UX 卡、caption 里大量既有编号被动改写（最小涟漪）。
**⑥ 分段最终形态 = owner 手调结果，不是 AI 的连体方案**：owner 先选「换 `Tab List` 真连体（0 间距）」，实机手调后定为 **`itemSpacing 16`**（非 0、也非原 8）+ 未选态填充 **`#353535`**。8 组（4 帧 × 2 组）已全部对齐，宽 314 / 251、行宽 525 / 462。**AI 先前写进 UX 卡的「连体 / itemSpacing 0 / 无间隙」措辞已就地修正**（自制旧措辞，§2a ① 抓出）。
**⑦ `Tab List` 走不通的实测（记录以免下轮重试）**：`Tab List Type=Filled` 的 SLOT 在 `use_figma` 环境下**无法可靠编辑** —— 纯读正常（slot 含 3 个 `Tab/Item`），但**任何写操作（`setProperties` 或改 `characters`）之后，slot 内 nested 子节点句柄全部失效**，通过父引用重新遍历也拿不到；四种写法均在同一点失败。逐 tab 拆调用需 24–48 次，成本不合理。故采**等价形态**：保留既有 auto-layout 容器 + 3 个**顶层** DS `Tab/Item`，用 `itemSpacing` 控间距 —— 组件层仍 100% DS 真源。
**⑧ 未选态抬色的真正含义（owner 明确，已回流 DS）**：owner 原话「主要是为了跟现有页面的背景颜色做对比，**不是绝对的色值，需要动态根据当前模块的背景颜色来调整**，可以回流到设计规则里面」。实测：`Tab/Item` 未选态原生 `#262626`（**已绑变量**）vs Config-T 内容区底 `#252525` → 对比度 **1.013**（不可辨）；`#353535` = **1.25**；选中绿 = 5.723。且 `#262626` = `--bg-layer3`、`#353535` = `--bg-layer4`（同族 `input box/filled` 填充底用 layer4）→ **未选态很可能只是绑错档位**。已回流 DS：backlog **`CANONICAL-F93`** + `figma-component-catalog.md` 的 `Tab/Item` 新增 Known gap 段（commit `64ffe026` + `03272cbc`，双 remote 实测已落地），并标注与 open PR #9 `docs/M21.2-feature-iteration-color-contract` 同主题不同对象、合并前先核其最终 diff。
**⑨ 显式不动项**：`Tx 1–4` 选择器 3 组 12 个仍 `itemSpacing 6` —— 它是继承自 canonical 全窗帧 `7485:1145` 的 **chrome**（D18 ⑥ 已定性），与表单内分段不同族，改它等于偏离 canonical。已在 UX 卡 Changes 写明「有意不动」。 |
| D20 | **状态由动作按钮承载，不另设状态标签；`Stop Test` 用 DS 蓝 token —— 与 LCD 同源**（2026-08-03 owner 走查十四轮拍板，**修订 D19 ② ③**） | owner 原话：「这个需要去掉，只在按钮上体现就可以，Stop Test 按钮我已经改成蓝色的了」+「config-T 的 Test 的按钮的色值为什么跟 LCD 不一样？这样会导致用户关联不起来」+ 拍板「两条状态行都去掉，浮层提示保留」「用设计系统里面的蓝色」。
**① 对象全集 ≠ owner 点名处**：owner 只贴了 C1a 的 `8180:720`，但 C2 有**完全同型**的一条（`8181:674`）。两条一并删除 —— 只删一条会让两帧顶部结构不一致、帧高也不再相等。删后 C1a / C2 由 `1228×1175` 回到 `1228×1131`，**四帧全部等高**。
**② 常驻载体换了对象，论证依然成立**：D19 ③ 说「toast 会自动消失，所以『仍在运行』必须有常驻载体」——该论证不变，但载体从「状态标签」换成 **`Stop Test` 按钮本身**（整个运行期常驻，且变蓝）。按钮同时承载「可执行的动作」与「当前状态」，比额外加一行标签更省，且与 LCD 同构（LCD 也不在画面上加 badge）。
**③ 跨端蓝色实测坐实同源（本轮关键发现）**：DS `UX/Blue/Default` Dark = **`#3892f3`**、`UX/Blue/Hover 1` Dark = **`#62a9f6`**；而 LCD `Stop Test` 按钮实测是 `grad #62a9f6 → #3892f3` —— **LCD 那个蓝本就是这两档 DS token**，不是自造色。故「用 DS 的蓝」与「跟 LCD 对齐」是同一个值。owner 手调的 `#33a4fd` 是本文件注释层 cyan、不属 DS 蓝族，已替换为绑定 `UX/Blue/Default`。
**④ 不追求两端 hex 完全相同（判据）**：两端语义映射（绿=开始 / 蓝=停止运行中 / 灰=不可用）已一致；不一致的只是实现形态（LCD 渐变 vs Config-T 纯色）。改 Config-T 的绿会与该文件其它所有页面的主按钮脱节（`#33ab4f` 是 Config-T 全产品主按钮色），改 LCD 渐变会偏离已交付设备端帧 —— 两头都有代价，而用户跨端关联靠**文案 + 色相语义**，不是像素级比色。
**⑤ 组件缺口（实测，更正 owner 一处判断）**：owner 认为 DS 里有蓝色按钮，实测 `Button/dark M / dark L / dark S / light M` 四个组件集的 `color` 轴一律 `gray 1 / green / orange / red`，**均无 blue**；Config-T 产品库 `web button` 也只有 `clickable=yes`（绿 `#33ab4f`）/ `no`（灰 `#4f4f4f`）两个变体。**DS 有蓝色 token 但 Button 不暴露蓝色轴** = 真实缺口，已回流 DS backlog **`CANONICAL-F94`** + `figma-component-catalog.md` 的 `Button/dark M` 新增 Known gap 段，两处均反向引用本条。UX 卡已写明：dev 须实现**停止态按钮变体**，不要写死色值。
**⑥ 显式保留项**：C2 的 DS `Message`（`status=success`、自动消失）**保留** —— owner 明确「浮层提示保留」。它是**一次性操作结果**，与「常驻状态」性质不同，两者不可互相替代。C1a 仍不出 toast。
**⑦ 已知取舍（非缺陷）**：C1a 与 C1 的视觉差异现在只剩底栏按钮与 hint 一行字，两帧并排看差异微弱。这是「只在按钮上体现」的必然结果，annot 已写清差异。 |
| D21 | **四条悬置项一次性裁定：组件缺口打包提库维护者 · 分隔线只认 DS 真源库 · 浮层位移一律实测比对 · 提示浮层只维持单主题**（2026-08-03 owner 走查十五轮拍板） | 本轮 **mockup 零改动**，四条全部落在设计系统真源与文档层。
**① 三条 tab / button 变体轴缺口打包成一次裁定提库维护者，禁分开改**（owner：「同意推荐」）。三条 = 分段 tab 无禁用态 · 分段 tab 未选态填充不随模块背景 · 按钮无蓝色停止态；都落在同一族组件上，分开改容易做出互不兼容的决定。**前置已实测解除**：此前写「合并前先核那条做颜色对比的分支最终改了什么」，实测该分支（`docs/M21.2-feature-iteration-color-contract`）**完全没有触及分段控件**（三个 doc 文件里 `Tab/Item` 命中 0；它实际改的是弹窗底部按钮行的坑、表单字段包装器条目、文字节点双绑规则），且**落后主干 815 个提交、仅领先 10**，处于搁置状态 ⇒ 三条可独立裁定。已在 DS repo 建统一入口 **`CANONICAL-F92–F94 · 打包裁定入口`**（含裁定顺序建议：未选态改绑档位最省 → 按钮加蓝色轴 → 禁用态须与另外三个缺 disabled 的组件一起定）+ 三条各自加反向指针 + 标出必须收敛的 `opacity 0.45` vs `0.4` 数值分叉。
**② 分隔线归属：只认 TVU UX Design System 一个库，查不到就收口**（owner：「不用搜索其他库，只需要搜索 TVU UX Design System 这个设计库」）。实测结论比"检索未命中"更硬：DS 库内以 `line` / `divider separator horizontal rule` / `Divider` 三组关键词分别检索（`search_design_system` + `includeLibraryKeys`），**本库没有任何独立的分隔线 component / component_set**；本库的分隔线范式 = **画 1px 线 / 细 rect + 颜色绑 `Color Type/Line/Deep Divider` 或 `Light Divider` 样式**。⇒ 顶栏下那 4 个 `line`（`907b0e79…`）**结构上不可能在 DS 库里找到归属**（不是检索能力不足），定性为「非 DS 真源件、且 DS 无同形态组件可换」，记产品级存量债、**停止每轮重查**。已把这段指路写进 DS catalog 的 `Border / divider` 段，防下轮又去搜组件。
**③ 浮层位移后的检查规则改成单一动作规则**（owner：「同意修改」）。旧条文按「容器本身位移 → 不补 / 容器内容位移 → 手动补」分两套处置，要求执行者动手前先正确分类，而两种分类错误方向相反（漏补 / 多补）、事后都不易看出。新条文 = **容器或其内容发生任何位移 / 增删 / 尺寸变化后，一律实测依附元素与其依附对象的间距并与变更前基线比对，差值不为 0 才调整；禁止靠预判分类**。已回流 DS `mockup-conventions.md` §M-INTEGRITY §I7 ③（把 `ABSOLUTE` 浮层显式纳入 ③ 的对象 + 加硬约束一条 + Acceptance 加「须贴 `baseline → now` 两个实测值，而非分类结论」+ 同步顶部 Quick Reference 那一行）。
**④ 提示浮层在深色界面呈浅色 = 不立缺口**（owner：「不用，这个是设计库的真源，只维持一个主题就行，不用两个主题」）。即 `Message` 只有 `status × size` 两轴、无 theme 轴是**有意为之**，不是缺口。⇒ **不给它立 backlog、不提案增 theme 轴、消费侧一律按发布原样使用禁改色**（改色即断变量绑定）。已写进 DS catalog `Message` 条目的 Owner ruling 段（含两端实证：Config-T success 态呈浅色 / LCD `status=info` 正常）。本条同时**闭合 D19 ④ 留下的悬置**。 |
| D22 | **单选按钮归到设计系统 radio · 禁用表达统一为一条规则 · Text Color 照参考给快捷色块**（2026-08-03 owner 走查十五轮中途三次追加派单） | owner 原话：「这种单选按钮的为啥没用设计库中的组件啊」（贴 `8081:484`）+「设计库中的组件已经有禁用的样式了，不用再整体降低透明度了，比如这个」（贴 `8081:499`）+「没有禁用变量的组件可以沿用透明度，其他的有禁用变体的就用禁用变体；Color 要跟参考样式的一样，提供几个快捷选项」。
**① 单选按钮归正（20 处）**：实测建成物是 Config-T 产品库 `WebUI/Form/Radio/Selected` + `/Unselect` —— **两个独立组件、无任何变体轴**；DS 有 `radio`（8 变体，`dark theme × status × enable`）。前几轮机检按「产品自有库＝M32 第 2 条正常落点」判它合规，**规则字面上没错，但结果不一致**：同帧的下拉 / 输入框 / 开关轮十二都已归到 DS，只剩单选留在产品库。已全部换成 DS `radio`（C1/C3 用 `enable=yes`，C1a/C2 用 `enable=no`）。**换过去顺带修掉一个真缺陷**：此前 C1a / C2 号称「参数全禁用」，单选按钮却与空闲态视觉完全相同（因为产品库那对没有禁用态可切）。另修掉两处副作用 —— 旧外部标签是裸 `#f1f1f1` 无文字样式绑定，DS radio 的 label 自带 text style + 颜色变量绑定。
**② 禁用表达统一为一条规则（撤 7 处双重处理）**：owner 拍板口径 = **有禁用变体的控件就切变体，没有变体的才沿用降透明度**。实测发现 7 处容器在**已经用真变体的同时又整体降了透明度**（C2 三处 + C1a 四处：单选组 3 处、色块行 4 处），已撤掉容器 opacity。**对象全集 ≠ owner 点名处**：owner 只贴了 C2 的 `Time source options`，实际含 C1a 的两个单选组与两端各 2 处色块行；另发现 C2 的 `Tone Mode options` 本就没降透明度、与同帧 `Time source options` 不一致（轮十三遗留），现已统一。**仍保留降透明度的只有 4 处**：C1a / C2 的 Position 与 Text Size 分段 —— `Tab/Item` live 全枚举实测 **6 变体**（`Property 1`=Active/Normal × `Property 2`=Green/White × `Type`=Line/Filled/Text），**无任何禁用轴**（即打包裁定里的第一条缺口），加上自画色块也无变体，两者按 owner 口径沿用透明度。
**③ Text Color 照参考重建（8 处）**：原先只有单个灰色块 + hex 输入。按 owner「跟参考样式一样、提供几个快捷选项」，probe MicroApps 参考面板 `295:1035` 实测形态后重建 = **5 个快捷色块（黑 / 白 / 蓝 / 绿 / 红）+ 当前值绿描边 + 勾标记 + hex 输入框**。
**③-a 一处自我更正**：我起初判断「色块是用户要选的颜色数据、应该用 raw hex 不绑变量」，probe 参考后发现**参考的色块全部绑了 DS 变量**（黑=`Color Type/Background/Top Bar`、蓝=`UX/Blue/Default`、绿=`UX/Brand/Brand`、红=`UX/Red/Default`），故按参考绑 token 落地，见 §4 M0 表。
**③-b 两处刻意偏离参考（记录理由）**：参考的色块本体是**非 DS 库**的 `Tab` 组件（`5b16bb77…`，DS 库内只有 `Tab/Item` / `Tab List` / `Table`）→ **不引入**，沿用自画 rect（避免重犯轮十二「从一个错库换到另一个错库」的陷阱，DS 缺 color-swatch 组件的库候选登记保留）；参考的 hex 用 `input box/line`，此处保持 `input box/filled` 与本页其它输入框统一。
**③-c 绿勾的坑（实测）**：DS `icon/Edit/Selected` 原生把 vector 填充绑在 **`UX/Grey/grey-4 #DBDBDB`** 上，在本文件解析为浅灰、放在白色块上几乎不可见（参考文件里显绿是因为它把该 vector **换绑**到了 `UX/Brand/Brand`）。已照参考换绑 `UX/Brand/Brand` —— 是换绑、不是断绑写死 hex。 |
| D23 | **LCD 未选态 = 「列表在、无选中项」，不用 `---` 占位；Config-T 自定义色给出「第 6 个当前色块」方案示意**（2026-08-03 owner 走查十六轮派单） | owner 原话：「未选 R 时，不应该展示一个『---』，应该展示列表，但是没有已选中项，所以需要修改这里的 Mockup（贴 `9742:303`），相关的 UX 交付说明也需要更新」+「如果 Text Color 不是已经提供的那几个选项，而是自定义的选项，那么页面上应该如何展示（贴 `8159:43285`）做一个效果图看看」。
**① LCD C1 未选态（对象是两处，不止 `---`）**：实测 C1 与 C2 的 `Content` **逐节点同构**，差异只在字段行的值（C1 `---` `#666666` / C2 绿字 `PM_X7L`）。**但截图目视暴露了第二处**：列表里 `PM_X7M` 那一行带着**三角选中标记 + 深色高亮背景**（`Rectangle 4` + `Path`）—— 我起初只读机器值时把这两个节点判成「不是选中标记」，是**看图才发现**的。这正是 owner 说的「没有已选中项」所指。⇒ C1 落地两处：字段行值节点隐藏（未选态不显示任何值）+ 选中标记两节点隐藏（列表无任何选中项）。
**⚠️ 2026-08-04 轮二十一 D28 修订 —— 这两处隐藏已从 C1 迁到 C0**：owner 在本地把 C1 字段行改出值并把标记移到列表第 1 行（即 C1 转已选态，owner 已确认属有意改动），故本条描述的「隐藏两处」现落在新建的 **`C0` 帧**上（clone C1 后隐藏字段行值 `9866:376` + 标记对 `9866:374`/`9866:375`，**并把继承来的列表首行绿字改回普通行白字**——未选态下不该有任何绿字，此处是本轮实测补出的第 3 处，D23 ① 原文只点了两处）。C1 本身现为已选态，不再隐藏任何节点。**教训**：判「有没有某个视觉元素」，读节点名与坐标不够，必须看渲染图 —— 名字叫 `Rectangle 4` / `Path` 的节点可以是语义关键的选中标记。
**② C2 的一处既有不一致（本轮无法修，提请 owner）**：C2 字段行绿字是 `PM_X7L`，而列表里带选中标记的那一行是 `PM_X7M`，列表 4 项（`XMM_X8L` / `YLA_0912` / `PM_X7M` / `PM_UED`）里**根本没有 `PM_X7L`** —— 即「字段行说选了 A、列表里标记的是 B」。这来自 clone 源帧（Go Live `8062:8004`）的既有形态。**修法受工具限制**：列表项与字段值文本都是 **Verdana**，本环境 `loadFontAsync` 实测失败（`font family "Verdana" does not exist`），改字必然把它变成 Roboto、新增字体债（与 owner 已关闭的 88 处同源）。⇒ 三条可选处置留给 owner：(a) owner 本地把列表某一项改名为 `PM_X7L`（其环境有 Verdana）(b) 接受现状、在交付说明里注明列表为滚动态、当前值可能在可见区外 (c) 由我把该行改成 Roboto 并接受字体不一致。~~**本轮按 (b) 未动，如实登记。**~~
✅ **2026-08-03 轮十七 owner 拍板选 (a)** —— 由 owner 在本地把列表项改名为 `PM_X7L`（其环境有 Verdana，不产生字体债）。**我方无改动动作**；待 owner 改完后核一眼即闭合。
**⚠️ 2026-08-05 轮二十二实测收窄落点 + 核出未做**：① 该改的是 **C2 被标记那一行 `9742:392` `PM_X7M → PM_X7L`**，不是列表里随便一项 —— 依据是线 A 四帧（`9359:651`/`9359:837`/`9469:236`/`9480:279`）+ C3（`9760:491`）的 `video parameter` 区 Receiver 回显**实测一律 `PM_X7L`**，故取值链 `C1 当前 XMM_X8L → C2 改选 PM_X7L → C3 运行 PM_X7L = 线 A` 才自洽；改别的项则字段行与标记行仍对不上。② 机读 + 渲染图双证据确认 **owner 尚未改**（`9742:392` 仍为 `PM_X7M`）⇒ 本条继续挂账。详见 handoff §1k-W ①②。
**⚠️ 2026-08-05 轮二十三二次核验：仍未改**（`9742:392` 仍 `PM_X7M`，机读 + 渲染图双证据 —— C2 列表 4 项 `XMM_X8L` / `YLA_0912` / `PM_X7M` / `PM_UED` 里依旧无 `PM_X7L`）⇒ 继续挂账。**同轮升级定性**：本处与 D28 ⑦ (a) 同为「字段行值 ≠ 被标记行」，而 UX 卡 `Acceptance 9597:220` 的判据落在「**the matching row** / 对应的那一行」上 ⇒ 属**已交付验收条目当前判 fail**，**定稿发 Jira 前必须闭合**。详见 handoff [`§1k-X ③`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
**⚠️ 2026-08-05 轮二十四：本处成为唯一剩余的改名项，且验收压力已解除** —— D29 落地后字段行值不再单独显示，故 (a) C1 那处改名需求消失、UX 卡 Acceptance 的判据也从「两处 match」改为「整屏唯一一处绿」⇒ 本处不再是「验收判 fail」的成因；但取值链 `C2 改选 → C3 运行 = PM_X7L（线 A 同源）` 仍要求 C2 被标记那一行是 `PM_X7L`。**owner 本轮明确选「我本地改，零字体债」**（保 Verdana）。改完核一眼即闭合本条 + D28 ⑦。
**③ Config-T 自定义色方案（效果图已产出）**：落点 = 交付说明层，置于 C3 下方（标题 `8256:816` + 示意组 `8256:817` + 右侧说明 `8257:826`），沿用 LCD 结果示意那套范式（cyan 标题 + 承载内容 + 右侧双语说明，间距 60 / 16）。
**方案**：当 hex 值不属于五个预设时，**色块行末尾追加第 6 个「当前色」块**，由它带绿描边 + 勾标记；五个预设块此时都不带勾。示意含 A（预设态，当前=白）/ B（自定义态，当前=`#FFCC00`）两行对比。
**判据**：任何时刻「当前设的是什么颜色」都有且只有一个可见标记，且操作者能看到**颜色本身**而不只是色值代码。
**曾考虑未采用**：五个预设全不标记、只让 hex 输入框承载当前值 —— 未采用因为操作者只看得到代码、看不到颜色。
**第 6 块的填充有意不绑 DS 变量**（与五个预设相反）：它是操作者填入的原始数据，不是系统语义色。
**一处曾待拍板的边界**：当自定义色本身接近标记用的绿色（如 `#3FBF55`）时，勾标记会失去对比（已随方案被否而搁置）。
❌ **④ 本方案已被 owner 否决（2026-08-03 收尾）**：owner 原话「Text Color 自定义色方案看起来不太 OK，自定义跟快捷选项区别不大，再想下其他方案」。**判据（成立）**：第 6 块与前五块**同形同尺寸同标记方式**，读起来就是「又一个预设」，操作者分不出「我自己填的颜色」与「系统提供的颜色」；而这个区分恰恰是本方案要解决的问题本身。⇒ ~~Figma 示意区已就地标红为 `⚠ NOT APPROVED`（标题 `8256:816` + 说明 `8257:826` 开头插入否决记录与判据），**保留作为「此路不通」的存档，不要在其上继续搭**。~~ **⚠️ 2026-08-03 轮十七 owner 推翻本处置**（原话「Text Color 只保留通过的，未通过的移除」）→ **v1 三节点已删除**，不再作存档；判据 = 交付层只应留下现行方案，否则评审者面对两套并列示意需要自行判断哪套有效。本条其余部分（否决本身与判据）仍然有效。
**下一轮重新设计的方向线索（仅线索，未做任何决策）**：① 让自定义色在**形态层面**就与预设不同（角标 / 不同描边样式 / 与预设组之间加分隔），而不是仅靠位置在末尾；② 不用色块承载自定义值，改由 **hex 输入框自身**表达（框内嵌一个当前色小圆点）—— 即先前「未采用方案」的改良版，它天然不与预设同形；③ 引入**独立的取色入口**（预设行末尾一个色轮 / 滴管图标按钮，点开取色面板），把「选预设」与「自定义」变成两个不同的 affordance；④ 把当前色显示在 **label 一侧**而非预设行内。选型前须先按 M32 查 DS 库有无取色器 / 色轮图标类组件。 |
| D24 | **Text Color 自定义色 = 预设行退回纯快捷入口，当前色由 hex 输入框内嵌色点承载**（2026-08-03 owner 走查十七轮选型，**替代被 D23 ④ 否决的 D23 ③**）| owner 轮十六收尾否决旧版的判据（第 6 块与前五块同形同尺寸同标记 → 读成「又一个预设」）已记在 D23 ④。
**① 根因再推一层（本轮新增，比"换个花纹"更本质）**：旧版的问题是**信息架构错位** —— 预设行的语义是「候选值选择器」，我却让它同时承担「当前值显示器」。两种语义共用同一视觉形态，就必然被读成同一类东西。⇒ 正解不是给第 6 块换标记样式，而是**把「当前值」整体搬出预设行**。
**② M32 库检索实测（选型前置，三组关键词 + `includeLibraryKeys`）**：DS 库**没有**取色器 / 色轮 / 滴管 / 色块（swatch）组件（`color picker·color wheel·eyedropper` / `swatch·palette·color chip` / `icon plus·add·custom` 三组均无命中；最近的只有语义不符的 `icon/Picture/Color Correction` 与展示件 `Brand color`）。**但关键发现**：DS `input box/filled` 的变体轴实测为 `dark theme × status × enable × UX × size × feature`，其中 **`feature = yes` 就是「前置图标槽」**（原生放 `icon/Search/Search` + 文本，同在 `Content` SLOT 内）⇒ DS **认可「输入框带前置元素」这个形态**，「内嵌色点」不是自造范式。
**②-a 落地时对本条的两处实测更正（先写结论，免得下轮照着错的做）**：**(a)** 色点**不依赖 `feature` 轴** —— 实测 `feature=no` 的 `Content` SLOT 同样可 `insertChild` 且渲染正常，因为 SLOT 内容是 override、与变体轴无关。故最终**不切 `feature` 轴**，8 处保持原变体。**(b)** 更关键：**`feature=yes` 的 32 个变体里 `enable=off` 有 0 个**，若真去切这个轴，禁用态两帧反而切不过去 —— 即「用 `feature=yes` 落地」这条路本身走不通。
**③ 方案（owner 从四条线索里选定，= D23 ④ 线索 ② + ④ 的合流）**：预设行只做快捷入口；**当前色的唯一权威载体 = hex 输入框左侧内嵌的 16×16 色点**。当前值命中预设时，该预设保留绿描边 + 勾标记、色点显示同色；当前值为自定义色时，**五个预设全不带标记**、只由色点显示该颜色。
**④ 四条判据**：(a) 自定义色不再出现在预设行里 → **结构上不可能被读成「又一个预设」**，直接消解 owner 的否决判据；(b) 操作者仍看得见**颜色本身**而不只是色值代码 —— 这正是 D23 里「只让 hex 输入框承载」那个未采用方案被弃的唯一理由，加色点即补上；(c) **色点同时是取色入口**（点它打开取色面板；面板本体不在本轮范围，dev 可用浏览器原生取色控件），一个元素两职责且不冲突，预设行不再额外加入口、不引入第二个同形可点元素；(d) **顺带闭合 D23 遗留的待定边界** —— 「自定义色接近标记绿时勾失去对比」在新方案里自动消失，因为自定义色**不带勾**。
**⑤ 色点的两条硬规则**：(a) **一律带 1px 描边**并绑 DS `Color Type/Line/Popup Border` —— 单一规则，使 `#000000` 这类深色值在输入框 `#353535` 底上仍可辨，dev 无需逐色值判断（示意区 C 行即演示此边界）；(b) **填充有意不绑 DS 变量** —— 它是操作者填入的原始数据，不是系统语义色（五个预设块相反，填充全部保持绑定 DS 变量，见 §4 M0 表）。
**⑥ 选中标记随所在色块动态取色（owner 落地时追加的第二条规则）**：owner 原话「如果当前色是绿色的话，选中的是边框+图标是白色，这样动态调整对比；如果是其他颜色的快捷选项，选中的边框+勾选图标是绿色」。⇒ **选中绿色预设时，绿描边 + 绿勾在绿底上没有对比 → 描边与勾换绑白色**（`UX/Grey/grey-2`）；**其他颜色一律维持绿**（`UX/Brand/Brand`）。示意区 **D 行**专门演示此态。**UX 卡已写明 dev 不要写死绿色。**
**⑦ 落地（v1 已删，非存档）**：owner 收尾追加「**只保留通过的，未通过的移除**」→ **D23 ④ 的「保留 v1 作存档」处置被推翻，v1 三节点（`8256:816` / `8256:817` / `8257:826`）已删除**，v2 上移到其原位。现落点 = C3 下方：标题 `8267:840` + 示意组 `8266:830`（**A** 命中预设 / **B** 自定义琥珀 / **C** 自定义深色演示描边边界 / **D** 绿预设选中→标记转白，四行）+ 右侧双语说明 `8267:841`。owner 另要求「状态说明尽量简洁明了」→ 说明从 7 条长段压到 **5 条短句**（高 697 → 341）。间距沿用范式（C3 底 → 标题 60 · 标题 → 示意组 16 · 示意组 → 说明 30）；Section `6935 → 6805`、底边距 60、重叠 0 / 溢出 0。
**⑧ 产品帧落地 4/8，禁用态 4 处受组件限制未落（owner 拍板接受）**：可用态 **C1 ×2 + C3 ×2 = 4 处**已落（色点插入 `Content` SLOT + 输入框 `120 → 148`）。**C1a ×2 + C2 ×2 = 4 处禁用态落不了** —— 实测 `input box/filled` 的 `enable=off` 变体**根本没有 `Content` SLOT**（其结构是普通 `Frame 2806`，对 instance 内普通 frame `insertChild` 直接被 Figma 拒绝：`Cannot move node. New parent is an instance or is inside of an instance`）。**owner 拍板：接受限制 + 登记 DS 缺口**，不退回「`enable=on` + 降透明度」（那会违背 D22 ② 已确立的口径）。已回流 DS backlog **`CANONICAL-F95`** + 新规则 **M32.4 第 3 条**（变体轴互斥时保住真禁用变体优先），UX 卡 Interaction 已写明「代码实现中禁用态同样要显示色点（置灰即可）—— 这是组件限制、不是设计决定」。
**⑨ SLOT 可写性实测（技术，防下轮重试）**：`input box/filled` 的 `Content` SLOT **可以 `insertChild`**，但**任何写操作之后 nested 子节点句柄全部失效**（`remove` 报 `Node with id … not found`）⇒ 修法 = **写操作后重新遍历取新句柄**，或分成两次 `use_figma` 调用。这与 D19 ⑦ 记的 `Tab List` SLOT **同型但结论不同**：`Tab List` 是四种写法都失败、判定不可靠；`input box/filled` 是**可用**，只需重遍历。**另一条**：`enable=off` 变体连 SLOT 都没有（见 ⑧），这不是句柄问题、是结构缺失，重遍历也解决不了。 |
| D25 | **默认制式改为 ~~`1080i5994`~~ → `1080i59.94`；并明确「制式参数以开发提供的列表为准、图上为示例」**（2026-08-03 owner 走查十八轮拍板 · **2026-08-05 轮二十五按 D31 修订**）| **⚠️ 2026-08-05 D31 修订（先读这段，下面 ①–⑥ 里凡写 `1080i5994` 的都按此替换）**：① 默认制式的**写法**规范化为 `1080i59.94`（带小数点，与新清单其余档位 `720p59.94` / `1080p29.97` / `1080p59.94` 一致）；② 本条 ① 的「两端映射：Config-T 三个独立下拉 vs LCD 合并预设」**已作废** —— 两端现在都是**一个 `Format` 设置项、同一份 10 档清单**，D31 落地后不再需要「把两端接起来」的对应关系句（改为一句「两端暴露完全同一份清单」）；③ 本条 ③ 记的「LCD 选项列表选中态迁移」实测结果 `720p50 / 720p60 / 1080i5994(选中) / 1080p30 / 1080p50 / 1080p60 / 2160p30` **已被 10 档新清单整体替换**（新终态见 D31 落地明细 (a)），其中**「若只改字不迁移标记就会出现字段行说 A、标记 B」这条判据仍然有效、本轮继续遵守**（新清单的绿+▶ 落在第 5 位的 `1080i59.94` 上，与四处字段行回显一致）；④ 本条 ④ 的说明文案（`Video format settings follow the list provided by dev…`）**原样保留、仍是 owner 指定措辞**；⑤ 与 D10 的关系不变；⑥ 参考面板原值 `Progressive (p) · 30` **仍不动**。 | owner 原话：「默认制式改成 1080i5994，相关的 Mockup 和 UX 交付说明、PRD 都更新一下，并且附上说明：视频制式这些设置参数以开发提供的列表为准，Mockup 上的作为示例，供参考。」
**① 两端映射（同一制式、两种暴露形态）**：Config-T 三个独立下拉 = `1920 x 1080` + **`Interlaced (i)`** + **`59.94`**；LCD 合并预设 = **`1080i5994`**。两者指同一制式，这句对应关系已按 §2a ③ 判据 d 写进两端交付卡。
**② 对象全集 ≠ owner 点名处（第 N+3 次复发）**：owner 只说「默认制式」，实际落点 = **两个 surface × 产品帧 + PRD + UX 卡 + Journey/REFERENCE 对照表 + annot**。Config-T 产品帧 4 帧 × 2 值 = 8 处；LCD 产品帧 5 处（L1.5 摘要 / L2 / L3 字段行 / L3 选项 / L4）+ 选中态迁移。
**③ LCD 选项列表的选中态迁移（不只是改字）**：原列表 `… / 1080i60 / 1080p30(选中) / …`。若只把 `1080i60` 改成 `1080i5994`，默认值就会与选中标记不一致 —— **正是 D23 ② 那个「字段行说 A、列表标记 B」的同型缺陷**。故做法 = 把带 marker 的选中行改为 `1080i5994` 并**前移一位**，原选中项退回普通行 `1080p30`，保持「i 排在同分辨率 p 之前」的排序。实测结果 = `720p50 / 720p60 / **1080i5994**(绿+▶) / 1080p30 / 1080p50 / 1080p60 / 2160p30`。
**④ 说明文案（owner 指定，两端统一措辞）**：EN `Video format settings follow the list provided by dev — the values shown in this mockup are examples for reference only.` / ZH `视频制式等设置参数以开发提供的列表为准 —— 本效果图所示取值仅为示例、供参考。` 落点 = 两端 **PRD**（需求侧措辞，列为一条独立需求）+ **UX 卡 Data Contract 首条** + **贴着 mockup 的 annot**（dev 最先看到的位置）。
**⑤ 与 D10 的关系**：D10 已有「档位清单是常见示例、非穷举」的口径，本条**不是重复**而是**升级** —— D10 管的是「清单不穷举」，本条管的是「**权威来源是 dev 提供的列表**」，且 owner 要求它出现在 mockup 旁而非只在文档深处。
**⑥ 参考面板原值不动**：§1 参考表仍记 `Progressive (p) · 30` —— 那是 MicroApps 参考设计的事实记录，不是本 feature 的默认值（详见 D6 的警示句）。 |
| D26 | **LCD 选项列表「被选中行」文字色统一为绿 `#7ed321`**（2026-08-04 走查轮十九，owner 同意推荐）| 本轮由我方走查发现、owner 一句「同意推荐」拍板，**owner 未点名具体节点**。
**① 判据（规则真源 + 同 feature 内一致性，双支撑）**：[`domain-tvu.md` §M17.1] 明写「当前值行 … 文字 **绿色 `#7ed321`**，左侧选中标记 = 矢量三角（`#f1f1f1`）」；同 feature 的 L3 Format 列表（选中行 `1080i5994`）与 REFERENCE 区的 canonical 参考帧（`720P60`）实测均为绿字，**只有 C2 的 Receiver 列表是白字** —— 同一设备端同一范式出现两种表现。
**② 白字不是 clone 丢色（实测排除，决定了该不该改）**：截图比对 Go Live 源帧 `8062:8004`，**源帧本身就是白字 + ▶**。⇒ 这是**跨 feature 的既有范式分叉**、源头在 8.x Go Live 已交付帧，不是本 feature clone 时掉的色。L3 那一侧才是对齐 canonical 的一侧。
**③ 对象全集（page 内「带选中标记的列表行」共 5 处，逐处定性）**：L3 `9593:947` 已绿 ✓ · REFERENCE 参考帧 `9625:336` 已绿 ✓（且属参考物、本不该动）· C1 那对被轮十六隐藏的标记 `9742:339/340` 仍隐藏 ⇒ 不构成选中行 · ~~**C1 新出现的一对可见标记（见 ⑥）⇒ 因 C1 状态待澄清而暂缓**~~ · **C2 `9742:392` = 本轮唯一落地对象**。
**✅ 2026-08-05 轮二十三复核 —— 本条完全闭合，对象全集零遗留**：C1 的语义已由 D28 定为已选态（不再"待澄清"），其被标记行 `9742:343` 实测 `#7ed321` —— 绿字随 owner 那次本地改动一并带入，**我方无任何动作**。5 处逐一实测：L3 `9593:947` `#7ed321` · REFERENCE `9625:336` `#7ed321` · C0 隐藏字段行 `9866:376` `visible:false` ⇒ 不构成选中行 · C1 `9742:343` `#7ed321` · C2 `9742:392` `#7ed321`。**双向探针**：非选中行 `9742:342`(C1 YLA_0912) / `9742:391`(C2 XMM_X8L) 实测均 `#ffffff` ⇒ 「绿只出现在被标记行」判据方向正确，不是把整列表读成绿。⑦ 的「其余差异不自改」仍是**登记项、非待办**。详见 handoff [`§1k-X ②`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
**④ 落地做法**：绿值**从 L3 选中行 `9593:947` 同源复制**（读其 `fills[0].color` 再赋值），不手敲 hex；只改 `fills`，**不动 `characters` / `fontName`** ⇒ Verdana 保持、**零字体债**（与 D23 ② 那处「改名必须由 owner 本地做」的原因正相反 —— 改色不触发字体写入）。实测 `exactMatch: true`、样式段数 1→1 不变。
**⑤ 交付层同步 3 处（§M-DISCIPLINE.SYNC ② 轮「新事实逐条」）**：改前实测 annot C2 与 UX 卡只写了「字段行绿字回显」、**漏了列表被选中行的表达**（对比 L3 的 annot 写全了「当前值绿字 + 三角标记」）⇒ annot C2 `9747:319` EN+ZH 补句 · UX 卡 Interaction `9597:219` EN+ZH 补句 · UX 卡 Acceptance `9597:220` **新增一条已选态验收项**（原先只有未选态那条）。**PRD 不改** —— 需求侧不写视觉规格。
**⑥ 本轮的副产品：统一颜色让 D23 ② 那处缺陷更醒目**。C2 字段行 `PM_X7L` 与列表标记行 `PM_X7M` 现在同为绿字，「说选了 A、标记的是 B」比之前更直观 —— 这是**暴露缺陷而非掩盖**，owner 那步本地改名因此更有必要。
**⑦ 显式不改项（登记，非静默跳过）**：C2 列表行与 M17.1「当前值行」规格的**其余差异** —— 用 `Rectangle 4` 深色高亮矩形而非「1px `#7ed321` INSIDE 边框」、行高 33 而非 36 —— 属**不同类型**的偏差，超出 owner 本轮同意的范围，且会更大幅偏离 Go Live 已交付形态，故提请不自改。Go Live 源帧 `8062:8004` 的同型白字与 `PM_X7M` 命名问题**一并不动**（已交付节点）。 |
| D27 | **真实视频信号优先于测试信号：测试中插入视频源 → 直接以 Live 发往 Receiver，两端切 Live 表现；拔源 → 测试信号自动恢复**（2026-08-04 owner 走查轮二十派单 + 两条边界拍板）| owner 原话：「如果已经开始测试信号传输了，中途若插入视频信号了，视频信号直接传输到 Receiver 端了，状态变成 Live，按钮、topbar 等都改成 Live 状态时的样式；看看这个逻辑是更新到 UX 交付说明里面还是 PRD 里面，LCD 和 Config-T 记得同步」。
**① 本条推翻已交付的反向决策（本轮最关键的发现，非"加一帧"）**：Section 内**已有** 2b `9469:65` / 2c `9480:108` 两帧就在处理「测试中插入视频信号」，但走的是相反方向 —— 实测原文 `9597:219` Interaction「测试中接入视频源**不会自动切换**…先 Stop Test 再切换」+ annot `9495:4`「**测试继续，不自动切**」+ ZH ref `9475:108`「先 Stop Test 再切换」。**已亲验**（`get_screenshot` 渲染 2b：蓝 ● TEST band 不变 + `Stop Test` 不变 + 彩条不变，只多一个 info toast）。⇒ 本轮性质 = **改设计 + 作废旧决策 + 全量措辞回流**。
**② 归属判定（回答 owner 的提问，规则真源支撑、非偏好）**：**两层都要写、各写各层**，不是二选一。**PRD** 只写需求侧那一句「真实视频优先于测试信号」（落 §4 Requirements 第 14 条 + §5 Acceptance 两条）—— 依据 [`design-process.md` Step B]「PRD 恒 6 段、衍生轮并进既有段并连续重编号，禁加 `§4b` 类后缀段」；**UX 交付卡**只写表现与状态迁移（落 `Interaction` 状态转移 + `Acceptance` 可测项 + `Changes` 本轮 delta）—— 依据 §M23.0 canonical 5 段，且**卡级不新建第二张平级卡**（轮六实证）。另按 6-JIRA ⑤ 与 memory `V4-2356 曾漏 Config-T 侧` 的实证，**两端 Journey 卡同步更新**（stage 4/5 + State coverage）。
**③ owner 拍板的两条边界（交付物零 TBD，`No Open Questions`）**：(a) 2b/2c **就地改造**成 Live 接管态（不划线存档、不另建新帧）—— 与轮十七「只保留通过的，未通过的移除」同口径，且合 M42.3「迭代既有物优先就地改」；(b) 拔源后**自动恢复测试信号**（owner 选，**推翻我方推荐的「回 idle」**）⇒ 该转移是**可逆闭环**（测试态 ⇄ Live 态），措辞必须写双向，且「参数全程保持锁定」因为恢复的仍是同一个测试会话。
**④ LCD 落地（零字体债，关键实测）**：改前 probe 确认 2b/2c 里**所有待改文字节点都是 Roboto**（`TEST` `9469:250` Roboto/Bold/16 · 源字段 `9469:251` Roboto/Regular/14 · 按钮 `9469:230` Roboto/Bold/14 · toast 内文 Roboto/Regular/14）⇒ 可直接改 `characters`，**不触发 Verdana 写入**（与 D23 ② 那处「必须 owner 本地改」正相反）。逐项：band `9469:67`/`9480:110` 蓝渐变 → 红（**fills 原文从已交付 Live 帧 `8062:7678` 复制**，含三段 stops 与 `gradientTransform`，不手敲）· `TEST` → `LIVE` + fill `#d0021b`（同源 `8062:7684`）· dot `9469:262`/`9480:305` → 红 · 源字段 → `HDMI-1080p60`（去掉 `· Test Pattern`）· `Stop Test` → `Stop` + 红渐变（同源 `8062:7587`）· 内容区 `9469:199`/`9480:242` 彩条位图 → **真实画面 imageHash `5879fc7b9fcf9e55fc570c9ef895a395c49252ab`**（即 Live 帧 `8062:7606` 所用同一张，CROP）· 测试专用时间码 + scrim 隐藏 · 2b toast 文案 → `Video input detected — now live.`（**textStyleId 实测保住**，M47）。两帧已 `get_screenshot` 亲验。
**⑤ Config-T 落地（新增 C4 `8317:840`）**：**顶栏无状态载体可用** —— 实测 `Header`（`a1579a23…`）是 standalone COMPONENT、`componentPropertyDefinitions = {}`，**无任何 variant 轴**，一级导航靠换组件而非切变体。⇒ 沿用本文件**唯一**的既有「设备正在 Live」范式（`3192:407`「Is Live」，已 `get_screenshot` 亲验）= **内容区橙色 `#FF9A24` inline 说明行 + 动作态承载**，**不加 Badge**（合 D20 已确立的「状态只由动作按钮承载、面板内不放独立状态标签」）。落地 = clone C2 → hint 改橙色 `Live transmission in progress — the test resumes when the video source is unplugged` · toast 切 `status=info`（外部事件≠操作结果，`success` 不适用；切变体后按 §M-DISCIPLINE.VARIANT 做了 compare-and-fix，文本存活 + textStyleId 保住）· 参数全程保持禁用。
**⑥ C4 动作按钮 = 红 `Stop`（owner 当轮推翻我方判断）**：我方初版让 C4 保持 `Stop Test` 可用，判据是「测试会话在接管期间仍存在，操作者需要退出路径」。**owner 当轮否决**（原话「C4 留成可用是什么状态，不是应该变成 Stop 按钮吗？」）。**我方判据的漏洞（成立）**：它只在 Config-T 单端推理，**没有与 LCD 端对齐** —— LCD 侧同一时刻按钮已是红 `Stop`（停 Live），Config-T 留 `Stop Test` 等于同一状态下两端给出两个不同的动作语义，正是 §M-DISCIPLINE.SYNC ③ 轮判据 d（跨 surface 复用口径须 probe 目标端本体）要防的失守。⇒ 落地 = 文案 `Stop Test → Stop`、填充由蓝 `UX/Blue/Default` 换绑 **`UX/Red/Default`**（`web button` 只有 `clickable` 轴、无红变体，按 D20 先例**绑 DS 变量而非写死 hex**；实测 `boundNow = UX/Red/Default`），与 LCD 红 `Stop` 同源同义。
**⑥-a 连带边界（我方定，判据可论证）**：点该 `Stop` 停掉 Live 之后 → **回 idle，测试不恢复**（视频源仍连接期间）。判据 = 若「停止」反而启动了另一路传输（测试），与按钮语义正面冲突；「自动恢复」的触发条件是**拔掉视频源**，不是手动停止 Live。已写进两端 PRD / UX 卡 / annot。
**⑥-b 跨端一致性升为需求条**：LCD PRD 第 14 条 + Config-T PRD 第 12 条均补入「接管生效期间，两端动作控件停止的都是该 Live 传输、不是测试」—— 这是行为规则（需求侧），非视觉规格。
**⑦ 顺带修掉的既有措辞债（本轮必修，非顺手扩 scope）**：交付层**三处**把**测试态**描述成「**红色** LIVE 色带 + ● LIVE」，而 mockup 实测测试态是**蓝 band + TEST**（Option B 全蓝已采纳）—— `9597:217` Changes · `9597:220` Acceptance · `9598:219` Journey stage 4，另 annot `9495:3` 同病。**不修则本轮引入真红 LIVE 后 dev 会把两个状态读成同一个**。已全部改为 `blue ● TEST`。（注：`9762:338` annot C3 早已写对「Blue ● TEST … distinguish it from a real broadcast (red)」，是唯一没染上此债的一处。）
**⑧ 显式不改项（登记，非静默跳过）**：(a) **Live 参照帧的第 4 行 `Encoder` 遥测不加** —— 其 label 是 Verdana（本环境写不了，同 D23 ② 根因），且遥测行数不属 owner 说的「按钮 / topbar 样式」范围；(b) **LCD 时序线未画 2c→2 回环连线** —— 线 A 列左侧只剩 40px 缝（Section 左缘 1080 / 帧左缘 1120），画长竖线会贴边且 cyan 标签无处安放，反违 §M23.6 避让精神；回环行为已写进 annot `9495:5`（「回到 A1」）+ UX 卡 Interaction + Journey State coverage。**若 owner 要求图上可见，需先拓宽 Section 左边距**；~~(c) **Config-T C4 落点续排到 page 末**（`8317:840` @ y 7116）而非插在 C2 之后 —— 插入需整体下移 LCD 参考区 + C3 + demo 三组已交付内容，annot 已显式写「continues from C2 · 承接 C2」消歧义；若 owner 要求严格时序位序，可另起一轮重排。~~ → **owner 当轮拍板「需要按照严格序位，这样比较清晰」，已同轮重排完成**：C4 annot `8320:1028` → y **4577**（C2 帧底 4517 + 60）· C4 帧 `8317:840` → y **4712**（annot 底 + 20，与 C1a / C2 / C3 实测同一节奏）；下游 8 个节点（LCD 参考 3 + C3 annot/帧 + demo 3）统一下移 **1328**；Section `8309 → 8164`。产品帧列最终阅读序 = **C1 → C1a → C2 → C4 → LCD 参考 → C3 → demo**，机检 `I2_sectionInternalOverlap=0 / I3_overflow=0`。
**⑨ 机检（in-file，本环境无 `FIGMA_PERSONAL_ACCESS_TOKEN`，按 §7 条 2 合法替代）**：两端 `I2_internal=0 / I2_sectionToSection=0 / I3_overflow=0`；段完整性（收窄判据：CJK 正文落在 Roboto **Regular** 段）`=0`。**过程中真抓到并修掉两处结构问题**：LCD 侧 UX 卡增高 445px 撑出 Section（溢出 408px）→ 先下移 sibling Section `9530:140` 再扩 Section 至 4054、两 Section 间距保持 60px；Config-T 侧 UX 卡增高后压住 Journey 卡 → Journey 下移、间距 60px。另 **State coverage `8086:524` 曾被我写坏**（中段插入后按原始边界重设样式 → 段边界错位、CJK 落进 Roboto/Medium 15），已整段重建为干净 5 段 —— **教训：中段插入必须偏移原段边界，或直接整段重建，不可两者混用**。
**⑩ 旧措辞清零核验**：`no auto-switch` / `不自动切` / `Stop Test to switch` / `先 Stop Test 再切换` / `test keeps running` / `测试继续` 全 page 扫查 —— 仅剩 **1 处有意保留**：`9597:217` ③ 批次末句「本条取代此前『测试继续、须手动 Stop Test 才能切换』的决策」，属可追溯性引用而非残留。 |
| D28 | **线 C 拆为四步：未选态获得独立载体 `C0`，C1 转为「当前接收机已回显」**（2026-08-04 走查轮二十一落地 · owner 轮二十收尾拍板推荐 ①②③）| **① 起因是 owner 的本地改动，不是我方提案**：owner 在 C1 帧把字段行值从 `---` 改成有值、并把选中标记移到列表第 1 行，且确认「这个改动是我同意的」⇒ C1 语义由**未选态**变为**已选态**，与 D15 / D23 ① / 帧名 / annot / UX 卡 Acceptance 的未选态措辞**全面互斥**（登记于 handoff §1k-T ④ 第 1 条；当轮按「不在待澄清的基线上叠加」未动 Figma）。
**② owner 拍板的三条**：推荐 ① 取值 = `XMM_X8L`（列表第 1 项）+ 标记移第 1 行 · 推荐 ② 删重复标记 `9790:349/351`、解隐藏原对 `9742:339/340` · 推荐 ③ **补一帧 `C0` 未选态**（判据：D16 是 owner 拍板的状态粒度决策，不宜因一次局部改动而静默失效）。**①② 由 owner 本地完成**（字段行是 Verdana，本环境写不了），③ 及全部连带由我方落地。
**③ C0 的做法 = 纯隐藏 + 改色，零字体债**：clone C1 → 隐藏字段行值 `9866:376` + 隐藏标记对 `9866:374`/`9866:375` → **列表首行绿字改回普通行白字**（同源从同列表普通行 `YLA_0912` 复制 `fills`，不手敲 hex，`exactMatch: true`）。全程不动 `characters` / `fontName` ⇒ 不触发 Verdana 写入。**第 3 处（首行回白）是本轮实测补出的**：D23 ① 只点了「隐藏两处」，但 clone 会把 owner 新上的绿字一并继承 —— 未选态出现绿字 = 「无标记却有当前值」，正是 D23 ① 要消除的那类自相矛盾。已 `get_screenshot` 亲验 C0 四项列表全白、无标记、字段行无值。
**④ 四步的语义分工（决定了 annot 怎么写）**：`C0` 未选（= Preset R 第 ③ 态：preset 离线且无 last-live R ⇒ 无值可回显）→ `C1` 当前 R 回显（Preset R 第 ①② 态）→ `C2` **改选到另一台**（换 R 即覆盖 Preset R、无清空动作）→ `C3` 运行中（与线 A 汇合）。**C2 的定性由「已选」升为「改选」是四步拆分的必然结果** —— 否则 C1 与 C2 都叫「已选」，看不出中间发生了什么动作。
**⑤ 重排的几何实测（省掉一半预期工作量）**：三帧 + 三条 annot 各下移 450 ⇒ `760 / 1210 / 1660 / 2110`，与线 A / 线 B 同节奏；**两条既有竖连线的坐标恰好无需移动**（C0 落在原 C1 位 ⇒ `9761:338` 天然成为 `C0→C1`、`9761:341` 成为 `C1→C2`），只改名 + clone 出第三条 `C2→C3`（`9864:338`）；**分叉线 `9673:306` 几何同样零改动**（它原本就指向 abs 760 那一格），只改名为 `①→C0`。四条连线两端锚定实测 Δ3px 全 pass（§M23.6 A）。
**⑥ 交付层同步（LCD 4 处 / Config-T 0 处）**：UX 卡 `Interaction 9597:219`（`C1→C2→C3` 改 `C0→C1→C2→C3` 并逐帧重写定性）· `Acceptance 9597:220`（未选态那条加载体 `(C0)`；已选态那条从「Once a receiver is picked」放宽为「resolves or is picked (C1 / C2)」）· `Changes 9597:217` 新增 **④ 批次**记本轮 delta · Journey `State coverage 9598:221`（「选择页三步」→「四步」）。annot 四条：`C0` 新建 `9867:346` · `C1 9747:318` 改已选态 · `C2 9747:319` 改改选态 · `C3 9762:338` 步序 3→4。**Config-T 侧实测零改动**（其交付层不引用 LCD 线 C 的帧编号，`C1a/C2/C4` 是 Config-T 自己的命名空间；其未选态本就按 D16 属纯文字描述）—— 显式登记、非静默跳过。
**⑦ owner 本地仍待做两处（Verdana 墙）**：C1 字段行 `9742:341` 文字 `XMM_X2L → XMM_X8L` —— 该节点已改名为 `field row value (current receiver — OWNER TODO: XMM_X2L → XMM_X8L, Verdana)`，打开文件即可见 · C2 的 `PM_X7L` vs 标记行 `PM_X7M`（D23 ② 同一堵墙，轮十七起挂账）。**两处都不影响本轮形态成立** —— 改的是字符，不是结构。
**⚠️ 2026-08-05 轮二十二核验：两处均未做**（`9742:341` 仍 `XMM_X2L`、`9742:392` 仍 `PM_X7M`，机读 + 渲染图双证据）⇒ 本条不闭合、继续挂账。同轮把第 (b) 处的落点写死为「C2 被标记那一行」（见 D23 ② 修订）。顺带登记：C0 的隐藏字段行 `9866:376` 仍是 `XMM_X2L`，owner 改完 C1 后两者将不一致，但它 `visible:false` 且 Verdana 不可写 ⇒ 不影响形态、不列为缺陷。
**⚠️ 2026-08-05 轮二十三二次核验：两处仍未做**（`9742:341` 仍 `XMM_X2L`、`9742:392` 仍 `PM_X7M`，机读 + 渲染图双证据；结构侧全绿、owner 未误碰、线 C 四帧几何 drift 0）⇒ 本条继续挂账。**同轮把缺口定性升级**：UX 卡 `Acceptance 9597:220` 已选态那条写的是「the field row echoes it in green and **the matching row** in the list carries the same green plus the triangle marker」，而 C1（字段行 `XMM_X2L` vs 标记行 `XMM_X8L`）与 C2（`PM_X7L` vs `PM_X7M`）**都不 match** ⇒ 两帧当前**不满足自己那条已交付的验收项**，不再只是「字符层不一致」。⇒ **定稿发 Jira 前必须闭合**（改法与 Verdana 墙处置不变，仍由 owner 本地做）。详见 handoff [`§1k-X ①③`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。
**⑧ 两行同名绿字不是缺陷（实测坐实，防下轮误判）**：C1/C2 的字段行值与列表项同 `x=2416`、行距 36 ⇒ 字段行值在视觉上就是面板第 1 行；owner 改完取值后会出现「两行同名绿字」= 字段值 + 被标记项，语义自洽。
**⑨ 显式不改项**：L3 面板是纯列表（字段行值不入列），与 C1/C2 形态不一致 —— 属 Go Live 源帧带来的形态偏离，触及已交付帧，本轮未扩；如要对齐需 owner 单独拍板。
**⚠️ 2026-08-05 轮二十四：⑦ 收窄、⑧⑨ 作废（均被 D29 取代）** —— ⑦ (a) C1 字段行值 `9742:341` 已随 D29 置 `visible:false`、不再显示 ⇒ **该处改名需求消失**（`visible` 是结构属性、本环境可写，不触 Verdana 墙），**只剩 (b) C2 `9742:392` `PM_X7M → PM_X7L`**（owner 本轮选自己本地改，保 Verdana 零字体债）。⑧「两行同名绿字不是缺陷」**被 owner 判据推翻**（「绿 = 当前保存的值，只可能有一个」）—— 同名也不行，故字段行值一律不再单独占格。⑨ 的「L3 vs C 系列形态不一致」**已由 D29 解决**（owner 拍板对齐，方案 A）。详见 **D29** 与 handoff [`§1k-Y ①②`](../handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md)。|
| D29 | **同一选择页「绿色当前值」有且仅有一处：字段行值不再单独占格，候选列表上移占掉那一格**（2026-08-05 走查轮二十四落地 · owner 判据 + 四方案选型拍板 A）| owner 原话（贴三帧链接）：`C0` 为啥空了一个 · `C1`/`C2` 为啥有 2 个绿色的 —— 「**绿色的理论上代表当前选项保存的值，只可能有一个**」。
**① 根因（三问同源，实测）**：C 系列的**字段行值与候选列表挤在同一列、逐行叠放** —— `Receiver` 那一行的右半格就是列表的"第 0 行"（同 `x=2416`，行距 35–39），连体绿框 `Combined Shape`（434×179）把「字段行 + 4 行列表」整包框住。⇒ 那一格**填了就是第二个绿字**（C1 `XMM_X2L` + `XMM_X8L` / C2 `PM_X7L` + `PM_X7M`），**不填就是空一格**（C0）。
**② canonical 一侧对照**：`L3 9594:214` 是设置页三行 + **独立浮层** `9593:942`（240×211）右对齐盖住值列，字段值白字被完全遮住 ⇒ 全屏只有浮层内一处绿字；REFERENCE 参考帧 `9625:287`（源 `5314:9520`）同构。⇒ **owner 判据与 canonical 一致，C 系列是偏离的一侧**（同 D26 ① 结论），这条同时**解决了 D28 ⑨ 登记的形态不一致**。
**③ 选型（给 4 方案 + ASCII 示意，owner 选 A）**：A 列表上移占掉那一格（选定）· B 仅隐藏字段值（会保留 C0 那个空格）· C 改成 L3 式独立浮层（形态最统一但三帧列表容器 + 绿框要重画、且偏离 Go Live 源帧）· D 反过来让字段值留绿、列表选中行改白（违反 M17.1 + 推翻 D26）。
**④ 落地（三帧一致）**：隐藏字段行值（C1 `9742:341` / C2 `9742:389`；C0 `9866:376` 早已隐藏）+ 列表 4 项与标记对**上移一位**（首项落到「字段值原 y」、其余各落到「前一项原 y」，**不按栅格算 delta** —— 三帧行距实测 35/37/38/37、C2 首行 39，源自 clone 源帧的既有不均匀几何）+ 连体绿框**改 `vectorPaths` 的一个数**（阶梯 path `M 0 0 L 434 0 L 434 H L 300 H L 300 36.017 …` 只改 H：C0/C1 178.665→143.665、C2 183.665→148.665）。**禁用 `resize()`** —— 会按比例拉伸整条路径、阶梯拐点跟着变形。
**⑤ 亲验**：渲染图逐帧目视 + 机读 `listAreaGreenTexts = {C0: [], C1: [9742:343], C2: [9742:392]}` ⇒ C0 零绿且**不再空格**、C1/C2 各唯一一处绿。
**⑥ 交付层同步 6 处**（annot C0/C1/C2 + UX 卡 Interaction/Acceptance/Changes，EN+ZH 双语）：措辞从「字段行绿字回显 + 列表对应行同为绿字」改为「**列表内该行绿字 + 三角标记并占据字段值的位置，整屏有且仅有一处绿色当前值**」；annot C1 标题 `值已回显` → `列表内已标记`。**Acceptance 那条判据由「两处 match」改为「唯一」，一并消除了 §1k-X ③ 记的验收级缺口。**
**⑦ 容器连带（§I7）**：Changes 增 653 字符 ⇒ UX 卡 `9597:214`（VERTICAL auto-layout）自动增高、bot 4384 越过 feature Section 原底 4218 ⇒ Section `9402:59` h 3713→**3939**（底 4444 = 最深子节点 + pad 60）、sibling `9530:140` y 4278→**4504** 保持 gap 60。复核：Section 两两重叠 0 · 子节点越界 0 · 线 C 四帧 drift 0。 |
| D30 | **测试中顶栏只显示信号类型，不带音频参数：`NO INPUT · Test Pattern`**（2026-08-05 走查轮二十四落地 · owner 派单）| owner 原话：「没信号时，不用再加上 ` / 1kHz` 这个字样了，音频参数是根据实际的设置来传输的，只需要显示是什么信号类型即可，无需显示音频相关信息在 topbar 上，**这样也就跟 Live 时的状态保持一致了**」。
**① 对象全集（全 page 扫 `1kHz\|Test Pattern\|NO INPUT` 命中 18 处，逐条定性）**：产品帧带 ` / 1kHz` 的 topbar **3 处**（C3 `9760:506` · 对比 Section 方案 A 副本 `9517:711` · 方案 B 副本 `9530:327`）全部已改；**线 A 主帧 `9359:852` 早已是 `NO INPUT · Test Pattern`** ⇒ 本轮实为把 C3 与两份副本**对齐到主帧既有写法**，不是新范式。
**② 交付层描述 topbar 显示内容的 5 处已改**（EN+ZH 共 10 句）：annot C3 `9762:338` · UX 卡 `Changes 9597:217` / `Data Contract 9597:218` / `Acceptance 9597:220` · Journey `stage 4 9598:219`。
**③ 需求侧 1kHz 一律保留**（音频仍传输，只是不在顶栏呈现）：PRD §1/§3/§4/§5 · Changes「Test stream = … + 1 kHz tone」· Acceptance「stream carries … + a 1 kHz tone」· Journey stage 3 · UX 卡 Why。**判据：删的是「顶栏显示什么」，不是「流里有什么」**；精确匹配串 ` / 1kHz` 天然只命中顶栏写法（需求侧一律写 `+ 1 kHz tone` / `+ 1kHz 音频`），已用探针逐节点复核保留为真。 |
| D31 | **制式清单重定为 10 项、默认 `1080i59.94`；Config-T 也用一个设置项**（2026-08-05 owner 与开发商定 · **已拍板，轮二十四未落地，派轮二十五**）| owner 原话：「经与开发商定，LCD 和 Config-T 两端的制式都修改一下：`720p50 720p59.94 720p60 1080i50 1080i59.94 1080p29.97 1080p30 1080p50 1080p59.94 1080p60`，默认 `1080i59.94`，Config-T 的设置项也跟 LCD 的一样，用一个设置项搞定。」
**① 与现状的差异（已实测固化，省下轮重推）**：LCD 现清单 7 项 `720p50 / 720p60 / 1080i5994 / 1080p30 / 1080p50 / 1080p60 / 2160p30` ⇒ **`2160p30` 要删**、新增 `720p59.94 / 1080i50 / 1080p29.97 / 1080p59.94`、`1080i5994` 写法规范化为 **`1080i59.94`**；默认值由 D25 的 `1080i5994` 改为 `1080i59.94`。
**② 它修订 D4 / D6 / D25**：D4「Config-T 全量照参考面板」中的 `Resolution` + `Scan Type` + `Frame Rate` **三项合并为一个 `Format` 项**（与 LCD 同）；D6 / D25 的默认制式改写法。
**③ 为什么不在轮二十四顺手做（预算与风险判断，非搁置）**：这是跨两端的**结构改造** —— Config-T 五帧（`C1 / C1a / C2 / C3 / C4`）要三行合一、`C3 · Resolution dropdown expanded` 整帧语义变为 Format dropdown，须重走 M0 + M32 锁库；LCD 侧 7→10 项触刚改过的几何（浮层 `9593:942` h211 + 连体绿框 + `clipsContent` 首屏档位，受 D13 与轮五「被裁切掉的内容等于没交付」约束）。**在一轮末尾做高风险几何改造正是此前多次返工的成因。** 完整派单见 handoff §1k-Y ⑥ 第 2 项。
✅ **2026-08-05 轮二十五落地明细**：
**(a) LCD `L3` 浮层零扩容（本轮最省的一处，判据可复核）** —— 新清单里 `1080i59.94` 恰好排**第 5 位**，而面板 `240×211` 的首屏容量正好是 6 行（`5×35 + 36`）⇒ 默认档天然进首屏，**面板高度与连体绿框 `9658:4777` 实测 `baseline (3044,2157,464×211) → now 同值`（delta 0）**，§I7 三项复测均无需调整。物理余量算式：面板底 `2367` < 内容区底 `2384` < 底栏顶 `2389`；物理上限 `2384 − 2156 = 228`，7 行 = 246 > 228 ⇒ **6 行仍是物理上限**，末 4 档（`1080p30 / 1080p50 / 1080p59.94 / 1080p60`）靠 `▼▲` 翻页。落地手法 = 复用既有 7 行（含把 `2160p30` 那行**改字复用**为 `1080p59.94`，不删不建）+ clone 3 行 + `insertChild` 逐位排序，10 行文本段数全部 `1→1`。
**(b) LCD 产品帧回显 4 处** `1080i5994 → 1080i59.94`：L1.5 摘要 `9636:279` · L2 `9593:980` · L3 字段行 `9594:244` · L4 `9594:281`。**`9469:251` / `9480:294` 的 `HDMI-1080p60` 有意不动** —— 那是 2b/2c 里**真实视频源**的制式，不是测试信号档位。
**(c) Config-T 五帧三行合一**：保留 `row · Resolution` 就地改造为 `row · Format`（label `Resolution:` → `Format:`、`select box/filled` 值 → `1080i59.94`），**删除 `row · Scan Type + Frame Rate`** ⇒ 每帧少 56（36 行 + 20 itemSpacing），五帧 `1228×1133 → 1228×1077`、**仍全部等高**。M32.3 复核：`select box/filled` component_set key `ca2ff89d…` @ `TVU UX Design System`（实例侧 `fb36db34…` / `3f8caac6…`(enable=off) / `6883a460…`(UX=click) 是同一 set 内的变体 key，**无库漂移**）。
**(d) `CT3` 展开态**：`Drop down List/Select`（`Type=Radio`）的 `Select Item` SLOT 由 3 项扩到 **10 项**（clone 未选项 7 个 + `insertChild` 排序，选中项落第 5 位），浮层 `240×128 → 240×352`，底 `7300` < 帧底 `7604` ⇒ 不越界。**SLOT 可写性复现 D24 ⑨ 结论**：`insertChild` 可用，但写后 nested 句柄失效 ⇒ **拆两次 `use_figma`**（先扩容+排序，再重遍历写 10 个 label）。
**(e) 帧缩短后的列内 reflow**：14 个下游节点按累计 `−56 / −112 / −168 / −224 / −280` 上移，**列内 60 / 20 间距节奏逐项复测与 baseline 相同**（CT4 annot 那处既有 7px 偏差按纪律**原样保留、不顺手修**）；Section `8075:1000` `8164 → 7884`。 |
| D32 | **「视频源丢失 → 自动回落测试信号」要在主线流程图上有独立一格**（2026-08-05 owner 派单 · **已拍板，轮二十四未落地，派轮二十五**）| owner 贴 `9480:108`（AFTER 2c）原话：「此时，视频信号源突然没了，就自动变成测试信号传输状态，这个流程需要补充，**要不然开发和测试还会有疑问**。」
**① 实测现状：文字层早已全覆盖，缺的是流程图上那一格** —— 帧名 `9480:108` 自带 `test signal auto-resumes when the source is unplugged`；annot `9495:5`、PRD §4-14 与 §5 验收、UX 卡 Changes / Interaction / Acceptance、Journey `stage5` 与 `State coverage` 共 8 处都写明这条可逆边。⇒ **owner 要的不是补一句说明，而是主线时序线上看得见这一步。**
**② 与 D16 不冲突**：D16 的「仅文字、不新增帧」约束的是三个**异常/边界态**（R 离线 / 发起失败 / 无信号源），不含主线时序态（轮十三已就 `C1a · Starting` 澄清过同一边界）。本条是 **D27（真实视频优先）的反向可逆边**，属主线。
**③ 落位与素材已实测**（下轮直接用）：线 A 列 x=1120 的**下一格 (1120, 2560) 空着**，Section `9359:491` bot 2960 ⇒ 放得下、无需扩 Section；连线 clone `9490:10`（x1352, y2427）；annot 落 (1620, 2560) 仿 `9495:5`；回落后画面 = 测试态，clone `AFTER 2 9359:678` 起步（源帧已交付、clone 后不得回改源帧）。
**④ 一处待 owner 选型（下轮先问，别直接画）**：视频源丢失时要不要给 toast —— M12（外部事件不得静默 no-op：检测→告知→前进）指向「要告知」，且与 2b 的 `Video input detected` info toast 对称；但 owner 原话只说「自动变成测试信号传输状态」。⇒ 给两版（带 toast「Video input lost — test signal resumed」/ 不带，仅色带与源字段变化）让 owner 选；文案属 UI 文字 ⇒ 走 role-ux + 词库 bridge。
✅ **2026-08-05 轮二十五：owner 选「给 toast」，本条已落地**。
**(a) 落地物**：新帧 `AFTER 2d 9901:580`（名 `AFTER 2d - Video source lost · test signal auto-resumes (blue ● TEST returns)`）@ 线 A 列 abs (1120, 2560) · 连线 `9901:795`（`_connector · s4 屏2c→屏2d`）@ (1352, 2427) · annot `9902:379`（`annot · s2d state+Δ`）@ (1620, 2560)。三者均已 `appendChild` 进 AFTER 子 Section `9359:491` 并按 §Q15 用 **section-relative** 坐标定位（`clone()` 默认把副本挂到 page 而非原 parent —— 本轮实测踩到一次，已在 handoff §1k-Z 登记）。
**(b) toast 落地手法**：**不新建**，从 2b 的 DS `Message` instance `9472:84`（`status=info` × `size=L`，component key `bd68c0f4…`，remote）**clone 进新帧**并改文案 ⇒ 组件归属与 `textStyleId` 天然保住，段数 `1→1`。帧内位置沿用 2b 的 `(60, 8)`。
**(c) 文案（role-ux + 词库 bridge）**：EN `Video input lost — test signal resumed.`（与 2b `Video input detected — now live.` 对称：同句式、同破折号、同「事件 → 结果」结构）· ZH 释义「视频源已断开 —— 测试信号已自动恢复」。两条 EN 措辞属**词库新词**，已按 shared-vocab-rules 回流 `vocabulary.md`。
**(d) M23.6 锚定实测**：srcEdge（2c 帧底）`2430` → tgtEdge（2d 帧顶）`2560`；dot y `2427`（startGap **−3**）· line `2430 → 2560`（endGap **0**）⇒ 两端均在 ±8 内，与既有 `s2 / s3` 逐值同形。
**(e) 交付层同步（「自动恢复」由纯文字升为有帧承载）**：Journey `State coverage 9598:221` 的 `auto-resume (source unplugged)` 加载体 `— its own frame A4` · UX 卡 `Interaction 9597:219` / `Acceptance 9597:220` 各补帧号 + toast · UX 卡 `Changes 9597:217` 新增 **⑤ 批次** · **annot 2c `9495:5` 的「回到 A1」改为「回到 A4 的测试信号态」**（原写法把可逆边指回起点帧，现在有了专属载体）。
**(f) 渲染图亲验**：`get_screenshot 9901:580` 目视确认蓝 ● TEST 色带 + `NO INPUT · Test Pattern` + SMPTE 彩条 + 毫秒时间码 + 蓝 `Stop Test` + info toast 文案正确。 |
| D33 | **帧编号命名空间消歧：只给 Config-T 一端加前缀 `CT`，LCD `C0–C3` 不动**（2026-08-05 轮二十五 owner 选型落地）| **① 歧义是实质性的、不只是文档口头指代**：实测两端的 `C2` / `C3` 语义完全不同 —— LCD `C2` = 改选接收机、`C3` = 测试运行中；Config-T `C2` = 运行中置灰、`C3` = 下拉展开态。同一份 handoff / Jira 评论里同时出现两端编号时，读者无法判断指哪个。
**② 改一端而非两端的判据**：LCD 的 `C` 有**语义来源**（`线 C` = 「先选接收机」那条流程线，见 D17 ②），改它会同时破坏「线 A / 线 B / 线 C」这套已交付的命名体系；且线 C 四帧刚连续三轮被逐帧核过（§1k-W / §1k-X / §1k-Y），动它风险最大。Config-T 的 `C` 只是「第几张帧」的流水号、无语义包袱。
**③ owner 从三个候选里选定 `CT1 / CT1a / CT2 / CT3 / CT4`**：`CT` 直读 Config-T；未选 `T1…`（`T` 在本 feature 里已被 Transmitter / per-Tx / `T_INFO` 占用，会被读成「Transmitter 1」）；未选 `CT-1…`（既有 annot / UX 卡的编号写法一律无连字符，引入两种书写风格）。
**④ 落地面（对象全集 = 帧名 + annot 名 + 交付层正文引用）**：五个帧名 + 五条 annot 名（`annot · CT1/CT1a/CT2/CT3/CT4 state+Δ`）· Config-T UX 卡 `Changes 8085:520` 4 处正文引用（`Starting (C1a` / `Running (C2)` / `Below C2` 及其 ZH）· annot `CT4 8320:1028` 标题的 `continues from C2 / 承接 C2` · LCD 结果示意说明 `8146:528` 的 `(C2)`。**LCD 侧同步**：UX 卡 `Changes` ⑤ 批次写明改名及其理由，让读两端交付物的人知道对应关系。
**⑤ 残留探针**：全 page 扫 `\(C2\)|（C2）|Starting \(C1a|Below C2|continues from C2` = **0**。
**⑥ 显式不改项**：Config-T 的 `CT3` 在阅读序上仍排在 `CT4` 之后（`CT1 → CT1a → CT2 → CT4 → LCD 参考 → CT3 → demo`）—— 这是 D27 ⑧(c) owner 拍板的「严格时序位序」结果（`C3` 是状态清单里的下拉示例、不属主线时序），本轮只改编号不动位序。 |
| D34 | **DS 真源两条改动落地：`probeI2()` 双重收集 bug 修复 + 硬约束 5 补第 ⑤ 条**（2026-08-05 轮二十五落地 · owner 轮二十四已口头同意）| 连续 3 轮挂账（§1k-W ④⑤ 提请 → 轮二十四 owner「同意」但未写入），本轮写代码 + 测试 + commit 一次做完。
**① bug 与修法**：`probeI2()` 里 `walk(page, null)` **已经**收集了 page 直属的 SECTION（它带 `parent = page` 递归进 `page.children`），后面那段显式遍历 `page.children` 于是把每个顶层 Section 收了**第二遍** ⇒ `i/j` 双循环把它与**自己**配对 ⇒ **每个顶层 Section 报一处假 FAIL，即使文件完全干净**；`dedupe` 按 `[aId,bId].sort().join('|')` 去重杀不掉（自配对 key `X|X` 唯一）。连锁后果 = **I2 恒 FAIL → integrity 恒 FAIL → conformance 总闸恒 blocking**。修法 = 删冗余收集段 + dedupe 加 `o.aId !== o.bId` 防御。
**② `export` + main-guard（为了可测）**：原脚本在模块顶层就做 `--file` / `FIGMA_PERSONAL_ACCESS_TOKEN` 校验并 `process.exit`，import 即退出。已加 `IS_CLI`（`resolve(process.argv[1]) === resolve(fileURLToPath(import.meta.url))`）把两处校验与 `main()` 一起收进 CLI 分支，并 `export { probeI1, probeI2, probeI3, probeI4, bboxOverlap }` —— 先例 `tests/audit-plan-lifecycle.test.ts`。CLI 行为实测未变（无参仍打 usage）。
**③ 双向回归测试** `tests/AuditMockupIntegrityProbeI2.test.ts`（6 tests，实跑 **6 passed**）：干净 page 必 0（防 bug 复活）· 真重叠必报且 `overlapWxH` 精确（防「修成永远返回 0」）· 无自配对 · 嵌套子 Section 覆盖且只比同 parent · 非 SECTION 忽略 · 每对只报一次。**「测试有意义」也自证过**：另写脚本复刻修前的收集逻辑，在同一份干净 3-Section 构造上得到 `[{1:1,1:1},{2:2,2:2},{3:3,3:3}] pass=false` ⇒ 新测试在修前必然失败。
**④ 真文件验证**：LCD page `9343:2` 的 I2 由**连续多轮 4 处假 FAIL** 变为 **pass**（I3 / I4 仍 pass）⇒ 此前 handoff 里那句「I2 报的是脚本 bug 假阳性」从**推断**升为**已修复的事实**，下轮不必再写例外说明。
**⑤ 硬约束 5 新增第 ⑤ 条**（`mockup-conventions.md` §M-DISCIPLINE.SCOPE）：④ 管「扫了哪些对象」，⑤ 管「**判据算得对不对**」—— 判据写错时脚本照样跑完、输出外观与正确输出完全一样，「看输出」结构上发现不了。硬约束 = **(a) 双向探针**（既要已知必命中、也要已知必不命中；只做前者则「永远返回 0」的坏判据通过，只做后者则「永远全报」的通过）· **(b) 已知基线比对**（拿上轮终态数字当探针，对不上先怀疑判据、不要先怀疑文件）· **(c) 替代脚本与真源脚本都算脚本，「它是真源」不构成判据正确的证据**。配两条方向相反的实证：替代脚本 AABB **漏报**（§1k-W ⑤）· 真源 `probeI2` **虚报**（本条）。
**⑥ 顺带更正 `:1090`**：该处原写「缺口是替代脚本覆盖面窄，**不是规则漏写、也不是真源脚本有 bug**」—— 后半句是**没有验证过的附带断言**，现已被本条坐实推翻，已就地加更正段并写明教训：**给一个缺陷定根因时，别顺便宣告另一个组件没问题，只写自己验过的那一半**。
**⑦ commit 纪律**：DS repo 另有 F96 / F97 并行线在活动（本轮起手时 `ahead 2` + 2 dirty，收尾前该 session 已 push、本地回到与远端同步），故按 memory `并行任务用 Git Worktree 隔离` 的兜底口径**精确 `git add` 三个文件**（脚本 + conventions + 新测试），不 `git add -A`。 |
| D35 | **交付层写给开发/测试、不写给下个 session：Changes 按功能模块写终态 + 判据单一归属**（2026-08-05 走查轮二十六 owner 派单 · 三项选型 + 追加去重拍板 · 已落地并回流 DS）| owner 原话：「PRD 的需求里面是否太过详尽了？包括 UX 交付等说明，**现在的文案看起来像是 AI 读的，开发和测试来读的话显得内容太多了**」。
**① 诊断（三处结构性病灶，均有实证，非主观判断）**：**(a) Changes 是按轮次组织的变更日志** —— `① … shipped 07-09` / `③ … this round (2026-08-04)` / `⑤ … this round (2026-08-05)` 分批 + 三句沿革叙述（「本条取代此前『测试继续、须手动 Stop Test』的决策」等），而这些沿革在 handoff（3969 行）+ 本文件 D1–D34 里已 100% 覆盖 ⇒ 卡内属重复；**(b) PRD 混进交互实现细节** —— req 5 讲「返回箭头＝放弃修改」· req 12 整段铺 Preset R 三档取值（单条 578 字符）· req 14 讲按钮语义；**(c) Acceptance 一条塞 3–5 个判据** ⇒ 测试无法逐条打勾；**(d) 外加一处此前未识别的重复** —— `PRD §5` 与 `UX 卡 Acceptance` 是同一套验收写两遍。
**② owner 三项选型**：精简力度 = **B 中度重构**（未选 A 轻度 / C 含双语降级）· 双语 = **保持全量双语**（体量靠结构降、不砍语言）· 范围 = **先 LCD 定形态 → 确认后套 Config-T**。**追加拍板**：PRD §5 与 UX 卡 Acceptance **去重（方案 a）** + **规则回流 DS，「后续的需求也都按照这个规则来」**。
**③ 落地形态**：Changes 改按功能模块（LCD `① Test Signal transmission / ② Parameters & entry point / ③ Format list / ④ Receiver picker / ⑤ Live takeover & auto-resume`；Config-T `① Tab & layout / ② Parameters / ③ Footer & states / ④ Live takeover / ⑤ Component sources (for dev)`），删净全部日期标注与沿革句 + **删 mockup 施工记录**（如「五帧各少一行、1228×1133→1228×1077、列内 60/20 节奏不变」—— dev 对此无动作）。**判据分工**：PRD 验收段 = 功能级（生效与持久化 / 取值顺序 / 失败处理 / 跨端同步）· UX 卡 Acceptance = 界面级（色带 / 字段文案 / 唯一绿值 / 首屏可见 / 跳数 / 组件来源），两段各留**一行**指路句、不复述对方内容。**PRD 条目编号刻意不变**（LCD 14 条 / Config-T 12 条）⇒ handoff 与本文件里 `req 8` `req 12` 这类引用不失效。
**④ 实测减幅（如实记录，低于 B 档预估 40–45%）**：两端 **59,460 → 48,332 字符（−18.7%）** —— LCD −25.6%（PRD −21.9% / UX 卡 −31.9% / Journey −12.8%）· Config-T −12.0%。三条原因：保持全量双语使减幅摊薄一半 · PRD 每条都是真需求（压句可以、删条不行）· Config-T 原文已偏终态导向且含大量必留的开发指引。卡高降幅更直观：LCD UX 卡 4217→3044（−27.8%）· PRD 2990→2564 · Config-T UX 卡 3298→2798。
**⑤ 同轮扫出并修掉一个潜伏多轮的既有缺陷**：`→` `▼` `①–⑤` 在 **Roboto 段渲染为空白**（同符号在 ZH 的 Noto Sans SC 段正常）⇒ Journey 里的 `C0 → C1 → C2` 在效果图上一直缺箭头。**共修 81 处**（LCD 56 + Config-T 25），改绑 Noto Sans SC。**发现路径值得记**：机读 `characters` 里符号永远"在"，**只有渲染图能发现** —— 此前多轮走查都没抓到。
**⑥ 规则已回流 DS**（commit `08a25bf4`，三条均并入既有条文、未续新编号）：§M23.11 新增 **(B) 终态优先** · §M23.0 硬约束新增 **判据单一归属 + 一条 Acceptance 一个判据 + Changes/Acceptance 分工** · §M-TXT-ICON-AUDIT 新增 **注释层排版符号例外 + Roboto 缺 glyph 字符表**。四道文档闸全 PASS。
**⑦ 一个自抓的反效果（已修并写进规则）**：首版指路句**列举了被移走的条目** ⇒ Config-T PRD §5 反从 2122 涨到 2179；改为只写落点的一行后降到 2025。手法用 `deleteCharacters` **只删不插**（改 `characters` 会把整节点样式重置为首段样式）。 |
| D36 | **验收唯一归属 UX 交付卡：PRD §5 只留一行指针；同一事实全局只写一处**（2026-08-05 走查轮二十七 owner 派单 · 已落地）| owner 原话：「不是说了 Acceptance 从 PRD 里面移除，只保留 UX 说明里面的吗？我看了下目前还是有重复的，UX 交付说明也很多，LCD 和 config-T 都一样」。
**① 口径澄清（本条推翻 D35 ③ 的判据分工）**：轮二十六把 owner 的「去重（方案 a）」落地成了**分工**（PRD 留功能级 / UX 卡留界面级），owner 要的是**整段移除**。⇒ **验收唯一归属 = UX 交付卡**；PRD §5 保留段标题 + **一行指针**（`Acceptance criteria live in the UX delivery card.` / 验收标准见 UX 交付卡）—— owner 选定「留段标题 + 一行指针」而非整段删，理由 = PRD 6 段结构不破 + §6 编号不变（handoff 里 §5/§6 引用不失效）+ 读 PRD 的人知道去哪找。
**② 横向去重（owner 选定「全面去重」档）**：轮二十六只处理了 PRD↔UX 的 Acceptance 一层；本轮实测发现真正的病灶是**同一事实在 3 张卡 × 2 端里最多写 6 遍** —— Live 接管 **12 处** · 测试中锁定 **9 处** · Format 十档**全串枚举 6 处**（每处 EN+ZH ≈ 250 字符）· 权威来源 8 处 · per-Tx+提交+重启 7 处 · Preset R 7 处 · 默认值 5 处。归属表：**清单 / 默认值 / 持久化 / Preset R / 后端契约 → Data Contract**（唯一处）· **交互行为 → Interaction** · **界面终态 → Changes** · **怎么验 → Acceptance** · **需求 → PRD §4（只留结论句 + 指路）**。owner 未选「砍跨端解释」档 ⇒ 两端互引段落保留。
**③ 实测数字（如实记录，本轮 −13.3% 低于我给 owner 的 −29% 预估）**：
PRD 两端 16197 → **10869（−32.9%）**（LCD §4 4211→3724 · §5 2147→**79**；Config-T §4 4671→3755 · §5 2025→**80**）
验收总量 8424 → **6046（−28%）**（PRD §5 两处清零，UX 卡 Acceptance 吸收功能级判据后 LCD 2425→3120 · Config-T 1827→2767）
UX 卡 Changes：LCD 3302→2652 · Config-T 4575→3928；Interaction：LCD 2236→**1568** · Config-T 4161→3919；Journey：LCD stages 3095→2733 · Config-T stages 3168→2949
**两端合计 48332 → 41888（−13.3%）**，累计相对最初 59460 = **−29.5%**
**⚠️ 预估偏差的原因（不是执行不到位）**：验收从 PRD 全部搬进 UX 卡 ⇒ UX 卡 Acceptance 两端各涨 695 / 940 共 **+1635**，抵消了横向去重的大部分收益。**owner 能直接感受到的是 PRD 短了三分之一**。若还要更狠，剩下的刀口只有「Config-T Changes 3928 / Interaction 3919 里的开发指引条目」或「双语降级」，两者都需 owner 另行拍板。
**④ 卡高与容器**：LCD PRD 卡 2564→**1785** · UX 卡 3044→**3003** · Journey 1366→1364；Config-T PRD 卡 2274→**1696** · UX 卡 2798→**3020** · Journey 1100→1120。§I7 连带见 handoff §1k-AB ⑤（含一处**实质缺陷**：Config-T UX 卡吸收判据后变高 222，Journey 卡原 relY 3136 与它**重叠 162px** —— 不是留空隙，量了才发现）。
**⑤ 自己引入又自己修掉的 3 处中文错字**：`底标齿轮`→`底栏齿轮`（Changes ②）· `扇描方式`→`扫描方式`（Changes ③）· `底栁齿轮`→`底栏齿轮`（Interaction B）。用 `deleteCharacters` + `insertCharacters('BEFORE')` 就地改，样式继承前一字符。**登记而非隐去**。 |
| D37 | **Config-T 端有了自己的开发单 V4-2376；LCD 端仍 V4-2333**（2026-08-05 轮二十七 owner 新建 + 派单落地）| owner 原话：「之前只创建了 LCD 的 V4 项目的 JIRA，刚刚新增了 config-T 的 V4 的 JIRA：V4-2376，你帮我更新成超链接写到两份文件的 PRD 里面」。
**① 单本身已核实（非照 owner 口述照抄）**：`summary` = `RPS One Able to Stream Test Pattern and 1kHz audio signal without camera connected on config-T` · type `Task` · parent **`V4-1676`**（RPS One Software 8.4 controller, Epic）· priority **High** · status `To Do` · assignee **Bonnie Zhou**（Config-T 负责人 ✓）· reporter Nancy Zeng · 关联 = **clones V4-2333** + **implements FB-9937** · URL `https://tvunetworks.atlassian.net/browse/V4-2376`。
**② 落地面（两端不同范式，实测后各自照办）**：LCD 文件用**PRD §1 内联超链接**范式（Roboto/Medium 12 lh18 cyan + `setRangeHyperlink`），**没有** Jira 组件 instance（宽搜确认，既有状态、本轮不扩范围）⇒ §1 JIRA 行改为 `V4-2333 (LCD) · V4-2376 (Config-T) · FB-9937`，5 个链接全部机读复核真 href。Config-T 文件**有** Jira 组件 instance `8083:999` ⇒ issue key `V4-2333`→`V4-2376` + hyperlink 换新 + instance 改名；PRD §1 改为 `V4-2376 (development task, this surface) · V4-2333 (RPS One LCD surface, this task is cloned from it) · FB-9937`（EN + ZH 双行各 3 链接）。
**③ 单号同步的连带面（§M-DISCIPLINE.SCOPE：改主单号 ⇒ 全部提到单号处）**：Config-T 侧改 **6 处** —— PRD Title `8084:518` · UX 卡 Section Header `8085:518` · 4 个节点名（Section `8075:1000` / PRD 卡 / UX 卡 / Journey 卡）。
**④ 刻意不改的 3 处 V4-2333（已核语义，是正确的跨端引用）**：PRD §1 的 clone 源 · PRD §6「与 LCD 传输测试（V4-2333）同一版本发布」· annot `8146:528`「LCD 界面本身在 LCD 文件 page `< V4-2333 > Transmission Test` 交付」。
**⑤ page 名~~仍带 V4-2333~~ → 已同步（2026-08-06 轮二十八 owner 拍板「同步改」，已落地）**：`8075:2` 改为 `< V4-2376 > Test Signal Parameters · Config-T 20260728`（M45 三段式保持，`20260728` = page 创建日、不随改号变）；反向探针确认该文件已无任何 page 名带 `V4-2333`；项目文档内 6 处旧 page 名字符串同步。**本条挂账闭合。** |
| D38 | **Config-T 控件几何统一：宽度 / 间距 / 对齐照宿主产品既有页面**（2026-08-05 轮二十七 owner 派单 + 选型 · 已落地）| owner 原话：「Config-T 的输入长度、下拉选择框的长度、操作按钮的宽度/间距/对齐方式，都不统一，需要跟其他页面保持一致」，并给出两个参考页：**`2791:1534`**（表单行布局）+ **`3832:3450`**（双动作按钮布局）。
**① 参考页实测规格（本项目资料真源，勿凭印象）**：表单行总宽 689 · 标签列宽 209（控件起始 x）· **控件宽 480** · 行高 36 · 行间距 20（`2791`）/ 8（`3832`，两页不同 ⇒ 行间距不在统一范围）· 分隔线 814×2 上下留白 20 · **按钮 h36 · padding 20/20 · 宽度随文字 hug**（实测 70 / 74 / 76 三个值）· **双按钮间距 20** · **按钮组右缘 = 表单行右缘 689**〔**⚠️ 2026-08-06 轮三十 owner 补正：按钮间距由写死 20 改为 16 且必须绑 DS token** —— owner 原话「Apply 与 Start Test 这类两个按钮之间的间距调整为 token 变量值为 16px Token 变量」。落地 = 九处按钮组容器的 `itemSpacing` 绑定 DS 语义 token **`Spacing/M`**（key `bc1d646c…`，Dark/Light 两 mode 均 alias 到 `Basic Size/#16` ⇒ 解析值 16），**不再写死数值**。该 token 本文件已在 6 处使用，非新引入。**右缘不变量未受影响**（九处第二按钮右缘实测仍全 = 2058，Apply 左缘 1872→1876 = 20→16 的差；几何闸 G1/G2/G3 仍全 0）。现行取值以此为准，本条的「20」保留仅作沿革。〕。
**② 改前偏差（五帧实测，比 owner 说的更严重）**：三个 select 240 · Overlay Text input 300 · hex 框 **148/120 两种值**（同一控件在五帧间不一致！CT1/CT3=148，CT1a/CT2/CT4=120）· `Update` 按钮 relX **五帧五个值**（881/698/662/881/835）⇒ 与主按钮间距 **16/199/235/16/97** · 按钮右缘 1089 而控件右缘 658 ⇒ **差 191px**。
**③ 间距跑飞的直接机制（根因，值得记）**：五帧 `row · actions` 的 `itemSpacing` **全都是 16、宽度全是 882**，区别在 `primaryAxisAlignItems` —— CT1/CT3 是 `MAX`（2 个子元素，间距正确）；CT1a/CT2/CT4 是 **`SPACE_BETWEEN` + 3 个子元素**（hint + Update + 主按钮）⇒ **SPACE_BETWEEN 把空隙在三者之间均分，`itemSpacing` 被静默覆盖**。修法 = 把两个按钮包进一个 hug 的 `row · actions · buttons` 容器（itemSpacing 20），使 SPACE_BETWEEN 只作用于 `[hint, 按钮组]` 两个元素 —— **这正是参考页 `3832` 的 `Frame 32` 结构**。
**④ owner 选型 = 分类统一**（未选「全部照 480 含 hex」/「只做互相统一不拉 480」）：主控件（3 select + Overlay Text）**480** · hex 色值框作为色块行附属控件**统一 148**（参考页无此形态）· 按钮照参考页规格。
**⑤ 一处我自己修正的判断**：选型时我写「右对齐不变」，渲染图核出**控件右缘 898 vs 按钮右缘 1089 差 191px 恰恰就是 owner 说的对齐不统一** ⇒ 按两个参考页共同满足的规律「**按钮右缘 = 控件右缘**」改为对齐 **898**（`row · actions` 加 `paddingRight 191`）。
**⑥ 按钮宽度不该动（实测推翻我的初判）**：`Update` 88（文字 45 + 20/20 padding + 3）· `Start Test` 104（文字 61 + 20/20 + 3）—— **已符合 padding 20/20 + hug 规格**，差 3px 是参考页用 **Helvetica**、CT 用 **Roboto**（DS 字体）的字宽差异。按 memory `figma-font-portability` **不为对齐宽度去动字体** ⇒ 宽度保持不动。
**⑦ CT4 一处连带**：hint 531 + 按钮组 177 + 间距 = 708 > 可用 691 ⇒ SPACE_BETWEEN 无空间可分、按钮组被挤到 915。帧高固定 1077 且五帧须等高 ⇒ **不能让 hint 换行**（会顶高整帧）⇒ 删掉一个词 `video `（`the video source is unplugged` → `the source is unplugged`，语义无损、UX 卡有完整表述）⇒ 531→**494**，正好进预算。手法 = **纯删除，用 `deleteCharacters`**。
**⑧ 终态（五帧一致）**：主控件 right **898** · hex right **714** · 主按钮右缘 **898** · 按钮间距 **20** · 五帧仍等高 **1077** · CT3 展开面板 240→**480**（选项行自动重排）。 |
| D39 | **几何一致性从「靠人看」升级为「有闸可跑」；`domain-tvu.md` §M17.1 的 LCD 规格表判为项目资料**（2026-08-06 走查轮二十八 owner 拍板 · 已落地）| owner 四问四答（原样）：`§M17.1 归属 = 取值搬走，DS 只留做法` · `还没走查，本轮只做 DS 侧` · `page 名同步改成 V4-2376` · `DS 侧四项全做`。
**① 几何维度不再只靠目测**：新闸 `pnpm audit:mockup-geometry-consistency`（DS `scripts/audit-mockup-geometry-consistency.mjs`，18 单测）。三判据 G1 同组件同宽 / G2 状态帧间同名控件同宽 / G3 动作按钮右缘 = 控件右缘。**本 feature 实测 G1=1 · G2=0 · G3=0**（45 控件 + 6 按钮）—— **G2/G3 归零是对 D38 终态的独立复现**（不是读 handoff 相信的）；唯一 G1（`input box/filled` 148 / 480）正是 D38 ④ owner 选定的「分类统一」⇒ 用**具名 allow 条目**（`docs/handoffs/.conformance/geometry-consistency.config.json`）而非抬 baseline，**宽度集一旦出现第三个值例外自动失效**。
**② 判为项目资料的两块**（下轮搬，落点 `docs/specs/lcd-canonical-spec.md`）：DS `domain-tvu.md` §M17.1 的 LCD 设置页规格表（行高 42 / 内容容器 456 / 底栏按钮 82·84 / 帧 `8878:2` `8878:21` / `LCD Button` `4518:3244`+key）与 LCD 选项列表规格表（面板 240 / 帧 `5314:9520` 等 5 个）。判据 = 三问②「取值 + 标识符」+ 反模式「LCD 只在背包设备族内复用 = **同一项目内可复用，不是跨产品通用**」。
**③ page 名同步**：`8075:2` → `< V4-2376 > Test Signal Parameters · Config-T 20260728`（M45 三段式保持，日期段 = 创建日不变），**D37 ⑤ 闭合**。
**④ 一处显式限制（别读成通过）**：F101 v1 只认「控件是 DS 组件 instance」的 surface，**LCD 实测 0 control instances** ⇒ LCD 端跑出的「0 findings」是**没有对象**、不是几何已核。已新立 DS `CANONICAL-F104`；在它落地前，**LCD 几何仍须人工贴实测数字**。
**⑤ 一处我自己的形态错误（被机检纠正）**：先把已闭合的 F101/F102 标成 `### ✅ …` 保留 entry，`audit:status-consistency` C4 报计数不符 —— owner 2026-08-03 已裁定「闭合 = 直接删除 entry，加删除线/✅ 不算」。改为整条删除 + 把真源里指向它们的两处引用改写成「已闭合 + 落地指针」。 |
| D40 | **提交范式重做：两端统一 `Apply`、参数恒可编辑、dirty 驱动、离开前 Discard 兜底**（2026-08-06 轮二十九 owner 四条拍板 · 已落地 · **整体推翻 D1 的 2026-07-29 修订与轮七补记**）| owner 起因原话：「发现 **Update 按钮完全没用**，应该在 Live 时也可以实时更新，按钮我已经改成 **Apply** 了，不可用时是灰色的，可用时是绿色的……不管啥时候，输入框都可更改，Apply 按钮只有输入项发生改动后才是可点击的，如果已经改动但未保存，需要使用 **discard 弹窗**提醒机制」。
**① 四条拍板（AskUserQuestion 逐条选定）**：**(a) Apply 两态由 dirty 驱动** —— 五帧 Apply 一律 `Enable=no`，另建 CT5 演示 dirty 态（未选「保持现状只加弹窗」）；**(b) Discard 触发集 = 3 项** —— 切换 Transmitter · 切走 tab / 离开页面 · 关闭或刷新浏览器；**`Start Test` / `Stop Test` 明确不触发**，按已保存值执行；**(c) 生效方式 = 应用后测试信号短暂重连**（未选「热更新不中断」，也未选「按参数分两类」）；**(d) LCD 同步改造** —— owner 原话「LCD 端也支持 Test 过程中去修改参数，点击『Apply』后自动更新，把『OK』按钮换成 Apply 按钮；相关的 Mockup、UX 交付说明等也都需要修改」。**⛔ 2026-08-06 轮三十：本 (d) 的「把『OK』按钮换成 Apply」已被 D41 ① 推翻** —— owner 改定为措辞按端统一（Config-T=`Apply` / LCD=`OK`），5 处已由 owner 手改为 `Apply` 后再手改回 `OK`。(d) 的另一半「LCD 也支持测试中改参数 + 点提交后自动更新」**仍然有效**。
**② `Apply` 措辞属项目级约定**（owner 追加原话：「Update 按钮改成 Apply 按钮是为了跟其他 config-T 页面保持一致，这个措辞也需要记住在项目里面」）。**实证支撑（非照 owner 口述照抄）**：跨 3 个 page 实测 —— `V4-1827` IP Source Item 内 **12+ 处**同款 ghost 绿 62×32 `Apply`；`V4-2285/2286` 与 `TM3-1930` 另有 `web button` set 的 `Button/Disable` 76×36 实心 `Apply`。⇒ 措辞一致成立，形态在产品内本就有两种。**落点 = 本项目 `docs/`（`PRODUCT_INTRODUCTION.md` 产品设计规则段），不进 DS 真源**（§M-DISCIPLINE.SOURCE 三问：换个产品不成立 ⇒ 项目资料）。
**③ Apply 组件来源（沿用 owner 手改，未按 M32 换成 DS Button）**：旧库 `TVU UX Library` 的 `button/no icon`（set key `4c56b094…`），变体 `Dark theme=on, Style=ghost, color=green, Fix wide=on, Enable=yes|no`，62×32。**理由**：owner 明确以「与其他 Config-T 页面一致」为准，且该形态在 V4-1827 有 12+ 处先例。**D18 不适用**（D18 归正的是「分段选择器误用 button」= tab 语义误用 button，本处是真按钮语义）。**M32.4 满足**：该组件自带 `Enable` 轴 ⇒ 禁用走切变体、不叠加透明度（五帧实测 opacity 全 1）。
**④ Discard 弹窗 = 本项目统一范式（owner 手动定稿，本轮 AI 初版被替换）**：AI 初版用 `form=pop confirm, type=danger`；**owner 换成 `theme=dark, form=dialog, type=default, closable=true`，480×153**，并指示「后续其他的类似需要也都要用这个文案和样式，宽度可以适当调整」。**canonical 文案**：标题 `Confirm discard changes?`（Roboto Medium 16）· 正文 `Your changes have not been saved. Discard changes?`（Roboto Regular 14）· 按钮 `Cancel` + `Discard`（红）。**scrim 按 M41 默认建**（黑 20% + `BACKGROUND_BLUR` 8，全帧）—— 本页此前无 modal，属新设计、非 retrofit，故不走 M41 retrofit 例外。**AI 侧一处踩坑值得记**：`pop confirm` 变体的 `Notification_content` SLOT **是空的且排在 Description 之后**（塞进去的标题会渲染在正文下方并右对齐）；`dialog` 变体的 SLOT 才是标题位、内含 `title` frame + close icon —— **选变体前应先 probe SLOT 的实际位置，不能按名字推断**。
**⑤ 两端形态差异（文案统一、形态按端）**〔**⛔ 2026-08-06 轮三十：本条的 LCD 半边已被 D41 ② 整体推翻** —— LCD **不做** discard 确认，覆盖式列表面板方案作废（且实测该面板 `9965:653` 从未真正建出）。Config-T 侧的 DS Notification 弹窗 + 遮罩**保留不变**。〕：Config-T 用 DS Notification 弹窗 + 遮罩；**LCD 没有 modal 弹窗组件** ⇒ L6 复用 LCD 覆盖式列表范式（绿框面板 + 高亮行三角标记），文案与 Config-T 逐字一致（`Confirm discard changes?` / `Discard` / `Cancel`）。**LCD 无浏览器概念** ⇒ 第三个触发条件（关闭/刷新）在 LCD 侧不存在，交付层显式写「设备侧无对应场景」，不照抄。
**⑥ 一处本环境硬限制（须 owner 手动收口）**〔**✅ 2026-08-06 轮三十已收口**：owner 手改完毕，5 处实测 `characters=OK`、Verdana Regular 15 全保住、变体值未动、`opacity` 全 1。**更正本条一处记录**：`Type=Primary` 的变体默认文案实测是 **`Start`** 而非 `OK`，现有 `OK`/`Apply` 一律靠文本覆盖；另实测切 `Status` 变体时文本覆盖**存活**（节点 id 变、`characters` 保留）。〕：LCD 底栏提交按钮的文案**硬编在 file-local `LCD Button` 组件的 `Type` 变体里**（`Type=Primary`→"OK"，无 `Apply` 变体），且其文本字体为 **Verdana，本环境 `loadFontAsync` 实测失败**（`The font family "Verdana" does not exist`）⇒ **`OK` → `Apply` 无法由 AI 落地**。已改的部分：三处 instance 的 `Status` 变体（L2/L3 `Normal`→`Disabled`、L5 `Normal`）+ 图层名标注。**待 owner 手动改的清单见 handoff §1k-AD**。**建议**：给 `LCD Button` 加一个 `Type=Apply` 变体，两端可长期复用。
**⑦ 顺带修掉的既有缺口（非本轮引入）**：D24 的「hex 输入框内嵌当前色点」原来**只落在 CT1**，CT1a / CT2 / CT4 共 **6 处**缺失（clone 自禁用态帧时 `input box/filled` 的 `enable=off` 变体无 Content 槽所致）⇒ 本轮补齐，五帧 10 处全有。同时删掉 UX 卡 Interaction 里那条已失效的「已知 Figma 侧限制：禁用态没有色点」。
**⑧ 改动量**：Config-T —— 5 帧 Apply 变体 + 36 个控件解禁 + 12 个容器 opacity 复位 + 3 条 hint + 3 个帧名 + 新增 CT5 / CT6 两帧 + 2 条新 annot + 4 条 annot 改写 + PRD §4（4 条改 + 1 条新增）+ UX 卡 4 段 + Journey 3 段 + 全 Section 垂直节奏复位（90/20）；LCD —— L4 三行解禁 + 3 个按钮变体 + 2 条 hint + 1 个帧名 + 新增 L5 / L6 两帧 + 2 条新 annot + 3 条 annot 改写 + UX 卡 4 段 + Journey 3 段 + PRD §4（2 条改 + 1 条新增）+ 2 条连线 + 三级容器扩高。 |
| D41 | **提交措辞按端统一（Config-T `Apply` / LCD `OK`）· LCD 撤 discard · 两端补提交结果双态**（2026-08-06 轮三十 owner 三条拍板 · 已落地 · **推翻 D40 (d) 的按钮改名与 D40 ⑤ 的 LCD 半边**）| **① 措辞按端统一，不跨端强行统一一个词**：Config-T 全线 `Apply`（D40 ② 不变）；**LCD 全线 `OK`**。owner 原话：「LCD 触摸屏上面好像全是 OK 按钮，要不然 LCD 端统一措辞，Config-T 统一措辞？」→ 追问后重申「我刚刚已经全部改回 OK 了，就用这个措辞」。**实证反证已完整呈报（本条的判据不是照 owner 口述照抄）**：按「owner 的一致性主张先实测再采信」纪律扫了 LCD 文件 6 个 page（维度全集 = 15 个短提交类候选词，含 INSTANCE 子树）—— `OK` 在非本 feature 的 5 页共出现 **2 次**且均非表单提交底栏；`Apply` 出现 **7 次且全部集中在 LCD 上唯一的同类表单配置页 `V4-1542`「configure LAN IP on the touch screen」**，其中 4 处正是同一个 file-local `LCD Button` instance；LCD 底栏真正高频的 `Home`(17+6+7) / `Cancel`(19+1+3) / `Back` / `Start` / `Stop` 属导航与运行控制、非提交。⇒ **「LCD 全是 OK」在 Figma 设计真源里不成立**。owner 重申以设备实机为准 ⇒ 按 `OK` 执行，并把「与 `V4-1542` 的 `Apply` ×7 留跨页不一致」**显式登记为已知偏差**（若后续统一，V4-1542 是要一并改的那处）。**实现注意**：`LCD Button` 轴仍是 `Type: Back\|Home\|Primary × Status: Normal\|Disabled\|Live\|Stop`，`Type=Primary` 默认文案 = `Start`，**无 `OK` 也无 `Apply` 变体**，现有 label 全靠文本覆盖；Verdana 本环境不可写 ⇒ **LCD 按钮文案只能 owner 手改**。
**② LCD 不做 discard 确认弹窗**（owner 原话：「LCD 端的 discard 弹窗不做」）。LCD 带未应用改动离开 = 直接丢弃、无二次确认；**Config-T 侧 D40 ④ 的 `form=dialog` 弹窗 canonical 保留不变**。⇒ 两端差异从「同文案、异形态」变为「**Config-T 有 discard 兜底 / LCD 无**」，交付层已显式交代。顺带坐实：D40 ⑤ 记的 LCD 面板 `9965:653` **在文件里从未存在**（`getNodeByIdAsync` 返回 NOT FOUND，L6 的 12 个 TEXT 与 L5 逐字相同、渲染图亦同），故本次无需删除、只需改造。
**③ 两端提交后必须反馈结果（成功 + 失败）**（owner 原话：「只是点击 Apply 按钮后需要给成功和失败的提醒」）。**推翻轮二十九计划的「Apply 失败态不建帧、仅 UX 卡写明」**。成功 = DS `Message status=success, size=L`；失败 = `status=error, size=L`；失败后**设备侧无任何变化、字段保留新取值、提交键保持可点以便重试**。新增四帧：LCD **L6** `9965:610`（成功，就地改造）/ **L7** `9988:647`（失败，clone L5）· Config-T **CT7** `8418:1356`（成功）/ **CT8** `8418:1463`（失败）。**落位按各端既有 toast 范式实测复刻，不自创**：LCD = 水平居中 + 距帧顶 8px（两处先例 `9472:84`/`9901:778` 实测 relX 均等于居中值、relY 均为 8）· Config-T = 帧内 relX 528 / relY 48 且 `layoutPositioning=ABSOLUTE`（源 `8181:761` 实测）。**一处更正**：Config-T 既有那个 `status=success` toast 文案是 `Test signal started`（开测成功），**不是 Apply 成功** ⇒ Config-T 端此前既无成功也无失败提醒，故补两帧而非一帧。
**④ 文案（两端逐字一致）**：成功 `Parameters applied — test signal reconnected.` · 失败 **`Couldn't apply parameters — please try again.`**（句子 + em dash + 句点，与 LCD 既有 toast 范式同构）。
**⑦ 失败提示不许编原因（owner 走查补正，2026-08-06 同日）**：失败 toast 初版写的是 `— test signal unchanged.`，**owner 判为不合理** —— 原话「这个错误示例不合理，没改变都不能点击 OK 按钮，发生应用失败应该是其他的原因」。病灶：那句把「**设备侧状态未改变**」（安慰性信息）与「**没有待应用改动**」（dirty 前提）混成一句 ⇒ 按 dirty 规则「没改动 ⇒ 提交键不可点」，它与图上提交键可点**正面矛盾**，读者会把「没改动」当成失败原因；且**既没给真原因、也没给下一步**。**归正口径**：失败提示**只说「失败 + 下一步」，不写设备无法确认的原因**；「设备侧无任何变化 / 改动仍保留 / 可直接重试」这层信息下沉到 annot 与 Acceptance，不挤在 toast 里。**失败原因枚举与其具体文案属 dev 的错误码范畴**，已列入 Open scope 待 Edward / Bonnie 定（处理方式同 D25「Format 取值以开发清单为准，图上为示例」）；两端 UX 卡 Data Contract 已写明「本效果图所示文案只是该形态的占位，不是 spec」。
**⑤ 落点**：措辞与取值属**项目资料**，记进 `docs/PRODUCT_INTRODUCTION.md` §3.4 / §3.4.1 / §3.5，**不进 DS 真源**（§M-DISCIPLINE.SOURCE 三问）。
**⑥ 顺带修掉两处上一轮扫查真漏**（非本轮引入）：LCD Journey `State coverage` 仍含 `blocked while running`（D40 已推翻「运行中锁定」）· Config-T UX 卡 `Changes` 仍写 discard 弹窗为 `form=pop confirm, type=danger`（owner 轮二十九已手动换成 `form=dialog, type=default`）。两处均已改。 |
| D42 | **交付层双语样式以 DS 角色样式表为唯一真源（中文必降透明度）· 说明文案按「只留事实」精简 · 页脚版权年跟随当年**（2026-08-06 轮三十一 owner 三条走查意见 · 已落地）| **① 双语样式合规（owner 原话：「PRD、UX 状态和 UX 交付说明的双语样式没有完全使用设计系统里面的来，中文应该有个透明度」）**：立**canonical 角色样式表**（派生自 DS §M23.14 (B) + §双语 + 同文件既有正样本，完整表在 `docs/plans/2026-08-06-v4-2376-round31-bilingual-style-and-copy-slim-plan.md` §1a）——大卡 卡标题 `Roboto Bold 18/lh26/#fff` ÷ ZH `NotoSC 16/lh19/op0.45` · meta 行 `Roboto Medium 12/lh18/cyan` · 段名 `Roboto Medium 15/lh24/cyan` ÷ ZH `NotoSC 13/lh16/cyan/op0.45` · 模块小节名 `Roboto Medium 13/lh20/cyan` · 正文 `Roboto Regular 13/lh22/#fff` ÷ ZH `NotoSC 11/lh14/#fff/op0.45`；annot 小卡 标题 `Roboto Medium 13` ÷ ZH `NotoSC 11/cyan/op0.45` · 正文 `Roboto Regular 11/lh18` ÷ ZH `NotoSC 10/lh13/op0.45`；**label chip** ZH = `NotoSC 11/op0.45`（**字号不降**：M23.14 (A) 明确 chip 不适用行距三档、「小 2px」属 (B) 段名条款 ⇒ chip 只落字体 + opacity 两项，**项目级判定**）。**两端全域落地**，77 个注释层节点中 61 处偏差全清，回读复核 ZH 残留 0。**病根**：轮二十九～三十用 M47.2 重写文本时逐段重设**只复刻字号/行距、漏了 ZH 的 opacity 与字体降档**，而机械闸 `bilingual-spacing` **只查行距比、不查 opacity/字体** ⇒ 一路没报（已列 DS 回流候选）。
**② 文案精简 = 中等档（owner 经 AskUserQuestion 选定「条数不减、每条只留事实」）**：删四类 —— **帧编号消歧 · 设计动机辩护 · 跨端对比/澄清 · 卡内交叉引用**（判据 = M23.11 (B)「删掉后 dev/QA 动作不变 ⇒ 该删」）。实测 11 节点 **32 184 → 28 745 字符（-10.7%）**；卡高 Config-T UX **3557→3201**、LCD UX **3386→3138**。**⛔ 明确更正**：本轮计划里我给中等档写的「-40~50%」预算**被实测推翻**——中等档定义在结构上限死上限，`Data Contract`/`Acceptance`/`PRD §4` 三类几乎纯事实、降幅仅 2–8%。**若要卡真正变短只能切激进档（合并验收条），代价是 QA 勾选粒度变粗、与 M23.0「一条 Acceptance 一个判据」有张力，需 owner 另行拍板。** Journey 卡文案与 LCD `Acceptance` 内容未改（非膨胀源 / 纯 checkbox），只做样式合规。
**③ 页脚版权年跟随当年**（owner 原话：「底部的『© 2024 TVU NETWORKS.』中的 2024 改成 2026 年，也就是当天的年份」）：Config-T 九帧 `CopyRight` 文本 override 改为 `© 2026`（残留 0、样式未变、渲染图亲验）；**LCD 端无此元素（零对象，非漏改）**。**登记**：九处均为 instance override，**主组件默认仍是 `© 2025`** ⇒ reset/detach 会回落，属库侧 scope。
**④ 顺带归正 4 处非文案真缺陷**：**(a) 本条最重要 —— Config-T PRD req 9 仍写「测试进行中不可更改接收机」，与 D40「参数恒可编辑」+ UX 卡「改接收机测试中也可 Apply」正面互斥**，已改为「测试进行中同样可以更改接收机并 Apply」，反向探针清零；(b) LCD PRD §4 两条都编号 13（轮三十插入时未重排）→ 排成 13/14/15，第一个 13 不动以保 §1k-AE 引用有效；(c) 两处 EN/ZH 不对齐（LCD req 3/6 中文多一句理由；Config-T `Data Contract` 中文多一句「未应用的编辑同样按 Transmitter 记录」）已各自对齐；(d) Config-T UX `Changes` 的 `Commit result` 整条被轮三十误挂在 `⑤ Component sources` 段末（带孤立空行）→ 移回 `③ Footer & states`，`④` 改名 `Live takeover & pending changes`。
**⑤ 落点**：样式表 / 取值 / 节点 id 属**项目资料**（本 spec + 计划文件 + `PRODUCT_INTRODUCTION.md`），**不进 DS 真源**（§M-DISCIPLINE.SOURCE 三问）；唯一 DS 档候选 = 5 条**机检/纪律层**回流（bilingual 闸补 ZH opacity+字体检查 · 修 `charStyle()` 非 BMP 下标错位 · conformance `--report` 落 node 级 findings · SYNC 收尾加卡高/字符数同比 · M47.2 显式点名 opacity 与 ZH 字体降档），见 handoff §1k-AF ⑧，**待 owner 拍板**。〔**✅ 2026-08-06 轮三十二：5 条已由 owner 全部拍板并落地，见 D43 ③**〕 |
| D44 | **Verdana 墙的边界 = 「文本是否仍为组件默认」，不是「节点在不在 LCD 产品帧」· 交付层补发起失败态（A5）· 验收拆条 14→15 · conformance report 只入库 findingNodeIds**（2026-08-07 轮三十三 owner 三条拍板 · 已落地 · **推翻 §1k-AG ⑦.3 的 owner-only 登记**）| **① ⛔ Verdana 墙边界纠正（owner 质疑触发：「那两处你不可以帮我改吗？加也是你加的啊」）**：§1k-AG ⑦.3 登记的「只有 owner 能改的 2 类 = toast 文案 + 4 处 `LCD Button` label」**是错的**。实测这 5 处（`I9901:778;…` toast · `I9742:350`/`I9742:399`/`I9866:386` button label · `9359:642`）**字体全是 Roboto**，AI 一直就能改 —— 因为它们的文本早被 override 成 Roboto（正是 AI 自己先前写进去的），改它们无需加载 Verdana。**墙本身仍成立**（`listAvailableFontsAsync` 1938 字族无 Verdana、metric 替代全无），**但它只挡「文本仍是组件默认 Verdana」的节点**。**按对象全集重推（22 个产品帧 / 643 文本节点）**：`Verdana` **491 节点**（不可写，且本来就是对的）· `Roboto` **152 节点**（= 真字体债，需 owner 本地换 Verdana；**DS 实证档案记的 88 是轮五旧数**）· `PingFang SC` **9 段**。**教训一般化**：把「组件默认字体」与「该 instance 当前字体」混为一谈，会把可做的事登记成做不了的事 —— 判定「AI 能不能改」必须 probe **该节点当前的 `getStyledTextSegments`**，不能按它所属的 surface 归类推断。
**② 交付层补「发起失败」态**：PRD req 14 要求发起失败时停留空闲态并给失败反馈，但交付帧只有**提交**失败（L7），且 Acceptance 第 14 条把两种失败合并成一句、遮蔽了缺口（F1 §2 覆盖率 14/15）。新增帧 `10052:459` **`AFTER 1b - Start Test failed · stays idle (error toast)`**（A 列 y2290，clone 自 AFTER 1 保持空闲态）+ error toast `10052:645` `Couldn’t start the test signal — please try again.`（沿 D41 ⑦「只说失败 + 下一步、不编原因」；w375、relX 53 = `(480−375)/2`、relY 8，与同族四个 toast 同构）+ annot `10053:492`（**A5**，6 段与模板角色逐段吻合）+ 分支标签 `10054:492`（消歧：分支自 ① Idle，非接在 A4 之后）。**Acceptance 拆条 14→15**（`9597:220`，段 30→32，卡高 960→**1018**）。
**③ UX 卡 `Changes` 补第 ⑥ 段「Commit & result feedback」**（F33-8）：LCD 卡原 ①–⑤ **完全没有提交流程**（dirty→OK→成功/失败全缺），而 Config-T 同类卡 `8085:520` 有 ⇒ 跨 surface 不对等。补段后卡高 604→**790**。**踩坑记录**：用 `indexOf('⑤ …')` 取标题样式时取到的是**圈号那一小段**（`⑤①②③` 按 M-TXT-ICON-AUDIT 属 Roboto 缺字形、必须绑 `Noto Sans SC`），导致新标题整行落成 NotoSC；canonical 是 **圈号 `NotoSC 13/cyan` + 英文标题 `Roboto Medium 13/cyan` 两段**，已修正。
**④ 两端参数对照表残留 `Update 提交` → `Apply 提交`**（F33-1，`9627:272` / `8094:521`）：与 D40②/D41① 拍板的 Config-T=`Apply` 正面冲突，是跨端对称残留、逃过前六轮扫查。**登记**：这两个表位于 REFERENCE Section 内但**属交付内容**，不适用「REFERENCE 区冻结」声明（owner 拍板保持现状不迁移，但须记此一句免得下轮又被当参考物跳过）。
**⑤ ⛔ 撤回一条 AI 自己给出的 finding（F33-3 假阳性）**：overlap 闸报 LCD 10 条 `frame ⨯ _connector`，AI 据 `480.0x3.0` 写成「连线横穿 C0 帧」并已获 owner 拍板「只修主犯」，**但动手前 probe 出前提是错的、未执行**。`9748:323` 的 `connector-line-h` 在 **y 23–25**、所有帧自 **y 40** 起 ⇒ 横线没进任何帧；group 包围盒到 y=43 是因为两端锚点圆点/箭头**故意探进帧内 3px**（M23.6「两端锚定」要求）。**逐叶子核验 10 对：6 对真相交但全是设计正确的 `connector-dot ⨯ frame` 锚点，4 对纯 bbox 假阳性（叶子相交 0）⇒ 0 条真缺陷。** **真问题在闸**：`audit-mockup-overlap` 以 group 包围盒判重叠、无连线锚定豁免 ⇒ 含长跨度连线的流程图**结构上不可能 PASS**（§M-DISCIPLINE.SOURCE 三问 ⇒ **DS 档**，建议对 `_connector · *` GROUP 走叶子级相交，或对端点 ≤8px 探入显式豁免）。**教训**：闸报的数字是**包围盒不是形状**，判几何缺陷前必须下钻叶子级。
**⑥ conformance report 体积策略（owner 拍板「只入库 findingNodeIds」）**：DS commit **`056ca562`**（已推 origin/master）。默认不落 `findingLines`，改写 gitignored 的 `.lines.json` 边车；`--report-lines` 恢复内联。抽出纯函数 `buildLinesSidecar()`/`sidecarPathFor()`，**边车 schema 照并行 INFRA session 已落地的形状实现**（owner 拍板「统一到它的格式」）。**⚠️ 体积如实更正**：AI 原称「大幅瘦身」不成立 —— 实测 **107 732 B → 79 463 B，仅 −26.2%**，大头是 **826 个 composite node id**（而那正是归属核验要用的），owner 拍板「就到这」。
**⑦ 机检口径两条硬记**：**(a)** `--non-blocking` 让总闸在 **9 个子闸全 ERROR 时照样 `exit 0`**（本轮首跑即撞上 —— worktree 无 `.env`）⇒ **exit 0 不等于通过**，必须看 summary 逐条；**(b)** 不带 `--node` 的整文件扫会把 `0054ib` 全域存量债 **41 279 节点 / 54 324 条**全卷进来 ⇒ 必须按 feature Section 限定（LCD `9402:59` / Config-T `8075:1000`）。
**⑧ 归属核验结论（不照抄上一轮的「零新增 findings」）**：新建 annot `10053:492` 命中 `B-TYPO 裸 fontSize=13`，与其模板兄弟 `9902:379` **逐字同构** ⇒ **新增 findings 全部落在既有 §M49.1 owner-deferred 类别、未引入新类别**。
**⑨ D43 ③ 记录口径更正**：「LCD 10 处保留 `Start Test`」实测为 **30 处**，逐条判定语义**全部正确**（均按钮动作）⇒ 属统计口径错误，非漏改。
**⑩ 落点**：节点 id / 取值 / 条数属**项目资料**（本 spec + handoff §1k-AH + F1 报告）；F33-3′ 的闸判据修法属**做法层 ⇒ DS 真源**（§M-DISCIPLINE.SOURCE 三问）。 |
| D43 | **验收条采用激进档（合并至每端 14 条）· LCD 该 feature 的页面/选项名 = `Test Signal`，按钮仍 `Start Test` · 机检盲区六条回流 DS**（2026-08-06 轮三十二 owner 两条拍板 + 一条新事实 · 已落地）| **① 激进档精简（owner 拍板「切激进档（两端都合并）」）**：两端 Acceptance 各合并至 **14 条** —— LCD `9597:220` **25→14**（卡高 1204→**960**，-20.3%）· Config-T `8085:523` **23→14**（卡高 914→**714**，-21.9%）。**合并判据**：同一对象 / 同一状态机的连续判据合并，跨对象的不合（如「Settings 行位置」+「该行行值预览」合，「提交成功」与「提交失败」**不合** —— QA 要分别构造两个场景）。**仅删 1 条**：LCD 原 `☐ EN / ZH copy correct.` 属元检查而非界面级判据，且已被新机检覆盖；**其余 47 条判据全部保留在合并条内，零信息丢失**。**归属不动**：原打算把功能级条按 M23.0 移交 PRD，**放弃** —— D36 已做过验收唯一归属收口，再搬迁等于推翻上一轮决策，改为并入同卡 dirty/热更新条。**代价（项目级例外，owner 已接受）**：合并条内含多个子判据，与 M23.0「一条 Acceptance 一个判据」有张力，QA 需按条内分号逐项验、不能靠勾选框计数当进度。
**⛔ ② 度量口径纠正（本轮最值得记的一条）**：D42 ② 用「字符数 -10.7%」衡量精简效果，**指标选错了**。激进档的机制是**减行不减字** —— 合并使行数 LCD 50→30 / Config-T 46→30，事实一条没删，故字符几乎不动（**Config-T 仅 -0.3%**）而卡高降两成。**owner 感知的「卡太长」对应卡高与条数，不是字符数。** 已回流 DS §M-DISCIPLINE.SYNC 第 6 条（两个量都记，判膨胀看卡高）。
**③ LCD 页面/选项改名 `Test Signal`（owner 原话：「LCD 设置测试信号的页面名称和选项我改成了『Test Signal』，不是『Start Test』」）**：**关键是两种 `Start Test` 必须分开，不是全局替换** —— 指**页面 / Settings 行 / 参数集 / 测试信号本身** → 改 `Test Signal`；指**按钮动作** → 保留 `Start Test`（按钮 label 本体仍是 Start Test，owner 未改，且 Verdana 墙下也只能 owner 改）。**判据不是偏好而是界面本体的事实，且有跨 surface 决定性证据**：Config-T 端早已是该范式（Section 名即 `< V4-2376 > Test Signal Parameters · Config-T`，产品层 18 处 / 注释层 18 处 `Test Signal`，而其 **34 处 `Start Test` 全为按钮语义、零处需改**；`8400:1177` 一句内同时出现「切走 **Test Signal** tab」与「**Start Test** / Stop Test 不触发」）⇒ LCD 只是追上既有口径，**同卡内两词并存本就是既定范式，不需补对应关系交代句**。落地：LCD 交付层 **23 处改 / 10 处保留 / 12 节点**，另 2 个 Section 改名（`9359:491` · `9625:217`），并顺带修好两处 EN/ZH 不对齐（`9345:2` req15 与两处标题的 EN 侧原仍写 `Start Test`，中文早已是「测试信号」）。**仍待 owner 手改 2 类**：toast `Video input lost — Start Test resumed.`（改后须同步 `9597:217` 的两处引用）+ 4 处 `LCD Button` label。
**④ 六条机检盲区回流 DS（owner 拍板「5 条全拍」，实际修了 6 条）** —— commit `1ae713f9`：① `bilingual-spacing` 补 `bilingual-zh-style-tier` probe（ZH 字体 + ZH opacity 0.45 + 纯拉丁行误落 ZH 字体），**且 ZH 行按 Unicode 汉字判定、不按字体判定**（按字体是循环论证：ZH 落在 Roboto 会被重标成 EN 行而永不被报）· ② 修 `charStyle()` 非 BMP 下标错位（探针坐实 REST 按**码点**索引：`9598:221` codeUnits 929 / codePoints 927 / cso 927）· **③ 新抓出且比其余都严重**：`ANNOTATION_RE` 写的是 `annotation`、匹配不到 `annot · …` ⇒ **整个 `annot · state+Δ` 小卡族被判成产品 UI 跳过**（LCD 单页修前扫 70 个注释 TEXT、修后 **87**，28 个含汉字节点 / 1800 汉字长期在 scope 外）⇒ **D42 记的「typography-icon 对本轮 7 个 annot 零命中」是假阴性**；两份副本已同步修、误伤面实测 0 · ④ 数字计入 EN 内容字符（否则 `V4-2376` 残留只报 1 个坏字符而实际 6 个）· ⑤ `--report` 落 node 级 findings（病根 = 子闸 `stdio:'inherit'` 致 stdout 从未被捕获；本轮实测 report 由 **491 字节 → 107 732 字节 / 826 节点**）· ⑥ 条文层：M47.2 点名 opacity 与 ZH 字体降档 + SYNC 加卡高/字符数同比防膨胀。**已知局限**：`library-origin` / `connector` 的输出格式未被 report 解析器覆盖。
**⑤ 顺带修掉新闸抓出的 2 处真缺陷**：Config-T `8084:518` / `8085:518` 的 cyan meta 行**首 7 字符 `V4-2376` 残留 `NotoSC 16 / op 0.45`**（应 `Roboto Medium 12 / cyan / op 1`）—— 轮二九～三十逐段重设把 ZH 行与 meta 行并成一块、段边界少推一段。闭环证据 = 同一个闸修前报 2 条、修后 0 条。
**⑥ 落点**：条数 / 合并映射 / 取值 / 节点 id 属**项目资料**（本 spec + 计划文件 + handoff §1k-AG）；六条机检修复与两条条文属**做法/判据层 ⇒ DS 真源**（§M-DISCIPLINE.SOURCE 三问）。 |
| D45 | **Config-T 新增 CT1b「已接入视频源 ⇒ 不可开测」态：Start Test 与 Receiver 双锁 · 交付层六处同步 · 一处 AI 自造的真重叠被机检抓出**（2026-08-18 轮三十四 owner 两条补充 · 已落地）| **① owner 两条补充（原话）**：「当前**已有视频信号源**时，**Start Test 不可点击**」+「不可测试状态下，**Receiver 也不可更改，以免影响 Live 的 Receiver**」。效果图由 owner 自建于 `8567:3436`（clone 自 CT1a），AI 侧只做归正与交付层同步。
**② 禁用范围实测（逐控件对照，不按层名推断）**：CT1b vs CT1 扫全部 14 个带 enable/clickable 轴的 instance —— 差异**恰好两处**：`8567:3461` Receiver `enable=off`（CT1 为 on）· `8567:3533` Start Test `clickable=no`（CT1 为 yes）；其余 12 个控件（Pattern/Format/三组 radio/switch/三个 input/两组色块）全部保持可编辑，Apply 两帧同为 `Enable=no`（无 dirty，非本状态所致），opacity 全 1。⇒ **owner 两条补充与已画效果图逐项吻合，控件层零改动**。设计自洽性：只锁 Receiver 不锁参数 —— 参数仍可为下一次测试预配，而 Receiver 与 Live 解析到同一目标、改它会改投正在进行的 Live。
**③ 帧名 / 层名归正（clone 残留）**：帧 `CT1a · Starting the test — request sent, parameters stay editable` → **`CT1b · Video input connected — Start Test disabled`**（编号取 `CT1b` 而非 CT9：本态是 **CT1 空闲态的条件变体**，沿用 CT1a 已开的「字母后缀 = CT1 同族」范式）；`8567:3530` `hint · parameters stay editable` → `hint · video input connected`（文本 owner 已改成 `Video input connected — go live directly.`）；`8567:3533` `web button · Starting… (disabled)` → `web button · Start Test (disabled)`。**登记**：层名与内容不符是走查与 dev 的误导源 —— 本轮若只按层名读图，会把这一帧读成 CT1a 的重复。
**④ 交付层六处同步**：(a) 新建 annot **`8572:2`** `annot · CT1b state+Δ`（clone 模板 `8177:676`，7 组双语共 **14 段**与模板逐段角色吻合，置于帧上方、gap **20** 与 CT1a 一致）· (b) UX `Acceptance` `8085:523` **14→15 条**（☐ 28→30、卡高 714→772）· (c) UX `Interaction` `8085:522` **修正过时口径**「本页只有 Apply 会处于禁用态」→ 改写为三处禁用态（Apply / Start Test / Receiver），并在 Receiver 条补锁定理由，旧措辞残留 **0** · (d) UX `Changes` ④ 补 CT1b 条 · (e) Journey `State coverage` ✅ 行补 CT1b + stage 4 `Daily Ops` 补一条 Pain→Fix · (f) PRD §4 **req 12 追加** idle 态禁测规则（并入「真实视频优先」总条，不新增条号，避免验收条数漂移）。
**⑤ ⛔ 一处 AI 引入的真重叠（与 D44 ⑤ 恰成对照）**：交付层增补使 UX 卡 `8085:517` 由 **3002 → 3190**，撞进下方 Journey Map `8086:517` **1000×127**。按增补前实测间隙 **61px** 下移 Journey Map 至 `y=3529`，同列碰撞核验 **0**，重跑 overlap **✅ PASS**。**与 F33-3 的分野**：那次报的是 `_connector` **group 包围盒**、下钻叶子级为 0 ⇒ 假阳性；这次报的是两张 auto-layout 卡的**真几何相交** ⇒ 真缺陷。**口径**：闸报重叠时先下钻再判真假，两种结论都可能 —— 不能因为上一轮撤回过一条就默认这类报都是噪声。**根因是 auto-layout 卡增高不推挤同 Section 兄弟** ⇒ 凡改卡内文本，收尾必须重量卡高与下邻间距。
**⑥ 归属核验（不照抄上一轮结论）**：新建 annot `8572:2` 命中子闸 **`binding-fidelity`**，与模板 `8177:676` **同一子闸、同一类别**；CT1b 帧命中 **39** 个节点、与 CT1a 帧**逐数相同**；全 Section 类别集合仍只有 `binding-fidelity` / `colors` / `typography-icon` ⇒ **无新类别引入**。机检（`--node 8075:1000`）：`integrity ✅ · bilingual-spacing ✅ · overlap ✅`；`colors / typography-icon / library-origin / binding-fidelity ❌` 为 §M49.1 owner-deferred 存量；`connector ❌` 为解析器已知局限；`library-binding ⚠️ERROR` 为无预取 figma-data。节点命中 **903**（轮三十三 826，+77 = CT1b 帧 76 + annot 1）。
**⑦ 数据可行性：本状态的前提已经成立，无需再问 dev**（核 V4-2333 评论链后更正 —— 原本准备把它当 Open scope 问出去）：Dave 2026-08-12 给出的 `/getTestPattern` 返回体已含 **`sourceDetected`** / **`detectedSource`** / **`outputSource`**（接口文档 apifox `7864814`）⇒ CT1b 可直接由 `sourceDetected` 驱动。**Open scope 仅剩失败原因枚举**（D41 ⑦ + D44 ②）—— Edward 的 LCD 实现已用 `lastApplyRestart` 承载提交结果，但失败分类与文案仍未定；**首个已知错误码 = `-211 已有信号`**（设备侧拒绝开测，Bonnie 提供）。**另四条后端事实改写了判据**（读 Slack thread 核到，详见 handoff §1k-AI ⑨）：**(a)** 本状态的需求源头是 **taoyang（QA）** 提出、Bonnie 复核、owner 拍板，不是 UX 主动设计；**(b)** `isRunning` **只代表 TestPattern 进程在跑、不代表在传输**，按钮态应跟**传输态**走（与 LCD 首页一致）⇒ CT2「运行中」的判据是传输态而非 `isRunning`；**(c)** Start Test **是两个动作**（开 TestPattern + 开 Live），任一失败另一个回退 —— 与 A5「不得假 LIVE」逐字吻合；**(d)** 该回退 **Dave 已实现**（CAMERA 翻 1 超时 / `startLive` 非 0 / 任意异常 → `setTestPattern?enable=0`）⇒ **A5 已有后端实现背书，不再是纯设计假设**。**另一处自然消解**：LCD 端「无源时才在 Live 按钮位显示 Start Test」⇒ 有源时该入口本就不存在，**CT1b 是 Config-T 独有问题**（它有独立 tab，有无源都能进），两端行为实为一致、只是承载形态不同 ⇒ 原以为要 owner 拍板的跨端对等问题不成立。
**⑧ 落点**：帧名 / 节点 id / 控件变体取值属**项目资料**（本 spec + handoff §1k-AI）；「auto-layout 卡增高须重量下邻间距」与「闸报重叠先下钻再判真假」属**做法层**，已列 DS 回流候选（与 F33-3′ 同批）。 |
---
## 3. 交付屏清单
### 3.1 LCD 侧 — 文件 `0054ib0nLmt27bC3QlGDl7`，page `9343:2`（`< V4-2333 > Transmission Test 20260709`）
落点：现有 feature Section `9402:59` 内，AFTER 子 Section `9359:491`（现有 4 屏 idle/streaming/2b/2c 纵向时序流程线）**下方续排**，或新建同级子 Section「AFTER — Test Signal Parameters」。
| # | 屏 | 内容 |
|---|---|---|
| L1 | home idle 屏（clone 自既有 `9359:492`）| **2026-07-29 修订：零改动**（原「右栏新增齿轮」已按 D9 撤销）。保留此帧作为对照锚点，说明 home 屏不变、`Test Signal` 仍一键直开测。右栏几何 = 已交付帧原值（视频右缘 368 → 右栏左缘 380.55，间距 12.55px；栏宽 84；按钮 84×32）。**`9359:492` 是已交付节点——只 clone，勿直接改原帧** |
| L1.5 | `Settings` 二级列表（clone 自 `5802:1074`）| **2026-07-29 新增**：列表末尾新增 `Test Signal` 行，右侧摘要值 = 当前预设（`Color Bars · 1080i5994`）+ 下钻三角。入口路径 = 底栏齿轮 → `Settings` → `Test Signal` 行。图示为列表已向下翻动的状态（`Receiver` / `Encoder` 在可见区之上） |
| L2 | `Test Signal` 设置页 | 3 行：`Pattern` → 当前值 `Color Bars` + `›`；`Format` → `1080i5994` + `›`；`Tone` → 分段按钮 `1 s / 2 s / Cont.` |
| L3 | `Format` 选项列表 | 覆盖内容区的选项列表，选中项绿字 + `▶`；**2026-08-05 D31 起清单 = 与开发商定的 10 档** `720p50 / 720p59.94 / 720p60 / 1080i50 / 1080i59.94 / 1080p29.97 / 1080p30 / 1080p50 / 1080p59.94 / 1080p60`（**默认选中 `1080i59.94`，排第 5 位 ⇒ 首屏 6 行内可见**；末 4 档靠 `▼▲` 翻页）。面板仍 `240×211` + `clipsContent`，**本轮零扩容、连体绿框 delta 0**。~~清单 `720p50 / 720p60 / 1080i5994 / 1080p30 / 1080p50 / 1080p60 / 2160p30`~~（`2160p30` 已不在清单内）|
| L4 | 运行中置灰态 | 设置行全灰 + hint「Stop the test to change parameters」 |
| **C0** | 线 C 第 1 步 · `Please select a Receiver` **未选态**（**2026-08-04 轮二十一 D28 新增**，节点 `9866:338`）| clone 现 C1 后**纯隐藏 + 改色**（零字体债）：隐藏字段行值 `9866:376` + 隐藏标记对 `9866:374`/`9866:375` + 列表首行绿字回普通行白字（同源复制 `YLA_0912` 的 `fills`）。**未选态就是「列表在、无选中项」**：字段行不显示任何值、列表无任何三角标记、无任何绿字（`---` 会让「无值」看起来像「有一个叫 --- 的值」，选中标记与绿字则与「未选」自相矛盾）。语义 = Preset R 第 ③ 态（preset 离线且无 last-live R）|
| C1 | 线 C 第 2 步 · **当前接收机已回显**（节点 `9742:303`；**2026-08-04 轮二十一 D28 起由未选态转为已选态**，owner 本地改动 + 确认）| clone 已交付的 `8062:6873`（Go Live 专页 `8062:545`，源帧未动）。字段行以绿字 `#7ed321` 回显 Preset R 解析出的当前接收机，列表第 1 行同为绿字 + 三角标记。✅ **该改名需求自 D29 起已消失**（字段行值 `9742:341` `visible:false`、不再显示）；2026-08-05 收尾已把它那条失效的 `OWNER TODO` 图层名一并清掉|
| C2 | 线 C 第 3 步 · **改选到另一台 R**（节点 `9742:351`）| clone 已交付的 `8062:8004`。`▼▲` 改选后字段行绿字回显新值、被选中的列表行同为绿字 + 三角标记；换 R 即覆盖 Preset R、无清空动作。从 home 点 `Receiver` 行也进入同一页（用于只改目标、不开测）。✅ **2026-08-05 收尾：owner 已改完** —— 被标记那一行实测 `PM_X7L`（Verdana 保住），与 C3 / 线 A / 2d 帧的回显一致，取值链自洽 ⇒ D23 ② / D28 ⑦ 闭合|
| C3 | 线 C 第 4 步 · **点 `Test Signal` 后 = 测试运行中**（2026-08-03 D17 新增，节点 `9760:320`）| clone 线 A 已交付的运行态帧 `9359:678`（源帧未动）。蓝 ● TEST band + SMPTE 彩条 + 毫秒时间码 + `Stop Test`。**与线 A 汇合于同一结果屏** |
| **A4 / AFTER 2d** | 线 A 第 5 步 · **视频源丢失 → 自动回落测试信号**（**2026-08-05 轮二十五 D32 新增**，节点 `9901:580` @ (1120, 2560)）| clone 线 A 已交付的 `9359:678`（源帧未动）+ 从 2b clone 来的 DS `Message`（`status=info`）toast「`Video input lost — test signal resumed.`」。承接 `AFTER 2c` 的 Live 接管态：色带回蓝 ● TEST、源字段回 `NO INPUT · Test Pattern`、彩条与毫秒时间码回来、按钮仍 `Stop Test`、参数全程锁定（同一个测试会话）。连线 `9901:795`（`s4 屏2c→屏2d`）· annot `9902:379`。**owner 选型 = 给 toast**（M12 + 与 2b `Video input detected` 对称）|
**C0 / C1 / C2 / C3 的底栏一律相同**（D15 轮十一修订）：`▼ ▲` + **`OK`** + **`Test Signal`**，每一步都可只保存选择或直接开测。**C0 与 C1 的唯一差别 = 未选态（字段行无值 + 列表无选中标记 + 无绿字）vs 已选态（字段行绿字回显 + 被选项带三角标记）**（**2026-08-04 轮二十一 D28**：该差别原先落在 C1 vs C2 之间，C1 转已选态后整体前移一格；C1 与 C2 的差别现在是「当前 R」vs「改选后的 R」）。
**AFTER 流程图布局（2026-08-03 轮十一起，列序 A · C · B）**：线 A `x=40` 直接开测（4 帧）· **线 C `x=1000` 先选接收机（**2026-08-04 轮二十一 D28 起 4 帧时序：C0→C1→C2→C3**，rel y `40 / 490 / 940 / 1390`，与线 A / 线 B 同节奏）** · 线 B `x=1960` 改参数（5 帧）；三条线共用起点帧 ①（D12）。**①→C0 = 480px 短分叉线**（起点帧右缘 → C0 左缘，Δ3 锚定；C0 落在原 C1 那一格 ⇒ 该线几何零改动、只改名）；**①→B1 = 顶部绕行线**（走 Section 顶部 `y=24` 空档，三段正交、零穿越 C 列，两端 dx 0）。两条分叉线各带 cyan 标签说明分支含义。AFTER 子 Section `2950×2240`（线 C 四步最底 2430 < 底缘 2960 ⇒ **本轮未扩容**）；feature Section 宽 5570、高 **3713**（2026-08-04 轮二十一：UX 卡 `Changes` 增高 140 → 先下移 sibling Section `9530:140` 至 4278、再扩 Section 至底 4218，底边距 60 / Section 间距 60）。
**范式来源（已勘察坐实）**：
- 设置页范式 = `8487:11`（V4-2318 `← Hotspot` 页）：绿字 `← 标题` 导航条 + 浅一档内容区 + 左标签/右分段按钮行 + 底部 `▼ ▲ … Home ⤺` 条。**恰好符合 LCD 双背景色硬规则**（导航+底部一色、内容区另一色）。
- 选项列表范式 = `5314:9520`（V4-1495 Resolution 绿框选项列表）：绿边框浮层、选中项绿字 + `▶` 前导标记。
- LCD 是设备端自绘 UI，**不用 DS 库组件**；字体沿用既有屏（Verdana 主体 / Roboto 注释与新增文案；Verdana `use_figma` 加载不了 → fallback Roboto，见 `figma-font-portability`）。
### 3.2 Config-T 侧 — 文件 `rJJjWWs51n2iFOlCIC7aYG`
> ⚠️ **2026-08-05 轮二十五 D33 帧编号改名**：下表的 `C1 / C1a / C2 / C3 / C4` 现已全部改名为 **`CT1 / CT1a / CT2 / CT3 / CT4`**（节点 id 不变），以消除与 LCD 线 C 的 `C0–C3` 的命名空间歧义（两端 `C2` / `C3` 语义完全不同）。下表沿用旧编号阅读时按 `Cx → CTx` 对应。同时 **`CT3` 的语义由「Resolution dropdown expanded」变为「Format dropdown expanded（10 档）」**，且五帧的 `Resolution` + `Scan Type` + `Frame Rate` **三行已合并为一个 `Format` 行**、帧高由 `1228×1133` 变 `1228×1077`（仍全部等高）。
**新建独立 page**（M45.1：全新需求 → 新 page，放 `-------------- To be confirmed ----------------` 分类顶，page id `1:2` 之后）：
命名 `< V4-2376 > Test Signal Parameters · Config-T 20260728`（2026-08-06 轮二十八随主单改号；`20260728` 是 page 创建日，M45 三段式不因改号而变）
| # | 帧 | 内容 |
|---|---|---|
| C1 | `Test Signal` tab 页 · idle | **Receiver 组（2026-07-31 D14 新增：`row · Receiver` 置于 `Content` index 0，`select box/filled` 下拉 + divider 独立成组）** + 信号组（Pattern / Resolution / Scan Type / Frame Rate / Tone Mode）+ 分隔线 + Timecode 组（switch + Local·Running Time + Text Color）+ 分隔线 + Overlay 组（Overlay Text / Position / Text Size / Text Color）+ 底部 `Update`(disabled) `Start Test`。四帧均 HUG。**2026-08-03 轮十四起四帧全部等高 = `1228×1131`（Content 950×779）**——两条状态行删除后 C1a / C2 由 `1175` 回到 `1131`（D20）|
| **C1a** | **`Starting` 中间态**（2026-08-03 D19 新增，节点 `8177:582`）| 全参数已锁（两组分段 `opacity 0.45`）+ hint 改为「Parameters are locked while the test is starting」+ 底栏 `Update`(disabled) `Starting…`(`clickable=no`，防重复发起)。**此态不出 toast**。
**2026-08-03 D20 修订**：~~蓝 `Badge`「Starting」+ 状态行~~ 已删除 —— 状态只由动作按钮承载 |
| C2 | 运行中置灰态（节点 `8081:447`）| 全参数 disabled + hint + 底部按钮变 `Stop Test`；DS `Message`（`status=success`、`Show close icon=false` 自动消失）「Test signal started」作帧内 ABSOLUTE 浮层（x 居中 528、y 164，与 Tx 行水平错开、精确重叠 0；与 C3 既有 dropdown 浮层同范式）。
**2026-08-03 D20 修订**：~~顶部常驻绿 `Badge`「Running」+ 状态行~~ 已删除；`Stop Test` 填充改绑 DS `UX/Blue/Default`（`#3892f3`）—— 按钮本身即运行态常驻载体，且与 LCD 停止按钮同源。toast **保留**（一次性操作结果，与常驻状态性质不同）|
| C3（可选）| 下拉展开态 | `Drop down List/Select` 展开一例（Resolution 或 Pattern）|
| —— | ~~「Text Color 自定义色值」方案示意 v1~~ | ❌ **已被 owner 否决（D23 ④）且已于 2026-08-03 轮十七删除** —— owner 追加「只保留通过的，未通过的移除」，**推翻了 D23 ④ 原本的「保留作存档」处置**。三节点 `8256:816` / `8256:817` / `8257:826` 已不存在，勿再引用 |
| —— | ✅ **「Text Color 自定义色值」方案示意 v2 —— 色点内嵌 hex 输入框**（2026-08-03 **D24**）| 置于 C3 **下方**（v1 删除后上移到其原位）：标题 `8267:840` + 示意组 `8266:830`（**A** 命中预设 / **B** 自定义琥珀 `#FFCC00` / **C** 自定义深色 `#000000` 演示描边边界 / **D** 绿预设被选中→描边与勾转白，**四行对比**）+ 右侧双语说明 `8267:841`（**5 条短句**，owner 要求精简）。间距沿用范式（C3 底 → 标题 60 · 标题 → 示意组 16 · 示意组 → 说明 30）。**色点插入 DS `input box/filled` 的 `Content` SLOT**（不切 `feature` 轴，见 D24 ②-a），16×16 椭圆：1px 描边绑 `Color Type/Line/Popup Border`、填充有意不绑变量。**非产品界面，属交付说明层**；产品帧同步落地 **4/8**（可用态，见 D24 ⑧）|
| —— | **「点 Start Test 后」的 LCD 结果示意**（2026-08-03 D17 新增）| 置于 C2 **下方**：标题 `8146:526` + 承载帧 `8146:527`（480×320，`upload_assets` 跨文件置入 LCD 运行态图）+ 双语说明 `8146:528`。说明写明「Config-T 是配置端，只显示测试正在进行、看不到信号本身」与「仅作示意，LCD 界面在 LCD 文件交付、不属 Config-T 交付范围」。**非产品界面，属交付说明层** |
**范式来源（已勘察坐实）**：全窗帧 = `7485:1145`（1228×514，含顶栏 `Live/File/Router/General/Advanced` + tab 条 + Tx `1 2 3 4` 选择器）。当前真实 tab 条 = `Encoder · Config for live · MediaMind · Return Video · IP Source · VoIP/IFB`（`7485:1145` 里的 `NDI Source` tab 是 V4-1827 Round 2 作废方案，**新建时该槽位改成 `Test Signal`，勿保留 NDI Source**）。内容区表单范式可参考 `7862:1721`（BEFORE IP Source）与 V4-1827 AFTER 帧。
---
## 4. M0 元素 → 组件映射表（已产出，owner 已过目通过）
> **2026-08-03 轮十二回填**：下表标 ✅ 的行此前只表示「表里定了」，**不等于建成物与表一致、更不等于库归属正确**。轮十二逐 instance 核 `key → libraryName` 后重写了两行（分段、输入框）并新增一行（Tx 选择器）。三层偏差的完整记述见 D18。**判归属只认 `search_design_system` + `includeLibraryKeys` 返回的 `libraryName`；`remote: true` 不构成依据。**
### Config-T（走库 / 既有 instance）
| Element | 组件 (key) | 库 | Status |
|---|---|---|---|
| 顶栏 + tab 条 | clone 既有 Config-T 全窗帧（含真 instance）| Config T ( Local UI ) | ✅ 实测 |
| **Tx `1 2 3 4` 选择器** | **`Tab/Item` (`2267405386cb3186ba920b0d0b790d54e65a1529`)** 选中 `Property 1=Active, Property 2=Green, Type=Filled` / 未选 `Normal, White, Filled` | **TVU UX Design System** | ✅ **2026-08-03 轮十二归正**（原为旧库 `button/no icon`，12 处）|
| Tab `Test Signal` | 复用 tab 条内既有 tab 节点改字 | Config T ( Local UI ) | ✅ |
| ~~Pattern / Resolution / Scan Type / Frame Rate 下拉~~ → **Pattern / Format 下拉（2 个，2026-08-05 D31 三行合一）** | `select box/filled` (**component_set** `ca2ff89d2fc24bad4cb29c8512d8102c04a2c352`) + 展开态 `Drop down List/Select` (`12602e73b9682f9a9c45ec1e9373e8ac80bb489a`) | TVU UX Design System | ✅ 轮十二实测坐实 · ✅ **2026-08-05 轮二十五 D31**：`Resolution` + `Scan Type` + `Frame Rate` 三行合并为**一个 `Format` 行**（五帧各删一行），组件族不变、**仍是同一个 DS component_set**。
**实测记录（防下轮误判库漂移）**：instance 侧 `getMainComponentAsync().key` 返回的是**变体 component key**、不是 set key —— C1 `fb36db34…`(`enable=on`) / C1a·C2·C4 `3f8caac6…`(`enable=off`) / C3 `6883a460…`(`UX=click`)。三者都属 `ca2ff89d…` 这个 set，`search_design_system` + `includeLibraryKeys` 复核 `libraryName = TVU UX Design System` ✓。
**展开态**：`CT3` 的 `Select Item` SLOT 由 3 项扩到 **10 项**（clone `Drop down List/Item` + `insertChild` 排序，选中项第 5 位 `1080i59.94`），浮层 `240×128 → 240×352`。**SLOT 写法**：`insertChild` 可用但写后 nested 句柄失效 ⇒ 必须拆两次 `use_figma`（复现 D24 ⑨，非 D19 ⑦ 那种不可用）|
| **Tone Mode · Timecode 时间源 单选** | **`radio` (`9f07746f19d962fe8b0ac31e6697a5b8f242d8b0`)** 实测轴 `dark theme`(off/on) × `status`(off/on) × `enable`(no/yes)，8 变体 —— **带 `enable` 轴**，禁用态切真变体 | **TVU UX Design System** | ✅ **2026-08-03 轮十五归正**（D22 ①）：轮十二写的「✅ 实测坐实」只核了这个 key 存在（那 3 个实为 C3 dropdown 内的 nested instance），**建成物实为 Config-T 产品库 `WebUI/Form/Radio/Selected` (`74f7335f…`) + `/Unselect` (`de850a00…`) 两个独立组件、无任何变体轴**，共 20 处 —— 与 D18 ② 的「表定 A、建成 B」第三次同型复发。已全部换成 DS `radio`（4 帧 × 5 处），C1a/C2 用 `enable=no` |
| Timecode 开关 | `switch` (`bf16e8f5ba6b8bd85a0b75961d19589a08a5c3a5`) | TVU UX Design System | ✅ 轮十二实测坐实 |
| **Overlay Text 输入 / hex 输入** | **`input box/filled` (`1f513914bde7e5e2844e785eefe427f0693f6d20`)**；C2 运行中态用真 `enable=off` 变体 | **TVU UX Design System** | ✅ **2026-08-03 轮十二归正**（建成物曾是个人库 `WebUI/Form/Input` + `Input&Pleaceholder`，9 处）|
| **Position · Text Size 分段** | **`Tab/Item`（同上，选中/未选同一对变体）** —— 语义是互斥单选 tab，不是触发动作的 Button。**轮十三形态定案**：容器 `itemSpacing 16`、未选态填充覆写 `#353535`（= `--bg-layer4`；原生 `#262626` 在 `#252525` 底上对比仅 1.013）| **TVU UX Design System** | ✅ **2026-08-03 轮十二归正**（表原定 `Button/dark M`、建成 旧库 `button/no icon`，18 处）· ✅ **轮十三按 owner 手调统一 8 组**（4 帧 × 2 组 = 24 tab）|
| ~~运行 / 启动状态标签~~ | ~~`Badge` (`4db5246d0782fe13bcc01747a7a2578c2da77b2a`)~~ | ~~TVU UX Design System~~ | ❌ **2026-08-03 轮十四移除**（D20）：两条状态行整体删除，状态改由动作按钮承载。机检复核 page 内 `Badge` instance **已归零** |
| **操作结果 toast** | **`Message` (`e9574b39e93ac3ffe94834f05d704798ce997274`)** `status=success` × `size=L`，`Show close icon=false`（自动消失）| **TVU UX Design System** | ✅ **2026-08-03 轮十三新增**（D19 ③）· ⚠️ **无 theme 轴** → 深色界面上呈浅色，**按发布原样使用禁改色**（D19 ④；LCD 侧同组件用 `status=info`）· ✅ **轮十五 D21 ④ owner 拍板：这不是缺口、是有意为之**（设计库真源只维持一个主题）→ **不立 DS backlog、不提案增 theme 轴**，D19 ④ 的悬置就此闭合 |
| ~~分段容器 `Tab List`~~ | ~~`Tab List Type=Filled` (`47efe04ff35b46602f0827f24c87af9dca3bae4b`)~~ | ~~TVU UX Design System~~ | ❌ **轮十三实测放弃**：SLOT 在 `use_figma` 下写操作后 nested 句柄全部失效，无法可靠编辑（D19 ⑦）。改用「既有 auto-layout 容器 + 顶层 `Tab/Item`」等价形态 |
| **Text Color 色块行**（Timecode + Overlay 各 1，共 8 处）| **5 个快捷色块（自画 24×24 rect，radius 4）+ 当前值绿描边 + DS `icon/Edit/Selected` (`100fc7c987660ab9922ef029adf74d24a666a812`) 勾标记 + DS `input box/filled` hex 输入框**。5 个填充**全部绑 DS 变量**：`Color Type/Background/Top Bar`(黑 `18e41d5d…`) · `UX/Grey/grey-2`(白 `cad33082…`) · `UX/Blue/Default`(蓝 `d3c9eebb…`) · `UX/Brand/Brand`(绿 `ea8c2383…`) · `UX/Red/Default`(红 `a3f82a4b…`)；绿描边与勾标记同绑 `UX/Brand/Brand` | 色块 = 自画（DS 无 color-swatch 组件）· 图标 / 输入框 / 变量 = **TVU UX Design System** | ✅ **2026-08-03 轮十五按参考重建**（D22 ③）：owner「Color 要跟参考样式的一样，提供几个快捷选项」→ 照 MicroApps 参考面板 `295:1035` 实测形态重建（原先只有单个灰色块 + hex）。⚠️ 参考的色块本体用的是**非 DS 库**的 `Tab` (`5b16bb77…`) 组件，**未引入**（避免从一个错库换到另一个错库）；DS 仍缺 color-swatch 组件，**保留库候选登记**
✅ **2026-08-03 轮十七 D24 已落地 4/8**：当前色改由 hex 输入框内嵌色点承载 —— **色点插入 `input box/filled` 的 `Content` SLOT**（**不切 `feature` 轴**；实测 SLOT 内容是 override、与该轴无关，且 `feature=yes` 无 `enable=off` 变体、切了反而落不了禁用态），16×16 自画椭圆：**描边** 1px 绑 `Color Type/Line/Popup Border` (`2dbb9fe9…`)、**填充有意不绑变量**（操作者数据 ≠ 系统语义色）；输入框 `120 → 148`。预设块本身与其 5 个变量绑定**不变**，变的是「自定义值时五块全不带勾」。
➕ **选中标记动态取色（D24 ⑥）**：选中**绿色**预设时，描边与勾换绑 `UX/Grey/grey-2`（白）；其他颜色维持 `UX/Brand/Brand`（绿）。
⚠️ **落地面 4/8** —— 可用态 C1 ×2 + C3 ×2 已落；**禁用态 C1a ×2 + C2 ×2 落不了**（`enable=off` 变体无 `Content` SLOT，见 D24 ⑧ + DS `CANONICAL-F95`），owner 拍板接受限制、由 code 侧补 |
| Update / Start Test / **Stop Test** / Starting… | `web button` (`5d8aae7961fb542318f6264b65c10f2d7422e218`)；**实测唯一轴 `clickable = yes / no`，仅 2 个变体** —— `yes` 恒为绿 `#33ab4f`、`no` 为灰 `#4f4f4f` | Config T ( Local UI ) | ✅ 产品自有库＝M32 第 2 条正常落点
⚠️ **2026-08-03 轮十四（D20）**：`Stop Test` 需要蓝色，但产品库无此变体、**DS `Button/dark M·L·S` + `light M` 四个组件集的 `color` 轴也只有 gray 1 / green / orange / red、均无 blue**（实测）。故在 instance 上把填充绑到 DS `UX/Blue/Default`（Dark `#3892f3`，与 LCD 停止按钮渐变末端同源）。已回流 `CANONICAL-F94`；UX 卡写明 **dev 须实现停止态按钮变体、禁写死色值** |
| CopyRight 页脚 | `CopyRight` (`0f4e93f3aa68434e6cd4fbf5fbf472895792b508`) | ⚠️ Nancy's Design Assets（个人库）| 🟡 **owner 拍板本轮不改**——全产品 Config-T 已交付帧一致，属产品级存量债 |
| `line` 分隔（顶栏下）| `907b0e79ad0f8d2ac502f16650634946f5bb7d9d` | ⚠️ **非 TVU UX Design System 件**（DS 库三组关键词检索均无命中；且 **DS 库内根本没有独立分隔线组件**，其范式是「画 1px 线 + 绑 `Color Type/Line/*` 样式」）| 🟡 **2026-08-03 轮十五 D21 ② 定性收口**：4 处（C1 / C1a / C2 / C3 各 1，随 clone 的全窗帧 chrome 带入），记产品级存量债、**停止每轮重查**；owner 拍板只认 DS 真源库、不再扫其他库 |
### LCD（设备端自绘，不用 DS 库）
| Element | 范式来源 |
|---|---|
| 480×320 屏体 / 顶带 / 底部 slot 条 | clone `9359:492` |
| 右栏 Test Signal 按钮 + 新增齿轮 | 就地改 clone 出的副本里的 `9359:639` 对应节点 |
| 设置页导航条 + 双背景 + 分段行 + 底部条 | 复刻 `8487:11` |
| Format 选项列表浮层 | 复刻 `5314:9520` |
---
## 5. M48 命中规则清单（开建时逐条打勾）
M0（本文件 §4）· M1（Config-T 顶栏必 instance）· M23 / M23.0 / M23.6 / M23.7 / M23.10–12 / M23.14 / M23.18（交付卡结构·连线·状态标注·双语行距·浅色匹配）· M23.8（Jira 组件 setRangeHyperlink）· M45 / M45.1（Config-T 新建独立 page 命名与落点）· M42 / M42.2 / M42.3（clone gate + 结构审计 + 就地改优先）· M46（迭代既有 instance）· M47（字体 fallback 保 textStyleId）· M-COLOR C1/C2/C3 · M-INTEGRITY I1–I6 · M-LIFECYCLE（每批次后跑 conformance）· M31（Auto Layout 默认）· M32 / M35（库优先 + affordance trace 三行）· M-FONT · M-TXT-ICON-AUDIT · M43（Overlay Text 长文本截断三态）· domain M12（外部事件/参数改动的反馈路径）· LCD 双背景色硬规则 · figma-technical-reference Q15（SECTION 局部坐标）。
---
## 6. 交付层清单（两个 surface 各一套，禁漏）
| 交付物 | LCD 侧 | Config-T 侧 |
|---|---|---|
| PRD | 更新既有 `9343:3`（补「测试信号参数」段：参数集 / 默认值 / LCD 暴露范围 / 运行中不可改）| **新建** PRD 卡（6 段结构，双语）|
| UX Delivery 卡（M23.0 canonical 5 段）| 更新既有 `9393:59` 或新建本轮卡 | 新建 |
| User Journey Map（5-stage）| 新建/更新 `9396:59` | **新建**（memory 实证：V4-2356 曾漏 Config-T 侧）|
| Jira requirement 组件（M23.8）| 既有 | 新建 instance + 真 URL hyperlink |
| design-record | 本文件收尾时升级为 design-record，或新建 `2026-07-XX-v4-2333-test-signal-parameters-design-record.md` | 同 |
---
## 7. 收尾 gate
1. ~~`pnpm audit:mockup-conformance --file ` 在 tvu-design-system repo 下跑；本环境缺 `FIGMA_PERSONAL_ACCESS_TOKEN` → 退化用 `use_figma` in-file 机检~~ → **⚠️ 2026-08-05 两处更正，勿再照旧照抄**：**(a) token 不缺**（轮二十二实测：`.env` 里是 `FIGMA_TOKEN`、脚本读 `FIGMA_PERSONAL_ACCESS_TOKEN`，只是变量名不同）⇒ 收尾**跑真源单项脚本**，映射见 handoff §1k-Z ⑧；聚合总闸 `audit:mockup-conformance` 对本文件体量会 2min 超时，**跑单项而非总闸**。**(b) `probeI2()` 的假阳性已于本轮修掉**（D34）⇒ 此前各轮 handoff 里「I2 报的 N 处是脚本 bug 假阳性」的例外说明**不再需要**，I2 现在真报真过。**禁伪造 PASS** 仍然有效（`never-fabricate-tool-results`）。
2. handoff 写 `TVU Pack/docs/handoffs/`，机检机器输出原文贴进 `Rule checklist:` 块。
**⚠️ 与 DS F62-a 的关系（2026-07-30 轮九 owner 拍板显式标注，勿再当"AI 漏写"）**：DS `§M-DISCIPLINE.SYNC` 第 3 条 + `mockup-conventions.md:1179` 要求 handoff 必含一行 `Conformance report: <脚本 --report 落盘的 JSON>`，并明写「手打 Integrity 文本可编造、已失效」。**本环境结构上无法满足**：脚本产 report 需 `audit:mockup-conformance` 的 REST 子审计跑通，而 `FIGMA_PERSONAL_ACCESS_TOKEN` 实测 UNSET → 9/9 could-not-run、`subAudits` 全非 0 → `reportPassed` 恒 false（`audit-mockup-handoff-evidence.mjs` 实跑 `exitCode=1`，同目录共 6 份 handoff 同 fail，属 file-wide 存量）。
**故本 feature 的合法替代 = `use_figma` in-file 机检 + 机器原文贴进 handoff（禁伪造 PASS）**，理由：① 无 token 时 REST 闸无有效判据；② in-file 机检是真实工具返回、可逐条复核；③ 该 gate 以 consumer githook 形态分发，而 TVU Pack 非 git 仓库 → 当前无机器拦截。
**已按 AGENTS.md「pre-existing finding 必须有 backlog entry」在 DS `docs/internal/backlog.md` [[INFRA-F62]] 下登记子项**（含两条修法候选：给 gate 加无 token 合法降级通道 / 把 token 作为消费环境硬前置）。拿到 token 后应批量补跑 `--report` 并回填引用行，届时删除本例外说明。
3. ~~append `tvu-design-system/docs/internal/_metrics/phase0-ledger.md`。~~ → **已被条 4 推翻（2026-07-30 轮九显式标注，§2a ③ 轮判据 b）**：ledger 位于 DS repo 内，与条 4「纯项目 mockup 轮 → DS repo 零写入」正面互斥。实际执行长期按条 4（ledger 末条 = 07-29，轮五~轮八均未 append，owner 派单亦明写「phase0-ledger 不 append」）。**留划线仅作历史，勿据此写 DS repo**——并行线 session 活跃时写入 DS 尤其危险。
4. **纯项目 mockup 轮 → DS repo 零写入**（无新设计规则则不改 DS、不更新 DS STATUS）。若真产生新规则才回流 `mockup-conventions.md`。
5. Jira 回复按精简格式（`UX Design updated.` + 短锚文本 Figma 链接 + @Trevor `5e59a401a17f930c9b9627c2` + cc Edward/Dave），**发前先贴给 owner 确认**（`slack-jira-write-confirm`）。
---
## 8. 遗留待确认（不阻塞开建，PRD 里标注即可）
- ~~**Format 预设清单的硬件支持范围** — 需 dev（Edward）确认 RPS One 实际支持哪些分辨率/帧率组合；mockup 先按 §3.1 L3 清单画，PRD 标 `pending dev confirmation`。~~ → ✅ **2026-08-05 已闭合（D31）**：owner 与开发商定 10 档 `720p50 / 720p59.94 / 720p60 / 1080i50 / 1080i59.94 / 1080p29.97 / 1080p30 / 1080p50 / 1080p59.94 / 1080p60`，默认 `1080i59.94`，两端同一份。**清单本身已不是待确认项**；D25 ④ 那句「以开发提供的列表为准、图上为示例」按 owner 指定**继续保留在交付层**（它现在的作用是「后续若清单再变以 dev 为准」，不再是「本轮清单未定」）。
- **Config-T 参数是 per-Transmitter 还是全局** — 参考面板无此维度；Config-T 帧带 Tx `1 2 3 4` 选择器，倾向 **per-Transmitter**（与 IP Source / NDI 一致），开建按 per-Tx 画并在 PRD 标注请 dev 确认。