factory

factory

根据跟踪器、PR、检查、评审和部署证据推导状态和下一项技能。报告是无状态的；运行会保留执行检查点。

输入

• 模式 — report（默认）或 run，取自第一个参数。只有用户自己的请求明确要求时才进入 run；状态问题绝不代表此意。
• 引用 — 以下之一：规格（PRD）议题（PRWL-100、GitHub 议题 URL 或编号）、工单、PR 编号或 URL，或表示尚无规格的构想的 start。run 还接受标签名称（/factory run automate）：所有带有该标签的未关闭议题。缺失 → 询问；绝不根据当前分支猜测。可选的 reviewer=<harness>/<provider>/<model> 可在无人值守启动时回答评审者问题。
• 记录跟踪器 — Linear（通过 Linear MCP）或 GitHub（通过 gh），从工作区 AGENTS.md 读取。不明确 → 询问。
• 暂存分支 — 默认为 staging；在任何依赖此分支的状态之前，使用 git ls-remote --heads origin <branch> 确认。

规则

• 报告模式为只读。 它会读取跟踪器、gh 和 git。不会写入远程内容，也不会编辑文件；所有状态变更都由其指定的技能负责。
• 报告模式只提供建议，不会自动串联执行。 使用精确调用方式指定下一项技能，然后停止。由用户运行。只有由用户启动的 run 模式才会继续执行建议。
• 关卡需要证据，而非状态用语。 只有满足 references/states.md 中可观察到的信号，关卡才算通过：针对 head 的必需 CI 证据（或权威的「不适用 CI」策略及强制本地证明）、绑定到 head 的 QA / 风险证据，以及针对合并提交的部署监控证明。标签、聊天中的说法或「CI 没问题」都不能通过关卡。
• 所有内容都绑定到 Head SHA。 只有针对 PR 当前 headRefOid 的评审、QA 和风险证据才有效；只有评审中的 commit.oid 等于 head 时，批准才有效。新的推送会让 PR 重新进入 CI 阶段。
• 暂存是上限。 READY_FOR_OWNER 是终态。绝不建议部署到生产环境、创建生产 PR / 合并 PR 或推出功能标志。默认分支仅限负责人操作，除非明确授权进行非生产交付 local；否则应指出负责人。
• 无法读取的信号必须停止。 表格所需的信号无法读取（跟踪器访问遭拒、找不到部署工作流）→ 报告 UNKNOWN 并说明缺少什么。绝不猜测更高级的状态。gh 查询失败或报错时，结果为未知——绝不是空结果、通过或绿色；报告命令及其错误。
• 不添加任何归属信息。 所有输出中都不得标注共同作者、AI 或工具归属，references/records.md 中的评审者来源信息除外。
• 阶段转换时，遵循 references/session-handoff.md 中可移植的状态与等待约定。

工作流

1. 确定工作单元

根据引用，构建待放置单元的列表：一个规格会展开为其所有子议题，包括未关闭和已关闭的议题（注明数量）；一个工单或 PR 算作一个单元。对每张工单，查找其 PR：使用 gh pr list --search "<issue-id>" --state all --json number,headRefName,baseRefName,state，或查询跟踪器的关联 PR 字段。已关闭和已合并的工单仍保留在列表中——它们可能仍处于 STAGING。除 not-deployed 以外的 qa-escape 标记会根据之后最新的 PR 放置其工单。

2. 读取信号

每个单元只读取状态表所需的内容。解读检查项之前，先应用 references/ci-policy.md；该文件会区分已知的无 CI 策略与待处理、失败、缺失的必需检查项，以及无法读取的策略：

gh pr view <pr> --json state,isDraft,baseRefName,headRefOid,mergeCommit,mergedAt,reviewDecision,reviews,statusCheckRollup,autoMergeRequest,body,comments,commits
gh pr diff <pr> --name-only
gh run list --workflow <deploy-workflow> --branch <staging-branch> --json headSha,status,conclusion,url
gh issue view <issue> --json state,comments

使用分页 GraphQL reviewThreads 查询读取尚未解决的评审讨论串；在合并之前，无法读取的讨论串状态为 UNKNOWN。

通过 PR 和 issue 记录读取 QA／风险／部署证据，参见 references/records.md。Linear 评论使用可读的标题和字段；旧版记录仍可读取。针对所需修订版本的最新有效证据优先。清除 BUILDING 状态的 Acceptance criteria 判定必须注明 head：读取正文；否则，读取最新的 ## QA handoff，其 Change: SHA 必须是 head。旧 head 的验收不计入。

3. 确定每个单元的状态

将信号与 references/states.md 中的表格匹配，从首行开始检查——第一个满足条件的行就是该状态。状态顺序为：OUTCOME、TICKETS、QA_RETURNED、BUILDING、CI_STUCK、CI、QA_STUCK、CHANGES、QA、REVIEW、HUMAN_REVIEW、MERGE、READY_FOR_OWNER、DEPLOY_FAILED、STAGING，以及 UNKNOWN。

4. 检查门槛并选择一项后续技能

