flower-trellis 0.5.1-beta.0 → 0.5.1

package/README.md

@@ -52,6 +52,9 @@ flower-trellis init -u <your-name> -y
 # 升级 Trellis 并按新版本重新叠加强化包
 flower-trellis update
 
+# 临时保留最近 5 份升级备份；传 0 可关闭本次自动清理
+flower-trellis update --backup-retention 5
+
 # 检查当前项目是否需要更新(稳定 JSON,供 AI / hook 使用)
 flower-trellis self-check --json --target .
 
@@ -97,9 +100,23 @@ flower-trellis -v
 | `--variant <old\|0.5\|0.6>` | 强制指定强化包变体(默认按 `.trellis/.version` 自动选) |
 | `--target <dir>` | 目标目录(默认当前目录) |
 | `--no-update-check` | 本次跳过 flower-trellis 新版本检测(等价环境变量 `FLOWER_NO_UPDATE_CHECK=1`) |
+| `--backup-retention <n>` | `update` 成功后保留最近 n 份 `.trellis/.backup-<timestamp>` 快照(默认 3，`0` 表示本次不清理) |
 
 未指定平台时,交互模式会弹出多选菜单(默认勾选 Claude Code + Codex);也可直接传 `--claude` / `--codex` / `--cursor` / `--devin` / `--zcode` / `--trae` 等指定,或用 `-y` 跳过菜单。`--windsurf` 仍作为 Devin 的旧别名透传给 Trellis。其余未识别的 flag(如 `-u`、`-f`、`--template`、`--with-statusline`)一律透传给 Trellis。
 
+### 升级备份保留
+
+上游 `trellis update` 会在写入前创建 `.trellis/.backup-<timestamp>/` 完整快照。
+`flower-trellis update` 在 Trellis 更新、强化包叠加和本地配置恢复流程完成后，默认只保留最近 3 份：
+
+- 只有名称严格符合时间戳格式的直接子目录会参与清理；`.trellis/.backup-flower/`、普通文件、
+  软链接和相似名称目录不会被删除。
+- 更新失败时不清理，并保留本轮上游已经创建的备份。
+- `--dry-run` 只展示预计保留和删除的备份，不修改文件系统。
+- `--backup-retention 0` 可关闭本次自动清理；该设置只影响当前命令，不写入项目配置。
+- `self-update` 可通过 `--` 传入覆盖值，例如
+  `flower-trellis self-update --target . --yes -- --backup-retention 5`。
+
 ### 自动版本检测
 
 运行 `init` / `update` 时,flower-trellis 会顺带检测**自身**在 npm 上是否有新版本:

package/enhancements/0.6/.agents/skills/trellis-auto-loop/SKILL.md

@@ -5,216 +5,152 @@ description: "启动、恢复和推进 Trellis 自动任务循环。用于用户
 
 # Trellis Auto Loop
 
-用 `.trellis/scripts/auto_loop.py` 驱动一个接近 `/goal` 的任务循环。Python runner 是状态权威；本 skill 只负责把用户意图映射到 runner 命令，并按 runner 返回的 action 调用现有 Trellis workflow / skill / subagent。
+用 `.trellis/scripts/auto_loop.py` 驱动批量无人值守任务。runner 是状态、manifest、hash、依赖和预算的权威；本 skill 只判断语义边界并执行 runner 返回的 action。
 
-## 核心规则
+## Run Contract
 
