flower-trellis 0.6.0-beta.6 → 0.6.0-beta.8

package/README.md

@@ -168,7 +168,7 @@ flower-trellis plugin
 | `.flower/state.json` | 本机;记录实际平台、生成路径、ownership 与 Patch provenance |
 | `.flower/cache/`、`.flower/transactions/` | 本机;可清理缓存与事务恢复证据 |
 
-`rd-guide` 是随包预注册、默认启用但惰性访问的 GitLab Marketplace。打开管理器后，`发现` 页会在已有凭据时读取远程目录；未登录时只展示授权入口，不会尝试读取仓库内容。普通交互默认使用 Device Flow，PKCE 浏览器登录保留为来源详情中的高级选项。OAuth 只申请 `read_api read_repository`，Application Secret 和 token 都不会写入项目文件。
+`rd-guide` 是随包预注册、默认启用但惰性访问的 GitLab Marketplace。它的 GitLab 地址、项目和 ref 随 Flower 包升级，用户配置只保存启用或停用偏好，避免旧的用户级完整副本静默遮蔽包内修复；需要其它地址或分支时应新增独立 source ID。打开管理器后，`发现` 页会在已有凭据时读取远程目录；未登录时只展示授权入口，不会尝试读取仓库内容。普通交互默认使用 Device Flow，PKCE 浏览器登录保留为来源详情中的高级选项。OAuth 只申请 `read_api read_repository`，Application Secret 和 token 都不会写入项目文件。
 
 GitHub 首版只支持 `github.com` 公共仓库和匿名 REST，不保存 PAT 或其它凭据。来源会固定确认后的格式入口；安装 lock 固定完整 commit 与 canonical digest，通过 Marketplace 发现时还会固定索引仓库和索引 commit。匿名 API 可能受每小时 60 次/IP 的主要限额影响，限流会显示为 GitHub 诊断，不会转成登录提示。
 

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

@@ -18,7 +18,7 @@ description: "统一 Check-All 入口：确认范围与运行上下文，按 req
 4. 先按根因性质和可达证据把发现分为主路径 `CHK-*`、兜底 `FBK-*` 与文档漂移 `DOC-*`，再为 `CHK-*` 和 `FBK-*` 分配 P0/P1/P2。
 5. 在最终报告前处理允许自动修复的文档漂移，并把修复内容展示在报告里。
 6. 根据 interactive / validated auto-loop 边界输出下一步或完成 runner `record + next`。
-7. untracked helper 只保存流程游标：findings 或新编辑设回 `implement`；只有严格通过且 disposition 确认继续时才 `advance --stage spec`。
+7. untracked helper 只保存流程游标：未处置 findings 或新编辑设回 `implement`；严格通过或已接受风险通过且 disposition 确认继续时才 `advance --stage spec`。
 
 ---
 
@@ -42,7 +42,7 @@ description: "统一 Check-All 入口：确认范围与运行上下文，按 req
 1. **默认 audit-only collect-all**：可以读文件、搜索、运行无业务写入副作用的 lint、typecheck 和测试；普通代码、配置、测试、任务规格语义问题不得在检查阶段直接修复。
 2. **唯一自修例外**：低风险文档漂移进入 `DOC-*` 通道，按 `references/document-drift-auto-remediation.md` 的白名单、黑名单和写入时机处理。
 3. **分类先于严重度**：读取 `references/fallback-findings.md`；主路径错误和非兜底契约违背进入 `CHK-*`，fail-closed、异常输入、失败降级和防御性保护缺口进入 `FBK-*`。契约证据影响严重度，不改变兜底根因归属。
-4. **修改前只确认一次**：除 `DOC-*` 自动修复外，全部检查结束后通过统一报告让用户选择 `CHK-*` / `FBK-*` 修复范围；`修复全部` 默认覆盖两类问题。
+4. **处置只确认一次**：除 `DOC-*` 自动修复外，全部检查结束后通过统一报告让用户选择 `CHK-*` / `FBK-*` 修复范围或明确接受当前风险；`修复全部` 默认覆盖两类问题，接受风险不得隐藏发现。
 5. **委托规则不改变边界**：复用 `trellis-check` 时只复用检查清单、验证方法和命令发现，忽略其中任何“直接修复”“失败后先修复”的指令。
 6. **真正阻塞才中途暂停**：只有业务规划冲突、后续验证前提失效、生产或外部副作用、破坏性操作风险时提前停止。
 
@@ -114,6 +114,7 @@ check_profile:
 - 三个维度状态；
 - 自动修复的 `DOC-*` 内容；
 - 剩余 `CHK-*` 主路径问题与 `FBK-*` 兜底问题；
+- 每个剩余问题的未处置或已接受风险状态；
 - 已执行验证和未覆盖风险；
 - 与当前结论匹配的唯一下一步。
 

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

@@ -1,6 +1,6 @@
 # Fallback Findings
 
-本文件定义 `CHK-*` 主路径问题与 `FBK-*` 兜底问题的根因边界。分类发生在严重度评估之前；分类完成后，两类问题都根据当前实际影响分配 P0/P1/P2，并进入同一个修复与严格通过门禁。
+本文件定义 `CHK-*` 主路径问题与 `FBK-*` 兜底问题的根因边界。分类发生在严重度评估之前；分类完成后，两类问题都根据当前实际影响分配 P0/P1/P2，并进入同一个修复、风险接受与通过门禁。
 
 ---
 
@@ -65,5 +65,9 @@
 - `CHK-*` 与 `FBK-*` 分别独立编号，当前修复/重检循环保留原 ID。
 - 两类问题都按实际影响分配 P0/P1/P2；严重度不改变通道归属。
 - 两类问题都是修复项，都被 `修复全部` 覆盖，也都可以通过混合精确 ID 修复，例如 `修复 CHK-001,FBK-002`。
