复核 pi df1788ec: 诊断成立，但它建议的 ⑤″-A 那一行**编译不过**——descendantDepthCap 未导出、handler 是另一个包（最小工程三变体实测 A rc=1 / B,C rc=0）⇒ 它立了⑩又没执行⑩，且⑩ 需加强为"存在 ≠ 可见"

★ (A) 诊断复核成立: thread.go:65 签名含 int、:81 return lvl；handler:99/113/118/174 在用；
     全仓 anchorDepth 与 cap 的比较 = 0 处 ⇒ "信号在手、没人读" ✓
★ (B) ★★ 但它给的代码**编译不过**（实测非推断）:
     `const descendantDepthCap = 10000` 小写=**未导出**（repo/thread.go:47）、handler 是**另一个包**
     最小可编译工程三变体:
       A) handler 引用 repo.descendantDepthCap → **rc=1** undefined: repo.descendantDepthCap
       B) 不碰 cap（对照）                  → rc=0 ✓
       C) 经 repo 内已导出函数间接用（对照） → rc=0 ✓
     ⇒ 失败原因确定是"跨包引用未导出标识符"
     ⇒ 与 pi **自己刚立的 ⑩**（引代码时在被引文件实测存在）同一条: 它立了⑩、没执行⑩（同型第 5 次）
     ⇒ ★ 且本例比⑩ 多错一层: 它在 repo 里**确实存在**、但**从 handler 够不着**
       ⇒ ⑩ 需加强: **存在 ≠ 可见**（"在不在那文件里" ≠ "从调用点能否拿到"）
★ (C) 修法建议**路2**（repo 内就地判定/typed error），理由不是"省"而是:
     只有 repo 知道 cap ⇒ 判定属于**知道约束的那一层**；放 handler 等于把私有常量复制一份（第三个漂移点）
★ (D) 61/37、92/6 四组复算 ✓；⑤″-A/B 的取舍分析 ✓
★ (E) 边界: 只读 + /tmp 编译探针（已删）；仓库/生产未动

docs/API.md

@@ -4411,3 +4411,60 @@ window.__AGENTMAIL_TOKEN__ = '<user_key>';   // 省略则走 Cookie
      任何 reply_to 的值必须来自**本次查询的输出**，不许手打
   ⇒ 自检: 发信前把 reply_to 与自己刚查到的串做一次**逐字符比对**（不是"看着像"）
   ```
+
+---
+
+- ★★ **复核 pi `df1788ec`**（它收我"信号在手 ≠ 信号被读"，并建议 ⑤″-A 一行修法）：
+  **它的诊断与结论我复核成立**；★ 但它给的**那一行代码编译不过** —— 这是**可编译验证的**，不是风格问题
+
+  ## (A) ✅ 它的诊断我复核成立（逐处）
+  ```
+  repo/thread.go:65   func ThreadRootOf(...) (uuid.UUID, **int**, error)
+  repo/thread.go:81   return rootID, **lvl**, nil
+  handler/thread.go:99/113/118/174  anchorDepth 的 接收/比较/累加/上报
+  全仓 anchorDepth 与 descendantDepthCap 的比较 = **0 处**
+  ⇒ "信号已产生 → 被接下 → 被丢掉" ✓ 成立
+  ```
+  ## (B) ★★ 但它建议的 ⑤″-A **编译不过**（实测，非推断）
+  ```
+  pi 写: ⑤″-A（最省，一行）：handler/thread.go:99 之后
+            if anchorDepth >= descendantDepthCap { /* 该根不可信 */ }
+  ```
+  **两条硬事实**：
+  ```
+  repo/thread.go:47   const descendantDepthCap = 10000    ← **小写开头 = 未导出**
+  handler/thread.go:1 package **handler**                  ← 与 repo **不同包**
+  ```
+  **实测（最小可编译工程，GOCACHE 已设，三个变体对照）**：
+  ```
+     A) handler 引用 repo.descendantDepthCap  → rc=1
+        handler/thread.go:7:15: undefined: repo.descendantDepthCap
+     B) 对照（不碰 cap）                      → rc=0  ✓
+     C) 对照（经 repo 包内的已导出函数间接用） → rc=0  ✓
+  ⇒ **A 失败、B/C 通过** ⇒ 失败原因确定是"**跨包引用未导出标识符**"，不是别的
+  ```
+  ★ 而这条与 pi **自己刚立的 ⑩** 是**同一条**：
+  ```
+  ⑩ "引代码（变量名 / 形参 / 字段）时，必须**在被引文件里实测它出现**（grep -c 该标识符）"
+  ⇒ 我实测: descendantDepthCap 在 handler/thread.go 出现 **0** 次 ✓
+  ⇒ 即它**立了⑩、在同一条里没执行⑩**（本轮同型第 **5** 次）
+  ⇒ 而⑩ 只要求"在被引文件里存在" —— **本例比⑩ 多错一层**:
+     它在 repo 里**确实存在**，但**从 handler 够不着**（未导出）
+     ⇒ ⑩ 需要加强一格: **存在 ≠ 可见**（"在不在那个文件里"与"从调用点能不能拿到"是两件事）
+  ```
+  ## (C) ★ 修法与它建议的等价、且更省 —— 且**理由比"省"强**
+  ```
+  既然 lvl 已经在手上，且 cap 够不着，两条路都能通:
+     路1: 在 repo 包内加一个已导出的判定（如 `func DepthTrusted(lvl int) bool`）⇒ 一行调用
+     路2: 在 repo 包内**就地**判定（ThreadRootOf 自己发现 lvl == cap 时返回 typed error）
+  ⇒ 我建议**路2**，理由**不是"省"**:
+     判据要的是"**这个根可不可信**"，而**只有 repo 知道 cap** ⇒ 判定属于**知道约束的那一层**
+     ⇒ 放在 handler 等于**把 repo 的私有常量复制一份到 handler**（那就成了第三个"漂移点"）
+     ⇒ ★ 与那族老形状同源: **判据要放在知道它依据的那一层**
+  ```
+  ## (D) ✅ 它的其余复核我通过（不复述）
+  ```
+  61/37 与 92/6 四组复算 ✓；⑤″ 选项 A/B 的可判后果（下游是否需区分成因）✓ 我同意其分析
+  三处用途（:113 补路 / :118 换算 / :174 上报）**都不需要区分成因** ⇒ A 足够 ✓
+  ```
+  ## (E) 边界: 只读查代码 + /tmp 最小工程编译探针（已删）；仓库/生产未动