fix(send): 按轮绑定 mention-back 发送者

[xiongz-c]

背景

在多 Bot 群中，Bot B 收到 Bot A 的消息后显式执行 botmux send --mention-back，预期应 @ 回本轮发送者 Bot A。现状存在两层退化：

1. daemon 把 quoteTargetSenderOpenId 存成 session 级单槽；排队或并发轮次到达时，后一轮会覆盖前一轮 sender。
2. botmux send 虽然已经按 BOTMUX_TURN_ID 读取 replyTargets[turnId] 的回复落点，却仍从上述最新单槽读取 sender，导致“落点来自 A 轮、sender 来自 B 轮”。
3. fix(send): 多人会话禁用 --mention-back 并修复人数查询注册顺序（兜底卡断链 deferred） #689 增加的参与人数门禁会在人数大于 2 时拒绝 --mention-back，迫使模型从上下文重新选择 --mention。这使原本可由平台事件确定的 sender 退化为模型猜测，表现为偶发 @ 到会话 owner 或其它参与者。

修复

• 扩展现有 replyTargets[turnId]，把 rootMessageId、senderOpenId、quoteOnly、substitute 原子写入同一条 per-turn 记录。
• thread scope 和 chat rootless turn 也写入记录；它们即使不需要 per-turn root，仍需要本轮 sender。
• botmux send --mention-back 只读取当前 turnId 的 sender；VC 显式 per-turn origin 仍保持最高优先级。
• 兼容旧 session：仅当 quoteTargetId === currentTurnId 时，才允许从旧 sender 单槽回退；reply slot 同样要求 slot.turnId === currentTurnId。
• 32 条上限淘汰或 turn 不匹配时 fail-closed，由现有 mention decision 校验拒绝 --mention-back，不会借用后一轮 sender。
• 删除 --mention-back 的群人数查询与人数门禁。

为什么挑战 #689 的人数门禁

#689 的担忧“多人群里触发者不一定是业务上的收件人”是成立的，但它适用于“系统或模型尚未选择收件人”的场景，不适用于已经显式选择 --mention-back 的调用。

--mention-back 的命令语义就是“@ 本轮真实发送者”。调用方如果要回复会话 owner、其他人或第三个 Bot，应使用显式 --mention；人数门禁无法判断这些业务意图，也没有为路由增加新信息。相反，门禁拒绝确定性路径后让模型从 <mentions> 等上下文重建同一个 open_id，扩大了误路由面。

因此本修复不按 human/bot 做不对称放行，也不依赖 quoteTargetSenderIsBot。后者包含平台 sender_type 与 cross-ref 学习两类信号，不应成为发送权限边界；这里所需的只是平台入站事件中、与当前 turn 原子绑定的真实 sender open_id。无 per-turn sender 时统一 fail-closed。

本 PR 不改变 daemon 忘记调用 botmux send 时的 owner 兜底，也不限制显式 --mention，因此 #689 对“无明确路由决定”的保守处理仍保留在原路径。

影响面

• 公共层：session 持久化的 replyTargets entry 新增可选 sender，旧数据向后兼容。
• IM / 会话：覆盖 thread、chat、rootless chat、passthrough、现有 session follow-up、自动创建；定时/系统轮次不伪造 sender。
• CLI / 后端：所有 CLI 与 PTY/Tmux 等后端共享同一 send 解析逻辑；未修改各 CLI adapter 和后端实现。
• 网络：--mention-back 不再额外调用群成员统计接口，也不再因统计软失败 {999,999} 被误拦。
• 未修改显式 --mention、--no-mention、top-level、daemon fallback card 与 bot trust 判定。

验证

通过：

• pnpm vitest run test/reply-target-fallback.test.ts test/send-policy.test.ts test/cli-send-hook-context.test.ts test/daemon-turn-reply-sender-wiring.test.ts — 4 files / 62 tests passed
• pnpm build — TypeScript、dashboard bundle、domain audit、dist audit 全部通过
• git diff --check — 通过
• pnpm test — 800 files / 12842 tests passed；本 PR 新增与相关测试均通过

