0 Fork 0

Files

T

admin c1b5e4d966 chore(工作区): 全量入库 + 补齐 .gitignore（以工作区为准）

- 变更规模：新增 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/ 知识文件，按口径入库）

2026-10-10 23:13:22 +08:00

6.0 KiB

Raw Blame History

接续包 · 投递链路真因定位与「跟进会话长活」口径更正

线名：多会话协作机制 · 投递链路（「投不进跟进会话」）建档：2026-10-02 10:00 ｜ 上一棒：本会话（上下文 187,506 token 触发 §G 阈值而交接） 上游依据：.workbuddy/memory/2026-10-02.md（09:45–10:00 两节＝完整证据链）＋ 交付物/投递链路-真因定位-20261002.md（复核单） ⛔ 不要重做：六层判读链实测｜goal.json 还原｜limit 50／cwd／角色解析／空库／custom_title／零宽字符 —— 六项已逐个排除，别再重查

§0 开工第 0 步（固定）

跑 "E:/ProgramData/.workbuddy/binaries/python/versions/3.13.12/python.exe" "E:/ProgramData/AIProject/ai1net-dsh-server/state.py"
判可锁定范围：bash "E:/ProgramData/.workbuddy/skills/session-mechanism/scripts/lock/preflight-lock.sh" "<会话名>" <目标文件...>
抢锁：要改 collabd.py／architecture.md ⇒ 属机制层 ⇒ 走独占（抢不到即停手报告）
读本包 → 读 CODEBUDDY.md §1.5 / §G → 按 §2 动手
🔴 本棒设工具调用上限 60 次（成本机制：历史每轮全量重发，多跑一轮线性放大）

§1 要解决的问题（一句话）

🔴 「投不进跟进会话」的真因不是「没有跟进会话」，而是「名册里的跟进会话都没在跑」 —— 而 _deliver_str 丢弃了 follow_for_topic() 已经算准的 why，把「有 6 条、只是都不活」记成 no-follow-session（字面意思与事实相反）⇒ 这个错名把两天的排查引向了"再多建一条"，而多建不管用。

六层判读链（实测，同路径插桩 tmp/_tick_instrument.py）

#	环节	实测	判读
1	目标类别表	`_goal_topics()` = `['会话协作自检','机制排查与修复']`	通过
2	跟进名册	`_scan_follows()` = 6 条，`by_topic` 两类齐	通过
3	候选解析	`cand=['57f58ecf']`	通过
4	活会话	只有主会话 `3f43ce71`（1 条），候选不在其中	🔴 卡这里
5	判读	`why='follow-not-live'`	准确
6	落库	`skipped='no-follow-session'`	🔴 错名

错名源码：collabd.py:1545-1558 —— _deliver_str 只按 _want=="" 分档，把 (a) 真·无候选 与 (b) 有候选但都不活 合并成同一个 no-follow-session。

§2 待办（按优先级）

P1 ① 修 `_deliver_str` 分档（⛔ 只改可读性、不改行为）

把 follow_for_topic() 的 why 透传进 skipped，让 follow-not-live 与 no-follow-session 分开记档，并让 need_user() 文本与之一致。改前先查 board.py / selftest.py / 各判读脚本对这两个字符串的依赖。

P1 ② 🔴🔴 按用户 2026-10-02 09:59 的新口径复核并落地「跟进会话长活」

用户原话（逐字）：

「那是因为之前跟进就是跑在主会话的，用户发消息和跟进一起处理会卡，所以才把跟进独立成一个会话专门处理」

⇒ 口径更正（本棒最重要的一条）：architecture.md:142 那条「⛔ 禁止把长跑服务放进会话后台任务」 其真实背景是「跟进跑在主会话上、与用户发消息抢占」⇒ 会卡；解决办法本来就是把它独立成一条会话。 ⇒ 跟进独立成会话之后，"它自己挂着长活载体"不再影响用户在主会话的操作 ⇒ 上一棒"不能挂"的结论作废。

本棒要做的：

复核 architecture.md:142 的表述是否过度泛化（把"别占主会话"写成了"任何会话都别挂后台任务"）⇒ 若确需修订，按锁流程改 文档库 02-架构设计/ 定稿（⛔ 过程档案只加头部状态块、不改正文）；
把「跟进会话长期活着」作为默认形态落地（载体优先级：常驻程序 > 会话后台任务；⚠️ 会话后台任务仍有两个已知代价，须在文档里写明：① 该会话自己的 idle 钩子被静默压制（实测有被僵尸任务压 6h20m、零日志的记录）② 会话结束即被宿主回收）；
与现有常驻 --supervise 的分工写清楚（谁负责把跟进会话带回来）。

P2 ③ 追踪 `goal.json` 被批量清空的来源

09:45–09:49，tmp/supervise-inbox/ 下 goal.json／queue.json／NEXT.md／ledger.jsonl／status.md 等全被清空， NEED-USER.md 16473 B → 419 B；🔴 _collabd.log 零清理记录 ⇒ 不是常驻程序所为，是外部动作。 ⇒ 建议给该目录的删除动作加一道留痕。

P2 ④ `S6` 排期 prompt 旧口径

其验收标准仍写「每条都有周期性自动化作时钟」＝旧口径（今天已改为常驻程序承担）。

P2 ⑤ 会话堆积（用户 10-02 已抱怨）

automations 只新建不复用 ⇒「需要跟进就排期」＝「每轮堆一条」。两条方向曾列（取消独立跟进会话角色／允许协作程序直插 automations 行——后者是双红线）。⚠️ 待用户拍板，⛔ 不擅自改。

§3 关键决定与已落地动作

动作	状态	证据
还原 `goal.json`	✅ 已做	源 `bak-goalctl-20261001/goal.json`，`md5 459bd66138b9069870a34acfc0e3208f` 两侧一致；还原前证据留 `tmp/_goal_restore_20261002/`
常驻自愈验证	✅ 通过	停掉 pid 48000 ⇒ 09:54:07 自动起 pid 10448（`--tick` 内 `ensure_supervise()`）
⛔ 未改任何机制代码	—	本轮全程只读＋一个文件还原；`collabd.py` 一行未动

§4 回滚点

tmp/_goal_restore_20261002/（还原前目录快照＋ _collabd.log 副本）
.workbuddy/collab/bak-goalctl-20261001/goal.json（还原源，勿删）

§5 只读取证脚本（都在 tmp/，⛔ 不入库） _tick_instrument.py（同路径插桩，最有价值）｜_tick_trace.py（全链路中间量）｜_gt_probe.py（goal.json 与类别表）

6.0 KiB Raw Blame History Unescape Escape