flower-trellis 0.5.2-beta.0 → 0.5.2

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

@@ -13,6 +13,7 @@ description: "启动、恢复和推进 Trellis 自动任务循环。用于用户
 - 用户发出启动指令即授权本次 `commit-only` run。prepare 完成后不再确认 manifest，也不逐任务执行 `confirm_brief`。
 - 新 run 先 prepare 全部显式任务，Open Questions 全部收敛后才进入 running。running 中不再询问 route、planning 或普通 Check-All 停止边界。
 - 每个 action 完成后，必须用同名 `record --action ...` 精确回写并立即 `next`。不得根据聊天摘要手改 runtime 或跳步。
+- `record` 返回 `status=retryable` 时保留的是同一个 outstanding Check action：不得运行 `next`，必须先按返回指令消解漂移并重录。
 - 本地提交是自动终点。不得 push、merge、release、deploy、finish-work 或 archive；queue item 完成后 Trellis task 仍保持 `in_progress`。
 - 任务顺序只决定稳定调度顺序，不隐含依赖。依赖必须通过 `--depends-on dependent=dependency` 明确传入或由 planning artifacts 明确声明。
 - 任务级失败只阻塞自身及显式依赖项；独立任务继续。fix/recheck 与 planning repair 各最多 3 轮，队列结束后不自动执行第二遍恢复扫描。
@@ -82,7 +83,7 @@ python3 ./.trellis/scripts/auto_loop.py decide \
   [--verification "<验证摘要>"]
 ```
 
-决策写入 runtime 摘要和任务 `decisions.jsonl`，只保存结论与证据，不保存思维链。下一次同任务 action record 会消费该决策：列明的 planning/handoff 变化生成绑定 decision ID 的 manifest revision；其它变化按 `artifact-drift` 阻塞。
+决策写入 runtime 摘要和任务 `decisions.jsonl`，只保存结论与证据，不保存思维链。下一次同任务 action record 会消费该决策：列明的 planning/handoff 变化生成绑定 decision ID 的 manifest revision；Check record 中其它变化进入有限自纠，其它 action 仍按 `artifact-drift` 阻塞。
 
 以下事项不得用 `decide`，必须 blocked：
 
@@ -100,7 +101,7 @@ python3 ./.trellis/scripts/auto_loop.py decide \
 | --- | --- | --- |
 | `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_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 "..." [--doc-remediation-file <repository>::<path> ...]` |
 | `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` |
@@ -118,6 +119,17 @@ python3 ./.trellis/scripts/auto_loop.py next
 
 Check-All 的 ok/failed/blocked 都要带实际 effective depth 与原因。validated auto-loop 不进入普通 Post-Check Stop Gate；检查完成后立即 `record + next`。
 
+Check-All 自动修复当前任务 `implement.md` 或 `brief.md` 时，每个实际变化文件都要用重复的 `--doc-remediation-file` 精确声明；声明集合必须与 action 发出后的真实变化完全一致。`prd.md`、`design.md`、其它任务和其它仓库文件不得使用该参数。
+
+若 Check record 返回 `status=retryable reason=artifact-drift`：
+
+1. 不运行 `next`，保留 runner 返回的 outstanding action。
+2. 若是本 action 的误改，撤回误改后用原 action 重录。
+3. 若是合法 `implement.md` / `brief.md` DOC 修复，补齐精确 `--doc-remediation-file` 后重录。
+4. 若无法安全归因，使用原 action、`--result blocked --failure-type artifact-drift` 重录并停止。
+
+同一 Check action 最多允许 3 次 retryable 自纠，第 4 次进入 terminal blocked。实现、spec update、commit-only 等其它 action 的 artifact drift 不使用该预算。
+
 ## Commit-Only
 
 收到 `commit_only` 后：
@@ -145,12 +157,13 @@ 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`。
+默认使用紧凑输出；只有诊断 manifest、dirty、漂移、依赖链或决策详情时加 `--verbose`。`retryable` 不是终态，由 agent 在同一 outstanding Check action 内立即自纠；`completed_with_blocked` 才是本次 run 的可审计终态，后续恢复由用户显式调用 `retry-blocked`。
 
 ## 禁止事项
 
 - 不手写 `.trellis/.runtime/auto-loop/*.json`，不提交 runtime 或 `.route-prefs.tmp`。
 - 不覆盖、暂存或提交 protected-retained 文件；发生路径冲突只阻塞涉及任务。
 - 不用 `start --force` 代替 `retry-blocked`。
