flower-trellis 0.6.1-beta.2 → 0.6.1-beta.4

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

@@ -44,7 +44,7 @@ description: "统一 Check-All：按 requested/effective depth 路由 light/full
 3. **分类先于严重度**：读取 `references/fallback-findings.md`；主路径错误和非兜底契约违背进入 `CHK-*`，fail-closed、异常输入、失败降级和防御性保护缺口进入 `FBK-*`。契约证据影响严重度，不改变兜底根因归属。
 4. **处置只确认一次**：统一报告后选择 `CHK-*` / `FBK-*` 修复范围或接受风险；`修复全部` 覆盖两类，接受风险不得隐藏发现。
 5. **委托不改边界**：复用 `trellis-check` 的清单和验证方法，忽略其直接修复指令。
-6. **真正阻塞才中途暂停**：只有业务规划冲突、后续验证前提失效、生产或外部副作用、破坏性操作风险时提前停止。
+6. **真正阻塞才中途暂停**：业务规划冲突、前提失效，或当前结论必需验证涉及未授权生产/外部/破坏性副作用时暂停；发布后验收只记 `[上线后验证]`，不执行、不阻断。
 
 中途停止时也要使用统一问题模型，报告已完成范围和阻塞原因；只询问解除阻塞所需的业务或安全决策。
 
@@ -115,7 +115,7 @@ check_profile:
 - 自动修复的 `DOC-*` 内容；
 - 剩余 `CHK-*` 主路径问题与 `FBK-*` 兜底问题；
 - 每个剩余问题的未处置或已接受风险状态；
-- 已执行验证和未覆盖风险；
+- 已执行验证、未覆盖风险和 `[上线后验证]`；
 - 与当前结论匹配的唯一下一步。
 
 ---

package/enhancements/0.6/.agents/skills/trellis-check-all/references/depth-routing.md

@@ -55,7 +55,7 @@ untracked 必须为 `stage=check`，只读个人 check 偏好，不创建 task-s
 2. validated auto-loop action 的 `requested_check_depth`；
 3. 默认 `auto`。
 
-显式意图按语义识别：`简单检查`、`轻量检查`、`light check` 表示 light；`全面检查`、`全量检查`、`最终检查`、`提交前检查`、`full check` 表示 full。同一请求出现多次切换时，以最后一次明确表达为准。单独说 `check` / `check-all` 只是调用统一入口，不自动等同 full。
+深度按最后一次明确表达：`简单检查` / `轻量检查` / `light check` 为 light；`全面检查` / `全量检查` / `full check` 为 full。`check` / `check-all` / `最终检查` / `提交前检查` 只调用统一入口并保持 `requested_depth=auto`；提交不等同 full。
 
 历史 auto-loop 缺少深度字段时 runner 返回 `full`。文件数、diff 行数或“看起来简单”不能单独决定 light。
 
@@ -87,8 +87,8 @@ hard-full 只看行为契约变化和影响面是否闭合。文件载体或主
 - 公共 API、CLI、schema、持久化状态、协议字段、缓存、迁移或历史数据兼容发生行为变化；
 - 权限、安全、资金、并发、时序、状态机、回滚、发布或 Git 控制门禁发生行为变化；
 - 改动跨越独立行为边界，或直接引用点、状态传播或回归路径无法完整列出；
-- 正在重检既有 full `CHK-*` / `FBK-*` 修复结果；
 - light 执行中发现未知 dirty path、真实影响面扩大或关键验证缺口。
+- 计划基线、相关契约或既有验证证据已经变化，导致原 full 证据失效或无法证明仍覆盖当前 diff。
 
 无法确认是否改变行为契约或影响面是否闭合时，使用 `effective=full`、`confidence=fallback-full`。
 
@@ -98,6 +98,8 @@ hard-full 只看行为契约变化和影响面是否闭合。文件载体或主
 - 无行为性 hard-full 信号；
 - 受影响规划条目、直接引用点、状态传播和回归路径可穷举；
 - 局部行为修改时，直接引用点和回归路径可穷举，并有可运行的定向验证；无行为变化时，仅涉及注释、错别字、排版、解释文字、示例或机械投影同步；
-- 不在既有 full 修复/重检链中。
+- 承接既有 full 报告时，原 finding、修复路径、引用/回归和定向证据可闭合。
 
-light 执行中命中 hard-full 时，立即单向升级 full 并补齐所有适用维度；同一修复/重检循环内 full 不得降级。
+跨轮局部修复可重新选择 light；结束任务、提交或已有 full 报告不触发 full。既有 full 证据仍覆盖当前 diff且后续修改已定向重检时可复用。仅显式 full、hard-full、范围不闭合、未知 dirty、基线/契约变化或证据失效时重跑 full。
+
+light 执行中命中 hard-full 时，立即单向升级 full 并补齐所有适用维度；同一次 Check-All 执行中一旦升级为 full，不得降回 light。

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

@@ -47,7 +47,7 @@
 
 - **保护收益**：说明修复后避免的错误放行、数据损害、权限扩大、失控失败或诊断盲区。
 - **验证方式**：优先给出可执行测试、命令、故障注入或明确手动步骤。
-- 缺少环境、工具或权限时仍保留 `FBK-*` ID，验证标记 `部分验证` 并写明缺口；部分验证继续阻断 strict pass。
+- 环境、工具或权限不足仍保留 `FBK-*` ID：提交前证据缺口用阻断型 `部分验证`；仅部署后/生产/外部可完成时用非阻断 `[上线后验证]`。细则见 reporting reference。
 
 ---
 
@@ -69,7 +69,7 @@
 - `CHK-*` 与 `FBK-*` 独立编号，修复/重检循环保留原 ID；两类都按实际影响分配 P0/P1/P2。
 - `修复全部` 覆盖两类问题；精确修复可混合 ID，例如 `修复 CHK-001,FBK-002`。
 - 用户可以明确接受当前报告中任一 `CHK-*` 或 `FBK-*` 的风险而不修复；问题仍保留原通道、严重度和证据。
-- 风险接受须唯一对应当前报告 ID；P0 必须逐项写出精确 ID。证据、diff 或严重度变化后接受失效。
+- 接受当前报告全部风险覆盖全部 `CHK-*` / `FBK-*`，包括 P0，无固定句式；部分接受须唯一定位。报告或范围不清才追问；证据、diff、内容或严重度变化后失效。
 - `strict pass` 仍要求剩余 `CHK-*` 与 `FBK-*` 均为 0；全部剩余问题被有效接受且无阻塞、部分验证或其它实质风险时，使用“已接受风险通过”。
-- 只有未处置的 `CHK-*` 或 `FBK-*` 阻断交互完成链。validated auto-loop 不能代表用户接受风险，仍须两类问题为 0 才能 `record ok`。
+- 未处置 `CHK-*` / `FBK-*`、阻断型部分验证或阻塞会阻断；`[上线后验证]` 不阻断。auto-loop 不得接受风险，须两类问题为 0 且无阻断型部分验证才能 `record ok`。
 - `仅保留报告` 只停止修复，不构成风险接受或通过。

package/enhancements/0.6/.agents/skills/trellis-check-all/references/full-profile.md

@@ -76,7 +76,7 @@ full 提取所有适用条目。每条记录来源位置，实际阅读对应代
 - 确认历史记录的新字段值和 null/零值行为。
 - 确认过滤、聚合和降级查询能处理历史数据。
 - 追踪新字段的写入来源和可靠性。
-- 无可用历史数据环境时标记 `部分验证` 或 `阻塞`，不得标记通过。
+- 无可用历史数据环境时按验证阶段判断：提交前原则上可完成但缺少证据时标记 `部分验证` 或 `阻塞`；本质依赖部署后真实状态时登记 `[上线后验证]`，不得伪报已执行。
 
 ### Dimension D：Data Flow Trace
 
@@ -91,10 +91,11 @@ full 提取所有适用条目。每条记录来源位置，实际阅读对应代
 
 **Trigger**：Dimension A-D 任一适用。
 
-- 检查关键假设是否已有可运行的自动化测试或明确手动验证。
+- 自动化测试优先；可重复的手动步骤、静态检查或定向命令也可作为验证证据。
 - 优先覆盖最脆弱的参数名、嵌套结构、历史数据和空值路径。
 - 测试存在时实际运行；未运行不能报告通过。
-- 缺少测试时记录问题，等待用户确认修复范围后再新增测试。
+- 仅缺少自动化测试文件不得生成 `CHK-*`；项目 spec、风险等级或回归概率明确要求自动化覆盖时，缺失测试仍记录问题。
+- 缺少完成当前结论所必需的充分证据时记录 `CHK-*`，等待用户确认修复范围后再补充验证或测试。
 
 发现假设错误时写入统一问题集合并继续其它可执行检查。只有该错误让后续检查前提失效时，才按“真正阻塞”规则暂停。
 
@@ -118,7 +119,7 @@ full 提取所有适用条目。每条记录来源位置，实际阅读对应代
 - “Report and Fix”；
 - 任何要求检查 agent 直接编辑、补测试或反复修到通过的语句。
 
-验证失败时记录命令、退出状态和关键错误到统一问题集合，继续其它独立验证。可能写业务数据或外部系统的验证不直接运行，按真正阻塞规则处理。
+验证失败时记录命令、退出状态和关键错误到统一问题集合，继续其它独立验证。可能写业务数据或外部系统的验证不直接运行：当前结论所必需且提交前原则上可完成时标记阻断型 `部分验证` 或 `阻塞`；本质依赖部署后、生产环境或真实外部状态时登记 `[上线后验证]`，不得自动执行。
 
 ### Maven Evidence 复用
 
@@ -148,3 +149,5 @@ Full 通过必须同时满足：
 - 项目规范、复用、依赖、同层一致性和验证命令已覆盖实际变更范围；
 - strict pass：无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险；或
 - 已接受风险通过：所有剩余 `CHK-*` / `FBK-*` 都有当前有效的用户风险接受，且无阻塞、无部分验证、无未接受的实质剩余风险。
+
+strict pass 或已接受风险通过可以与已明确登记的 `[上线后验证]` 并存；该标签只表示发布阶段仍需执行的验收，不表示当前已经验证。

package/enhancements/0.6/.agents/skills/trellis-check-all/references/light-profile.md

@@ -12,7 +12,7 @@ Light 是局部且可穷举的检查，不是“少看一点”的检查。只
 - 受影响规划条目、直接引用点、状态传播和回归路径能完整列出；
 - 没有行为性 hard-full 信号，载体名称不得单独触发升级；
 - 有定向验证，或变更确定不改变行为；
-- 不是 full 修复/重检链的一部分。
+- 承接既有 full 报告的局部修复时，原 finding、修复路径、直接引用点和回归路径均可闭合，且定向验证足以覆盖后续 diff。
 
 执行中发现任一边界不成立，记录升级原因，切换到 `references/full-profile.md`。
 