针对每个单元，说明从当前状态出发的门槛，以及是否具备相应证据。从表格的 next 列中为每个单元准确选择一项后续技能。当该技能运行或更改代码时，注明它将使用的工作树——PR 使用 <project-repo>/.worktrees/pr-<n>，escape 使用 .worktrees/qa-escape-<issue>。对于包含多个单元的规格，建议顺序应先列出受阻单元（QA_RETURNED、DEPLOY_FAILED、CI_STUCK、QA_STUCK、CHANGES、UNKNOWN），再列出进展正常的单元；正常单元按 Since 从早到晚排序，处于同一状态超过 3 天的单元标记为 stalled。共享门槛和技能的单元合并为一条建议。

5. 报告并停止

打印下方输出。报告模式到此结束：不要运行建议的技能，即使用户不在也一样；下一步由用户决定。

运行模式

用户的 /factory run <reference> 会批准整个链路。首先阅读 references/run.md；其中的 阶段映射 指明单元首次进入相应状态时需要阅读的后期阶段文件（references/review-and-delivery.md、[references/returned-by-qa.md](references/returned-by-qa.md）。

派发前阅读任务简报；继续执行时阅读收据；QA 期间阅读草稿。

1. 接收。 按步骤 1 解析单元，并在执行构建器／运行时工作前应用 分流。信息完整的工单可在运行授权下进行范围明确的资格状态转换；有歧义的工作则暂缓。仅发布用于重述既有结果的缺失条件。应用 开始 以继承构建器。除非已回答，否则只询问审核者问题。

   若审核者尚未回答 → 停止，并提供设置说明和继续执行提示。恢复时保留原有选择。完成此接收阶段后，运行过程不再提问。

2. 循环。 等待活跃子任务并自动继续；工作进程的一轮结束不代表工厂停止。遵循 依赖感知调度：彼此隔离且独立的单元可在容量范围内并行；父级负责串行整合。对于每个就绪单元：安置该单元（步骤 2–4），按 阶段映射 执行其 Next，然后再次安置；记录并应用 经验教训。每个单元都要：将状态设为 In Progress，使用专属工作树和 任务栈，在所选后端上由构建器工作进程处理，在 QA 工作进程中进行 Agent 式 QA，创建 PR，运行 CI，在审核者与构建器之间执行 审核循环，进行风险审核，执行 合并，以 In Review 状态进行 交接，执行 清理、晋级、暂存。对于设置或本地运行时阻塞，阅读 references/readiness-and-recovery.md；加载阶段技能 规定了恢复和停止流程。

3. 暂缓项。 对于需要人员处理的单元（高风险审核、额度耗尽、仅报告者掌握的事实），附上证据并暂缓；继续运行。不得编辑受跟踪的 Compose 文件或问题正文；不得关闭问题。

4. 运行报告。 没有剩余自动工作时，打印输出表格、暂缓单元的标准交接信息、起草的条件、生产就绪情况和 经验教训。

输出

Factory — <reference>  (<n> units)

| Unit | PR | State | Since | Gate evidence | Next |
| ---- | -- | ----- | ----- | ------------- | ---- |
| #418 | #87 | CI | 2026-10-02 14:10 | run 9912 failed on a1b2c3d (unit-tests) | /ci-loop 87 |
| #419 | #88 | HUMAN_REVIEW | 2026-09-28 09:02 (stalled) | risk-review tier=high on 4e5f6a7 (migration) | engineer review — no skill |
| #420 | #85 | READY_FOR_OWNER | 2026-10-01 17:45 | deploy run 9890 success on merge 7c8d9e0, smoke passed | owner promotes — factory ends |

Escapes: 2 qa-escape on this spec — 1 after agentic-qa verified (honesty gap: #418 missed-empty-state)
Next: /ci-loop 87

每个单元最多占一行；Gate evidence 应注明运行、SHA 或评论，不能只写一个不带说明的“pass”。Since 是安置该单元的信号的时间戳（head 推送、标记或运行），请从本次运行中读取。结尾的 Next: 行提供唯一最紧急的建议。若某个单元为 UNKNOWN，其行应说明缺少哪个信号。Escapes: 行统计规范中重现的 qa-escape 标记数量（排除类别为 not-a-regression 的标记），并统计其中有多少标记指定了 PR（pr=），且该 PR 的最终 head 带有 verified agentic-qa 标记——此数量即为诚信差距；请逐一列出。

完成标准

• 规范中的每个单元都出现在表格中，且打印的单元数量与从跟踪器读取的子问题总数（包括未关闭和已关闭）相符
• 每个 Gate evidence 单元格都注明本次运行中实际读取过的运行 ID、SHA 或评论标记
• 报告模式：git status 和 PR 均显示本次运行未作出任何更改，且未调用下一项技能
• 运行模式：就绪／修复证据注明检出环境／运行时、原因、已更改的条件以及复查结果，并且未超过任何额度
• 运行模式：每个单元最终都已合并且其交付记录已回读，或已注明明确原因并暂缓；清理回读应显示没有遗留任务运行时资源或 /tmp/<task-id>/，否则应逐一列出；不得关闭任何问题，也不得更改任何受跟踪的 Compose 文件