stuck-crewmate-recovery

卡住队员的恢复

当会话启动摘要报告普通直接下属的端点已失效或其元数据没有窗口时，或者直接下属已过时、陷入循环、反复感到困惑、询问其简报中已有答案的问题、没有响应，或引导未能生效时，请使用此操作手册。 对于已合并拉取请求的工作者，若其报告过时或端点已失效，这不属于恢复场景：工作已完成，因此请通过常规拆除流程关闭任务（firstmate 请参阅 AGENTS.md 第 7 节；监督分支请参阅 bin/fm-branch-prompt.sh 中关于已合并工作的规则），而不要使用此操作手册，绝不要使用 --force。

恢复托管看板的工作者时，请遵循 docs/configuration.md 中的团队托管 Lavish 看板约定。

通过 bin/fm-control.sh <task-id> interrupt|exit|relaunch 中断、停止并重新启动工作者。该命令会自行解析记录的运行时，验证每项操作，且绝不会拆除或丢弃任何内容（docs/agent-control.md）。 该操作平面适用于在此主目录中运行的工作者；如果 secondmate 被放置在远程位置，则会按名称拒绝操作，并通过 secondmate-provisioning 进行协调。 在执行恢复命令或调用特定于运行框架的技能之前，以及适配器自身的特性会产生影响时，请先加载 harness-adapters。 目标窗口所用的运行框架记录在 state/<id>.meta 中的 harness= 字段。

托管审批故障转移

在绕过模式下观察到 Codex 命令审批提示，或 Claude 拒绝绕过会话的策略后，请征求船长的明确批准，以更改所属主目录的工作者权限配置并重新启动工作者。 只有在获得明确同意后，才加载 harness-adapters，并使用 FM_HOME=<owning-home> bin/fm-approval-failover.sh apply <id>；其头部说明持久化配置和受保护的恢复流程，且不会自动检测。 报告经模型审核后保存的补救措施及实际恢复结果；保留明确设置和现有工作，不要更改供应商策略，也不要回答审批或钩子信任提示。 backend=t3code 的工作者已在 T3 的 full-access 运行时模式下运行，因此该命令会在更改任何内容之前拒绝执行；请在 T3 Code 中批准其待处理请求（T3 待处理请求流程），或将工作转移到其他后端。

已退出的普通直接下属的会话启动对账

此流程适用于普通的 kind=ship 和 kind=scout 直接下属。 对于 kind=secondmate 的恢复，请改为加载 secondmate-provisioning。

对于远程 secondmate，fm-crew-state 和 fm-peek 会通过 fm-on.sh 读取实际的远程端点；fm-send 会将已送达但待确认的引导报告为已送达（相关约定以各自的标头为准）。读取结果为 unknown-remote 或因主机不可达而失败，表示无法读取远程状态，绝不意味着该队友已退出或发送失败。 仅通过 bin/fm-spawn.sh <id> --secondmate 恢复确实卡住的远程队友，绝不要直接对 herdr 面板执行关闭或终止操作，否则会使端点绑定失效。

将摘要中的端点结果视为存在性信号，而不是任务的工作内容或验证运行已消失的证明。 在决定重新启动之前，先使用 bin/fm-crew-state.sh <id> 读取指定任务的当前状态。 如果某次无错误运行与团队分支和当前代码匹配，那么即使端点已退出，该运行仍具有权威性：按正常生命周期处理已终止或已停放的运行；如果运行仍处于活动状态，则继续监督，而不是创建重复的工作进程。

如果没有权威运行能够对应此任务，只检查该任务记录的后端和工作树清单。 对于由 treehouse 支持的 tmux、herdr、zellij、cmux、Paseo、Rex、t3code 或 tern 任务，使用 treehouse status；对于 Orca 任务，使用记录的 orca_worktree_id= 和 terminal=。 不要扫描其他 home 的端点，也不要根据匹配的窗口标签推断归属。

重新启动之前，确认没有其他活动 Agent 仍拥有记录的任务，并确认现有工作树仍可用。 保留其中未提交的更改和提交，保持相同的任务身份，并在现有工作树中恢复或重新启动记录的运行框架，同时附上相同的任务说明和简短的进度备注。 HERDR 端点不仅仅是空闲，而是在 Herdr 变动期间面板或工作区被移除而遭到销毁时，也通过同样的重新启动来恢复；此操作会在现有工作树中创建一个全新的端点，并将任务记录重新绑定到该端点；无需进行任何特殊处理，工作树不会受到影响（docs/agent-control.md “回收端点已消失的任务”）。 重新启动会先证明端点已被销毁，然后才重新绑定，因此，如果 Herdr 服务只是停止了，它会被重新接管，而不会创建重复项。 tmux 不支持回收：任务记录不包含其端点的 socket 身份，因此无法区分 missing 窗口是确实不存在，还是位于当前 seat 无法访问的 tmux 服务端上；这两种情况都会拒绝 exit 和 relaunch。 T3 Code 不支持替换式重新启动：线程会保留其对话，因此更换轮次或提供方会继续使用同一个 Agent；请保留任务记录和工作树，并遵循 docs/t3code-backend.md，不要尝试重新生成该 Agent。 不要通过重新生成来绕过这些拒绝；保留记录的任务，并遵循后端的恢复约定。 回收操作只能由所属 home 执行；唯一例外是 secondmate，必须按上述方式通过 bin/fm-spawn.sh <id> --secondmate 恢复。 如果记录的工作树尚未查明，不要使用全新的通用生成操作，因为分配另一棵工作树可能会让同一任务分散在两个副本中。 如果无法安全地对账工作树或归属，请保持所有状态不变，并根据相互冲突的证据报告任务失败或受阻。

