■ 先说结论：**那条规范⛔ 没加，因为它已经有两份了**
  `show_guidance`：「讲完其中一类，**紧接着**调一次；⛔ 别攒着一起调」
  `propose_assignment`：「可动手的事**一件一件**开放：说完它管的那件事，当场就开放它」
  两者是 2026-08-15 同一次事故之后一起调好的，`propose` 那句上面还有一条明确的
  ⛔「这里别再出现比"一件"更粗的量词 —— 粒度只该由 show_guidance 定」。
  ⇒ 再写第三份正是文件头禁止的「同一件事只许有一份」，两边必然各自漂。

■ 真正缺的是**验证手段**
  留痕此前只记「调了几次 show_guidance」，而那看不出对错：
    3 次可以是**分 3 步各讲一段后各调一次**（对）
    也可以是**同一步里一口气调 3 次**（错 —— 三排按钮叠在同一段末尾，正是那次事故的形状）
  ⇒ 新增 `output.steps = [{n, textLen, tools[]}]`：每一步讲了多少字 + 调了哪些工具。
    判据：show_guidance 落在**各自独立、且 textLen>0** 的步里 = 守规矩。

■ ⚠️ 线上已经量出一次不合规
    23:25 | propose → show_guidance ×3 → show_sheet        看着像一类一调
    23:05 | propose → propose → show_sheet → show_guidance ← **明细先摆，引导落在后面**
  后者与 `propose_assignment` 描述里「最后让他看这一版的完整明细」相反。
  有了 steps 之后，这类问题不用再靠翻聊天记录看。

■ 顺带对齐两处落下的改名（工作区把标识改成了「最忙和超期」，但这两处还写着「最忙的那位」）
  · lab.controller 的工具描述
  · assignment-signals 里我自己写的那条注释

⚠️ 字段名**查了 SDK 类型定义**再写的，⛔ 没靠猜：`StepResult.toolCalls[].toolName`
  （index.d.ts:854 / 695）—— 名字写错的话 tools 会永远是空数组，**静默失败**。
验证：tsc 通过;jest 87 套 1359 例全过;真模型跑一轮确认 steps 落库
  （`[{"n":1,"tools":[],"textLen":142}]`）。