JianFeeeee
1ea92098d1
## 起因：修部署漂移时撞出来的
b0c8719（2026-09-30）给 `inboundHeadline` 加了 `parentFrom`/`selfName`，
用来分辨「回的是你那封」与「多方线索里的他人续谈」——单向续信链（8 封全是
对方发来的）同样满足 `in_reply_to`，不判方向就会被逐封宣称「回的是你那封」，
模型把它当新任务处理。**但只有 pi 桥接了**：
pi parentFrom: data?.parent_from ✓（turn.mjs:148）
dsh 从不传 ✗ 3 处
opencode 从不传 ✗ 1 处
判据函数是三个桥**同一份** relay-policy.js 的拷贝，看起来测过了 ——
但「函数支持」≠「调用方传了」。三个桥各自都有 relay-policy 单元测试且全绿，
因为它们只测那个**纯函数**，没有一个测「桥真的把参数传进去了」。
dsh 还多一层：它有一份**手写**的 `lib/relay-policy.d.ts`，缺这两个字段
⇒ tsc 报 TS2353 ⇒ 调用方即使想传也过不了类型检查。那行判据是被类型系统
**主动拦住**的死代码。只补 .js 不补 .d.ts 等于没补。
## 改动
dsh 3 处 + opencode 1 处调用点补 `parentFrom`/`selfName`，对齐 pi 的样板；
dsh 的 `.d.ts` 补声明（注释写明「光有声明不够，调用点也得传」）。
## 新增判据 deploy/check-parent-from.mjs（7 格）
不只是查「有没有传」，还查**三处曾经不一致的接缝**：
① 每个 inboundHeadline 调用点都传了 parentFrom（次数写死，新增调用点
忘了传要能被发现，而不是被 `>0` 静默接受）
② 传了 parentFrom 就必须传 selfName —— 只传前者时
`parentFrom === selfName` 永不成立，判据形同虚设
③ 三份 relay-policy.js 都真的有 `parentFrom === selfName`
④ dsh 的 .d.ts 声明与实现一致（否则 tsc 拦住，判据等于没有）
**变异验证**：撤一处传参 → 红 2；只撤 selfName → 红 1；撤 .d.ts 声明 → 红 1。
## ★ 判据自身也踩了两次坑（都已修）
1. 初版 `.d.ts` 那格用 `\bparentFrom\b` 全文件搜 ⇒ 撤掉字段声明后，
**注释文字里还留着这个词** ⇒ 照样匹配 ⇒ 变异不红（假绿）。
改为只认字段声明 `^\s*parentFrom\??\s*:\s*string\s*;`。
2. 初版 `.mjs` 写了 `require` ⇒ ReferenceError（ESM）。已改 import。
## 顺带修掉 6 个陈旧判据（都在 HEAD 上、此前静默红着）
`turn.test.mjs` 的「回信到达时明说不是新任务」：只造 `in_reply_to` 却断言
`/m-0/`，而 `b0c8719` 新增的「我的回复」分支文案里压根不含父邮件 ID ——
判据没跟上那次改动。已改成覆盖三种情形（parent_from 是我 / 是别人 / 缺席）。
★ 我第一版改完是**假绿**：只断言 `/续谈/` 时，把 `mine` 分支改坏也会走
「续谈」分支而照样通过。加反向断言（mine 不含「续谈」、theirs 不含
「不是新任务」）后才抓住。变异 A/B 各 35 pass / 1 fail。
`cross-bridge-permission-routing.test.mjs`：zcode 的路径与目录还指向
`d09ef39` 已删的 `hooks/`、`mcp/` ⇒ ENOENT。zcode 确实**没有** 409 分支了
（移除执行类工具所致，非缺陷）⇒ `permanent: null` 表示不适用，并加反向
守卫：若 `src/` 里出现 `isPermanentFailure` 就红（防止前提变了却继续空转）。
`isPermanentFailure` 是 `lib/relay-key.js` 的通用网关辅助，与权限放行无关 ——
踩过一次：把 `lib` 加进扫描范围后对着共享辅助函数误报。
全量：pi 533 / opencode 364 / dsh 433，零红（此前 4 红）。
## 部署与端到端
pi / opencode / dsh 三个宿主均已部署；dsh 已真实收发验证：
[dsh-mail-bridge] 本轮不自动转发：来信方 pi 是 Agent…
[dsh-mail-bridge] new_mail -> 新会话 mail-8e8bf319…
39 lines
1.3 KiB
TypeScript
39 lines
1.3 KiB
TypeScript
export function addrName(addr: string): string;
|
||
|
||
export interface AutoRelayCtx {
|
||
fromHuman: boolean;
|
||
replyTo?: string;
|
||
}
|
||
|
||
export function autoRelayDecision(ctx: AutoRelayCtx): { relay: boolean; reason: string };
|
||
|
||
export interface ReplyInstructionCtx {
|
||
fromHuman: boolean;
|
||
replyAddress?: string;
|
||
}
|
||
|
||
export function replyInstruction(ctx: ReplyInstructionCtx): string[];
|
||
|
||
export interface InboundHeadlineCtx {
|
||
inReplyTo?: string;
|
||
/**
|
||
* parentFrom 是**父邮件的发件人**（服务端 parent_from）。
|
||
*
|
||
* ★ 2026-10-02 补：`.js` 早就认这两个字段（b0c8719 加的），但这份手写声明
|
||
* 没跟上 ⇒ TypeScript 报 TS2353，调用方**不敢传**，于是那行方向判据
|
||
* 在本桥上一直是死代码：单向续信链同样满足 in_reply_to，被逐封宣称
|
||
* 「回的是你那封」，模型把它当新任务处理。pi 桥是唯一接了的。
|
||
*
|
||
* 光有声明不够 —— 调用点也得传，见 src/index.ts 的三处 inboundHeadline。
|
||
* 两者缺一，判据都等于没有。
|
||
*/
|
||
parentFrom?: string;
|
||
/** selfName 是本方名字（收件方自己）；`parentFrom === selfName` 才是「我的回复到了」。 */
|
||
selfName?: string;
|
||
fromHuman: boolean;
|
||
catchup?: boolean;
|
||
reused?: boolean;
|
||
}
|
||
|
||
export function inboundHeadline(ctx: InboundHeadlineCtx): string;
|