Bun Loop
借鉴 Jarred Sumner 的 Bun 重写工作流，应用 Oracle 驱动的工程循环。将对抗性审查视为缺陷过滤器。将可执行的 Oracle——测试、编译器、linter、复现、一致性检查或基准测试——作为完成标准的唯一来源。
路由明确请求
尊重显式的 $bun-loop-skill factory 或 $bun-loop-skill patch 选择。对于纯 $bun-loop-skill 调用，仅当所有四个条件成立时选择 Factory 模式：
- 源可以生成多个结构相似的工作项，例如文件、编译器诊断、失败测试、堆栈跟踪或迁移记录。
- 可以在批量实施之前建立可重复执行的 Oracle。
- 对当前工作流的修正可以改进同类的剩余项。
- 准备工作和三项试运行预计消耗不超过总工程工作量的四分之一。当此分摊不明确时，优先选择 Patch 模式并报告估算。
否则选择 Patch 模式。不要对琐碎的编辑或只读问题使用任何一种模式；解释该技能的多代理成本不合理。如果用户明确请求 Factory 模式但无法建立 Oracle，则完成准备审计，将运行标记为 blocked，并报告缺失的 Oracle，而不是静默地回退。
在委托之前，说明选择的模式以及选择的证据。
维护通用操作约定
- 尊重仓库说明、用户范围、审批要求和现有更改。
- 使用真实的独立子代理上下文。加载此技能的代理是编排器，即使它本身也是一个子代理。
- 保持角色分离：编排器协调；实现者和修复者编写；审阅者保持只读。编排器不得编写生产变更或发起审查发现。
- 每个工作项只允许一个编写者。绝不允许在一个工作树中出现重叠的编写者。仅在 Factory 模式的隔离规则下使用并行编写者。
- 向审阅者提供项目合同、相关参考工件、基线或源材料、最终差异和原始 Oracle 输出。排除实现者的推理和说服性解释。
- 保留不相关的工作。永远不要使用
git stash、破坏性重置或 checkout，或丢弃另一个代理或用户更改的命令。未经明确授权，不得提交、推送或打开拉取请求。 - 在开始之前设定上下文、编写者和昂贵 Oracle 的预算。预算是停止条件，绝不是削弱证据或宣布未完成工作已完成的许可。
- 当独立上下文或所需的隔离不可用时，以能力阻塞器停止。切勿在编排器上下文中模拟缺失的角色。
一致使用证据
为每个项定义一个紧凑的合同，包含：
- 目标、拥有的路径和可观察的验收标准；
- 相关的映射指南、不变量或真相来源工件；
- 针对性的项目 Oracle 和完整的集成 Oracle；
- 禁止的捷径和兼容性约束；
- 依赖项、当前队列状态和声明的增长边界。
按此顺序使用证据：明确的用户验收标准；记录的公共行为和任务陈述；独立的可执行 Oracle；基线测试和仓库约定（排除所谓的缺陷）；然后作者添加的测试。当排名较高的证据冲突或留下未解决的实质性语义决策时，阻塞以获取澄清。
审阅者必须返回 CLEAN 或以下形式的发现：
severity: critical | high | medium | low
location: path and tight line or symbol reference
failure_mode: what breaks and under which conditions
evidence: reasoning, reproduction, or command output
required_correction: the behavior that must change
仅接受由复现、命令输出、逻辑演示或项目合同支持的、相关的发现。去重报告，并记录拒绝不支持、重复或范围扩展的发现的简短原因。审查活动和 CLEAN 标签不是可执行的证据。
仅当项目涉及相应的风险类别时，才读取 references/review-rubrics.md：状态转换、精确的结构语义、解析器或兼容性边界、异步生命周期或迁移。默认情况下不加载每个评估标准。
在两种模式下拒绝虚假进展：
- 存根、占位符返回、新的未解决 TODO、忽略的错误、或仅编译的必需行为替代品；
- 删除、禁用、跳过或弱化的测试和断言；
- 未请求的泛化，拓宽了语法或兼容性边界；
- 需要段落长度的注释来论证其安全的变通方法；
- 仅仅为了保持补丁本地化而对仓库拥有的解析器、状态模型或算法进行并行实现。
运行 Factory 模式
将 Factory 模式用作工程生产系统，包含内部项循环和外部过程改进循环。
1. 准备工厂
启动一个映射器来检查请求和仓库。让其生成紧凑的活动工件：
- 移植或迁移指南以及显式的不变量；
- 确定性队列生成器和初始有序队列；
- 项目和完整集成 Oracle 命令；
- 所有权分区、依赖项和安全的集成顺序；
- 仅包含相关风险类别的初始审查评估标准；
- 上下文、编写者通道、Oracle 运行和项目增长的限制。
将这些工件保存在任务暂存空间中，除非用户授权的项目范围包括将它们写入仓库。将工件发送给两个全新的、只读的对抗性审阅者。启动一个全新的修复者来合并已接受的准备阶段发现。编排器裁决证据，但自己不重写工件。
要求队列生成器和项目 Oracle 在批量实施前工作。当两者中任何一个不可用时，将准备标记为 blocked，并说明确切缺失的能力。
2. 运行三项试运行
选择三个代表不同依赖项或风险类别的项。对于每个试运行项：
- 仅为此项启动一个实现者。
- 运行项目 Oracle 并捕获原始输出。
- 同时启动两个全新的审阅者。
- 裁决他们的证据，并在存在接受的发现时启动一个全新的修复者。
- 针对集成结果再次运行项目 Oracle。
在所有三项完成后，仅通过基于试运行证据的映射器/修复者交接，更新活跃的映射指南、队列规则、所有权、审查评估标准和并行性。在处理剩余队列之前，冻结最终的工厂合同。
3. 处理队列
对于每个项，使用以下状态流：
queued -> implementing -> reviewing -> fixing -> verifying -> done | requeued | blocked
项循环如下：
- 一个实现者做出完整的有限变更，并运行可负担的项目 Oracle。
- 两个全新的审阅者并行检查相同的最终差异和原始 Oracle 输出。
- 编排器裁决；一个全新的修复者应用所有接受的发现。
- 按声明的顺序集成补丁，并运行项目 Oracle。
- 仅在项目 Oracle 和验收标准通过且无接受的发现剩余时，将项标记为
done。
不要仅仅因为修复者编写了代码就递归启动另一对审阅者。仅当修复者实质性地跨越了项的声明增长边界或 Oracle 仍然失败时，才创建有界后续项。新的项必须命名剩余的失败，并使用相同的队列纪律。
4. 改进活跃过程
对已证实的失败进行分类。当同一类失败在至少两个项中出现时，将其视为过程缺陷：
- 启动映射器/修复者更新活跃的指南、队列生成器或相关的审查评估标准；
- 识别已暴露于该类别的已完成或进行中的项，并仅重新排队这些项；
- 将修正应用于所有剩余项；
- 保持此已安装的技能不变。
通过更少的 Oracle 失败和更少的未解决队列项来衡量进展。如果同一阻塞器持续存在，或者连续三次尝试中两个衡量指标均未改善，则将对受影响的工作标记为 blocked，并附上尝试次数和所需的外部决策。
5. 仅并行处理隔离的工作
在共享的工作树中，保持恰好一个编写者活跃。试运行成功后，仅当运行时提供隔离工作树或等效文件系统、每个通道拥有非重叠路径且编排器有确定性集成顺序时，才使用最多四个并发的编写者通道。审阅者保持只读。
一次集成一个通道补丁，并在每次集成后运行相关项目 Oracle。如果安全隔离不可用，则继续顺序执行；不要将降低的并行性视为阻塞器。
6. 完成工厂
队列清空后，运行完整的集成 Oracle。完成需要：
- 生成的队列为空；
- 完整 Oracle 通过；
- 没有测试或检查被移除、跳过、禁用或弱化；
- 所有接受的发现都已被处理；
- 报告剩余的限制和风险。
不需要额外的一对全局 CLEAN 审查。如果完整 Oracle 产生失败，则将每个可复现的失败组转换为新的队列项。审查不能替代不可用或失败的完整 Oracle。
运行 Patch 模式
将 Patch 模式用于单个高风险变更集。不要创建 Factory 工件、批量队列、试运行或全局最终审查。
- 构建紧凑的项目合同，并声明四个全新角色上下文的标准预算：一个实现者、两个并行审阅者和一个修复者。编排器上下文不计算在内。
- 启动实现者做出完整的变更并运行有针对性的检查。
- 将最终差异和原始检查输出同时发送给两个审阅者。
- 裁决支持的发现。即使没有接受的发现，也启动修复者；在这种情况下，它不执行编辑并确认交接。
- 针对结果树运行目标明确且负担得起的集成 Oracle。
当验收标准和 Oracle 通过、无接受的发现剩余且不存在禁止的捷径时完成。仅当修复者实质性地扩展了声明的变更边界或 Oracle 仍然失败时，才重新进入审查。将剩余的失败表示为一个有界的后续项，并将总的新的角色上下文预算保持在或低于七个。否则停止为 blocked，而不是增加推测性的审查轮次。
报告结果
报告选择的模式、已完成和阻塞的项、Oracle 命令和原始结果、接受和拒绝的审查计数、使用的上下文和修复轮次、Factory 模式下进行的过程更改以及明确的残余风险。区分进展、完成以及预算或能力阻塞器。