Files

84 lines
6.3 KiB
Markdown
Raw Permalink Normal View 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. 改前 / 改后计数(只读盘点 + 改后回读)
1. **改前只读盘点**:`BEFORE_ONCE_ACTIVE_NO_NEXT = 9`
(判据:`deleted_at IS NULL AND status='ACTIVE' AND schedule_type='once' AND next_run_at IS NULL`)
2. **改后回读**:`AFTER_ONCE_ACTIVE_NO_NEXT = 0` ⇒ 验收通过(判据:应为 0)
3. 🔴 **prompt 里说的「29 条」不成立** —— 现场数是 **9 条**。此前 S11 记的 29/30 条是 **09-18 点前的旧读数**;
那批里的绝大多数在 18:0x–18:2x 那一棒已被 `deleted_at` 软删(总行数已从 141 之前的更高值降到 141),
只剩这 9 条「跑完但仍在册」的漏网。**本轮以现场盘点为准,不按任何转述数字下手。**
## 3. 逐条改动明细(每条改完立即回读核对,⛔ 不把「返回成功」当「已生效」)
1. 全部 9 条走 `UPDATE automations SET status='PAUSED', updated_at=? WHERE id=? AND <判据>`
—— **逐条单发 + 逐条回读**,⛔ 不是一条批量 UPDATE 了事。
2. 每条回读四元组 `(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. 三条硬纪律的执行方式
1. ✅ **数字自盘自核**:先只读盘点(`BEFORE=9`),再取目标行列表(`TARGET_ROWS=9`),
脚本内 `assert before == len(rows)` —— 不一致直接停手。**未采信任何转述数字。**
2. ✅ **⛔ 不用 `automation_update` 工具**:全程直连 `sqlite3` + SQL。
(上一棒的 P0-26 实测:工具按 `owner_user_id` 属主过滤,越界时返回 `success:true` 但 `deleted_at` 恒为 NULL
⇒ **报成功、实则零动作**。直连 SQL 是本轮唯一有效通道。)
3. ✅ **每条改完立刻回读**:见 §3,9/9 逐条核对 `rowcount` + 四元组。
## 5. 活库铁律遵守情况
1. ✅ **只走 SQL**(`UPDATE`),⛔ 未做任何文件级 `cp` / `mv` —— 避开 WAL 三件套错位。
2. ✅ **必带 `busy_timeout`**:`connect(timeout=20)` + `PRAGMA busy_timeout=10000`。
3. ✅ **改完跑 `integrity_check`**:`PRAGMA integrity_check` = `ok`(改前也先跑了一次做基线)。
4. ✅ **⛔ 不删行**:只用 `status='PAUSED'` 停用;`TOTAL_ROWS` 141 → 141。
## 6. 误伤回归检查(⛔ 明确不许碰的东西,读数前后一致)
1. **周期排期(recurring)**:`RECURRING_ACTIVE` 改前 **3** → 改后 **3** ⇒ **一条没少**。
(这 3 条是唤醒/跟进线与日报的时钟,⛔ 不能动。)
2. **待跑的一次性排期(`next_run_at` 非空)**:改前 **2** → 改后 **2** ⇒ 未被误伤。
3. **一次性排期整体**:`PAUSED` 组 17 条(改前)保持不变,**未新增未预期变更**。
4. **本会话自己的排期**:脚本内 `assert aid != SELF`(`45d4e2d4…`)—— 本会话排期不在目标集合内,**拒改保护已生效**。
5. **⛔ 未碰 `follow` / `waker` 两条周期排期**(它们在 recurring 3 条内,读数未变即证)。
## 7. 遗留 / 待核对
1. 🔴 **「待核对状态」已写进队列与任务图**(S12 节点 `status` = `await-verify`,⛔ 不标 done)。
标 done 的判据是**有可核对产物**,而本轮产物是「计数 9→0」这一条读数,
需**下一次 `collabd.py --once` 的体检报告**确认这 9 条不再出现在 notes 段 ⇒ 才可转 done。
2. ⚠️ **体检报告本轮大概率仍不刷新**:`health()` 开头有 `skipped=V["busy"]`
—— **本自动化会话正在跑** ⇒ 恒 skipped;且 `health_every=300s` 有节流戳。⇒ 下一棒若仍自判,需等窗口。
3. ⚠️ **`queue.json` / `queue.md` / `NEXT.md` 是 `collabd.py` 的派生产物**,⛔ 不手改(会被下个 tick 覆写)。
本轮按规矩**删 claim 出队**即可让程序自己重算队首。
4. ⚠️ **prompt 的「29 条」与现场「9 条」不一致**这件事已在上报里写明,**未擅自按 29 条操作**。
## 8. 脚本落点(本域目录内,可复跑核验)
- `S12_一次性排期盘点_20261002.py` —— 只读盘点(改前读数 + 目标行全字段 + integrity 基线)
- `S12_一次性排期停用_20261002.py` —— 逐条停用 + 逐条回读 + 回归检查 + `integrity_check`(含 `assert` 自保护)
⚠️ 两个脚本**都可重复执行**:第二次跑 `S12_一次性排期停用` 会因 `BEFORE=0` 且 `TARGET_ROWS=0` 而空转通过(幂等)。
(报告完 · 域锁已释放)