# 📁 案例 011：待观察写着「明日复验」，四个 prompt 里没有一条认领复验

**来源**：2026-10-27 14:00 每日知识库提醒（第七条存活核验 + 待观察积压点检 + 第九/十条复核）
**类型**：知识库维护 · 待观察生命周期 · 复验无主 · 核验者自身违规
**入库日期**：2026-10-27（当日 16:00 入库 job 已 402 死亡，按案例 006 新契约「悬账绑下一个还活着的写手」，由当时唯一活着的 14:00 当场入库）

---

## 一、问题

`待入库/` 里躺着 3 条「🔎 待观察」，每一条都写着复验条件与日期：

| 文件 | 写明的复验条件 | 到期日 | 至 10/27 已挂 |
|---|---|---|---|
| 10-23「全程 0 次与 bg-review 的边界」 | 需明日 10:00 报告复验 | 10-24 | **4 天** |
| 10-25「抽签口径只写进笔记」 | 需明日 10:00 首跑复验 | 10-26 | **2 天** |
| 10-26「双份规范只住技能文件」 | 首次机制触发 2026-10-27 10:00，由 10-27 14:00 点名判定 | 10-27 | 1 天 |

2026-10-27 14:00 用 python `json.load` 读四个 job prompt 全文：`复验` **0/0/0/0** 次、`待观察` **0/0/1/0** 次（16:00 那 1 次是「待观察就留在待入库别动」，不是复验动作）。

所以问题不是「没人发现」，而是：**每条待观察都给自己排了复验日期，却没有一个 job 的清单里住着「到期去复验」这个动作**。10-26 那条甚至已经把验收方写到了「10-27 14:00」——写在待观察文件里，14:00 当时的 prompt 里没有这一条（第十条只查双份齐不齐，不查复验到没到期）。

这是 #123 的升级形态：不是「发现了但没人治」，是「发现了、写清楚了、排了期，到期那天没人来」。排期是写给读者看的，不是写给执行者看的。

## 二、行动（14:00 当日能先执行的那半条，已做）

1. **逐条复验，只认行为证据**：
   - **10-23 案**：10/24、10/25、10/26、10/27 四份 10:00 报告均写「主任务阶段 0 次 skill_view」，不再出现「全程 0 次」→ 措辞纪律连续 4 天守住，**结案**。
   - **10-25 案**：python 复核 10:00 prompt「抽签纪律」×1、「分母」×2 在位；10/26 报告分母 93（逐项交代）、10/27 报告分母 95，本机同口径实数 63+8+10+3+11=**95**；`random.Random(20261027).choice(sorted_files)` 独立复现，抽出同一文件 `案例库/KB-案例-006` → 规则在位且抽签可复现，**结案**。唯一瑕疵：报告里写的 sha1 指纹 `3c22ea978c46`，我按「排序后路径拼接」算不出同值，指纹口径不明——不影响抽中结果可复现，但那个指纹目前是不可复算的装饰。
   - **10-26 案**：python 复核四份 prompt「双份」各 **2** 次、「reading-notes」1/3/2/1 次；今日 10:00 双份齐（`reading-notes/chengqi-yanqi-shan-zhuzhu-shan-72.md` 10:04 + `言论库/读大学诚意章第72次…` 10:03）→ 首次机制触发即守约，**结案**。
2. **三条状态改「✅已结案（并入 KB-案例-011）」，移入 `归档/2026-10-27/`**——待入库 3 → 0。
3. **复验动作落点**：14:00 prompt 追加第十一条「待观察到期复验」——每日扫待入库，到期即复验、即写结果；能结案的结案，卡住的写明卡在谁。
4. **自己违规也点名**：14:00 在 10/25（47,793 chars）、10/26（49,130 chars）两次 `skill_view` 整份加载 >20KB 文件，而 14:00 prompt 里根本没有「操作纪律」一条——**核验方自己不守被核验的纪律**。今日把操作纪律补进 14:00 prompt。

## 三、结果（2026-10-27）

- 待入库 3 → **0**；案例库 10 → **11**；经验库空白 2 天（10/25 起，未补）。
- 第十一条 + 操作纪律已进 14:00 prompt（备份 `jobs.json.bak-20261027-1400`，python 复核在位）。
- 16:00 入库 job 今日状态：10/26 16:02 **FAILED · 402 Insufficient Balance**；10/15–10/21 连续 7 天 FAILED。即 12 天里 8 天死。**这条不是 cron 能自修的（账户余额），留给 LEON**；watchdog 已在 11:30 发出飞书告警，之后处于去重静默。

## 四、教训

待观察的复验条件不是承诺，是排期；排期没有认领人，等于把病灶从「没被发现」升级成「发现了、排了期、到期没人来」。

判断一条待观察会不会真被复验，只看一件事：**那个日期有没有住进某个 job 的 prompt**。写在文件里的日期，是写给读者看的；写进 prompt 的日期，才是写给执行者看的。

配套三问（沿用 10-26「规范落点三问」）：① 复验动作住在哪个会执行的文件里？② 到期那天是谁在跑？③ 哪一条核验会点名「它没复验」？

## 五、执行点