+- `record` 返回 `retryable` 后不得调用 `next` 或重新发起 action。
 - 不把 queue item completed 解释为任务已归档。
 - 不在无人值守执行中替用户回答 Open Questions。

package/enhancements/0.6/.agents/skills/trellis-check-all/references/document-drift-auto-remediation.md

@@ -65,6 +65,13 @@
 
 subagent 模式只返回 `DOC-*` 候选；主会话按同一规则决定是否写入。validated auto-loop 模式由主会话完成允许的 `DOC-*` 修复后再 `record`。
 
+### Validated Auto-Loop 绑定
+
+- 只有当前任务的 `implement.md` 与 `brief.md` 参与 runner DOC 重绑；每个实际修改文件使用一次 `--doc-remediation-file <repository>::<path>`。
+- 声明集合必须与 Check action 发出后的真实变化完全一致。`prd.md`、`design.md`、其它任务或其它文件一律不允许借此重绑。
+- `check.jsonl` 可按本通道记录，但它不属于 planning/handoff hash，不传 `--doc-remediation-file`。
+- record 返回 `status=retryable reason=artifact-drift` 时不运行 `next`；先撤回误改、补齐合法 DOC 声明后重录，或在无法安全归因时显式回写 `blocked + artifact-drift`。
+
 ---
 
 ## 失败处理

package/enhancements/0.6/.agents/skills/trellis-check-all/references/reporting-and-disposition.md

@@ -131,11 +131,11 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 
 validated auto-loop 复用相同的画像、profile、`DOC-*` 通道和问题模型，但不展示普通模式的修复选择：
 
-- 有 `DOC-*` 且可自动修复：主会话先应用并验证，再决定最终 `ok|failed|blocked`。
+- 有 `DOC-*` 且可自动修复：主会话先应用并验证；当前任务 `implement.md` / `brief.md` 的每个实际变化都追加精确 `--doc-remediation-file`，再决定最终 `ok|failed|blocked`。
 - 有剩余 `CHK-*`：向 runner `record --result failed --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含最高严重度、问题 ID、根因、受影响文件和已自动修复的 `DOC-*`。
 - 真正需要用户产品决策、越权、生产副作用或破坏性安全决策：使用同样深度字段 `record --result blocked`，随后按 runner 状态停止。
 - 无剩余问题：`record --result ok --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含自动修复数量。
-- 记录后立即 `next`；validated auto-loop 不渲染交互式下一步段、不提示用户回复“继续”、不等待普通修复范围选择。
+- record 成功后立即 `next`；若返回 `status=retryable reason=artifact-drift`，不得 `next`，先按 runner 指令在同一 outstanding action 内自纠并重录。validated auto-loop 不渲染交互式下一步段、不提示用户回复“继续”、不等待普通修复范围选择。
 - 不修改 runner 的 fix/recheck 预算、commit-only 授权或队列行为。
 
 subagent 只返回结构化报告、`DOC-*` 候选和 `check_profile`；主会话收到后必须完成允许的 `DOC-*` 处理，再完成匹配 action 的 `record + next`。

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

@@ -28,16 +28,16 @@ description: "按确认的精确文件范围提交普通变更或完成已就绪
 
 内部 `commit-only` 不接受临时扩大文件范围、远端推送或其他附加动作。安全条件不满足时返回失败，由调用方决定后续状态。
 
-## Step 0：交互式完成链门禁
+## Step 0：记录完成链证据
 
-除 auto-loop 内部 `commit-only` 外，任何普通 push 或用户 `commit-only` 在读取 Git 提交计划前，按以下顺序验证交互式完成链：
+除 auto-loop 内部 `commit-only` 外，普通 push 或用户 `commit-only` 已经构成明确 Git 意图。本 skill 在读取 Git 提交计划前只记录当前可用的完成链证据，不补跑、不切换阶段，也不新增确认：
 
