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');