全量测试有 2 个与本改动无关的既有 macOS 文件系统失败，单独复跑结果一致：

• test/v2-run-archive.test.ts：对目录调用 rmSync(path, { force: true })，报 Path is a directory
• test/v3-host-execution.test.ts：同类目录清理错误

未部署 live daemon；本 PR 不抢占本机全局 botmux checkout，合并前可按需做飞书多 Bot 手工验证。

[deepcoldy]

复核 head b3534a779：当前有 1 个 blocking；其余实现未发现新的代码阻塞。

🔴 thread-scope 替身轮会错误关闭 streaming card

调用链成立：

1. 话题群替身触发在 event-dispatcher.ts 中保留 thread scope 与原话题锚点。
2. 本 PR 将 beginReplyTargetTurn() 的 replyTargets[turnId] 写入移到 scope 早返之前，因此 thread-scope 轮也会持久化 { substitute: true, senderOpenId }。
3. isSubstituteTurn(ds, turnId) 优先读取该 map entry，于是同一 thread-scope 轮由原先的 false 变为 true。
4. worker 的 ready 与 screen_update 都携带该入站 turnId，并分别经过 streamingCardDisabled(ds, msg.turnId)；初始卡会被跳过，后续卡创建/PATCH 也会被跳过。
5. substitute control card 明确只补偿 scope === 'chat'；noteTurnReceived 虽通常会用反应补反馈，但配置 silentTurnReactions 后同样被关闭。因此该组合可以整轮没有状态反馈。

最小探针在当前 head 得到：

{"scope":"thread","replyTargets":{"om_turn":{"substitute":true,"senderOpenId":"ou_sender"}},"isSubstituteTurn":true,"isSubstituteWithoutTurn":false}

现有相关测试 53/53 通过，但没有覆盖 thread scope + substitute=true + exact turnId 这一组合。

建议把 scope 约束集中到卡片抑制判定：最小改法是让 isSubstituteTurn 接受 scope，顶部对非 chat 返回 false，并把注释改成“是否为会关闭 streaming card 的替身轮”；补一条 thread-scope substitute 返回 false 的回归测试。若希望保留 helper 的字面语义，也可在 streamingCardDisabled 与 streamingCardDisabledFor 两处写 ds.scope === 'chat' && isSubstituteTurn(...)，但需要两处同步维护。

🟡 policy 需明确确认

删除多人会话 --mention-back 门禁的技术论证是自洽的：命令语义确实是回复本轮真实 sender，per-turn sender 也比让模型重建 open_id 更确定。但这是对已合入保守策略的反转，合并前仍需要维护者明确确认；本次没有执行合并。

验证：

• pnpm build：通过
• git diff --check origin/master...HEAD：通过
• pnpm exec vitest run --project unit test/reply-target-fallback.test.ts test/turn-reactions.test.ts test/substitute-control-card.test.ts：3 files / 53 tests passed
• PR CI / CodeQL：当前均通过

[deepcoldy]

补充修正前一条 review 的修法建议：只在 isSubstituteTurn() 对非 chat scope 早返并不完整。

cli.ts 的 footer 寻址还会直接读取 pickTurnReplyTarget(...).substitute，不经过 isSubstituteTurn()。当前 head 的 thread-scope map entry 一旦带上 substitute: true，buildFooterAddressing() 就会从普通 thread 语义的 owner 寻址切到 substitute 分支的 last-caller 寻址。最小探针结果：

{
  "turnReplyTarget":{"substitute":true,"senderOpenId":"ou_sender","turnId":"om_turn"},
  "masterLike":{"sendTo":"ou_owner","cc":[]},
  "polluted":{"sendTo":"ou_sender","cc":[]}
}

因此更准确的主修应放在写入边界：beginReplyTargetTurn() 对 thread scope 仍写 senderOpenId + updatedAt，但不持久化 chat-scope 专属的 quoteOnly/substitute；这样 --mention-back 所需 sender 不丢，卡片和 footer 两个读取点同时恢复原语义。

建议同时保留两处纵深防御，以覆盖历史/异常污染 entry：

• isSubstituteTurn()：非 chat scope 返回 false；
• footer isSubstitute：显式要求 isChatScope。

