flower-trellis 0.6.8-beta.0 → 0.6.8-beta.2

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

@@ -12,8 +12,8 @@ description: "启动、恢复和推进 Trellis 自动任务循环。用于用户
 - 仅在用户明确要求 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 或跳步。
-- `record` 返回 `status=retryable` 时保留的是同一个 outstanding Check action：不得运行 `next`，必须先按返回指令消解漂移并重录。
+- 每个 action 完成后，必须用同名 `record --action ...` 精确回写；record 成功后立即 `next`。不得根据聊天摘要手改 runtime 或跳步。
+- `record` 返回 `status=retryable` 时不得运行 `next`，必须按返回指令在同一个 outstanding action 内纠正并重录；恢复诊断的 owner 见下方 Action 内恢复。
 - 本地提交是自动终点。不得 push、merge、release、deploy、finish-work 或 archive；runner 在 item 本地提交成功后把该任务写入本地完成态（`status=completed` + `completedAt`），归档仍需用户显式执行。
 - 任务顺序只决定稳定调度顺序，不隐含依赖。依赖必须通过 `--depends-on dependent=dependency` 明确传入或由 planning artifacts 明确声明。
 - 任务级失败只阻塞自身及显式依赖项；独立任务继续。fix/recheck、planning repair 与安全的 commit-only repair 各最多 3 轮，队列结束后不自动执行第二遍恢复扫描。
@@ -67,7 +67,7 @@ readiness 的 `repairable` 仅适用于不改变目标、可由仓库证据确
 
 ## Autonomous Decisions
 
-满足任务目标内、仅影响本地代码、可逆且可验证时，AI可自主选择推荐方案。作出选择后必须先记录，再继续修改或 record；会修改 planning/handoff 时，`--file` 必须列出全部目标 artifact：
+满足任务目标内、仅影响本地代码、可逆且可验证时，AI可自主选择推荐方案。作出选择后必须先记录，再继续修改或 record；会修改 planning/handoff 时，`--task-file` 或完整 `--file` 必须列出全部目标 artifact：
 
 ```bash
 python3 ./.trellis/scripts/auto_loop.py decide \
@@ -79,11 +79,11 @@ python3 ./.trellis/scripts/auto_loop.py decide \
   [--evidence "<证据>" ...] \
   --risk low|medium \
   --confidence low|medium|high \
-  [--requirement <id> ...] [--file <repository>::<path> ...] \
+  [--requirement <id> ...] [--task-file <name> ...] [--file <repository>::<path> ...] \
   [--verification "<验证摘要>"]
 ```
 
-决策写入 runtime 摘要和任务 `decisions.jsonl`，只保存结论与证据，不保存思维链。下一次同任务 action record 会消费该决策：列明的 planning/handoff 变化生成绑定 decision ID 的 manifest revision；Check record 中其它变化进入有限自纠，其它 action 仍按 `artifact-drift` 阻塞。
+决策写入 runtime 摘要和任务 `decisions.jsonl`，只保存结论与证据，不保存思维链。下一次同任务 action record 会消费该决策：列明的 planning/handoff 变化生成绑定 decision ID 的 manifest revision；Check record 中其它变化进入有限自纠，其它 action 的确定路径错误先进入恢复诊断，未知或越界漂移仍按 `artifact-drift` 阻塞。
 
 以下事项不得用 `decide`，必须 blocked：
 
@@ -95,6 +95,10 @@ python3 ./.trellis/scripts/auto_loop.py decide \
 - 明显改变任务目标或业务规则且仓库没有倾向证据。
 - `Open Questions` 中人工保留的任何选择。
 
+## Action 内恢复
+
+`next` 保留原 action 和文档基线，不消费 pending。收到 `artifact-recovery-required` 或 `artifact-recovery-failed` 时，必须读取 [恢复协议](references/artifact-recovery.md)，同轮完成诊断、纠正、`reconcile` 校验并继续原 action。初次诊断不计数，最多三次实际纠正，第三次仍可成功；不要求用户回复“继续”。
+
 ## Running Actions
 
 | action | 主 agent 行为 | 成功 record |