@@ -41,12 +41,14 @@ untracked 上下文没有 task artifacts，本维度标记 `N/A`，不得根据
 | --- | --- | --- |
 | API Contract | 新增或修改 API 调用、请求参数或响应解析 | 读取实际 Handler/DTO/Schema 或同模式调用，确认字段名、类型、默认值和错误响应 |
 | Component Context | Modal、Drawer、Tab 或条件渲染容器内修改有状态组件 | 确认销毁/保留、受控值、初始化值和重置行为 |
-| Data History | 新增、修改或重新解释持久化字段 | 确认 null/零值/历史记录降级；无环境证据标记 `部分验证` |
+| Data History | 新增、修改或重新解释持久化字段 | 确认 null/零值/历史记录降级；按验证阶段区分阻断型 `部分验证` 与 `[上线后验证]` |
 | Data Flow Trace | 变更跨越 UI/API/Service/Storage 中两个或更多边界 | 连起来核对参数名、类型、嵌套层级和错误传播 |
-| Verification Tests | A-D 任一适用 | 找到并运行定向测试；缺少测试记录为 `CHK-*` |
+| Verification Tests | A-D 任一适用 | 自动化测试优先；也可使用可重复的手动步骤、静态检查或定向命令覆盖关键假设 |
 
 未触发的 Dimension 标记 `N/A`。
 
+仅缺少自动化测试文件不得生成 `CHK-*`。已有测试时应实际运行；项目 spec、风险等级或回归概率明确要求自动化覆盖时，缺失测试仍记录问题。否则只有缺少完成当前结论所必需的充分证据时才记录 `CHK-*`，模糊的“手动看过”不构成证据。
+
 ---
 
 ## 维度 3：完整性、规范与项目验证
@@ -81,4 +83,4 @@ Light 通过必须同时满足：
 - strict pass：无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险；或
 - 已接受风险通过：所有剩余 `CHK-*` / `FBK-*` 都有当前有效的用户风险接受，且无阻塞、无部分验证、无未接受的实质剩余风险。
 
-存在未覆盖但不影响局部结论的内容时，必须在“未覆盖与风险”中说明。
+存在未覆盖但不影响局部结论的内容时，必须在“未覆盖与风险”中说明。只有部署后、生产环境或外部系统中才能安全完成的事项使用 `[上线后验证]`；它可以与通过结论并存，但不得伪报已执行。

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

@@ -40,24 +40,30 @@
 | 影响 | 加粗字段 | 当前缺口的用户、数据、安全或工程影响 |
 | 保护收益 | 加粗字段 | 修复后恢复或新增的明确保护结果；属于报告完整度，不得省略或并入建议 |
 | 建议 | 加粗字段 | 推荐修复方式，不在检查阶段执行 |
-| 验证 | 加粗字段 | 修复后的测试、故障注入、命令或手动验证步骤；受环境限制时标记 `部分验证` |
+| 验证 | 加粗字段 | 修复后的测试、故障注入、命令或手动验证步骤；受环境限制时按验证阶段标记阻断型 `部分验证` 或 `[上线后验证]` |
 
-`FBK-*` 分类只由具体位置、可达场景和问题证据三项硬准入决定。保护收益与验证方式属于报告完整度；缺少环境时保留 ID 和已有证据，标记 `部分验证`，不得伪报 strict pass。
+`FBK-*` 分类只看具体位置、可达场景和问题证据；环境不足保留 ID。保护收益与验证方式仍为报告字段。
 
-`CHK-*` 与 `FBK-*` 分开编号。同一根因的多个位置合并到一个问题；严重度排序只在各自通道内部生效，每个通道内部按 `P0 -> P1 -> P2` 展示，但不得因此重排已经分配的 ID。跨通道报告顺序固定为完整 `CHK-*` 区块在前、完整 `FBK-*` 区块在后；禁止因 FBK 严重度更高、分类时先判断 FBK、发现先后或 ID 分配时机而 FBK-first、交错两类问题或省略分区标题。新根因使用对应通道的下一个 ID。每个问题的处置状态默认为待处理且不加标签，只有 `已接受风险` 才在条目标题行末尾追加 `` `[已接受风险]` `` 标签。`仅保留报告` 不改变处置状态，相关问题仍不加标签。处置状态不改变 ID、通道和严重度。
+`CHK-*` 与 `FBK-*` 分开编号，同根因位置合并。严重度排序只在各自通道内部生效，每个通道内部按 `P0 -> P1 -> P2` 展示且不重排 ID。跨通道报告顺序固定为完整 `CHK-*` 区块在前、完整 `FBK-*` 区块在后；禁止因 FBK 严重度更高、分类时先判断 FBK、发现先后或 ID 分配时机而 FBK-first 或交错。新根因递增编号。默认待处理无标签；仅 `已接受风险` 在标题末尾加 `` `[已接受风险]` ``。`仅保留报告` 不改变处置，处置不改变 ID、通道或严重度。
 
 ## 风险接受
 
-风险接受是用户对当前报告的显式处置，不是检查器对问题严重度的降级：
+风险接受由用户显式处置，不改变问题严重度：
 
 1. 只有用户可以接受风险；主会话、subagent 和 validated auto-loop 都不得代替用户推断或授权。
-2. 接受必须唯一对应当前报告的问题 ID。用户可以写 `接受风险 CHK-001,FBK-002 并继续`；当前报告只有一个候选时，“这个问题”“不管这个”等明确指代可以解析为该 ID。P0 必须逐项写出精确 ID，不接受 `接受全部剩余风险`。
+2. 按当前报告和语义解析：“接受当前报告全部风险”“全部接受”“这些风险都接受”等覆盖全部 `CHK-*` / `FBK-*`，包括 P0，无固定句式或逐项 ID。部分接受须唯一定位子集；报告版本或范围不清时才追问。
 3. 接受只绑定当前问题证据与实际 diff。受影响代码、契约、验证结果、问题内容或严重度变化后，原接受立即失效，问题恢复为待处理并移除标题行末尾的 `` `[已接受风险]` `` 标签。
 4. 已接受问题继续完整展示证据、影响、建议和验证，标题行末尾追加 `` `[已接受风险]` `` 标签；不得删除条目、改列 `DOC-*` 或伪报已修复。
-5. `strict pass` 只用于剩余 `CHK-*` / `FBK-*` 均为 0。所有剩余问题均已被有效接受，且无 blocked、无部分验证、无未接受的实质剩余风险时，结论为 `通过·已接受风险`。
-6. blocked、部分验证和无法唯一对应到当前问题 ID 的实质剩余风险不是 `CHK-*` / `FBK-*` 处置状态，不能借风险接受绕过。
+5. `strict pass` 只用于剩余 `CHK-*` / `FBK-*` 均为 0。所有剩余问题均已被有效接受，且无 blocked、无阻断型部分验证、无未接受的实质剩余风险时，结论为 `通过·已接受风险`。
+6. blocked、阻断型部分验证和无法唯一对应当前报告范围的实质剩余风险不是 `CHK-*` / `FBK-*` 处置状态，不能借风险接受绕过；`[上线后验证]` 不属于风险接受对象。
 7. `仅保留报告` 表示停止处置并等待，不等于接受风险；只有带明确接受语义的用户回复才改变问题处置状态。
 
+## 验证阶段
+
+- `部分验证`：当前结论必需、提交前可完成但证据不足；阻断 strict pass、Update-Spec 和 direct Git。
+- `[上线后验证]`：仅部署后、生产或外部系统可安全验收；在“未覆盖与风险”写动作、责任边界和预期结果。它不属于维度状态，不阻断 strict pass、Update-Spec 或 direct Git；strict pass 可以与其并存。
+- 本地 fixture、测试环境、静态契约或无副作用命令可完成的检查不得延期为 `[上线后验证]`。Check-All 不得执行生产或外部系统操作，也不得伪报通过。
+
 ---
 
 ## 输出：统一检查报告
@@ -121,14 +127,14 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 
 ### 未覆盖与风险
 
-- [<部分验证/阻塞/N/A>] <说明>
+- [<部分验证/上线后验证/阻塞/N/A>] <说明；上线后验证写动作、责任边界和预期结果>
 
 ### 修复批次
 
 - **批次 1**：<CHK/FBK 问题 ID> · <修复目标>
 - **修复后**：定向验证 -> Check-All 重检
 
-操作：`修复全部`、`修复 CHK-001,FBK-002`、`接受风险 CHK-001,FBK-002 并继续`、`仅保留报告`
+操作：`修复全部`、`修复 CHK-001,FBK-002`、`接受当前报告全部风险并继续`、`接受风险 CHK-001,FBK-002 并继续`、`仅保留报告`
 
 ### 下一步
 
@@ -137,7 +143,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 
 展示规则：
 
-- 报告头部的“工作/范围/画像/结论”与“修复批次”内的行必须使用 `- ` 列表项。这些行在 Markdown 段落内会被折叠成一段，不得改回裸段落行，也不得依赖行尾空格实现换行。
+- 报告头部“工作/范围/画像/结论”和“修复批次”必须使用 `- ` 列表项，不得改为裸行或依赖行尾空格。
 - 每个问题必须由一个四级标题承载，固定顺序为 `` #### `<ID>` `<严重度>` `<来源>` <标题> ``。仅 `已接受风险` 的问题在标题末尾追加 `` `[已接受风险]` ``；待处理不加标签。`来源` 与 `处置` 都不再单独占行。
 - 不得改用 `- [ ]` / `- [x]` 列表项承载问题条目。终端渲染器会把松散列表压平，相邻条目会糊成一段无法分辨；只有标题这类块级元素才能稳定产生视觉分隔。修复状态由“修复结果”表格表达，不靠 checkbox。
 - 条目内部的字段一律写成 `- **<字段>**：<值>` 加粗标签列表项。字段值折行后回到左边界，加粗标签是唯一能定位字段起点的锚，裸标签会淹没在正文里。
@@ -147,7 +153,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 - 同时存在两类问题时，`### 主路径问题` 及其全部 `CHK-*` 必须完整出现在 `### 兜底问题` 及其全部 `FBK-*` 之前；不得按全局严重度排序反转或交错两个区块。
 - 存在未处置 `CHK-*` 或 `FBK-*` 时展示“修复批次”，并只在报告末尾提供一次处置选择，不再逐项提问。
 - `修复全部` 始终覆盖全部 `CHK-*` 与 `FBK-*`；精确修复可以混合两类 ID。
-- 风险接受可以混合两类 ID；只有全部剩余问题都已有效接受时才形成“通过·已接受风险”。
+- 风险接受可混合两类 ID；“接受当前报告全部风险”覆盖全部剩余问题，包括 P0，无固定句式。全部有效接受后才形成“通过·已接受风险”。
 - `仅保留报告` 只表示停止处置，不改变未通过结论或剩余风险。
 - interactive 标准报告必须以“下一步”段结束；停止等待不等于省略引导。
 - 独立 `CHK-*` 或 `FBK-*` 不得因数量多而静默省略；先合并同根因重复项，再完整列出剩余项。
@@ -164,7 +170,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 2. 修复过程中不对每个问题重复确认。
 3. 新增业务歧义、破坏性风险或范围扩张时才暂停，并一次性说明受影响问题。
 4. 完成定向验证后复用当前 check route 重新执行 Check-All。