-- 任何剩余 `CHK-*` 或 `FBK-*` 都阻断 strict pass，并让 interactive、untracked、auto-loop、direct Git、Update-Spec 与 Push 进入未通过或 fix/recheck 路径。
-- `仅保留报告` 可以显式停止修复，但不能把未解决问题改写成通过。
+- 用户可以明确接受当前报告中任一 `CHK-*` 或 `FBK-*` 的风险而不修复；接受风险不改变问题通道、严重度、证据或建议，也不能把问题从报告中删除。
+- 风险接受必须能唯一对应当前报告的问题 ID；当前报告只有一个候选时，“这个问题”“不管这个”等明确指代可以解析为该 ID。P0 必须逐项写出精确 ID，不接受“全部”式概括授权。
+- 风险接受只适用于当前问题证据和实际 diff；受影响代码、契约、验证结果或问题证据变化后立即失效，必须重新检查和接受。
+- `strict pass` 仍要求剩余 `CHK-*` 与 `FBK-*` 均为 0；若所有剩余问题都已被用户有效接受，且无阻塞、无部分验证、无未接受的实质风险，则使用“已接受风险通过”。两种通过都可以进入 interactive、untracked、direct Git、Update-Spec 与 Push 的继续路径。
+- 只有未处置的 `CHK-*` 或 `FBK-*` 阻断交互完成链。validated auto-loop 不能代表用户接受风险，仍要求两类问题均为 0 才能 `record ok`。
+- `仅保留报告` 只表示停止修复，不构成风险接受，也不能把未处置问题改写成通过。

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

@@ -131,4 +131,5 @@ Full 通过必须同时满足：
 - 所有适用 PRD / design / implement 条目已映射到实现或明确 `N/A`；
 - 所有触发的假设 Dimension 已完成源码或真实契约核对；
 - 项目规范、复用、依赖、同层一致性和验证命令已覆盖实际变更范围；
-- 无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险。
+- strict pass：无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险；或
+- 已接受风险通过：所有剩余 `CHK-*` / `FBK-*` 都有当前有效的用户风险接受，且无阻塞、无部分验证、无未接受的实质剩余风险。

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

@@ -70,6 +70,7 @@ Light 通过必须同时满足：
 - 所有受影响规划条目已核对；
 - 所有触发的假设维度状态为 `通过` 或合理的 `N/A`；
 - 定向验证已运行并通过，或明确说明无需运行的原因；
-- 无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险。
+- strict pass：无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险；或
+- 已接受风险通过：所有剩余 `CHK-*` / `FBK-*` 都有当前有效的用户风险接受，且无阻塞、无部分验证、无未接受的实质剩余风险。
 
 存在未覆盖但不影响局部结论的内容时，必须在“未覆盖与风险”中说明。

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

@@ -6,7 +6,7 @@
 
 ## 统一问题模型
 
-先按 `references/fallback-findings.md` 判定 `CHK-*` / `FBK-*`，再为两类问题分配 P0/P1/P2。分类表达根因性质，严重度描述当前实际影响；两者都不改变问题必须进入修复和 strict pass 门禁的处置规则。
+先按 `references/fallback-findings.md` 判定 `CHK-*` / `FBK-*`，再为两类问题分配 P0/P1/P2。分类表达根因性质，严重度描述当前实际影响；两者都不决定问题必须修复还是可以由用户接受风险。
 
 ### `CHK-*` 主路径问题
 
@@ -42,7 +42,19 @@
 | 位置 | 同一根因的全部受影响位置 |
 | 验证 | 修复后的测试、故障注入、命令或手动验证步骤 |
 
-`CHK-*` 与 `FBK-*` 分开编号。同一根因的多个位置合并到一个问题；报告按严重度排序，但不得因此重排已经分配的 ID。新根因使用对应通道的下一个 ID。
+`CHK-*` 与 `FBK-*` 分开编号。同一根因的多个位置合并到一个问题；报告按严重度排序，但不得因此重排已经分配的 ID。新根因使用对应通道的下一个 ID。每个问题还必须标记 `未处置` 或 `已接受风险`；处置状态不改变 ID、通道和严重度。
+
+## 风险接受
+
+风险接受是用户对当前报告的显式处置，不是检查器对问题严重度的降级：
+
+1. 只有用户可以接受风险；主会话、subagent 和 validated auto-loop 都不得代替用户推断或授权。
+2. 接受必须唯一对应当前报告的问题 ID。用户可以写 `接受风险 CHK-001,FBK-002 并继续`；当前报告只有一个候选时，“这个问题”“不管这个”等明确指代可以解析为该 ID。P0 必须逐项写出精确 ID，不接受 `接受全部剩余风险`。
+3. 接受只绑定当前问题证据与实际 diff。受影响代码、契约、验证结果、问题内容或严重度变化后，原接受立即失效，问题恢复为 `未处置`。
+4. 已接受问题继续完整展示证据、影响、建议和验证，并标记 `处置：已接受风险`；不得删除、改列 `DOC-*` 或伪报已修复。
+5. `strict pass` 只用于剩余 `CHK-*` / `FBK-*` 均为 0。所有剩余问题均已被有效接受，且无 blocked、无部分验证、无未接受的实质剩余风险时，结论为 `通过·已接受风险`。
+6. blocked、部分验证和无法唯一对应到当前问题 ID 的实质剩余风险不是 `CHK-*` / `FBK-*` 处置状态，不能借风险接受绕过。
+7. `仅保留报告` 表示停止处置并等待，不等于接受风险；只有带明确接受语义的用户回复才改变问题处置状态。
 
 ---
 
