[dashhuang]

这次改了什么

摘要

宿主自动唤醒伙伴查看进度时，原模板要求卡住就继续、出错就换路线；工作台责任身份与本机工具免审批又使这些建议成为实际干预。本 PR 将默认改为“自动检查，按授权行动”：自动轮次可以读取与提醒，没有具体授权就拒绝跨任务写入。

主人请求使用普通任务原有的权限流程：私聊输入，以及经 Chat Server 实时核验的群内主人请求，不额外弹行动确认卡。群里 @ 自己伙伴后 start_session_task 被当作自动操作拒绝的问题已补回归修复；访客、转入输入和定时跟进不获得同样放行。

已转为正式 PR 进入评审；下列剩余工程与验收事项仍未完成，不代表已通过合并验收。 本次未安装、部署、重启或替换客户端，未修改现用配置、规则、队列或用户数据，未改动产品中在用的自动跟进规则。

变更类型

• fix 缺陷修复
• docs / test / chore 文档、测试或工程维护

范围

• 关联需求：自主跟进的观察责任与执行授权分离。
• v5 内置正文缩短为用户指定的两句话；事件仍是原有不可信数据块。共享指南、工具说明及产品规则同步。
• cindy_helper 直接/渐进工具与 cindy_orca 写操作接入同一 Host admission。Full Access、自动审阅、creator/follower/scheduler、suggested route 均不能生成行动授权。
• taskActionHost 复用 authorizeGroupTool(sessionId, botId, 'owner-action')，仅将通过 Chat Server 实时核验、仍在当前执行中的 owner 群授权视为主人输入。chat / tools 访客、过期/错误伙伴授权及 GROUP_AUTHORIZATION_UNAVAILABLE 不放行。
• 主人输入的 capture 返回 null，不调用额外 confirm；仍沿用原 Agent 权限档/审批。复用原有单次调用上下文保留来源、目标和正文证据，使工作台行动检查、消息队列与新建委托继续正常工作；没有新增通用权限体系。
• 相同门覆盖 helper 的直接/渐进调用和 Orca 写入口，自动轮次没有授权只给建议，不自动弹卡。
• 新建 Session 委托在既有 permission snapshot 中记录 Host 证据，复用其当前运行的消息/停止范围；代答、恢复暂停、路线调整不继承消息授权。历史委托不自动获得新授权。
• 继续/插话/队列与运行设置接入复查；进程内队列守卫不序列化，无法证明授权的已标记自动输入不恢复执行。已发送历史保留。
• 跨电脑 handoff 增加能力探测与临时回执，绑定设备、来源任务、目标和消息，消费前回源复查；同一回执只认领一次。
• 自动发现事项在待办文件的既有写锁内标为 discovered，更新已有事项保留原来源；不做推断式历史批量迁移。
• 明确不包含：服务端修改、生产配置/数据操作、客户端重启/替换、个人版更新、合并、自动合并和部署。
• 用户可见变化：无授权的自动干预被拒；主人自己发起的请求不再被自动行动门误拦，也不再增加一张行动确认卡。
• 兼容影响：跨电脑任务互发要求双方支持新回执；旧发送端/旧接收端明确拒绝，不降级跳过检查。

本轮修复的不变量

• 观察不能创造执行权：set_workbench_task_responsibility 同样经过 Host 写入门，自动轮次不能先接手再扩大读取范围。
• 已有委托按自身生命周期失效：取消观察规则或例行引擎尚未启动不撤销显式委托；仍检查任务、动作、当前 runSequence 与暂停状态。普通 Lead 的 Worker 回报只延续其当前 active team，经数据库归属核验，不放行无关 helper 操作。
• 新正文必须有对应来源证据：可信主人编辑队列时按新正文重绑；访客、Agent 或旧快照不能据来源标签造授权。用户原话封装与授权回执绑定同一最终 wire 正文。
• 已消费回执不占 pending 配额，也不恢复执行：复用已有派发、插话接受和丢弃回调释放远端回执；发送端删除后明确返回 released: true 才释放接收端认领。重复、取消、未知结果/断线分别保持拒绝或原 TTL 兜底；旧端普通验证成功不算释放确认。没有新增缓存、数据库、锁或重试系统。

插话授权收敛检查点

不变量：一次写入在 admission 后跨越异步等待，仍须在产生副作用前复核同一 Host 授权。已有队列正文的投递证据，不能替代本次“提前插话”动作的授权。

• 授权状态由现有 taskActionHost / 调用上下文持有；输入队列、插话标记与失败清理由现有 AgentInputCoordinator 持有，没有新增状态存储、锁或重试机制。
• sessionControlService 的插话、队列编辑/撤回、停止与运行设置复用 combineInputGuards，把原调用方检查与当前行动检查组合起来。新插话把组合检查继续交给 expectedTurn。
• 共享插话边界对新输入和已有队列提升均复查当前工具授权，并经现有 MCP_APP_MESSAGE_GUARD 传到最终 beforeProviderStart。授权失败沿用原拒绝与清理分支，不生成重发。

事件 / 路径	授权仍有效	授权已撤销
外部输入检查、正文构建、Host 检查返回	保留能力/目标轮次判断后继续	抛出授权失效，尚未发送
新插话 / 已有排队消息转插话，经过内容检查或引用解析	原轮次、暂停与停止条件仍适用	不进入供应商发送；已有队列项原位保留
最终供应商发送前再次检查	沿用原有发送及 ACK 流程	不接受输入，不回退新一轮、不自动重试
目标轮次结束 / 替换、暂停、未知 ACK	沿用现有协调器状态与回执	不因授权检查恢复旧输入或重复发送

元数据写入与回执收敛检查点

不变量仍是“异步准备结束后、产生副作用前复查同一授权”。本轮 e1946c2a38 复用现有 assertTaskActionCurrent 和既有写入回调，没有新增权限档、锁、缓存或重试系统。

路径	本轮落实的边界
批量改名	SELECT 返回后、标题标记和事务之前复查
本机归档 / 恢复	路由与工作目录锁内，回收意图写入前及最终状态事务前复查
移动任务	目录 / 任务 / team 异步读取结束后复查；Codex/Pi 空闲 runtime 关闭前也复用 beforeWrite；最终 DB 写入仍再次检查
远程批量状态	每项 invoke 前复查；授权失效则保留已完成项回执并停止后续项，不伪造回滚
远程消息回执	确定未发送或目标明确拒绝立即释放；已排队、在途断连、未知结果、远端写后回执查询拥塞保留；260 次未发送失败不耗尽 256 配额