-- 只有用户明确要求自动跑、auto loop、goal-like、继续自动 run、批量任务队列时才启动或恢复；不要把普通实现请求自动升级为 auto-loop。
-- 每次开始、恢复、压缩后继续时，先运行 runner 的 `resume` 或 `next`，不要凭聊天摘要推断下一步。
-- 每完成一个 action，必须用 `record --action <next 返回的 action>` 精确写回结果；runner 会拒绝缺失或不匹配的 action。写回后立即再调用 `next`，直到 `done`、`blocked` 或需要用户决策。
-- run 进入 `blocked` 后不要用 `start --force` 新建 run 来纠正参数；先补齐缺失 route/context，然后用 `retry-blocked` 在同一个 run 内恢复。
-- runner 默认输出是紧凑 JSON，只包含当前 action、队列计数、简短 blocked/pending/completed 列表和最近少量决策摘要；排障时才给 `status` / `resume` / `next` / `record` / `retry-blocked` 加 `--verbose` 读取完整 item、blocked detail 和 decision data。
-- 默认 profile 是 `commit-only`：自动推进到本地 commit，不 push、不发布、不归档。
-- 普通 `trellis-push` 默认 commit + push 不改变 auto-loop 的授权边界；auto-loop 始终只走专用 commit-only 预授权，不得因普通流程文案而推送远端。
-- 多任务只按用户显式给出的任务顺序执行；同一 worktree 不并发。
-- 启动 runner 前先完成 route 准备度判断：已有当前任务 runtime route 决策或个人 `.trellis/.route-prefs.tmp` 时可启动；没有时先进入 `trellis-route` 正常询问 / fallback，写入真实决策后再启动。
-- auto-loop 不默认写 `route_authorization`；只有用户本次明确给出的临时 route 策略，才能通过 `--route-implement` / `--route-check` 传给 runner，且不能当成模型真实执行结果。
-- auto-loop 启动前若 implement 与 check 都缺 route，优先展示 auto-loop 专用的合并选择，不要把 `trellis-route` 的两套完整 fallback 原样贴给用户。仍允许用户回复高级格式 `implement 1, check 1`。
-- 检查深度由 run 级 `--check-depth auto|light|full` 控制，默认 `auto`，与 `--route-check` 独立；历史 run 缺少该字段时按 `full` 兼容。
-- 代码提交必须复用 `trellis-push` 的内部 commit-only 执行能力；auto-loop 自己负责预授权校验和 runner 回写，不要裸 `git commit` / `git push`。
-- `Open Questions` 的确定性状态由 runner 处理：`- [ ]` 阻塞，`- [x]` 不阻塞，无章节或空章节放行。历史无 checkbox 列表只能按 `review_open_questions` action 做语义复核，不能自行跳过 runner 回写。
-- 启动或恢复 validated auto-loop 前先运行 `python3 ./.trellis/scripts/pre_check_state.py clear`，静默清除当前任务的交互式 Check-All 前暂缓偏好。清理返回 miss 或 task mismatch 视为无状态；runtime 损坏只记录诊断，不得阻断 runner，也不得让 runner 读取该偏好。
+- 仅在用户明确要求 auto-loop、自动跑到底、goal-like 或继续既有 run 时使用；普通实现请求不能自动升级。
+- 用户发出启动指令即授权本次 `commit-only` run。prepare 完成后不再确认 manifest，也不逐任务执行 `confirm_brief`。
+- 新 run 先 prepare 全部显式任务，Open Questions 全部收敛后才进入 running。running 中不再询问 route、planning 或普通 Check-All 停止边界。
+- 每个 action 完成后，必须用同名 `record --action ...` 精确回写并立即 `next`。不得根据聊天摘要手改 runtime 或跳步。
+- 本地提交是自动终点。不得 push、merge、release、deploy、finish-work 或 archive；queue item 完成后 Trellis task 仍保持 `in_progress`。
+- 任务顺序只决定稳定调度顺序，不隐含依赖。依赖必须通过 `--depends-on dependent=dependency` 明确传入或由 planning artifacts 明确声明。
+- 任务级失败只阻塞自身及显式依赖项；独立任务继续。fix/recheck 与 planning repair 各最多 3 轮，队列结束后不自动执行第二遍恢复扫描。
+- schema 1 runtime 继续按 runner 返回的旧 action 恢复，包括 outstanding `confirm_brief`；不要把旧 run 改写成 schema 2。
 
-## 启动
-
-用户给了任务列表时，按原顺序传入；用户只说当前任务时，用 `task.py current --source` 的当前任务。
-
-启动前先静默清理交互式暂缓偏好：
+启动或恢复前静默清除交互式 pre-check hold；miss、task mismatch 或损坏诊断不阻断 runner：
 
 ```bash
 python3 ./.trellis/scripts/pre_check_state.py clear
 ```
 
-启动前对当前任务执行 route 准备度检查：
-
-```bash
-python3 .agents/skills/trellis-route/scripts/route_state.py resolve --target implement
-python3 .agents/skills/trellis-route/scripts/route_state.py resolve --target check
-```
-
-如果两个 target 都返回 `status=miss`，优先用 auto-loop 专用合并选择询问用户，避免把两套 route fallback 列表完整贴出：
-
-```text
-auto-loop 需要你先选执行路线，才能启动。
-
-推荐：
-1. 本次全 Inline：implement inline + check-all inline（只影响本次 run）
-2. 本次全 Subagent：implement subagent + check-all subagent（只影响本次 run）
-3. 保存默认全 Inline：写入个人默认，后续自动复用
-4. 保存默认全 Subagent：写入个人默认，后续自动复用
-
-高级：也可以回复 `implement 1, check 2` 分别选择。
-```
-
-映射规则：
+## Start
 
