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/ 知识文件，按口径入库）
7.1 KiB
投递链路 · 错名修复 与「跟进会话长活」口径落地（复核单）
- 线名：多会话协作机制 · 投递链路（「投不进跟进会话」）
- 本棒：会话名
投递链路真因修复｜ 2026-10-02 10:0x–10:3x - 上游：
接续包_投递链路真因_20261002.md（md5fe714700f43a9ad3c9f6de6ef3c1fd6a，开工前重算一致 ✅） - 锁：改机制层 ⇒ 全程持全局独占锁，收口已释放（
--release-exec回执「已释放全局执行锁」）
一、结论
- P1① 已修 —— 投递「错名」：
_deliver_str把follow_for_topic()已经算准的why丢掉了， 把「有跟进会话、只是都不在跑」记成no-follow-session（字面与事实相反）。 ⇒ 已改为透传why，follow-not-live与no-follow-session分开记档；喊用户文案同步分档。⛔ 只改可读性，未改行为。 - P1② 已落地（文档层） —— 按用户 2026-10-02 09:59 口径更正：那条「⛔ 禁止把长跑服务放进会话后台任务」 属过度泛化；真因是跟进当时跑在主会话上、与用户发消息抢占轮次，而解法本来就是把它独立成一条会话。 ⇒ 跟进独立之后，它自己挂长活载体不再影响用户 ⇒ 允许，「跟进会话长期活着」＝默认形态已写入唯一权威文档。
二、P1① 改了什么（collabd.py）
| 项 | 内容 |
|---|---|
| 落点 | ~/.workbuddy/skills/session-mechanism/scripts/collabd.py，原 _deliver_str 的 if g is None: 分支 |
| 改法 | _why = _rft.get("why") ⇒ info["skipped"] = _why；加兜底（值不在两个已知档时按 _want 是否为空回退）⇒ ⛔ 不制造新档位 |
| 文案 | 按 why 分档；no-follow-session 再分「一条 [跟进] 都没有」与「有 N 条、但都不属这个类别」（旧文案对第二种会撒谎） |
| 改前依赖核查 | board.py 零命中（仅 board.html 注释提函数名）｜goalctl.py:581-583 两值都已登记（⛔ 无未登记值风险）｜selftest.py:1006 断言两串仍在源码里 ⇒ 不破 |
自证：selftest.py ⇒ PASS 47 / FAIL 0（新增 1 例）。
新增钉死用例：selftest.py::投递：错名修复 —— why 透传…（4 项）—— 临时替 follow_for_topic／need_user ＋ 补网关口令过 no-token 闸，构造「有候选·都不活」与「真·无候选」两种前提。
🔴 反证（防恒真假绿）：把修复临时回退成硬编码 ⇒ 该用例变红（PASS 46 / FAIL 1）⇒ 已还原并复跑回绿，TEMP-FALSIFY 残留 0。
只读现场取证（tmp/_why_probe_20261002.py，⛔ 不取锁、不投递）—— 今天这条路径仍复现：
_goal_topics() = ['会话协作自检','机制排查与修复']
_scan_follows() = sids=6 by_topic=['会话协作自检','机制排查与修复']
_live_sids() = 2 条
topic='会话协作自检' -> sid=- why='follow-not-live' cand=['57f58ecf'] all=6
topic='机制排查与修复' -> sid=- why='follow-not-live' cand=['6ab1463e'] all=6
topic='' -> sid=- why='follow-not-live' cand=['57f58ecf'] all=6
⇒ 这三个 follow-not-live 修复前都会被错记成 no-follow-session —— 与接续包 §1 的六层判读链完全吻合。
三、P1② 落地了什么（references/architecture.md，协作机制唯一权威）
用户原话（逐字）：「那是因为之前跟进就是跑在主会话的，用户发消息和跟进一起处理会卡，所以才把跟进独立成一个会话专门处理」
- ⚠️ 一处纠偏：接续包写「改文档库
02-架构设计/定稿」——实查D:\github\dsh_shenxian\dsh-server-docs\02-架构设计\只有 3 份（README／分库与权威存储／覆盖网络），没有协作机制定稿 ⇒ 真正的权威是技能内的references/architecture.md，改动落在这里。
| # | 改动 | 位置 |
|---|---|---|
| ① | 「当前结论」节加一行（跟进会话长期活着 ＝ 默认形态） | 表内（原第④类那行之后） |
| ② | 原那条禁令收窄对象：禁区＝「用户会在上面发消息的那条会话（主会话）」，⛔ 不是「会话后台任务」这个形态本身 | 原 :142 |
| ③ | 新增 §2.3.0e：默认形态 ＋ 载体优先级表（常驻程序 ＞ 会话后台任务）＋ 后台任务两个已知代价 ＋ 与 --supervise 的分工表 |
新节 |
| ④ | §4 那条禁令同步收窄（⛔ 防「同一事实两处打架」） | 原 §4「第四种」 |
顺手纠正同行一处过时表述：「第④类＝尚未落地（全库零命中）」⇒ 改为「✅ 解析层已落地（[跟进]⇒role='follow'）」。
新判据（一句）：「谁把跟进会话带回来」＝ 自动化（只有它能开会话）；「谁叫醒它、谁投给它」＝ 常驻投递。两者 ⛔ 不可互替 ⇒ 那条"带回来"的排期必须一直在册。 后台任务两个代价（已写明）：① 该会话自己的 idle 钩子被静默压制（实测被僵尸任务压 6h20m、零日志）② 会话结束即被宿主回收（历次 8/12/20 分钟）。
四、⛔ 未处置（下一棒 / 待拍板）
| # | 项 | 状态 |
|---|---|---|
| P2③ | tmp/supervise-inbox/ 下 goal.json／queue.json 等被批量清空的来源（_collabd.log 零清理记录 ⇒ 外部动作）⇒ 建议给删除动作加留痕 |
⛔ 未做 |
| P2④ | S6 排期 prompt 仍写「每条都有周期性自动化作时钟」＝旧口径（今已改常驻承担） |
⛔ 未做 |
| P2⑤ | 会话堆积：automations 只新建不复用 ⇒ 每轮堆一条（用户 10-02 已抱怨）；曾列两方向（取消独立跟进角色／允许协作程序直插 automations 行＝双红线） |
🔴 待用户拍板，⛔ 不擅改 |
| 新发现 | references/rules.md:44、collab-detail.md:788、pitfalls.md P1(613) 仍带同款过度泛化的"别用会话后台任务"表述（与本次修订后口径不一致）⇒ 属教训记录，按规矩应加状态块指向 §2.3.0e、⛔ 不改正文 |
⛔ 留给下一棒 |
| 记忆 | .workbuddy/memory/MEMORY.md 7,988 字符（上限 7,650）⇒ 本棒只做净减 5（原 7,993），🔴 仍超上限，需后续腾挪 |
⚠️ 已知 |
五、收尾自判 ⇒ 已派下一棒
tmp/supervise-inbox/advance.md：「可派 S5」＋「S7 在等 S5」；任务图 S5＝todo、
S6/S8/S9＝done、S7 唯一阻塞项就是 S5 ⇒ 收尾自判判定有缺口，已写一行 automations：
- 下一棒：
[协作]-[机制排查与修复]-S5 修主会话可响应 - id：
3872e203-18b9-4a28-8ff8-7b488345c997（只来自工具返回值） - 排期：一次性 · 收口 ＋ 4 分钟（
2026-10-02T10:31）｜工作区E:/ProgramData/AIProject/ai1net-dsh-server - 节点：S5「修：主会话可响应」（验收 V2；现状
--tick恒判target-deaf）⇒ 完成后派 S7（全量验收 V1–V7）