-1. 当前工作内容缺少有效 Check-All，或实际 diff、检查范围/结论已变化：先向用户给出两个选项：`运行 check-all`（推荐）或 `跳过检查并继续 push`。用户选择运行时返回 Phase 2.2；用户明确选择跳过检查时，记录“用户已接受跳过 Check-All 风险”，直接继续本 skill 的 Git 预检与计划。唯一例外是当前有效 `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`：停止，不生成提交计划。
+- Check-All：根据当前标准报告与实际 diff 标记为 `通过`、`未运行`、`已失效`、`存在 findings`、`blocked` 或 `部分验证`。没有可验证的当前报告时使用 `未运行`，不得从历史消息、摘要或 dirty 状态猜测通过。
+- Update-Spec：根据当前 `spec_update_result` 与实际 diff 标记为 `no-op`、`written`、`needs-review`、`未运行` 或 `已失效`。结果缺失或无法证明仍适用于当前 diff 时使用 `未运行` / `已失效`。
 
-用户直接说 push/提交不构成跳过 Phase 3.3 的授权。auto-loop 内部 `commit-only` 已由 runner 的 `run_spec_update -> commit_only` 状态机和预授权保证顺序，因此不得重复进入本门禁。
+上述状态只进入 Step 3 的完成链证据与风险展示，不会阻止读取 Git 状态或生成提交计划。本步骤不得返回 Phase 2.2，不得加载 `trellis-check-all` 或 `trellis-update-spec`，也不得要求用户改写成“跳过检查后 push”。正常 workflow 的 Check-All -> Update-Spec -> Push 顺序仍由 Phase 2.2、Phase 3.3 和各自 owner 推进；`trellis-push` 不反向补做上游阶段。
+
+auto-loop 内部 `commit-only` 已由 runner 的 `run_check_all -> run_spec_update -> commit_only` 状态机和预授权保证顺序，因此不重复记录或判断本交互证据。
 
 ## Step 1：发现仓库与任务
 
@@ -119,6 +119,10 @@ git log @{u}..HEAD --oneline 2>/dev/null || true
 [无活动任务时追加：无活动任务]
 顺序：<repo-a> [-> `<local generation command>`] -> <repo-b> [-> task progress]
 
+### 完成链证据
+- Check-All：<通过 / 未运行 / 已失效 / 存在 findings / blocked / 部分验证>
+- Update-Spec：<no-op / written / needs-review / 未运行 / 已失效>
+
 ### 1. <repository-name>
 
 `<commit message>`
@@ -139,7 +143,7 @@ Push：<执行 / 跳过（commit-only）>
 - [staged] <path>
 
 ### 风险（仅数量大于 0 时显示）
-- <unknown ahead / branch-upstream / attribution risk>
+- <Check-All / Update-Spec 风险，或 unknown ahead / branch-upstream / attribution risk>
 
 [任务记录（仅普通模式且存在活动任务时显示）：`chore(task): update <task-name> progress` · <N> 个文件]
 [仓库：<repository-name> · 分支：`<branch>` -> `<upstream>`]
@@ -156,8 +160,9 @@ Push：<执行 / 跳过（commit-only）>
 - 超过 8 个时按目录归组，最多 12 行；用户要求展开时展示同一 exact set。
 - 顶部仓库/commit/file 总数包含独立任务记录提交所在 Git root、该提交及其 exact files；任务记录文件使用相同的 8 文件展示阈值和展开规则。
 - 保留未提交的变更始终逐项标注 Git 状态；真正风险在独立“风险”区逐项展示。
+- 完成链证据始终显示当前状态，但不重复 Check-All 报告或 Spec review 正文；`未运行`、`已失效`、findings、blocked、部分验证或 `needs-review` 同时计入风险区。
 - 无活动任务或 `commit-only` 时省略进度动作。
-- 不重复展示检查结果、规范复核、归档或其他阶段信息。
+- 不重复展示检查结果、规范复核、归档或其他阶段的详细信息。
 - 生成前无法确定的内容和增删行写“生成后计算”，不得填预测值。
 
 普通多仓只确认一次。计划已展示生成命令和预计 exact files 时，命令成功且没有出现预计列表外的新 dirty path 就沿用原确认；内容、hash 或统计变化不重问。其它计划边界变化仍按 Step 4 重新规划。

package/enhancements/0.6/.agents/skills/trellis-task-brief/SKILL.md

@@ -14,7 +14,9 @@ description: "从最新 prd.md、design.md、implement.md 生成、刷新、校
 - `brief.md` 必须以三件套为准覆盖旧内容；无法从三件套追溯的旧内容不能保留为事实。
 - 不要在 `brief.md` 里发明三件套没有表达的新需求。缺失字段写“未明确”，并提示应补充三件套。
 - 写回 `brief.md` 后，必须在当前对话中展示 brief 正文；不要只给文件路径。