@@ -53,7 +65,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 ```markdown
 ## Trellis Check-All 结果
 
-[<通过/未通过/阻塞>] <N> 个维度 · CHK <N> · FBK <N> · 自动修复 DOC <N> · P0 <N> / P1 <N> / P2 <N> · 验证 <通过>/<总数>
+[<通过/通过·已接受风险/未通过/阻塞>] <N> 个维度 · CHK <N>（接受 <N>）· FBK <N>（接受 <N>）· 自动修复 DOC <N> · P0 <N> / P1 <N> / P2 <N> · 验证 <通过>/<总数>
 
 工作：<任务名称 | Untracked work: work-id | 无活动工作>
 范围：<文件数与层级摘要；包含自动修复产生的文档 diff>
@@ -77,6 +89,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 ### 主路径问题
 
 - [ ] `CHK-001` `[P1]` <标题>
+  - 处置：<未处置/已接受风险>
   - 来源：<来源>
   - 证据：<file:line / 契约 / 命令结果>
   - 影响：<影响>
@@ -87,6 +100,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 ### 兜底问题
 
 - [ ] `FBK-001` `[P1]` <标题>
+  - 处置：<未处置/已接受风险>
   - 来源：<来源>
   - 证据：<file:line / 契约 / 命令结果>
   - 兜底场景：<可达异常或失败场景>
@@ -105,7 +119,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 批次 1：<CHK/FBK 问题 ID> · <修复目标>
 修复后：定向验证 -> Check-All 重检
 
-操作：`修复全部`、`修复 CHK-001,FBK-002`、`仅保留报告`
+操作：`修复全部`、`修复 CHK-001,FBK-002`、`接受风险 CHK-001,FBK-002 并继续`、`仅保留报告`
 
 ### 下一步
 
@@ -116,9 +130,10 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 
 - 没有 `DOC-*` 自动修复时省略“自动修复”区。
 - 没有 `CHK-*` 时省略“主路径问题”区；没有 `FBK-*` 时省略“兜底问题”区。
-- `CHK-*` 或 `FBK-*` 任一存在时展示“修复批次”，并只在报告末尾提供一次修复范围选择，不再逐项提问。
+- 存在未处置 `CHK-*` 或 `FBK-*` 时展示“修复批次”，并只在报告末尾提供一次处置选择，不再逐项提问。
 - `修复全部` 始终覆盖全部 `CHK-*` 与 `FBK-*`；精确修复可以混合两类 ID。
-- `仅保留报告` 只表示停止修复，不改变未通过结论或剩余风险。
+- 风险接受可以混合两类 ID；只有全部剩余问题都已有效接受时才形成“通过·已接受风险”。
+- `仅保留报告` 只表示停止处置，不改变未通过结论或剩余风险。
 - interactive 标准报告必须以“下一步”段结束；停止等待不等于省略引导。
 - 独立 `CHK-*` 或 `FBK-*` 不得因数量多而静默省略；先合并同根因重复项，再完整列出剩余项。
 - 报告不得包含 commit message、拟提交/暂存文件、commit-only 决策或提交确认。
@@ -160,9 +175,9 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 <按下方 `Interactive Post-Check Stop Gate` 输出一个明确、可执行的主动作>
 ```
 
-检查通过后的动作由下方 `Interactive Post-Check Stop Gate` 判断：普通交互停止等待，符合 direct Git 严格通过条件时同轮进入 Phase 3.3 `trellis-update-spec`，再到 Phase 3.4 `trellis-push`。仍有 `CHK-*` 或 `FBK-*` 时停留在修复/重检循环。
+检查通过后的动作由下方 `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 证据。普通严格通过但尚未继续时保持 `stage=check`；只有 direct Git 同轮继续或用户后续明确继续时才 `advance --stage spec`。有剩余 `CHK-*`、`FBK-*`、部分验证、阻塞或报告后的新编辑时，先 `advance --stage implement` 再返回实现。
+untracked helper 不记录 Check-All 证据或风险接受。普通 strict pass / 已接受风险通过但尚未继续时保持 `stage=check`；只有 direct Git 同轮继续或用户后续明确继续时才 `advance --stage spec`。有未处置 `CHK-*`、`FBK-*`、部分验证、阻塞或报告后的新编辑时，先 `advance --stage implement` 再返回实现。
 
 ---
 
@@ -171,7 +186,7 @@ untracked helper 不记录 Check-All 证据。普通严格通过但尚未继续
 validated auto-loop 复用相同的画像、profile、`DOC-*` 通道和问题模型，但不展示普通模式的修复选择：
 
 - 有 `DOC-*` 且可自动修复：主会话先应用并验证；当前任务 `implement.md` / `brief.md` 的每个实际变化都追加精确 `--doc-remediation-file`，再决定最终 `ok|failed|blocked`。
-- 有剩余 `CHK-*` 或 `FBK-*`：向 runner `record --result failed --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含最高严重度、两类问题 ID、根因、受影响文件和已自动修复的 `DOC-*`。
+- 有剩余 `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 成功后立即 `next`；若返回 `status=retryable reason=artifact-drift`，不得 `next`，先按 runner 指令在同一 outstanding action 内自纠并重录。validated auto-loop 不渲染交互式下一步段、不提示用户回复“继续”、不等待普通修复范围选择。
@@ -185,19 +200,19 @@ subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `chec
 
 非 validated auto-loop 先输出完整标准报告，再在本 Gate 内按以下顺序分流：
 
-1. 只从触发本轮完成链的最新用户消息识别 direct Git intent：明确请求普通 push，或用户主动 `commit-only`。不得从历史消息、任务标题、摘要、dirty 状态或 auto-loop 内部 action 推断。
-2. direct Git 只有在 Check-All 整体结论通过、剩余 `CHK-*` 和 `FBK-*` 均为 0、无阻塞、无部分验证、无待用户接受的实质剩余风险时才算严格通过。允许存在已成功验证的 `DOC-*` 自动修复；标准报告输出后，同一轮进入 Phase 3.3 `trellis-update-spec`；`no-op|written` 再由其加载 `trellis-push`，`needs-review` 停止。
-3. 剩余 `CHK-*`、`FBK-*`、blocked、部分验证或实质剩余风险均不满足条件：输出标准报告并停止，不运行 Update-Spec，也不生成 Git 计划。原始 Git 请求不授权自动修复普通问题、忽略问题或扩大 Git 权限。
+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 请求不授权自动修复普通问题或替用户接受风险。
 4. 没有匹配 direct Git intent 的普通 interactive 检查保持原行为：报告后立即停止并等待用户选择。
 
 ### 交互式下一步引导
 
 所有 interactive 标准报告都必须在末尾输出 `### 下一步`，并按以下首个命中分支给出一个明确主动作：
 
