rch

RCH — 远程编译专家

RCH 可以卸载一条明确指定的编译命令，也可以检查远程编译器路径。此技能会报告发生了什么；不会管理重试或修复。

分阶段诊断之所以有效，是因为卸载流水线会按顺序失败——可用性、配置、钩子、分类、同步、远程编译、工作器压力——因此，第一个失败阶段可以定位故障，在它通过之前，后续阶段都是干扰信息。按不可逆程度的顺序采取补救措施：先进行只读探测和配置检查，再重启守护进程，然后才清理；只有获得调用方的明确授权，才能执行破坏性清理或修改工作器。

命名故障模式——本地成功造成盲区：将通过的 [RCH] local (...) 构建误读为卸载成功；本地回退掩盖了远程执行的说法从未得到证实。

反模式：重新运行构建，寄希望于回退原因消失。 纠正方法：读取已记录的回退原因，并修复对应阶段；流水线的失败是确定性的，不会反复无常。

流程

1. 修改前，收集 rch check、rch doctor --json、工作器状态以及相关的 [RCH] 摘要。
2. 进行诊断时，找出第一个失败的阶段：可用性、配置、钩子、分类、同步、远程编译或工作器压力。
3. 只运行调用方授权的命令或文档中记载的安全诊断一次。
4. 记录准确的命令、已知时的工作器、退出代码、本地回退原因以及操作后的状态。
5. 停止并返回证据。

即使本地构建成功，[RCH] local (...) 也表示所请求的远程卸载说法未得到证实。破坏性清理、部署工作器、配置守护进程以及远程修改都需要调用方的明确授权。

rch check 的退出状态用于判定是否就绪（0 = 就绪，非零 = 未就绪，无法卸载）。不要将 rch doctor --json 中的 success: true 解读为就绪——诊断报告成功，也可能同时存在守护进程已停止或工作器不可达的情况。应以 rch check 为判定依据；使用 doctor 查看其背后的原因。

输出

返回一份事实记录，包含状态（remote、local_fallback、failed 或 not_proven）、命令和退出代码、工作器、摘要行，以及已检查／未检查的部分。不要包含后续操作。此处的 not_proven 是运行时诊断状态，不是 AgentOps 判定；它不具有任何判定效力，也绝不能替代 verdict.v2。

参考资料

上方的 SKILL.md 权限边界适用于以下所有参考资料。若参考资料列出了补救措施，其只读诊断可以自主运行，但远程、特权或不可逆操作（远程／sudo 修改、启动／重启／重新配置守护进程、部署工作器或工作器集群、同步工具链、破坏性清理）仍须事先获得调用方的明确授权。参考资料绝不会扩大内核授予的自主权限。

• Fail-open 原因
• 错误目录
• 故障排除
• 恢复操作手册
• 工作器操作
• 配置
• 机器可读界面