Factory Operator 用于以手动、持久的状态机方式操作 Harness Factory 工作项。其核心目标是：一次只处理一个工作项，执行一个由持久状态选定的动作，检查其持久化结果，报告边界，然后把控制权交还给调用者，绝不把 CLI 变成自动循环。
用途与定位 该技能面向需要逐步、可控地推进 Factory 工作流的操作者。它把持久化的 Factory 事件日志视为机器真相，把 Linear 和 GitHub 视为可重试的、面向人的投影。每个活跃阶段都要固定一个不可变的 Harness 控制器产物；从源码自举时，应使用记录在案的 SHA 上的专用干净分离检出，而不是可变的人工或 main 检出，并通过 --workspace 传入单独的可变目标。
主要能力与操作契约
- 一次只操作一个工作项。
- 只运行由持久状态选定的确切动作：一次调用最多执行一个处理器，持久化其结果，打印下一个反应，然后退出。
- 等待进程退出。动作启动输出和心跳表示进展，而非完成；动作运行期间不要用竞争命令轮询。
- 在每个动作边界后停止，报告结果和确切打印的下一条命令，由调用者决定何时调用。
- 绝不从 Linear 状态、评论、代理消息或可变工作区状态推断 Factory 转换。
- 每次外部变更都需要明确授权：Linear --apply、计划发布、实现发布和合并确认。打开拉取请求绝不授权合并。
- 不自行发明评审轮次上限；当调用者提供上限时，在记录另一次继续前与持久 reviewRound 比较，统计已完成的评审轮次，而非重试或修订。
按需加载细节
- 涉及 Linear 接收、--apply、角色选择或存储覆盖时，阅读 Linear 与配置。
- 涉及失败动作、重放、投影修复、不兼容存储或深度证据检查时，阅读恢复与证据。
- 需要确切命令和标志时，运行 harness factory --help 及相关子命令帮助；生成的帮助拥有当前命令界面。
预检（Preflight）
- 记录控制器 realpath 和版本或确切 SHA；在每个动作前验证同一身份。它无需跟踪目标的 main。
- 记录目标分支或分离状态、确切 HEAD、工作树状态和预期基线；遇到无法解释的漂移即停止。
- 运行只读的 factory status；解析单个条目时也运行 factory inspect，使用与后续动作相同的存储覆盖。
- 当实时跟踪器问题是输入源时，获取它，并将其范围与委托权限和持久 Factory 状态核对。
- 确认哪些变更被授权：Linear 投影、分支推送、拉取请求发布和合并确认。除非用户明确说明，否则合并本身视为未授权。
- 如果任务方向与持久阶段、反应或不可变工作项冲突，停止；不要重写持久产物来强行路由。
执行一个动作
- 使用与预检相同的 workspace 和 store 身份调用一个阶段命令。
- 同步等待退出；动作活跃期间不要为该工作项启动另一个 Factory 命令。
- 读取终端 stdout，然后读取 summary.md 和 meta.json；当边界需要验证时，跟进引用的动作结果和证据。
- 验证已执行的处理器、尝试、因果、终止事件、路由和下一个反应。等待反应没有可运行动作。
- 发送一条简洁检查点，包含：命令和退出状态；工作项、阶段运行、处理器、尝试和终止事件；持久结果、路由和确切下一条命令或等待原因；检查的证据、Git 状态和外部变更；发现、阻塞项以及调用者需要做出的任何决定。
- 暂停。仅在调用者授权后调用下一条命令；不要用轮询循环等待调用者。
分类（Triage）
- 运行实时分类以进行分类。--dry-run 仅用于检查接线和产物布局，不产生权威路由。
- 预期四种持久路由之一：直接实现、规划、需要信息或停放/等待。
- 遇到意外路由即停止并报告分类器理由；不要捏造规划阶段或手动编辑路由。
- 仅在核对先前历史后有意重新分类时使用 --rerun；正常重试应恢复现有动作或投影。
规划（Planning）
- 每个可运行反应调用一次 planning run。候选生成和评审是分开的手动调用。
- 首次评审前，当人工响应需要更改计划字节时使用 revise。非通过评审后，记录以下之一：revise（恢复保存的规划器会话并创建新候选）；re-review（保留候选并将接受的澄清或证据发回评审者）。
- 将响应放在绝对、非空、不超过 32 KiB 的 UTF-8 文件中。它可以澄清不可变工作项，但不得扩展或覆盖它。
- 将 planning continue 视为仅持久决定；它不调用处理器，稍后运行单独打印的 planning run 命令。
- 仅在明确授权后发布确切已评审的计划。停止并报告拉取请求。人工合并后，验证记录的 URL 和合并提交，然后运行明确的合并确认命令。
实现（Implementation）
- 从干净的已附加目标分支开始，该分支具有持久直接就绪状态或 HEAD 处已提交的已批准计划。
- 调用一次 implementation run 以产生不可变候选。Harness 在生产期间不得移动分支或真实索引。
- 在调用评审者之前，检查实现者证据，并从目标工作区运行目标仓库所需的最终交接门。提供者声明、聚焦检查和 Git 钩子不能替代绿色的最终门。
- 如果门发现确定性代码失败，记录一次预评审 revise 继续，附上确切命令和失败证据，然后恢复保存的实现者会话。这不消耗评审轮次。
- 如果基础设施阻止门运行，停止并报告阻塞项；不要为环境失败捏造修订或评审发现。
- 再次调用打印的命令，针对该候选运行 Factory 的实现和质量评审者。不要为 Factory 候选运行单独的独立变更评审。
- 非通过时，按与规划相同的响应规则记录 revise 或 re-review。revise 恢复有效实现者会话，并将完整持久发现带入一个不同的候选；re-review 不调用生产者，用接受的响应评审未更改的候选。
- 将 implementation continue 视为仅持久决定；单独调用打印的 implementation run。
- 通过时，验证 Factory 提升了确切已评审提交，并保持分支和索引干净。
- 仅在明确授权后发布。在记录的拉取请求处停止，让人决定是否合并。人工合并后，在运行合并确认前验证 URL 和合并提交。
- Factory 记录实现 PR 合并后，编排器使用提供者原生工具清理其创建的任何临时目标工作树或 Grove 租约。对于更早的等待或失败，保留它；保留 Factory 证据。
重试与恢复规则
- 新阶段允许同一处理器和 Factory 尝试最多三次自动执行。如果第三次持久结果是可重试的，Factory 将其记录为需要人工。在由此产生的人工等待处停止；不要调用或发明另一个操作。
- 不要将重复投递、保存结果恢复、下一事件发送重试或抛出基础设施错误的 Inngest 重试计为另一次 Factory 执行。显式人工 revise 和 re-review 继续开始新的适用链，并保持调用者控制，没有固定限制。
- 重复显式 --apply 命令以修复其失败的 Linear 投影。恢复不得追加重复阶段请求或重跑已完成的提供者动作。
- 仅当阶段失败且没有可复用候选，或明确授权重新分类时使用 --rerun。绝不用它放弃有效候选。
- 跨修订保留原始生产者会话。拒绝缺失、格式错误或错误提供者的会话连续性，而不是静默重新开始。
- 保留现有运行、不可变引用、结果和用户数据。绝不编辑或删除持久状态来制造成功。
- 在处理存储不兼容、提供者/评审者变更、中断发布或模糊传输之前，遵循恢复参考。
停止条件 在以下情况之前停止并报告：任何等待或人工反应；意外路由、处理器、候选、评审裁决或下一条命令；冲突或缺失的变更授权；并发动作所有权或仍在运行的命令；控制器、目标分支、HEAD、索引、工作区、候选引用或当前阶段引用在动作文档授权之外的漂移；不兼容或未标记的非空 Factory 存储；对 Linear、GitHub、Jira、Inngest 或其他系统的不支持变更；合并，除非用户明确授权；提交生成的 .harness/runs/* 或修改持久 Factory 证据；恢复已移除的调度器、添加 CLI 循环或批量移动收件箱条目。
适用场景与限制 该技能适用于需要人工逐步控制 Factory 工作项生命周期的操作场景，强调持久状态、明确授权和边界报告。其限制包括：不自动循环、不推断转换、不自行发明评审上限、不无授权合并、不修改持久证据。具体命令、标志和配置细节以生成的帮助和资料中引用的参考为准；资料未提供的收费、价格、平台支持等信息暂未提供。