79 lines
4.9 KiB
Markdown
79 lines
4.9 KiB
Markdown
# 入队后的 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。
|