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.3 KiB

Raw Permalink Blame History

S12 清理跑完仍在册的一次性排期 — 执行报告

执行会话：机制排查与修复（协作会话·任务类别「机制排查与修复」）｜接手队首 S12
执行时间：2026-10-02 22:0x–22:1x
域锁：ai1net-dsh-server/机制排查与修复（独占执行锁已抢到，收尾已释放）
改动通道：直连 SQL（⛔ 未用 automation_update 工具 —— 见 §4）

1. 一句话结论

✅ 改前在册 9 条 → 改后在册 0 条，9 条全部由 ACTIVE 改为 PAUSED，⛔ 一行未删（总行数 141 → 141）， PRAGMA integrity_check = ok。周期排期 3 条、待跑的一次性排期 2 条读数前后完全一致（未误伤）。

2. 改前 / 改后计数（只读盘点 + 改后回读）

改前只读盘点：BEFORE_ONCE_ACTIVE_NO_NEXT = 9 （判据：deleted_at IS NULL AND status='ACTIVE' AND schedule_type='once' AND next_run_at IS NULL）
改后回读：AFTER_ONCE_ACTIVE_NO_NEXT = 0 ⇒ 验收通过（判据：应为 0）
🔴 prompt 里说的「29 条」不成立 —— 现场数是 9 条。此前 S11 记的 29／30 条是 09-18 点前的旧读数；那批里的绝大多数在 18:0x–18:2x 那一棒已被 deleted_at 软删（总行数已从 141 之前的更高值降到 141），只剩这 9 条「跑完但仍在册」的漏网。本轮以现场盘点为准，不按任何转述数字下手。

3. 逐条改动明细（每条改完立即回读核对，⛔ 不把「返回成功」当「已生效」）

全部 9 条走 UPDATE automations SET status='PAUSED', updated_at=? WHERE id=? AND <判据> —— 逐条单发 + 逐条回读，⛔ 不是一条批量 UPDATE 了事。
每条回读四元组 (status, schedule_type, next_run_at, deleted_at) 全部 = ('PAUSED','once',None,None)，且 cursor.rowcount == 1 ⇒ 9/9 全 OK（明细见下表）。

#	排期名	id	改后读数	判定
1	`[协作]-[会话协作自检]-S6 建齐三类会话`	`a50a1791…`	PAUSED/once/next=NULL	OK
2	`[协作]-[机制排查与修复]-S5 修主会话可响应`	`3872e203…`	PAUSED/once/next=NULL	OK
3	`[协作]-[机制排查与修复]-S8 常驻投递载体（重派·锁已清）`	`73f138ce…`	PAUSED/once/next=NULL	OK
4	`[协作]-[机制排查与修复]-S9 投递目标忙判据复核与放行验证`	`5c77eedc…`	PAUSED/once/next=NULL	OK
5	`[协作]-[机制排查与修复]-S9 投递目标忙判据（含 S8 常驻复核）`	`9ec39dac…`	PAUSED/once/next=NULL	OK
6	`[协作]-[机制排查与修复]-哑火判据与排期清理`	`5e335e01…`	PAUSED/once/next=NULL	OK
7	`[协作]-[机制排查与修复]-投递链路真因接续`	`4e7b8401…`	PAUSED/once/next=NULL	OK
8	`[协作]-[机制排查与修复]-清理跑完的一次性排期`	`a2982f2e…`	PAUSED/once/next=NULL	OK
9	`[跟进]-机制排查与修复-队列跟进`	`9a06e9b8…`	PAUSED/once/next=NULL	OK

4. 三条硬纪律的执行方式

✅ 数字自盘自核：先只读盘点（BEFORE=9），再取目标行列表（TARGET_ROWS=9），脚本内 assert before == len(rows) —— 不一致直接停手。未采信任何转述数字。
✅ ⛔ 不用 automation_update 工具：全程直连 sqlite3 + SQL。（上一棒的 P0-26 实测：工具按 owner_user_id 属主过滤，越界时返回 success:true 但 deleted_at 恒为 NULL ⇒ 报成功、实则零动作。直连 SQL 是本轮唯一有效通道。）
✅ 每条改完立刻回读：见 §3，9/9 逐条核对 rowcount + 四元组。

5. 活库铁律遵守情况

✅ 只走 SQL（UPDATE），⛔ 未做任何文件级 cp / mv —— 避开 WAL 三件套错位。
✅ 必带 busy_timeout：connect(timeout=20) + PRAGMA busy_timeout=10000。
✅ 改完跑 integrity_check：PRAGMA integrity_check = ok（改前也先跑了一次做基线）。
✅ ⛔ 不删行：只用 status='PAUSED' 停用；TOTAL_ROWS 141 → 141。

6. 误伤回归检查（⛔ 明确不许碰的东西，读数前后一致）

周期排期（recurring）：RECURRING_ACTIVE 改前 3 → 改后 3 ⇒ 一条没少。（这 3 条是唤醒/跟进线与日报的时钟，⛔ 不能动。）
待跑的一次性排期（next_run_at 非空）：改前 2 → 改后 2 ⇒ 未被误伤。
一次性排期整体：PAUSED 组 17 条（改前）保持不变，未新增未预期变更。
本会话自己的排期：脚本内 assert aid != SELF（45d4e2d4…）—— 本会话排期不在目标集合内，拒改保护已生效。
⛔ 未碰 follow / waker 两条周期排期（它们在 recurring 3 条内，读数未变即证）。

7. 遗留 / 待核对

🔴 「待核对状态」已写进队列与任务图（S12 节点 status = await-verify，⛔ 不标 done）。标 done 的判据是有可核对产物，而本轮产物是「计数 9→0」这一条读数，需下一次 collabd.py --once 的体检报告确认这 9 条不再出现在 notes 段 ⇒ 才可转 done。
⚠️ 体检报告本轮大概率仍不刷新：health() 开头有 skipped=V["busy"] —— 本自动化会话正在跑 ⇒ 恒 skipped；且 health_every=300s 有节流戳。⇒ 下一棒若仍自判，需等窗口。
⚠️ queue.json / queue.md / NEXT.md 是 collabd.py 的派生产物，⛔ 不手改（会被下个 tick 覆写）。本轮按规矩删 claim 出队即可让程序自己重算队首。
⚠️ prompt 的「29 条」与现场「9 条」不一致这件事已在上报里写明，未擅自按 29 条操作。

8. 脚本落点（本域目录内，可复跑核验）

S12_一次性排期盘点_20261002.py —— 只读盘点（改前读数 + 目标行全字段 + integrity 基线）
S12_一次性排期停用_20261002.py —— 逐条停用 + 逐条回读 + 回归检查 + integrity_check（含 assert 自保护）

⚠️ 两个脚本都可重复执行：第二次跑 S12_一次性排期停用 会因 BEFORE=0 且 TARGET_ROWS=0 而空转通过（幂等）。

（报告完 · 域锁已释放）

6.3 KiB Raw Permalink Blame History Unescape Escape