-- Phase 1.4 前展示完整 brief，并等待用户确认 planning artifacts 和 brief 后，才运行 `task.py start`。
+- Phase 1.4 前必须展示完整 brief。默认等待用户确认后再运行 `task.py start`；只有用户明确把当前任务或最终 Brief 与“展示后直接开始 / 不用再次确认 / 视为已确认”绑定时，才可在范围未变化的前提下免除第二次确认。
+- “开始做吧”“按你建议来”“可以创建任务”等普通实现或建任务意图不是 Brief 预授权，不能据此跳过确认。
+- 预授权只依赖当前对话中仍然明确可见的用户表达，不建立跨会话永久偏好，也不写 session runtime。
 - `in_progress` 阶段发现缺失 brief 时，不自动生成未经 review 的 brief；先读取三件套并建议回补。只有用户明确要求当场回补并 review 时，才继续写回 `brief.md`。
 - 不要机械限制 brief 或对话展示长度；信息完整优先，不能截掉会影响实现判断的范围、约束、风险或验收条件。
 
@@ -29,15 +31,21 @@ description: "从最新 prd.md、design.md、implement.md 生成、刷新、校
 3. 读取任务文件：
    - 必读：`prd.md`。
    - 存在则读：`design.md`、`implement.md`。
-4. 从最新三件套提取：
+4. 判断当前对话是否存在有效预授权：
+   - 必须由用户明确指向当前任务或最终 Brief，并明确表示展示后直接开始、不用再次确认或视为已确认。
+   - 普通实现意图、任务创建授权、旧任务确认或无法确定指向的表达均按“无预授权”处理。
+   - 若最终内容扩大范围、仍有未解决 Open Questions，或新增权限、安全、隐私、生产、费用、真实数据、破坏性公开契约、外部系统边界，则预授权失效。
+5. 从最新三件套提取：
    - `Goal`：任务目标一句话。
    - `Scope`：本轮实现范围。
    - `Non-Goals`：明确不做的范围。
    - `Key Context`：关键文件、模块、入口、约束或风险。
    - `Acceptance`：主要验收标准。
    - `Next Step`：进入实现后的下一步。
-5. 写回 `<task>/brief.md`。如果文件已存在，仍用最新三件套派生内容覆盖旧正文。
-6. 在对话中展示 brief 正文，并说明来源文件。
+6. 写回 `<task>/brief.md`。如果文件已存在，仍用最新三件套派生内容覆盖旧正文。
+7. 在对话中展示 brief 正文，并说明来源文件：
+   - 无有效预授权：展示后结束当前回合，等待用户确认。
+   - 有有效预授权：先完整展示，再在同一回合返回主 workflow 执行 `task.py start`，不得省略展示步骤。
 
 ## 模板
 
@@ -81,6 +89,16 @@ Phase 1.4 review 前：
 请确认 planning artifacts 和上述 brief；确认后才运行 `task.py start <task>`。
 ```
 
+存在有效预授权时：
+
+```markdown
+任务交接摘要已更新：<task>/brief.md
+
+<brief.md 正文>
+
+已按你对当前 Brief 的明确预授权完成复核；范围未扩大、无未解决问题，继续启动任务。
+```
+
 任务已经是 `in_progress` 时，如果 brief 存在，进入 implement route 前重述：
 
 ```markdown
@@ -96,7 +114,9 @@ Phase 1.4 review 前：
 
 ## 不要做
 
-- 不要执行 `task.py start`；这仍由主 workflow 在用户确认后执行。
+- 不要在完整展示 brief 之前执行 `task.py start`；启动仍由主 workflow 执行。
+- 不要把普通实现意图解释成免确认授权。
+- 不要把一次预授权扩展为后续任务或其它高风险操作的长期授权。
 - 不要修改三件套来迎合 brief。
 - 不要把 `brief.md` 当作第四件套扩写。
 - 不要只因为 `brief.md` 已存在就跳过更新。

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

@@ -13,6 +13,7 @@ description: "启动、恢复和推进 Trellis 自动任务循环。用于用户
 - 用户发出启动指令即授权本次 `commit-only` run。prepare 完成后不再确认 manifest，也不逐任务执行 `confirm_brief`。
 - 新 run 先 prepare 全部显式任务，Open Questions 全部收敛后才进入 running。running 中不再询问 route、planning 或普通 Check-All 停止边界。
 - 每个 action 完成后，必须用同名 `record --action ...` 精确回写并立即 `next`。不得根据聊天摘要手改 runtime 或跳步。
