# AGENT_RULES

<!-- playbook:rules:start -->

目的：为本仓库提供稳定的 Matt Pocock 工程流程与 ticket 执行约束。

`.scratch/` 是 spec、ticket、feature 队列和执行状态的唯一事实源。
`memory-bank/` 保存稳定的项目定位、技术上下文和当前系统模式。
`CONTEXT.md` 保存稳定领域词汇，`docs/adr/` 保存关键架构决策。

## 优先级

1. 系统/开发者指令
2. 项目私有规则：`AGENT_RULES.local.md`（如存在）
3. 仓库规则：`.agents/` 与 `AGENTS.md`
4. 本文件

## 沟通原则

- 统一使用简体中文
- 发现用户理解有误时，礼貌纠正
- 不给时间估算，专注事实、风险与下一步

## 项目边界

- `{{PLAYBOOK_ROOT}}/` 是 Playbook 模板/供应商目录，不是业务项目源码
- 除非任务明确维护 Playbook，不得修改 `{{PLAYBOOK_ROOT}}/` 下内容
- 当前项目的生效规则位于项目根目录的 `AGENT_RULES.md`、
  `AGENT_RULES.local.md`、`AGENTS.md` 与 `.agents/`
- 搜索、批量修改、review 和提交时默认排除 `{{PLAYBOOK_ROOT}}/`
- 不覆盖、stash、reset 或提交不属于当前 ticket 的既有改动

## 会话启动

处理首个实质性任务前，按相关性读取；不存在则跳过：

1. `AGENT_RULES.local.md`
2. `.agents/index.md`
3. `memory-bank/project-brief.md`
4. `memory-bank/tech-context.md`
5. `memory-bank/system-patterns.md`
6. `docs/agents/issue-tracker.md`
7. `docs/agents/domain.md`
8. `CONTEXT.md` 或 `CONTEXT-MAP.md`
9. 相关 `docs/adr/`
10. `main_loop.py status --state-root .scratch` 的当前状态

## 任务入口

四个入口按成本递增排列，**从上往下取第一个满足的**。每个入口都定义了强制升级条件；条件成立
时立即停止当前路径并转入指定入口，已产生的改动只作为事实输入，不视为已批准方案。

### 入口 1：直接执行

只读分析、定位、审查，以及不改变可观察行为的机械修改（重命名、格式化、注释、导入整理、纯
文档措辞）。不生成 spec/tickets，不建 branch。仍须遵守项目规则、验证实际结果，并只处理本次
相关改动。

**升级条件**：出现任何可观察行为变化 → 入口 2。

### 入口 2：单切片改动

会改变行为、不属于入口 3 的已知 bug，且同时满足以下**全部**条件的改动走这里，不入队、不建
ticket branch：

- 只涉及一个模块，或只扩展一个已存在的公开接口
- 能在已存在的测试 seam 上验证，不需要新建 seam
- 不新增公开接口、配置项、数据格式或第三方依赖
- 不涉及数据迁移、回滚、兼容性窗口或并发协调
- 预计一个 session 内交付，不需要跨 session 调度

流程：在已存在 seam 上按 `tdd` 完成一个可观察行为切片 → 运行局部验证 → 提交 → 对
`HEAD` 运行 `code-review` 的 Standards 单轴 → 修完硬 finding 后重新提交和验证。证据
写入 commit message 和 session 收尾，不写 `.scratch/`。

**升级条件**（任一成立即停止并转入口 4）：需要新 seam、跨出上述任一条边界、或发现
未确认的设计取舍。

### 入口 3：已明确预期行为的 bug

正确行为已知的 bug 走这里，**无论当下能否建立失败反馈回路**——建立反馈回路是
`diagnosing-bugs` 的 Phase 1，不是进入它的前提。`diagnosing-bugs` 完整执行 Phase 1-6，负责反馈回路、
复现最小化、假设、回归测试、修复、验证和清理；不另起 `tdd` 会话（Phase 5 内部已是
test-first），也不为已确定的需求重新 grilling。

两种缺口按该 skill 自身的规定处理：Phase 1 建不出可失败的命令时停下来索取环境、artifact 或
许可，不要换入口绕过；不存在正确 seam 时把"缺失 seam"本身作为发现记录，不因此中断修复，
修复落地后再建议 `improve-codebase-architecture`。诊断暴露新的产品取舍或架构方向时，先完成
Phase 5-6 让缺陷不再复现，再把取舍带入入口 4，不要把未修完的缺陷留在原地等设计结论。