-- `1` → `--route-implement inline --route-check check-all-inline`
-- `2` → `--route-implement subagent --route-check check-all-subagent`
-- `3` → 先用 `trellis-route` helper 分别写入 `implement=inline`、`check=check-all-inline` 且 `--save-pref`，再启动 runner
-- `4` → 先用 `trellis-route` helper 分别写入 `implement=subagent`、`check=check-all-subagent` 且 `--save-pref`，再启动 runner
-
-如果只有一个 target 返回 `status=miss`，再按 `trellis-route` 的对应 target 正常 numbered fallback 询问。不要替用户默认 inline 或 subagent。若用户选择的是本次临时策略，把选择映射为 runner route 参数一起传入，例如 `implement 1, check 1` 对应 `--route-implement inline --route-check check-all-inline`。若用户选择保存默认，则由 `trellis-route` 写入偏好后再启动 runner。
+任务列表必须显式。用户只说当前任务时，先用 `task.py current --source` 解析。启动前为 implement/check 解析可复用 route；已有 session runtime 或 `.trellis/.route-prefs.tmp` 就复用，没有时按 `trellis-route` 询问并写入真实选择。临时选择才传 runner 参数，个人默认由 route helper 自己保存。
 
 ```bash
 python3 ./.trellis/scripts/auto_loop.py start \
   --tasks <task> [<task> ...] \
+  [--depends-on <dependent>=<dependency>] \
   --profile commit-only \
   [--check-depth auto|light|full] \
   [--route-implement inline|subagent] \
   [--route-check check-all-inline|check-all-subagent]
-```
-
-除非用户明确指定 light/full，启动时使用默认 `--check-depth auto`。显式 light 仍必须进入 Check-All，命中 hard-full 时由 Check-All 升级 full；不得把它映射到顶层 `trellis-check`。
-
-多任务队列中，当前任务切换到下一个任务且缺少该任务 route 决策时，回到 `trellis-route` 获取该任务真实选择，再继续 `next` / `record`。个人 `.trellis/.route-prefs.tmp` 会由 `trellis-route` 统一复用并写回 runtime。
-
-启动后立即运行：
-
-```bash
 python3 ./.trellis/scripts/auto_loop.py next
 ```
 
-## 恢复
+默认 check depth 为 `auto`。light/full 只是 Check-All 请求深度，不是 route mode；hard-full 风险仍由 Check-All 升级。
 
-压缩、重开会话、用户说“继续自动跑 / continue auto loop”时：
+用户一次选择全 Inline/Subagent 时可同时映射两个 route：
 
-```bash
-python3 ./.trellis/scripts/pre_check_state.py clear
-python3 ./.trellis/scripts/auto_loop.py resume
-python3 ./.trellis/scripts/auto_loop.py next
-```
+- Inline：`--route-implement inline --route-check check-all-inline`
+- Subagent：`--route-implement subagent --route-check check-all-subagent`
 
-`resume` 默认只输出紧凑状态；`resume_capsule` 不再持久写入 runtime JSON，仅在 `resume --verbose` / `status --verbose` 等诊断输出中动态生成。下一步以 `next` 返回的 JSON 为准。
+runner 在 start 时检查任务存在性、task status、staged/conflict/未完成 Git 集成，并捕获主仓及已初始化子仓的 dirty baseline。全局安全错误不得通过 `--force` 绕过。
 
-## Blocked 后重试
+## Prepare Actions
 
-如果 `next` 或 `status` 显示 run 内有 blocked 队列项，先根据 blocked reason 补齐条件，然后复用同一个 run：
+prepare action 必须先完成并 record，runner 才会继续扫描整个队列。
 
-```bash
-python3 ./.trellis/scripts/auto_loop.py retry-blocked \
-  [--run-id <run-id>] \
-  [--task <task>] \
-  [--check-depth auto|light|full] \
-  [--route-implement inline|subagent] \
-  [--route-check check-all-inline|check-all-subagent]
-python3 ./.trellis/scripts/auto_loop.py next
-```
+| action | 主 agent 行为 | record |
+| --- | --- | --- |
+| `classify_dirty_baseline` | 把每个 `repository::path` 精确归到一个任务的 owned dirty，或归为 protected-retained；不猜测归属 | `record --action classify_dirty_baseline --result ok [--owned-dirty <task>=<repository>::<path>] [--protected-retained <repository>::<path>]` |
+| `resolve_open_questions` | 使用 `trellis-brainstorm` 一次引导人工回答一个问题，并更新对应 planning artifacts；AI 不得代答、删除、改写或勾选 | 全部问题消失后 `record --action resolve_open_questions --result ok` |
+| `review_planning_readiness` | 读取 action 绑定的 artifacts，按 Brainstorm Quality Bar 判断 `ready|repairable|blocking` | `record --action review_planning_readiness --result ok --readiness-verdict ready|repairable --summary "..."`；blocking 用 `--result blocked` |
+| `run_planning_repair` | 仅按现有需求、代码、spec 和仓库证据修复 planning；不得处理 Open Questions 或高风险事项 | `record --action run_planning_repair --result ok --summary "..."` |
+| `refresh_brief` | 使用 `trellis-task-brief` 刷新派生的 `brief.md`，无需再次让用户确认 | `record --action refresh_brief --result ok` |
 
