长期运行编排
协调器是一个串行决策点：它进行的每次读取和路由到它的每个决策都会在无时钟的队列中等待，当它饱和时工作会无声停止。此技能确保不会有任何事情到达这样的队列。
驱动的顶层是两个会话。
通信器 是所有者输入命令的会话；它的全部工作就是为所有者服务。
协调器 是一个兄弟 Orca 会话，绑定为 root 通道：它会在每个带有正文的请求到达时生成一个通道，决定哪些问题需要上报，并传递工作台产生的结果。它们旁边是 元通道，它处理每次技能、工具和流程变更，并把每个裁决转化为技能更新；以及 信号通道，它监听协调器的输出，这样通信器就不必亲自轮询。除此之外的一切都是驱动工具 lr 的一个动词，或者是一个无需它们中任何一个即可运行的进程。这里的规则指明了使失败不可能发生的动词或进程；没有这些的规则是需要在该驱动包中修复的缺陷。
此技能位于 ~/.claude/CLAUDE.md，负责管理扇出形状、模型路由和验证深度。该驱动包是一个 Go 二进制文件 lr，以及它所取代的 Python 脚本，这些脚本会保留到每个动词上线为止（设计）。
同时运行三个或更多通道、一个超出单个上下文窗口生存期的任务、等待 CI、队列、应用或验证，或者扫描多个独立单元，都属于一个驱动。单通道调查是一个处于直接模式的子代理，而不是一个驱动。
目录
- 读取你的职责文件
- 判断优先
- 钩子和拒绝
- 元变更落地到技能中
- 每次工具调用前
- 询问动词，从不直接读取
- 规则
- 阶段 0：常驻会话
- 无需协调器即可运行的内容
- 通道和工作台
- 所有者的交互界面
- 记录和任务列表
- 启动和恢复
- 为此技能添加规则
读取你的职责文件
只读取你正在执行的任务对应的文件。每个文件都明确说明了其规则。
判断优先
- 没有规则禁止读取决策所依赖的那一行。
- 手中的发现就是修复，而不是通道、重新审计或工作流。
- 将所有者的每句话当作细心的同事来理解。修正指出的是对表述理解的缺陷，而不是对所有者先前裁决过的内容进行重新设计；行动前先阅读注册表中关于该主题的行。重复出现是对首次阅读的缺陷报告：修复它当时幸存下来的所有地方。
钩子和拒绝
- 钩子用于警告。它们仅在信任事项上阻止：未经所有者批准合并，更改批准落地的人，未经其同意回滚，从通信器启动运行器或工作台，驱动其登录生产环境的浏览器的通道，编辑已安装的钩子文件和会话保护守卫。读取失败仅发出警告；
tests/test_fail_open.py强制执行此项并列出例外情况，Slack 权限钩子则采用默认放行方式（slack-lane-brief.md）。 - 一个对你的工作误报的钩子，在它阻止你的那次轮次中，你会获得一个修复通道，并且你可以继续处理它不阻止的工作。一个正确的拒绝，例如生产身份守卫，则不会获得修复通道。被阻止的会话（无论是通道、工作台、协调器还是通信器）会启动修复通道，无需询问
root，也无需元通道：lr launch lane hook-fix-<hook> opus high <brief> --drive <drive> --lane <you>，除非lr lanes hook-fix-<hook>显示已有一个存活的修复通道。 - 钩子位于 yasyf/cc-skills 仓库的
plugins/long-running/capt-hook/hooks/和 yasyf/captain-hook 仓库的captain_hook/builtin_packs/中，每次变更都遵循captain-hook:authoring-hooks，其 lint 和测试在该仓库的 CI 中运行。修复通道修复钩子的实际缺陷并附带回退测试，将其提交并安装到被阻止会话运行的位置，其验证证明是被拒绝的调用现在能通过了（orca-lane-brief.md）。 - 修复不是绕过：在拒绝仍然有效时，没有人通过包装器、
cc-sudo或脚本运行被阻止的内容。所有者的安全规则保持不变：合并、Slack、负载测试和进程守卫。如果一个保护其中之一但误报的钩子，会修复其误报并附带回退测试，而规则本身只有在他的指示下才能更改。在其修复之前被禁用的唯一一个钩子，是会阻止通信器一切行动的钩子：在驱动包源代码中将其注释掉，附上引用其修复通道的 TODO，通过一个立即合并的 PR 提交，因为对已安装缓存的编辑只持续到下一次安装，而此 Mac 会在几分钟内运行下一次安装。 - 一个不阻止任何内容但可以改进的钩子，会通过一条
cci post --kind note --to meta-desk记录发送到元通道。任何其他工具的拒绝也在同一轮次发送到元通道，工作继续通过其手动路径进行。任何拒绝都不是借口或向所有者提出的问题，平台也不是：一个将等待或失败归咎于 Sprite、宿主机或共享工具的记录，必须指明修复其根本原因的通道及其截止时间，如果没有这样的通道，则在该轮次向协调器请求一个。替换机器是权宜之计，绝不是最终解决方案。
元变更落地到技能中
接收到全局适用的元变更的通道——任何关于通道、卡片、等待、回复、钩子、路由或答案如何工作的裁决，都会在其到达的轮次中将其作为一条 cci 记录发送到元通道。元通道始终将其转化为此技能的更新，或转化为它所属的简报模板、钩子或 cc-notes 文档的更新，合并并安装，重写和重构其触及的部分，使技能读起来像一个整体设计，绝不是一个追加的行。一个内存文件或记录只是一个指针，永远不会被视为完成。
每次工具调用前
| 如果调用是 | 执行操作 |
|---|---|
| 动词能回答的事情 | 运行该动词。 |
| 带有正文的工作 | 用其任务和账本行生成通道。 |
| 等待 | 将其折叠到执行动作的通道中。 |
| 状态查询 | 通信器发送更新工作台的渲染结果；协调器不发送任何东西。 |
| 所有者的消息 | 通信器为其生成一个子代理，它在消息来源的交互界面上进行回答；协调器将裁决应用到所有地方；关于驱动工作方式的裁决会在该轮次发送到元通道，元通道将其转化为技能更新。 |
| 监督者尚未响应的告警 | 立即运行 lr incident run <slug>。 |
| 工具拒绝，或出了两次错的事情 | 一个阻塞你工作的钩子会获得你此轮启动的修复通道（钩子和拒绝）；其他任何问题都立即转到元通道，在那里修复是一个 Go 动词。无论如何都要继续。 |
| 批准、暂停、启动或取消 | 所有者的命令承载它，或者由某个通道拥有它。 |
已完成的代理停止，生产操作已记录，没有什么是完成但尚未在线且已验证的。 一个通过此列表检查的调用，决定的是没有动词或通道能决定的事情。除此之外的一切都是通道。
询问动词，从不直接读取
| 要知道 | 运行命令 |
|---|---|
| 一个通道是否存活，以及它最后说了什么 | lr lanes <lane> --config <lr.json> |
| 每个通道、其状态、PR 和常驻职责 | lr lanes |
| 自从上次查看以来发生了什么 | cci digest --drive <drive>，然后 cci tail --drive <drive> --cursor root |
| 什么在等待所有者 | cci owner-waits --drive <drive> |
| 哪些子驱动处于打开状态，以及每个子驱动还持有多少内容 | lr drive sub list |
| 它必须指名的 PR 的状态 | ccx vcs pr status <n1> <n2> ...，批量处理 |
| 所有者批准了看板上的哪些 PR，以及其中哪些仍然打开 | lr approved [--since <seq>]，排除回溯裁决 |
| 每个未解决的问题，以及已落地但未上线的功能 | lr asks |
| 完整的所有者更新，合并来源信息 | lr update render，由通信器的 update-desk 运行 |
| 一个事件正在做什么；用一句话描述它是什么 | lr incident status <slug>; lr incident describe <slug> |
一个通道的邮件在哪里；每个 lr 动词都接收一个主干名，例如 meta-desk，用于其最新的存活通道 | lr route <lane> |
表中缺少的读取属于通道：PR、CI 日志、Slack 线程、长文件、云列表、构建页面。一个你正在批准的 diff、计划或裁决是你自己可以读取的。协调器生成一个读取器并最多取回五行；搜索通过一次调用 lr ask-lane '<question>' 完成。root_context 和 root_reads 钩子会警告这些类型的读取、为单个所有者请求打开的第二个源、以及通过 tail 或 grep 管道处理的通道记录；在通信器的窗口中，root_context 拒绝广泛的搜索并推荐使用 lr ask-lane。
规则
规则 ID 是稳定的；脚本、钩子和引用文档都会引用它们。root 指的是协调器，除非规则指明了通信器。
R1. 真相来自所属通道或动词，而不是 grep、列出、curl 或构建页面；最多返回五行。优先级 PR 的状态通过一次批量 ccx vcs pr status 调用来读取。
R2. 任何带有正文的内容都是一个通道：超过有限窗口的读取、日志、调查、PR 或合并机制、枚举。允许一次对单个命名文件的最多 150 行的有限读取。
R3. 每个等待-然后-执行链对应一个通道，并且没有通道是停驻的：一个通道等待一个 Monitor、Agent 通知、用于计时的 CronCreate 或一次 lr wait 调用，直到终止状态，并报告一次。shell_waits 阻止 shell 循环或休眠器。工作台的 Monitor 在到期时重新布防。
R4. 绝不重新简报一个通道，绝不回答重复问题。向已完成代理发送 SendMessage 会重新运行其简报。lr wait 将打印的邮件标记为已读。
R5. 记录它，不要记在脑子里：发现结果由发现它们的通道记录到 cc-notes 中；简报作为附件放在 briefs: <slug> 日志中；不要在 ~/.claude/scratch 下手动创建任何东西。
R6. 每个所有者的请求在其到达的轮次中都处于进行中状态，每个问题一个通道，绝不附加到繁忙通道的队列。一个通道每个交付物拥有一个 PR，并将其修复作为提交落地在该 PR 上；orca-lane-brief.md 说明了何时进行堆叠。
R7. PR 的状态在报告之前必须读取：使用 ccx vcs status 或获取主干上的压缩提交，绝不使用消息或记忆。
R8. 每个所有者的请求在到达的轮次中都是一个账本行，并且仅在 LIVE 状态下才算完成；在此之前，答案是“在 #N 中，尚未上线：<阻塞原因>”。
… （为翻译而截断）