-5. 原 `CHK-*` / `FBK-*` 沿用各自 ID；新根因在对应通道继续递增编号。上次 `effective_depth=full` 时，本次最小深度为 full。
+5. 原 ID 沿用，新根因递增。后续按当前 diff 选深度：原 finding、修复路径、引用/回归和定向证据均闭合时可 light；范围扩大、契约/基线变化、未知 dirty 或证据失效时 full。
 
 修复完成后输出：
 
@@ -192,7 +198,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 
 检查通过后的动作由下方 `Interactive Post-Check Stop Gate` 判断：普通交互停止等待，符合 direct Git strict pass 或已接受风险通过条件时同轮进入 Phase 3.3 `trellis-update-spec`，再到 Phase 3.4 `trellis-push`。仍有未处置 `CHK-*` 或 `FBK-*` 时停留在处置/重检循环。
 
-untracked helper 不记录 Check-All 证据或风险接受。普通 strict pass / 已接受风险通过但尚未继续时保持 `stage=check`；只有 direct Git 同轮继续或用户后续明确继续时才 `advance --stage spec`。有未处置 `CHK-*`、`FBK-*`、部分验证、阻塞或报告后的新编辑时，先 `advance --stage implement` 再返回实现。
+untracked helper 不存检查证据或风险接受。普通通过后保持 `stage=check`；direct Git 同轮继续或用户明确继续才 `advance --stage spec`。未处置 `CHK-*` / `FBK-*`、阻断型部分验证、阻塞或新编辑先 `advance --stage implement`；仅 `[上线后验证]` 不回退。
 
 ---
 
@@ -202,8 +208,8 @@ validated auto-loop 复用相同的画像、profile、`DOC-*` 通道和问题模
 
 - 有 `DOC-*` 且可自动修复：主会话先应用并验证；只有当前任务 `implement.md` / `brief.md` 的实际变化追加精确 `--doc-remediation-file`，源码注释等其它 DOC 改动不得传该参数；随后重算 diff、范围和画像，再决定最终 `ok|failed|blocked`。
 - 有剩余 `CHK-*` 或 `FBK-*`：向 runner `record --result failed --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含最高严重度、两类问题 ID、根因、受影响文件和已自动修复的 `DOC-*`。validated auto-loop 不创建也不复用 interactive 风险接受。
-- 真正需要用户产品决策、越权、生产副作用或破坏性安全决策：使用同样深度字段 `record --result blocked`，随后按 runner 状态停止。
-- 无剩余 `CHK-*` 且无剩余 `FBK-*`：`record --result ok --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含自动修复数量；只有两类问题都为 0 才能进入通过路径。
+- 产品决策、越权、提交前生产副作用授权或破坏性决策：`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 授权或队列行为。
 
@@ -216,16 +222,16 @@ subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `chec
 非 validated auto-loop 先输出完整标准报告，再在本 Gate 内按以下顺序分流：
 
 1. 只从当前完成链证据识别 direct Git intent：触发检查的最新用户消息明确请求普通 push 或用户主动 `commit-only`；或者 Check-All 已因该 Git 请求报告并停止后，用户在当前报告上明确接受风险并要求继续。不得从任务标题、摘要、dirty 状态、无关历史或 auto-loop 内部 action 推断。
-2. direct Git 在以下任一条件成立时可以继续：Check-All strict pass；或全部剩余 `CHK-*` / `FBK-*` 都有当前有效的用户风险接受。两条路径还必须无阻塞、无部分验证、无未接受的实质剩余风险。允许存在已成功验证的 `DOC-*` 自动修复；标准报告输出后，同一轮进入 Phase 3.3 `trellis-update-spec`；`no-op|written` 再由其加载 `trellis-push`，`needs-review` 停止。
-3. 未处置 `CHK-*` / `FBK-*`、blocked、部分验证或未接受的实质剩余风险均不满足条件：输出标准报告并停止，不运行 Update-Spec，也不生成 Git 计划。原始 Git 请求不授权自动修复普通问题或替用户接受风险。
+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 检查保持原行为：报告后立即停止并等待用户选择。
 
 ### 交互式下一步引导
 
 所有 interactive 标准报告都必须在末尾输出 `### 下一步`，并按以下首个命中分支给出一个明确主动作：
 
-1. 有未处置 `CHK-*` 或 `FBK-*`：提示用户回复 `修复全部`、混合精确问题 ID、`接受风险 <问题 ID> 并继续` 或 `仅保留报告`；不得重复提出逐项确认。
-2. 有 blocked、部分验证或实质剩余风险：指出解除阻塞所需的精确决策、授权或验证，以及完成后重新运行 Check-All；涉及生产、外部系统或破坏性副作用时只引导用户授权，不自行执行。
+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` 生成提交计划。
 
@@ -237,8 +243,8 @@ subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `chec
 - `CHK-*` 主路径问题和 `FBK-*` 兜底问题的证据、影响与验证；
 - `DOC-*` 自动修复内容和验证；
 - 已执行验证及结果；
-- 未覆盖验证和剩余风险；
+- 未覆盖验证、`[上线后验证]` 和剩余风险；
 - 总体结论；
 - 与当前结论匹配的唯一主动作引导；有未处置 `CHK-*` 或 `FBK-*` 时是一次修复或风险接受选择，部分验证/阻塞时是补充决策或验证，通过时是 Phase 3.3 / Phase 3.4 指向。
 
-Check-All 不新增 direct Git 专用摘要，也不得自行生成提交计划、commit message、拟提交文件或要求用户确认提交；strict pass 后的 Git 计划仍由 Update-Spec disposition 和 `trellis-push` owner 生成。
+Check-All 不新增 direct Git 摘要或 Git 计划；这些仍由 Update-Spec 与 Push 所有。`[上线后验证]` 交给 Push 风险摘要和既有 `trellis-release` / `release.md`。

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

@@ -33,7 +33,7 @@ description: "按确认的精确文件范围提交普通变更或完成已就绪
 
 除 auto-loop 内部 `commit-only` 外，普通 push 或用户 `commit-only` 已经构成明确 Git 意图。本 skill 在读取 Git 提交计划前只记录当前可用的完成链证据，不补跑、不切换阶段，也不新增确认：
 