远程状态工具的检查不等于已经覆盖连接建立后到接收端最终写入的所有撤销窗口；这一限制在下方保留。既有已提交副作用不回滚，未新增自动重发。

创建与 Orca 共用授权检查点（第四轮）

不变量：已经通过 admission 的操作，在异步准备返回后仍须持有原调用的有效授权；授权失效不能产生新的子任务执行或 Orca 派发。授权事实仍由 taskActionHost 持有，资源和失败收口仍由原创建/Orca 服务持有。

本轮将同族问题收拢到既有边界：start_session_task 使用 openSession 的提交回调；Orca 将当前调用的校验闭包接入所有生命周期/控制入口已共用的 captureOrcaPluginAuthority。无需给每个 MCP adapter 另造状态，也没有新锁、缓存、数据库或重试机制。闭包在调用上下文结束后的排队接受中仍检查原授权。

事件	授权有效	授权撤销 / 迟到结果
模型/工作区准备返回	提交任务与委托快照	提交前拒绝，释放未提交的预建工作区
创建事务返回	沿用原投递流程	标记创建失败，不启动子任务；保留已提交记录
Orca team 查询返回	按原模式创建/复用	不创建团队或 Worker
团队角色写入 / Worker 创建返回	继续激活/派发	不设置运行时或发首条消息，沿用原失败补偿
send/interrupt 的目标查询、排队接受	保留原归属、队列与派发规则	拒绝写入，不启动、不打断、不补发
queue edit/cancel/merge/steer/move、idle/end/archive	共用原 control authority 检查点	同一原调用授权失效即拒绝；不新增恢复路线

重复调用仍由现有单次 admission 拒绝；超时、断连与部分已提交结果仍走原服务的失败/回执分支，不自动重试或伪造撤回。范围复核：上一轮增长主要来自授权回归测试与既有写入/回执回调的接线；本轮继续使用这些生命周期，没有扩展成通用权限系统。删除本轮接线会使已复现的撤销后创建/派发再次发生，因此只保留这些必要检查点。

委托控制与 transport 收敛检查点（第五轮）

两条 P1 同属“异步等待后沿用旧来源”失败族。唯一授权 owner 仍为 taskActionHost：来源输入代次、账号、群执行和委托范围由它判断；委托状态与补偿仍归既有 botDelegationService，发送排队归既有 device-link。没有增加锁、缓存、持久化或重试机制。

本轮把行动检查组合进 resolveCaller 返回的既有 mutation authority，使代答、消息/队列、暂停/取消、恢复、路线变更共享原检查点与原补偿分支，并删除创建路径的重复行动检查；不为每个工具另建判据。延迟接受处将行动失效转换为原有取消派发信号，防止普通回调异常被吞掉后继续发送。远程状态复用 transport 的同步 preSend，捕获原调用的同步来源检查；逐项异步完整检查仍保留。

事件 × 状态	有效授权	来源已替换 / 撤销
代答目标读取返回	原同步 resolver 执行	拒绝，不代答
停止/暂停在 reservation、目标读取后	沿用原原生停止	尚未执行则撤销本次意图，精确恢复原暂停/hold；不覆盖新状态
恢复在准备、flush、提交、释放后	原 receipt 防重复	保留原暂停与已接受回执，不开始下一轮；主人可明确重试
路线检查返回及最终 beforeMutation	原目标/路线校验继续	不改模型/账号
已获准的暂停写入自身意图	允许同一次停止完成	新调用仍被暂停阻止；换 runSequence 后旧调用失效
远程 invoke 的排队/连接等待返回	preSend 核对来源后发送	明确未发送，停止后续项；先前成功回执保留并去除私有元数据
发送后的超时/断连、部分成功、重复或迟到回执	原未知结果/一次消费规则	不假报未执行、不重发、不伪造撤回

对称审计覆盖成功、拒绝、暂停/撤销、输入替换、迟到与重复。范围复核：本轮收拢到原 coordinator 回调，没有新状态存储；若删除这些接线，已定位的私聊控制与 transport 等待窗口会重新出现。接收端最终事务前的来源撤销窗口仍列为限制，不为补齐该窗口新增远程权限机制。

UI 变化

• 首版草稿保留的权限桥及五语文案未扩展；本次主人请求绕过额外卡片，普通权限模式和 Orca Full Access 升级等既有确认保持原样。
• 引用的设计规范：docs/design-rules/DESIGN.md §2 与 §10，复用既有语义 token 和双主题组件，没有新布局、颜色或尺寸。
• Light / Dark 均未实机目检；没有启动或接管正在使用的客户端。

Orca 写入口分类收敛检查点（第六轮）

不变量：会修改协同持久状态或恢复 Worker 的工具必须进入同一行动授权门，工具名里的 focus 不代表只读。唯一授权判据仍为 taskActionHost；焦点写入与恢复仍由原 Host adapter / Orca 生命周期负责。本轮生产代码仅将 switch_focus 加入既有集合，无新状态、锁、缓存、持久化或重试机制。

核对全部 20 个 Orca 注册工具：14 个写工具受同一门保护；list_workers、get_worker_queue_status、list_available_models、get_workspace_info、worker_status、read_worker 6 个读取入口保留原可见范围。焦点 adapter 已复用 captureOrcaPluginAuthority，在列表返回后、写焦点前及恢复空闲 Worker 前复查来源，无需另加检查体系。

输入 / 状态	switch_focus 结果
自动跟进、转入输入、群访客、失效/不可用群核验	admission 拒绝，不调用焦点/恢复 Host callback，不弹卡
私聊主人、实时核验的群主人	原权限流程直接继续，不额外确认，保留调用授权
普通 Lead 收到自己 active team 的 Worker 回报	复用已有 team 范围；不获得其它任务写权限
admission 后来源撤销 / 迟到	原共用 lifecycle guard 拒绝继续；不新增恢复或重试路径

回归通过真实 createOrcaMcpServer 注册的 DirectToolSink handler 验证自动拒绝及主人请求放行，并扩展现有群授权/委托矩阵；修复前有 11 项失败，能识别上一版仅遍历行动集合却漏掉工具的缺口。当前剩余验收事项见下方，未因本轮修复宣称全部完成。

怎么验证的

自动验证

2026-10-20 第六轮 review 跟进：只补齐 switch_focus 的已有写操作分类，处理一个 P2 技术 thread。

