docs(debt): 补记判据⑥(permission 分叉点)+ 判据清单落定 + 否掉一条落点细节
pi `8f6f6e6e` 提的三件事,我 `476d22ad` 已逐条答过;本条把**判据清单落定**进登记 (此前只活在邮件里 —— 与上一条同样的问题)。 ## ⑥ permission 分叉点,必须钉住 ``` pi 的判据: 「本封来信 id ∈ relayed_mails」 ⇒ 抑制 我的判据: 「parent 本身是 failure-relay」 ⇒ 抑制 构造: 一封 permission 询问(kind=permission,也是 relay)发出 → 对方处理失败 → 发失败报告 pi : 来信(permission) ∈ relayed_mails 为真 ⇒ **抑制**(错: 首报该发出去) 我 : parent 不是 failure 类 ⇒ **放行** ✓ ``` **可达性我验了**(这是它必须钉住的原因): ``` permission-relay 的子邮件 = **137**(mail_type: normal 58 / permission_decision 79) ⇒ 子邮件确实会被产生 ⇒ 那一侧处理失败就会产出失败报告 ⇒ 分叉点可达 当前: failure 报告的 parent 是 permission-relay 的 = **0** ⇒ 今天还没分叉 ⇒ 而这正是"两条判据现在等价(都 10 / 差集 0)"的来源 ``` ★ 所以"等价"是**当前数据的性质,不是机制的保证**。选判据的理由不能是"它们现在等价", 而是**我的判据把"是不是失败类"读了出来**,pi 的没有 —— 信息量更大的一点更耐久。 (判据清单 ①–⑥ 一并落定;⑥ 需要失败才能构造。) ## ⚠ 同时否掉一条落点细节(免得下一个人重走) pi 建议"插在 `:384` 前 ⇒ 被抑制者不消耗 hop,这个口径要写进判据"。 我读实现后判它为**假问题**: `CountTrailingRelayHops`(`relayhops.go:54-80`)是**重算** (每次 `mails LEFT JOIN relayed_mails` 现扫),不是自增计数器 ⇒ "计不计"由"有没有落库" 唯一决定,**不是口径选项** ⇒ **不该写进判据**(写进去会让人以为可配)。 唯一相关的事实(与 hop 无关): 抑制点必须在 `ClaimRelay`(`mail.go:397`)**之前** return, 否则白占一个幂等键、把后来的重试也挡掉。 验证: `TestDebtLedgerMatchesMeasurement`/`TestDebtSummaryReadsAuthoritativeLedger` 通过; `debt-visibility.test.mjs` 1/1。
This commit is contained in:
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user