dsh_ai1net_server/执行会话/目标-本机协作-3e3182/S12_收尾核对_20261003.md

S12 收尾核对（await-verify → 判定）· 2026-10-03

• 执行会话：[协作]-[机制排查与修复]-S12 收尾核对转 done
• 执行时间：2026-10-03 11:14–11:2x
• 域锁：ai1net-dsh-server/目标-本机协作-3e3182（已抢到，收尾已释放）
• 一句话结论：⚠️ 状态判据本轮判不出来 —— 真体检又被跳过（原因＝busy，不是节流）； 节点 S12 维持 await-verify，⛔ 未标 done。

1. 结论为什么不是 done（先说卡在哪一条）

• 节点 S12 的第二条判据是「下一次真体检的 体检报告.md 里，那 9 条 id 不出现在 notes/issues 段」。
• 本轮现跑了 collabd.py --once（⛔ 未带 --supervise），命令 rc=0，但落盘文件 tmp/supervise-inbox/体检报告.md 的 mtime 仍是 2026-10-02 20:50:22 —— 内容没被刷新。
• ⇒ 本轮没有新的体检读数。而磁盘上那份是清理动作之前（20:50 早于 22:0x）的旧读数， 它仍然把 5e335e01 列在 issues 段、把另外 8 条列在 notes 段。
• ⇒ 现在若把节点标 done，等于与磁盘上那份报告直接矛盾。按判据纪律 ⇒ 不标 done。

2. 跳过原因＝busy（不是 300 s 节流戳）

判据来自 collabd.py::health() 第 727–729 行：out = {"skipped": V["busy"], ...} ＋ if V["busy"]: return out —— 只要 busy 为真就直接早退，连节流判断都走不到。本轮把两个因子分别实测：

• V.busy = True（实测打印）。根因＝fetch() 取到 1 条 working 会话： a80f300d-bdca-41a0-a17d-edda4fffcb77「分析定时任务创建会话机制」（cwd 命中本工作区）。 辅助读数：busy_(d)=True、_all_sessions_idle()=False。
• 节流戳不是原因：state.health_at = 1790935400.37，年龄 61,945 s ≈ 17.2 h， 远大于 health_every = 300 ⇒ 若 busy 为假，这一轮就会落盘。

⇒ 结论：只要还有任一 working 会话，体检就恒被跳过。这与 S12 报告 §7.2 预判的病灶同源， 但真因是 busy（不是「本自动化会话在跑」本身） —— 本轮实测是另一条 working 会话顶上的。

⛔ 本轮未处置该 working 会话：按本机铁律，⛔ 不得对宿主在跑的会话做 load/接管、改其配置或进程。

3. 计数判据：9 条逐条现读（全部保持停用，⛔ 无回归）

直连只读（mode=ro ＋ busy_timeout=10000）逐条回读四元组，9/9 全为 ('PAUSED','once',None,None)：

• a50a1791［协作］-［会话协作自检］-S6 建齐三类会话
• 3872e203［协作］-［机制排查与修复］-S5 修主会话可响应
• 73f138ce［协作］-［机制排查与修复］-S8 常驻投递载体（重派·锁已清）
• 5c77eedc［协作］-［机制排查与修复］-S9 投递目标忙判据复核与放行验证
• 9ec39dac［协作］-［机制排查与修复］-S9 投递目标忙判据（含 S8 常驻复核）
• 5e335e01［协作］-［机制排查与修复］-哑火判据与排期清理
• 4e7b8401［协作］-［机制排查与修复］-投递链路真因接续
• a2982f2e［协作］-［机制排查与修复］-清理跑完的一次性排期
• 9a06e9b8［跟进］-机制排查与修复-队列跟进

⚠️ 另核一条旧报告里出现过、但不在本次 9 条清单内的 id：87d55715（S7 全量验收 V1–V7）—— 现读数同为 PAUSED，也不在任何 ACTIVE 集合里。