-常见场景：启动时漏传临时 route，导致 `missing-implement-context` / `missing-check-context`。此时不要 `start --force`，直接用 `retry-blocked --route-implement ... --route-check ...` 重置 blocked 项。
+`resolve_open_questions` 是整队列门禁：任一任务仍有 `- [ ]` 或历史裸列表时，run 保持 `awaiting_input`，不得先执行其它任务。`- [x]`、空章节或无章节不阻塞。
 
-## Action 映射
+readiness 的 `repairable` 仅适用于不改变目标、可由仓库证据确定的问题，例如验收不可测试、design/implement 不完整或 context 未整理。达到 3 轮、需要产品选择或越过风险黑名单时返回 blocking。
 
-| runner action | 主 agent 动作 | 成功 record |
-| --- | --- | --- |
-| `review_open_questions` | 结合 PRD 语义判断历史裸列表是已解决、仍阻塞或无法确定 | 已解决：`record --action review_open_questions --result ok --review-verdict resolved --summary "<摘要>"`；仍阻塞/无法确定：使用 `--result blocked --review-verdict blocking|ambiguous` |
-| `review_planning_readiness` | 按 `trellis-brainstorm` Quality Bar 复核验收标准可测试、范围明确、关键决策收敛、仓库问题已研究 | ready：`record --action review_planning_readiness --result ok --readiness-verdict ready --summary "<摘要>"`；仍阻塞/无法确定：使用 `--result blocked --readiness-verdict blocking|ambiguous` |
-| `refresh_brief` | 使用 `trellis-task-brief` 刷新并展示 brief；这一步不代表用户确认 | `record --action refresh_brief --result ok` |
-| `confirm_brief` | 再次展示 action 对应的完整 brief，并等待用户显式确认 | 收到确认后：`record --action confirm_brief --result ok --summary "<确认摘要>"`；未确认时停止，不得 record |
-| `start_task` | 执行返回的 `task.py start ...` 命令 | `record --action start_task --result ok` |
-| `run_implement` | 进入 Phase 2.1，先用 `trellis-route(target=implement)` 决定 inline/subagent，再实现 | `record --action run_implement --result ok --route-mode <mode> --route-source <source>` |
-| `run_check_all` | 进入 Phase 2.2，先用 `trellis-route(target=check)`，按 action 的 requested depth 执行 Check-All | `record --action run_check_all --result ok --route-mode <mode> --route-source <source> --effective-check-depth <light|full> --check-depth-reason "<摘要>"` |
-| `run_fix` | 根据 `last_failure` 修复，复用当前任务 implement route | `record --action run_fix --result ok --route-mode <mode> --route-source <source>` |
-| `run_recheck` | 复用当前任务 check route，按 action 的 requested/minimum depth 重新 Check-All | `record --action run_recheck --result ok --route-mode <mode> --route-source <source> --effective-check-depth <light|full> --check-depth-reason "<摘要>"` |
-| `run_spec_update` | 调用 `trellis-update-spec` 自主返回三态 | `no-op` / `written`：`record --action run_spec_update --result ok` 后立即 `next`；`needs-review`：`record --action run_spec_update --result blocked --failure-type spec-needs-review` |
-| `commit_only` | 校验本 run 的预授权与文件归属，再把 exact files/message 交给 `trellis-push` 内部 commit-only 执行 | auto-loop 执行 `record --action commit_only --result ok --commit <hash>` |
-
-失败时写回：
+## Autonomous Decisions
 
