cross-repo-request

用途：当本仓库的改动依赖另一个拥有独立运行中 Claude 会话的仓库时，向拥有该变更的会话发起请求，而不是自行猜测契约或静默打桩。它防止的失败场景：前端 Agent 需要尚不存在的接口，便私自 stub 响应、臆造 payload 形状并据此写代码，结果是后端从未同意的契约，stub 进入评审后字段形状不匹配；反向亦然。\n\n主要能力与用法：\n1. 查找对端：用 ListAgents 列出本机运行的 Claude 会话，每行开头是可寻址的名称。若目标仓库没有会话，应停止并告知用户去那边开启一个，等待期间不要按假定契约实现。\n2. 发送请求：用 SendMessage 发给对端；首行是对方展开前唯一可见的内容，因此必须独立说明诉求。每次都要包含七项：仓库或服务路径与分支；HTTP 方法与完整路由路径（非 HTTP 则为函数/模块）；请求负载形状及类型与必填字段；期望的成功响应形状与状态码；期望的认证与租户上下文（header、role、scope）；需要区分的错误情形（状态码加代码）；实际想要的回报：确认契约、mock 或真实实现。改动较小时可用紧凑形式，并注明调用方文件，便于对端阅读你这一侧。\n3. 等待期间：发送时传入 notify_when_idle: true，在对方完成时获得一次通知；不要循环轮询 ListAgents，也不要发“完成了吗”。先做不依赖答案的部分，依赖部分宁可留白也不打桩；若必须放 stub 以保持编译，用注释标明所等待的对端请求，避免被误认为已完成。\n4. 回复处理：对端首行为 DONE、PROPOSAL 或 BLOCKED。DONE 时，先读取其 files: 行下的每个文件再基于其构建，摘要只是声明，代码才是契约；检查其 deviations: 行，若有偏差先告知用户再适配；然后运行其结果中的校验或从本侧调用端点验证，失败则把实际错误回发一次，再失败就停下连同两个错误交用户。PROPOSAL 表示对端想要不同契约，需转达用户并附理由让其决定，不得代用户接受或拒绝，也不得在用户同意并转发同意前开始构建。BLOCKED 时告知用户并停止依赖部分。\n\n限制：权限按会话划分，绝不要让对端运行你自己权限设置所阻止或会阻止的操作；若某操作被拒，应上报用户，而非绕道其他会话。官方文档其余细节暂未提供。