# 入队后的 ticket 执行

## 建立机器上下文

先读 `main_loop.py status --help`，再按 stdout 分开读取 qualified `TICKET_FRONTIER` 与
`INTEGRATION_FRONTIER`，并处理 `CLAIM`、`STALE`、`BLOCKED`、`TICKET_ERROR`、
`BLOCKED_DEPENDENCY`、`WAITING_ON`、`FEATURE_BLOCKED` 和 `MAIN_INTEGRATION_COMMIT`；
单 feature 空 frontier 不是全局 BUSY。

claim 前使用 `--state-root "<PROJECT_ROOT>/.scratch"`；claim 必须显式传绝对
`--repo-root "<PROJECT_ROOT>"`、全局唯一 `--owner` 和 `--isolation`。只从
`main_loop.py claim --help` 取得参数。成功 assignment 的键是 `FEATURE`、`TICKET`、
`CONTROL_ROOT`、`STATE_ROOT`、`WORKSPACE`、`BRANCH`、`BASE`、`ISOLATION`。

领取后立即从返回的绝对 `STATE_ROOT` 读取 feature spec/ticket。领取后实现前重读三个
memory-bank 文件；不要预猜 ticket，也不要使用 worktree 中的 `.scratch` 副本。
`NO FEATURES`、`NOOP`、`BUSY`、`RETRY` 和 `INTEGRATION_REQUIRED=<feature>@integrated`
是 stdout/0 的机器结果，`ERROR` 是 stderr/2；始终解析 stdout。只有全局无可领取 ticket 且
integration frontier 可推进时，才把 `INTEGRATION_REQUIRED` 交给 feature integration 路由。

## 🔴 Integration visibility RETRY

stdout 出现 `RETRY: dependency integration is not visible` 时，立即停止 claim 和实现。
必须原样取得 `TICKET`、`DEPENDENCY`、`INTEGRATION_COMMIT`、`WORKSPACE`、`BRANCH`、
`BRANCH_HEAD`、`TICKET_BRANCH`、`TICKET_BRANCH_HEAD`、`SYNC_BRANCH`、`MAIN_BRANCH`、
`MAIN_HEAD`、`SYNC_COMMAND`。

任一字段缺失就报告原始 stdout 并停止，不自行推导 fetch、merge、rebase 或 cherry-pick。
从任一现有目录执行返回的 `SYNC_COMMAND`；它负责创建或使用 `WORKSPACE`，不要预先切换到
可能不存在的目录。成功后重新运行 status/claim；取得正式 assignment 前不得继续。

## 隔离、租约与恢复

- 请求 in-place 时，任意活动 claim 都令其 BUSY；活动 in-place claim 也阻止新 claim 和
  pending integration。
- worktree ticket 可跨 feature 并发；活动 worktree 不阻止更早 feature integration。
- `auto` 在全局无 claim 时选 in-place，否则选 worktree；同 owner 只恢复自己的 ticket。
- in-place 要求 control checkout 除 `.scratch` 外干净；不要 stash、reset 或覆盖其他 session 改动。

claim 租约固定为 30 分钟，至少每 10 分钟运行 `main_loop.py heartbeat`，并在长验证/review
前后续租。`reclaim` 只接管 stale 的 `claimed` ticket，保留 branch、workspace、未提交改动和
原 `BASE`；接管后原 owner 不得 heartbeat/finish。

blocked ticket 用原 owner 的 `main_loop.py finish --result released` 释放；原 session 丢失时才用
`main_loop.py release-ticket`，不要用 reclaim。claim 环境准备失败会占住该 ticket，也按此恢复；
blocked/skipped 必须给 reason，released 回到 ready 并保留 workspace。禁止猜 ticket、复用通用
owner 或自动转移 stale claim。

## 实现、Review 与 Finish

按顺序执行：读取已领取 ticket 的 spec → 按 `tdd` 实现与验证 → 提交全部实现 →
运行 `code-review` 的 Standards/Spec 双轴 → 修复硬 finding 后重新提交、验证、完整 review →
结构化证据调用 main_loop.py finish。

ticket review 的 fixed point 是 claim 返回的 `BASE`，或 RETRY 返回的 `FEATURE_HEAD`；
Spec sources 是 `<STATE_ROOT>/<feature>/spec.md` 与
`<STATE_ROOT>/<feature>/issues/<NN>-*.md`。只有对应 axis 零个未解决的硬 finding 才能映射为 pass；
`code-review` 不给 pass/fail 判定，来源缺失、axis 跳过或仍有 finding 时不得填写 pass。

收到 `RETRY: feature advanced` 时，把该 `FEATURE_HEAD` 合入 ticket branch，重新验证并以它为新
review base；只有成功合入 feature branch 后 ticket 才能 resolved。调用前读取
`main_loop.py finish --help`，不得复用旧 artifact。

无人值守或当前 session 无法继续时，按 `main_loop.py finish --result blocked` 记录具体 reason。
按各自 `--help` 调用 `main_loop.py status`、`main_loop.py heartbeat`、`main_loop.py finish`、
`main_loop.py reclaim`、`main_loop.py release-ticket`、`main_loop.py block-feature`、
`main_loop.py release-feature`；不维护命令职责表。

## 证据门禁

ticket、feature、main candidate 验证是三个独立门禁，不能互相替代。只接受 fresh UTF-8 JSON artifact；
精确 verification/review schema 以 `finish --help` 和 `integrate --help` 为准。
主循环校验摘要、Git object、branch tip、review base 与 workspace，并快照到
`.scratch/<feature>/evidence/`。

artifact 无法证明命令真的执行过或报告来自真实 review；无法证明命令真的执行过时不得伪造 pass。
完成前做 fresh verification，并按帮助输出构造结构化参数。禁止手工修改 ticket `Status`，
禁止为旧 Blocked by 格式增加 fallback，禁止伪造或复用证据 artifact。