+- `record` 返回 `status=retryable` 时保留的是同一个 outstanding Check action：不得运行 `next`，必须先按返回指令消解漂移并重录。
 - 本地提交是自动终点。不得 push、merge、release、deploy、finish-work 或 archive；queue item 完成后 Trellis task 仍保持 `in_progress`。
 - 任务顺序只决定稳定调度顺序，不隐含依赖。依赖必须通过 `--depends-on dependent=dependency` 明确传入或由 planning artifacts 明确声明。
 - 任务级失败只阻塞自身及显式依赖项；独立任务继续。fix/recheck 与 planning repair 各最多 3 轮，队列结束后不自动执行第二遍恢复扫描。
@@ -82,7 +83,7 @@ python3 ./.trellis/scripts/auto_loop.py decide \
   [--verification "<验证摘要>"]
 ```
 
-决策写入 runtime 摘要和任务 `decisions.jsonl`，只保存结论与证据，不保存思维链。下一次同任务 action record 会消费该决策：列明的 planning/handoff 变化生成绑定 decision ID 的 manifest revision；其它变化按 `artifact-drift` 阻塞。
+决策写入 runtime 摘要和任务 `decisions.jsonl`，只保存结论与证据，不保存思维链。下一次同任务 action record 会消费该决策：列明的 planning/handoff 变化生成绑定 decision ID 的 manifest revision；Check record 中其它变化进入有限自纠，其它 action 仍按 `artifact-drift` 阻塞。
 
 以下事项不得用 `decide`，必须 blocked：
 
@@ -100,7 +101,7 @@ python3 ./.trellis/scripts/auto_loop.py decide \
 | --- | --- | --- |
 | `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_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 "..." [--doc-remediation-file <repository>::<path> ...]` |
 | `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` |
@@ -118,6 +119,17 @@ python3 ./.trellis/scripts/auto_loop.py next
 
 Check-All 的 ok/failed/blocked 都要带实际 effective depth 与原因。validated auto-loop 不进入普通 Post-Check Stop Gate；检查完成后立即 `record + next`。
 
+Check-All 自动修复当前任务 `implement.md` 或 `brief.md` 时，每个实际变化文件都要用重复的 `--doc-remediation-file` 精确声明；声明集合必须与 action 发出后的真实变化完全一致。`prd.md`、`design.md`、其它任务和其它仓库文件不得使用该参数。
+
+若 Check record 返回 `status=retryable reason=artifact-drift`：
+
+1. 不运行 `next`，保留 runner 返回的 outstanding action。
+2. 若是本 action 的误改，撤回误改后用原 action 重录。
+3. 若是合法 `implement.md` / `brief.md` DOC 修复，补齐精确 `--doc-remediation-file` 后重录。
+4. 若无法安全归因，使用原 action、`--result blocked --failure-type artifact-drift` 重录并停止。
+
+同一 Check action 最多允许 3 次 retryable 自纠，第 4 次进入 terminal blocked。实现、spec update、commit-only 等其它 action 的 artifact drift 不使用该预算。
+
 ## Commit-Only
 
 收到 `commit_only` 后：
@@ -145,12 +157,13 @@ 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`。
+默认使用紧凑输出；只有诊断 manifest、dirty、漂移、依赖链或决策详情时加 `--verbose`。`retryable` 不是终态，由 agent 在同一 outstanding Check action 内立即自纠；`completed_with_blocked` 才是本次 run 的可审计终态，后续恢复由用户显式调用 `retry-blocked`。
 
 ## 禁止事项
 
 - 不手写 `.trellis/.runtime/auto-loop/*.json`，不提交 runtime 或 `.route-prefs.tmp`。
 - 不覆盖、暂存或提交 protected-retained 文件；发生路径冲突只阻塞涉及任务。
 - 不用 `start --force` 代替 `retry-blocked`。
+- `record` 返回 `retryable` 后不得调用 `next` 或重新发起 action。
 - 不把 queue item completed 解释为任务已归档。
 - 不在无人值守执行中替用户回答 Open Questions。

package/enhancements/0.6/.claude/skills/trellis-check-all/references/document-drift-auto-remediation.md