@@ -161,7 +165,7 @@ python3 ./.trellis/scripts/auto_loop.py status [--verbose]
 python3 ./.trellis/scripts/auto_loop.py stop --reason "<原因>"
 ```
 
-默认使用紧凑输出；只有诊断 manifest、dirty、漂移、依赖链或决策详情时加 `--verbose`。`retryable` 不是终态，由 agent 在同一 outstanding Check action 内立即自纠；`completed_with_blocked` 才是本次 run 的可审计终态，后续恢复由用户显式调用 `retry-blocked`。
+默认使用紧凑输出；只有诊断 manifest、dirty、漂移、依赖链或决策详情时加 `--verbose`。`retryable` 不是终态，由 agent 按对应通道在同一 outstanding action 内立即自纠；`completed_with_blocked` 才是本次 run 的可审计终态，后续恢复由用户显式调用 `retry-blocked`。
 
 ## Run 收尾交接
 

package/enhancements/0.6/.agents/skills/trellis-auto-loop/references/artifact-recovery.md

@@ -0,0 +1,38 @@
+# Action 内恢复与三轮纠正
+
+收到 `status=retryable reason=artifact-recovery-required|artifact-recovery-failed` 时读取本文件，并在同轮执行纠正。它是原 action 的恢复通道，不是新的业务 action，也不要求用户回复“继续”。
+
+## 登记与恢复
+
+- 当前任务四文档优先用 `decide --task-file prd.md|design.md|implement.md|brief.md`，可重复。普通 `--file` 仍是仓库相对路径或 `<repository>::<path>`，可登记尚未创建的代码文件；裸文档名不自动解释为任务路径。
+- 无效路径被拒绝时不会写入 decision/pending/manifest；有可信原 action 的确定 basename 错误会返回恢复诊断。根同名文件、未知仓库、越界、软链或 protected 冲突不能猜测修正。
+- `next` 重放同一 outstanding action、issued_at、深度和原文档基线。正确 pending 覆盖的修改可以恢复执行，但只能由后续真实 `record` 消费 pending 和重绑 manifest。
+- 原 Check 只有 implement/brief 的待申报 DOC 变化时，恢复后仍按 Check 的 DOC 资格与精确文件申报规则回写；不能把恢复查询视为接受内容。
+
+## Agent 纠正步骤
+
+1. 读取诊断的 `recovery_id`、`source`、原 action、原 decision ID、`baseline`、`candidates`、`changed` 和 `attempts`，结合原 `decisions.jsonl`、任务 artifacts、真实 diff 和执行证据核实归属。文件集合吻合不能代替需求和语义审查。
+2. 对已证明的 basename 错登记，提交诊断中的精确一对一映射。旧 pending 的纠正只追加普通决策审计并改文件键，保留原 choice、requirements、risk 与修改前 baseline。初始 decide 被拒绝时，纠正成功后必须重新调用原 decide，登记成功才编辑。
+3. 存在额外误改时，先保全新增记录，仅撤回能证明由本 action 造成的误改，再提交校验。runner 不覆盖文件；不得恢复用户、外部会话或来源不明的修改。
+4. 无法安全归因、原语义不足、涉及 Open Questions、需求扩张或风险黑名单时提交 `blocked`。
+
+```bash
+python3 ./.trellis/scripts/auto_loop.py reconcile \
+  --run-id <run> --task <task> \
+  --recovery-id <诊断ID> --attempt-id <本次唯一ID> \
+  --result ok|failed|blocked --summary "<纠正结论>" \
+  [--evidence "<已读取的证据>" ...] \
+  [--file-map '<旧唯一键>=<当前任务同名文档唯一键>' ...]
+```
+
+runner 会重读文件并验证映射、基线和 protected 边界，不能仅凭 `--result ok` 放行。`reconciled` 后按返回指令在同轮继续原 action 或重试原 decide，提交原 action 的真实结果；纠正不能代表 Check 通过、实现完成或提交成功。非 Check record 若返回恢复诊断，也必须先纠正，再重新提交原真实 record，不能直接 next 跳过。
+
+## 预算与重复恢复
+
+初次发现为 0 次；next/status/resume、压缩恢复和同尝试同载荷重放不计数。前三次以明确提交的实际纠正计数：前两次失败继续同轮纠正，第三次可成功，第三次失败才终态 blocked。更换诊断或错误路径不能重置同一 action 的预算。
+
+同一个 attempt-id 仅用于重放完全相同的请求；载荷变化用新 ID。回执丢失后重放原请求，日志已写但 runtime 未写也不会重复追加决策。观察值变化会拒绝沿用旧回执，按 runner 指令重新诊断；不手写 runtime 或删审计来“修复”状态。
+
+既有 Check `status=retryable reason=artifact-drift` 继续由原 Check 重录通道负责：不调用 next/reconcile 获取第二套预算，保留原 3 次 retryable 后第 4 次 blocked 的规则。next 已建立的恢复诊断先完成，再允许原 record；一个错误只走一个通道。fix/recheck、commit repair 和部分成功提交仍由原 owner 管理。
+
+恢复期 run/item 仍 running，依赖项不会提前失败。未知漂移、无可信基线、受保护内容变化或预算耗尽仍按原阻塞和依赖传播规则处理；独立任务继续。历史终态 run 不自动复活，仍需用户显式 retry-blocked。

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

@@ -30,7 +30,7 @@ description: "统一 Check-All：按 requested/effective depth 路由 light/full
 1. **默认 audit-only collect-all**：可读取、搜索和运行无业务写入的验证；普通代码、配置、测试和任务规格语义不得直接修复。
 2. **唯一自修例外**：低风险事实漂移进入 `DOC-*` 通道，按 `references/document-drift-auto-remediation.md` 的白名单、黑名单和写入时机处理。
 3. **分类先于严重度**：读取 `references/fallback-findings.md`；主路径错误和非兜底契约违背进入 `CHK-*`，fail-closed、异常输入、失败降级和防御性保护缺口进入 `FBK-*`。契约证据影响严重度，不改变兜底根因归属。
-4. **处置只确认一次**：统一报告后选择 `CHK-*` / `FBK-*` 修复范围或接受风险；`修复全部` 覆盖两类，接受风险不得隐藏发现。
+4. **处置只确认一次**：统一报告后选择 `CHK-*` / `FBK-*` 修复范围或接受风险；`修复全部` 覆盖两类。接受后按 reporting reference 简短确认，保留发现记录，不重复展开未变化的已接受问题。
 5. **共享验证**：两个 profile 共用 `references/verification.md`；同一追踪与有效验证证据跨维度复用，检查保持只读。
 6. **真正阻塞才中途暂停**：业务规划冲突、前提失效，或当前结论必需验证涉及未授权生产/外部/破坏性副作用时暂停；发布后验收只记 `[上线后验证]`，不执行、不阻断。
 
@@ -85,7 +85,7 @@ untracked helper 只存游标：findings 或新编辑回 `implement`；通过且
 
 ### Step 4：统一报告与分流
 
-读取 `references/reporting-and-disposition.md`，按其完整模板与分流规则在对话中输出报告；默认不新建报告文件，落盘例外由该 reference 定义。
+读取 `references/reporting-and-disposition.md`，按其首次报告、接受后增量展示与分流规则输出；默认不新建报告文件，落盘例外由该 reference 定义。
 
 ---
 

package/enhancements/0.6/.agents/skills/trellis-check-all/references/fallback-findings.md

@@ -69,7 +69,7 @@
 - `CHK-*` 与 `FBK-*` 独立编号，修复/重检循环保留原 ID；两类都按实际影响分配 P0/P1/P2。
 - `修复全部` 覆盖两类问题；精确修复可混合 ID，例如 `修复 CHK-001,FBK-002`。
 - 用户可以明确接受当前报告中任一 `CHK-*` 或 `FBK-*` 的风险而不修复；问题仍保留原通道、严重度和证据。
-- 接受当前报告全部风险覆盖全部 `CHK-*` / `FBK-*`，包括 P0，无固定句式；部分接受须唯一定位。报告或范围不清才追问；证据、diff、内容或严重度变化后失效。
+- 接受当前报告全部风险覆盖全部 `CHK-*` / `FBK-*`，包括 P0，无固定句式；部分接受须唯一定位。报告或范围不清才追问；接受有效性与增量展示统一按 `reporting-and-disposition.md`，不因无关 diff 变化失效。
 - `strict pass` 仍要求剩余 `CHK-*` 与 `FBK-*` 均为 0；全部剩余问题被有效接受且无阻塞、部分验证或其它实质风险时，使用“已接受风险通过”。
 - 未处置 `CHK-*` / `FBK-*`、阻断型部分验证或阻塞会阻断；`[上线后验证]` 不阻断。auto-loop 不得接受风险，须两类问题为 0 且无阻断型部分验证才能 `record ok`。
 - `仅保留报告` 只停止修复，不构成风险接受或通过。

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

@@ -26,15 +26,10 @@
 
 ### `FBK-*` 兜底问题
 
-每个满足硬准入的独立兜底根因使用固定字段。`ID`、`严重度`、`来源`、`处置`、`标题` 内联在条目的四级标题行，其余字段以加粗标签的列表项逐行展开：
+满足硬准入的兜底根因沿用上方标题行字段与呈现规则；ID 独立从 `FBK-001` 递增，其余字段如下：
 
 | 字段 | 呈现 | 规则 |
 | --- | --- | --- |
-| ID | 标题行 | 首次记录时依次分配 `FBK-001`、`FBK-002`；当前修复/重检循环中不重新编号 |
-| 严重度 | 标题行 | 与 `CHK-*` 使用同一 P0/P1/P2 影响尺度 |
-| 来源 | 标题行 | prd/design/implement/spec/assumption/verification |
-| 处置 | 标题行 | 仅 `已接受风险` 时在标题行末尾追加 `` `[已接受风险]` `` 标签；待处理是默认状态，不加标签也不占行 |
-| 标题 | 标题行 | 描述具体保护路径根因，不写泛化“增强健壮性” |
 | 证据 | 加粗字段 | 保护缺失、错误或可绕过的全部受影响 `file:line`，以及实际契约或命令结果；承载硬准入的「具体位置」与「问题证据」，不再单列「位置」 |
 | 兜底场景 | 加粗字段 | 可达的异常、失败、越权、数据损害或诊断盲区场景；承载硬准入的「可达场景」 |
 | 影响 | 加粗字段 | 当前缺口的用户、数据、安全或工程影响 |
@@ -42,9 +37,9 @@
 | 建议 | 加粗字段 | 推荐修复方式，不在检查阶段执行 |
 | 验证 | 加粗字段 | 修复后的测试、故障注入、命令或手动验证步骤；受环境限制时按验证阶段标记阻断型 `部分验证` 或 `[上线后验证]` |
 
-`FBK-*` 分类只看具体位置、可达场景和问题证据；环境不足保留 ID。保护收益与验证方式仍为报告字段。
+`FBK-*` 分类和环境不足处理沿用 fallback reference；保护收益与验证方式仍为报告字段。
 
-`CHK-*` 与 `FBK-*` 分开编号，同根因位置合并。严重度排序只在各自通道内部生效，每个通道内部按 `P0 -> P1 -> P2` 展示且不重排 ID。跨通道报告顺序固定为完整 `CHK-*` 区块在前、完整 `FBK-*` 区块在后；禁止因 FBK 严重度更高、分类时先判断 FBK、发现先后或 ID 分配时机而 FBK-first 或交错。新根因递增编号。默认待处理无标签；仅 `已接受风险` 在标题末尾加 `` `[已接受风险]` ``。`仅保留报告` 不改变处置，处置不改变 ID、通道或严重度。
+`CHK-*` 与 `FBK-*` 分开编号，同根因位置合并。严重度排序只在各自通道内部生效，每个通道内部按 `P0 -> P1 -> P2` 展示且不重排 ID。跨通道报告顺序固定为完整 `CHK-*` 区块在前、完整 `FBK-*` 区块在后；禁止因 FBK 严重度更高、分类时先判断 FBK、发现先后或 ID 分配时机而 FBK-first 或交错。新根因递增编号。处置不改变 ID、通道或严重度。
 
 ## 风险接受
 
@@ -52,12 +47,20 @@
 
 1. 只有用户可以接受风险；主会话、subagent 和 validated auto-loop 都不得代替用户推断或授权。
 2. 按当前报告和语义解析：“接受当前报告全部风险”“全部接受”“这些风险都接受”等覆盖全部 `CHK-*` / `FBK-*`，包括 P0，无固定句式或逐项 ID。部分接受须唯一定位子集；报告版本或范围不清时才追问。
-3. 接受只绑定当前问题证据与实际 diff。受影响代码、契约、验证结果、问题内容或严重度变化后，原接受立即失效，问题恢复为待处理并移除标题行末尾的 `` `[已接受风险]` `` 标签。
-4. 已接受问题继续完整展示证据、影响、建议和验证，标题行末尾追加 `` `[已接受风险]` `` 标签；不得删除条目、改列 `DOC-*` 或伪报已修复。
+3. 接受绑定该问题的证据与相关 diff。代码、契约或验证变化后，先核对是否实质改变该问题的证据、触发条件、影响或严重度；改变时仅该问题的原接受失效，恢复为待处理并说明变化。无关文件改动、行号移动或不改变问题语义的报告整理不使接受失效。无法确认关联证据仍有效时明确缺口，不推断继续有效。
+4. 原报告与接受记录保留完整问题、原通道、严重度和证据；不得删除条目、改列 `DOC-*` 或伪报已修复。对话展示按下方“接受后的增量展示”执行；需要展开已接受条目时，标题行末尾追加 `` `[已接受风险]` `` 标签。
 5. `strict pass` 只用于剩余 `CHK-*` / `FBK-*` 均为 0。所有剩余问题均已被有效接受，且无 blocked、无阻断型部分验证、无未接受的实质剩余风险时，结论为 `通过·已接受风险`。
 6. blocked、阻断型部分验证和无法唯一对应当前报告范围的实质剩余风险不是 `CHK-*` / `FBK-*` 处置状态，不能借风险接受绕过；`[上线后验证]` 不属于风险接受对象。
 7. `仅保留报告` 表示停止处置并等待，不等于接受风险，也不授权写文件；只有带明确接受语义的用户回复才改变问题处置状态。
 
+### 接受后的增量展示
+
+- 首次报告完整展示全部问题。若只改变处置状态，简短确认本次接受的 ID、更新后的结论和必要的下一步；不重贴报告、维度表、问题字段或原风险说明，也不因此重跑检查。部分接受时补充剩余待处置 ID，不误报通过。
+- 后续重检完整展示新增、实质变化、接受失效及仍待处置的问题；未变化且接受仍有效的问题只汇总数量，计入报告总数与接受数，不重复字段。无须展开的通道省略问题区块。
+- 恢复会话、验证进展和 Update-Spec 内部沿用有效接受记录，不主动复述；Push 按其输出 reference 汇总。用户要求详情时再展开指定问题的原报告与当前处置。
+- 原报告或接受依据无法恢复时，说明缺口并针对受影响项目补核，不凭摘要伪报通过或要求全部重接受。复用现有对话或任务记录，不新增展示次数、状态文件或报告附件。
+- 单纯接受只更新处置；已有当前完成链推进意图时沿用。“接受并继续”等明确表达在通过门禁后同轮进入 Update-Spec，无需再回复“继续”；仍有未处置问题或阻塞时说明剩余项并停止。继续不替代 Push 的精确计划确认。
+
 ## 验证阶段
 
 - `部分验证`：当前结论必需、提交前可完成但证据不足；阻断 strict pass、Update-Spec 和 direct Git。
@@ -68,16 +71,16 @@
 
 ## 输出：统一检查报告
 
-报告默认在对话中完整展示，不得为了缩短回复、提供链接、留存结论或同步任务状态新建 `check-report.md` 等附件，也不得用附件链接代替应展示的内容。
+按“接受后的增量展示”在对话中报告。不得为缩短回复、留存结论或同步任务状态新建 `check-report.md` 等附件或用链接代替应展示内容。
 
-仅用户明确要求导出或已确认的交付约定要求文件时，由主会话保存，不得自行补写约定。Maven、auto-loop 沿用各自机器证据契约，不额外生成 Markdown。已有报告不自动删除或复制。
+仅用户明确导出或已确认交付约定要求时由主会话保存。Maven、auto-loop 沿用机器证据契约，不额外生成 Markdown；已有报告不自动删除或复制。
 
 interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动、行为影响和结论，再展示证据与问题：
 
 - 依据当前审查范围的最终 diff 和已读实现，覆盖 staged、unstaged、未跟踪文件及必要的子仓；复用检查时收集的材料，不额外启动 Diff Brief 流程或重复扫描。
 - 按行为说明改前后的差异，只有证据支持时才描述旧行为；无行为变化时说明文档、测试或生成物调整，不罗列文件。
 - 区分已实现、已验证和仍未解决的内容；计划中的功能不得写成已经交付，未归属本次范围的 dirty 不得混入。阻塞或重大问题在开头说明，不能被改动介绍掩盖。
-- 自然段不另设固定字段或空项，按复杂度展开。重检只解释本轮修复及其影响。随后保留完整问题、风险和下一步。
+- 自然段不另设固定字段或空项，按复杂度展开。重检只解释本轮修复及其影响。随后按增量展示规则保留应展开的问题、风险和下一步。
 
 ```markdown
 ## Trellis Check-All 结果
