chore(backlog): 记录 g272 完成

.ua/backlog.json

@@ -2834,6 +2834,15 @@
       "status": "done",
       "domain": "new",
       "notes": "返回句柄是本库既定模式（formItem / virtualList 同款），因为「有画布就有外部要的操作」：取图、清空、判空。三处状态（位图 / signed 信号 / value 信号）必须一次改完——clear() 里少写一处就会出现「画布清空但信号还是旧图」。踩坑：Write 工具连续三次只写进文件头部（把注释当全文提交），build 直接暴露；demo 里 IIFE 少一个右括号，esbuild 报 Expected ) but found ; —— 新建组件后先 build 再谈其余门禁，能省一轮全量 check"
+    },
+    {
+      "id": "g272",
+      "title": "视觉回归抽查清单扩到十一个组件并让下限自推导",
+      "motivation": "清单固定 six 组件是 10-23 定的，那时库只有 34 个组件、新增的多是表单小件。这两轮一口气加了 layout / jsonViewer / diffView / codeBlock / signaturePad 五类新形态（容器、数据展示、录入画布），它们恰恰是「令牌用对了但观感可能错」的高风险区——侧栏折叠抖动、JSON 竖线叠重、diff 行底色渗到行号列、代码块悬停残影、签名笔迹发灰，这些都没有抽查位。清单不覆盖，就等于默认它们不用人眼验收。",
+      "acceptance": "ITERATION.md 清单新增 layout / jsonViewer / diffView / codeBlock / signaturePad 五段，各 3-4 条、维度标签仍限五类；ua verify 的 REQUIRED 扩到十一段，MIN_TOTAL 改为 REQUIRED.length × MIN_PER_GROUP（33）由段数推导——以后加抽查位只需加段、不用手改总数；verify 成功语与 AGENTS.md、ITERATION.md 的「六段 / ≥18 条」表述同步为「十一段 / ≥33 条」；npm run check 全绿",
+      "status": "done",
+      "domain": "visual",
+      "notes": "下限从写死的 18 改成 段数 × 每条下限：这类「N 个组件」的计数一旦写死在门禁里就必然会漂——库自己已经在 verify 里靠 sync-counts 治过一次同样的病，这次直接把口径做成派生量。选题前先查了「焦点环覆盖」与「outline:none 是否配环」两处，均已被全局规则与逐组件 :focus-visible 覆盖，于是转向验收纪律本身：视觉门禁的分工是 audit:visual 管字面量、清单管观感，清单漏段等于放行"
     }
   ]
 }