若 bug 来自已领取 ticket，Phase 6 后直接继续本地 ticket 执行协议的提交、review 和 finish
门禁。

### 入口 4：新 feature 或设计变更

以下任一条成立时进入完整工程主链：

- 存在需要用户决策的产品取舍或架构方向
- 需要新的测试 seam，或新增公开接口、配置项、数据格式
- 跨两个以上模块边界
- 涉及数据迁移、回滚或兼容性窗口
- 需要跨 session 调度或多 session 并发
- 预计无法在一个 session 内交付

**边界不清时先按入口 2 起步**，触到入口 2 的任一升级条件时立即转入本入口。"不确定"的正确
处置是用最小路径试探到边界，不是预付最贵的流程。

### 非交互模式下的入口 4

主链的 grilling 收敛和 seam confirmation 需要用户在场。无人值守而判定为入口 4 时：已有已领取
ticket 就 `finish --result blocked --reason "<待确认的具体决策>"`；尚无 ticket 则不得代替用户
决策、也不得降级到入口 2 硬做。用 `to-questionnaire` 把待决问题写到项目根目录的
`.scratch/questions/<slug>.md`，记录阻塞阶段、已知上下文、待决问题和恢复入口；用户回答后从
`grill-with-docs` 恢复。不得把问题清单写入临时 worktree 或稳定知识文件。

## 正式工程主链

入口 4 使用以下顺序：

```text
setup-matt-pocock-skills
  -> grill-with-docs (grilling + domain-modeling)
  -> to-spec
  -> to-tickets
  -> main_loop.py enqueue
  -> main_loop.py claim
  -> 本地 ticket 执行协议 (tdd -> commit -> code-review -> finish)
  -> main_loop.py integrate
```

- 每个仓库首次使用时运行 `setup-matt-pocock-skills`，本地开发选择 local markdown tracker
- 进入 `grill-with-docs` 或本地 ticket 执行协议前，重新读取 `memory-bank/project-brief.md`、
  `memory-bank/tech-context.md` 和 `memory-bank/system-patterns.md`
- `grilling` 必须走完整 design tree，**design frontier**（尚未定下的决策集合）清空并经用户
  确认后才进入 `to-spec`。该词与调度语义里的 ticket frontier 无关
- seam confirmation 的责任在 `to-spec` 与 `tdd`，不在 `grilling`——后者只收敛设计决策，不涉及
  测试 seam。`to-spec` 必须按其原始流程与用户确认 seam 并写入 spec 的 Testing Decisions；
  `tdd` 不得在未经确认的 seam 上开始
- `to-spec` 不重新进行已经完成的需求采访
- `to-tickets` 产出可独立验证的 tracer-bullet tickets，并显式声明 `Blocked by`
- 一次可以先生成多个 feature 的 spec/tickets，再按期望顺序逐个 `enqueue`
- `codebase-design` 是 seam、deep module 与依赖分类的词汇来源，供 `to-spec` 和 `tdd` 查阅，
  不作为独立会话运行

## On-ramps 与 detours

- 超过单个 session 可容纳的巨大、模糊工作先走 `wayfinder`；决策地图清晰后进入
  `to-spec -> to-tickets`，不得从决策 ticket 直接跳到实现
- `research` 产出的高可信一手来源报告先进入 `grill-with-docs`，作为设计输入；调研不能
  替代 grilling
- 已由 `to-tickets` 生成的 ticket 直接从 `main_loop.py claim -> 本地 ticket 执行协议` 开始，
  不再 triage 或重复需求采访

## Phase boundaries

只在阶段边界判断去向，阶段中途不做这个决定。按以下顺序取首个满足项：

1. 下一阶段需要当前 session 作为 primary source，或剩余 smart zone 仍够下一阶段
   （约 150k tokens）时，继续当前 session
2. 当前上下文与下一阶段无关时，使用 `clear`
3. 仅在跨 harness、跨目录/仓库、交给同事或 mid-phase 分出旁支任务时使用 `handoff`
4. 任务可独立 AFK 完成时交给 subagent
5. 其余同 harness、同目录且仍需当前上下文的情况使用 `compact`，并附上下一阶段要保留
   什么的指令