@@ -65,6 +65,13 @@
 
 subagent 模式只返回 `DOC-*` 候选；主会话按同一规则决定是否写入。validated auto-loop 模式由主会话完成允许的 `DOC-*` 修复后再 `record`。
 
+### Validated Auto-Loop 绑定
+
+- 只有当前任务的 `implement.md` 与 `brief.md` 参与 runner DOC 重绑；每个实际修改文件使用一次 `--doc-remediation-file <repository>::<path>`。
+- 声明集合必须与 Check action 发出后的真实变化完全一致。`prd.md`、`design.md`、其它任务或其它文件一律不允许借此重绑。
+- `check.jsonl` 可按本通道记录，但它不属于 planning/handoff hash，不传 `--doc-remediation-file`。
+- record 返回 `status=retryable reason=artifact-drift` 时不运行 `next`；先撤回误改、补齐合法 DOC 声明后重录，或在无法安全归因时显式回写 `blocked + artifact-drift`。
+
 ---
 
 ## 失败处理

package/enhancements/0.6/.claude/skills/trellis-check-all/references/reporting-and-disposition.md

@@ -131,11 +131,11 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 
 validated auto-loop 复用相同的画像、profile、`DOC-*` 通道和问题模型，但不展示普通模式的修复选择：
 
-- 有 `DOC-*` 且可自动修复：主会话先应用并验证，再决定最终 `ok|failed|blocked`。
+- 有 `DOC-*` 且可自动修复：主会话先应用并验证；当前任务 `implement.md` / `brief.md` 的每个实际变化都追加精确 `--doc-remediation-file`，再决定最终 `ok|failed|blocked`。
 - 有剩余 `CHK-*`：向 runner `record --result failed --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含最高严重度、问题 ID、根因、受影响文件和已自动修复的 `DOC-*`。
 - 真正需要用户产品决策、越权、生产副作用或破坏性安全决策：使用同样深度字段 `record --result blocked`，随后按 runner 状态停止。
 - 无剩余问题：`record --result ok --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含自动修复数量。
-- 记录后立即 `next`；validated auto-loop 不渲染交互式下一步段、不提示用户回复“继续”、不等待普通修复范围选择。
+- record 成功后立即 `next`；若返回 `status=retryable reason=artifact-drift`，不得 `next`，先按 runner 指令在同一 outstanding action 内自纠并重录。validated auto-loop 不渲染交互式下一步段、不提示用户回复“继续”、不等待普通修复范围选择。
 - 不修改 runner 的 fix/recheck 预算、commit-only 授权或队列行为。
 
 subagent 只返回结构化报告、`DOC-*` 候选和 `check_profile`；主会话收到后必须完成允许的 `DOC-*` 处理，再完成匹配 action 的 `record + next`。

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

@@ -28,16 +28,16 @@ description: "按确认的精确文件范围提交普通变更或完成已就绪
 
 内部 `commit-only` 不接受临时扩大文件范围、远端推送或其他附加动作。安全条件不满足时返回失败，由调用方决定后续状态。
 
-## Step 0：交互式完成链门禁
+## Step 0：记录完成链证据
 
-除 auto-loop 内部 `commit-only` 外，任何普通 push 或用户 `commit-only` 在读取 Git 提交计划前，按以下顺序验证交互式完成链：
+除 auto-loop 内部 `commit-only` 外，普通 push 或用户 `commit-only` 已经构成明确 Git 意图。本 skill 在读取 Git 提交计划前只记录当前可用的完成链证据，不补跑、不切换阶段，也不新增确认：
 
-1. 当前工作内容缺少有效 Check-All，或实际 diff、检查范围/结论已变化：先向用户给出两个选项：`运行 check-all`（推荐）或 `跳过检查并继续 push`。用户选择运行时返回 Phase 2.2；用户明确选择跳过检查时，记录“用户已接受跳过 Check-All 风险”，直接继续本 skill 的 Git 预检与计划。唯一例外是当前有效 `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`：停止，不生成提交计划。
+- Check-All：根据当前标准报告与实际 diff 标记为 `通过`、`未运行`、`已失效`、`存在 findings`、`blocked` 或 `部分验证`。没有可验证的当前报告时使用 `未运行`，不得从历史消息、摘要或 dirty 状态猜测通过。
+- Update-Spec：根据当前 `spec_update_result` 与实际 diff 标记为 `no-op`、`written`、`needs-review`、`未运行` 或 `已失效`。结果缺失或无法证明仍适用于当前 diff 时使用 `未运行` / `已失效`。
 