-```bash
-python3 ./.trellis/scripts/auto_loop.py record \
-  --action <action> \
-  --result failed \
-  --failure-type <type> \
-  --summary "<失败摘要>" \
-  [--effective-check-depth light|full] \
-  [--check-depth-reason "<深度原因>"] \
-  --files <file> [<file> ...]
-```
-
-需要用户产品决策或越权时写回 blocked：
+满足任务目标内、仅影响本地代码、可逆且可验证时，AI可自主选择推荐方案。作出选择后必须先记录，再继续修改或 record；会修改 planning/handoff 时，`--file` 必须列出全部目标 artifact：
 
 ```bash
-python3 ./.trellis/scripts/auto_loop.py record \
-  --action <action> \
-  --result blocked \
-  --failure-type <type> \
-  --summary "<阻塞原因>" \
-  [--effective-check-depth light|full] \
-  [--check-depth-reason "<深度原因>"]
+python3 ./.trellis/scripts/auto_loop.py decide \
+  --task <task> \
+  --topic "<主题>" \
+  --option "<候选>" [--option "<候选>" ...] \
+  --choice "<选择>" \
+  --summary "<依据摘要>" \
+  [--evidence "<证据>" ...] \
+  --risk low|medium \
+  --confidence low|medium|high \
+  [--requirement <id> ...] [--file <repository>::<path> ...] \
+  [--verification "<验证摘要>"]
 ```
 
-runner 会按 3 轮 fix/recheck 预算决定继续、跳过当前任务或结束队列。
-
-`review_open_questions` 必须只依据 action 返回的 `questions` 和当前 PRD 判断。runner 会把结果绑定到 action 发出时的 PRD SHA-256；PRD 在复核期间发生变化时，record 会返回 `stale-open-questions-review`，此时重新运行 `next`，不得复用旧判断。`ambiguous` 必须保守阻塞，交由用户或 planning 收敛。
-
-`review_planning_readiness` 必须读取 action 指向的当前 planning artifacts，并按 Brainstorm Gate 的语义质量线复核，不能把文件存在、章节存在或 route context 已 curated 当作 ready。runner 会把结论绑定到 `prd.md`、存在时的 `design.md`/`implement.md` 内容；任一文件变化后旧结论失效。
-
-`refresh_brief` 成功后必须立即 `next`。runner 随后返回 `confirm_brief`，主 agent 要展示当前完整 brief 并停止等待用户；启动 auto-loop、选择 route 或生成 brief 都不构成确认。`confirm_brief` 只在收到明确确认后回写，且确认绑定 planning artifacts 与 brief 内容；任一文件变化后必须重新展示并确认。
+决策写入 runtime 摘要和任务 `decisions.jsonl`，只保存结论与证据，不保存思维链。下一次同任务 action record 会消费该决策：列明的 planning/handoff 变化生成绑定 decision ID 的 manifest revision；其它变化按 `artifact-drift` 阻塞。
 
-`record` 默认只返回当前 item 的 `task`、`item_status`、`current_step`、`commit` 和紧凑 `summary`；只有排查状态漂移时才加 `--verbose` 查看完整 `item`。
+以下事项不得用 `decide`，必须 blocked：
 
-route action 成功回写时必须带上 `trellis-route` 输出里的真实 `mode` / `source`，例如
-`--route-mode inline --route-source route-prefs` 或
-`--route-mode check-all-subagent --route-source trellis-route`；不要写 auto-loop 默认值。
+- 不可逆真实数据修改。
+- 扩大权限或降低安全、隐私保护。
+- 公开 API 或数据格式破坏性变更。
+- 费用、生产环境或外部系统影响。
+- push、merge、release、deploy、finish-work、archive。
+- 明显改变任务目标或业务规则且仓库没有倾向证据。
+- `Open Questions` 中人工保留的任何选择。
 
-`run_check_all` / `run_recheck` 无论结果为 ok、failed 还是 blocked，都必须回写 Check-All 实际产生的 effective depth 和原因。更新后的 runner 会保存 `item.last_check`；旧调用缺字段时只能按 `full / legacy-default-full` 记录，不能推断为 light。recheck action 的 `minimum_check_depth=full` 时不得降级。
+## Running Actions
 
-检查 action 完成后，validated auto-loop 不适用普通 Post-Check Stop Gate：inline Check-All 直接执行匹配 action 的 `record` 并立即 `next`；subagent 只返回 audit-only 报告和 `check_profile`，主会话收到后立即完成同样的 `record + next`。只有 runner action mismatch、真正产品决策、越权、生产副作用或破坏性安全边界才停止等待用户。
-
-## Commit-Only 预授权
-
-auto-loop 的 `commit-only` profile 是用户对“当前 run 内任务相关本地提交”的一次性预授权。预授权判断和 runner 状态写回全部由本 skill 负责，不能下放给 `trellis-push`。
-
-收到 `commit_only` action 后，按顺序执行：
+| action | 主 agent 行为 | 成功 record |
+| --- | --- | --- |
+| `start_task` | 执行 action 返回的 `task.py start ...` | `record --action start_task --result ok` |
+| `run_implement` | 进入 Phase 2.1，复用 manifest/当前任务 implement route | `record --action run_implement --result ok --route-mode <mode> --route-source <source>` |
+| `run_check_all` | 进入 Phase 2.2，按 requested depth 执行统一 Check-All | `record --action run_check_all --result ok --route-mode <mode> --route-source <source> --effective-check-depth light|full --check-depth-reason "..."` |
+| `run_fix` | 根据 `last_failure` 修复并复用 implement route | `record --action run_fix --result ok --route-mode <mode> --route-source <source>` |
+| `run_recheck` | 复用 check route，且不得低于 `minimum_check_depth` | 同 `run_check_all`，action 改为 `run_recheck` |
+| `run_spec_update` | 执行 `trellis-update-spec` | `no-op|written` 用 ok；`needs-review` 用 blocked + `spec-needs-review` |
+| `commit_only` | 复用 `trellis-push` 内部精确本地提交能力，不 push | `record --action commit_only --result ok --commit <hash> --files <exact...> --commit-message "..."` |
 