上下文过长不等于必须 `handoff`；`handoff` 解决的是可移植性。`compact` 是决策树的默认落点，
但不是第一选择——除 continue 以外的每个选项都把 primary source 换成 secondary source。
`CONTEXT.md` 和 memory-bank 都不能替代阶段上下文。

## 本地 Ticket 执行协议

这是 Playbook 对 Matt 工程 skills 的调度适配层，只复用 `tdd` 和 `code-review`。尾部顺序与
上游的 `code-review -> commit` 相反：主循环要求证据绑定到固定 commit，所以先提交再 review。

对每个 claim 严格按以下顺序执行：

1. 读取已领取 ticket 的 spec、ticket、相关稳定知识和 ADR
2. 在已确认 seam 上按 `tdd` 完成 ticket 的可观察行为，并运行局部验证
3. 提交全部实现，使 ticket branch `HEAD` 成为固定、干净的审查点
4. 运行 `code-review`，显式提供 fixed point 和 Review 适配契约规定的需求来源
5. 修复硬 finding 后重新提交、验证和 review，直到两个 axis 均满足 pass 条件
6. 调用 `main_loop.py finish`，提交与当前 `HEAD`/base 绑定的结构化证据

## 文档职责

- `memory-bank/project-brief.md`：稳定项目定位、边界、目标和成功定义
- `memory-bank/tech-context.md`：技术栈、工具链、环境差异和验证入口
- `memory-bank/system-patterns.md`：当前模块边界、数据流、系统不变量和扩展路径
- `CONTEXT.md`：稳定领域词汇和定义，不记录 feature 状态
- `docs/adr/`：难以逆转且需要长期背景的真实技术取舍
- `.scratch/<feature>/spec.md`：单个 feature 的问题、方案、用户故事和测试决策
- `.scratch/<feature>/issues/*.md`：ticket DAG、验收标准和机器状态
- `.scratch/queue.md`：feature 开发与集成顺序
- `docs/agents/*.md`：tracker、领域文档布局和 skill 配置

不得手工修改 ticket 的 `Status` 或 `main-loop:ticket-state` 区块；只通过主循环变更。主循环
没有对应命令的状态组合按"卡死与恢复"处理，仍然不手工改。

`.scratch/` 是否纳入版本控制由项目决定并写入 `AGENT_RULES.local.md`：纳入则 spec、ticket 和
证据进入历史，可审计、新 clone 能接手队列，代价是状态变更产生提交噪音；排除则历史干净，
代价是状态只存在于本机磁盘、集成后审计线索消失，并发只靠"共享同一文件系统"兜住。无论哪种
都不得把两份 `.scratch/` 当成同一队列。

## 稳定知识维护

只记录下一 session 仍需要的稳定知识；当前 feature、ticket、owner、heartbeat、验证和集成
状态只由 `.scratch/` 与 `main_loop.py` 维护。

- 项目定位、边界、目标或成功定义长期变化时，更新 `project-brief.md`
- 技术栈、工具链、环境差异或验证入口长期变化时，更新 `tech-context.md`；写入
  `tech-context.md` 的命令和环境事实必须已经验证
- `system-patterns.md` 记录当前成立的架构；关键取舍及理由写入 `docs/adr/`
- `CONTEXT.md` 只记录稳定领域词汇和定义；不把聊天流水、未验证猜测或短期进度写入
  `CONTEXT.md`
- 项目特有执行规则写入 `AGENT_RULES.local.md`
- `handoff` 的产物写入 OS 临时目录，不写入稳定知识文件
- 不为普通实现选择创建 ADR；没有长期价值的信息时不更新这些文件

## 调度语义

- feature 按 `.scratch/queue.md` 顺序调度
- 同一 feature 中 blocker 全部满足的 tickets 构成 ticket frontier，按稳定编号领取
- 同一 feature 的多个 frontier tickets 可在 worktree 模式并发执行
- 当前 feature 的 frontier 全被领取时返回 `BUSY`，不向后续 feature 扩张
- 只有前序 feature 无 frontier、无活动 claim 且确实 blocked 时，才可开发后序 feature
- 前序 feature 恢复后，新 claim 重新优先前序 feature
- 后序已领取 ticket 可以完成，但 feature 集成到 `main` 必须严格遵循队列顺序
- `resolved` 和显式 `skipped` 满足 blocker；`claimed`、`blocked`、
  `ready-for-agent` 不满足