@@ -116,14 +119,6 @@ interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动
 - **建议**：<修复建议>
 - **验证**：<验证命令或步骤>
 
-#### `CHK-002` `P2` `<来源>` <标题> `[已接受风险]`
-
-- **证据**
-  - `<file:line>` — <契约、实际值或命令结果>
-- **影响**：<影响>
-- **建议**：<修复建议>
-- **验证**：<验证命令或步骤>
-
 ### 兜底问题
 
 #### `FBK-001` `P1` `<来源>` <标题>
@@ -145,8 +140,6 @@ interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动
 - **批次 1**：<CHK/FBK 问题 ID> · <修复目标>
 - **修复后**：定向验证 -> Check-All 重检
 
-操作：`修复全部`、`修复 CHK-001,FBK-002`、`接受当前报告全部风险并继续`、`接受风险 CHK-001,FBK-002 并继续`、`仅保留报告`
-
 ### 下一步
 
 <按下方 `Interactive Post-Check Stop Gate` 输出一个明确、可执行的主动作>
@@ -154,20 +147,19 @@ interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动
 
 展示规则：
 
-- strict pass 且无剩余问题时可紧凑表述，保留模板顺序、画像、维度、实际验证、DOC（如有）、风险和下一步，省略空区块；不得缩减实际检查范围。有问题或已接受风险时完整展示问题字段与处置。
+- strict pass 或仅剩未变化的有效已接受问题时可紧凑表述，保留模板顺序、画像、维度、实际验证、DOC（如有）、风险和下一步，省略空区块；不得缩减实际检查范围。应展开的问题完整展示字段与处置；仅更新接受状态时使用简短确认，不套用本模板。
 - 报告头部“工作/范围/画像/结论”和“修复批次”必须使用 `- ` 列表项，不得改为裸行或依赖行尾空格。