• pnpm --filter desktop exec vitest run src/main/maker-ipc/__tests__/taskActionAuthorization.test.ts src/main/maker-ipc/__tests__/orcaTeamService.test.ts --maxWorkers=2：222 项通过，2.88s。
• taskActionAuthorization.test.ts 最终夹具独立 25 项通过，1.63s；修复前同文件 11 失败 / 14 通过。生产入口、最小输入、覆盖缺口及 unit tier 见上方检查点与测试注释。
• pnpm check:test-hygiene 368 文件基线通过；pnpm check:dev-docs 10 项通过；git diff --check 通过。首次 Desktop typecheck 抓到新测试夹具的缺失依赖与上下文字段，已补全为类型完整的依赖；最终 pnpm --filter desktop run typecheck 通过，退出码 0。
• 本轮初始 PR 快照 23 个检查中 22 个已结束、1 个 CodeQL 运行中，0 失败；新提交仍需新 HEAD 的 CI，不混同本地验证。

2026-10-20 第五轮 review 跟进：修复两条 P1 和 Linux/Windows 单测分片暴露的测试装配遗漏，基线仍为 064354193a，本轮未重做 rebase。

• 将新增交错用例置于旧生产模块：远程归档/恢复、委托代答与路线切换共 4 项失败，分别出现撤权后仍发送/写入。恢复实现后通过；暂停、取消、恢复覆盖复用现有 group 矩阵扩展到 private action。
• 7 文件定向回归 1,441 项通过，26.91s；随后合并创建重复检查并补接受异常转换，botCanonicalSession.test.ts 581 项通过，26.06s。此前其它 6 文件无需重跑；不把两个运行的重复用例相加。
• 首次类型检查抓到新增测试变量作用域错误，已修正；后续 Desktop typecheck 已通过，最终收口后的 pnpm --filter desktop run typecheck 再次通过（退出码 0）。
• CI 原因：orcaWorkerCreationService.test.ts 和 pluginStartTeamAdmission.test.ts 提取真实注册函数时未绑定新增 captureTaskActionGuard；均接入真实 helper，保留所有原断言。旧 HEAD 的 CI 仍红，新提交结果待 CI。
• check:test-hygiene 368 文件基线通过，check:dev-docs 10 项通过，git diff --check 通过。未运行整仓或实机端到端测试。

修改的测试文件	生产入口 / 缺口 / 最小失败输入（均 unit）	独立实测
taskActionAuthorization	真实 Host adapter，输入/账号/群执行变化使同步 preSend guard 失效；已获准暂停能完成自己意图，新调用与新 runSequence 不能继承。原异步 guard 用例未覆盖同步边界。	24 项，1.26s
sessionStatusRemote	真实 setter 的 transport preSend；第 1 项成功，第 2 项连接等待期间撤权：不发送且保留/净化先前回执。原用例只覆盖两项之间的撤权。	31 项，693ms
botCanonicalSession	真实委托服务 + SQLite + 接受 adapter；等待期间撤权不得代答、停止、恢复、改路线或延迟派发，已写意图按原 CAS 补偿。原 group 用例没有 private action 变体。	581 项，26.06s（既有大文件：收集 9.85s、执行 15.87s；复用 fixture，无新模块重载或真实等待）
orcaWorkerCreationService	保留真实注册回调的既有 creation/permission 覆盖，修复函数依赖遗漏，不新增重复用例。	378 项，5.69s（收集 4.01s、执行 1.36s）
pluginStartTeamAdmission	保留 public start_team 的已有普通/插件权限矩阵，绑定真实检查函数。	114 项，3.20s

以下为此前验证记录，保留其对应范围与限制：

2026-10-20 第四轮 review 跟进（8b6149fce8）：同步至已获取的 origin/main 064354193a，原 5 项提交 range-diff 均为相同补丁；集中修复当前两条技术反馈。

• 先红后绿：创建期间撤权、Orca team/Worker 查询期间撤权共 3 个断言在旧实现失败；send/interrupt 的查询与延迟接受共 4 个断言在旧实现失败。另补已提交创建的失败收口、团队激活/Worker 创建后的补偿验证。
• 同步主干后的定向 vitest run：4 文件、906 项通过，25.95s，覆盖 botCanonicalSession、orcaLifecycleService、orcaTeamService、taskActionAuthorization。最终 Orca 小幅接线整理后，两文件 314 项再次通过（3.30s）。
• 首次 desktop typecheck 发现新增测试的两个联合 Promise 推断错误，已改为 async 回调；最终 pnpm --filter desktop run typecheck 退出码 0。
• pnpm check:test-hygiene 通过（368 files within baseline），pnpm check:dev-docs 10 项通过，git diff --check 通过；DCO 6 个提交通过，preflight 无 BLOCK；upstream 分叉仅来自已核对的 rebase。
• 原 HEAD e1946c2a38 的 Linux/Windows 单测分片均已通过，上一轮飞书上传的 Windows 失败未重现；本轮新 HEAD 仍以新 CI 为准。

文件	生产入口 / 缺口 / 最小失败输入	Tier / 独立实测
botCanonicalSession	admitTaskAction → 实际 startSessionTask + SQLite 创建事务；原覆盖只撤销权限档，未撤销行动来源。准备/事务返回时撤销，验证无新行或已提交失败、无启动及预建资源清理。	既有 standard tier 的 DB 运行时集成文件；571 项、24.68s（收集 11.03s、测试 13.31s）。沿用数百个持久化/生命周期用例的文件级 fixture，新增 3 项没有模块重载或真实等待；未为本修复拆分或迁移整份存量大测试。
orcaLifecycleService	实际 Host authority capture → lifecycle；原覆盖只有插件撤权。查询/激活/创建返回时撤销当前输入，验证无创建或沿用补偿，且不派发。	unit；117 项，3.93s
orcaTeamService	实际 Host capture → send/interrupt → 延迟接受；原插件矩阵未覆盖普通行动来源，最小输入为查询/接受期间撤权，验证无派发、队列和 Worker 状态保持。	unit；197 项，3.89s

2026-10-20 第三轮 review 跟进（e1946c2a38）：处理两条现有技术反馈，并核查同类本机 / 远程批量入口。