-1. 读取 `auto_loop.py status`，确认 `run_status=running`、profile 为 `commit-only`，且 `outstanding_action.action/task` 与本次 action 和活动任务一致。
-2. 读取当前任务 artifacts、`git status`、`git diff` 和必要文件内容，由 AI 生成 exact files、commit message 与逐文件归属理由。
-3. 确认 staged 区为空、没有冲突或未完成的 Git 集成状态，所有 planned files 均属于当前任务，且不包含 `.trellis/.runtime/`、`.trellis/.route-prefs.tmp`、其他任务目录或未解释文件。
-4. 调用 `trellis-push` 内部 commit-only，只传 exact files 与 message。该调用只执行精确本地提交，不读取 auto-loop 状态、不 push、不写任务进度。
-5. 提交成功后，本 skill 执行：
+失败或越权时必须回写，runner 决定重试、blocked 或继续队列：
 
 ```bash
 python3 ./.trellis/scripts/auto_loop.py record \
-  --action commit_only \
-  --result ok \
-  --commit <hash> \
-  --files <exact files> \
-  --commit-message "<message>"
+  --action <action> --result failed|blocked \
+  --failure-type <type> --summary "<摘要>" \
+  [--files <repository>::<path> ...]
+python3 ./.trellis/scripts/auto_loop.py next
 ```
 
-6. `record` 成功后立即再次调用 `next`。
+Check-All 的 ok/failed/blocked 都要带实际 effective depth 与原因。validated auto-loop 不进入普通 Post-Check Stop Gate；检查完成后立即 `record + next`。
+
+## Commit-Only
 
-如果预检或内部提交失败，由本 skill 使用匹配的 action 写回 `failed` 或 `blocked`，并保留未识别 dirty 文件。不要用时间差或 dirty baseline 猜测文件归属。普通 dirty 文件不自动纳入提交；未识别 staged 文件、冲突、远端推送、上线/归档动作、真实外部系统或生产数据效果都必须阻止本次 commit-only。
+收到 `commit_only` 后：
 
-`trellis-push` 在这个路径中只是精确提交执行器，不得自行调用 `status`、`record` 或决定队列项是 blocked/skipped。当前 item 失败后的继续、跳过或停止仍由 runner 的既有预算和 `next` 结果决定。
+1. 用 `status` 确认 active run、profile、outstanding action 和 task 一致。
+2. 读取任务 artifacts、Git status/diff，生成 exact files、message 和归属理由。
+3. staged 必须为空；不得包含冲突、未完成集成、runtime、route prefs、其它任务目录或 protected-retained。
+4. 使用 `trellis-push` 内部 commit-only 提交 exact files。不得裸 `git add .`、`git add -A`、push 或按时间差猜归属。
+5. 用提交 hash 和 exact files record，然后立即 next。
 
-## 状态与停止
+`decisions.jsonl` 属于当前任务文件，发生决策时应进入该任务最终精确提交。任务 `task.json.status` 不因 queue item completed 而改写。
 
-查看：
+## Resume, Retry, Stop
 
 ```bash
-python3 ./.trellis/scripts/auto_loop.py status
-```
+python3 ./.trellis/scripts/auto_loop.py resume
+python3 ./.trellis/scripts/auto_loop.py next
 
-停止：
+python3 ./.trellis/scripts/auto_loop.py retry-blocked \
+  [--run-id <run-id>] [--task <task>] [--all] \
+  [--check-depth auto|light|full]
+python3 ./.trellis/scripts/auto_loop.py next
 
-```bash
+python3 ./.trellis/scripts/auto_loop.py status [--verbose]
 python3 ./.trellis/scripts/auto_loop.py stop --reason "<原因>"
 ```
 