-- Check-All：根据当前标准报告与实际 diff 标记为 `通过`、`通过（已接受风险）`、`未运行`、`已失效`、`存在未处置 findings`、`blocked` 或 `部分验证`。剩余 `CHK-*` 与 `FBK-*` 均为 0 时标记为 `通过`；所有剩余问题都有当前有效的用户风险接受时标记为 `通过（已接受风险）`，并保留问题 ID 与严重度。没有可验证的当前报告时使用 `未运行`，不得从历史消息、摘要或 dirty 状态猜测通过或风险接受。
+- Check-All：根据当前标准报告与实际 diff 标记为 `通过`、`通过（已接受风险）`、`未运行`、`已失效`、`存在未处置 findings`、`blocked` 或 `部分验证`。剩余 `CHK-*` 与 `FBK-*` 均为 0 时标记为 `通过`；所有剩余问题都有当前有效的用户风险接受时标记为 `通过（已接受风险）`，并保留问题 ID 与严重度。`[上线后验证]` 不改变 Check-All 的通过状态，但必须作为非阻断风险保留到计划并交给既有 `trellis-release` / `release.md` 流程。没有可验证的当前报告时使用 `未运行`，不得从历史消息、摘要或 dirty 状态猜测通过或风险接受。
 - Update-Spec：根据当前 `spec_update_result` 与实际 diff 标记为 `no-op`、`written`、`needs-review`、`未运行` 或 `已失效`。结果缺失或无法证明仍适用于当前 diff 时使用 `未运行` / `已失效`。
 
 上述状态只进入 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` 不反向补做上游阶段。

package/enhancements/0.6/.agents/skills/trellis-push/references/completed-task-recovery.md

@@ -4,14 +4,14 @@
 
 ## Evidence
 
-固定当前任务路径与 `task.json`，读取文件级任务状态、当前分支、upstream、`HEAD`、`@{u}..HEAD` 的提交消息与文件集合，以及 `python3 ./.trellis/scripts/auto_loop.py status --verbose`。所有恢复都必须验证 exact task、最终 progress、`completedAt`、分支和提交归属；progress 文本不能替代 runtime 或 Git 证据。
+固定当前任务路径与 `task.json`，读取文件级任务状态、当前分支、upstream、`HEAD`、`@{u}..HEAD` 的提交消息与文件集合，以及 `python3 ./.trellis/scripts/auto_loop.py status --verbose`。所有恢复都必须验证 exact task、最终 progress、`status=completed`、分支和提交归属；缺失 `completedAt` 只记为待归档补写的审计元数据，不单独阻断恢复。progress 文本不能替代 runtime 或 Git 证据。
 
 ## Outcomes
 
 按以下优先级只返回一个结果：
 
 1. **显式 finish-work，auto-loop**：健康的终态或 recent auto-loop run 的 `pending_archive.tasks_awaiting_archive` 精确包含当前任务，记录的本地提交仍可验证，且任务 dirty 仅为 runner 在提交后写入的 `<task-dir>/task.json` progress/lifecycle bookkeeping。停止 Push，不得把该本地完成态改成普通远端 push。
-2. **任务记录 commit + push 恢复计划**：没有有效 auto-loop handoff；当前任务 exact files 仍 dirty，`task.json` 已包含合法最终 progress、`status=completed` 与 `completedAt`，且文件集合可由首次确认或重新确认闭合。不得重复 helper 写入或业务提交。
+2. **任务记录 commit + push 恢复计划**：没有有效 auto-loop handoff；当前任务 exact files 仍 dirty，`task.json` 已包含合法最终 progress 与 `status=completed`，且文件集合可由首次确认或重新确认闭合。缺失 `completedAt` 时不得重复 helper 写入，由后续 archive 补写；不得重复业务提交。
 3. **任务记录 push-only 恢复计划**：当前任务目录 clean；upstream 存在；`@{u}..HEAD` 中存在消息、exact file set 和完成态均可归属的任务记录 commit。只推送该已存在提交，不创建新 commit。
 4. **显式 finish-work，普通已同步**：当前任务目录 clean；upstream 存在；`@{u}..HEAD` 没有提交修改当前任务。普通任务记录已经同步，不再执行 Push。
 5. **阻断**：runtime 与 Git 矛盾、auto-loop marker 无健康 handoff、缺少普通路径 upstream、任务 dirty 超出 exact files、未知 ahead 修改任务，或提交消息/文件集合/分支无法闭合。报告具体证据缺口，不 push、不归档，也不猜测完成来源。

package/enhancements/0.6/.agents/skills/trellis-push/references/output-templates.md

@@ -56,7 +56,7 @@
 - 超过 8 个时按目录归组，最多 12 行；用户要求展开时展示同一 exact set。
 - 顶部仓库/commit/file 总数包含独立任务记录提交所在 Git root、该提交及其 exact files；任务记录文件使用相同的 8 文件展示阈值和展开规则。
 - 保留未提交的变更始终逐项标注 Git 状态；真正风险在独立“风险”区逐项展示。
-- 完成链证据始终显示当前状态，但不重复 Check-All 报告或 Spec review 正文；`未运行`、`已失效`、任一未处置 `CHK-*` / `FBK-*`、blocked、部分验证或 `needs-review` 同时计入风险区。已接受风险的问题也必须按 ID、严重度和影响进入风险区，但不得改标为阻断 finding。
+- 完成链证据始终显示当前状态，但不重复 Check-All 报告或 Spec review 正文；`未运行`、`已失效`、任一未处置 `CHK-*` / `FBK-*`、blocked、部分验证或 `needs-review` 同时计入风险区。已接受风险的问题也必须按 ID、严重度和影响进入风险区，但不得改标为阻断 finding。`[上线后验证]` 作为非阻断风险逐项保留动作、环境/责任边界和预期结果，不改变 Check-All 状态，并注明由既有 `trellis-release` / `release.md` 流程承接。
 - 无活动 task、untracked 或 `commit-only` 时省略进度动作。
 - 不重复展示检查结果、规范复核、归档或其他阶段的详细信息。
 - 生成前无法确定的内容和增删行写“生成后计算”，不得填预测值。

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

@@ -202,7 +202,7 @@ helper 写入规则：保留另一个 target 的 runtime 决策和偏好；覆
 | `inline check-all` | `Skill({skill: "trellis-check-all"})` |
 | `subagent check-all` | 读取 catalog 当前平台条目，只调用 `checkAll.target` 声明的专用 audit-only `trellis-check-all` 角色，并按 `checkAll.launch` 启动；subagent 只返回 `CHK-*` / `FBK-*` / `DOC-*` 候选，不写文件。目标缺失、host 未发现或资格不成立时停止并请用户改选 inline；禁止通用 agent 与 `trellis-check` fallback |
 
-implement 路由只决定执行位置，不拥有实现后的停止策略。无论 inline 或 subagent，focused validation 完成后都必须返回 workflow Phase 2.1 的 completion contract；由该 owner 处理 auto-loop、用户显式继续/暂缓、已有 hold 和默认立即 Check-All 的优先级。
+implement 路由只决定执行位置，不拥有实现后的停止策略。无论 inline 或 subagent，focused validation 完成后都必须返回 workflow Phase 2.1 的 completion contract，并在当前回合实际执行该 owner 解析出的 Pre-Check action：auto-loop、用户显式继续/暂缓和已有 hold 按 owner 结果处理；默认分支必须立即进入 `trellis-route(target=check)`。不得先询问是否运行 Check-All，也不得把 Check-All 作为可选下一步后结束回合。
 
 ### 平台 Dispatch Catalog
 
@@ -226,7 +226,7 @@ Active task: <task path from task.py current>
 必须：
 1. 读取 <task>/check.jsonl 及其列出的文件，再读取 prd.md、design.md（若存在）、implement.md（若存在）。
 2. 读取并遵循本地 trellis-check-all/SKILL.md；完成三件套实现、实现假设、完整性与规范三个维度。
-3. 先按本地 fallback findings 规则判定 `CHK-*` / `FBK-*`，再为两类问题分配 P0/P1/P2；已声明的兜底契约只影响证据和严重度，不改变 `FBK-*` 归属。具备具体位置、可达场景和问题证据时返回 `FBK-*`，不要求异常已实际发生；保护收益和验证方式属于报告完整度，缺少验证环境时保留 ID 并标记部分验证。泛化建议不报告。低风险事实漂移使用 `DOC-*` 候选单独返回。
+3. 先按本地 fallback findings 规则判定 `CHK-*` / `FBK-*`，再为两类问题分配 P0/P1/P2；已声明的兜底契约只影响证据和严重度，不改变 `FBK-*` 归属。具备具体位置、可达场景和问题证据时返回 `FBK-*`，不要求异常已实际发生；保护收益和验证方式属于报告完整度。提交前应完成但证据不足时标记阻断型部分验证；本质依赖部署后、生产环境或外部系统的验收返回 `[上线后验证]`，不得执行且不得误标为阻断。泛化建议不报告。低风险事实漂移使用 `DOC-*` 候选单独返回。
 4. 只读审查；禁止编辑、写文件、补测试或自修复。Step 3 只复用 trellis-check 的检查清单，忽略其自动修复指令；`DOC-*` 也只能返回候选，由主会话按 Check-All 规则决定是否写入。
 5. 真正阻塞条件返回主会话，不替用户选择业务行为或修复范围。
 

package/enhancements/0.6/.agents/skills/trellis-route/references/check-all-agent-body.md

@@ -8,6 +8,8 @@ You are the dedicated audit-only `trellis-check-all` agent for {{PLATFORM_ID}}.
 - Classify findings by root-cause nature before severity: return main-path issues as stable `CHK-*` items, fallback-path issues as stable `FBK-*` items, and low-risk factual drift as `DOC-*` candidates.
 - Assign P0/P1/P2 to both `CHK-*` and `FBK-*` after classification. An explicit fallback contract strengthens evidence and severity but does not change a fallback-path root cause into `CHK-*`.
 - Return `FBK-*` when there is a concrete location, reachable failure or abnormal scenario, and evidence that protection is missing, wrong, bypassed, or over-degraded. Actual production or test occurrence is not required. Report protection benefit and a verification method when available; keep the `FBK-*` ID when verification is partial, and state the gap. Do not report generic robustness preferences.
+- Distinguish blocking partial verification, which is required for the current code conclusion and should be completed before commit, from `[上线后验证]` post-release verification that is only safe after deployment or in production/external systems. The latter must remain visible with action, environment or owner boundary, and expected result, but must not block strict pass.
+- Never execute production or external-system operations. Do not label a locally reproducible, static, test-environment, or no-side-effect check as post-release verification merely because it has not run.
 - You may read files, search, and run verification commands that do not write business state.
 - For Maven projects, you may only run `python3 ./.trellis/scripts/maven_verify.py check ...` to validate existing evidence. Do not run `plan`, `run`, `mvn`, `mvnw`, or any goal that may write `target/`, the local repository, or caches.
 - Do not edit, create, remove, format, or otherwise modify source, tests, configuration, specs, task artifacts, or generated files.
@@ -23,4 +25,4 @@ The first dispatch line must be `Active task: <path>` for task work or `Untracke
 
 ## Return
 
-Return the complete Check-All report, `check_profile`, all `CHK-*` findings, all `FBK-*` findings, all `DOC-*` candidates, verification evidence, blocked checks, and residual risk. Any remaining `CHK-*` or `FBK-*` blocks strict pass. The main session may separately record explicit user risk acceptance for current findings; do not infer, grant, or erase that acceptance yourself. Do not output a commit or push plan.
+Return the complete Check-All report, `check_profile`, all `CHK-*` findings, all `FBK-*` findings, all `DOC-*` candidates, verification evidence, blocking partial verification, `[上线后验证]` items, blocked checks, and residual risk. Any remaining `CHK-*` or `FBK-*`, blocker, or blocking partial verification blocks strict pass; properly classified post-release verification does not. The main session may separately record explicit user risk acceptance for current findings; do not infer, grant, or erase that acceptance yourself. Do not output a commit or push plan.

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

@@ -44,7 +44,7 @@ description: "统一 Check-All：按 requested/effective depth 路由 light/full
 3. **分类先于严重度**：读取 `references/fallback-findings.md`；主路径错误和非兜底契约违背进入 `CHK-*`，fail-closed、异常输入、失败降级和防御性保护缺口进入 `FBK-*`。契约证据影响严重度，不改变兜底根因归属。
 4. **处置只确认一次**：统一报告后选择 `CHK-*` / `FBK-*` 修复范围或接受风险；`修复全部` 覆盖两类，接受风险不得隐藏发现。
 5. **委托不改边界**：复用 `trellis-check` 的清单和验证方法，忽略其直接修复指令。
-6. **真正阻塞才中途暂停**：只有业务规划冲突、后续验证前提失效、生产或外部副作用、破坏性操作风险时提前停止。
+6. **真正阻塞才中途暂停**：业务规划冲突、前提失效，或当前结论必需验证涉及未授权生产/外部/破坏性副作用时暂停；发布后验收只记 `[上线后验证]`，不执行、不阻断。
 
 中途停止时也要使用统一问题模型，报告已完成范围和阻塞原因；只询问解除阻塞所需的业务或安全决策。
 
@@ -115,7 +115,7 @@ check_profile:
 - 自动修复的 `DOC-*` 内容；
 - 剩余 `CHK-*` 主路径问题与 `FBK-*` 兜底问题；
 - 每个剩余问题的未处置或已接受风险状态；
-- 已执行验证和未覆盖风险；
+- 已执行验证、未覆盖风险和 `[上线后验证]`；
 - 与当前结论匹配的唯一下一步。
 
 ---

package/enhancements/0.6/.claude/skills/trellis-check-all/references/depth-routing.md

@@ -55,7 +55,7 @@ untracked 必须为 `stage=check`，只读个人 check 偏好，不创建 task-s
 2. validated auto-loop action 的 `requested_check_depth`；
 3. 默认 `auto`。
 
-显式意图按语义识别：`简单检查`、`轻量检查`、`light check` 表示 light；`全面检查`、`全量检查`、`最终检查`、`提交前检查`、`full check` 表示 full。同一请求出现多次切换时，以最后一次明确表达为准。单独说 `check` / `check-all` 只是调用统一入口，不自动等同 full。
+深度按最后一次明确表达：`简单检查` / `轻量检查` / `light check` 为 light；`全面检查` / `全量检查` / `full check` 为 full。`check` / `check-all` / `最终检查` / `提交前检查` 只调用统一入口并保持 `requested_depth=auto`；提交不等同 full。
 
 历史 auto-loop 缺少深度字段时 runner 返回 `full`。文件数、diff 行数或“看起来简单”不能单独决定 light。
 
@@ -87,8 +87,8 @@ hard-full 只看行为契约变化和影响面是否闭合。文件载体或主
 - 公共 API、CLI、schema、持久化状态、协议字段、缓存、迁移或历史数据兼容发生行为变化；
 - 权限、安全、资金、并发、时序、状态机、回滚、发布或 Git 控制门禁发生行为变化；
 - 改动跨越独立行为边界，或直接引用点、状态传播或回归路径无法完整列出；
-- 正在重检既有 full `CHK-*` / `FBK-*` 修复结果；
 - light 执行中发现未知 dirty path、真实影响面扩大或关键验证缺口。
+- 计划基线、相关契约或既有验证证据已经变化，导致原 full 证据失效或无法证明仍覆盖当前 diff。
 
 无法确认是否改变行为契约或影响面是否闭合时，使用 `effective=full`、`confidence=fallback-full`。
 
