dsh-workplan 1.12.3 — 澄清闸门 + 句中先行词 + 法务召回

1.12.3 — 2026-11-04

修好 MS2 20 条真实实跑暴露的四处缺陷：指代误拦（T05-08）、该问不问（T05-04/09/13/20）、未确认自行派发、法务召回缺失（T05-12）。默认行为变化：信息不足时不再生成计划、不再派发，改为向用户提问。

一、四处缺陷的修法

编号	缺陷（MS2 实测）	1.12.3 的修法	代码位置
① 指代误拦	T05-08「它每天具体走势」——「它」的先行词就在同一句的上半句，却被判成「找不到先行词」直接拦下	先在任务原文的同一句、再在上一句里找「实体型」先行词（引号跨度，或含数字/字母的中文实体片段）；只有两处都找不到才拦	src/understanding.ts resolvePronounAntecedentInline
② 该问不问	T05-04/09/13/20 四条本该澄清，却照做计划并派发	四条可判定规则：C1 裸表态、C2 悬空内部编号、C3 预测类无标的、C4 界面改动无对象；命中时在规划之前拦下，并给出一句可以原样问用户的话	src/understanding.ts auditClarifyNeed；src/plan.ts buildClarifyMessage；src/runtime.ts 规划前闸门
③ 未确认自行派发	20 条里累计 46 次未经用户确认就启动部门 Agent	按用户 2026-11-04 的决定：自动派发语义不变，只在「信息不足」这一类上拦截——缺信息时连计划都不生成，自然走不到派发	src/runtime.ts clarifyGateDisabled / maybePlan
④ 法务召回	T05-12「会不会窃取用户文件和数据」判成无部门覆盖	legal 词表增加 窃取 / 信息泄露 / 个人信息 / 数据安全 / 隐私风险 / 移动终端（刻意不用「泄露」：内存泄露属于工程问题）	src/departments.ts

二、每一条结论的证据（可复核）

• 离线回放（不调用模型）：20 条真实原文 → clarify 4/4 命中，16 条正常任务误拦 0 条；T05-12 legal 命中 2 词（窃取、移动终端）；「修复内存泄露导致的崩溃」legal 命中 0 词；「参考国际标准做一下排版」仍为 1 词（低于 ≥2 门槛，不会把排版任务拉进法务）。
• 端到端（headless 真跑）：用 T05-13 原文启动 headless → 事件流里 0 个计划、0 次 dsh_workplan_* 工具调用，模型改为向用户提问（证据见 _t_clarify_20261104/）。
• 自动化测试：npm test 523 条全过、0 失败（含新增 tests/clarify-gate.test.ts、tests/antecedent-inline.test.ts）；npm run check（tsc --noEmit）退出码 0。
• 修正了一条旧断言：legal 词表从 16 词增到 22 词，tests/department-coverage.test.ts 的数量断言同步更新并写明原因；C4 曾把「把红圈处改为默认收起」误判成「没说要改哪里」，用 department-fit.test.ts 抓出来后才补上「红圈/红框/圈出」三种说法。

三、开关与行为影响

• 新增 DSH_WORKPLAN_CLARIFY_GATE=0：关闭澄清闸门，回到旧行为（信息不足也照做计划、照派发）。默认开启。
• DSH_WORKPLAN_AUTO_DISPATCH 语义未变：默认自动派发照旧，只是信息不足的任务不会再走到派发这一步。
• C3/C4 允许「缺的对象在最近对话里」：上一轮说过「截图红圈处的分步进度」，本轮「把它改成默认收起」就不算缺信息（否则会把正常追问也拦掉）。

四、本版没有覆盖的（如实登记，不计入修复证据）

• 同一工作区里还有一个 headless「未完成不得成功收尾」闸门（failClosedOnIncomplete / WORKPLAN_INCOMPLETE），目前只有实现、没有自动化用例；发布前必须补测，本版不宣称它已验证。