-- 每个问题必须由一个四级标题承载，固定顺序为 `` #### `<ID>` `<严重度>` `<来源>` <标题> ``。仅 `已接受风险` 的问题在标题末尾追加 `` `[已接受风险]` ``；待处理不加标签。`来源` 与 `处置` 都不再单独占行。
-- 不得改用 `- [ ]` / `- [x]` 列表项承载问题条目。终端渲染器会把松散列表压平，相邻条目会糊成一段无法分辨；只有标题这类块级元素才能稳定产生视觉分隔。修复状态由“修复结果”表格表达，不靠 checkbox。
-- 条目内部的字段一律写成 `- **<字段>**：<值>` 加粗标签列表项。字段值折行后回到左边界，加粗标签是唯一能定位字段起点的锚，裸标签会淹没在正文里。
-- 每个问题的受影响位置合并进 `证据`，不再单列「位置」行。`证据` 写成不带值的 `- **证据**` 后接子项列表，一个受影响 `file:line` 一条子项，不得用 `；` 把多个位置堆进一行，也不得只写概括性描述。
+- 展开项使用 `` #### `<ID>` `<严重度>` `<来源>` <标题> ``；仅已接受项追加 `` `[已接受风险]` ``，来源与处置不另占行。
+- 禁止用 `- [ ]` / `- [x]` 承载问题：终端会压平松散列表，四级标题能稳定分隔。修复状态用“修复结果”表格表达。
+- 字段使用 `- **<字段>**：<值>` 加粗列表标签，避免折行后难以定位。
+- 位置并入 `证据`：`- **证据**` 后接子列表，全部受影响 `file:line` 逐项列出，不用 `；` 堆叠或仅写概述。
 - 没有 `DOC-*` 自动修复时省略“自动修复”区。