回归测试应分别锁住卡片判定与 footer 寻址两个读取点，并确认 thread-scope entry 仍保留 sender、但不带 quoteOnly/substitute。

[deepcoldy]

增量复核结论：thread-scope 写入边界已收敛正确，rootMessageId/quoteOnly/substitute 不再落入 thread per-turn entry；isSubstituteTurn 与 footer 的 scope 守卫也能兼容已有污染记录。人数门禁主链同样是 fail-closed：bot 触发按精确轮次短路，人类/未知触发在多人群中校验人数，统计或动态导入失败均拒绝。

仍有 1 个 sender 归属缺口需要补齐：startInitialPassthroughSession 的 thread caller 已经用 isForeignBot（含 isKnownPeerBot cross-ref 兜底）识别了 bot，并把它传入 botSender；但函数内部在 initialPassthroughSender.type、quoteTargetSenderIsBot、beginReplyTargetTurn(...senderIsBot) 及 registration-loser handoff 四处重新只看 parsed.senderType === 'app' || 'bot'。当飞书 sender_type 缺失/变值但 cross-ref 已识别 peer 时，其它 thread 路径均按 bot 处理，唯独冷启动 passthrough 会把本轮持久化成 human，导致多人群中的 --mention-back 再次进入人数门禁并被拒绝。

建议把 quota 使用的 platform-stamped botSender 与回复归属使用的 senderIsBot 分开传递：new-topic caller 传其完整 bot 判定，thread caller 传 isForeignBot，函数内上述四处统一使用 senderIsBot。这样既补齐 bot→bot 放行，也不扩大 quota 信任边界。

验证：pnpm build 通过；相关 13 个测试文件共 193 tests 通过；当前 GitHub build / CodeQL checks 全绿。

[deepcoldy]

复核通过。此前两项阻塞均已闭环：

• thread-scope per-turn entry 只持久化 sender attribution，不再携带 chat-scope 的 rootMessageId/quoteOnly/substitute；卡片与 footer 两个读取点均有 scope 纵深防御。
• senderIsBot 按轮传递；冷启动 passthrough 现在把 quota 的 botSender 与 reply attribution 的 senderIsBot 分离，并在 primary path、quote legacy slot、pending sender、registration-loser handoff 四处统一使用 caller-resolved 值。thread caller 使用 isBotSenderType || isForeignBot 合理：该字段判定“是否 bot”，不会扩大 quota 信任边界；self echo 与缺失 open_id 分别由 dispatcher / mention-back hard gate 收口。
• bot 触发直接跳过人数查询；human/unknown 触发在多人群走人数门禁，统计软失败及导入异常均 fail-closed。
• 6a84833 已同步此前遗漏的 registration-loser source assertion。

独立验证：git diff --check 通过；pnpm build 通过；相关 14 个测试文件共 269 tests 全绿。当前 head 可批准；合并仍应遵循既定的产品策略确认与 CI 门禁。

[deepcoldy]

ef92513c3 的主路径和定向测试是绿的，但当前“窗口近似只会偏宽、不会漏禁”的不变量还没有成立，需补以下问题后再合并：

1. 参与者窗口缺失时会 fail-open。 collectTurnWindowParticipants() 在 turnId/map/anchor/participants 不可用时都返回 []，而 mentionBackAmbiguity([]) 把它当成“明确 0 人”并放行。此时 pickTurnReplyTarget() 仍可能从 per-turn/legacy sender 槽拿到 senderOpenId，所以升级中正在执行的旧轮、旧持久化记录等场景会绕过歧义门禁并自动 @。请区分“窗口完整且只有一人”和“窗口未知/不完整”；后者在 group 中应 fail toward explicit --mention/--no-mention。

2. 非 open_id 形态的 @ 参与者被直接漏掉。 parseEventMessage() 明确让 app_id mention 的 openId 为 undefined（test/message-parser.test.ts 已锁定），而 buildTurnParticipants() 对 !m.openId 直接 continue。因此“真人 sender + @Otherbot（app_id 形态）”只留下真人一个 participant，窗口非空且 distinct=1，仍放行 --mention-back；空窗口守卫也兜不住。user_id/union_id 形态同理。请保留并解析这些身份，能换成当前 app 可用 open_id 就作为候选；无法换出时至少把窗口标成 incomplete 并阻止自动 @，不能把它当成未参与。