-1. 有剩余 `CHK-*` 或 `FBK-*`：提示用户回复 `修复全部`、混合精确问题 ID 或 `仅保留报告`；不得重复提出逐项确认。
+1. 有未处置 `CHK-*` 或 `FBK-*`：提示用户回复 `修复全部`、混合精确问题 ID、`接受风险 <问题 ID> 并继续` 或 `仅保留报告`；不得重复提出逐项确认。
 2. 有 blocked、部分验证或实质剩余风险：指出解除阻塞所需的精确决策、授权或验证，以及完成后重新运行 Check-All；涉及生产、外部系统或破坏性副作用时只引导用户授权，不自行执行。
-3. direct Git 严格通过：说明本轮正在进入 `trellis-update-spec`，不要求用户再次回复“继续”或确认 Git 计划。
-4. 无 direct Git intent 且严格通过：提示用户回复 `继续`，下一轮进入 `trellis-update-spec`，再由 `trellis-push` 生成提交计划。
+3. direct Git strict pass 或已接受风险通过：说明本轮正在进入 `trellis-update-spec`，不要求用户再次回复“继续”或确认 Git 计划。
+4. 无 direct Git intent 且 strict pass / 已接受风险通过：提示用户回复 `继续`，下一轮进入 `trellis-update-spec`，再由 `trellis-push` 生成提交计划。
 
 停止边界只控制是否自动推进，不能让报告在没有下一步提示的情况下结束。
 
@@ -209,6 +224,6 @@ subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `chec
 - 已执行验证及结果；
 - 未覆盖验证和剩余风险；
 - 总体结论；
-- 与当前结论匹配的唯一主动作引导；有 `CHK-*` 或 `FBK-*` 时是一次修复范围选择，部分验证/阻塞时是补充决策或验证，通过时是 Phase 3.3 / Phase 3.4 指向。
+- 与当前结论匹配的唯一主动作引导；有未处置 `CHK-*` 或 `FBK-*` 时是一次修复或风险接受选择，部分验证/阻塞时是补充决策或验证，通过时是 Phase 3.3 / Phase 3.4 指向。
 
 Check-All 不新增 direct Git 专用摘要，也不得自行生成提交计划、commit message、拟提交文件或要求用户确认提交；strict pass 后的 Git 计划仍由 Update-Spec disposition 和 `trellis-push` owner 生成。

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

@@ -33,7 +33,7 @@ description: "按确认的精确文件范围提交普通变更或完成已就绪
 
 除 auto-loop 内部 `commit-only` 外，普通 push 或用户 `commit-only` 已经构成明确 Git 意图。本 skill 在读取 Git 提交计划前只记录当前可用的完成链证据，不补跑、不切换阶段，也不新增确认：
 
-- Check-All：根据当前标准报告与实际 diff 标记为 `通过`、`未运行`、`已失效`、`存在阻断 findings`、`blocked` 或 `部分验证`。只有剩余 `CHK-*` 与 `FBK-*` 均为 0 才能标记为 `通过`；没有可验证的当前报告时使用 `未运行`，不得从历史消息、摘要或 dirty 状态猜测通过。
+- Check-All：根据当前标准报告与实际 diff 标记为 `通过`、`通过（已接受风险）`、`未运行`、`已失效`、`存在未处置 findings`、`blocked` 或 `部分验证`。剩余 `CHK-*` 与 `FBK-*` 均为 0 时标记为 `通过`；所有剩余问题都有当前有效的用户风险接受时标记为 `通过（已接受风险）`，并保留问题 ID 与严重度。没有可验证的当前报告时使用 `未运行`，不得从历史消息、摘要或 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` 不反向补做上游阶段。
@@ -136,7 +136,7 @@ auto-loop 内部 `commit-only` 也允许 retained dirty 存在，但每个生成
 顺序：<repo-a> [-> `<local generation command>`] -> <repo-b> [-> task progress]
 
 ### 完成链证据
-- Check-All：<通过 / 未运行 / 已失效 / 存在阻断 findings / blocked / 部分验证>
+- Check-All：<通过 / 通过（已接受风险：CHK-001,FBK-002） / 未运行 / 已失效 / 存在未处置 findings / blocked / 部分验证>
 - Update-Spec：<no-op / written / needs-review / 未运行 / 已失效>
 
 ### 1. <repository-name>
@@ -176,7 +176,7 @@ Push：<执行 / 跳过（commit-only）>
 - 超过 8 个时按目录归组，最多 12 行；用户要求展开时展示同一 exact set。
 - 顶部仓库/commit/file 总数包含独立任务记录提交所在 Git root、该提交及其 exact files；任务记录文件使用相同的 8 文件展示阈值和展开规则。
 - 保留未提交的变更始终逐项标注 Git 状态；真正风险在独立“风险”区逐项展示。
-- 完成链证据始终显示当前状态，但不重复 Check-All 报告或 Spec review 正文；`未运行`、`已失效`、任一剩余 `CHK-*` / `FBK-*`、blocked、部分验证或 `needs-review` 同时计入风险区。
+- 完成链证据始终显示当前状态，但不重复 Check-All 报告或 Spec review 正文；`未运行`、`已失效`、任一未处置 `CHK-*` / `FBK-*`、blocked、部分验证或 `needs-review` 同时计入风险区。已接受风险的问题也必须按 ID、严重度和影响进入风险区，但不得改标为阻断 finding。
 - 无活动 task、untracked 或 `commit-only` 时省略进度动作。
 - 不重复展示检查结果、规范复核、归档或其他阶段的详细信息。
 - 生成前无法确定的内容和增删行写“生成后计算”，不得填预测值。

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

@@ -22,4 +22,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. 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, 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.

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

@@ -20,26 +20,48 @@ flower-trellis worktree status --target <target-worktree> --json
 
 3. Route by status:
    - `ready-local`: continue with the user's original Trellis intent in this worktree.
-   - `needs-prepare`: run `flower-trellis worktree prepare --target <target-worktree>` with an explicit developer identity when requested.
+   - `needs-prepare`: run `flower-trellis worktree prepare --target <target-worktree>` with an explicit developer identity when requested. Add `--inherit-route-prefs` only when the user wants the same developer's normalized personal route defaults from the current controlling worktree.
    - `needs-init`: initialize Trellis in that branch; do not copy another worktree's version.
    - `needs-migration`: run `flower-trellis worktree migrate --target <target-worktree> --dry-run` before the real migration.
    - `blocked` or `error`: stop and report the stable reason and conflict paths.