-- 没有 `CHK-*` 时省略“主路径问题”区；没有 `FBK-*` 时省略“兜底问题”区。
-- 同时存在两类问题时，`### 主路径问题` 及其全部 `CHK-*` 必须完整出现在 `### 兜底问题` 及其全部 `FBK-*` 之前；不得按全局严重度排序反转或交错两个区块。
-- 存在未处置 `CHK-*` 或 `FBK-*` 时展示“修复批次”，并只在报告末尾提供一次处置选择，不再逐项提问。
+- 本轮无须展开的通道省略问题区。
+- 展开顺序遵循上方通道规则，不得按全局严重度排序反转或交错两个区块。
+- 存在未处置 `CHK-*` 或 `FBK-*` 时，“修复批次”只说明分组与验证安排，处置选择统一在报告末尾“下一步”中提供一次，不再逐项提问。
 - `修复全部` 始终覆盖全部 `CHK-*` 与 `FBK-*`；精确修复可以混合两类 ID。
-- 风险接受可混合两类 ID；“接受当前报告全部风险”覆盖全部剩余问题，包括 P0，无固定句式。全部有效接受后才形成“通过·已接受风险”。
 - interactive 标准报告必须以“下一步”段结束；停止等待不等于省略引导。
-- 独立 `CHK-*` 或 `FBK-*` 不得因数量多而静默省略；先合并同根因重复项，再完整列出剩余项。
+- 独立 `CHK-*` 或 `FBK-*` 不得因数量多而静默省略；合并同根因后列全应展开项，已接受项按增量规则汇总。
 - 报告不得包含 commit message、拟提交/暂存文件、commit-only 决策或提交确认。
 - light 通过正式满足 Phase 2.2 检查门禁；未执行维度必须标记 `N/A`，不得伪装为已验证。
 
@@ -200,7 +192,7 @@ interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动
 
 ### 未修复与风险
 
-- <问题或风险；没有时写“无”>
+- <待处置、新增或变化的问题及风险；未变化的有效已接受问题只汇总数量；没有时写“无”>
 
 结论：<重检结论>
 
@@ -224,7 +216,7 @@ validated auto-loop 复用相同的画像、profile、`DOC-*` 通道和问题模
 - 产品决策、越权、提交前生产副作用授权或破坏性决策：`record --result blocked`。
 - 无 `CHK-*` / `FBK-*` 和阻断型部分验证：`record --result ok --effective-check-depth <light|full> --check-depth-reason <summary>`；摘要包含自动修复和全部 `[上线后验证]`，后者不阻断且不得代执行。
 - record 成功后立即 `next`；若返回 `status=retryable reason=artifact-drift`，不得 `next`，先按 runner 指令在同一 outstanding action 内自纠并重录。validated auto-loop 不渲染交互式下一步段、不提示用户回复“继续”、不等待普通修复范围选择。
-- 不修改 runner 的 fix/recheck 预算、commit-only 授权或队列行为。
+- `artifact-recovery-required` 交由 `trellis-auto-loop`；不叠加 Check 重录预算，不改 fix/recheck、commit-only、队列。
 
 subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `check_profile`；主会话收到后必须完成允许的 `DOC-*` 处理，再完成匹配 action 的 `record + next`。
 
@@ -232,12 +224,12 @@ subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `chec
 
 ## Interactive Post-Check Stop Gate
 
-非 validated auto-loop 先输出完整标准报告，再在本 Gate 内按以下顺序分流：
+非 validated auto-loop 先按本文件输出标准报告或接受状态的简短确认，再依序分流；不重贴已有报告：
 
 1. 只从当前完成链证据识别 direct Git intent：触发检查的最新用户消息明确请求普通 push 或用户主动 `commit-only`；或者 Check-All 已因该 Git 请求报告并停止后，用户在当前报告上明确接受风险并要求继续。不得从任务标题、摘要、dirty 状态、无关历史或 auto-loop 内部 action 推断。
-2. direct Git 可在 strict pass，或全部 findings 已有效接受时继续；还须无阻塞、无阻断型部分验证、无未接受且未标记 `[上线后验证]` 的实质风险。允许已验证 `DOC-*` 和完整登记的 `[上线后验证]`；报告后同轮进入 Update-Spec，`no-op|written` 再到 Push，`needs-review` 停止。
+2. direct Git 或用户明确要求继续，可在 strict pass，或全部 findings 已有效接受时继续；还须无阻塞、无阻断型部分验证、无未接受且未标记 `[上线后验证]` 的实质风险。允许已验证 `DOC-*` 和完整登记的 `[上线后验证]`；报告或简短确认后同轮进入 Update-Spec，`no-op|written` 再到 Push，`needs-review` 停止。
 3. 未处置 `CHK-*` / `FBK-*`、blocked、阻断型部分验证或其它未接受实质风险时，报告并停止，不运行 Update-Spec 或生成 Git 计划。Git 请求不授权修复或代用户接受风险。
-4. 没有匹配 direct Git intent 的普通 interactive 检查保持原行为：报告后立即停止并等待用户选择。
+4. 没有匹配 direct Git intent 且用户未要求继续的普通 interactive 检查保持原行为：报告或简短确认后停止并等待用户选择。
 
 ### 交互式下一步引导
 
@@ -245,11 +237,9 @@ subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `chec
 
 1. 有未处置 findings：提示 `修复全部`、精确 ID、接受当前报告全部风险、`接受风险 <ID> 并继续` 或 `仅保留报告`；不逐项重复确认。
 2. 有 blocked、阻断型部分验证或未标记 `[上线后验证]` 的实质风险：指出所需决策、授权或验证，完成后重跑 Check-All；不自行执行生产、外部或破坏性操作。
-3. direct Git strict pass 或已接受风险通过：说明本轮正在进入 `trellis-update-spec`，不要求用户再次回复“继续”或确认 Git 计划。
-4. 无 direct Git intent 且 strict pass / 已接受风险通过：提示用户回复 `继续`，下一轮进入 `trellis-update-spec`，再由 `trellis-push` 生成提交计划。
+3. direct Git 或用户已要求继续，且 strict pass / 已接受风险通过：说明本轮正在进入 `trellis-update-spec`，不要求用户再次回复“继续”；Git 计划确认仍由 Push 执行。
+4. 无 direct Git intent、用户未要求继续且 strict pass / 已接受风险通过：提示用户回复 `继续`，下一轮进入 `trellis-update-spec`，再由 `trellis-push` 生成提交计划。
 
 停止边界只控制是否自动推进，不能让报告在没有下一步提示的情况下结束。
 
-标准报告仅包含上方统一模板定义的检查内容和本 Gate 的唯一主动作。
-
 Check-All 不新增 direct Git 摘要或 Git 计划；这些仍由 Update-Spec 与 Push 所有。`[上线后验证]` 交给 Push 风险摘要和既有 `trellis-release` / `release.md`。

