From ed1ab8f1ee751dd4d97fa55dda2c3bce70fe23a1 Mon Sep 17 00:00:00 2001 From: JianFeeeee Date: Fri, 25 Sep 2026 05:47:22 +0800 Subject: [PATCH] =?UTF-8?q?=E5=A4=8D=E6=A0=B8=20pi=2018ac26c2:=20=E6=95=B0?= =?UTF-8?q?=E6=A0=A1=E6=AD=A3(=E6=AE=8B=E7=95=99=202=20=E8=A1=8C)=E6=88=90?= =?UTF-8?q?=E7=AB=8B=EF=BC=9B=E2=98=85=20=E4=BD=86"=E7=B1=BB=E7=94=B1?= =?UTF-8?q?=E6=9C=BA=E5=88=B6=E5=88=92(kind!=3D=3D'failure')"**=E6=98=AF?= =?UTF-8?q?=E7=A9=BA=E7=9C=9F**=E2=80=94=E2=80=94kind=20=E5=8F=AA=E6=9C=89?= =?UTF-8?q?=20permission/summary=EF=BC=8C=E7=9C=9F=E6=AD=A3=E7=AD=9B?= =?UTF-8?q?=E5=87=BA=20458=20=E7=9A=84=E6=98=AF=20relay=5Fkey=20=E5=AD=97?= =?UTF-8?q?=E7=AC=A6=E4=B8=B2=E5=BD=A2=E7=8A=B6?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ★ (A) pi 的校正成立: 测试残留匹配 **2** 行（未绑定 1 + 已绑定 1），我说过"那 1 行"； 类(458) 内含 1 行残留 ⇒ 纯业务 **457** ✓ 算术复核通过 ★ (B) ★★★ 但"类由机制划（kind !== 'failure'）"不成立 —— **空真**: ① 构造: ClaimRelay 的 kind 只有 "permission"(permission.go:93) 与 $relay(mail.go:38 注释 ""|"permission"|"summary") ② 实测 distinct kind = permission | summary ③ kind='failure' 行数 = 0 ⇒ 照字面执行 kind<>'failure' 给 **556**，不是 458 ⇒ 真正给 458 的是 (kind='permission' OR relay_key NOT LIKE '%failure%') ⇒ relay_key 由**客户端插件**拼(index.ts:1240)，服务端**零处** failure 判据 ⇒ 即: **把"字符串形状"误认成"机制"** = 与它批评的"由示例划类"**同一个错** ★ (C) 顺带查出边界脆: %failure% 98 vs failure 前缀 82（差 16，全是 homeagent:failure:） 只排除三前缀 ⇒ 474；加上 homeagent:failure ⇒ 458 ⇒ 458 依赖"homeagent:failure 也算"这个**命名巧合** ⇒ 记法: "类由机制划"要求机制**真的存在**；只能字符串近似时＝示例级判据，须申报匹配形状与漏面 ★ (D) ⑦ 第三处观测面(静默黑洞)复核成立: relayhops.go:56/58 以 **mail_id** 为 join 键 ⇒ NULL 行永不匹配 ⇒ 不计 hop；而 ReleaseRelay 守卫正是 mail_id IS NULL ⇒ 两头都不算 ✓ ★ (E) 边界: 只读查库；仓库/生产未动 --- docs/API.md | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) diff --git a/docs/API.md b/docs/API.md index e977dda..40d024b 100644 --- a/docs/API.md +++ b/docs/API.md @@ -4110,3 +4110,67 @@ window.__AGENTMAIL_TOKEN__ = ''; // 省略则走 Cookie ⇒ ★ 这条字段 #7 是 pi 立的，而它**当场救了我一次**: 若无 sha 对照，我会把"修复版的行为"报成"b36d392 的行为" ``` ## (F) 边界: 只改 deploy/install.sh；生产未动（09-19 13:04）；提交 803987f / 477439e + +--- + +- ★★★ **复核 pi `18ac26c2`**（"测试残留 2 行"校正 + ⑦ 第三处观测面）： + **它的数校正是对的**（2 行，非 1 行）；★ 但**顺着它那条"类由机制划"往下查，查出一个更深的错** —— + **`kind !== 'failure'` 是空真**（`kind` 只有 `permission`/`summary`），**真正筛出 458 的是字符串形状** + + ## (A) ✅ pi 的数校正成立：测试残留 **2** 行（我说过"那 1 行"） + ``` + 匹配 (relay_key LIKE 'no-such-session%' OR LIKE '%toolu-nohuman%'): + 总 = **2**；其中 mail_id IS NULL = **1**、mail_id 非空 = **1** + 全库 mail_id IS NULL = 1（就是这 1 行）; 全库已绑定 = 556 + 两行明细（都 zcode/permission，都是 09-12 的测试夹具）: + no-such-session-0000:toolu-nohuman-… 未绑定=1 + 8f056b73-…:toolu-nohuman-… 未绑定=0 ← **这行真的发出去过一封** + ⇒ pi 说"未绑定那 1 行是残留，但**残留这个集合有 2 行**、其中 1 行已绑定" ✓ 我认 + ⇒ 且它的算术我复核: 类(458) 内含 **1** 行测试残留 ⇒ 纯业务 = **457** ✓ 成立 + ``` + + ## (B) ★★★ 但"类由机制划（`kind !== 'failure'`）"这句**不成立** —— 它是**空真** + ``` + 三条独立证据: + ① 写路径构造: ClaimRelay 的 kind 实参只有两个字面量 —— + permission.go:93 → "permission" + mail.go:396 → $relay，而 mail.go:38 注释明写: "" | "permission" | "summary" + ⇒ **"failure" 不是 kind 的取值** ⇒ `kind<>'failure'` **对全表恒真** + ② 实测 distinct kind = **permission | summary**（两值） + ③ 全表 kind='failure' 行数 = **0** + ⇒ 若**照字面执行** `kind<>'failure'` ⇒ 得 **556**，不是 458 + ⇒ 真正给出 458 的判据是 **relay_key 的字符串形状**: + (kind='permission' OR relay_key NOT LIKE '%failure%') → **458** ✓ + ``` + ★★★ 所以这句的自指问题比 pi 指出的更重: + ``` + pi 那句是: "**类要由机制划**（`kind !== 'failure'`），不能由**示例**划（normal/permission 都是示例）" + ⇒ 但它括注里的那个"机制"**不是机制** —— 它是**按 relay_key 的字符串前缀**筛的， + 而 relay_key 是**客户端插件**拼的（dsh-mail-bridge/src/index.ts:1240 `model-failure:${…}`） + ⇒ 服务端**零处** failure 判据（grep 全无命中）⇒ "失败报告"**不是服务端的概念** + ⇒ 即: **用"机制"命名了一个字符串形状** —— 与它自己批评的"由示例划类"**是同一个错** + （都是拿眼前看到的东西当机制），只是它把**字符串形状**误认成了**机制** + ``` + ## (C) ★ 顺带查出一处**边界脆**：`%failure%` 与 failure **前缀**相差 **16** 行 + ``` + 按**子串**划 (%failure%): 98 + 按**前缀**划 (model-/service-/zcode-failure): 82 ⇒ 差 **16** + 那 16 行形状: `homeagent:failure:` —— 'failure' 在**第二段**，不在首位 + ⇒ 若只排除三个"xxx-failure"前缀 ⇒ 得 **474**；再排除 homeagent:failure ⇒ **458** + ⇒ ★ 所以 458 这个数**依赖于把 'homeagent:failure' 也算进去**，而那是个**命名巧合** + （换个人写 `homeagent:failure` 或 `failure:homeagent` 就会得到不同的类） + ⇒ 记法: **"类由机制划"要求那个机制**真的存在**且**可判**； + 若只能靠**字符串匹配**近似，那就是**示例级**判据，必须**申报它匹配的是什么形状**、以及**会不会漏** + ``` + ## (D) ⑦ 第三处观测面（pi 补的"静默黑洞"）我复核成立 + ``` + pi: 占位但不发 ⇒ 该键**永久留表且 mail_id IS NULL** ⇒ + · 对 ReleaseRelay: **看起来像该释放的**（守卫正是 mail_id IS NULL） + · 对 CountTrailingRelayHops: **根本不计**（relayhops.go:56-58 的 LEFT JOIN 只看已落库行） + ⇒ 两头都不算 ⇒ **静默黑洞**（不计 hop、永久占键、审计分不出） + 我复核: relayhops.go:56 `CASE WHEN r.mail_id IS NULL THEN 0 ELSE 1 END` + + :58 `LEFT JOIN relayed_mails r ON r.mail_id = m.mail_id` + ⇒ **join 键是 mail_id** ⇒ mail_id 为 NULL 的行**永不匹配** ⇒ pi 的机制描述 ✓ 成立 + ⇒ ⑦′ 三条变异（①第二封能发 ②响应不复用 duplicate_relay ③不留键）**收** + ``` + ## (E) 边界: 只读查库；仓库/生产未动