• 回归先红后绿：改名/归档/移动撤销与回执泄漏共 11 项先失败；对称的 Codex/Pi 关闭前检查及远程批量下一项检查另有 3 项先失败。旧错误断言经过校正后，Codex/Pi 用例确实以“仍关闭了 runtime”失败。
• 定向 vitest run：8 文件、246 项通过（11.51s）；最终回执保留矩阵补一个未知 timeout 输入后，两文件 47 项通过（687ms），回执文件最终单独 18 项通过（765ms）。合计当前覆盖 247 项，不把重复运行累加。
• pnpm --filter desktop run typecheck：退出码 0。pnpm check:test-hygiene：368 files within baseline；pnpm check:dev-docs：10 项通过；git diff --check 通过；DCO 5 个提交通过，preflight 无 BLOCK。
• 旧 HEAD cf41c7b1c5 的 Windows unit (2/4) 在 outboundFile.test.ts 首个上传用例超出 5s；同文件注明 Windows 会启动 PowerShell 编译辅助程序，失败文件与本轮主干一致，PR 没有修改 lizi-im。没有 Windows 本地复现证据，不能宣布该 CI 已修复；不混入飞书代码改动，不盲重跑，等待新 HEAD CI。

文件	真实入口 / 旧覆盖缺口 / 最小失败输入	Tier / 独立实测
renameSessionTitlesInDb	action admission + 实际批量 writer；SELECT 期间更换输入，验证无标题事务和广播；原测试只有 DB 标题冲突。	unit；2 项，4.32s
setSessionsStatusInDb	实际归档/恢复 writer；读取或 recycle 等待时撤权，验证无状态提交、关闭和广播；原测试只有生命周期与账号边界。	unit；37 项，4.70s
moveSession	真实 MCP adapter；取得锁/提交前替换输入，验证不保存；原测试只有远程账号权限。	unit；32 项，438ms
sessionsUpdate	实际 DB 更新入口和内存 SQLite；Codex/Pi beforeWrite 拒绝时不关闭 runtime、cwd 不变；原测试只在关闭后撤权。	unit；93 项，11.11s（既有删除扫描测试约 7s，无新增真实等待或模块重载）
sessionStatusRemote	真实远程批量 setter；第一项成功后输入失效，第二项不发，第一项回执保留；原测试仅核账号变化。	unit；29 项，576ms
sessionHandoffRemote	真实 sender + receipt 验证；确定未发送/拒绝释放，未知/在途/排队保留，260 次失败后仍可发送；原矩阵只断言错误码。	unit；最终 18 项，765ms

2026-10-20 第二轮 review 跟进（历史 HEAD cf41c7b1c5）：同步到已获取的 origin/main 82cf0119e0，原三项提交的 range-diff 均为相同补丁；本轮只修插话期间授权撤销和两处旧签名守卫。

• 修复前最小回归先红：service 的 4 个等待边界均会错误成功；coordinator 的新输入/队列提升在内容检查后撤销有 2 项失败，最终供应商回调前撤销另有 2 项失败。
• rebase 后 pnpm --dir apps/desktop exec vitest run <sessionControlService / agent-input-coordinator / taskActionAuthorization / sessionQueueControl / mobileClientPromptNote.contract / sessionRuntimeControlWiring> --maxWorkers=2：6 文件、683 项通过，12.64s。
• 两处 CI guard 仍验证真实 IPC 来源盖章，只将旧 stampQueuedEditProvenance(updated, ...) 签名更新为带目标 sid 的签名；未跳过或削弱检查。上一提交的 Linux / Windows 全部 8 个单测分片已通过；本次推送后仍以新 HEAD CI 为准。
• pnpm --filter desktop run typecheck：rebase 后最终代码通过，退出码 0。
• pnpm check:test-hygiene 通过（368 files within baseline），pnpm check:dco 4 个提交通过，git diff --check 通过，preflight 无 BLOCK。

文件	生产入口 / Bug / 覆盖缺口 / 最小输入	Tier 与独立实测
sessionControlService.test.ts	#6399 新 review；真实 action admission + service。旧测试只覆盖目标轮次变化，新增外部输入检查、正文构建、最终回调与调用方检查期间撤销，验证不接受插话。	unit；22 项，1.10s
agent-input-coordinator.test.ts	真实 coordinator + action admission；原队列证据仍有效但当前提升动作已撤销，内容检查/供应商发送前交错均须不发送、不重试且保留已有队列行。	unit；536 项，独立总耗时 10.91s（用例 6.46s、收集 4.23s）。既有大型生命周期文件只增加 4 个表驱动输入，无新文件、模块重载或真实等待；未为本修复迁移无关测试。
mobileClientPromptNote.contract / sessionRuntimeControlWiring	原来源/权限跨文件 guard，仅跟随新增目标参数修正调用合同，保持两个编辑入口都必须重新盖章。	guard；本轮 9ms / 49ms

2026-10-20 第一轮 review 跟进（历史验证）：基于 origin/main 5bf0a6e353 rebase，保留主干 #6514 的用户原话封装及本 PR 授权边界，修复 6 个技术 review thread（远程回执问题有两条重复反馈）。

• pnpm --filter desktop exec vitest run <以下 17 个文件> --maxWorkers=2：1258 项通过，15.91s。覆盖本轮 CI 报错文件、Host 授权、群授权、队列、Orca、消息来源和远端投递。
• pnpm --dir packages/lizi-mcps exec vitest run <以下 6 个文件>：80 项通过，1.06s，验证 helper 的直接/渐进调用与 Orca 工具路径。
• pnpm --filter desktop run typecheck：通过（退出码 0）；最终生产代码再运行一次仍通过。
• pnpm check:test-hygiene：通过（368 files within baseline）；pnpm check:dev-docs：10 项通过；git diff --check：通过。
• pnpm check:dco：3 个提交签名通过；git skill preflight 无 BLOCK。
• taskActionAuthorization.test.ts 单文件 21 项，1.06s；sessionHandoffIpc.test.ts 单文件 15 项，779ms。新用例并入既有文件，模块只加载一次，无真实等待。
• CI 原来的 bindTaskActionInput / assertTaskActionCurrent / getTaskActionInputState 缺失来自生产代码切片/模块 mock 未提供新依赖；本轮接入真实 helper 或对应宿主事实，保留原有权限与来源断言。sessionControlService 的 runtime patch 断言包含新增的 beforeMutation，没有删弱测试。

Desktop 文件：taskActionAuthorization、agent-input-coordinator、sessionHandoffIpc、sessionHandoffRemote、messageSourceNote、pluginTaskAuthorshipWiring、botDirectMessageService、sendToSessionLazyResumePermission、sessionControlService、collabSendOutcome、botGroupToolAuthorization、botWorkbenchAccess、taskToolCallAuthorizer、mcpToolApprovalPolicy、chatServer、orcaLifecycleService、orcaInterAgentDispatcher。
MCP 文件：botWorkbenchTool、lizi_xdtHelperMcpServer、botCapabilitiesTool、getCapabilitiesTool、startTeamTool、createWorkersTool。

