docs(specs): 更正 #46 的收口处置（T23 已补做）

依据 = `rulings.md` **§C56.2**（裁决：这是批 7 的**交付缺口**，不是「批 8 输入」）+ **§C56.1**（规格 `:738` 处置栏逐字「补 UI（本批）」；计划 `:532`/`:2299`/`:2309` 三处指派一致）+ **§C57.1/§C57.5**（T23 交付 + 返工已逐项复核）。
形态 = **原文 + 就地加注**（上一轮的实测发现**逐字保留**、处置以加注**作废**）⇒ 本提交 **+8 行 / −0 行**。

【逐字对照：改了哪几行 / 原文是什么】
- **位点 1 = 规格 §9 表末 #46 行的状态更正注（`:745`）**
  · **原文（保留，一字未动）**：「…**批 7 只做"接线"那一半**（命令本身的生产调用点）。🔴 **但 T21 实测推翻了后半句的兑现**：…⇒ **「接线」那一半在本批未做**。**处置**：与 §C9.1 的裁决不冲突…⇒ **逐字登记为批 8 输入**，**不得**读成「本批 12 条补 UI 已全部接线」。」
  · **加注（新增）**：「🔻 **收口更正（2026-09-13 · T21 追加轮；上一注的实测发现保留、处置作废）**」= 该「→ 批 8」处置**作废**（引 §C56.2 逐字）+ 规格处置栏与计划三处指派的逐字依据 + T23 三条 sha 与交付物 + **T21 独立复测 PROD 0 → 1**（落点 `FragmentGroupAction.tsx:92` 逐字载荷）+ 落点形态（`:71`/`:72` 的 feed 双道收口 · `{ fragmentId, groupId }` 的 camelCase 依据 `commands_fragments.rs:141-145` · `groupId: null` = 移出组）+ 判据 V7/V8/V9 + 🔴 **缺口成因**（计划口径正确且预警过；T20 的「6+4=10」吞掉第 11 个名字）。