- 含 `skipped` ticket 的 feature 标记为 partial，集成时必须显式授权
- stale 只由 heartbeat 时间派生，不自动转移 owner；只有 `reclaim` 可以接管

### 读取输出而不是只看返回码

`BUSY`、`NOOP: ...`、`RETRY: ...` 都写到 stdout 并且**返回码为 0**；只有真正的错误才是
`ERROR: <msg>` 到 stderr、返回码 2。调用方必须解析 stdout，不能用返回码判断是否拿到 ticket。

`status` 输出 `FEATURE=`、`STATE=`、`PARTIAL=`、`FRONTIER=`、`CLAIM=`、`OWNER=`、
`HEARTBEAT=`、`STALE=`、`ISOLATION=`、`WORKSPACE=`、`TICKET_ERROR=`、`BLOCKED=`、
`FEATURE_BLOCKED=`、`MAIN_INTEGRATION_COMMIT=`；队列为空时输出 `NO FEATURES`。

`STATE=active` 不代表可推进：tickets 只剩 `resolved` 与 `blocked` 的 feature 同样报
`STATE=active FRONTIER=-`，此时 `claim` 返回 `NOOP`。判断是否卡住要同时看 `FRONTIER=-` 和
是否存在 `BLOCKED=` 行。

### 心跳的实际作用

heartbeat 没有强制力：过期 claim 仍保有全部权限，原 owner 可以继续 heartbeat、`finish` 和
resolve。stale 的唯一后果是**别人获得 `reclaim` 的资格**。所以"每 10 分钟一次"是为了让接管
判断准确，不是为了保住 claim。

### 卡死与恢复

- claim 的环境准备失败时，主循环把该 ticket 写成 `blocked`、记录原因、把 `claimed_by` 设为
  本次 owner，并以返回码 2 退出。一次失败的 claim 会占住这张 ticket
- `finish --result released` 只允许原 `claimed_by` 解除 blocked；原 session 已丢失时用
  `release-ticket`
- `reclaim` 只接管 `claimed` 状态的 stale claim，不能用于 `blocked` ticket
- resume 与 `reclaim` 返回的 `BASE` 是 claim 当时记录的值，**不会刷新**；feature head 已推进
  时直接拿它去 `finish` 会得到 `RETRY: feature advanced`，按重试流程取新的 `FEATURE_HEAD`

## 执行隔离

`claim --isolation`：`in-place` 串行执行不建额外 worktree；`worktree` 每个 ticket 独立
branch/worktree，适用于多 session 并发；`auto` 无其他活动 claim 时用 in-place，否则用
worktree。计划并发时第一个 session 就必须指定 `worktree`。

`BUSY` 的作用域是**整个队列，不限于同一 feature**，来源有三个：请求 `in-place` 而队列里存在
任何活动 claim；队列里存在任何 `in-place` 活动 claim（此时所有 isolation 的新 claim 都
BUSY）；队首可调度 feature 的 frontier 已被领完。stale claim 也算活动 claim，必须显式
`reclaim` 或 `release-ticket` 才能腾出位置。同一 owner 恢复自己的 ticket 不受这些检查影响。

in-place 要求 checkout 无非 `.scratch` 改动、HEAD 非 detached、目标 branch 未被其他 worktree
占用。主循环不得自动 stash、reset、覆盖或丢弃改动。唯一例外：重新 claim 自己此前以 in-place
释放的同一 ticket 且 workspace/branch 都匹配时，跳过 dirty 检查以保留未提交改动。

worktree 模式下若 `feature/<slug>` 正被 control checkout 占用，主循环会先确认它干净、再把
control checkout 切到主干以释放该 branch。

`main_loop.py` 只支持 local Markdown tracker，要求所有 sessions 共享同一文件系统、control
checkout 和 Git common directory。远程 tracker 可以由 Matt skills 单独使用，但本主循环没有
远程 tracker adapter，不能接入远程 claim/finish 状态；跨机器或独立 clone 的并发不受支持。

## 主循环命令

主干 branch 名不是 `main` 时，`claim` 和 `integrate` 必须显式传 `--main-branch <name>`；其余
子命令不接触主干，也不需要 `--repo-root`。