本轮回归价值：

文件	失败输入 / 原覆盖缺口 / 真实入口	Tier 与实测
taskActionAuthorization.test.ts	自动轮次接手责任、已有委托但跟进未启用、Lead 收到 Worker 回报；真实 Desktop authorizer + 工具调用，验证限定范围、执行前撤销及不弹卡。原 owner 用例没覆盖已有执行委托。	unit；21 项 15ms，单文件 1.06s
agent-input-coordinator.test.ts	已授权排队输入经主人改正文；实际 IPC finalizer + coordinator 的 updateText/updateContent/dispatch，主人正文送出，访客编辑不获授权，来源保留。	unit/权限 wiring；532 项 7.862s（既有大文件）；新添 3 项，无新文件
sessionHandoffIpc.test.ts	260 条依次接受并消费的远端消息，原来只测入队接受而不释放；真实发送/接收/回执/队列 guard，排队前后重放都拒绝，绑定包含主人原话的最终正文。	unit/protocol；15 项 20ms，单文件 779ms
messageSourceNote / pluginTaskAuthorshipWiring / botDirectMessageService / sendToSessionLazyResumePermission / collabSendOutcome / sessionControlService	原有真实入口/生产切片接入新增授权依赖，恢复 CI 对消息来源、懒恢复权限档和 runtime patch 的原断言，未新增重复用例。	原有 tier；本轮分别 48 / 89 / 238 / 8 / 53 / 10ms

以下为上一轮已完成的验证记录，不替代上面当前 HEAD 的结果：

本次基于 fetch 后的 origin/main（6a6ad571ad）完成 rebase；解决语言文件和协议文档冲突时保留双方新增内容。

• pnpm --dir apps/desktop exec vitest run … --maxWorkers=2：907 项通过（14.69s）：taskActionAuthorization、botGroupToolAuthorization、botWorkbenchAccess、taskToolCallAuthorizer、agent-input-coordinator、sessionHandoffIpc、sessionHandoffRemote、mcpToolApprovalPolicy、chatServer。
• pnpm --dir packages/lizi-mcps exec vitest run …：80 项通过：botWorkbenchTool（10，558ms），lizi_xdtHelperMcpServer / botCapabilitiesTool / getCapabilitiesTool / startTeamTool / createWorkersTool（70，1.95s）。
• 回归先红后绿：修复前新增用例有 3 项失败，分别是私聊多确认、群内主人被拒及群内主人投递凭据缺失；最终 taskActionAuthorization.test.ts 单独 19 项通过，1.82s。
• pnpm --filter desktop run typecheck：最终提交前再次运行通过（退出码 0）。
• pnpm --filter @cindy/mcps run --if-present typecheck：该包无此脚本。本次仅改工具说明，类型依赖由 Desktop typecheck 覆盖；该包首版 build 的 10 条既有类型诊断曾在当时 main 副本复现，本轮未重跑该独立 build，不声明它已修复。
• pnpm check:test-hygiene：通过（368 files within baseline）。pnpm check:dev-docs：10 项通过。git diff --check：通过。
• 首版已完成的补充验证（本轮未重跑）：Scheduler routines 36 项，Todo / followUpPrompt / autonomy runtime 等定向测试，以及 i18n/glossary 检查。以下保留首版测试价值记录，本轮结果以上面命令为准。
• pnpm check:dco：2 个提交签名通过；git skill preflight 无 BLOCK。

本轮实际定向命令：

pnpm --dir apps/desktop exec vitest run src/main/maker-ipc/__tests__/taskActionAuthorization.test.ts src/main/maker-ipc/__tests__/botGroupToolAuthorization.test.ts src/main/maker-ipc/__tests__/botWorkbenchAccess.test.ts src/main/maker-ipc/__tests__/taskToolCallAuthorizer.test.ts src/main/maker-ipc/__tests__/agent-input-coordinator.test.ts src/main/maker-ipc/__tests__/sessionHandoffIpc.test.ts src/main/mcp-integrations/__tests__/sessionHandoffRemote.test.ts src/main/maker-host/__tests__/mcpToolApprovalPolicy.test.ts src/main/maker-ipc/__tests__/chatServer.test.ts --maxWorkers=2
pnpm --dir apps/desktop exec vitest run src/main/maker-ipc/__tests__/taskActionAuthorization.test.ts
pnpm --dir packages/lizi-mcps exec vitest run src/__tests__/botWorkbenchTool.test.ts src/__tests__/toolCallAuthority.test.ts
pnpm --dir packages/lizi-mcps exec vitest run src/__tests__/lizi_xdtHelperMcpServer.test.ts src/__tests__/botCapabilitiesTool.test.ts src/__tests__/getCapabilitiesTool.test.ts src/__tests__/startTeamTool.test.ts src/__tests__/createWorkersTool.test.ts

其中 toolCallAuthority.test.ts 在当前仓库不存在，第一条 MCP 命令实际只选中 botWorkbenchTool；共享权限入口的覆盖来自 Desktop taskActionAuthorization，以及 MCP server 的直接/渐进调用测试，不把未选中的文件计为通过。

测试价值（均 unit）：

文件	规则/缺口与最小失败输入	实测用例耗时
taskActionAuthorization.test.ts	真实 Desktop adapter、群授权登记及共享工具入口；主人私聊/群请求通过且不弹卡，访客/临时失败/自动输入无副作用，委托凭据与队列投递保持可用。旧纯 scope fixture 漏掉群来源及重复确认；最小失败输入是当前群 owner 授权 + start_session_task。另保留原自动权限与一次消费回归。	本轮 25ms；单文件整体 1.82s
agent-input-coordinator.test.ts	授权后排队、随后撤销/恢复旧快照；通过真实协调器验证不投递且下一条用户输入继续	6.238s（既有 528 项大文件，新用例并入而非复制模块）
botTodoStore.test.ts	自动事件自报 assigned；通过真实锁与文件写入验证 discovered、已交办事项保留、事件摄取同规则	386ms
botWorkbenchAccess.test.ts	scheduler/责任身份+无行动授权；读取仍可用而发送无副作用	7ms
sessionHandoffIpc.test.ts	无回执旧端、同回执重放、排队后撤销；接收生产入口只认领一次并再次校验	7ms
sessionHandoffRemote.test.ts	能力探测后发送；保留已发送/未发送/未知结果与账号切换的区分	6ms
mcpToolApprovalPolicy.test.ts	本机继续与发送不再免审；直接与渐进调用一致	7ms
followUpPrompt.test.ts	删除旧主动干预指令断言，仅保留有界、无不可信 bot id 插值；权限行为由真实入口测试负责	1ms