• PRAGMA integrity_check = ok（只读跑，未做任何写操作）
• 总行数 148（S12 清理当时是 141 ⇒ 增的 7 行是清理之后新建的排期，⛔ 不是"删了又补"）

4. 关于「计数从 0 变成 4」——不是回归，是新增

判据 ONCE_ACTIVE_NO_NEXT（deleted_at IS NULL ∧ status='ACTIVE' ∧ schedule_type='once' ∧ next_run_at IS NULL） 现读数 = 4（S12 清理后当时读数是 0）。逐条查 created_at，4 条全部晚于清理动作时刻：

1. b6ce8822 v1原型重跑-③段 —— 建于 2026-10-02 23:41:16
2. 99f803b0 ［跟进］-队列上报（固定席位·不分类别）—— 建于 2026-10-02 23:47:12
3. 056c427a ［协作］-③段-v1原型重跑 —— 建于 2026-10-02 23:47:31
4. 00bf17bd ［协作］-［目标检查］-ai1net-dsh-server-第2棒 —— 建于 2026-10-03 11:06:03

⇒ 结论：S12 那 9 条一条都没复活；这 4 条是清理之后由后续工作新建的排期（其中第 4 条就是本轮目标检查排期）， 不属于 S12 的清理范围，⛔ 本轮不处置（那是「跑完之后再清」的新一轮，不是回归）。

5. 只读模拟（⛔ 仅作旁证，不当作过）

为确认「一旦不 busy 会不会翻红」，在内存里把 V["busy"] 置 False 跑了一次 health()，⛔ 未落盘、未改任何库：

• issues = []（空）
• notes = 3 条，全部是新排期：b6ce8822（延迟 19 分钟跑完）、99f803b0（17 分钟）、056c427a（24 分钟）
• 目标 9 条 ＋ 87d55715 共 10 个 id：逐条「不在候选集」 ✅

结构性原因（读源码确认，非推断）：fetch() 第 466–467 行的候选 SQL 是 where status='ACTIVE' and (deleted_at is null or deleted_at='') ⇒ PAUSED 的行在数据源层就进不了 d["due"]， 因此它们不可能出现在 issues/notes 任何一段。

⚠️ 但这仍不算判据过：判据原文要求「体检报告确认」，而磁盘上那份报告没被刷新。 模拟是旁证，⛔ 不替代真读数（否则就成了"自己判自己过"）。

6. 节点处置与解锁条件

• S12 维持 status = await-verify，⛔ 未标 done、未退 todo（活本身干完了，只是门禁读数没拿到）。
• 解锁只需要一件事：在无 working 会话的窗口跑一次 collabd.py --once （判据：V.busy=False ∧ _all_sessions_idle()=True），让 体检报告.md 真正刷新。 届时若 issues/notes 不含那 9 条 ⇒ 直接置 done（第一条判据与第四条模拟读数均已就位）。
• ⛔ 本轮未改 collabd.py、⛔ 未改任何排期状态、⛔ 未碰 queue.json/queue.md/NEXT.md（派生产物）。

7. 台账同步

• tasks.json 的 S12 本来就已是 done（由 [主会话]-记录常驻起法 于 10-02 写入，artifact 指向清理报告）。 本轮沿用 done —— 台账语义是「活干完了吗」（活确实干完，9/9 现读为 PAUSED）； 更严的「读数门禁」由任务图节点的 await-verify 承担。两者分工不同，不是矛盾。
• 本轮只更新 artifact 指针指向这份核对报告（⛔ 按机制硬约束带 --artifact，缺了会被 rc=3 拒收）。

8. 结论（给检查会话读）

• 目标「检查会话协作是否运行正常 ＋ 协作机制问题排查与修复」仍不可改成已完成 —— 任务图仍有 1 个 status != done 的节点（S12＝await-verify），按 目标执行状态.md §一.3 三路取并集， 任一路没完就是没完。
• ⛔ 本轮未替检查会话改「目标生命周期」（那是检查会话的职责）。

（报告完 · 域锁已释放）