-## 不要做
+默认使用紧凑输出；只有诊断 manifest、dirty、漂移、依赖链或决策详情时加 `--verbose`。`completed_with_blocked` 已是本次 run 的可审计终态，后续恢复由用户显式调用 `retry-blocked`。
+
+## 禁止事项
 
-- 不要手写或手改 `.trellis/.runtime/auto-loop/*.json`。
-- 不要把 `.trellis/.runtime/` 或 `.trellis/.route-prefs.tmp` 加入提交。
-- 不要在 auto-loop 外把普通 check 的 post-check stop gate 当成可跳过。
-- 不要为模糊需求自动创建任务并开跑；先回到 Trellis planning。
+- 不手写 `.trellis/.runtime/auto-loop/*.json`，不提交 runtime 或 `.route-prefs.tmp`。
+- 不覆盖、暂存或提交 protected-retained 文件；发生路径冲突只阻塞涉及任务。
+- 不用 `start --force` 代替 `retry-blocked`。
+- 不把 queue item completed 解释为任务已归档。
+- 不在无人值守执行中替用户回答 Open Questions。

package/enhancements/0.6/.agents/skills/trellis-check-all/SKILL.md

@@ -322,12 +322,17 @@ interactive 模式完成所有可继续检查后，严格按以下顺序输出
 修复后：定向验证 -> Check-All 重检
 
 操作：`修复全部`、`修复 CHK-001,CHK-003`、`仅保留报告`
+
+### 下一步
+
+<按下方 `Interactive Post-Check Stop Gate` 输出一个明确、可执行的主动作>
 ```
 
 展示规则：
 
 - 没有问题时省略“问题清单”“修复批次”和操作行，只报告通过结果、验证和剩余风险。
 - 有问题时只在报告末尾提供一次修复范围选择，不再逐项提问。
+- interactive 标准报告必须以“下一步”段结束；停止等待不等于省略引导，不得只列出风险或写“等待用户选择”。
 - 独立问题不得因数量多而静默省略；先合并同根因重复项，再完整列出剩余问题。
 - 报告不得包含 commit message、拟提交/暂存文件、commit-only 决策或提交确认。
 - light 通过正式满足 Phase 2.2 检查门禁；未执行维度必须标记 `N/A`，不得伪装为已验证。
@@ -359,10 +364,14 @@ interactive 模式完成所有可继续检查后，严格按以下顺序输出
 
 - <问题或风险；没有时写“无”>
 
-结论：<重检结论与下一步>
+结论：<重检结论>
+
+### 下一步
+
+<按下方 `Interactive Post-Check Stop Gate` 输出一个明确、可执行的主动作>
 ```
 
-检查通过后才指向 Phase 3.3 `trellis-update-spec`，再到 Phase 3.4 `trellis-push`。仍有问题时停留在修复/重检循环。
+检查通过后的动作由下方 `Interactive Post-Check Stop Gate` 判断：普通交互停止等待，符合 direct Git 严格通过条件时同轮进入 Phase 3.3 `trellis-update-spec`，再到 Phase 3.4 `trellis-push`。仍有问题时停留在修复/重检循环。
 
 ---
 
@@ -374,21 +383,42 @@ validated auto-loop 复用相同的 audit-only 检查、画像和问题模型，
 - 真正需要用户产品决策、越权、生产副作用或破坏性安全决策：使用同样深度字段 `record --result blocked`，随后按 runner 状态停止。
 - 无问题：`record --result ok --effective-check-depth <light|full> --check-depth-reason <summary>`，随后立即 `next`。
 - subagent 只返回结构化报告和 `check_profile`；主会话收到后必须立即完成匹配 action 的 `record + next`，不得先套用 interactive 停止边界。
+- validated auto-loop 不渲染交互式下一步段、不提示用户回复“继续”、不等待普通修复范围选择；匹配 action 的 `record + next` 就是唯一后续动作。
 - 不修改 runner 的 fix/recheck 预算、commit-only 授权或队列行为。
 
 ---
 
 ## Interactive Post-Check Stop Gate
 
