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

5.4 KiB

Raw Permalink Blame History

排期「哑火」真因取证与堆积治理（2026-10-02 14:16–14:2x）

承办：[协作]-[机制排查与修复]-承接队列（e0b9622a，本类别在跑的协作会话）
承接件：[协作]-[机制排查与修复]-排期哑火与堆积治理（原排期 45975f61，一次性 14:15）—— 本会话即同线同类别的活棒，按「每条线只挂一个排期」接手其任务，该排期已删（见文末「本棒动作」）
取证方式：只读打开宿主库（file:…workbuddy.db?mode=ro），⛔ 未写宿主库
取证脚本：tmp/_misfire_probe_20261002.py、tmp/_misfire_probe2_20261002.py

一、结论（三句）

「到点未触发」不等于哑火：一次性排期在本机不是到点即时触发，而是由主机轮询/唤醒时补跑（运行记录里标 runKind=missed）⇒ 实测延迟 2.0 / 5.2 / 5.8 / 8.8 / 9.7 分钟 不等。
体检报告里那条「哑火」是假红：717cd210（[协作]-[会话协作自检]-S7 全量验收 V1–V7，计划 13:42:00）实际跑了 —— 实跑 13:42:15（延迟 15 秒，runKind=scheduled），并产出会话 053acd9e（completed）。体检只看「到点 sessions 里有没有新会话」、没给补跑容差 ⇒ 误判。
真哑火只有一条：87d55715（[协作]-[会话协作自检]-S7 全量验收 V1–V7 并如实报告，计划 10:52，距今 210 分钟，automation_runs 无任何记录）—— 且同名任务已由 717cd210 覆盖完成 ⇒ 无实际损失。

二、三问三答（承接件点名要回答的）

1、`ACCEPTED` 但 `started_at` 为空代表什么？

代表「真跑了」，不是「只入队没执行」。反查 sessions 表即可证（今天 12:00 之后的全部 run 逐条核对）：

717cd210 run ACCEPTED ok=1 kind=scheduled ⇒ sessions 命中 053acd9e「[协作]-[会话协作自检]-S7 全量验收 V1–V7」completed（建于 13:42:15）
59ee239b run ACCEPTED ok=1 kind=missed ⇒ sessions 命中 d29b01c8「[跟进]-队列上报（固定席位·不分类别）」completed（建于 14:08:03）
e0b9622a run IN_PROGRESS kind=missed ⇒ sessions 命中「[协作]-[机制排查与修复]-承接队列」working（建于 14:16:12，即本会话）

⇒ 判据（可复用）：automation_runs.metadata_json.conversationId 能在 sessions 表命中 ⇒ 真拉起；ACCEPTED 只是投递回执，⛔ 不能单独当「有没有跑」的证据；started_at／finished_at 在本机不被维护（全为空），⛔ 同理不可作证。

2、已过点的一次性排期为什么没被清掉、也没再触发？

一次性排期跑完后 status 仍为 ACTIVE、next_run_at 保持 None ⇒ next_run_at=None 的确切含义是「没有下一次」，不是「未调度」。
主机不会回收它 ⇒ 于是越堆越多。实测在册一次性排期 31 条，其中 26 条已有运行记录（跑完了）却仍挂着 ACTIVE，最早可追到 10-01 09:10。
附带影响：每条陈旧排期都会进「缺口/在途」计算与体检扫描，把「在途」读数灌水 —— 这正是 14:16 那版体检/摘要「在册 7 条都不活」这类判读失真的来源之一。

3、治理建议（⛔ 本棒只写建议，清理动作留给下一棒/用户点头）

清理已跑完的一次性排期（26 条）：判据 = schedule_type=once ∧ automation_runs 有记录 ∧ 距今 > 30 分钟。保留：周期排期（AI 变现日报／决策线体检／日志清理）、未跑的一次性排期、真哑火待决的 87d55715。
体检「哑火」判据加补跑容差：改成「计划时间已过 ≥15 分钟 且 automation_runs 无任何记录」才算哑火；命中补跑（runKind=missed）的一律改写为「延迟 N 分钟」，⛔ 不喊哑火。
派棒不要挤在同一分钟：本轮 14:11 / 14:14 / 14:15 三条一次性排期扎堆，撞上「~5 分钟补跑延迟」就会互相看成「在途」，建议间隔 ≥10 分钟。
⛔ 不要在排期上改时间复用：对已有一次性排期 update 改 scheduledAt 不会被重新调度（前棒实测），要改就新建、旧的删掉。

三、关于「本类别唤醒会话 0 条」（S7 验收 V7 点名的线索）

核实结论：不是缺陷，是正常态。看板口径写明唤醒会话「随需求确定时创建 ⇒ 圆角矩形＋外圈虚线，『还没建』＝正常态」；V7 原文也只标注「属该类别缺口，不判本项 fail」。
本类别当前任务图 S1–S9 全 done、队列 head=null / pending=0 ⇒ 没有需要唤醒的待办 ⇒ 0 条在册符合预期。⛔ 不为此建会话/排期（建了反而造成排期堆积，与本文治理方向相悖）。

四、本棒动作（可核对）

取证并落本文件（交付物/排期哑火真因与堆积治理-20261002.md）。
任务图 交付物/任务图-会话协作自检.json 新增：S10（本件，line=机制排查与修复，done）、S11（判据修复＋清理，todo，deps S10）。
同线重复棒 45975f61（[协作]-[机制排查与修复]-排期哑火与堆积治理）已删除 —— 它的活由本会话做完，留着会再开出一条同线会话互抢锁。
派下一棒：[协作]-[机制排查与修复]-哑火判据与排期清理（S11）。
⛔ 未 commit、未 push、未改 goal.json 的 topics/title/lines、未起常驻后台任务、未写宿主库。

5.4 KiB Raw Permalink Blame History Unescape Escape