package/enhancements/0.6/.agents/skills/trellis-create-command/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: trellis-create-command
-description: "Create a new trellis entry as command or skill; writes agents copy and optionally skill-garden."
+description: "Create a new trellis entry as command or skill for the target platform, optionally distributing through skill-garden."
 ---
 # Create New Trellis Entry
 
-创建一个新的 trellis 入口。支持两种形态：斜杠命令（command）或 Claude skill。
+创建一个新的 trellis 入口。支持两种形态：斜杠命令（command）或 skill，具体目录与格式遵循目标平台约定。
 
-> **0.6 取舍提示**：skill-garden 0.6 包默认全部 skill 化，不再维护 `.claude/commands/` 目录。形态选 command 时，**只在目标项目落 2 份**，不分发到 skill-garden 0.6 包（强制分发时需手动维护，不建议）。新建入口推荐选 skill 形态。
+> **0.6 取舍提示**：skill-garden 0.6 包默认全部 skill 化，不再维护 `.claude/commands/` 目录。形态选 command 时，**只按目标平台在项目内创建**，不分发到 skill-garden 0.6 包。新建入口推荐选 skill 形态。
 
 ---
 
@@ -54,6 +54,8 @@ description: "Create a new trellis entry as command or skill; writes agents copy
 - 若用户明确要在其他项目创建，改用其指定的绝对路径；本 skill 不主动 `cd`，只记住该路径用于后续写入
 - 若目标项目就是 skill-garden 本身（在 skill-garden 仓库里 `create-command`），`<target>` 与 `<skill-garden>` 指同一路径，**避免重复写入**（只写一次）
 
+**目标平台**：按 `trellis-meta` 的 `references/platform-files/platform-map.md`，结合用户指定的平台和目标项目实际配置，确定本次入口目录；未指定时推断当前平台，多平台需求才扩展到对应目录。
+
 **`<skill-garden>`（分发源，scope 含 skill-garden 时必需）**：默认 `/root/project/skill-garden`。
 
 - 路径不存在或与用户期望不符 → 询问用户确认
@@ -73,8 +75,8 @@ description: "Create a new trellis entry as command or skill; writes agents copy
 
 | 形态 | 何时选 | 触发方式 |
 |------|--------|---------|
-| **command** | 显式动作、高风险、需确认点（如 finish-work、continue） | `/trellis:<name>` |
-| **skill** | 自然语可触发、查询 / 分析 / 检查、低破坏性（如 check-all、extract-prd、visualize） | Claude 自动路由 + `/trellis-<name>` |
+| **command** | 显式动作、高风险、需确认点（如 finish-work、continue） | 按目标平台的显式入口语法 |
+| **skill** | 自然语可触发、查询 / 分析 / 检查、低破坏性（如 check-all、extract-prd、visualize） | 自动匹配或显式调用，以目标平台能力为准 |
 
 决定不了时**推荐 skill**：自然语路由更灵活，显式斜杠仍可用。反过来，后悔做成 skill 想改 command 比较费事。
 