3. 32 条裁剪会产生“部分窗口”，不只是空窗口。 当前 worker 没有 32 条 type-ahead 深度上限，且 Codex 可把连续输入 steer 进 active turn。90 秒内 A 先发一条、B 再发 32+ 条时，A 的 entry 可被裁掉，而当前 B anchor/participants 仍存在；collector 返回非空单人 B，仍会误放行。请持久化窗口完整性/裁剪水位，或维护不会因 per-turn entry 淘汰丢参与者的 rolling aggregate。只对空数组 fail-closed 不能覆盖该路径。

另外请一并修正候选元数据与仓库规范：sender participant 当前不带 name；isKnownPeerBot() === false 也只表示“不是已知 peer”，不能证明是人，第三方 bot 会被标错；未知类型应诚实显示为未知。src/core/reply-target.ts 新注释中的真人姓名/内部批准描述不应进入公开源码，请改成中性技术表述。

独立验证：pnpm build 通过；相关 5 个测试文件 206/206 通过；git diff --check 通过。现有测试把 participants: [] 断言为放行，且没有覆盖 app_id mention、部分窗口淘汰和未知类型，因而没有捕获上述 fail-open。

[deepcoldy]

c10c80a55 的共享裁剪 helper + prune watermark 方向是对的，但当前 incomplete 闭环仍有以下缺口：

1. 旧 schema 的 anchor 仍会假 complete。 collectTurnWindowParticipants() 只在 anchor 不存在时置 incomplete；若旧持久化 entry 是 { updatedAt, senderOpenId }、没有 participants/participantsIncomplete，会返回 {participants: [], incomplete: false}，随后放行 --mention-back。现有测试测的是“anchor 完全不存在”，不是这个升级场景。窗内 entry 有 sender 但缺 participants 字段时应置 incomplete，并把已知 senderOpenId 合成可执行候选；legacy slot 只有 sender 的路径也要把该 sender 交给错误提示。

2. app_id 形态的 self mention 会误拦正常单人轮。 helper 只能按 m.openId === selfOpenId 排除当前 bot；parser 对 app_id mention 保留 openId: undefined 且 LarkMention 未保存 appId，所以普通 @当前bot 帮我 若 self mention 是 app_id 形态，会落进 !m.openId → incomplete=true。请把 mentionIdentity(m).appId 保进 LarkMention，向 helper 传 self app id，先排除 self app_id；其它不可解析 mention 才标 incomplete。仓库现有 dispatcher 测试已经证明 self/other bot 的 app_id mention 都是支持形态。

3. 缺失 sender identity 也会被当 complete。 buildTurnParticipantsFrom({}, undefined, ...) 当前返回 complete 空集。realtime/message-listener 已有 only-app_id bot sender 路径；若该消息与后续有 open_id 的 type-ahead sibling 同窗，未知 sender 被漏掉，窗口可能剩单人并放行。该 helper 只服务真实入站消息，无法得到 sender open_id 时也应置 incomplete（明确识别为 self 的 sender除外）。

4. sender 三态在 caller 处仍被压成 boolean。 new-topic/existing/auto-create 传的是 isForeignBot*；sender_type 缺失/异常且 cross-ref 未命中时得到 false，于是错误列表仍标“人”。应把路由/owner 用 boolean 与展示身份分开：平台 app/bot 或 peer→true，明确 sender_type=user→false，其它→undefined；initial passthrough 的 fallback 也不要用一个 false-expression 抹掉 unknown。

另有一个持久化缺口：inheritTriggerReplyAnchor() 的新 watermark 只改内存；existing trigger 路径在调用后没有 sessionStore.updateSession()，新增测试也只断言内存。对当前 @ 门禁通常会因磁盘缺 synthetic anchor 而保守拦截，但“第二 writer 的 watermark 可被独立 botmux send 读取”并未成立，建议让 caller 在 arm 后持久化并补集成断言。