-4. For a new parallel task, create the worktree before planning files exist:
+4. For a new parallel task, load Trellis package context before requesting the plan:
 
 ```bash
-flower-trellis worktree create --target <path> --branch <branch> --base <ref> \
+python3 ./.trellis/scripts/get_context.py --mode packages
+```
+
+   Treat the default package as the selected root repository. Correlate package entries marked as Git repositories with the engine's submodule inventory. Display every additional independent Git package by name and path, and require its base/branch to be confirmed separately after handoff; never infer a child repository base from the root branch.
+5. Request the read-only create plan before planning files exist. Omit `--base` to use the current source branch; detached sources fall back to `HEAD`:
+
+```bash
+flower-trellis worktree create --target <path> --branch <branch> [--base <ref>] \
   --task-title <title> --task-slug <slug>
 ```
 
-5. Continue task planning in a new AI session whose cwd is the returned handoff directory.
+6. Present one compact confirmation view containing the selected root repository/branch/HEAD, requested and resolved base, target branch/path/task, root dirty warning, selected-commit submodules, independent Git packages, developer initialization, normalized route preference action, and excluded local state. State explicitly that only the selected root gets the new branch; submodules and independent Git packages are inventory-only.
+7. Ask for exactly one choice: confirm the displayed plan, change its inputs, or cancel. On confirmation, execute the exact plan fingerprint returned by preflight:
+
+```bash
+flower-trellis worktree create --target <path> --branch <branch> [--base <ref>] \
+  --task-title <title> --task-slug <slug> \
+  --yes --plan-fingerprint <fingerprint>
+```
+
+8. If the engine returns `create-plan-changed`, show the latest returned plan and require a new confirmation. Never reuse the old fingerprint.
+9. Continue task planning in a new AI session whose cwd/workspace root is the returned handoff directory. Do not continue the source session inside the new worktree.
 
 ## Safety Rules
 
 - `status` is read-only.
-- `prepare` only creates target-local gitignored state and registry metadata.
+- A `create` call without `--yes` is also read-only and must return `confirmation-required` plus a fingerprint.
+- `prepare` only creates target-local gitignored state and registry metadata. By default it reads no other worktree. Explicit route inheritance requires the same canonical Git common dir and developer, and preserves an existing target preference file.
 - `migrate` may replace only schema v1 manifest-managed symlinks, and only with content reconstructed from the target branch itself.
 - Do not read the legacy `sourceRoot` as migration content.
 - `create` does not attach or move an existing task.
+- Root tracked, staged, untracked, and conflict state is a warning only and is never included in the selected base commit, copied, stashed, or treated as an implicit blocker.
+- The only personal preference eligible for inheritance is `.trellis/.route-prefs.tmp`. Read only a regular file, keep only legal `implement` and `check` values, and write normalized fixed-order content. Never copy its original bytes.
+- Do not inherit session/current-task state, pre-check/untracked/auto-loop/Ralph state, agent temporary state, `.flower/state.json`, `.claude/settings.local.json`, caches, transactions, or backups.
+- Selected-commit submodules are inventory facts. Report initialized source branch/HEAD without fetching, checking out, or copying submodule working trees.
 - `remove` requires a clean worktree with no active task, session, or lock; it preserves the branch.
 - Do not use force, copy directories between worktrees, or treat setup as approval to start, check, commit, merge, or push.
 

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

@@ -18,7 +18,7 @@ description: "统一 Check-All 入口：确认范围与运行上下文，按 req
 4. 先按根因性质和可达证据把发现分为主路径 `CHK-*`、兜底 `FBK-*` 与文档漂移 `DOC-*`，再为 `CHK-*` 和 `FBK-*` 分配 P0/P1/P2。
 5. 在最终报告前处理允许自动修复的文档漂移，并把修复内容展示在报告里。
 6. 根据 interactive / validated auto-loop 边界输出下一步或完成 runner `record + next`。
-7. untracked helper 只保存流程游标：findings 或新编辑设回 `implement`；只有严格通过且 disposition 确认继续时才 `advance --stage spec`。
+7. untracked helper 只保存流程游标：未处置 findings 或新编辑设回 `implement`；严格通过或已接受风险通过且 disposition 确认继续时才 `advance --stage spec`。
 
 ---
 
@@ -42,7 +42,7 @@ description: "统一 Check-All 入口：确认范围与运行上下文，按 req
 1. **默认 audit-only collect-all**：可以读文件、搜索、运行无业务写入副作用的 lint、typecheck 和测试；普通代码、配置、测试、任务规格语义问题不得在检查阶段直接修复。
 2. **唯一自修例外**：低风险文档漂移进入 `DOC-*` 通道，按 `references/document-drift-auto-remediation.md` 的白名单、黑名单和写入时机处理。
 3. **分类先于严重度**：读取 `references/fallback-findings.md`；主路径错误和非兜底契约违背进入 `CHK-*`，fail-closed、异常输入、失败降级和防御性保护缺口进入 `FBK-*`。契约证据影响严重度，不改变兜底根因归属。
-4. **修改前只确认一次**：除 `DOC-*` 自动修复外，全部检查结束后通过统一报告让用户选择 `CHK-*` / `FBK-*` 修复范围；`修复全部` 默认覆盖两类问题。
+4. **处置只确认一次**：除 `DOC-*` 自动修复外，全部检查结束后通过统一报告让用户选择 `CHK-*` / `FBK-*` 修复范围或明确接受当前风险；`修复全部` 默认覆盖两类问题，接受风险不得隐藏发现。
 5. **委托规则不改变边界**：复用 `trellis-check` 时只复用检查清单、验证方法和命令发现，忽略其中任何“直接修复”“失败后先修复”的指令。
 6. **真正阻塞才中途暂停**：只有业务规划冲突、后续验证前提失效、生产或外部副作用、破坏性操作风险时提前停止。
 
@@ -114,6 +114,7 @@ check_profile:
 - 三个维度状态；
 - 自动修复的 `DOC-*` 内容；
 - 剩余 `CHK-*` 主路径问题与 `FBK-*` 兜底问题；