@@ -87,7 +89,7 @@ description: "Create a new trellis entry as command or skill; writes agents copy
 **简单 skill / command**（< 50 行）：
 
 ```markdown
-<frontmatter 仅 skill 有>
+<frontmatter 按 Step 4 与目标平台格式>
 # <标题>
 
 <1-2 行简介>
@@ -152,51 +154,24 @@ description: "<what> <when> <exclusion>"
 - 选 **Auto-routing** 当 skill 需要在对话中被自然语触发（如 `trellis-extract-prd`、`trellis-verify-task`、`trellis-check-all`）
 - 选 **Manual-only** 当 skill 用法明确、频率低、不希望占用每次对话 skill 列表 token（如 `trellis-create-command` 自身、`trellis-plan-version`）
 
-**agents 版 frontmatter**：正文 + frontmatter 与 skill 版完全一致（包括 `name: trellis-<name>`），只是落在 `.agents/skills/trellis-<name>/` 目录。
-
-```yaml
----
-name: trellis-<name>
-description: "<与 skill 版一致>"
----
-```
+**Skill-Garden 分发源码**：`.claude` 与 `.agents` 两份 skill 的正文 + frontmatter 完全一致（包括 `name: trellis-<name>`）。
 
-**command 版**：无 frontmatter，纯 markdown。
+**command 版**：格式与 frontmatter 参考 `trellis-meta` 及目标平台已有同类入口，不统一套用 Claude 格式。
 
 ### Step 5: 写入副本
 
-**不变量（必须遵守）**：每个 trellis 入口都成对存在 —— `.claude/<commands 或 skills>/...` 主副本 + `.agents/skills/trellis-<name>/SKILL.md` 镜像副本。漏写任一份会破坏 skill-garden install.sh 的对称分发。scope 含 skill-garden 时，skill 形态需要在 `<skill-garden>/.trellis/0.6/` 下各写一份（共 4 份）；command 形态在 0.6 中不再分发到 skill-garden（见下表注）。
+**项目内入口**：按 Step 0 确定的平台，使用 `trellis-meta` 的 `references/customize-local/change-skills-or-commands.md` 中对应目录与格式创建。多平台时同步所需入口；支持共享 `.agents/skills/` 的平台可复用同一份，不按消费者重复写入。不要求每个项目同时创建 `.claude` 和 `.agents` 副本，也不为 command 自动补同名 skill。
 
-按形态决定落盘位置：
-
-**形态 = skill**（2 份 / scope 为 skill-garden 时 4 份）：
+**Skill-Garden 分发源码**（仅 skill 形态且 scope 含 skill-garden）：双副本约定只适用于以下两个源码位置，正文、frontmatter 及配套文件保持一致。
 
 | 位置 | frontmatter name |
 |------|------------------|
-| `<target>/.claude/skills/trellis-<name>/SKILL.md` | `trellis-<name>`（主副本） |
-| `<target>/.agents/skills/trellis-<name>/SKILL.md` | `trellis-<name>`（镜像，body + frontmatter 完全同主副本） |
 | `<skill-garden>/.trellis/0.6/.claude/skills/trellis-<name>/SKILL.md` | `trellis-<name>` |
 | `<skill-garden>/.trellis/0.6/.agents/skills/trellis-<name>/SKILL.md` | `trellis-<name>` |
 
-**形态 = command**（仅 target 2 份；scope = skill-garden 也不分发到 0.6 包）：
-
-| 位置 | 格式 |
-|------|------|
-| `<target>/.claude/commands/trellis/<name>.md` | 无 frontmatter（主副本） |
-| `<target>/.agents/skills/trellis-<name>/SKILL.md` | 带 frontmatter，`name: trellis-<name>`（镜像） |
-
 > **0.6 不分发 command 到 skill-garden**：0.6 包目录树没有 `.claude/commands/`，install.sh 也不会处理。如果你确实希望 command 形态分发给其他项目使用，请：(a) 改用 skill 形态，或 (b) 把该 command 同时放到 0.5 包（向下兼容用户），或 (c) 在 skill-garden 包外用其他机制分发。
 
-**同步技巧**：写完主版（`.claude/skills/trellis-<X>/SKILL.md` 或 `.claude/commands/trellis/<X>.md`）后，用 `cp` 派生其他副本：
-
-```bash
-# 主副本写完后，副本内容完全一致，直接 cp 即可
-cp <target>/.claude/skills/trellis-<X>/SKILL.md <target>/.agents/skills/trellis-<X>/SKILL.md
-
-# 对 skill-garden 同步（仅 skill 形态、scope 为 skill-garden 时）
-cp -r <target>/.claude/skills/trellis-<X> <skill-garden>/.trellis/0.6/.claude/skills/
-cp -r <target>/.agents/skills/trellis-<X> <skill-garden>/.trellis/0.6/.agents/skills/
-```
+**同步技巧**：需要完全一致的副本时，用 `cp` 从已写好的 skill 目录派生，包含 `references/`、`scripts/` 等配套文件；目标路径取自本步确定的项目目录或分发源码目录。
 
 ### Step 6: 更新 skill-garden README（scope = skill-garden 时）
 
@@ -211,10 +186,10 @@ cp -r <target>/.agents/skills/trellis-<X> <skill-garden>/.trellis/0.6/.agents/sk
 
 | 检查项 | 方法 |
 |-------|------|
-| 新 skill 出现在 Claude skill list | 读 `<available-skills>` 区，确认 `trellis-<X>` 存在且 description 完整 |
-| 新 command 出现在 slash 列表 | 下拉 `/trellis:` 能看到 `<name>` |
+| 新 skill 出现在目标平台技能列表 | 使用目标平台的技能发现方式，确认 `trellis-<X>` 存在且 description 完整 |
+| 新 command 可被目标平台发现 | 按该平台的显式入口语法确认新命令可见 |
 | scope=skill-garden：install 端到端 | `rm -rf /tmp/sg-test && mkdir -p /tmp/sg-test/.trellis && echo "0.6.0-beta.8" > /tmp/sg-test/.trellis/.version && bash <skill-garden>/scripts/install.sh /tmp/sg-test <X>` |
-| 副本内容一致 | `wc -l` 行数一致；关键段落 `diff` 确认 |
+| 需要一致的副本内容一致 | 用 `diff` 比较正文、frontmatter 及配套文件 |
 
 ### Step 8: 输出确认
 
@@ -226,18 +201,17 @@ cp -r <target>/.agents/skills/trellis-<X> <skill-garden>/.trellis/0.6/.agents/sk
 
 ### 副本
 
-- `<target>/.claude/<path>`
-- `<target>/.agents/skills/trellis-<X>/SKILL.md`
-- `<skill-garden>/.trellis/0.6/` 同步位置 × 2（仅 skill 形态时显示）
+- `<target>/<实际创建的入口路径>`（多平台时逐项列出，共享路径只列一次）
+- `<skill-garden>/.trellis/0.6/` 下的两个实际源码路径（仅 skill 形态且 scope 含 skill-garden 时显示）
 
 ### 触发方式
 
 - **自然语**：<触发词例子>
-- **显式**：<`/trellis:<X>` 或 `/trellis-<X>`>
+- **显式**：<目标平台支持的调用方式>
 
 ### 下一步建议
 
-- 在当前对话试一次触发，观察 Claude 是否正确路由
+- 在目标平台试一次触发，观察是否正确路由
 - 触发失败时调整 description（精准化 when/exclusion）
 - 内容有遗漏时补充 Step 或 checklist
 ```
@@ -266,7 +240,7 @@ cp -r <target>/.agents/skills/trellis-<X> <skill-garden>/.trellis/0.6/.agents/sk
 
 - ❌ 不用 kebab-case（不要 `reviewPr` / `review_pr`）
 - ❌ 名字过于笼统（`tool` / `helper` / `util`）
-- ❌ 与现有命令冲突（先 `ls .claude/commands/trellis` 和 `.claude/skills/` 确认）
+- ❌ 与现有入口重名（先检查 Step 0 确定的目标平台入口目录）
 - ❌ skill 写文件时漏 `trellis-` 前缀（影响自动路由分组）
 - ❌ "严格提取"语义的入口用 `create-` 前缀（应该用 `extract-`，避免 AI 误判为生成型）
 
@@ -279,15 +253,15 @@ cp -r <target>/.agents/skills/trellis-<X> <skill-garden>/.trellis/0.6/.agents/sk
 - 输出格式必须用 markdown 模板明示
 - 反模式清单必写（帮 Claude 避免常见误用）
 - 中文注释 + 英文 description（description 中的触发词可中英混合）
-- 引用文件路径用反引号 `.claude/...`，不写裸路径
+- 引用文件路径用反引号包裹实际路径，不写裸路径
 
 ---
 
 ## 反模式（避免）
 
-- ❌ 写 `.cursor/commands/`（已废弃，统一 `.claude/commands/`）
+- ❌ 忽略 Meta 的平台目录规则，把入口写入未选平台的目录
 - ❌ 同时创建 command 和 skill 同名入口（触发歧义，不知选哪个）
-- ❌ 只写 `.claude/...`，漏了 `.agents/skills/trellis-<X>/`（skill-garden install 会不对称）
+- ❌ 分发到 skill-garden 时只写一份源码，漏掉 `.claude` / `.agents` 双副本中的另一份
 - ❌ 选 Auto-routing 策略但 description 过短（< 80 字），Claude 路由不稳；Manual-only 策略无此要求
 - ❌ description 用名词开头（"A skill for..."）而不是动词开头（"Analyzes..." / "Extract..." / "Create..."）
 - ❌ 不询问 scope 直接写 skill-garden（需要用户显式确认 skill-garden 路径）

package/enhancements/0.6/.agents/skills/trellis-extract-prd/SKILL.md