- **位点 2 = 规格 §11-7 的批 7 收口注第 4 条（`:908`）**
  · **原文（保留，一字未动）**：「🔴 **残留 1 条挂着「补 UI（本批）」却仍零引用**：`update_fragment_group`(#46) 全 `app/src/**`（**含测试**）命中 **0 文件 / 0 处**…⇒ **登记为批 8 输入**，并见 §9 该行的状态更正注。」
  · **加注（新增）**：「🔻 **收口更正（2026-09-13 · T21 追加轮；上面三条原读数一律保留为「T21 首轮」的历史读数）**」= 🔴 **残留 1 条 → 0 条** · 🔴 **前端零引用 11 → 10**（口径不变）· **有引用数 11 → 12**（本批实做补 UI = **11 条** = T20 的 6 + T23 的 1 + T18/T19 的 4）· 处置改为「已交付」。

【T21 追加轮实测（自跑，非转述）】
- `update_fragment_group` 前端命中：**PROD `app/src/components/FragmentGroupAction.tsx`(4)** · TEST `FeedFragmentList.test.tsx`(9) · `batch7UiWiring.test.tsx`(2)；正控 `invoke(` **68** 个生产文件 · 负控 **0**。
- T23 三条提交的 `--numstat` 与 parent 链：`125eec85`（4 路径，parent `d0ada786`）→ `5f662811`（1 路径，parent `125eec85`）→ `5d59e332`（3 路径，parent `5f662811`）；逐条 `git show --name-only -1` = 只列自己的路径。
- 行数（`countLines()`）：`FeedFragmentList.tsx` **299** · `FragmentGroupAction.tsx` **155** · `FeedFragmentList.test.tsx` **299** · `batch7UiWiring.test.tsx` **218**。

【门禁读数（串行，工作树；与上一轮逐条对账）】
- `node scripts/docs-check.mjs` ⇒ **exit 0** ·「扫描 **281** 个 Markdown 文件（检查 **181** 个）」⇒ **与上游基线 281/181 逐字一致**（本提交未新增/删除 `.md`，且**未改**非本文档）
- `node scripts/line-limits.mjs --full` ⇒ **exit 0** ·「>600 硬限 **0** · 301–600 档 **121** · 登记条目 **121**」⇒ **与上游逐字一致**
- `node scripts/check-command-registry.mjs` ⇒ **exit 0** ·「定义 **311** / 注册 **311** / 重复 **0**」⇒ **与上游逐字一致**（T23 未新增命令）
- `git diff --numstat -- <规格>` ⇒ **8 / 0**；`git diff` 的 `^-` 行数 = **0**（V2 继续成立）
- 🔴 **结构自证**：本文件的 `#`–`####` 标题逐条对拍 = **HEAD 51 / 工作树 51 / 差异 0 处**（§C55.2 / §C56.4 的纪律 —— 「不改历史原文」不能只看 numstat 删除列）
- 规格行数：**1022 → 1030**

【诚实边界】
- 🔴 **「删掉『登记为批 8 输入』的处置」按「就地作废」而非字面删行实现** —— 因为本轮**同时**被要求「规格 diff 仍必须只有 `+` 行、`−` 列为 0」（V2 继续有效）。字面删行会与该硬判据直接冲突 ⇒ 处置用加注**显式作废**（原文可读、结论唯一）。**如需字面删除，请明示——那会同时作废 V2。**
- §C57.2 的**控制方派单缺陷**（`container` vs `feed` 地形）与三条新事实的落账**不在本提交**：本提交只改规格，`v0.22` 与 `docs/standards/**` 在后续两条提交里。

Author: Aparencia

docs/superpowers/specs/2026-09-11-frontend-redesign-design.md

@@ -743,6 +743,13 @@
 > **🔻 角色变更登记（2026-09-13，批 7 T19）· 指上表 #30 `video_profile_spec_by_kind` 行**：本行当年删除 `video_profile_spec_by_kind` 的理由是「前端已有 KIND_TO_FORM / KIND_TO_TIER **双写**」。批 7 把读端接到后端 `video_profile_for_spec`（#28）之后，那张前端映射的**角色从「并行真源」变成「离线降级路径」（兜底）** —— **它仍然存在、也仍有生产调用点**（AGENTS.md §3.4 要求本地兜底路径必须留），**不是被删除**。⇒ 本行的删除理由**在"真源"这一层不再成立，在"兜底"这一层仍成立**；原文保留，本注为准。🔴 **实测**：`video_profile_for_spec` 前端生产调用点 **4 处 / 1 文件**（`components/ProfileDetector.tsx`）；`KIND_TO_FORM` / `KIND_TO_TIER` **仍在且仍有生产调用点**（R-11 剥注释实测 **6 处 / 2 处**；T21 未剥注释粗测 7 / 3，差额为注释行）⇒ **两张映射一个字未删**。
 >
 > **🔻 状态更正（2026-09-13）· 指上表 #46 `update_fragment_group` 行**：本行的「需同步修正记录」**已在批 1 完成**（`docs/product/requirements-pool.md:337` 含 2026-09-12 批 1 更正）。**批 7 只做"接线"那一半**（命令本身的生产调用点）。🔴 **但 T21 实测推翻了后半句的兑现**：`update_fragment_group` 在 `app/src/**`（**含测试**）命中 **0 文件 / 0 处**，而它**仍在 registry**（`定义 311 / 注册 311 / 重复 0` 含该条）⇒ **「接线」那一半在本批未做**。**处置**：与 §C9.1 的裁决不冲突（该行被排除出 10 条实做名单的依据是「记录同步已做」，**不是「接线已做」**）⇒ **逐字登记为批 8 输入**，**不得**读成「本批 12 条补 UI 已全部接线」。
+>
+> **🔻 收口更正（2026-09-13 · T21 追加轮；上一注的**实测发现保留**、**处置作废**）**：上一注把「接线」那一半登记为「→ 批 8 输入」—— 🔴 **该处置作废**。依据 `rulings.md` §C56.2 逐字：**「这是批 7 的交付缺口，不是「批 8 输入」……不得让一次漏做在事后读成一次有意的延期」**。**理由**：本行处置栏逐字是「**补 UI（本批）**」，且计划的指派三处一致 —— `:532` A-2「**不做记录**；**命令本身接线**」→ 本批 · `:2299` C11 给了落点与判据 · `:2309` Step 3 逐字「C 组（**C5–C11 共 7 条**）—— 逐条单独提交」。
+> - ✅ **已在批 7 内由 T23 补做并交付**（3 条提交）：`125eec85 feat(components): 片段行补上移动到组入口`（4 路径，含新件 `app/src/components/FragmentGroupAction.tsx`）· `5f662811 test(components): 把源码探针标题同步到七条命令` · `5d59e332 fix(components): 碎片归组候选改用 feed 地形组`（**地形返工**：候选集由 `container` 改为 **`feed`**）。
+> - ✅ **T21 于追加轮独立复测**（口径 = node `fs` 全仓扫描；正控 `invoke(` **68** 个生产文件 · 负控 **0**）：`update_fragment_group` 前端命中 = **PROD `app/src/components/FragmentGroupAction.tsx`（4 处；`:92` 逐字 `invoke("update_fragment_group", { fragmentId, groupId: target })`）** + 测试侧 `FeedFragmentList.test.tsx`(9) · `batch7UiWiring.test.tsx`(2) ⇒ **PROD 0 → 1（≥1）**。
+> - ✅ **落点形态**：`FragmentGroupAction.tsx:71` `invoke<NoteGroup[]>("list_note_groups", { terrain: "feed" })` + `:72` `.filter((g) => g.terrain === "feed")`（**后端真源 + 客户端第二道**）· 载荷键名 `{ fragmentId, groupId }`（Tauri 2 camelCase；Rust 真身 `app/src-tauri/src/commands_fragments.rs:141-145` = `update_fragment_group(state, fragment_id: i64, group_id: Option<i64>)`）· `groupId: null` = **移出组**（与 `Option<i64>` 的 `None` 逐字对齐）。
+> - ✅ **判据**（T23 自报 + 控制方 §C57.5 逐项复核）：**V7** 正控（feed 组入候选 + 查询载荷逐字 `{ terrain: "feed" }`）+ 🔴 **负控有效**（容器组不入候选）· **V8** 父层 ≤300 · **V9 两株**（`"feed"`→`"container"` 红在 `FeedFragmentList.test.tsx:225:33`；**删客户端收口**红在 V7 负控 `:227:82`）· V1–V6 重跑通过 · CONTROL 同树 29/29 绿。
+> - 🔴 **缺口成因（逐字登记，供 T22 的二分清单收录）**：计划口径**正确且甚至预警过** —— `:2304` 自陈「数一数是 **11** 个名字」、`:2305` 裁决「按名字列全 **11** 个，不删任何一个……**不自行删减**」；而 T20 报告的计数口径「6 + T18/T19 的 4 = **10**」**恰好吞掉了被删减的那一个名字** ⇒ **缺口成因 = 实做方的计数口径，不是计划缺陷**。
 
 **汇总**：删 **22** · 本批补 UI **12** · 登记不排期 **7** · 撤下 IPC **3** · 有意保留 **3** · 待核实 **0** ＝ 47。
 
@@ -899,6 +906,7 @@
     > - **差额逐条**：**24 → 11 = −13**，分解 = **−10**（本批实做补 UI 的 10 条各得 ≥1 生产调用点）+ **−3**（撤下 IPC 的三条随注册一起离开本集合）。同格局：上格「25 条」是**剩余命令条数**（含 `kb_search`）⇒ 现 **22 条**（−3 撤下）；条数 − 零引用 = **11 = 有引用数**（与逐条读数一致）。
     > - 🔴 **新命令 `remember_video_profile_tier` 不在上格的 47 条内**：前端生产调用点 **2**（`components/ProfileDetector.tsx`）⇒ **不计入零引用**（它的义务是 §1 L5 行 34 的「新增命令」，不是本格的补 UI）。
     > - 🔴 **残留 1 条挂着「补 UI（本批）」却仍零引用**：`update_fragment_group`(#46) 全 `app/src/**`（**含测试**）命中 **0 文件 / 0 处**，而它**仍在 registry** ⇒ **本批未接线**（它被 §C9.1 排除出 10 条名单，理由是「记录同步」那一半批 1 已做，**不是因为接线已做**）⇒ **登记为批 8 输入**，并见 §9 该行的状态更正注。
+    > - 🔻 **收口更正（2026-09-13 · T21 追加轮；上面三条原读数一律保留为「T21 首轮」的历史读数）**：`update_fragment_group`(#46) **已在批 7 内由 T23 补做**（`125eec85` + `5f662811` + `5d59e332`；T21 独立复测 **PROD 0 → 1**，落点 `components/FragmentGroupAction.tsx:92` 逐字 `invoke("update_fragment_group", { fragmentId, groupId: target })`）⇒ 🔴 **残留 1 条 → 残留 0 条**；🔴 **前端零引用 11 → 10**（口径不变：上格那 47 条中**仍在 registry 者 22 条**里的前端生产零引用数）⇒ **有引用数 11 → 12**（其中本批实做补 UI = **11 条**：T20 的 6 + T23 的 1 + T18/T19 的 4；`kb_search` 是第 12 个有引用者，但它属批 3 交付）。⇒ 上面那条第 4 项（「残留 1 条」）的**处置改为「已交付」**，`§9` 该行的状态更正注已在表末就地更正。
    > ⚠️ **批 1 的实测更正（供批 2+ 引用本条时注意）**：计划的「不删清单」在本批被**证伪五次**（`artifact_templates` 族 / `AiEnhance*` 半边 / `vad_threshold_slot` 三符号 / `spec_from_kind` / 调用点计数），根因是**用「看起来还有人用」代替「删除后可达性」**作保留判据 ⇒ 后续批次判断连通性请照「收口回写」节的四条约纪律（计划 `docs/superpowers/plans/2026-09-11-frontend-redesign-batch1-deletions.md`）。
 8. **标签能写进去**且标签过滤面板有内容；**画面档位选完真的生效**且跨会话记住。
 9. JS 包首屏 gzip 达标或给出瓶颈清单；GSAP 只在独立 chunk 懒加载。