手工验证

自审完整 diff、DCO 与公开内容；未读取或修改真实消息队列、用户待办、运行规则和模型配置。仅在隔离工作区及临时测试目录操作。

未执行的验证与剩余事项

1. 未运行整仓单测、真实 CC / Codex / Pi / SSH / Mobile 和两台电脑互发的端到端验收；本地按仓库规则完成定向验证。本轮已覆盖 Host adapter + 真实群授权登记/验证入口（数据库/账号/例行读取用内存事实替代），尚无真实数据库、登录群聊和多引擎端到端验收，不能据此宣称全链路已证明。工作台原有 canonical 主任务及目标可见范围限制保留；群专线可走其原有独立任务入口，未扩大工作台数据范围。
2. 本轮已补齐新插话与已有队列提升在内容检查、最终供应商发送前的撤销复查。本轮已补元数据写入、移动关闭与本机归档最终检查，以及远程状态批次逐项 invoke 前检查。本轮已将创建提交与 Orca 共用生命周期/控制边界接入同一来源检查，但未完成真实远端 Orca 全链路验收。第五轮已将委托代答/暂停/恢复/路线接入同一 mutation authority，并在远程状态 transport preSend 检查来源。其它最终写入边界仍需逐项收口：未带 Bot 归属的历史自动队列，以及发送后到远程接收端最终写入间的来源撤销窗口。当前 admission 拒绝无授权调用，但不声称所有旧数据与所有异步 sink 已完成封闭验证。
3. 本轮已移除有效委托对内置跟进开关/引擎启动的依赖，并验证当前委托暂停后立即失效。主人输入不加确认卡、普通 Orca Lead 接受其 active team 的 Worker 回报后仍能继续，均已在 Host 入口验证；原生权限 UI 与多轮真实协作的实机验收仍待完成。
4. 跨电脑回源复查需要反向通道可达；旧端互操作、关闭/撤销/重启、接收端重启后的重放与已发送去重须实机验收。临时回执最长一小时，超时排队不自动恢复。
5. 通知事件/引擎回执沿用现有去重；“重要新变化”和同义提醒合并仍由共享指南指导模型，未新增语义去重引擎。

上述剩余工程与验收事项继续保留，进入正式评审不表示这些事项已经完成；不扩大产品授权。PR 跟进仅按用户另行授权执行，不改产品中的例行跟进规则。

风险

风险分类

• system prompt（共享伙伴指南；内置例行正文属于用户段）
• 协议兼容
• 权限 / 安全 / 用户数据
• SQLite / migration（没有 schema/history migration）
• 原生层 / fingerprint / OTA（没有原生变更）

影响与回滚

• 影响范围：伙伴/自动输入发起的任务写操作、排队投递、跨电脑 handoff、自动待办来源。
• 迁移：v5 ensureBuiltin 保留 enabled 选择；旧 follower 不变成授权；已发送记录不删除，无用户数据脚本。
• 回滚：回退代码会恢复旧行为，不能视为安全降级。新版本与旧版本跨电脑不跳过授权；发布需在剩余验收完成后另行决定。
• 存量插件影响：无插件 manifest、批准状态、指纹、包格式或配置迁移。

提交前检查

• 已 review 完整 diff，并列出草稿剩余项
• 每个 commit 带 DCO 签名
• UI 文案注明设计依据及未目检范围
• 未提交凭证、令牌或授权文件
• 已同步受影响文档中的旧结论
• 已记录测试结果、基线故障及未执行项

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-20T09:00:36.861460Z	e0d7395	New commits
🔒 Security Review	✅ Completed 2026-10-20T09:04:54.705291Z	e0d7395	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0430098037

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[greptile-apps]

Confidence Score: 3/5

[High impact] The changes reach companion task actions across local and linked computers.

修复用户编辑后丢消息和 Orca 回报后无法继续派活的问题前，不建议合并。

Findings

1.  用户编辑后消息丢失 ▶
2.  团队回报后无法派活 ▶
3.  已送达消息占满额度 ▶

Fix with agent prompt

### Issue 1
apps/desktop/src/main/maker-ipc/taskActionAuthorization.ts:180-185
用户在界面中修改已获授权的排队消息后，消息会被丢弃。`bindTaskActionInput` 把原始正文固定在闭包里，但 `INPUT_UPDATE_TEXT` 和 `INPUT_UPDATE_CONTENT` 保存编辑时会保留这个旧闭包。任务消费消息时，新正文会触发 `TASK_ACTION_AUTHORIZATION_EXPIRED`，协调器随后丢弃消息。

请在可信用户编辑入口为新正文更新授权证据，不能只在工具侧的 `updateQueuedMessage` 中重新绑定。

### Issue 2
apps/desktop/src/main/maker-ipc/taskActionHost.ts:51-58
普通 Orca 协作中，Lead 收到 Worker 回报后会变成 `ownerInput=false`、`automatic=true`，因为回报来源是 `origin.kind='orca'`。这里因此不再保留普通任务流程，而现有委托检查只接受 `message_session_task` 和 `stop_session_task`。即使用户要求团队完成多轮工作，Lead 此时调用 `send_to_worker`、`create_worker` 或 `end_team` 也会被拒绝，必须等用户重新输入。

请为用户已授权的 Orca 工作保留可核验的委托范围，区分团队回报与自主观察唤醒。

### Issue 3
apps/desktop/src/main/mcp-integrations/sessionHandoffRemote.ts:169-171
成功送达的跨电脑消息也会一直占用待处理回执额度。接收端固定传入 `forceQueue: true`，现有任务路径因此始终返回 `wakeKind: 'queued'`；这里却只在结果不是 `queued` 时释放回执，后续消费也没有释放入口。

一小时内累计发送 256 条消息后，即使它们已全部送达，后续发送仍会报 `Too many pending remote task actions`。建议在确认消费完成后释放待处理额度，同时单独保留防重放记录。

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

本次将自主跟进改为“自动观察，按授权行动”，并为本机工具、队列投递和跨电脑互发增加 Host 检查。

• Automatic follow-up observes tasks but needs permission to change them.
• Cross-computer task messages need a one-use authorization receipt.
• Automatically found to-dos stay marked as discovered.

已知边界与未重复评论的事项：