本地纯探针结果：legacy anchor=incomplete:false，self app_id mention=incomplete:true，missing sender=incomplete:false；现有相关 6 文件 229/229 通过，说明测试口径尚未覆盖这些边界。PR 当前还与 master 冲突，补丁闭环后需 rebase 再做最终验证。

[deepcoldy]

3b2b41517 已修复上一轮列出的旧 schema、app_id self、缺失 sender、展示三态及 synthetic anchor 落盘问题；build 与相关回归均通过。但 participant 输入仍有两处 fail-open，需要继续收口：

1. [blocking] post inline at 未进入参与者窗口。 路由门 messageMentionsBot 会扫描 post content 中的 inline at，而 parseEventMessage 只把 message.mentions[] 写入 parsed.mentions。post 常见 mentions: [] 时，消息能正常路由，但 buildTurnParticipants(..., parsed.mentions) 只记录 sender。实测 post 同时含 @self(cli_self) 与 @OtherBot(cli_other) 时，当前结果为单一 human participant 且 incomplete:false，因此 --mention-back 被放行。应建立隔离的 participant-only post-at 提取，并覆盖 forward seed + follow-up 两份原始消息；self open_id/app_id 排除，其它 ou_ 进入候选，cli_/未知形态置 incomplete。不要改变通用 parsed.mentions 语义。

2. [blocking] 新增的 LarkMention.appId 没有贯穿 mergeMessageMentions。 该 helper 既未把 appId 纳入 identity，也未像 openId/userId/unionId 一样显式富化。跨消息 mention key 会从 @_user_1 重新编号；若 forward seed 的同名 bot 是 cli_self、follow-up 的同名 bot 是 cli_other，当前会按 key+name 合并并保留 seed 的 cli_self。participant core 随后把唯一记录当 self 排除，得到单人 complete 窗口。探针已复现。identity 应优先包含 app:${appId}，合并字段也应显式保留 appId，并补同名不同 appId 不合并回归。

另请在 participant core 收紧“可执行 open_id”域：仓库已有 structured @all 形态 {open_id:'all'}，当前会把 all 列为候选并建议非法的 --mention all。all/非 ou_ 值应不进入候选并置 incomplete；该校验应覆盖 text 与 post 两条 lane。

本地验证：

• pnpm build：通过。
• 8 个相关测试文件：274/274 通过。
• 独立探针：post inline-at 与同名不同 appId merge 两条均能稳定复现上述结果。

当前 PR 仍与 master 冲突；同意先收敛行为，再统一 rebase，并在 rebase 后 head 重跑 build、定向与全量回归。

[deepcoldy]

7353e1b4b 已正确修复正常路径下的 post inline-at participant lane、mergeMessageMentions 的 appId identity/字段传播，以及 structured/post @all 的不可执行候选问题；但 registration CAS loser 路径仍会丢 forward seed 的 post participants：

• PreparedThreadReply 没有携带 participant raw messages 或已提取的 routing-only mentions；
• new-topic CAS loser 调用 handleThreadReply(..., prepared) 时只传 parsed/resources/attachments/sender；
• winner 重绑本轮时，existingWindow 只从 data.message 提取 post-at。

因此「forward seed post 含 OtherBot + follow-up 仅 self」在正常 new-topic 路径会 incomplete，但只要新 session 注册竞争输给现有 winner，scratch 的完整 window 随 rollback 被关闭，winner 仅按 follow-up 重算，重新得到单 sender complete 窗口，--mention-back 仍 fail-open。

建议在 PreparedThreadReply 中显式携带已提取的 post participant mentions，并让两个 registration-loser handoff 都传递；winner 的 existingWindow 在 prepared 路径消费这份完整 seed+follow-up 集。传已提取 mentions 比传 raw message 更窄，也不依赖 ctx.forwardSeedData 生命周期。需补 handoff 级回归/类型与接线断言，当前 source 测试只锁正常 new-topic call 同时出现 current+seed 两条 raw message，未锁 loser path。

验证：