-用户直接说 push/提交不构成跳过 Phase 3.3 的授权。auto-loop 内部 `commit-only` 已由 runner 的 `run_spec_update -> commit_only` 状态机和预授权保证顺序，因此不得重复进入本门禁。
+上述状态只进入 Step 3 的完成链证据与风险展示，不会阻止读取 Git 状态或生成提交计划。本步骤不得返回 Phase 2.2，不得加载 `trellis-check-all` 或 `trellis-update-spec`，也不得要求用户改写成“跳过检查后 push”。正常 workflow 的 Check-All -> Update-Spec -> Push 顺序仍由 Phase 2.2、Phase 3.3 和各自 owner 推进；`trellis-push` 不反向补做上游阶段。
+
+auto-loop 内部 `commit-only` 已由 runner 的 `run_check_all -> run_spec_update -> commit_only` 状态机和预授权保证顺序，因此不重复记录或判断本交互证据。
 
 ## Step 1：发现仓库与任务
 
@@ -119,6 +119,10 @@ git log @{u}..HEAD --oneline 2>/dev/null || true
 [无活动任务时追加：无活动任务]
 顺序：<repo-a> [-> `<local generation command>`] -> <repo-b> [-> task progress]
 
+### 完成链证据
+- Check-All：<通过 / 未运行 / 已失效 / 存在 findings / blocked / 部分验证>
+- Update-Spec：<no-op / written / needs-review / 未运行 / 已失效>
+
 ### 1. <repository-name>
 
 `<commit message>`
@@ -139,7 +143,7 @@ Push：<执行 / 跳过（commit-only）>
 - [staged] <path>
 
 ### 风险（仅数量大于 0 时显示）
-- <unknown ahead / branch-upstream / attribution risk>
+- <Check-All / Update-Spec 风险，或 unknown ahead / branch-upstream / attribution risk>
 
 [任务记录（仅普通模式且存在活动任务时显示）：`chore(task): update <task-name> progress` · <N> 个文件]
 [仓库：<repository-name> · 分支：`<branch>` -> `<upstream>`]
@@ -156,8 +160,9 @@ Push：<执行 / 跳过（commit-only）>
 - 超过 8 个时按目录归组，最多 12 行；用户要求展开时展示同一 exact set。
 - 顶部仓库/commit/file 总数包含独立任务记录提交所在 Git root、该提交及其 exact files；任务记录文件使用相同的 8 文件展示阈值和展开规则。
 - 保留未提交的变更始终逐项标注 Git 状态；真正风险在独立“风险”区逐项展示。
+- 完成链证据始终显示当前状态，但不重复 Check-All 报告或 Spec review 正文；`未运行`、`已失效`、findings、blocked、部分验证或 `needs-review` 同时计入风险区。
 - 无活动任务或 `commit-only` 时省略进度动作。
-- 不重复展示检查结果、规范复核、归档或其他阶段信息。
+- 不重复展示检查结果、规范复核、归档或其他阶段的详细信息。
 - 生成前无法确定的内容和增删行写“生成后计算”，不得填预测值。
 
 普通多仓只确认一次。计划已展示生成命令和预计 exact files 时，命令成功且没有出现预计列表外的新 dirty path 就沿用原确认；内容、hash 或统计变化不重问。其它计划边界变化仍按 Step 4 重新规划。

package/enhancements/0.6/.claude/skills/trellis-task-brief/SKILL.md

@@ -14,7 +14,9 @@ description: "从最新 prd.md、design.md、implement.md 生成、刷新、校
 - `brief.md` 必须以三件套为准覆盖旧内容；无法从三件套追溯的旧内容不能保留为事实。
 - 不要在 `brief.md` 里发明三件套没有表达的新需求。缺失字段写“未明确”，并提示应补充三件套。
 - 写回 `brief.md` 后，必须在当前对话中展示 brief 正文；不要只给文件路径。