+- 每个剩余问题的未处置或已接受风险状态；
 - 已执行验证和未覆盖风险；
 - 与当前结论匹配的唯一下一步。
 

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

@@ -1,6 +1,6 @@
 # Fallback Findings
 
-本文件定义 `CHK-*` 主路径问题与 `FBK-*` 兜底问题的根因边界。分类发生在严重度评估之前；分类完成后，两类问题都根据当前实际影响分配 P0/P1/P2，并进入同一个修复与严格通过门禁。
+本文件定义 `CHK-*` 主路径问题与 `FBK-*` 兜底问题的根因边界。分类发生在严重度评估之前；分类完成后，两类问题都根据当前实际影响分配 P0/P1/P2，并进入同一个修复、风险接受与通过门禁。
 
 ---
 
@@ -65,5 +65,9 @@
 - `CHK-*` 与 `FBK-*` 分别独立编号，当前修复/重检循环保留原 ID。
 - 两类问题都按实际影响分配 P0/P1/P2；严重度不改变通道归属。
 - 两类问题都是修复项，都被 `修复全部` 覆盖，也都可以通过混合精确 ID 修复，例如 `修复 CHK-001,FBK-002`。
-- 任何剩余 `CHK-*` 或 `FBK-*` 都阻断 strict pass，并让 interactive、untracked、auto-loop、direct Git、Update-Spec 与 Push 进入未通过或 fix/recheck 路径。
-- `仅保留报告` 可以显式停止修复，但不能把未解决问题改写成通过。
+- 用户可以明确接受当前报告中任一 `CHK-*` 或 `FBK-*` 的风险而不修复；接受风险不改变问题通道、严重度、证据或建议，也不能把问题从报告中删除。
+- 风险接受必须能唯一对应当前报告的问题 ID；当前报告只有一个候选时，“这个问题”“不管这个”等明确指代可以解析为该 ID。P0 必须逐项写出精确 ID，不接受“全部”式概括授权。
+- 风险接受只适用于当前问题证据和实际 diff；受影响代码、契约、验证结果或问题证据变化后立即失效，必须重新检查和接受。
+- `strict pass` 仍要求剩余 `CHK-*` 与 `FBK-*` 均为 0；若所有剩余问题都已被用户有效接受，且无阻塞、无部分验证、无未接受的实质风险，则使用“已接受风险通过”。两种通过都可以进入 interactive、untracked、direct Git、Update-Spec 与 Push 的继续路径。
+- 只有未处置的 `CHK-*` 或 `FBK-*` 阻断交互完成链。validated auto-loop 不能代表用户接受风险，仍要求两类问题均为 0 才能 `record ok`。
+- `仅保留报告` 只表示停止修复，不构成风险接受，也不能把未处置问题改写成通过。

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

@@ -131,4 +131,5 @@ Full 通过必须同时满足：
 - 所有适用 PRD / design / implement 条目已映射到实现或明确 `N/A`；
 - 所有触发的假设 Dimension 已完成源码或真实契约核对；
 - 项目规范、复用、依赖、同层一致性和验证命令已覆盖实际变更范围；
-- 无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险。
+- strict pass：无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险；或
+- 已接受风险通过：所有剩余 `CHK-*` / `FBK-*` 都有当前有效的用户风险接受，且无阻塞、无部分验证、无未接受的实质剩余风险。

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

@@ -70,6 +70,7 @@ Light 通过必须同时满足：
 - 所有受影响规划条目已核对；
 - 所有触发的假设维度状态为 `通过` 或合理的 `N/A`；
 - 定向验证已运行并通过，或明确说明无需运行的原因；
-- 无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险。
+- strict pass：无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险；或
+- 已接受风险通过：所有剩余 `CHK-*` / `FBK-*` 都有当前有效的用户风险接受，且无阻塞、无部分验证、无未接受的实质剩余风险。
 
 存在未覆盖但不影响局部结论的内容时，必须在“未覆盖与风险”中说明。

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

@@ -6,7 +6,7 @@
 
 ## 统一问题模型
 
-先按 `references/fallback-findings.md` 判定 `CHK-*` / `FBK-*`，再为两类问题分配 P0/P1/P2。分类表达根因性质，严重度描述当前实际影响；两者都不改变问题必须进入修复和 strict pass 门禁的处置规则。
+先按 `references/fallback-findings.md` 判定 `CHK-*` / `FBK-*`，再为两类问题分配 P0/P1/P2。分类表达根因性质，严重度描述当前实际影响；两者都不决定问题必须修复还是可以由用户接受风险。
 
 ### `CHK-*` 主路径问题
 
@@ -42,7 +42,19 @@
 | 位置 | 同一根因的全部受影响位置 |
 | 验证 | 修复后的测试、故障注入、命令或手动验证步骤 |
 
-`CHK-*` 与 `FBK-*` 分开编号。同一根因的多个位置合并到一个问题；报告按严重度排序，但不得因此重排已经分配的 ID。新根因使用对应通道的下一个 ID。
+`CHK-*` 与 `FBK-*` 分开编号。同一根因的多个位置合并到一个问题；报告按严重度排序，但不得因此重排已经分配的 ID。新根因使用对应通道的下一个 ID。每个问题还必须标记 `未处置` 或 `已接受风险`；处置状态不改变 ID、通道和严重度。
+
+## 风险接受
+
+风险接受是用户对当前报告的显式处置，不是检查器对问题严重度的降级：
+
+1. 只有用户可以接受风险；主会话、subagent 和 validated auto-loop 都不得代替用户推断或授权。
+2. 接受必须唯一对应当前报告的问题 ID。用户可以写 `接受风险 CHK-001,FBK-002 并继续`；当前报告只有一个候选时，“这个问题”“不管这个”等明确指代可以解析为该 ID。P0 必须逐项写出精确 ID，不接受 `接受全部剩余风险`。
+3. 接受只绑定当前问题证据与实际 diff。受影响代码、契约、验证结果、问题内容或严重度变化后，原接受立即失效，问题恢复为 `未处置`。
+4. 已接受问题继续完整展示证据、影响、建议和验证，并标记 `处置：已接受风险`；不得删除、改列 `DOC-*` 或伪报已修复。
+5. `strict pass` 只用于剩余 `CHK-*` / `FBK-*` 均为 0。所有剩余问题均已被有效接受，且无 blocked、无部分验证、无未接受的实质剩余风险时，结论为 `通过·已接受风险`。
+6. blocked、部分验证和无法唯一对应到当前问题 ID 的实质剩余风险不是 `CHK-*` / `FBK-*` 处置状态，不能借风险接受绕过。
+7. `仅保留报告` 表示停止处置并等待，不等于接受风险；只有带明确接受语义的用户回复才改变问题处置状态。
 
 ---
 