@@ -98,6 +98,8 @@ hard-full 只看行为契约变化和影响面是否闭合。文件载体或主
 - 无行为性 hard-full 信号；
 - 受影响规划条目、直接引用点、状态传播和回归路径可穷举；
 - 局部行为修改时，直接引用点和回归路径可穷举，并有可运行的定向验证；无行为变化时，仅涉及注释、错别字、排版、解释文字、示例或机械投影同步；
-- 不在既有 full 修复/重检链中。
+- 承接既有 full 报告时，原 finding、修复路径、引用/回归和定向证据可闭合。
 
-light 执行中命中 hard-full 时，立即单向升级 full 并补齐所有适用维度；同一修复/重检循环内 full 不得降级。
+跨轮局部修复可重新选择 light；结束任务、提交或已有 full 报告不触发 full。既有 full 证据仍覆盖当前 diff且后续修改已定向重检时可复用。仅显式 full、hard-full、范围不闭合、未知 dirty、基线/契约变化或证据失效时重跑 full。
+
+light 执行中命中 hard-full 时，立即单向升级 full 并补齐所有适用维度；同一次 Check-All 执行中一旦升级为 full，不得降回 light。

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

@@ -47,7 +47,7 @@
 
 - **保护收益**：说明修复后避免的错误放行、数据损害、权限扩大、失控失败或诊断盲区。
 - **验证方式**：优先给出可执行测试、命令、故障注入或明确手动步骤。
-- 缺少环境、工具或权限时仍保留 `FBK-*` ID，验证标记 `部分验证` 并写明缺口；部分验证继续阻断 strict pass。
+- 环境、工具或权限不足仍保留 `FBK-*` ID：提交前证据缺口用阻断型 `部分验证`；仅部署后/生产/外部可完成时用非阻断 `[上线后验证]`。细则见 reporting reference。
 
 ---
 
@@ -69,7 +69,7 @@
 - `CHK-*` 与 `FBK-*` 独立编号，修复/重检循环保留原 ID；两类都按实际影响分配 P0/P1/P2。
 - `修复全部` 覆盖两类问题；精确修复可混合 ID，例如 `修复 CHK-001,FBK-002`。
 - 用户可以明确接受当前报告中任一 `CHK-*` 或 `FBK-*` 的风险而不修复；问题仍保留原通道、严重度和证据。
-- 风险接受须唯一对应当前报告 ID；P0 必须逐项写出精确 ID。证据、diff 或严重度变化后接受失效。
+- 接受当前报告全部风险覆盖全部 `CHK-*` / `FBK-*`，包括 P0，无固定句式；部分接受须唯一定位。报告或范围不清才追问；证据、diff、内容或严重度变化后失效。
 - `strict pass` 仍要求剩余 `CHK-*` 与 `FBK-*` 均为 0；全部剩余问题被有效接受且无阻塞、部分验证或其它实质风险时，使用“已接受风险通过”。
-- 只有未处置的 `CHK-*` 或 `FBK-*` 阻断交互完成链。validated auto-loop 不能代表用户接受风险，仍须两类问题为 0 才能 `record ok`。
+- 未处置 `CHK-*` / `FBK-*`、阻断型部分验证或阻塞会阻断；`[上线后验证]` 不阻断。auto-loop 不得接受风险，须两类问题为 0 且无阻断型部分验证才能 `record ok`。
 - `仅保留报告` 只停止修复，不构成风险接受或通过。

package/enhancements/0.6/.claude/skills/trellis-check-all/references/full-profile.md

@@ -76,7 +76,7 @@ full 提取所有适用条目。每条记录来源位置，实际阅读对应代
 - 确认历史记录的新字段值和 null/零值行为。
 - 确认过滤、聚合和降级查询能处理历史数据。
 - 追踪新字段的写入来源和可靠性。
-- 无可用历史数据环境时标记 `部分验证` 或 `阻塞`，不得标记通过。
+- 无可用历史数据环境时按验证阶段判断：提交前原则上可完成但缺少证据时标记 `部分验证` 或 `阻塞`；本质依赖部署后真实状态时登记 `[上线后验证]`，不得伪报已执行。
 
 ### Dimension D：Data Flow Trace
 
@@ -91,10 +91,11 @@ full 提取所有适用条目。每条记录来源位置，实际阅读对应代
 
 **Trigger**：Dimension A-D 任一适用。
 
-- 检查关键假设是否已有可运行的自动化测试或明确手动验证。
+- 自动化测试优先；可重复的手动步骤、静态检查或定向命令也可作为验证证据。
 - 优先覆盖最脆弱的参数名、嵌套结构、历史数据和空值路径。
 - 测试存在时实际运行；未运行不能报告通过。
-- 缺少测试时记录问题，等待用户确认修复范围后再新增测试。
+- 仅缺少自动化测试文件不得生成 `CHK-*`；项目 spec、风险等级或回归概率明确要求自动化覆盖时，缺失测试仍记录问题。
+- 缺少完成当前结论所必需的充分证据时记录 `CHK-*`，等待用户确认修复范围后再补充验证或测试。
 
 发现假设错误时写入统一问题集合并继续其它可执行检查。只有该错误让后续检查前提失效时，才按“真正阻塞”规则暂停。
 
@@ -118,7 +119,7 @@ full 提取所有适用条目。每条记录来源位置，实际阅读对应代
 - “Report and Fix”；
 - 任何要求检查 agent 直接编辑、补测试或反复修到通过的语句。
 
-验证失败时记录命令、退出状态和关键错误到统一问题集合，继续其它独立验证。可能写业务数据或外部系统的验证不直接运行，按真正阻塞规则处理。
+验证失败时记录命令、退出状态和关键错误到统一问题集合，继续其它独立验证。可能写业务数据或外部系统的验证不直接运行：当前结论所必需且提交前原则上可完成时标记阻断型 `部分验证` 或 `阻塞`；本质依赖部署后、生产环境或真实外部状态时登记 `[上线后验证]`，不得自动执行。
 
 ### Maven Evidence 复用
 
@@ -148,3 +149,5 @@ Full 通过必须同时满足：
 - 项目规范、复用、依赖、同层一致性和验证命令已覆盖实际变更范围；
 - strict pass：无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险；或
 - 已接受风险通过：所有剩余 `CHK-*` / `FBK-*` 都有当前有效的用户风险接受，且无阻塞、无部分验证、无未接受的实质剩余风险。
+
+strict pass 或已接受风险通过可以与已明确登记的 `[上线后验证]` 并存；该标签只表示发布阶段仍需执行的验收，不表示当前已经验证。

package/enhancements/0.6/.claude/skills/trellis-check-all/references/light-profile.md

@@ -12,7 +12,7 @@ Light 是局部且可穷举的检查，不是“少看一点”的检查。只
 - 受影响规划条目、直接引用点、状态传播和回归路径能完整列出；
 - 没有行为性 hard-full 信号，载体名称不得单独触发升级；
 - 有定向验证，或变更确定不改变行为；
-- 不是 full 修复/重检链的一部分。
+- 承接既有 full 报告的局部修复时，原 finding、修复路径、直接引用点和回归路径均可闭合，且定向验证足以覆盖后续 diff。
 
 执行中发现任一边界不成立，记录升级原因，切换到 `references/full-profile.md`。
 
@@ -41,12 +41,14 @@ untracked 上下文没有 task artifacts，本维度标记 `N/A`，不得根据
 | --- | --- | --- |
 | API Contract | 新增或修改 API 调用、请求参数或响应解析 | 读取实际 Handler/DTO/Schema 或同模式调用，确认字段名、类型、默认值和错误响应 |
 | Component Context | Modal、Drawer、Tab 或条件渲染容器内修改有状态组件 | 确认销毁/保留、受控值、初始化值和重置行为 |
-| Data History | 新增、修改或重新解释持久化字段 | 确认 null/零值/历史记录降级；无环境证据标记 `部分验证` |
+| Data History | 新增、修改或重新解释持久化字段 | 确认 null/零值/历史记录降级；按验证阶段区分阻断型 `部分验证` 与 `[上线后验证]` |
 | Data Flow Trace | 变更跨越 UI/API/Service/Storage 中两个或更多边界 | 连起来核对参数名、类型、嵌套层级和错误传播 |
-| Verification Tests | A-D 任一适用 | 找到并运行定向测试；缺少测试记录为 `CHK-*` |
+| Verification Tests | A-D 任一适用 | 自动化测试优先；也可使用可重复的手动步骤、静态检查或定向命令覆盖关键假设 |
 
 未触发的 Dimension 标记 `N/A`。
 
+仅缺少自动化测试文件不得生成 `CHK-*`。已有测试时应实际运行；项目 spec、风险等级或回归概率明确要求自动化覆盖时，缺失测试仍记录问题。否则只有缺少完成当前结论所必需的充分证据时才记录 `CHK-*`，模糊的“手动看过”不构成证据。
+
 ---
 
 ## 维度 3：完整性、规范与项目验证
@@ -81,4 +83,4 @@ Light 通过必须同时满足：
 - strict pass：无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险；或
 - 已接受风险通过：所有剩余 `CHK-*` / `FBK-*` 都有当前有效的用户风险接受，且无阻塞、无部分验证、无未接受的实质剩余风险。
 
-存在未覆盖但不影响局部结论的内容时，必须在“未覆盖与风险”中说明。
+存在未覆盖但不影响局部结论的内容时，必须在“未覆盖与风险”中说明。只有部署后、生产环境或外部系统中才能安全完成的事项使用 `[上线后验证]`；它可以与通过结论并存，但不得伪报已执行。

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

@@ -40,24 +40,30 @@
 | 影响 | 加粗字段 | 当前缺口的用户、数据、安全或工程影响 |
 | 保护收益 | 加粗字段 | 修复后恢复或新增的明确保护结果；属于报告完整度，不得省略或并入建议 |
 | 建议 | 加粗字段 | 推荐修复方式，不在检查阶段执行 |
-| 验证 | 加粗字段 | 修复后的测试、故障注入、命令或手动验证步骤；受环境限制时标记 `部分验证` |
+| 验证 | 加粗字段 | 修复后的测试、故障注入、命令或手动验证步骤；受环境限制时按验证阶段标记阻断型 `部分验证` 或 `[上线后验证]` |
 
-`FBK-*` 分类只由具体位置、可达场景和问题证据三项硬准入决定。保护收益与验证方式属于报告完整度；缺少环境时保留 ID 和已有证据，标记 `部分验证`，不得伪报 strict pass。
+`FBK-*` 分类只看具体位置、可达场景和问题证据；环境不足保留 ID。保护收益与验证方式仍为报告字段。
 