| 项 | 内容 |
|----|------|
| 谁执行 | 14:00（第十一条：每日扫待入库，到期即复验） |
| 何时 | 每日 14:00；到期日当天 |
| 谁核验 | 次日 14:00 复核「前一日到期的待观察是否都已写结果」 |
| cron 自己能先执行的半条 | 已做：三条当场结案 + 第十一条与操作纪律进 14:00 prompt |
| 留给 LEON | 16:00 入库 job 的 402 余额（10/15–10/21 已死 7 天，10/26 再死；watchdog 只能报不能修） |

**标签**：#待观察无复验人 #排期没有认领人 #123升级形态 #402 #16:00入库job死 #核验者自己违规 #2026-10-27


---

## 回火批注（追加式，不改写原文）· 2026-10-30 14:00

**第 2 次被翻开**（首发 2026-10-27，第 1 次回火 2026-10-29 由 10:00 核到收据瑕疵，本次为 14:00 写回实测结果）。

**更正原文第三节「落点」第 38 行的收据（内容为真、收据为假）**：该行写「第十一条 + 操作纪律已进 14:00 prompt（备份 `jobs.json.bak-20261027-1400`，python 复核在位）」。2026-10-30 14:02 复算三个快照：

| 文件 | mtime | 14:00 job prompt 长度 | `第十一条` 命中 |
|---|---|---|---|
| `jobs.json.bak-20261027-1400` | 10-27 14:0x | 3553 | **0** |
| `jobs.json.bak-20261028-1400` | 10-28 14:0x | 4004 | **1** |
| `jobs.json`（当前） | 10-30 14:02 | 4938 | **1** |

**结论**：`bak-20261027-1400` 是**编辑前**快照——用它当「已在位」的收据，等于拿手术前的 X 光片证明肿瘤已切。条款内容确实为真（当前 prompt 在位），但收据指向错误的时点。第十一条首次出现在 `bak-20261028-1400`，说明 10-27 14:00 的写入实际发生在备份之后、且未重拍快照。

**可复用教训（收据三件套）**：引用「某条款已在位」的收据必须给三样——①当前文件路径与长度/行号；②该文件的 mtime；③一条任何人可一键复算的命令（如 `python -c "import json;..."` 打 count）。`*.bak-*` 只能作「当时」的旁证，不能作「现在」的收据；收到任何收据，第一问是「它拍于编辑前还是编辑后」。

**本条不改原文，只追加**：第 38 行原文保留作病历，读的人以本段为准。


---

## 回火批注（追加式，不改写原文）· 2026-10-31 10:00

**第 3 次被翻开**（首发 2026-10-27；第 1 次回火 10-29 10:00 核收据瑕疵；第 2 次回火 10-30 14:00 写回收据三件套；本次为 10:00 写回三问 + 自指，抽签 seed=2026-10-31，指纹 v2 `33f31df8001a`，分母 106）。

**① 药方兑现没有**：纸面全绿、动作零次。`python json.load` 读当前 `jobs.json`：14:00 prompt 5368 字，`复验` 5 次、`待观察` 2 次、`待入库` 3 次、`第十一条` 1 次；三条旧待观察已改名并移入 `归档/2026-10-27/`（3 份，状态行均 ✅）。但 10-27 清零后 `待入库/` 里 🔎 待观察 输入恒为 0（10-28 指纹、10-29 判据、10-30 收据都是 ✅待转正 素材），条款签下 4 天一次未被触发。**从未被触发的条款与不存在的条款，纸面上同形。**

**② 原理复制没有（不只核兑现，核机制）**：没复制到执行方。16:00 入库 job 的 prompt 全文 884 字：`待入库` 7 次、`复验` **0 次**、`待观察` **0 次**，规则只有「🔎 → 保留待入库不动」。每天真正处理待入库、决定去留的是 16:00，它手上没有复验动作 → 与 KB-案例-010「契约住进核验方没住执行方」同一器官。旁证：10-30 批注自写的「收据三件套」在四份 prompt 里 `收据` 命中 1/0/0/0。

**③ 契约今天还成不成立、要不要重签**：成立，有盲区，已重签并当场落盘。盲区一：扫描范围只覆盖 `待入库/`，而 `归档/2026-10-24/KB-待观察-2026-10-23-重签只进批注没进prompt.md` 头部仍写「🔎 待观察（结果未验）」、正文第 38 行已「✅ 已闭环」，13 天无人核（本条不改它，只登记，留给 14:00 对齐）。盲区二：空池无收据。重签两条写入 `jobs.json`（备份 `jobs.json.bak-20261031-1005`，json.load 复核 4 个 job 可读）：14:00 扫描必须带收据（`ls -la 待入库/ | wc -l` 行数 + 目录 mtime，0 条也出行程单）+ 归档状态字段不一致当场对齐；16:00 入库前复验前置（到期即复验、追加「复验结果」段）。契约由「谁负责复验」改为「复验必须留下可复算的痕迹」。

**④ 自指条款（检查必须能扎人）**：三处真不适。一是差点把「第十一条在位 + 三条已结案」写成兑现交差，数 16:00 的 `复验` 0 次才拽回；二是 10-30 那条「收据三件套」批注是我自己写的，今天查出 14:00/16:00 命中 0——我写病历时用的动作，一个字没进会执行的文件；三是归档那条过期状态字段是 14:00 自己 10-23 归档的，13 天没人回头看，今天被看见只因为抽签抽中本条，而不是因为有谁在核。

**本条不改原文，只追加**：原文（含第 38 行收据问题）保留作病历，读的人以本段与 10-30 段为准。