• pnpm build：通过。
• 9 个相关测试文件：286/286 通过。
• 正常路径纯函数探针：post inline-at、appId merge、@ALL 均已转为预期；剩余问题来自 CAS loser 接线缺失。

另有一个不阻塞本次 merge 的既有路由不一致：纯 post inline cli_self 且 message.mentions=[] 时，participant extractor 能识别 self，但 messageMentionsBot inline 分支只比较 botOpenId、不比较 larkAppId，因此消息本身不会路由；mentionsAnotherMember 也会把它误判为别人。建议独立收口，避免本 PR 继续扩面。

[deepcoldy]

6d5919723 已修复第一处（new-topic）registration CAS loser 的 prepared participant handoff，但声明中的“两个 loser handoff 都携带”尚未完全落地：auto-create CAS loser 构造 PreparedThreadReply 时仍没有传 postParticipantMentions: autoCreatePostAt。

可达性是二次竞争，但仍会重现同类 fail-open：new-topic scratch 输后 prepared 携完整 seed+follow-up；接管 winner 在处理前消失，进入 auto-create，此时 autoCreatePostAt 仍完整；若 auto-create 又输给新 winner，第二次 prepared handoff 丢掉该集合，最终 winner 只从 data.message 重抽 follow-up，forward seed 的 post @ 再次消失。

最小修复是在 auto-create loser handoff 同样传 postParticipantMentions: autoCreatePostAt。测试应分别锁两处 handoff（或断言赋值出现两次）；当前测试只检查 postParticipantMentions: newTopicPostAt，因此没有覆盖第二处。

除此之外该 delta 的提取/消费分层、prepared 空数组通过 ?? 保留、正常 existing/auto-create 回退均核对成立。

验证：

• pnpm build：通过。
• 9 个相关测试文件：287/287 通过。

[deepcoldy]

Pre-rebase 行为复核已收敛：959339b7e 补齐了 auto-create CAS loser 的第二处 postParticipantMentions 透传，两个 handoff 均由测试明确锁定。

本地验证：

• pnpm build：通过。
• 9 个相关测试文件：287/287 通过。
• git diff --check 6d5919723..959339b7e：通过。

当前增量未发现新的 blocking，可以统一 rebase 到最新 master。由于 PR 目前存在真实冲突，本次不提前给 approval；请在 rebase 后 head 重跑 build、全量 unit 与相关定向回归，并对冲突文件做语义 diff 复核，随后再进行最终 review。

[deepcoldy]

已在 rebased head d5d26c14c6585070320cb793886e654941adce3e 完成最终检查，结论：APPROVED，无 blocking。

核对结果：

• range-diff：11 个提交中 9 个补丁等价；其余 2 个差异仅为接入最新 master 的预期变化。cli.ts 冲突分辨同时保留了 master 的 resolveReportPlacement / resolveReportRecipient 与本分支的 collectTurnWindowParticipants，对应 report 与 send 路径均未丢失。
• 总 diff：per-turn sender/participants 写入、thread-scope substitute 卡片与 footer 隔离、90s participant window、prune 水位、旧 schema / 非 executable mention 的 fail-toward-explicit、post inline @、两处 registration-race handoff 均闭合；chat/thread、普通/替身、冷启动 passthrough、trigger 与 p2p 分支的边界一致。
• 影响面：修改集中在 Lark 公共路由与 botmux send mention-back 决策；未改变其它 CLI / backend 的输入输出协议。thread-scope 仅持久化 sender/participants，chat-scope routing metadata 不再外溢。

验证：

• git diff --check origin/master..d5d26c14c：通过
• pnpm build：通过
• reply-target / parser / forward / daemon wiring / passthrough / trigger / send-policy / cli-send 定向：9 files，287 passed
• dispatch / cli-send-dispatch / VC send-policy（覆盖 rebase 冲突邻接路径）：3 files，140 passed
• GitHub CI：build + 全量 unit/workflow-core 全绿；CodeQL actions / JavaScript-TypeScript / Python 全绿；PR 为 MERGEABLE、0 behind master。

已知的 post inline app_id 自 @ 入站路由边界是既有行为，未由本 PR 引入，不阻塞本次合入，建议另行处理。