-`CHK-*` 与 `FBK-*` 分开编号。同一根因的多个位置合并到一个问题；严重度排序只在各自通道内部生效，每个通道内部按 `P0 -> P1 -> P2` 展示，但不得因此重排已经分配的 ID。跨通道报告顺序固定为完整 `CHK-*` 区块在前、完整 `FBK-*` 区块在后；禁止因 FBK 严重度更高、分类时先判断 FBK、发现先后或 ID 分配时机而 FBK-first、交错两类问题或省略分区标题。新根因使用对应通道的下一个 ID。每个问题的处置状态默认为待处理且不加标签，只有 `已接受风险` 才在条目标题行末尾追加 `` `[已接受风险]` `` 标签。`仅保留报告` 不改变处置状态，相关问题仍不加标签。处置状态不改变 ID、通道和严重度。
+`CHK-*` 与 `FBK-*` 分开编号，同根因位置合并。严重度排序只在各自通道内部生效，每个通道内部按 `P0 -> P1 -> P2` 展示且不重排 ID。跨通道报告顺序固定为完整 `CHK-*` 区块在前、完整 `FBK-*` 区块在后；禁止因 FBK 严重度更高、分类时先判断 FBK、发现先后或 ID 分配时机而 FBK-first 或交错。新根因递增编号。默认待处理无标签；仅 `已接受风险` 在标题末尾加 `` `[已接受风险]` ``。`仅保留报告` 不改变处置，处置不改变 ID、通道或严重度。
 
 ## 风险接受
 
-风险接受是用户对当前报告的显式处置，不是检查器对问题严重度的降级：
+风险接受由用户显式处置，不改变问题严重度：
 
 1. 只有用户可以接受风险；主会话、subagent 和 validated auto-loop 都不得代替用户推断或授权。
-2. 接受必须唯一对应当前报告的问题 ID。用户可以写 `接受风险 CHK-001,FBK-002 并继续`；当前报告只有一个候选时，“这个问题”“不管这个”等明确指代可以解析为该 ID。P0 必须逐项写出精确 ID，不接受 `接受全部剩余风险`。
+2. 按当前报告和语义解析：“接受当前报告全部风险”“全部接受”“这些风险都接受”等覆盖全部 `CHK-*` / `FBK-*`，包括 P0，无固定句式或逐项 ID。部分接受须唯一定位子集；报告版本或范围不清时才追问。
 3. 接受只绑定当前问题证据与实际 diff。受影响代码、契约、验证结果、问题内容或严重度变化后，原接受立即失效，问题恢复为待处理并移除标题行末尾的 `` `[已接受风险]` `` 标签。
 4. 已接受问题继续完整展示证据、影响、建议和验证，标题行末尾追加 `` `[已接受风险]` `` 标签；不得删除条目、改列 `DOC-*` 或伪报已修复。
-5. `strict pass` 只用于剩余 `CHK-*` / `FBK-*` 均为 0。所有剩余问题均已被有效接受，且无 blocked、无部分验证、无未接受的实质剩余风险时，结论为 `通过·已接受风险`。
-6. blocked、部分验证和无法唯一对应到当前问题 ID 的实质剩余风险不是 `CHK-*` / `FBK-*` 处置状态，不能借风险接受绕过。
+5. `strict pass` 只用于剩余 `CHK-*` / `FBK-*` 均为 0。所有剩余问题均已被有效接受，且无 blocked、无阻断型部分验证、无未接受的实质剩余风险时，结论为 `通过·已接受风险`。
+6. blocked、阻断型部分验证和无法唯一对应当前报告范围的实质剩余风险不是 `CHK-*` / `FBK-*` 处置状态，不能借风险接受绕过；`[上线后验证]` 不属于风险接受对象。
 7. `仅保留报告` 表示停止处置并等待，不等于接受风险；只有带明确接受语义的用户回复才改变问题处置状态。
 
+## 验证阶段
+
+- `部分验证`：当前结论必需、提交前可完成但证据不足；阻断 strict pass、Update-Spec 和 direct Git。
+- `[上线后验证]`：仅部署后、生产或外部系统可安全验收；在“未覆盖与风险”写动作、责任边界和预期结果。它不属于维度状态，不阻断 strict pass、Update-Spec 或 direct Git；strict pass 可以与其并存。
+- 本地 fixture、测试环境、静态契约或无副作用命令可完成的检查不得延期为 `[上线后验证]`。Check-All 不得执行生产或外部系统操作，也不得伪报通过。
+
 ---
 
 ## 输出：统一检查报告
@@ -121,14 +127,14 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 
 ### 未覆盖与风险
 
-- [<部分验证/阻塞/N/A>] <说明>
+- [<部分验证/上线后验证/阻塞/N/A>] <说明；上线后验证写动作、责任边界和预期结果>
 
 ### 修复批次
 
 - **批次 1**：<CHK/FBK 问题 ID> · <修复目标>
 - **修复后**：定向验证 -> Check-All 重检
 
-操作：`修复全部`、`修复 CHK-001,FBK-002`、`接受风险 CHK-001,FBK-002 并继续`、`仅保留报告`
+操作：`修复全部`、`修复 CHK-001,FBK-002`、`接受当前报告全部风险并继续`、`接受风险 CHK-001,FBK-002 并继续`、`仅保留报告`
 
 ### 下一步
 
@@ -137,7 +143,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 
 展示规则：
 
-- 报告头部的“工作/范围/画像/结论”与“修复批次”内的行必须使用 `- ` 列表项。这些行在 Markdown 段落内会被折叠成一段，不得改回裸段落行，也不得依赖行尾空格实现换行。
+- 报告头部“工作/范围/画像/结论”和“修复批次”必须使用 `- ` 列表项，不得改为裸行或依赖行尾空格。
 - 每个问题必须由一个四级标题承载，固定顺序为 `` #### `<ID>` `<严重度>` `<来源>` <标题> ``。仅 `已接受风险` 的问题在标题末尾追加 `` `[已接受风险]` ``；待处理不加标签。`来源` 与 `处置` 都不再单独占行。
 - 不得改用 `- [ ]` / `- [x]` 列表项承载问题条目。终端渲染器会把松散列表压平，相邻条目会糊成一段无法分辨；只有标题这类块级元素才能稳定产生视觉分隔。修复状态由“修复结果”表格表达，不靠 checkbox。
 - 条目内部的字段一律写成 `- **<字段>**：<值>` 加粗标签列表项。字段值折行后回到左边界，加粗标签是唯一能定位字段起点的锚，裸标签会淹没在正文里。
@@ -147,7 +153,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 - 同时存在两类问题时，`### 主路径问题` 及其全部 `CHK-*` 必须完整出现在 `### 兜底问题` 及其全部 `FBK-*` 之前；不得按全局严重度排序反转或交错两个区块。
 - 存在未处置 `CHK-*` 或 `FBK-*` 时展示“修复批次”，并只在报告末尾提供一次处置选择，不再逐项提问。
 - `修复全部` 始终覆盖全部 `CHK-*` 与 `FBK-*`；精确修复可以混合两类 ID。
-- 风险接受可以混合两类 ID；只有全部剩余问题都已有效接受时才形成“通过·已接受风险”。
+- 风险接受可混合两类 ID；“接受当前报告全部风险”覆盖全部剩余问题，包括 P0，无固定句式。全部有效接受后才形成“通过·已接受风险”。
 - `仅保留报告` 只表示停止处置，不改变未通过结论或剩余风险。
 - interactive 标准报告必须以“下一步”段结束；停止等待不等于省略引导。
 - 独立 `CHK-*` 或 `FBK-*` 不得因数量多而静默省略；先合并同根因重复项，再完整列出剩余项。
@@ -164,7 +170,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 2. 修复过程中不对每个问题重复确认。
 3. 新增业务歧义、破坏性风险或范围扩张时才暂停，并一次性说明受影响问题。
 4. 完成定向验证后复用当前 check route 重新执行 Check-All。
-5. 原 `CHK-*` / `FBK-*` 沿用各自 ID；新根因在对应通道继续递增编号。上次 `effective_depth=full` 时，本次最小深度为 full。
+5. 原 ID 沿用，新根因递增。后续按当前 diff 选深度：原 finding、修复路径、引用/回归和定向证据均闭合时可 light；范围扩大、契约/基线变化、未知 dirty 或证据失效时 full。
 
 修复完成后输出：
 
@@ -192,7 +198,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 
 检查通过后的动作由下方 `Interactive Post-Check Stop Gate` 判断：普通交互停止等待，符合 direct Git strict pass 或已接受风险通过条件时同轮进入 Phase 3.3 `trellis-update-spec`，再到 Phase 3.4 `trellis-push`。仍有未处置 `CHK-*` 或 `FBK-*` 时停留在处置/重检循环。
 
-untracked helper 不记录 Check-All 证据或风险接受。普通 strict pass / 已接受风险通过但尚未继续时保持 `stage=check`；只有 direct Git 同轮继续或用户后续明确继续时才 `advance --stage spec`。有未处置 `CHK-*`、`FBK-*`、部分验证、阻塞或报告后的新编辑时，先 `advance --stage implement` 再返回实现。
+untracked helper 不存检查证据或风险接受。普通通过后保持 `stage=check`；direct Git 同轮继续或用户明确继续才 `advance --stage spec`。未处置 `CHK-*` / `FBK-*`、阻断型部分验证、阻塞或新编辑先 `advance --stage implement`；仅 `[上线后验证]` 不回退。
 
 ---
 
@@ -202,8 +208,8 @@ validated auto-loop 复用相同的画像、profile、`DOC-*` 通道和问题模
 
 - 有 `DOC-*` 且可自动修复：主会话先应用并验证；只有当前任务 `implement.md` / `brief.md` 的实际变化追加精确 `--doc-remediation-file`，源码注释等其它 DOC 改动不得传该参数；随后重算 diff、范围和画像，再决定最终 `ok|failed|blocked`。
 - 有剩余 `CHK-*` 或 `FBK-*`：向 runner `record --result failed --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含最高严重度、两类问题 ID、根因、受影响文件和已自动修复的 `DOC-*`。validated auto-loop 不创建也不复用 interactive 风险接受。
-- 真正需要用户产品决策、越权、生产副作用或破坏性安全决策：使用同样深度字段 `record --result blocked`，随后按 runner 状态停止。
-- 无剩余 `CHK-*` 且无剩余 `FBK-*`：`record --result ok --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含自动修复数量；只有两类问题都为 0 才能进入通过路径。
+- 产品决策、越权、提交前生产副作用授权或破坏性决策：`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 授权或队列行为。
 
@@ -216,16 +222,16 @@ subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `chec
 非 validated auto-loop 先输出完整标准报告，再在本 Gate 内按以下顺序分流：
 
 1. 只从当前完成链证据识别 direct Git intent：触发检查的最新用户消息明确请求普通 push 或用户主动 `commit-only`；或者 Check-All 已因该 Git 请求报告并停止后，用户在当前报告上明确接受风险并要求继续。不得从任务标题、摘要、dirty 状态、无关历史或 auto-loop 内部 action 推断。
-2. direct Git 在以下任一条件成立时可以继续：Check-All strict pass；或全部剩余 `CHK-*` / `FBK-*` 都有当前有效的用户风险接受。两条路径还必须无阻塞、无部分验证、无未接受的实质剩余风险。允许存在已成功验证的 `DOC-*` 自动修复；标准报告输出后，同一轮进入 Phase 3.3 `trellis-update-spec`；`no-op|written` 再由其加载 `trellis-push`，`needs-review` 停止。
-3. 未处置 `CHK-*` / `FBK-*`、blocked、部分验证或未接受的实质剩余风险均不满足条件：输出标准报告并停止，不运行 Update-Spec，也不生成 Git 计划。原始 Git 请求不授权自动修复普通问题或替用户接受风险。
+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 检查保持原行为：报告后立即停止并等待用户选择。
 
 ### 交互式下一步引导
 
 所有 interactive 标准报告都必须在末尾输出 `### 下一步`，并按以下首个命中分支给出一个明确主动作：
 