@@ -53,7 +65,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 ```markdown
 ## Trellis Check-All 结果
 
-[<通过/未通过/阻塞>] <N> 个维度 · CHK <N> · FBK <N> · 自动修复 DOC <N> · P0 <N> / P1 <N> / P2 <N> · 验证 <通过>/<总数>
+[<通过/通过·已接受风险/未通过/阻塞>] <N> 个维度 · CHK <N>（接受 <N>）· FBK <N>（接受 <N>）· 自动修复 DOC <N> · P0 <N> / P1 <N> / P2 <N> · 验证 <通过>/<总数>
 
 工作：<任务名称 | Untracked work: work-id | 无活动工作>
 范围：<文件数与层级摘要；包含自动修复产生的文档 diff>
@@ -77,6 +89,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 ### 主路径问题
 
 - [ ] `CHK-001` `[P1]` <标题>
+  - 处置：<未处置/已接受风险>
   - 来源：<来源>
   - 证据：<file:line / 契约 / 命令结果>
   - 影响：<影响>
@@ -87,6 +100,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 ### 兜底问题
 
 - [ ] `FBK-001` `[P1]` <标题>
+  - 处置：<未处置/已接受风险>
   - 来源：<来源>
   - 证据：<file:line / 契约 / 命令结果>
   - 兜底场景：<可达异常或失败场景>
@@ -105,7 +119,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 批次 1：<CHK/FBK 问题 ID> · <修复目标>
 修复后：定向验证 -> Check-All 重检
 
-操作：`修复全部`、`修复 CHK-001,FBK-002`、`仅保留报告`
+操作：`修复全部`、`修复 CHK-001,FBK-002`、`接受风险 CHK-001,FBK-002 并继续`、`仅保留报告`
 
 ### 下一步
 
@@ -116,9 +130,10 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 
 - 没有 `DOC-*` 自动修复时省略“自动修复”区。
 - 没有 `CHK-*` 时省略“主路径问题”区；没有 `FBK-*` 时省略“兜底问题”区。
-- `CHK-*` 或 `FBK-*` 任一存在时展示“修复批次”，并只在报告末尾提供一次修复范围选择，不再逐项提问。
+- 存在未处置 `CHK-*` 或 `FBK-*` 时展示“修复批次”，并只在报告末尾提供一次处置选择，不再逐项提问。
 - `修复全部` 始终覆盖全部 `CHK-*` 与 `FBK-*`；精确修复可以混合两类 ID。
-- `仅保留报告` 只表示停止修复，不改变未通过结论或剩余风险。
+- 风险接受可以混合两类 ID；只有全部剩余问题都已有效接受时才形成“通过·已接受风险”。
+- `仅保留报告` 只表示停止处置，不改变未通过结论或剩余风险。
 - interactive 标准报告必须以“下一步”段结束；停止等待不等于省略引导。
 - 独立 `CHK-*` 或 `FBK-*` 不得因数量多而静默省略；先合并同根因重复项，再完整列出剩余项。
 - 报告不得包含 commit message、拟提交/暂存文件、commit-only 决策或提交确认。
@@ -160,9 +175,9 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 <按下方 `Interactive Post-Check Stop Gate` 输出一个明确、可执行的主动作>
 ```
 
-检查通过后的动作由下方 `Interactive Post-Check Stop Gate` 判断：普通交互停止等待，符合 direct Git 严格通过条件时同轮进入 Phase 3.3 `trellis-update-spec`，再到 Phase 3.4 `trellis-push`。仍有 `CHK-*` 或 `FBK-*` 时停留在修复/重检循环。
+检查通过后的动作由下方 `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 证据。普通严格通过但尚未继续时保持 `stage=check`；只有 direct Git 同轮继续或用户后续明确继续时才 `advance --stage spec`。有剩余 `CHK-*`、`FBK-*`、部分验证、阻塞或报告后的新编辑时，先 `advance --stage implement` 再返回实现。
+untracked helper 不记录 Check-All 证据或风险接受。普通 strict pass / 已接受风险通过但尚未继续时保持 `stage=check`；只有 direct Git 同轮继续或用户后续明确继续时才 `advance --stage spec`。有未处置 `CHK-*`、`FBK-*`、部分验证、阻塞或报告后的新编辑时，先 `advance --stage implement` 再返回实现。
 
 ---
 
@@ -171,7 +186,7 @@ untracked helper 不记录 Check-All 证据。普通严格通过但尚未继续
 validated auto-loop 复用相同的画像、profile、`DOC-*` 通道和问题模型，但不展示普通模式的修复选择：
 
 - 有 `DOC-*` 且可自动修复：主会话先应用并验证；当前任务 `implement.md` / `brief.md` 的每个实际变化都追加精确 `--doc-remediation-file`，再决定最终 `ok|failed|blocked`。
-- 有剩余 `CHK-*` 或 `FBK-*`：向 runner `record --result failed --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含最高严重度、两类问题 ID、根因、受影响文件和已自动修复的 `DOC-*`。
+- 有剩余 `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 成功后立即 `next`；若返回 `status=retryable reason=artifact-drift`，不得 `next`，先按 runner 指令在同一 outstanding action 内自纠并重录。validated auto-loop 不渲染交互式下一步段、不提示用户回复“继续”、不等待普通修复范围选择。
@@ -185,19 +200,19 @@ subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `chec
 
 非 validated auto-loop 先输出完整标准报告，再在本 Gate 内按以下顺序分流：
 
