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/ 知识文件，按口径入库）
105 lines
7.2 KiB
Markdown
105 lines
7.2 KiB
Markdown
# 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` 三路取并集，
|
||
**任一路没完就是没完**。
|
||
- ⛔ 本轮**未替检查会话**改「目标生命周期」（那是检查会话的职责）。
|
||
|
||
（报告完 · 域锁已释放）
|