@@ -114,9 +114,47 @@ description: "Extract a cohesive task PRD faithfully from a source requirements
 - ✅ 属于本任务实现？
 - ❌ 不属于本任务？（由哪个 task / wave 实现，或 N/A）
 
-将发现记录到 PRD 的「关联需求」表，表头必须含「本任务实现」列。
+整理发现，待 Step 6 写入 PRD 的「关联需求」表，表头必须含「本任务实现」列。
 
-### Step 5: 生成 PRD
+### Step 5: 创建或定位任务
+
+更新已有任务时，先读取已明确定位的任务目录中的 `task.json` 和 `prd.md`，沿用该目录，不运行 `task.py create`。
+
+新建任务时，从前述提取结果确定标题、slug 和一句话目标，先调用框架脚本创建任务目录、`task.json` 和默认 `prd.md`：
+
+```bash
+python3 .trellis/scripts/task.py create "<任务标题>" \
+  --slug "<任务 slug，不含日期前缀>" \
+  --priority P2 \
+  --description "<本任务要改动的行为，一句话>"
+```
+
+创建成功后，以命令返回的任务目录为准；不要提前建目录或写入 PRD。创建失败则停止后续写入，不能把同名目录自动当作待更新任务。
+
+如果基于版本规划批量创建 task，按以下规则生成 slug：
+
+```text
+<version>-wNN-tNN-<task-slug>
+```
+
+- `wNN`：wave 顺序号，例如 `w01`、`w02`
+- `tNN`：全版本 task 创建顺序号，例如 `t01`、`t02`
+- `<task-slug>`：保留业务语义的短 slug
+
+示例：
+
+```bash
+python3 .trellis/scripts/task.py create "项目列表反馈投标状态" \
+  --slug "srm-iqs-v141-w01-t01-project-list-feedback-bid-status" \
+  --priority P2 \
+  --description "项目列表反馈投标状态"
+```
+
+不要把日期写入 `--slug`；`task.py create` 会自动添加 `MM-DD-` 前缀。批量创建时，必须按版本规划的「Task 创建顺序」逐个执行上述命令。
+
+### Step 6: 写入 PRD 并补充 task.json
+
+在 Step 5 返回或已定位的任务目录中写入 `prd.md`：新任务用提取结果替换默认模板；已有任务在读过现有内容后更新本次提取涉及的内容。
 
 PRD 的结构按下列顺序组织：
 
@@ -164,39 +202,7 @@ PRD 的结构按下列顺序组织：
 - 关键文件路径（用于 task.json `relatedFiles`）
 ```
 
-### Step 6: 创建 / 更新 task.json
-
-PRD 写入后，调用框架脚本创建 `task.json`，使任务目录完整可用：
-
-```bash
-python3 .trellis/scripts/task.py create "<PRD标题>" \
-  --slug "<任务目录名去掉日期前缀>" \
-  --priority P2 \
-  --description "<TL;DR「做什么」一句话>"
-```
-
-如果基于版本规划批量创建 task，按以下规则生成 slug：
-
-```text
-<version>-wNN-tNN-<task-slug>
-```
-
-- `wNN`：wave 顺序号，例如 `w01`、`w02`
-- `tNN`：全版本 task 创建顺序号，例如 `t01`、`t02`
-- `<task-slug>`：保留业务语义的短 slug
-
-示例：
-
-```bash
-python3 .trellis/scripts/task.py create "项目列表反馈投标状态" \
-  --slug "srm-iqs-v141-w01-t01-project-list-feedback-bid-status" \
-  --priority P2 \
-  --description "项目列表反馈投标状态"
-```
-
-不要把日期写入 `--slug`；`task.py create` 会自动添加 `MM-DD-` 前缀。批量创建时，必须按版本规划的「Task 创建顺序」逐个执行上述命令。
-
-创建完成后，根据 PRD 中的分析补充 `task.json` 中的字段：
+PRD 写入后，根据其中的分析补充该任务现有 `task.json` 中的字段：
 - `dev_type`：`frontend` / `backend` / `fullstack`
 - `relatedFiles`：PRD Technical Notes 中识别的关键文件路径
 - `meta.version_plan`：版本规划产物路径（如有）

package/enhancements/0.6/.agents/skills/trellis-flower-update/SKILL.md

@@ -7,7 +7,7 @@ description: "手动检查和执行已安装 Flower/Trellis 强化包升级。
 
 用于用户主动要求升级已安装的 Flower/Trellis 强化层时。自动 SessionStart 提示的 snooze、skip 和 cooldown 只是不主动打扰，不能阻止用户显式要求升级。
 
-本 skill 不是发版入口。用户说“我想发版了”、release、打 tag、npm publish、更新 package 版本号或准备发布包时，不使用本 skill；按当前项目的 release SOP、`trellis-release` 或发布规范处理。
+本 skill 不是发版入口。用户说“我想发版了”、release、打 tag、npm publish、更新 package 版本号或准备发布包时，不使用本 skill；按当前项目的 release SOP 或发布规范处理。
 
 ## Workflow
 

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

@@ -144,7 +144,7 @@ auto-loop 内部 `commit-only` 不渲染交互式计划或结果，也不再次
 
 每个仓库按计划顺序执行。执行前重新检查 planned files、当前分支、HEAD、upstream、冲突状态、staged、全部 dirty paths 和 retained 摘要；任一关键条件变化都停止当前执行并重新规划。普通模式仅 `retained` 内容变化时可更新说明；auto-loop 内部模式的 retained 内容必须保持不变。
 
-计划包含本地生成命令时，前置仓成功后按计划执行命令，再复用本节现有预检。命令成功、后续仓全部 dirty paths 都在预计 exact files 内且 retained 摘要未漂移时直接继续；否则停止并重新生成计划。预计文件最终 clean 时不强行提交。
+计划包含本地生成命令时，前置仓成功后按计划执行命令，再复用本节现有预检。命令成功、后续仓全部 dirty paths（auto-loop 内部 `commit-only` 扣除已登记且验证未变化的 retained paths）都在预计 exact files 内且 retained 摘要未漂移时直接继续；否则停止并重新生成计划。预计文件最终 clean 时不强行提交。
 
 auto-loop retry/resume 时，读取调用方提供的已完成仓库提交，逐个验证 repository、commit object、message 和文件集合仍符合当前任务证据，并确认当前分支/HEAD 变化可由这些提交解释。验证通过的提交直接跳过；验证失败立即 blocked，不重复提交。确定性生成入口可以安全重跑，以当前 Git 状态重新规划后续步骤。