• dashhuang 已明确承认委托续跑依赖自主跟进开关，列为待补项。
• dashhuang 已明确承认委托代答、暂停及 Orca 异步期间的撤销检查尚未收口。
• dashhuang 已明确列出未带伙伴归属的历史自动队列缺口。
• dashhuang 已明确将跨电脑反向通道、重启与重放列为剩余验收，不以缺少端到端测试单独提出问题。
• 两句话模板是明确要求，共享指南仍说明提醒入口。
• 事件块仍有不可信数据警告；ensureBuiltin 仍保留已有 enabled。
• 工作台要求 canonical，群专线不能到达待办写入路径。
• 已检查的任务写工具均在受保护集合中；待办、提醒及责任记录不等于任务执行授权。
• 输入代数不是每轮递增，未据此认定正常换轮会丢消息。
• 从 JSON 恢复授权失败是明确要求的拒绝行为。

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[工具调用] --> B[Host 检查当前输入]
  B --> C{主人请求或有效委托?}
  C -->|否| D[拒绝行动，只读或提醒]
  C -->|是| E[绑定本次调用证据]
  E --> F{是否跨电脑?}
  F -->|否| G[本机排队]
  F -->|是| H[能力探测并签发临时回执]
  H --> I[接收端认领并排队]
  G --> J[投递前复查来源与正文]
  I --> K[投递前回源复查]
  J --> L[发送给任务]
  K --> L

Loading

_{Reviews (1) · Last reviewed commit: "fix(bots): respect verified owner reques..." · Reviewed by Greptile}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c24ffc6e26

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: cf41c7b1c5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[dashhuang]

本轮收敛检查点（e1946c2a38）：授权不能仅在 admission 检查；跨异步准备后必须在副作用前复查。

• 改名：SELECT → 标题事务；归档/恢复：路由与资源锁 → recycle 意图 → 状态事务；移动：异步目录/team 校验 → Codex/Pi 空闲 runtime 关闭 → DB 写入。均复用现有 guard / beforeWrite。
• 远程批量状态：逐项 invoke 前复查，保留已经完成的项；连接等待到远端最终写入的撤销窗口仍列为已知限制。
• 消息回执：确定未发送/明确拒绝释放；排队/在途/未知结果保留；远端写后查询拥塞不冒充未发送。没有新增存储、锁或自动重试。
• 定向覆盖当前 247 项，desktop typecheck、hygiene、文档及 DCO 通过。旧 HEAD Windows 的飞书文件上传测试超时与本轮 diff 无关，新 HEAD CI 待完成；PR 原有未完成验收继续保留。

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e1946c2a38

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8b6149fce8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 32c9edbbe0

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[MagicLizi]

PR #6399 独立代码审查报告（heavy 档）

• PR: fix(bots): 自主跟进区分观察责任与行动授权 #6399 —— fix(bots): 自主跟进区分观察责任与行动授权
• head/base: e0d73959697e1c4228d1652741a4f8506e17a22c / 064354193a196d02533b111c09c201e2fd566a9f（baseRef main）
• diffHash: 8434708adf3ae4da726c3db8bacf1ae032a2f9c97e047897b0b7f40b6318b5af（67 文件，+2402/-~）
• 审查档位: heavy（安全敏感触发：危险写法 13 处 dynamic-eval，均为测试内 new Function 生产切片夹具）；维护者确认门已由 zqchris 的 Approve 放行（security/rules/arch 三类触发，blocking=false）

Findings

没有 P0/P1。逐项核过以下候选疑点后均不构成可证实问题（按口径不发 P2）：

1. mcp-tool-approval-policy.ts 将 TASK_ACTION_TOOLS 强制 prompt-each-time：与「主人请求沿用普通任务权限流程、不额外弹行动确认卡」一致——per-call 审批就是唯一那次「展示目标、动作、内容并等待确认」，Host 行动确认卡（confirmTaskAction）对主人输入不再弹出；自动化无授权调用在 Host 门直接拒绝、不弹卡。属有意的安全收紧，测试名与产品文档均已同步。
2. taskActionInputGuard 的历史/无守卫 Bot 来源队列项 fail-closed 丢弃：与 PR 声明的「序列化不保存授权」「无法复核的旧自动输入不恢复投递」一致；正常新链路（bot-dm、botTaskCoordination、orca 来源、owner/UI 无 origin、scheduler）均有豁免或绑定守卫，已逐一核对 sendToSessionInternal 全部调用方与 sessionQueueOriginForDispatcher 四处使用点。
3. 跨电脑互发要求两端升级（旧端互发明确拒绝）：兼容收窄但已在 PR 风险段声明并登记于 docs/dev-rules/protocol-compatibility.md「跨电脑任务行动回执」，回执仅内存、绑定设备/任务/正文、一次性认领 + release 确认，256/1024 上限与 TTL 有测试覆盖。
4. 五语文案中 en/ja 用「session」：中文文案符合 task-and-conversation-naming.md（一律「任务」），该规则适用范围为中文文案，pnpm check:i18n-glossary 无新增违规；且该确认卡在当前流程中不被触发（见 1）。不构成阻断。
5. switch_focus、set_workbench_task_responsibility、rename/archive/move 复查等后补集合成员：均落在「观察不能创造执行权」同一不变量内，非无关扩范围。

Rule coverage

规则	逐项结论
AGENTS.md、docs/dev-rules/development-workflow.md（PR 契约、P0/P1 口径、验证真实性）	Description 三大段齐全、风险分类勾选与 diff 一致；验证记录可复核且未虚报，未执行项如实列出；DCO 8 commits 在 PR check 通过
docs/dev-rules/electron-security-and-process-boundaries.md（IPC/特权边界）	maker:session:handoff 新增 task-action-capability / validate-task-action 两个动作仍在既有 allowlist channel 内；wire 只传回执 id 与正文绑定字段，正向授权是 Main-only 闭包（TASK_ACTION_INPUT_GUARD 不序列化、投影时 Reflect.deleteProperty 剥除）；确认桥 resolve 走 assertTrustedAppRendererEvent、sharedTask 通道不受理
docs/dev-rules/engineering-conventions.md（i18n、错误处理）	五语文案同步补齐；IPC/工具错误全部沿用原 fail-closed 错误码族（TASK_ACTION_AUTHORIZATION_*），无吞错、无新增敏感日志
docs/dev-rules/architecture-invariants.md（依赖方向、main 加载）	packages/lizi-mcps 只新增可选 authorizeCall: ToolCallAuthorizer 注入点，不反向依赖 desktop；无新增第三方依赖
docs/dev-rules/maker-core-and-agent-behavior.md（tool 说明）	bot_capabilities / bot_workbench / capabilities / get_task_digest 工具说明与授权口径同步；未触碰 system 段
docs/dev-rules/orca-team-architecture.md、docs/product-rules/cindy-bots-runtime.md §6.3、bot-group-chat.md、bot-routines.md、agent-user-parity.md	文档更新与实现逐条对得上：自动检查按授权行动、群主人 authorizeGroupTool('owner-action') 实时核验、Lead 仅延续当前 active team、v5 模板 ensureBuiltin 对齐保留 enabled=false
docs/dev-rules/protocol-compatibility.md	跨电脑行动回执增量协议（能力探测、一次性认领、release 释放语义、旧端拒绝、TTL/上限）与 sessionHandoffIpc.ts / sessionHandoffRemote.ts / remoteTaskActionReceipt.ts 实现一致；无 relay channel、服务端、migration、Mobile 指纹变化
docs/dev-rules/credentials-and-local-storage.md	回执/守卫仅进程内存，无落盘、无仓库写入、无凭证
docs/product-rules/task-and-conversation-naming.md、i18n/GLOSSARY.md	zh-CN/zh-TW 文案使用「任务/消息」口径；pnpm check:i18n-glossary 通过（仅存量 proposed 术语告警）
docs/design-rules/DESIGN.md	无新布局/颜色/尺寸；确认卡复用既有 interaction(permission) 卡片与语义 token；Light/Dark 由既有 themed 组件承载，PR 如实注明未实机目检
受保护路径（.github/、CODEOWNERS）	未触碰

