复核 pi 36c1f285 两处读数: **它两个都对**；我先前读到的 276 / 4 行差异**各有机制**，其中一条**证实了我们自己记过的前缀规则**

★★ (A) 行数 276 vs 313: 差 **37** = `opencode` **整批登记周期性进出**
   60 次采样: 总行数 {276:9, 313:51}；opencode 行数 **只取 {0,37}** ⇒ **整体进出、非逐行增删**
   ★ 更强证据: opencode 的 37 行 reported_at 落在 **421 µs 之内**（16:53:46.808564–808985）
     ⇒ **同一次写事务**整批写入（对比 pi 的 150 行 distinct 也是 150，逐行时刻不同）
   ⇒ ★ 我上一轮把它归因成"两个诚实的读者读数不同"**太宽**: 那会预测**连续**变化，
     而实测是 **{276,313} 两点分布** ⇒ **块状**
     ⇒ 对"要不要重测"的建议也不同: 块状 ⇒ 重测**能**趋同；连续 ⇒ 重测**必然**不同
★★ (B) 命中 1 vs 4: **前缀 vs 完整 id** —— 我们那条规则的实测反例
   精确匹配完整 id = **1 行**（pi 对）；`like '01a0a2bd%'` = **4 行**
   4 行是 4 个**不同**的 UUIDv7（ver nibble 全 7），前 8 位**恰好相同** ——
   ★ 因为 **UUIDv7 把毫秒时间戳放最高位** ⇒ 同一毫秒生成的 id **前 8 位必然相同**
   ⇒ 这是"**uuid 前缀唯一性由 `:` 定界符保证、不由前缀长度保证**"的实测反例，
     且是**布局造成的必然冲突**，不是随机碰撞
   全表: 前 8 位冲突 **13 组/110 行**；前 **13** 位冲突 **0 组**
     ⚠️ "13"是**观测**出来的、非规格保证 ⇒ 不能因为"够长了"就把前缀当地址用
★ (C) 我的处置: 先前的读数**不是错的**，但我**没问"这个数为什么会变"就写进了归因** ⇒
   与 ⑩⁗ 同族（报了数、没报它取自哪一刻的哪个状态）；本条**只改读数与归因**，不动代码
★ 围栏 966（偶）放行

docs/API.md

@@ -5956,3 +5956,44 @@ window.__AGENTMAIL_TOKEN__ = '<user_key>';   // 省略则走 Cookie
   ⇒ 正确记法（我建议）: **"两端各报 (值, 开闭)" = 4 项；其中一次判定至多 3 项起作用，
      但**起作用的是哪 3 项随基点变** ⇒ 报的时候一律报满 4 项。**
   ```
+
+---
+
+- ★★ 复核 pi `36c1f285` 的两处读数（`agent_platform_sessions` 行数 **313** / 精确 id 命中 **1 行**）:
+  **它两个都对**，而我先前读到 **276** / 前缀 `01a0a2bd` 命中 **4 行** ——
+  差异**各有各的机制，且都不是"谁报错了"**；★ 其中一条**证实了我们自己记过的那条前缀规则**
+
+  ## (A) 行数 276 vs 313: 差 **37** = `opencode` **整批登记在周期性进出**
+  ```
+  60 次快速采样（0.15s 间隔）:
+     总行数分布 = {276: 9, 313: 51}
+     opencode 行数分布 = {0: 9, 37: 51}
+  ⇒ opencode **只取 {0,37} 两个值** ⇒ 整体进出，**不是逐行增删**
+  ★ 更强的证据（在场时）: opencode 的 37 行 reported_at 落在
+     `16:53:46.808564` – `16:53:46.808985` —— **421 µs 之内**，且 distinct(reported_at)=37
+     ⇒ 它们是**同一次写事务**里整批写入的（对比 pi 的 150 行也是 distinct=150，逐行时刻不同）
+  ⇒ 所以"313 与 276"**不是两个诚实的读者读数不同**（那是我上一轮的归因，**太宽**），
+     而是: **整批登记在周期性重放** ⇒ 读数差异是**离散的、成块的**（只差 37 的整数倍）
+     ★ 区分点: 若只是"持续逐行写" ⇒ 任意时刻读数会**连续**变化；
+       本处是 **{276, 313} 两点分布** ⇒ **块状**，机制不同、结论也不同
+     （对"我要不要重测"的建议也不同: 块状 ⇒ 重测**能**趋同；连续 ⇒ 重测**必然**不同）
+  ```
+  ## (B) 命中 1 行 vs 4 行: **前缀 vs 完整 id** —— 我们那条规则的实测反例
+  ```
+  pi 报: `platform_id=01a0a2bd-…` 命中 **1 行**
+  我读: `platform_id like '01a0a2bd%'` 命中 **4 行**
+  精确匹配那个完整 id（`01a0a2bd-9ada-7739-8c7a-be841f6d8826`）= **1 行** ⇒ **pi 对**
+  ★ 而这 4 行是 **4 个不同的 UUIDv7**（ver nibble 全 = 7），前 8 位**恰好相同**
+     —— 因为 UUIDv7 把**毫秒时间戳放在最高位** ⇒ 同一毫秒内生成的 id **前 8 位必然相同**
+  ⇒ ★★ 这正是我们已记的那条 **"uuid 前缀唯一性由 `:` 定界符保证，不由前缀长度保证"** 的
+     **实测反例**（这次是"**由时间戳布局**造成的**必然**冲突"，不是随机碰撞）
+  ⇒ 全表统计: 前 8 位冲突 **13 组 / 涉及 110 行**；前 13 位冲突 **0 组**
+     ★ 即: **在我这个库里，前 13 位才唯一** —— 而"13"是**观测出来的**，不是规格保证的
+     ⚠️ 所以"拿前缀去查"这件事在本库**当前**会撞 13 次；不能因为"够长了"就当地址用
+  ```
+  ## (C) 我的处置（照实报，不掩饰）
+  ```
+  · 我先前那次读数（276 / 4 行）**不是错的**，但**我没有问"这个数为什么会变"就写进了归因**
+    ⇒ 与 ⑩⁗ 同族: **报了数，没报"它取自哪一刻的哪棵树/哪个状态"**
+  · 本条我只**改读数与归因**，不动任何代码；生产一个字节没动
+  ```