### 入队和状态

```bash
python {{PLAYBOOK_SCRIPTS}}/main_loop.py enqueue \
  --state-root .scratch --feature <feature-slug>

python {{PLAYBOOK_SCRIPTS}}/main_loop.py status \
  --state-root .scratch
```

`enqueue` 对已入队 feature 幂等，返回 `EXISTS=<slug>`。

### 领取

`<owner>` 必须全局唯一且在本 session 内稳定，例如 `<agent>-<UTC timestamp>-<random>`。
不得在并行 session 间复用 `codex`、`claude` 等通用名称；同一 owner 重复 claim 只用于原
session 恢复自己的 ticket，其他 owner 不得接管，失联时用显式 reclaim。

```bash
python {{PLAYBOOK_SCRIPTS}}/main_loop.py claim \
  --state-root .scratch --repo-root . \
  --owner "<owner>" --isolation in-place|worktree|auto \
  [--main-branch main]
```

stdout 返回 8 个赋值行：`FEATURE`、`TICKET`；`CONTROL_ROOT` 是共享 Git control checkout；
绝对 `STATE_ROOT` 是唯一状态目录，不必位于 `WORKSPACE` 内；`WORKSPACE` 是当前 ticket 的代码
工作区；其余为 `BRANCH`、`BASE`、`ISOLATION`。也可能返回 `NO FEATURES`、
`NOOP: no claimable tickets`、`BUSY`，或 `INTEGRATION_REQUIRED=<slug>`（队首 feature 已
ready-to-integrate，必须先 `integrate`）。

领取成功后立即读取 `<STATE_ROOT>/<FEATURE>/spec.md` 和
`<STATE_ROOT>/<FEATURE>/issues/<TICKET>-*.md`；不得在 claim 前根据 frontier 猜测将领取哪个
ticket。后续 review 也必须用这两个已领取上下文，而不是 worktree 内相对 `.scratch` 的偶然
副本。

实现、提交和 review 在返回的 `WORKSPACE`/`BRANCH` 中完成；其余子命令一律用
`--state-root "<STATE_ROOT>"`，不得在 ticket worktree 中使用相对 `.scratch`。feature 集成
workspace 的路径不在 claim 输出里，只写在 `<STATE_ROOT>/<FEATURE>/.main-loop.json` 的
`integration_workspace`；纯 in-place 流程不创建该文件，feature 级操作在 `CONTROL_ROOT` 上做。

### 心跳和接管

claim 的 stale 租约固定为 30 分钟，调用者不得缩短。claim 存续期间至少每 10 分钟发送一次
heartbeat，并在耗时较长的验证、构建或 review 前后各发送一次。无法继续维持时，根据是否需要
保留阻塞原因分别执行下文完整的 `--result released` 或 `--result blocked --reason` 命令。

```bash
python {{PLAYBOOK_SCRIPTS}}/main_loop.py heartbeat \
  --state-root "<STATE_ROOT>" \
  --feature <feature> --ticket <NN> --owner "<owner>"

python {{PLAYBOOK_SCRIPTS}}/main_loop.py reclaim \
  --state-root "<STATE_ROOT>" --repo-root "<CONTROL_ROOT>" \
  --feature <feature> --ticket <NN> --owner "<new-owner>"
```

reclaim 只接管 stale 的 `claimed` ticket，要求新 owner 与原 owner 不同，保留原 branch、
worktree 和未提交改动。被接管后原 owner 的 heartbeat 与 finish 立即报
`owned by another session`。

### Review 适配契约

`code-review` 只产出 Standards 与 Spec 两段 findings，不给 pass/fail 判定，也不合并或
重排 findings。下面的 `pass` 映射是 Playbook 加的一层，由调用方把 findings 归结为判定。

调用时不得依赖其自动搜索或交互补问，必须显式提供：

- fixed point：ticket review 用 claim 的 `BASE` 或重试返回的 `FEATURE_HEAD`；feature
  review 用最新 `main` HEAD
- Spec sources：ticket review 用 `.scratch/<feature>/spec.md` 与
  `.scratch/<feature>/issues/<ticket>-*.md`；feature review 用该 spec 加本 feature 全部
  ticket 的 acceptance criteria。两者都从绝对 `STATE_ROOT` 解析

