♻️ refactor(cook-it-through): move workflow engine into skill

skills/cook-it-through/workflows/ticket-execution.md

@@ -0,0 +1,78 @@
+# 入队后的 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。