-1. 有未处置 `CHK-*` 或 `FBK-*`：提示用户回复 `修复全部`、混合精确问题 ID、`接受风险 <问题 ID> 并继续` 或 `仅保留报告`；不得重复提出逐项确认。
-2. 有 blocked、部分验证或实质剩余风险：指出解除阻塞所需的精确决策、授权或验证，以及完成后重新运行 Check-All；涉及生产、外部系统或破坏性副作用时只引导用户授权，不自行执行。
+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` 生成提交计划。
 
@@ -237,8 +243,8 @@ subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `chec
 - `CHK-*` 主路径问题和 `FBK-*` 兜底问题的证据、影响与验证；
 - `DOC-*` 自动修复内容和验证；
 - 已执行验证及结果；
-- 未覆盖验证和剩余风险；
+- 未覆盖验证、`[上线后验证]` 和剩余风险；
 - 总体结论；
 - 与当前结论匹配的唯一主动作引导；有未处置 `CHK-*` 或 `FBK-*` 时是一次修复或风险接受选择，部分验证/阻塞时是补充决策或验证，通过时是 Phase 3.3 / Phase 3.4 指向。
 
-Check-All 不新增 direct Git 专用摘要，也不得自行生成提交计划、commit message、拟提交文件或要求用户确认提交；strict pass 后的 Git 计划仍由 Update-Spec disposition 和 `trellis-push` owner 生成。
+Check-All 不新增 direct Git 摘要或 Git 计划；这些仍由 Update-Spec 与 Push 所有。`[上线后验证]` 交给 Push 风险摘要和既有 `trellis-release` / `release.md`。

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

@@ -33,7 +33,7 @@ description: "按确认的精确文件范围提交普通变更或完成已就绪
 
 除 auto-loop 内部 `commit-only` 外，普通 push 或用户 `commit-only` 已经构成明确 Git 意图。本 skill 在读取 Git 提交计划前只记录当前可用的完成链证据，不补跑、不切换阶段，也不新增确认：
 
-- Check-All：根据当前标准报告与实际 diff 标记为 `通过`、`通过（已接受风险）`、`未运行`、`已失效`、`存在未处置 findings`、`blocked` 或 `部分验证`。剩余 `CHK-*` 与 `FBK-*` 均为 0 时标记为 `通过`；所有剩余问题都有当前有效的用户风险接受时标记为 `通过（已接受风险）`，并保留问题 ID 与严重度。没有可验证的当前报告时使用 `未运行`，不得从历史消息、摘要或 dirty 状态猜测通过或风险接受。
+- Check-All：根据当前标准报告与实际 diff 标记为 `通过`、`通过（已接受风险）`、`未运行`、`已失效`、`存在未处置 findings`、`blocked` 或 `部分验证`。剩余 `CHK-*` 与 `FBK-*` 均为 0 时标记为 `通过`；所有剩余问题都有当前有效的用户风险接受时标记为 `通过（已接受风险）`，并保留问题 ID 与严重度。`[上线后验证]` 不改变 Check-All 的通过状态，但必须作为非阻断风险保留到计划并交给既有 `trellis-release` / `release.md` 流程。没有可验证的当前报告时使用 `未运行`，不得从历史消息、摘要或 dirty 状态猜测通过或风险接受。
 - Update-Spec：根据当前 `spec_update_result` 与实际 diff 标记为 `no-op`、`written`、`needs-review`、`未运行` 或 `已失效`。结果缺失或无法证明仍适用于当前 diff 时使用 `未运行` / `已失效`。
 
 上述状态只进入 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` 不反向补做上游阶段。

package/enhancements/0.6/.claude/skills/trellis-push/references/completed-task-recovery.md

@@ -4,14 +4,14 @@
 
 ## Evidence
 
-固定当前任务路径与 `task.json`，读取文件级任务状态、当前分支、upstream、`HEAD`、`@{u}..HEAD` 的提交消息与文件集合，以及 `python3 ./.trellis/scripts/auto_loop.py status --verbose`。所有恢复都必须验证 exact task、最终 progress、`completedAt`、分支和提交归属；progress 文本不能替代 runtime 或 Git 证据。
+固定当前任务路径与 `task.json`，读取文件级任务状态、当前分支、upstream、`HEAD`、`@{u}..HEAD` 的提交消息与文件集合，以及 `python3 ./.trellis/scripts/auto_loop.py status --verbose`。所有恢复都必须验证 exact task、最终 progress、`status=completed`、分支和提交归属；缺失 `completedAt` 只记为待归档补写的审计元数据，不单独阻断恢复。progress 文本不能替代 runtime 或 Git 证据。
 
 ## Outcomes
 
 按以下优先级只返回一个结果：
 
 1. **显式 finish-work，auto-loop**：健康的终态或 recent auto-loop run 的 `pending_archive.tasks_awaiting_archive` 精确包含当前任务，记录的本地提交仍可验证，且任务 dirty 仅为 runner 在提交后写入的 `<task-dir>/task.json` progress/lifecycle bookkeeping。停止 Push，不得把该本地完成态改成普通远端 push。
-2. **任务记录 commit + push 恢复计划**：没有有效 auto-loop handoff；当前任务 exact files 仍 dirty，`task.json` 已包含合法最终 progress、`status=completed` 与 `completedAt`，且文件集合可由首次确认或重新确认闭合。不得重复 helper 写入或业务提交。
+2. **任务记录 commit + push 恢复计划**：没有有效 auto-loop handoff；当前任务 exact files 仍 dirty，`task.json` 已包含合法最终 progress 与 `status=completed`，且文件集合可由首次确认或重新确认闭合。缺失 `completedAt` 时不得重复 helper 写入，由后续 archive 补写；不得重复业务提交。
 3. **任务记录 push-only 恢复计划**：当前任务目录 clean；upstream 存在；`@{u}..HEAD` 中存在消息、exact file set 和完成态均可归属的任务记录 commit。只推送该已存在提交，不创建新 commit。
 4. **显式 finish-work，普通已同步**：当前任务目录 clean；upstream 存在；`@{u}..HEAD` 没有提交修改当前任务。普通任务记录已经同步，不再执行 Push。
 5. **阻断**：runtime 与 Git 矛盾、auto-loop marker 无健康 handoff、缺少普通路径 upstream、任务 dirty 超出 exact files、未知 ahead 修改任务，或提交消息/文件集合/分支无法闭合。报告具体证据缺口，不 push、不归档，也不猜测完成来源。

package/enhancements/0.6/.claude/skills/trellis-push/references/output-templates.md

@@ -56,7 +56,7 @@
 - 超过 8 个时按目录归组，最多 12 行；用户要求展开时展示同一 exact set。
 - 顶部仓库/commit/file 总数包含独立任务记录提交所在 Git root、该提交及其 exact files；任务记录文件使用相同的 8 文件展示阈值和展开规则。
 - 保留未提交的变更始终逐项标注 Git 状态；真正风险在独立“风险”区逐项展示。
-- 完成链证据始终显示当前状态，但不重复 Check-All 报告或 Spec review 正文；`未运行`、`已失效`、任一未处置 `CHK-*` / `FBK-*`、blocked、部分验证或 `needs-review` 同时计入风险区。已接受风险的问题也必须按 ID、严重度和影响进入风险区，但不得改标为阻断 finding。
+- 完成链证据始终显示当前状态，但不重复 Check-All 报告或 Spec review 正文；`未运行`、`已失效`、任一未处置 `CHK-*` / `FBK-*`、blocked、部分验证或 `needs-review` 同时计入风险区。已接受风险的问题也必须按 ID、严重度和影响进入风险区，但不得改标为阻断 finding。`[上线后验证]` 作为非阻断风险逐项保留动作、环境/责任边界和预期结果，不改变 Check-All 状态，并注明由既有 `trellis-release` / `release.md` 流程承接。
 - 无活动 task、untracked 或 `commit-only` 时省略进度动作。
 - 不重复展示检查结果、规范复核、归档或其他阶段的详细信息。
 - 生成前无法确定的内容和增删行写“生成后计算”，不得填预测值。

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

@@ -202,7 +202,7 @@ helper 写入规则：保留另一个 target 的 runtime 决策和偏好；覆
 | `inline check-all` | `Skill({skill: "trellis-check-all"})` |
 | `subagent check-all` | 读取 catalog 当前平台条目，只调用 `checkAll.target` 声明的专用 audit-only `trellis-check-all` 角色，并按 `checkAll.launch` 启动；subagent 只返回 `CHK-*` / `FBK-*` / `DOC-*` 候选，不写文件。目标缺失、host 未发现或资格不成立时停止并请用户改选 inline；禁止通用 agent 与 `trellis-check` fallback |
 
-implement 路由只决定执行位置，不拥有实现后的停止策略。无论 inline 或 subagent，focused validation 完成后都必须返回 workflow Phase 2.1 的 completion contract；由该 owner 处理 auto-loop、用户显式继续/暂缓、已有 hold 和默认立即 Check-All 的优先级。
+implement 路由只决定执行位置，不拥有实现后的停止策略。无论 inline 或 subagent，focused validation 完成后都必须返回 workflow Phase 2.1 的 completion contract，并在当前回合实际执行该 owner 解析出的 Pre-Check action：auto-loop、用户显式继续/暂缓和已有 hold 按 owner 结果处理；默认分支必须立即进入 `trellis-route(target=check)`。不得先询问是否运行 Check-All，也不得把 Check-All 作为可选下一步后结束回合。
 
 ### 平台 Dispatch Catalog
 
@@ -226,7 +226,7 @@ Active task: <task path from task.py current>
 必须：
 1. 读取 <task>/check.jsonl 及其列出的文件，再读取 prd.md、design.md（若存在）、implement.md（若存在）。
 2. 读取并遵循本地 trellis-check-all/SKILL.md；完成三件套实现、实现假设、完整性与规范三个维度。
-3. 先按本地 fallback findings 规则判定 `CHK-*` / `FBK-*`，再为两类问题分配 P0/P1/P2；已声明的兜底契约只影响证据和严重度，不改变 `FBK-*` 归属。具备具体位置、可达场景和问题证据时返回 `FBK-*`，不要求异常已实际发生；保护收益和验证方式属于报告完整度，缺少验证环境时保留 ID 并标记部分验证。泛化建议不报告。低风险事实漂移使用 `DOC-*` 候选单独返回。
+3. 先按本地 fallback findings 规则判定 `CHK-*` / `FBK-*`，再为两类问题分配 P0/P1/P2；已声明的兜底契约只影响证据和严重度，不改变 `FBK-*` 归属。具备具体位置、可达场景和问题证据时返回 `FBK-*`，不要求异常已实际发生；保护收益和验证方式属于报告完整度。提交前应完成但证据不足时标记阻断型部分验证；本质依赖部署后、生产环境或外部系统的验收返回 `[上线后验证]`，不得执行且不得误标为阻断。泛化建议不报告。低风险事实漂移使用 `DOC-*` 候选单独返回。
 4. 只读审查；禁止编辑、写文件、补测试或自修复。Step 3 只复用 trellis-check 的检查清单，忽略其自动修复指令；`DOC-*` 也只能返回候选，由主会话按 Check-All 规则决定是否写入。
 5. 真正阻塞条件返回主会话，不替用户选择业务行为或修复范围。
 

package/enhancements/0.6/overrides/conflicts.json

@@ -287,8 +287,10 @@
           "Failed to write initial task.json",
           "Relationship rollback incomplete",
           "task.json not found or invalid:",
-          "only completed tasks with completedAt can be archived",
+          "only completed tasks can be archived",
           "complete the normal trellis-push progress sync before finish-work archive",
+          "completedAt was missing and has been set to",
+          "Failed to persist completedAt before archive",
           "Failed to persist branch",
           "Failed to persist base branch",
           "Failed to persist scope",
@@ -1639,7 +1641,8 @@
           "### 1. Completion State Gate",
           "taskStatus=completed",
           "finish-work must not manufacture completion",
-          "preserves the existing `completedAt` and performs no lifecycle status write"
+          "backfills a missing value after those guards pass",
+          "performs no lifecycle status transition"
         ]
       },
       "owner": "trellis-finish-work",

package/enhancements/0.6/overrides/patches/scripts/task-store-write-integrity/archive-guard-content.py

@@ -3,9 +3,9 @@
     if not task_data:
         print(colored(f"Error: task.json not found or invalid: {task_json_path}", Colors.RED), file=sys.stderr)
         return 1
-    if task_data.get("status") != "completed" or not task_data.get("completedAt"):
+    if task_data.get("status") != "completed":
         print(
-            colored("Error: only completed tasks with completedAt can be archived", Colors.RED),
+            colored("Error: only completed tasks can be archived", Colors.RED),
             file=sys.stderr,
         )
         print(

package/enhancements/0.6/overrides/patches/scripts/task-store-write-integrity/archive-write-content.py

@@ -1 +1,10 @@
-            # completed 状态和 completedAt 已由普通 push 的原子 progress 写入完成；归档只移动任务。
+            # completedAt 仅是审计元数据；兼容旧任务时在移动前补齐，不把缺失元数据当作非法状态。
+            if not data.get("completedAt"):
+                data["completedAt"] = today
+                if not write_json(task_json_path, data):
+                    print(colored("Error: Failed to persist completedAt before archive", Colors.RED), file=sys.stderr)
+                    return 1
+                print(
+                    colored(f"Warning: completedAt was missing and has been set to {today}.", Colors.YELLOW),
+                    file=sys.stderr,
+                )

package/enhancements/0.6/overrides/patches/skills/trellis-finish-work/exact-bookkeeping/content.md

@@ -25,7 +25,7 @@ Run:
 python3 ./.trellis/scripts/task_progress.py status --task <task-name> --json
 ```
 