Verification

实际运行（worktree .../worktrees/pr-6399，日志均落在 roundDir）：

命令	结果
pnpm install --frozen-lockfile --prefer-offline --prod=false（worktree 首装）	exit 0
pnpm --filter desktop run typecheck	exit 0
vitest run 批1：taskActionAuthorization / sessionControlService / sessionHandoffIpc / botWorkbenchAccess / botTodoStore / messageSourceNote / pluginTaskAuthorshipWiring / sendToSessionLazyResumePermission	8 文件 160 项全过，exit 0
vitest run 批2：botCanonicalSession / agent-input-coordinator / orcaLifecycleService / orcaTeamService / orcaWorkerCreationService / pluginStartTeamAdmission	6 文件 1923 项全过，exit 0
vitest run 批3：mobileClientPromptNote.contract / renameSessionTitlesInDb / sessionRuntimeControlWiring / setSessionsStatusInDb / followUpPrompt / sessionsUpdate / mcpToolApprovalPolicy / botDirectMessageService / collabSendOutcome / moveSession / sessionHandoffRemote / sessionStatusRemote	12 文件 439 项全过，exit 0
pnpm check:i18n-glossary	exit 0（18 处存量 proposed 术语告警，不阻断）
pnpm check:dev-docs	exit 0
scripts/security-scan.mjs --base 06435419	exit 0；依赖 audit 跳过（未新增依赖）；semgrep 仅新增 0 条

security-scan verificationLine（原样）：依赖漏洞扫描:本 PR 未新增依赖,无需扫描;静态扫描(semgrep,仅新增):0 条。
注意：semgrep errors 非空（botCanonicalSession.test.ts、moveSession.test.ts 两个测试文件的 new Function 切片写法解析失败），即这两文件未被 semgrep 覆盖，已由人工 diff 审查补位，不把该部分记为「已扫描无问题」。

本 PR 全部 26 个改动测试文件均已实际执行且通过（合计 2522 项）。CI：head e0d7395 上 client-ci、pr-design-basis、PR #6399 全绿（context gate.ci.status=pass）。

未执行（如实声明）：整仓 pnpm test:unit 全量、真实 CC / Codex / Pi / SSH / Mobile / 双机跨电脑端到端验收、确认卡与五语文案实机目检。PR 自身亦将多端实机验收、历史自动队列与「发送后到远端最终写入间的来源撤销窗口」列为剩余事项——属已声明限制，不构成 P1。

Intent alignment

• 描述来源：PR body（当前版本，读取于 2026-10-20）；产品裁决正文在 docs/product-rules/cindy-bots-runtime.md §6.3（2026-10-19「自动检查，按授权行动」显式取代 2026-10-17「卡住就推一把」）。
• 初始实现：2762ac4fc1（2026-10-19，45 文件 +740/-113），已实际读取该 revision 的 followUpPrompt.ts（v5 两句话模板，与最终一致）与 taskActionAuthorization.ts（同一工具集合/授权模型，后续仅扩充成员与复查点）。
• 待合并 head：e0d7395969（8 commits，均为同一目标内的审查修复）。

原目标/初始行为	最终行为与影响	代码/提交证据	变化依据
观察责任与行动授权分离：自动轮次只读与提醒	helper/orca 全部写入口走 Host admission，无授权拒绝且不弹卡	apps/desktop/src/main/maker-ipc/taskActionAuthorization.ts、taskActionHost.ts（初始 2762ac4 即有）	同一目标内加固：set_workbench_task_responsibility、switch_focus 等后补集合成员对应「观察不能创造执行权」
主人请求沿用普通权限流程、不加行动确认卡	owner capture 返回 null 不调用 confirm；per-call prompt-each-time 承担唯一确认	taskActionHost.ts、maker-host/mcp-tool-approval-policy.ts	与 PR「本轮修复的不变量」及 capabilities/bot_workbench 工具说明一致
v5 内置正文 = 用户指定的两句话	初始即为最终文案，不插值不可信 bot id	bot-autonomy/followUpPrompt.ts、bot-routines.md	用户明确决定
群里 @ 自己伙伴的 start_session_task 不被当自动操作误拒	群主人请求经 authorizeGroupTool(…,'owner-action') 实时核验后按主人输入处理	commit 99835f8f、docs/product-rules/bot-group-chat.md 2026-10-20 段	原目标内缺陷修复（有回归测试）
多轮 Codex/Greptile 14 条 thread（消息被编辑丢弃、回报后无法派活、回执泄漏/占额度、异步复查窗口）	逐条修复并全部 Resolve	thread 历史 + b2fb14b0…e0d73959 各 commit	同一目标内缺陷修复，无产品方向变化
跨电脑任务互发（原有免审通道）	收窄为「两端都支持行动回执才可互发」，旧端明确拒绝不降级	sessionHandoffIpc.ts、sessionHandoffRemote.ts、protocol-compatibility.md 新章节	已在 PR 风险段声明、维护门已确认的兼容收窄，服务于同一授权目标

结论：一致 / 已获明确同意的调整。无确认偏离、无需要用户裁定的核心方向问题；剩余实机验收事项已在 PR 中如实保留。

Overall

pass —— 没有 P0/P1。