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/ 知识文件，按口径入库）
6.6 KiB
6.6 KiB
多会话协同机制 · 实施方案（怎么实现它）
⛔ 已退役（2026-09-30）
本件（实施方案）的内容已并入 →
E:/ProgramData/.workbuddy/skills/multi-session-collab/references/architecture.md（协作机制的唯一权威文档） ⇒ ⛔ 别再引用本件做判断（曾因它把旧结论当现状）；本件只作历史沿革留档，⛔ 已不再维护。 依据：用户 2026-09-29 定案「只有一份架构文档」「一切迭代都在 skill 内」「⛔ 不在工作区或别处另开平行文档」。
配套：机制定义 ⇒
多会话协同机制-定稿-20260929.md｜作业规程 ⇒协同监管棒-SOP.md｜执行纪律 ⇒CODEBUDDY.md §1.5本件回答一个问题：这套机制要"实现"，具体要做哪几件事、谁做、怎么验。
一、组件清单：已就绪 vs 待落地
| # | 组件 | 状态 | 说明 |
|---|---|---|---|
| ① | 机械层脚本 advance-watch.py |
✅ 已就绪 | 直读 automation_runs 拿各线收官结论 ＋ 判三线靶点/全局靶点/锁；自带 120s 节流、异常全吞 |
| ② | 收结果通道（直读宿主库） | ✅ 已就绪 | 实测已读到棒 1b 完成结论、「IN_PROGRESS」也在 |
| ③ | 决策层规程 协同监管棒-SOP.md |
✅ 已就绪 | 收产出→判 V1–V7→刷看板→派下一棒→异常处置 |
| ④ | 进度看板（用户唯一入口） | ✅ 已就绪 | 每轮覆写 |
| ⑤ | 派活模板（含必含三条款） | ✅ 已就绪 | 多会话协同机制-定稿 §4.1 |
| ⑥ | 兜底自动化（每小时循环） | ✅ 已就绪 | 1eaf45c3，至 09-30 12:00 |
| ⑦ | 钩子挂载生效 | 🔴 未落地 | 我改过 wb-result-hook.py；但钩子是「会话启动时快照」 ⇒ 必须完全重启 WorkBuddy 才生效（关窗 ≠ 退出）。没做完这步，① 永远不会被自动触发。 |
| ⑧ | 「完成即推进」不依赖纪律 | 🔴 本轮刚补 | 已写进 CODEBUDDY.md §1.5 D ⑤（每次会话开机必读）⇒ 从"口头纪律"升级为"硬规则" |
| ⑨ | 收敛判据机械化 | 🟡 部分 | V4/V5/V7 里可机械判的项可继续加进 ① 的 TARGETS；需 AI 判断的（V1/V2 语义）留给监管棒 |
⇒ 一句话：① 待做（需你配合重启）；⑧ 已补；⑨ 增量可做。
二、"完成即推进"到底怎么实现 —— 四条路，选了哪条
| 方案 | 做法 | 优点 | 缺点 | 判定 |
|---|---|---|---|---|
| A 完成方自己叫 | 各棒收尾时创建一次性自动化叫监管棒（now+2min） | 零新增件；≈2 分钟；不靠常驻 | 依赖执行方记得（会漏） | 🟡 可接受，且已写进 §1.5 D⑤ ⇒ 变成必读硬规则，漏的概率大降 |
| B 钩子直接派活 | 钩子里 POST /api/v1/scheduled-tasks 建任务 |
全自动、即时 | 🔴 违反钩子纪律（七条硬纪律明令：钩子不读令牌、不联网、不起子进程）；且要处理 sessionId | ⛔ 不可用 |
| C 钩子只落标志 + 整点兜底读 | 钩子写"待推进"文件；每小时轮读它再派 | 完全合规、零 token | 最慢 60 分钟（回到"稀饭凉"） | 🟡 仅作兜底 |
| D 独立常驻进程 | 独立窗口/计划任务里的进程，读标志 → 调网关建自动化 | 秒级、不占会话 | ①多一个常驻；②它不是 WorkBuddy 后代 ⇒ 拿不到口令（同 G-C 困境）⇒ 调不了网关 | ⛔ 不可行（口令） |
⇒ 选定：A 为主（且已升格为必读硬规则）＋ C 为兜底（= 现有每小时循环）。
关键洞察：宿主只给两种"等待"形态 —— 钩子（被明令禁网）与自动化（能开会话、但有粒度下限）。⇒ "完成即推进"在合规前提下的最短路径，就是让完成方自己叫（≈2 分钟），这条路已通过 §1.5 变成制度。
三、实施步骤（按顺序，每步都可独立验证）
| 步 | 做什么 | 谁做 | 怎么验（判据） | 阻塞 |
|---|---|---|---|---|
| S1 | 完全重启 WorkBuddy（让 ⑦ 钩子改动生效） | 需用户（会打断在跑会话，要在你合适的时间做） | 新会话收尾后：tmp/supervise-inbox/advance.md 的 mtime 变新；_phone-bridge.log 类似台账出现新增行 |
⚠️ 等你定时机 |
| S2 | 各棒按 §1.5 D⑤ 收尾即叫监管 |
各线会话 | 看板在上游完成后 ≈2 分钟内被刷新（看板里「更新时间」跳变） | 已具备（规则已进 §1.5） |
| S3 | 收敛判据机械化（把 V4/V5/V7 可机械项加进 advance-watch.py 的 TARGETS） |
我 | 跑一轮 advance-watch.py --force，advance.md 里出现对应 ✅/⛔ 行 |
无 |
| S4 | 每轮监管棒刷新看板 + 按异常处置表派活 | 监管棒（每小时 + 收尾触发） | 看板「更新时间」持续跳变；缺口消失即 V 判据转 ✅ | 无 |
| S5 | V1–V7 全过 ⇒ 收敛 | 监管棒 | 看板标「目标达成」，不再派棒 | 依赖 S1–S4 ＋ 业务线真装 |
四、验收：怎么算"这套机制实现了"
| # | 判据 | 怎么测 |
|---|---|---|
| M1 | 钩子真的被触发 | 造一次会话收尾 ⇒ advance.md mtime 变新（S1 之后才可能） |
| M2 | 收结果零轮询、零 token | 只读一次 automation_runs 就能列出各线结论（已实测 ✅） |
| M3 | 完成 → 推进 ≈2 分钟 | 某棒收尾后，看板在 2 分钟内刷新（S2） |
| M4 | 兜底有效 | 即使完成方忘记叫，≤60 分钟内仍会被推进（每小时循环） |
| M5 | 不影响 WorkBuddy 本身 | 全程 ⛔ 无会话后台任务、⛔ 无常驻；WorkBuddy pid 恒定、宿主会话能回 idle |
| M6 | 收敛可停 | V1–V7 全过 ⇒ 看板标达成、停止派棒、明说"可结束监管" |
五、未决 / 风险（如实登记）
- 🔴 S1 需你拍板时机 —— 「完全重启 WorkBuddy」会打断所有在跑会话，属影响面超出本功能 ⇒ 必须你定时间（这也是机制里唯一必须你介入的点）。
- ⚠️ A 方案仍可能被漏（执行方忘记叫）⇒ 靠 M4 兜底兜住；若发现漏得频繁，可把兜底从"每小时"加密为多个错开的一次性自动化（rrule 校验器只接受整小时粒度，密不过 1 小时）。
- ⚠️
automation_runs.thread_title的语义依赖宿主实现；若某次结论为空（[IN_PROGRESS]正在跑就是空的）⇒ 判据以status为准，不把"空标题"当"没干活"。