只有对应 axis 零个未解决的硬 finding 时才能记录 `pass`：`standards=pass` 指没有未解决的
仓库标准违规（baseline smell 属 judgement call，须逐项记录已修复或带理由接受，不因被提出
就自动失败）；`spec=pass` 指没有遗漏、部分实现、错误实现或未授权范围扩张。

任一来源缺失、Spec axis 被跳过、review 尚在询问输入，或仍有未解决的硬 finding 时，
不得据此填写 `standards=pass` 或 `spec=pass`。修复会改变 `HEAD`，必须重跑受影响验证和完整双轴
review，不能沿用旧报告。

### Ticket 完成或状态转换

`resolved` 前必须先提交实现，再按 Review 适配契约对 `BASE...HEAD` 运行 Matt
`code-review` 的 Standards/Spec 双轴审查。验证证据必须包含被验证 commit，review 证据必须
包含被审查 commit 和固定 base；任意非空文本或裸 `pass` 不能替代结构化证据。

```bash
python {{PLAYBOOK_SCRIPTS}}/main_loop.py finish \
  --state-root "<STATE_ROOT>" --repo-root "<CONTROL_ROOT>" \
  --feature <feature> --ticket <NN> --owner "<owner>" \
  --result resolved \
  --implementation-commit <HEAD> \
  --feature-head <已验证feature HEAD> --review-base <同一feature HEAD> \
  --verified "<ticket-verification.json>" \
  --reviewed "<ticket-review.json>"
```

验证和 review 参数必须是下文定义的 UTF-8 JSON artifact 路径，不接受内联 `pass` 文本。

首次 review base 是 claim 返回的 `BASE`。feature HEAD 已推进时返回
`RETRY: feature advanced` 和新的 `FEATURE_HEAD`；把该 `FEATURE_HEAD` 合入 ticket branch，
重新运行受影响验证，并以它作为新的 review base 重跑双轴 review。重试时
`--feature-head`、`--review-base` 和 review evidence 的 `base` 都用该新值，验证与 review
evidence 的 `commit` 必须等于新的 ticket `HEAD`。只有成功集成到 feature branch 后 ticket
才变为 `resolved`。

`finish` 不检查验收勾选框；验收由 `code-review` 的 Spec axis 负责，勾选框在 resolve 前
自行更新。

其他 `finish` 转换共用上面的 `--state-root`、`--repo-root`、`--feature`、`--ticket`、`--owner`：

```bash
python {{PLAYBOOK_SCRIPTS}}/main_loop.py finish \
  --state-root "<STATE_ROOT>" --repo-root "<CONTROL_ROOT>" \
  --feature <feature> --ticket <NN> --owner "<owner>" \
  --result blocked --reason "<明确原因>"

python {{PLAYBOOK_SCRIPTS}}/main_loop.py finish \
  --state-root "<STATE_ROOT>" --repo-root "<CONTROL_ROOT>" \
  --feature <feature> --ticket <NN> --owner "<owner>" \
  --result released

python {{PLAYBOOK_SCRIPTS}}/main_loop.py release-ticket \
  --state-root "<STATE_ROOT>" --feature <feature> --ticket <NN> \
  --reason "<原 session 无法恢复的原因>"
```

`blocked` 和 `skipped` 都必须提供 `--reason`。`released` 回到 `ready-for-agent` 并保留 workspace，
只能由原 `claimed_by` 调用。`release-ticket` 用于原 session 已丢失、无人能 release 的 blocked
ticket；它不校验 owner，保留 branch、worktree 和未提交改动，返回
`TICKET_RELEASED=<feature>/<NN>`。

### Feature 顺序集成

feature 必须吸收最新 `main`，完成 feature 验证、main 候选验证和最终双轴 review：

```bash
python {{PLAYBOOK_SCRIPTS}}/main_loop.py integrate \
  --state-root "<STATE_ROOT>" --repo-root "<CONTROL_ROOT>" \
  --feature <feature> --feature-head <已验证feature HEAD> \
  --verified "<feature-verification.json>" \
  --main-verified "<main-candidate-verification.json>" \
  --reviewed "<feature-review.json>"
```

partial feature 还需 `--allow-partial`；未显式授权时报错而不是静默集成。