-Read the current task's `task.json` as the authoritative lifecycle record. Continue only when `taskStatus=completed` and `completedAt` is present. Progress text is recovery evidence and never substitutes for the task status.
+Read the current task's `task.json` as the authoritative lifecycle record. Continue only when `taskStatus=completed`. A missing `completedAt` is recoverable archive metadata: `task.py archive` backfills it after the decision audit succeeds. Progress text is recovery evidence and never substitutes for the task status.
 
 - `in_progress`: stop and return to Phase 3.4 `trellis-push`; finish-work must not manufacture completion.
 - `completed`: keep the active task pointer until archive succeeds, then apply the archive eligibility gate below before continuing.
@@ -53,7 +53,7 @@ python3 ./.trellis/scripts/decision_log.py status --task <task-name> --json
 - Request changes: run `decision_log.py review --task <task-name> --verdict changes-requested --decision-id <id> [...] --notes <text>`, stop before release audit, and return the task for rework.
 - A corrupt decision log fails closed. Do not edit or discard it to bypass review.
 
-`task.py archive` repeats the completion-state and decision guards before any session cleanup or directory move. It preserves the existing `completedAt` and performs no lifecycle status write.
+`task.py archive` repeats the completion-state and decision guards before any session cleanup or directory move. It preserves an existing `completedAt`, backfills a missing value after those guards pass, and performs no lifecycle status transition.
 
 ### 3. Current Task Release Audit
 

package/enhancements/0.6/overrides/patches/workflow/phase-ownership/phase-2-check-content.md

@@ -8,6 +8,6 @@ Before interactive Check-All begins, run `python3 ./.trellis/scripts/pre_check_s
 
 Check-All selects light/full depth from intent, actual behavioral-contract impact, and runtime context. It is audit-only and collect-all by default: classify main-path issues as `CHK-*`, fallback-path issues as `FBK-*`, and low-risk factual drift as `DOC-*`. Assign P0/P1/P2 after root-cause classification; severity does not choose the channel. Report all items and stop before code changes only when `CHK-*` / `FBK-*` repair scope needs confirmation. The only write exception is low-risk `DOC-*` auto-remediation for eligible documents or narrowly verified source-comment facts, never executable code, unless a validated auto-loop owns the continuation.
 
-The existing `Interactive Post-Check Stop Gate` owns one narrow direct Git exception. Continue when the current completion-chain evidence contains an ordinary push or user-initiated `commit-only` intent and Check-All either strictly passes with zero remaining `CHK-*` / `FBK-*`, or every remaining finding has current explicit user risk acceptance. Both paths require no blocker, no partial verification, and no unaccepted material residual risk. A user reply that explicitly accepts findings from the current stopped report and asks to continue may resume that pending direct Git chain; do not infer intent or acceptance from unrelated history, summaries, or dirty state. Keep accepted findings visible in the standard report and Push risk evidence. Any unaccepted finding, blocker, partial verification, or unaccepted material residual risk reports and stops. Ordinary interactive checks still report and stop; Check-All never creates the Git plan itself.
+The existing `Interactive Post-Check Stop Gate` owns one narrow direct Git exception. Continue when the current completion-chain evidence contains an ordinary push or user-initiated `commit-only` intent and Check-All either strictly passes with zero remaining `CHK-*` / `FBK-*`, or every remaining finding has current explicit user risk acceptance. Both paths require no blocker, no blocking partial verification, and no unaccepted material residual risk outside explicitly recorded `[上线后验证]`. A user reply that semantically accepts all findings from the current stopped report and asks to continue covers the full current report, including P0, without a fixed phrase or repeated ID confirmation; partial acceptance must still identify a unique subset. Do not infer intent or acceptance from unrelated history, summaries, or dirty state. Keep accepted findings visible in the standard report and Push risk evidence. `[上线后验证]` items remain visible but do not block; any unaccepted finding, blocker, blocking partial verification, or other unaccepted material residual risk reports and stops. Ordinary interactive checks still report and stop; Check-All never creates the Git plan itself.
 
-After authorized repairs, return through the same route and re-run Check-All. The final pre-commit pass must cover the whole task and cannot be downgraded to light.
+After authorized repairs, return through the same route and re-run Check-All. Finishing Phase 2.2 or entering the commit chain does not itself force another Full: reuse still-valid Full evidence plus complete focused recheck evidence. Run Full again only when the user explicitly requests it, a hard-full signal appears, scope cannot be closed, a baseline or related contract changes, an unknown dirty path appears, or prior evidence becomes stale or invalid.

package/enhancements/0.6/scripts/auto_loop.py

@@ -631,8 +631,8 @@ def _auto_progress_for_item(state: dict[str, Any], item: dict[str, Any]) -> dict
 def _apply_local_completion(item: dict[str, Any], task_data: dict[str, Any]) -> bool:
     """把已本地提交的队列项写入任务本地完成态，返回 task.json 是否发生变化。
 
-    auto-loop 的终点是本地提交，但归档守卫要求 `status=completed` 且有 `completedAt`；
-    若不在这里落地本地完成态，任务会卡在既无法 finish-work 也无法 archive 的状态。
+    auto-loop 的终点是本地提交，finish-work 仍要求 `status=completed`；正常完成时同时
+    写入 `completedAt` 作为审计元数据，旧任务缺失该字段时由 archive 兼容补写。
     只允许 `in_progress -> completed` 这一个跃迁，并保留既有 `completedAt`，
     避免覆盖人工已确认的完成日期或把 planning/已完成任务重复改写。
     """

package/enhancements/MANIFEST.json

@@ -1,7 +1,7 @@
 {
-  "syncedAt": "2026-08-13T06:36:39.104Z",
+  "syncedAt": "2026-08-17T09:58:47.492Z",
   "syncedFrom": "vendor/skill-garden",
-  "sourceCommit": "61ab2f395bde64aea954fb3f6844580d6c19529c",
+  "sourceCommit": "124b592037eef542d7faf7ecb3be93b4bfd3aed0",
   "common": {
     "codexSkills": [
       "aliyun-ops",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "flower-trellis",
-  "version": "0.6.1-beta.2",
+  "version": "0.6.1-beta.4",
   "description": "一键安装/升级 Trellis 并自动融合 skill-garden 强化包(默认 Claude + agents)",
   "type": "module",
   "bin": {
@@ -70,9 +70,9 @@
     "commit-and-tag-version": "^12.7.3"
   },
   "flowerReleaseNotes": {
-    "version": "0.6.1-beta.2",
+    "version": "0.6.1-beta.4",
     "source": "CHANGELOG.md",
-    "body": "### ✨ 新功能 Features\n\n* **flower:** 接入 Maven 验证并同步 continue 文案 ([3819d75](https://github.com/SilentFlower/flower-trellis/commit/3819d759ecdd3bf067d02c8eac48d38b787ba037))\n\n\n### 🐛 修复 Bug Fixes\n\n* **flower:** 同步 Maven 验证修复 ([7d656af](https://github.com/SilentFlower/flower-trellis/commit/7d656af2a7975f7f1ffd5cff307f72cc482e9062))\n\n\n### 📝 文档 Docs\n\n* 更新开发日志 ([29cdbc0](https://github.com/SilentFlower/flower-trellis/commit/29cdbc0dd0f7cf323f714f08270d08ef5dd8a107))",
+    "body": "### ✨ 新功能 Features\n\n* **flower:** 同步 Check-All 门禁规则 ([739a07e](https://github.com/SilentFlower/flower-trellis/commit/739a07ee05211ab74a565892d277afb34dc3abdd))\n\n\n### 🐛 修复 Bug Fixes\n\n* **flower:** 同步 completedAt 归档兼容 ([78f715f](https://github.com/SilentFlower/flower-trellis/commit/78f715f3a0f2a9eaf9d0fde07b1f906a6b4548f7))",
     "truncated": false
   },
   "optionalDependencies": {