-非 validated auto-loop 的检查报告输出后立即停止并等待用户选择。允许输出的内容只有：
+非 validated auto-loop 先输出上述完整标准报告，再在本 Gate 内按以下顺序分流：
+
+1. 只从触发本轮完成链的最新用户消息识别 direct Git intent：明确请求普通 push，或用户主动 `commit-only`。不得从历史消息、任务标题、摘要、dirty 状态或 auto-loop 内部 action 推断。
+2. direct Git 只有在 Check-All 整体结论通过、问题数为 0、无阻塞、无部分验证、无待用户接受的实质剩余风险时才算严格通过。标准报告输出后，同一轮进入 Phase 3.3 `trellis-update-spec`；`no-op|written` 再由其加载 `trellis-push`，`needs-review` 停止。
+3. findings、blocked、部分验证或实质剩余风险均不满足条件：输出标准报告并停止，不运行 Update-Spec，也不生成 Git 计划。原始 Git 请求不授权自动修复、忽略问题或扩大 Git 权限。
+4. 没有匹配 direct Git intent 的普通 interactive 检查保持原行为：报告后立即停止并等待用户选择。
+
+### 交互式下一步引导
+
+本节只适用于非 validated auto-loop；Auto-Loop Return Gate 已经先行完成 `record + next`。
+
+所有 interactive 标准报告都必须在末尾输出 `### 下一步`，并按以下首个命中分支给出一个明确主动作：
+
+1. 有 findings：提示用户回复 `修复全部`、精确问题 ID 或 `仅保留报告`；不得重复提出逐项确认。
+2. 有 blocked、部分验证或实质剩余风险：指出解除阻塞所需的精确决策、授权或验证，以及完成后重新运行 Check-All；涉及生产、外部系统或破坏性副作用时只引导用户授权，不自行执行。
+3. direct Git 严格通过：说明本轮正在进入 `trellis-update-spec`，不要求用户再次回复“继续”或确认 Git 计划。
+4. 无 direct Git intent 且严格通过：提示用户回复 `继续`，下一轮进入 `trellis-update-spec`，再由 `trellis-push` 生成提交计划。
+
+停止边界只控制是否自动推进，不能让报告在没有下一步提示的情况下结束。
+
+允许 Check-All 标准报告输出的内容只有：
 
 - 各维度状态、问题数和问题清单；
 - 已执行验证及结果；
 - 未覆盖验证和剩余风险；
 - 总体结论；
-- 有问题时的一次修复范围选择，或通过时的 Phase 3.3 / Phase 3.4 下一步指向。
+- 与当前结论匹配的唯一主动作引导；有问题时是一次修复范围选择，部分验证/阻塞时是补充决策或验证，通过时是 Phase 3.3 / Phase 3.4 指向。
 
-禁止在本轮生成提交计划、commit message、拟提交文件或要求用户确认提交。
+Check-All 不新增 direct Git 专用摘要，也不得自行生成提交计划、commit message、拟提交文件或要求用户确认提交；strict pass 后的 Git 计划仍由 Update-Spec disposition 和 `trellis-push` owner 生成。
 
 ---
 

package/enhancements/0.6/.agents/skills/trellis-push/SKILL.md

@@ -30,11 +30,12 @@ description: "按确认的精确文件范围提交普通变更或完成已就绪
 
 ## Step 0：交互式完成链门禁
 
-除 auto-loop 内部 `commit-only` 外，任何普通 push 或用户 `commit-only` 在读取 Git 提交计划前，都必须确认当前工作内容已经通过 Check-All，且该结论之后存在当前有效的 `spec_update_result`：
+除 auto-loop 内部 `commit-only` 外，任何普通 push 或用户 `commit-only` 在读取 Git 提交计划前，按以下顺序验证交互式完成链：
 
-- `status=no-op|written`：继续本 skill 的 Git 预检与计划。
-- 缺失，或实际 diff、Check-All 结论、用户 spec 意图已变化：先加载 `trellis-update-spec`，只有新的 `no-op|written` 才能回到本 skill。
-- `status=needs-review`：停止，不生成提交计划。
+1. 当前工作内容缺少有效 Check-All，或实际 diff、检查范围/结论已变化：返回 Phase 2.2。唯一例外是当前有效 `spec_update_result.status=written` 的 `changed_files`，且这些受控写入全部位于 `.trellis/spec/**`；该 Update-Spec 自校验结果不触发额外 Check-All。当前 direct Git 请求只作为“严格通过后继续”的条件意图；Check-All 有 findings、blocked、部分验证或实质剩余风险时停止。此分支不得运行 Update-Spec，也不得读取 Git 计划。
+2. Check-All 有效后检查当前有效的 `spec_update_result`。结果缺失，或除上述受控 spec 写入外的实际 diff、Check-All 结论、用户 spec 意图已变化时，先加载 `trellis-update-spec`；只有新的 `no-op|written` 才能回到本 skill。
+3. `status=no-op|written`：继续本 skill 的 Git 预检与计划。
+4. `status=needs-review`：停止，不生成提交计划。
 
 用户直接说 push/提交不构成跳过 Phase 3.3 的授权。auto-loop 内部 `commit-only` 已由 runner 的 `run_spec_update -> commit_only` 状态机和预授权保证顺序，因此不得重复进入本门禁。