一个声称流水线已死的存活队友

这与上面的端点失效情况正好相反：工作进程仍在运行，而且它声称已死的流水线通常也仍在运行。 一次 drive 调用会阻塞，直到到达下一个关卡或产生结果，耗时远超执行框架允许单条命令运行的时间；守护进程会立即接受响应，并在后台运行这一轮。 因此，队友的 drive 调用若超时、被终止或出错，就会让它一直等待一个永远没有收到的读取结果；它由此得出的“守护进程已退出”结论只是猜测，不是证据。

在相信这一说法之前，请亲自查看以下两个权威来源：

1. 使用 no-mistakes daemon status 查看套接字。
2. 使用 no-mistakes axi status --run <id> 查看运行，或使用 bin/fm-crew-state.sh <id>；该脚本已将这一矛盾纳入判断：如果守护进程状态不是套接字问题或超时，而运行仍在进行或修复中且有近期活动，它会将 blocked: 行报告为已被取代，因为运行仍然存活。

如果 daemon status 返回连接被拒绝或套接字缺失，这是守护进程已停机的直接证据，必须上报，即使持久化的运行记录仍显示正在运行或修复中；守护进程退出后，该记录可能已过时。 否则，如果运行仍在进行或修复中且有近期活动，那么这一说法就是错的：引导队友从自己的工作树使用 no-mistakes axi run 重新连接；只要运行仍与其 HEAD 相符，这样做就是安全且幂等的，并告诉它超时不代表守护进程已退出。 这种情况下，不要向队长报告任何内容。

不要因为队友的说法而重启、停止或更新共享守护进程。 它是为所有工作通道和主目录提供服务的单个实例，因此重启会终止其他工作通道中正在进行的运行。 只有套接字连接被拒绝或套接字缺失，才表明守护进程已停机；将此发现上报，或者将明确指出守护进程错误的失败运行记录上报给队长。

实时端点升级处理

按顺序升级处理：

1. 查看窗格，并检查任务的指挥收件箱（state/<id>.inbox/），查找尚未处理的 *.msg 记录——如果过期的唤醒消息指出有一条未读的 firstmate 指令，就意味着工作者从未确认过持久化指令，而记录本身会准确显示预期内容。 如果工作者当前状态是声明了 paused: 的等待状态，它只说明了正在等待什么，因此请核实它所提及的条件——例如，它自己的后台作业的终止记录或进程；如果该条件已经满足，就引导工作者读取结果并恢复工作，而不是将等待状态报告为正常。
2. 如果队友正在等待一个其任务简报已经回答的问题，请按照 T3 待处理请求流程处理 T3 运行时请求。 对于窗格后端，除非 FM_HOME 已设置为当前 firstmate 主目录，否则请在活跃的 firstmate 会话中通过 FM_HOME=<this-firstmate-home> bin/fm-send.sh 用一行回复。
3. 如果队友感到困惑或陷入循环，请使用 FM_HOME=<this-firstmate-home> bin/fm-control.sh <task-id> interrupt 中断，然后通过 fm-send 发送一行纠正指令。
4. 如果队友在重新引导后确实陷入停滞，且其后端支持替换，请使用 FM_HOME=<this-firstmate-home> bin/fm-control.sh <task-id> relaunch --note '<progress so far>' 重新启动；这会停止 Agent，将任务简报及该备注一并交给同一本地副本中的替代 Agent，并在替代 Agent 无法启动时恢复之前的记录。 对于 T3 Code，不要重新启动；请保留任务，并报告线程卡住的情况及其当前服务端状态，以便操作员处理。 如果工作者需要在不同的运行时中重新启动，请在同一命令中传入 --harness、--model 或 --effort。 真正陷入停滞是指陷入循环、无响应、反复遇到同一障碍，或确实已停止运行。 上下文余量低不代表陷入停滞；现代框架会自动压缩上下文并继续运行。 工作树和提交会保留，因此重新启动成本很低。
5. 如果第二次重新启动也失败，请在待办列表中写入 failed，并根据 AGENTS.md 第 9 节，将明确的失败情况、已保留的工作以及后果告知队长；除非该路径是采取行动所必需的，否则不要提及元数据、框架、窗口或工作树。