admin
c1b5e4d966
- 变更规模：新增 514 / 修改 62 / 重命名 155 / 删除 4（归档重组与文档轮次） - .gitignore 修：`归档/**/db-cwd归一-备份-*/` —— 原规则写绝对层级（归档/db-cwd归一-…）， 目录搬进 归档/配置与备份/ 后**静默失效**，43 MB 的 DB 备份又变成未跟踪 - .gitignore 补：嵌套 git 内部数据（归档/内嵌git-20261008/、归档/skills-git-旧线-20261007/dotgit-原样移出/） - .gitignore 补：运行态与部署副本（.workbuddy/collab/、.workbuddy/tools/、.workbuddy/.load-pending、.workbuddy/tmp-*） - .gitignore 补：备份件（*.bak-*） - 未跟踪文件从 2190 降到 890（其余为 归档/ 归档件与 .workbuddy/memory/ 知识文件，按口径入库）
5.7 KiB
5.7 KiB
目标执行状态
🔴 本文件＝检查会话判断目标状态的唯一依据（用户 2026-10-03 10:5x 要求逐字： 「目标执行情况也要有文档，这样检查会话直接根据文档判断目标状态，避免检查会话到处找信息」）。 ⛔ 检查会话不许再去工作区里翻文件找目标状态 —— 读本文件 ＋
tasks.json就够了。
- 目标标题：检查会话协作是否运行正常 ＋ 协作机制问题排查与修复
- 目标简称：本机协作
- 目标生命周期：进行中
- 本文件由谁更新：目标检查会话（
[协作]-[目标检查]-…）在核对完成后改「目标生命周期」并更新本文档 - 最后实测时间：2026-10-03 10:52（所有读数均为现测，⛔ 不是转述）
一、怎么用这份文档（检查会话照此判断，别自己另立口径）
- 先读
tmp/supervise-inbox/tasks.json（队列四态台账）—— 那是「活干完了吗」。 - 再读本文档 —— 那是「目标达成了吗」。
- ⛔ 两者都不许跳。三路取并集，任一路"没完"就是没完：
- 台账里有
pending／running／blocked的件； - 任务图（
交付物/任务图-会话协作自检.json）里还有status != done的节点； - 本文档第二节里还有任何一条判据没过。
- 台账里有
- 全部满足 ⇒ 才可把目标生命周期改成「已完成」，并在本文档把「结论」那一行更新掉。
二、验收判据（逐条，⛔ 判据值是中文写法：过｜…／🔴 不过｜…）
V1 协作程序常驻一直运行
- 结论：过
- 实测：
supervise-heartbeat.json→pid=38988、round持续上涨（10 s/轮）、ts_h=2026-10-03 10:35:21。 - 判据：pid 活 ∧ 心跳新鲜（<90 s）—— 与
selftest.py::t_supervise_ensure同一口径。
V2 队列与检查会话链路
- 结论：过
- 实测：
tasks.json读数S5=done（带 artifact）、S12=done（带 artifact）；queue_pending()=0（真源tasks.json四态口径）；闸②_all_sessions_idle()=True、闸④ws_pending_schedules()=[]、闸③ 走queue-empty。 - ⚠️ 旧判据「跟进会话链接得住（零条活着 / 今日投递成功 0 次）」已作废 —— 唤醒／跟进／队列投递 整套退役（用户 2026-10-03 定案），那条判据永远不可能满足。⇒ 本条改为校验现行链路。
V3 协作会话在台账里留有产物文档
- 结论：过
- 实测：
S5.artifact指向references/architecture.md §2.3.0f；S12.artifact指向机制排查与修复/S12_清理报告_20261002.md。 - 判据：每条
done必须有artifact。⇒ 机制侧已加硬约束：--report --state done缺--artifact直接拒收（rc=3）。
V4 看板可服务
- 结论：过
- 实测：
netstat→127.0.0.1:8788LISTENING（pid 41764）；/board.json→ HTTP 200、ts=2026-10-03 10:52:35。 - 判据：能起得来 ＋ 回环 HTTP 200（⛔ 不看页面像不像，看接口读数）。
V5 机制自测全绿
- 结论：过
- 实测：
selftest.py→ PASS 55 / FAIL 0。 - ⚠️ 基线是 FAIL 1（
技能侧零项目串那条，已于 2026-10-03 上午修掉：域键锚点词表三处对齐 ＋ 结构性豁免）。 ⇒ 判据写成「FAIL 0」，⛔ 不写「与基线持平」—— 那种写法会让真红也通过。
V6 协作程序格能显示"检查程序在运行"
- 结论：过
- 实测：
/board.json→runtime.check = {"n":0,"label":"无检查在跑"}。 端到端验过：临时把一条检查会话置working⇒ 线上runtime.check.n=1、label=有结果检查在运行；还原后回n=0。 - 判据：
runtime.check字段在位 ＋ 与真库working检查会话数一致（不许恒绿）。 - ⚠️ 旧判据「跟进会话角色落地（名册 11 条）」已作废 —— 跟进会话整套退役。
V7 检查会话按规范命名、能被看板认出
- 结论：过
- 实测：排期名＝
[协作]-[结果检查]-<工作区>-第N棒（两级方括号前缀）；parse_session_name()⇒role=worker / topic=结果检查 / ok=True； 线上/board.json里44b547d4的role=协作会话（改前是「主会话」）。 - 判据：
role=worker＋topic非空 ＋ 两侧解析零漂移。 - ⚠️ 旧判据「开工建齐三类（唤醒/协作/跟进）」已作废 —— 会话只剩两类（主会话／协作会话）。
三、结论
- 7 条判据全部通过 ⇒ 目标「检查会话协作是否运行正常」这一部分已经达成。
- ⚠️ 但整体目标未完成 —— 标题里还有「协作机制问题排查与修复」那半句，
而任务图（
交付物/任务图-会话协作自检.json）里仍有status != done的节点。 ⇒ 目标生命周期维持「进行中」，⛔ 不得改成「已完成」。
四、旧判据的作废清单（⛔ 别再拿它们判）
| 旧判据 | 作废原因 |
|---|---|
| V2-跟进会话链接得住（零条活着／今日投递成功 0 次） | 唤醒／跟进／队列投递整套退役，永远不可能满足 |
| V6-跟进会话角色落地（名册 11 条） | 同上 |
| V7-开工建齐三类会话（唤醒／协作／跟进） | 会话只剩两类（主会话／协作会话） |
⚠️ 本清单不是为了好看 —— 留着它们，目标状态就永远判不出来（同族红线： 「一条判据都没有 ⇒ 判不出来，⛔ 不许当成已完成」的反面：有一条永远红的 ⇒ 也不许当成未完成）。