-1. 只从触发本轮完成链的最新用户消息识别 direct Git intent：明确请求普通 push，或用户主动 `commit-only`。不得从历史消息、任务标题、摘要、dirty 状态或 auto-loop 内部 action 推断。
-2. direct Git 只有在 Check-All 整体结论通过、剩余 `CHK-*` 和 `FBK-*` 均为 0、无阻塞、无部分验证、无待用户接受的实质剩余风险时才算严格通过。允许存在已成功验证的 `DOC-*` 自动修复；标准报告输出后，同一轮进入 Phase 3.3 `trellis-update-spec`；`no-op|written` 再由其加载 `trellis-push`，`needs-review` 停止。
-3. 剩余 `CHK-*`、`FBK-*`、blocked、部分验证或实质剩余风险均不满足条件：输出标准报告并停止，不运行 Update-Spec，也不生成 Git 计划。原始 Git 请求不授权自动修复普通问题、忽略问题或扩大 Git 权限。
+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 请求不授权自动修复普通问题或替用户接受风险。
 4. 没有匹配 direct Git intent 的普通 interactive 检查保持原行为：报告后立即停止并等待用户选择。
 
 ### 交互式下一步引导
 
 所有 interactive 标准报告都必须在末尾输出 `### 下一步`，并按以下首个命中分支给出一个明确主动作：
 
-1. 有剩余 `CHK-*` 或 `FBK-*`：提示用户回复 `修复全部`、混合精确问题 ID 或 `仅保留报告`；不得重复提出逐项确认。
+1. 有未处置 `CHK-*` 或 `FBK-*`：提示用户回复 `修复全部`、混合精确问题 ID、`接受风险 <问题 ID> 并继续` 或 `仅保留报告`；不得重复提出逐项确认。
 2. 有 blocked、部分验证或实质剩余风险：指出解除阻塞所需的精确决策、授权或验证，以及完成后重新运行 Check-All；涉及生产、外部系统或破坏性副作用时只引导用户授权，不自行执行。
-3. direct Git 严格通过：说明本轮正在进入 `trellis-update-spec`，不要求用户再次回复“继续”或确认 Git 计划。
-4. 无 direct Git intent 且严格通过：提示用户回复 `继续`，下一轮进入 `trellis-update-spec`，再由 `trellis-push` 生成提交计划。
+3. direct Git strict pass 或已接受风险通过：说明本轮正在进入 `trellis-update-spec`，不要求用户再次回复“继续”或确认 Git 计划。
+4. 无 direct Git intent 且 strict pass / 已接受风险通过：提示用户回复 `继续`，下一轮进入 `trellis-update-spec`，再由 `trellis-push` 生成提交计划。
 
 停止边界只控制是否自动推进，不能让报告在没有下一步提示的情况下结束。
 
@@ -209,6 +224,6 @@ subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `chec
 - 已执行验证及结果；
 - 未覆盖验证和剩余风险；
 - 总体结论；
-- 与当前结论匹配的唯一主动作引导；有 `CHK-*` 或 `FBK-*` 时是一次修复范围选择，部分验证/阻塞时是补充决策或验证，通过时是 Phase 3.3 / Phase 3.4 指向。
+- 与当前结论匹配的唯一主动作引导；有未处置 `CHK-*` 或 `FBK-*` 时是一次修复或风险接受选择，部分验证/阻塞时是补充决策或验证，通过时是 Phase 3.3 / Phase 3.4 指向。
 
 Check-All 不新增 direct Git 专用摘要，也不得自行生成提交计划、commit message、拟提交文件或要求用户确认提交；strict pass 后的 Git 计划仍由 Update-Spec disposition 和 `trellis-push` owner 生成。

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 才能标记为 `通过`；没有可验证的当前报告时使用 `未运行`，不得从历史消息、摘要或 dirty 状态猜测通过。
+- Check-All：根据当前标准报告与实际 diff 标记为 `通过`、`通过（已接受风险）`、`未运行`、`已失效`、`存在未处置 findings`、`blocked` 或 `部分验证`。剩余 `CHK-*` 与 `FBK-*` 均为 0 时标记为 `通过`；所有剩余问题都有当前有效的用户风险接受时标记为 `通过（已接受风险）`，并保留问题 ID 与严重度。没有可验证的当前报告时使用 `未运行`，不得从历史消息、摘要或 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` 不反向补做上游阶段。
@@ -136,7 +136,7 @@ auto-loop 内部 `commit-only` 也允许 retained dirty 存在，但每个生成
 顺序：<repo-a> [-> `<local generation command>`] -> <repo-b> [-> task progress]
 
 ### 完成链证据
-- Check-All：<通过 / 未运行 / 已失效 / 存在阻断 findings / blocked / 部分验证>
+- Check-All：<通过 / 通过（已接受风险：CHK-001,FBK-002） / 未运行 / 已失效 / 存在未处置 findings / blocked / 部分验证>
 - Update-Spec：<no-op / written / needs-review / 未运行 / 已失效>
 
 ### 1. <repository-name>
@@ -176,7 +176,7 @@ Push：<执行 / 跳过（commit-only）>
 - 超过 8 个时按目录归组，最多 12 行；用户要求展开时展示同一 exact set。
 - 顶部仓库/commit/file 总数包含独立任务记录提交所在 Git root、该提交及其 exact files；任务记录文件使用相同的 8 文件展示阈值和展开规则。
 - 保留未提交的变更始终逐项标注 Git 状态；真正风险在独立“风险”区逐项展示。
-- 完成链证据始终显示当前状态，但不重复 Check-All 报告或 Spec review 正文；`未运行`、`已失效`、任一剩余 `CHK-*` / `FBK-*`、blocked、部分验证或 `needs-review` 同时计入风险区。
+- 完成链证据始终显示当前状态，但不重复 Check-All 报告或 Spec review 正文；`未运行`、`已失效`、任一未处置 `CHK-*` / `FBK-*`、blocked、部分验证或 `needs-review` 同时计入风险区。已接受风险的问题也必须按 ID、严重度和影响进入风险区，但不得改标为阻断 finding。
 - 无活动 task、untracked 或 `commit-only` 时省略进度动作。
 - 不重复展示检查结果、规范复核、归档或其他阶段的详细信息。
 - 生成前无法确定的内容和增删行写“生成后计算”，不得填预测值。