fix(notify+四桥): ★ 投递通知带 parent_from（方向判据）—— in-reply-to-ignores-direction 转绿

为什么这次顺手修：网关部署门禁（redeploy-gateway.sh 跑全量 Go 测试）被
TestInReplyToCarriesParentSender 拦下 —— 那是 2026-09-28 判据先行的债，
死锁修复本身无涉，但不修它网关换不上去。已用 git worktree 在修复前的
HEAD（16bf474）上验证过该测试原本就红，不是本次改动引入。

服务端（数据本来就在手，零新增查询）：
  · resolveTarget 的 reply_to 分支原本把父邮件整行读进内存、只用 SessionID
    就丢掉；现在把 mail.FromName 一并返回。
  · notify.Mail 增 ParentFrom；payload 增 "parent_from"。
  · 转发 / 人类发信（me.go）路径如实传 ""（转发本就是新线索）。

四桥（relay-policy.js 四份逐字相同的拷贝 + 各自调用点）：
  · inboundHeadline 增方向判据：parentFrom === selfName 才说
    「你上一封信的回复到了」；parentFrom 非空但≠自己 ⇒ 明说
    「多方线索里的续谈（回的那封是 X 发的）」；服务端未升级（无
    parent_from）⇒ 退回旧行为（含糊的「回复到了」强于把真回复当新任务
    —— 那是互相客套的起点，回退语义被既有判据钉死）。
  · 「回的是你那封：<id>」一行同样只在父邮件确为本方发出时才输出。
  · 四份 lib + 四份 test 逐一 md5 相同（cross-bridge-prompt 1/2/3/4 继续绿），
    判据 5 转绿。

红绿：
  · 服务端 TestInReplyToCarriesParentSender 修复前红（16bf474 实测）、修复后绿；
  · 四桥新增 3 条方向判据测试（别人发的 / 自己发的 / 未升级回退）；
  · client/electron 聚合套件 cross-bridge-prompt 5/5 绿。

plugins/dsh-mail-bridge/lib/relay-policy.js