`RETRY: feature needs main sync` 表示 `main` 不是 feature head 的祖先。此时在 feature
integration workspace（纯 in-place 流程下是 `CONTROL_ROOT`）合并最新 main，重新验证和
review 后再调用。main 合并冲突时主循环会**自动**把 feature 标记为 blocked，不需要手工
`block-feature`；解决冲突后 `release-feature` 再重试。

成功后主循环会把 control checkout 切到主干，并移除干净的 ticket worktree 与
`_integration` worktree；不干净或路径异常的保留并以 `WARNING=` 行报告。已集成的 feature
再次调用时幂等返回 `INTEGRATED=`。

ready-to-integrate feature 因人工决策暂时不能集成时必须显式记录，否则主循环不会为后序
feature 继续分配开发工作：

```bash
python {{PLAYBOOK_SCRIPTS}}/main_loop.py block-feature \
  --state-root "<STATE_ROOT>" --feature <feature> --reason "<明确原因>"

python {{PLAYBOOK_SCRIPTS}}/main_loop.py release-feature \
  --state-root "<STATE_ROOT>" --feature <feature>
```

release 后该 feature 重新成为队首 `INTEGRATION_REQUIRED`；后序 feature 即使已开发完成，
仍不得越过它集成到 main。

## Git 与证据门禁

branch 命名：ticket 用 `ticket/<feature>/<NN>-<slug>`，feature 用 `feature/<feature>`。
执行顺序见"本地 Ticket 执行协议"，证据参数见"主循环命令"。

局部 ticket 验证、feature 验证和 main 候选验证是三个独立门禁，不能互相替代。

`--verified`、`--main-verified` 和 `--reviewed` 必须指向 UTF-8 JSON artifact。验证 artifact
包含 `version=1`、`kind=verification`、`commit`、`result=pass`、`command`、`exit_code=0`、
`output` 和 `output_sha256`；review artifact 包含 `version=1`、`kind=review`、`commit`、`base`、
`standards=pass`、`spec=pass`、`report` 和 `report_sha256`。输出和报告必须先移除 secret；摘要是
对应 UTF-8 文本的 SHA-256。

门禁校验每个 commit 真实存在、artifact schema 与摘要、implementation/verification/review
commit 与目标 branch tip 一致、review base 正确、workspace 干净且在自己的 branch 上。成功后
把规范化 artifact 快照到 `.scratch/<feature>/evidence/`，并在 ticket 或 feature 状态中记录快照
路径和 SHA-256；原始 artifact 删除后仍可审计。

artifact 能阻止空文本、字段缺失、摘要篡改和 Git 上下文错配，但无法证明命令真的执行过，也
无法证明 report 来自真实 review。证据必须来自实际 fresh run，无法运行时不得伪造 `pass`；
需要机器强制时由 CI 或 pre-commit hook 生成 artifact。

## 辅助能力

以下能力在对应阶段内按需使用，不替代上面的入口路由和证据门禁：

| Skill                           | 触发条件                                     |
| ------------------------------- | -------------------------------------------- |
| `codebase-recon`                | 架构、跨模块、重构、迁移或风险不明           |
| `brooks-audit`                  | 架构边界和长期维护性审查                     |
| `codebase-design`               | 需要 seam、deep module、依赖分类的词汇与判据 |
| `improve-codebase-architecture` | 修复落地后暴露出的结构问题                   |
| `resolving-merge-conflicts`     | feature 吸收 main 或集成时出现冲突           |
| `to-questionnaire`              | 需要把待决问题整理成清单交回用户             |
| `commit-message`                | 需要检查 staged diff 或生成提交信息          |

## 需要确认的场景

设计阶段由 `grilling` 收敛所有决策。执行 ticket 时仅在以下情况暂停确认：

- ticket/spec 仍存在会改变实现的真实歧义
- 需要 spec 未授权的行为、兼容性或架构取舍
- 需要破坏性操作、覆盖他人改动或扩大任务范围

入口 1、入口 2 范围内的改动和已批准 ticket 范围内的实现不重复需求采访。无交互模式按
"非交互模式下的入口 4"处理，不得替用户作设计决策。

## Session 收尾

- 运行与声明相匹配的 fresh verification
- 列出已完成、未完成、验证证据、风险和下一步
- 只提交当前 ticket/feature 相关改动，不混入其他 session 差异
- 工作未结束时按 Phase boundaries 决策树选择去向

---

**最后更新**：{{DATE}}

<!-- playbook:rules:end -->