-- Phase 1.4 前展示完整 brief，并等待用户确认 planning artifacts 和 brief 后，才运行 `task.py start`。
+- Phase 1.4 前必须展示完整 brief。默认等待用户确认后再运行 `task.py start`；只有用户明确把当前任务或最终 Brief 与“展示后直接开始 / 不用再次确认 / 视为已确认”绑定时，才可在范围未变化的前提下免除第二次确认。
+- “开始做吧”“按你建议来”“可以创建任务”等普通实现或建任务意图不是 Brief 预授权，不能据此跳过确认。
+- 预授权只依赖当前对话中仍然明确可见的用户表达，不建立跨会话永久偏好，也不写 session runtime。
 - `in_progress` 阶段发现缺失 brief 时，不自动生成未经 review 的 brief；先读取三件套并建议回补。只有用户明确要求当场回补并 review 时，才继续写回 `brief.md`。
 - 不要机械限制 brief 或对话展示长度；信息完整优先，不能截掉会影响实现判断的范围、约束、风险或验收条件。
 
@@ -29,15 +31,21 @@ description: "从最新 prd.md、design.md、implement.md 生成、刷新、校
 3. 读取任务文件：
    - 必读：`prd.md`。
    - 存在则读：`design.md`、`implement.md`。
-4. 从最新三件套提取：
+4. 判断当前对话是否存在有效预授权：
+   - 必须由用户明确指向当前任务或最终 Brief，并明确表示展示后直接开始、不用再次确认或视为已确认。
+   - 普通实现意图、任务创建授权、旧任务确认或无法确定指向的表达均按“无预授权”处理。
+   - 若最终内容扩大范围、仍有未解决 Open Questions，或新增权限、安全、隐私、生产、费用、真实数据、破坏性公开契约、外部系统边界，则预授权失效。
+5. 从最新三件套提取：
    - `Goal`：任务目标一句话。
    - `Scope`：本轮实现范围。
    - `Non-Goals`：明确不做的范围。
    - `Key Context`：关键文件、模块、入口、约束或风险。
    - `Acceptance`：主要验收标准。
    - `Next Step`：进入实现后的下一步。
-5. 写回 `<task>/brief.md`。如果文件已存在，仍用最新三件套派生内容覆盖旧正文。
-6. 在对话中展示 brief 正文，并说明来源文件。
+6. 写回 `<task>/brief.md`。如果文件已存在，仍用最新三件套派生内容覆盖旧正文。
+7. 在对话中展示 brief 正文，并说明来源文件：
+   - 无有效预授权：展示后结束当前回合，等待用户确认。
+   - 有有效预授权：先完整展示，再在同一回合返回主 workflow 执行 `task.py start`，不得省略展示步骤。
 
 ## 模板
 
@@ -81,6 +89,16 @@ Phase 1.4 review 前：
 请确认 planning artifacts 和上述 brief；确认后才运行 `task.py start <task>`。
 ```
 
+存在有效预授权时：
+
+```markdown
+任务交接摘要已更新：<task>/brief.md
+
+<brief.md 正文>
+
+已按你对当前 Brief 的明确预授权完成复核；范围未扩大、无未解决问题，继续启动任务。
+```
+
 任务已经是 `in_progress` 时，如果 brief 存在，进入 implement route 前重述：
 
 ```markdown
@@ -96,7 +114,9 @@ Phase 1.4 review 前：
 
 ## 不要做
 
-- 不要执行 `task.py start`；这仍由主 workflow 在用户确认后执行。
+- 不要在完整展示 brief 之前执行 `task.py start`；启动仍由主 workflow 执行。
+- 不要把普通实现意图解释成免确认授权。
+- 不要把一次预授权扩展为后续任务或其它高风险操作的长期授权。
 - 不要修改三件套来迎合 brief。
 - 不要把 `brief.md` 当作第四件套扩写。
 - 不要只因为 `brief.md` 已存在就跳过更新。

package/enhancements/0.6/overrides/bundles/control-plane-integrity.json

@@ -5,6 +5,7 @@
   "installMode": "full-only",
   "patches": [
     "scripts/task-store-write-integrity",
-    "scripts/runtime-state-integrity"
+    "scripts/runtime-state-integrity",
+    "scripts/session-context-update-boundary"
   ]
 }

package/enhancements/0.6/overrides/bundles/trellis-meta.json

@@ -0,0 +1,12 @@
+{
+  "schemaVersion": 1,
+  "id": "trellis-meta",
+  "aliases": ["meta-architecture", "trellis-create-command", "create-command"],
+  "installMode": "full-or-selected",
+  "patches": [
+    "skills/trellis-meta/managed-mode-precedence",
+    "skills/trellis-meta/managed-architecture-and-ownership",
+    "skills/trellis-meta/managed-customization-routing",
+    "skills/trellis-meta/managed-workflow-owners"
+  ]
+}