@@ -37,6 +37,8 @@ export function addrName(addr) {
  * 这一轮的结论该不该由插件自动转发出去。
  *
  * @param {object} ctx
+ * @param {string}  [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
+ * @param {string}  [ctx.selfName]   本方名字（收件方自己），用于方向判据
  * @param {boolean} ctx.fromHuman 来信方是人类用户（SSE 的 `from_human`）
  * @param {string}  [ctx.replyTo] 自动转发本来要发给谁
  * @returns {{relay: boolean, reason: string}}
@@ -65,6 +67,8 @@ export function autoRelayDecision(ctx) {
  * 而实际上那封信永远不会发出去，发件方一直等着。
  *
  * @param {object} ctx
+ * @param {string}  [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
+ * @param {string}  [ctx.selfName]   本方名字（收件方自己），用于方向判据
  * @param {boolean} ctx.fromHuman
  * @param {string}  [ctx.replyAddress] 服务端算好的回信地址
  * @returns {string[]} 若干行，直接拼进提示词
@@ -97,17 +101,36 @@ export function replyInstruction(ctx) {
  *
  * @param {object} ctx
  * @param {string}  [ctx.inReplyTo] 非空 = 这是对本方某封信的回复（SSE 的 `in_reply_to`）
+ * @param {string}  [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
+ * @param {string}  [ctx.selfName]   本方名字（收件方自己），用于方向判据
  * @param {boolean} ctx.fromHuman
  * @param {boolean} [ctx.catchup]  离线期间积压后补投的
  * @param {boolean} [ctx.reused]   投进一条已存在的会话（续谈）
  * @returns {string} 提示词第一行
  */
 export function inboundHeadline(ctx) {
-  const { inReplyTo, fromHuman, catchup, reused } = ctx || {};
+  const { inReplyTo, parentFrom, selfName, fromHuman, catchup, reused } = ctx || {};
   const who = fromHuman ? "" : "（对方是一个 Agent）";
   if (inReplyTo) {
     // 「回复到了」与「有人派活」是两种处境。说清楚它，模型才不会把
     // 一句确认当成新任务 —— 那正是互相客套的起点。
+    //
+    // ★ 还必须有**方向**判据（2026-09-30 修，in-reply-to-ignores-direction）：
+    // 只有 inReplyTo 时只能判断「这是回信」，分不清回的是**谁**的信。
+    // 单向续信链（8 封全是 opencode → pi）同样满足「有父邮件」，曾被逐封
+    // 宣称「回的是你那封」，把纯单向链读成双向对话。服务端现在在载荷里
+    // 带父邮件发件人（parent_from）；`parentFrom === selfName` 才是
+    // 「我上一封信的回复到了」，否则是多方线索里的他人续谈 —— 当新输入。
+    // 服务端未升级（无 parent_from）时退回旧行为，不比原来更差。
+    const mine = parentFrom != null && parentFrom !== "" && selfName != null && parentFrom === selfName;
+    if (mine) {
+      return `你上一封信的**回复**到了${who}。这不是新任务。`;
+    }
+    if (parentFrom != null && parentFrom !== "") {
+      return `这是多方线索里的**续谈**（回的那封是 ${parentFrom} 发的，不是对你上一封信的回复）${who}。`;
+    }
+    // 服务端未升级（无 parent_from）时退回旧行为：含糊地说「回复到了」
+    // 也强于让模型把一封真回复当新任务再处理一遍 —— 那是互相客套的起点。
     return `你上一封信的**回复**到了${who}。这不是新任务。`;
   }
   if (catchup) {

plugins/dsh-mail-bridge/test/relay-policy.test.mjs

@@ -125,6 +125,34 @@ test('续谈与新会话的措辞不同', () => {
   assert.match(inboundHeadline({ fromHuman: true, reused: false }), /你收到/);
 });
 
+
+test('★ 方向判据：父邮件是别人发的 ⇒ 不是「你上一封信的回复到了」（in-reply-to-ignores-direction）', () => {
+  // 生产兜现：压测线索 stress-thread-21863-15348，8 封全是 opencode → pi，
+  // pi 的投递通知却逐封宣称「回的是你那封」—— 没有一封是 pi 发出的。
+  // 单向续信链同样满足「有父邮件」⇒ 纯单向链被读成双向对话，Agent 把
+  // 「收到」当新任务客套到撞 hop 上限。
+  const h = inboundHeadline({
+    inReplyTo: 'm-1', parentFrom: 'opencode', selfName: 'pi', fromHuman: false,
+  });
+  assert.doesNotMatch(h, /你上一封信的\*\*回复\*\*到了/,
+    '父邮件是 opencode 发的，pi 不该被告知「你的回复到了」');
+  assert.match(h, /opencode/, '要说清父邮件是谁发的，模型才能判断处境');
+});
+
+test('★ 方向判据：父邮件是自己发的 ⇒ 仍是「回复到了」', () => {
+  const h = inboundHeadline({
+    inReplyTo: 'm-1', parentFrom: 'pi', selfName: 'pi', fromHuman: false,
+  });
+  assert.match(h, /回复/);
+  assert.match(h, /不是新任务/);
+});
+
+test('★ 方向判据：服务端未升级（无 parent_from）⇒ 退回旧行为，不比原来更差', () => {
+  const h = inboundHeadline({ inReplyTo: 'm-1', fromHuman: false });
+  assert.match(h, /回复/, '缺方向信号时不能把回信误报成新任务');
+  assert.doesNotMatch(h, /续谈/);
+});
+
 test('缺省参数不抛错', () => {
   assert.equal(typeof inboundHeadline(), 'string');
   assert.equal(typeof inboundHeadline({}), 'string');

plugins/opencode-mail-bridge/lib/relay-policy.js

@@ -37,6 +37,8 @@ export function addrName(addr) {
  * 这一轮的结论该不该由插件自动转发出去。
  *
  * @param {object} ctx
+ * @param {string}  [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
+ * @param {string}  [ctx.selfName]   本方名字（收件方自己），用于方向判据
  * @param {boolean} ctx.fromHuman 来信方是人类用户（SSE 的 `from_human`）
  * @param {string}  [ctx.replyTo] 自动转发本来要发给谁
  * @returns {{relay: boolean, reason: string}}
@@ -65,6 +67,8 @@ export function autoRelayDecision(ctx) {
  * 而实际上那封信永远不会发出去，发件方一直等着。
  *
  * @param {object} ctx
+ * @param {string}  [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
+ * @param {string}  [ctx.selfName]   本方名字（收件方自己），用于方向判据
  * @param {boolean} ctx.fromHuman
  * @param {string}  [ctx.replyAddress] 服务端算好的回信地址
  * @returns {string[]} 若干行，直接拼进提示词
@@ -97,17 +101,36 @@ export function replyInstruction(ctx) {
  *
  * @param {object} ctx
  * @param {string}  [ctx.inReplyTo] 非空 = 这是对本方某封信的回复（SSE 的 `in_reply_to`）
+ * @param {string}  [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
+ * @param {string}  [ctx.selfName]   本方名字（收件方自己），用于方向判据
  * @param {boolean} ctx.fromHuman
  * @param {boolean} [ctx.catchup]  离线期间积压后补投的
  * @param {boolean} [ctx.reused]   投进一条已存在的会话（续谈）
  * @returns {string} 提示词第一行
  */
 export function inboundHeadline(ctx) {
-  const { inReplyTo, fromHuman, catchup, reused } = ctx || {};
+  const { inReplyTo, parentFrom, selfName, fromHuman, catchup, reused } = ctx || {};
   const who = fromHuman ? "" : "（对方是一个 Agent）";
   if (inReplyTo) {
     // 「回复到了」与「有人派活」是两种处境。说清楚它，模型才不会把
     // 一句确认当成新任务 —— 那正是互相客套的起点。
+    //
+    // ★ 还必须有**方向**判据（2026-09-30 修，in-reply-to-ignores-direction）：
+    // 只有 inReplyTo 时只能判断「这是回信」，分不清回的是**谁**的信。
+    // 单向续信链（8 封全是 opencode → pi）同样满足「有父邮件」，曾被逐封
+    // 宣称「回的是你那封」，把纯单向链读成双向对话。服务端现在在载荷里
+    // 带父邮件发件人（parent_from）；`parentFrom === selfName` 才是
+    // 「我上一封信的回复到了」，否则是多方线索里的他人续谈 —— 当新输入。
+    // 服务端未升级（无 parent_from）时退回旧行为，不比原来更差。
+    const mine = parentFrom != null && parentFrom !== "" && selfName != null && parentFrom === selfName;
+    if (mine) {
+      return `你上一封信的**回复**到了${who}。这不是新任务。`;
+    }
+    if (parentFrom != null && parentFrom !== "") {
+      return `这是多方线索里的**续谈**（回的那封是 ${parentFrom} 发的，不是对你上一封信的回复）${who}。`;
+    }
+    // 服务端未升级（无 parent_from）时退回旧行为：含糊地说「回复到了」
+    // 也强于让模型把一封真回复当新任务再处理一遍 —— 那是互相客套的起点。
     return `你上一封信的**回复**到了${who}。这不是新任务。`;
   }
   if (catchup) {

plugins/opencode-mail-bridge/test/relay-policy.test.mjs

@@ -125,6 +125,34 @@ test('续谈与新会话的措辞不同', () => {
   assert.match(inboundHeadline({ fromHuman: true, reused: false }), /你收到/);
 });
 
+
+test('★ 方向判据：父邮件是别人发的 ⇒ 不是「你上一封信的回复到了」（in-reply-to-ignores-direction）', () => {
+  // 生产兜现：压测线索 stress-thread-21863-15348，8 封全是 opencode → pi，
+  // pi 的投递通知却逐封宣称「回的是你那封」—— 没有一封是 pi 发出的。
+  // 单向续信链同样满足「有父邮件」⇒ 纯单向链被读成双向对话，Agent 把
+  // 「收到」当新任务客套到撞 hop 上限。
+  const h = inboundHeadline({
+    inReplyTo: 'm-1', parentFrom: 'opencode', selfName: 'pi', fromHuman: false,
+  });
+  assert.doesNotMatch(h, /你上一封信的\*\*回复\*\*到了/,
+    '父邮件是 opencode 发的，pi 不该被告知「你的回复到了」');
+  assert.match(h, /opencode/, '要说清父邮件是谁发的，模型才能判断处境');
+});
+
+test('★ 方向判据：父邮件是自己发的 ⇒ 仍是「回复到了」', () => {
+  const h = inboundHeadline({
+    inReplyTo: 'm-1', parentFrom: 'pi', selfName: 'pi', fromHuman: false,
+  });
+  assert.match(h, /回复/);
+  assert.match(h, /不是新任务/);
+});
+
+test('★ 方向判据：服务端未升级（无 parent_from）⇒ 退回旧行为，不比原来更差', () => {
+  const h = inboundHeadline({ inReplyTo: 'm-1', fromHuman: false });
+  assert.match(h, /回复/, '缺方向信号时不能把回信误报成新任务');
+  assert.doesNotMatch(h, /续谈/);
+});
+
 test('缺省参数不抛错', () => {
   assert.equal(typeof inboundHeadline(), 'string');
   assert.equal(typeof inboundHeadline({}), 'string');

plugins/pi-mail-bridge/lib/relay-policy.js

@@ -37,6 +37,8 @@ export function addrName(addr) {
  * 这一轮的结论该不该由插件自动转发出去。
  *
  * @param {object} ctx
+ * @param {string}  [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
+ * @param {string}  [ctx.selfName]   本方名字（收件方自己），用于方向判据
  * @param {boolean} ctx.fromHuman 来信方是人类用户（SSE 的 `from_human`）
  * @param {string}  [ctx.replyTo] 自动转发本来要发给谁
  * @returns {{relay: boolean, reason: string}}
@@ -65,6 +67,8 @@ export function autoRelayDecision(ctx) {
  * 而实际上那封信永远不会发出去，发件方一直等着。
  *
  * @param {object} ctx
+ * @param {string}  [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
+ * @param {string}  [ctx.selfName]   本方名字（收件方自己），用于方向判据
  * @param {boolean} ctx.fromHuman
  * @param {string}  [ctx.replyAddress] 服务端算好的回信地址
  * @returns {string[]} 若干行，直接拼进提示词
@@ -97,17 +101,36 @@ export function replyInstruction(ctx) {
  *
  * @param {object} ctx
  * @param {string}  [ctx.inReplyTo] 非空 = 这是对本方某封信的回复（SSE 的 `in_reply_to`）
+ * @param {string}  [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
+ * @param {string}  [ctx.selfName]   本方名字（收件方自己），用于方向判据
  * @param {boolean} ctx.fromHuman
  * @param {boolean} [ctx.catchup]  离线期间积压后补投的
  * @param {boolean} [ctx.reused]   投进一条已存在的会话（续谈）
  * @returns {string} 提示词第一行
  */
 export function inboundHeadline(ctx) {
-  const { inReplyTo, fromHuman, catchup, reused } = ctx || {};
+  const { inReplyTo, parentFrom, selfName, fromHuman, catchup, reused } = ctx || {};
   const who = fromHuman ? "" : "（对方是一个 Agent）";
   if (inReplyTo) {
     // 「回复到了」与「有人派活」是两种处境。说清楚它，模型才不会把
     // 一句确认当成新任务 —— 那正是互相客套的起点。
+    //
+    // ★ 还必须有**方向**判据（2026-09-30 修，in-reply-to-ignores-direction）：
+    // 只有 inReplyTo 时只能判断「这是回信」，分不清回的是**谁**的信。
+    // 单向续信链（8 封全是 opencode → pi）同样满足「有父邮件」，曾被逐封
+    // 宣称「回的是你那封」，把纯单向链读成双向对话。服务端现在在载荷里
+    // 带父邮件发件人（parent_from）；`parentFrom === selfName` 才是
+    // 「我上一封信的回复到了」，否则是多方线索里的他人续谈 —— 当新输入。
+    // 服务端未升级（无 parent_from）时退回旧行为，不比原来更差。
+    const mine = parentFrom != null && parentFrom !== "" && selfName != null && parentFrom === selfName;
+    if (mine) {
+      return `你上一封信的**回复**到了${who}。这不是新任务。`;
+    }
+    if (parentFrom != null && parentFrom !== "") {
+      return `这是多方线索里的**续谈**（回的那封是 ${parentFrom} 发的，不是对你上一封信的回复）${who}。`;
+    }
+    // 服务端未升级（无 parent_from）时退回旧行为：含糊地说「回复到了」
+    // 也强于让模型把一封真回复当新任务再处理一遍 —— 那是互相客套的起点。
     return `你上一封信的**回复**到了${who}。这不是新任务。`;
   }
   if (catchup) {

plugins/pi-mail-bridge/src/turn.mjs

@@ -145,6 +145,8 @@ export function buildMailPrompt({ agentName, data, kind, reused }) {
   const lines = [
     inboundHeadline({
       inReplyTo: data?.in_reply_to,
+      parentFrom: data?.parent_from,
+      selfName: agentName,
       fromHuman,
       catchup: data?.catchup,
       reused,
@@ -154,7 +156,8 @@ export function buildMailPrompt({ agentName, data, kind, reused }) {
     `主题：${data?.subject || '(无主题)'}`,
     `邮件 ID：${data?.mail_id || 'unknown'}`,
   ];
-  if (data?.in_reply_to) {
+  // 「回的是你那封」只在父邮件**确实是本方发出**时才成立（方向判据，同 inboundHeadline）
+  if (data?.in_reply_to && data?.parent_from && data.parent_from === agentName) {
     lines.push(`回的是你那封：${data.in_reply_to}`);
   }
   if (!reused) lines.push(`身份：你是 ${agentName}`);

plugins/pi-mail-bridge/test/relay-policy.test.mjs

@@ -125,6 +125,34 @@ test('续谈与新会话的措辞不同', () => {
   assert.match(inboundHeadline({ fromHuman: true, reused: false }), /你收到/);
 });
 
+
+test('★ 方向判据：父邮件是别人发的 ⇒ 不是「你上一封信的回复到了」（in-reply-to-ignores-direction）', () => {
+  // 生产兜现：压测线索 stress-thread-21863-15348，8 封全是 opencode → pi，
+  // pi 的投递通知却逐封宣称「回的是你那封」—— 没有一封是 pi 发出的。
+  // 单向续信链同样满足「有父邮件」⇒ 纯单向链被读成双向对话，Agent 把
+  // 「收到」当新任务客套到撞 hop 上限。
+  const h = inboundHeadline({
+    inReplyTo: 'm-1', parentFrom: 'opencode', selfName: 'pi', fromHuman: false,
+  });
+  assert.doesNotMatch(h, /你上一封信的\*\*回复\*\*到了/,
+    '父邮件是 opencode 发的，pi 不该被告知「你的回复到了」');
+  assert.match(h, /opencode/, '要说清父邮件是谁发的，模型才能判断处境');
+});
+
+test('★ 方向判据：父邮件是自己发的 ⇒ 仍是「回复到了」', () => {
+  const h = inboundHeadline({
+    inReplyTo: 'm-1', parentFrom: 'pi', selfName: 'pi', fromHuman: false,
+  });
+  assert.match(h, /回复/);
+  assert.match(h, /不是新任务/);
+});
+
+test('★ 方向判据：服务端未升级（无 parent_from）⇒ 退回旧行为，不比原来更差', () => {
+  const h = inboundHeadline({ inReplyTo: 'm-1', fromHuman: false });
+  assert.match(h, /回复/, '缺方向信号时不能把回信误报成新任务');
+  assert.doesNotMatch(h, /续谈/);
+});
+
 test('缺省参数不抛错', () => {
   assert.equal(typeof inboundHeadline(), 'string');
   assert.equal(typeof inboundHeadline({}), 'string');

plugins/zcode-mail-bridge/lib/relay-policy.js

@@ -37,6 +37,8 @@ export function addrName(addr) {
  * 这一轮的结论该不该由插件自动转发出去。
  *
  * @param {object} ctx
+ * @param {string}  [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
+ * @param {string}  [ctx.selfName]   本方名字（收件方自己），用于方向判据
  * @param {boolean} ctx.fromHuman 来信方是人类用户（SSE 的 `from_human`）
  * @param {string}  [ctx.replyTo] 自动转发本来要发给谁
  * @returns {{relay: boolean, reason: string}}
@@ -65,6 +67,8 @@ export function autoRelayDecision(ctx) {
  * 而实际上那封信永远不会发出去，发件方一直等着。
  *
  * @param {object} ctx
+ * @param {string}  [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
+ * @param {string}  [ctx.selfName]   本方名字（收件方自己），用于方向判据
  * @param {boolean} ctx.fromHuman
  * @param {string}  [ctx.replyAddress] 服务端算好的回信地址
  * @returns {string[]} 若干行，直接拼进提示词
@@ -97,17 +101,36 @@ export function replyInstruction(ctx) {
  *
  * @param {object} ctx
  * @param {string}  [ctx.inReplyTo] 非空 = 这是对本方某封信的回复（SSE 的 `in_reply_to`）
+ * @param {string}  [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
+ * @param {string}  [ctx.selfName]   本方名字（收件方自己），用于方向判据
  * @param {boolean} ctx.fromHuman
  * @param {boolean} [ctx.catchup]  离线期间积压后补投的
  * @param {boolean} [ctx.reused]   投进一条已存在的会话（续谈）
  * @returns {string} 提示词第一行
  */
 export function inboundHeadline(ctx) {
-  const { inReplyTo, fromHuman, catchup, reused } = ctx || {};
+  const { inReplyTo, parentFrom, selfName, fromHuman, catchup, reused } = ctx || {};
   const who = fromHuman ? "" : "（对方是一个 Agent）";
   if (inReplyTo) {
     // 「回复到了」与「有人派活」是两种处境。说清楚它，模型才不会把
     // 一句确认当成新任务 —— 那正是互相客套的起点。
+    //
+    // ★ 还必须有**方向**判据（2026-09-30 修，in-reply-to-ignores-direction）：
+    // 只有 inReplyTo 时只能判断「这是回信」，分不清回的是**谁**的信。
+    // 单向续信链（8 封全是 opencode → pi）同样满足「有父邮件」，曾被逐封
+    // 宣称「回的是你那封」，把纯单向链读成双向对话。服务端现在在载荷里
+    // 带父邮件发件人（parent_from）；`parentFrom === selfName` 才是
+    // 「我上一封信的回复到了」，否则是多方线索里的他人续谈 —— 当新输入。
+    // 服务端未升级（无 parent_from）时退回旧行为，不比原来更差。
+    const mine = parentFrom != null && parentFrom !== "" && selfName != null && parentFrom === selfName;
+    if (mine) {
+      return `你上一封信的**回复**到了${who}。这不是新任务。`;
+    }
+    if (parentFrom != null && parentFrom !== "") {
+      return `这是多方线索里的**续谈**（回的那封是 ${parentFrom} 发的，不是对你上一封信的回复）${who}。`;
+    }
+    // 服务端未升级（无 parent_from）时退回旧行为：含糊地说「回复到了」
+    // 也强于让模型把一封真回复当新任务再处理一遍 —— 那是互相客套的起点。
     return `你上一封信的**回复**到了${who}。这不是新任务。`;
   }
   if (catchup) {

plugins/zcode-mail-bridge/src/prompt.mjs

@@ -130,6 +130,8 @@ export function buildMailPrompt({ agentName, data, kind = 'mail', reused = false
   const lines = [
     inboundHeadline({
       inReplyTo: data?.in_reply_to,
+      parentFrom: data?.parent_from,
+      selfName: agentName,
       fromHuman,
       catchup: data?.catchup,
       reused
@@ -140,7 +142,10 @@ export function buildMailPrompt({ agentName, data, kind = 'mail', reused = false
     `邮件 ID：${data?.mail_id || 'unknown'}`
   ];
 
-  if (data?.in_reply_to) lines.push(`回的是你那封：${data.in_reply_to}`);
+  // 「回的是你那封」只在父邮件**确实是本方发出**时才成立（方向判据，同 inboundHeadline）
+  if (data?.in_reply_to && data?.parent_from && data.parent_from === agentName) {
+    lines.push(`回的是你那封：${data.in_reply_to}`);
+  }
   if (!reused) lines.push(`身份：你是 ${agentName}`);
   // 服务端算好的回信地址。带上它是因为模型**确实会**自己发信（抄送第三方、
   // 分多封交代不同的事）。让它自己拼三维地址的话，`.new` 会被拼进去，

plugins/zcode-mail-bridge/test/relay-policy.test.mjs

@@ -125,6 +125,34 @@ test('续谈与新会话的措辞不同', () => {
   assert.match(inboundHeadline({ fromHuman: true, reused: false }), /你收到/);
 });
 
+
+test('★ 方向判据：父邮件是别人发的 ⇒ 不是「你上一封信的回复到了」（in-reply-to-ignores-direction）', () => {
+  // 生产兜现：压测线索 stress-thread-21863-15348，8 封全是 opencode → pi，
+  // pi 的投递通知却逐封宣称「回的是你那封」—— 没有一封是 pi 发出的。
+  // 单向续信链同样满足「有父邮件」⇒ 纯单向链被读成双向对话，Agent 把
+  // 「收到」当新任务客套到撞 hop 上限。
+  const h = inboundHeadline({
+    inReplyTo: 'm-1', parentFrom: 'opencode', selfName: 'pi', fromHuman: false,
+  });
+  assert.doesNotMatch(h, /你上一封信的\*\*回复\*\*到了/,
+    '父邮件是 opencode 发的，pi 不该被告知「你的回复到了」');
+  assert.match(h, /opencode/, '要说清父邮件是谁发的，模型才能判断处境');
+});
+
+test('★ 方向判据：父邮件是自己发的 ⇒ 仍是「回复到了」', () => {
+  const h = inboundHeadline({
+    inReplyTo: 'm-1', parentFrom: 'pi', selfName: 'pi', fromHuman: false,
+  });
+  assert.match(h, /回复/);
+  assert.match(h, /不是新任务/);
+});
+
+test('★ 方向判据：服务端未升级（无 parent_from）⇒ 退回旧行为，不比原来更差', () => {
+  const h = inboundHeadline({ inReplyTo: 'm-1', fromHuman: false });
+  assert.match(h, /回复/, '缺方向信号时不能把回信误报成新任务');
+  assert.doesNotMatch(h, /续谈/);
+});
+
 test('缺省参数不抛错', () => {
   assert.equal(typeof inboundHeadline(), 'string');
   assert.equal(typeof inboundHeadline({}), 'string');

server/internal/handler/forward.go

@@ -160,7 +160,7 @@ func doForward(w http.ResponseWriter, r *http.Request, mailID uuid.UUID, actor,
 	subject := forwardSubject(req.Subject, src.Subject)
 
 	// 转发按目标地址寻址，不带 reply_to：它是一条新线索，不该并进原会话
-	sessionID, _, created, err := resolveTarget(r, to, "", actor, subject, req.SessionAlias, agentLimiterKey(isAgent, actor))
+	sessionID, _, _, created, err := resolveTarget(r, to, "", actor, subject, req.SessionAlias, agentLimiterKey(isAgent, actor))
 	if err != nil {
 		writeErr(w, err, "Failed to resolve session")
 		return
@@ -224,7 +224,7 @@ func doForward(w http.ResponseWriter, r *http.Request, mailID uuid.UUID, actor,
 	// 全新的信：那封原邮件不是它写的，也不在它的线索里。
 	// 因此 in_reply_to 传空串 —— 提示词该说「有人转了一封信给你」而不是
 	// 「你上封信的回复到了」。
-	notifyRecipients(r.Context(), to, ccList, sessionID, newID, actor, subject, "")
+	notifyRecipients(r.Context(), to, ccList, sessionID, newID, actor, subject, "", "")
 
 	JSON(w, http.StatusOK, map[string]any{
 		"mail_id":        newID.String(),

server/internal/handler/mail.go

@@ -64,7 +64,7 @@ type sendMailRequest struct {
 // 人类不受此限（手工点「新建邮件」的频率天然受限，加限制只会在批量派活时误伤）。
 // resolveTarget 依据地址的 session 位定位（或新建）会话。
 //
-// 返回值：会话 id / 父邮件 id（仅 reply_to 路径非 nil）/ **created** / 错误。
+// 返回值：会话 id / 父邮件 id（仅 reply_to 路径非 nil）/ 父邮件发件人（仅 reply_to 路径非空，其余路径空串）/ **created** / 错误。
 //
 // created 为真**仅**表示这次调用真的新建了一条会话。它存在的理由是：
 // `parentMailID == nil` 曾被当作「新建会话」的判据，而那是错的 ——
@@ -72,15 +72,15 @@ type sendMailRequest struct {
 // 第一封信 `max_rounds=7`，第二封信省略该字段，会话预算被静默改成 20。
 // 「只在新建时生效」的字段（往返预算、权限档位）必须靠这个返回值判断，
 // 否则每封新信都在改写对方正在遵守的规则。
-func resolveTarget(r *http.Request, addr models.Address, replyTo, fromAgent, subject, alias string, byAgent string) (uuid.UUID, *uuid.UUID, bool, error) {
+func resolveTarget(r *http.Request, addr models.Address, replyTo, fromAgent, subject, alias string, byAgent string) (uuid.UUID, *uuid.UUID, string, bool, error) {
 	if replyTo != "" {
 		replyID, err := uuid.Parse(replyTo)
 		if err != nil {
-			return uuid.Nil, nil, false, errBadRequest("Invalid reply_to UUID")
+			return uuid.Nil, nil, "", false, errBadRequest("Invalid reply_to UUID")
 		}
 		mail, err := repo.GetMailByID(r.Context(), replyID)
 		if err != nil {
-			return uuid.Nil, nil, false, errNotFound("Parent mail not found")
+			return uuid.Nil, nil, "", false, errNotFound("Parent mail not found")
 		}
 		// 归档契约在这条路径上同样成立：别名寻址回 404（FindNamedSessionFor
 		// 带 s.status <> 'archived'），reply_to 是**绕过它的那条路**。
@@ -90,11 +90,15 @@ func resolveTarget(r *http.Request, addr models.Address, replyTo, fromAgent, sub
 		// （ListInbox 按会话状态把它放回来、unreadFor 按邮件行继续藏）。
 		// 判据见 repo.TouchSession 与 session_status_invariant_test.go。
 		if err := repo.EnsureSessionOpen(r.Context(), mail.SessionID); err != nil {
-			return uuid.Nil, nil, false, errNotFound(
+			return uuid.Nil, nil, "", false, errNotFound(
 				"无法送达：被回复的邮件属于一条已归档的会话。归档是单向的，请用 .new 另起一条")
 		}
 		repo.TouchSession(r.Context(), mail.SessionID)
-		return mail.SessionID, &replyID, false, nil
+		// ★ 把父邮件发件人一并带出去（2026-09-30，dsh）：
+		// 这一行在上一个版本里只用了 SessionID 就把整行丢掉 —— 而
+		// notify 载荷的方向判据（in_reply_to_ignores_direction 那笔债）
+		// 恰恰需要它，且**数据本来就在手**，不需要任何额外查询。
+		return mail.SessionID, &replyID, mail.FromName, false, nil
 	}
 
 	switch addr.Mode() {
@@ -104,17 +108,17 @@ func resolveTarget(r *http.Request, addr models.Address, replyTo, fromAgent, sub
 		var aliasPtr *string
 		if a := strings.TrimSpace(alias); a != "" {
 			if err := validateSessionAlias(a); err != nil {
-				return uuid.Nil, nil, false, err
+				return uuid.Nil, nil, "", false, err
 			}
 			if _, err := repo.FindSessionByAlias(r.Context(), a); err == nil {
-				return uuid.Nil, nil, false, errConflict(fmt.Sprintf(
+				return uuid.Nil, nil, "", false, errConflict(fmt.Sprintf(
 					"会话别名 %q 已被占用；若要接着该会话谈请用 %s@%s.%s", a, addr.Name, addr.Path, a))
 			}
 			aliasPtr = &a
 		}
 		// Agent 主动开新线索要过速率限制
 		if ok, retry := repo.AllowNewSession(r.Context(), byAgent); !ok {
-			return uuid.Nil, nil, false, errRateLimited(fmt.Sprintf(
+			return uuid.Nil, nil, "", false, errRateLimited(fmt.Sprintf(
 				"新建会话过于频繁（1 小时内已开 %d 条）。请在已有会话里继续，或 %d 秒后再试。",
 				repo.SessionRateLimit(), retry))
 		}
@@ -124,7 +128,7 @@ func resolveTarget(r *http.Request, addr models.Address, replyTo, fromAgent, sub
 		if err != nil {
 			// 建失败要把名额还回去：那次新建实际上没有发生
 			repo.ReleaseNewSession(r.Context(), byAgent)
-			return id, nil, false, err
+			return id, nil, "", false, err
 		}
 		// `.new` 是一次性动作：它建完会话就用完了，之后要再投进这条会话只能靠
 		// `name@path.<别名>`。未命名会话既查不到（FindNamedSessionFor 的
@@ -136,7 +140,7 @@ func resolveTarget(r *http.Request, addr models.Address, replyTo, fromAgent, sub
 			// 只能用 reply_to 续谈，比整封退回轻。
 			_, _ = repo.EnsureSessionAlias(r.Context(), id, repo.AutoAliasFor(addr.Name, subject))
 		}
-		return id, nil, true, nil
+		return id, nil, "", true, nil
 
 	case models.SessionDefault:
 		// 默认会话「从未通信则建立」也会产生新会话，但一个 name@path 只有一条，
@@ -146,29 +150,29 @@ func resolveTarget(r *http.Request, addr models.Address, replyTo, fromAgent, sub
 		// parentMailID == nil，靠它判断会把续谈误当新建（预算与档位被静默改写）。
 		id, created, err := repo.FindOrCreateDefaultSessionCreated(r.Context(), addr.Name, addr.Path, fromAgent, subject)
 		if err != nil {
-			return id, nil, false, err
+			return id, nil, "", false, err
 		}
 		// 默认会话同样需要可寻址的别名：省略 session 位能投进来，但要**指名**
 		// 投进这一条（而不是「该 name@path 当前的默认会话」）仍然只能靠别名。
 		// 已有别名时 EnsureSessionAlias 直接返回，复用旧会话不会被改名。
 		_, _ = repo.EnsureSessionAlias(r.Context(), id, repo.AutoAliasFor(addr.Name, subject))
-		return id, nil, created, nil
+		return id, nil, "", created, nil
 
 	default: // models.SessionNamed
 		id, err := repo.FindNamedSessionFor(r.Context(), addr.Name, addr.Path, addr.Session)
 		if err == nil {
 			repo.TouchSession(r.Context(), id)
-			return id, nil, false, nil
+			return id, nil, "", false, nil
 		}
 		// 同名别名在多个工作目录下都存在、而地址里又没写 path：不能猜一条，
 		// 要让发信方补 path（见 repo.ErrSessionAmbiguous 的注释）。
 		if errors.Is(err, repo.ErrSessionAmbiguous) {
-			return uuid.Nil, nil, false, errBadRequest(fmt.Sprintf(
+			return uuid.Nil, nil, "", false, errBadRequest(fmt.Sprintf(
 				"别名 %q 在多个工作目录下都存在，无法确定是哪一条：请在地址里写明 path（name@/路径.%s）。",
 				addr.Session, addr.Session))
 		}
 		if !errors.Is(err, repo.ErrSessionNotFound) {
-			return uuid.Nil, nil, false, err
+			return uuid.Nil, nil, "", false, err
 		}
 
 		// 本侧没有这条别名 —— 再看平台会话镜像。
@@ -182,12 +186,12 @@ func resolveTarget(r *http.Request, addr models.Address, replyTo, fromAgent, sub
 		// 接管**是**新建本侧会话（绑定了 platform_id 的那条），
 		// 所以 created 为真：它此前没有档位与预算，需要按这次投递定下来。
 		if adopted, aErr := adoptFromPlatform(r, addr, fromAgent, subject, byAgent); aErr == nil {
-			return adopted, nil, true, nil
+			return adopted, nil, "", true, nil
 		} else if !errors.Is(aErr, repo.ErrSessionNotFound) {
-			return uuid.Nil, nil, false, aErr
+			return uuid.Nil, nil, "", false, aErr
 		}
 
-		return uuid.Nil, nil, false, errNotFound(fmt.Sprintf(
+		return uuid.Nil, nil, "", false, errNotFound(fmt.Sprintf(
 			"无法送达：会话 %q 不存在于 %s@%s。若要新建会话请用 %s@%s.new，投递默认会话请省略 session 位",
 			addr.Session, addr.Name, addr.Path, addr.Name, addr.Path))
 	}
@@ -294,7 +298,7 @@ func SendMail(w http.ResponseWriter, r *http.Request) {
 		return
 	}
 
-	sessionID, parentMailID, created, err := resolveTarget(r, to, req.ReplyTo, agentName, req.Subject, req.SessionAlias, agentName)
+	sessionID, parentMailID, parentFrom, created, err := resolveTarget(r, to, req.ReplyTo, agentName, req.Subject, req.SessionAlias, agentName)
 	if err != nil {
 		writeErr(w, err, "Failed to resolve session")
 		return
@@ -577,7 +581,7 @@ func SendMail(w http.ResponseWriter, r *http.Request) {
 		_ = repo.BindRelayMail(r.Context(), agentName, relayKey, mailID)
 	}
 
-	notifyRecipients(r.Context(), to, ccList, sessionID, mailID, agentName, req.Subject, parentIDString(parentMailID))
+	notifyRecipients(r.Context(), to, ccList, sessionID, mailID, agentName, req.Subject, parentIDString(parentMailID), parentFrom)
 
 	// 回传会话别名与本任务剩余往返，让发件方知道后续用什么地址续谈、还能发几封
 	resp := map[string]any{
@@ -610,7 +614,12 @@ func SendMail(w http.ResponseWriter, r *http.Request) {
 // 加字段时漏改一处直接造成生产事故（详见那个包的注释）。
 //
 // parentMailID 为空字串表示这不是回信。
-func notifyRecipients(ctx context.Context, to models.Address, cc []models.Address, sessionID, mailID uuid.UUID, from, subject, parentMailID string) {
+// parentFrom 是**父邮件的发件人**（仅 reply_to 路径非空）：
+// 载荷带上它，插件才能区分「父邮件是我发的」（= 我的回复到了）
+// 与「父邮件是别人发的」（= 第三方在续谈）—— 单向续信链同样满足
+// 「有父邮件」，没有方向判据就会被读成「对方在回我」
+// （docs/DEBTS.json: in-reply-to-ignores-direction，生产兜现过）。
+func notifyRecipients(ctx context.Context, to models.Address, cc []models.Address, sessionID, mailID uuid.UUID, from, subject, parentMailID, parentFrom string) {
 	notify.Recipients(ctx, notify.Mail{
 		SessionID:    sessionID,
 		MailID:       mailID,
@@ -619,6 +628,7 @@ func notifyRecipients(ctx context.Context, to models.Address, cc []models.Addres
 		CC:           cc,
 		Subject:      subject,
 		ParentMailID: parentMailID,
+		ParentFrom:   parentFrom,
 	})
 }
 

server/internal/handler/me.go

@@ -114,7 +114,7 @@ func MeSendMail(w http.ResponseWriter, r *http.Request) {
 		return
 	}
 
-	sessionID, parentMailID, created, err := resolveTarget(r, to, req.ReplyTo, user.Username, req.Subject, req.SessionAlias, "")
+	sessionID, parentMailID, parentFrom, created, err := resolveTarget(r, to, req.ReplyTo, user.Username, req.Subject, req.SessionAlias, "")
 	if err != nil {
 		writeErr(w, err, "Failed to resolve session")
 		return
@@ -183,7 +183,7 @@ func MeSendMail(w http.ResponseWriter, r *http.Request) {
 		return
 	}
 
-	notifyRecipients(r.Context(), to, ccList, sessionID, mailID, user.Username, req.Subject, parentIDString(parentMailID))
+	notifyRecipients(r.Context(), to, ccList, sessionID, mailID, user.Username, req.Subject, parentIDString(parentMailID), parentFrom)
 
 	resp := map[string]any{
 		"mail_id":       mailID.String(),

server/internal/notify/mail.go

@@ -59,6 +59,18 @@ type Mail struct {
 	// 后果在生产上兜现过：pi 转发给 dsh，dsh 回确认，pi 把那封确认当成新任务
 	// 又回一封，两边互相客套 6 轮直到撞上 hop 上限。
 	ParentMailID string
+	// ParentFrom 是**父邮件的发件人**（仅 reply_to 路径非空）。
+	//
+	// 只有 ParentMailID 时插件只能判断「这是回信」，分不清回的是**谁**的信：
+	// 单向续信链（压测里 8 封全是 opencode → pi）同样满足「有父邮件」，pi 侧的
+	// 投递通知逐封宣称「回的是你那封：<上一封 id>」，而那封上一封是 opencode
+	// 自己发的 —— 没有一封是 pi 发出的。方向被省略 ⇒ 单向链被读成双向对话，
+	// Agent 把「收到」当新任务继续客套（docs/DEBTS.json: in-reply-to-ignores-direction）。
+	//
+	// 插件判据：`parent_from == 我自己` ⇒ 「我上一封信的回复到了」；
+	// `parent_from != 我` ⇒ 多方线索里的他人续谈，当作新输入处理。
+	// 空串（转发 / 非回信路径）退回旧行为。
+	ParentFrom string
 }
 
 // Recipients 把一封邮件推给主收件人、所有抄送方，并刷新发件方的会话列表。
@@ -200,6 +212,13 @@ func Recipients(ctx context.Context, m Mail) {
 			// 插件据此换一套提示词：把它当新任务会让模型又“处理”一遍并再回一封，
 			// 于是两个 Agent 互相客套直到撞上 hop 上限（生产实测 6 轮）。
 			"in_reply_to": m.ParentMailID,
+			// parent_from 是父邮件的发件人 —— **方向**判据。
+			//
+			// 只有 in_reply_to 时插件只能判断「这是回信」，分不清回的是谁的信：
+			// 单向续信链同样满足「有父邮件」，曾被逐封读成「对方在回我」，
+			// Agent 把「收到」当新任务继续客套直到撞 hop 上限。
+			// parent_from == 收件人自己 ⇒ 我的回复到了；≠ ⇒ 他人续谈/多方线索。
+			"parent_from": m.ParentFrom,
 			// from_human 区分「人在找你」与「另一个 Agent 在找你」。
 			//
 			// 插件据此不再对 Agent → Agent 的信说「回信不用你自己发」：