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

package/README.md

@@ -52,6 +52,15 @@ flower-trellis init -u <your-name> -y
 # 升级 Trellis 并按新版本重新叠加强化包
 flower-trellis update
 
+# 真正关闭整个项目中全部平台的 Trellis 集成
+flower-trellis trellis disable --target .
+
+# 查看项目级开关和入口漂移状态
+flower-trellis trellis status --target .
+
+# 恢复 Trellis，并规范化到当前 Flower/Trellis 版本
+flower-trellis trellis enable --target .
+
 # 临时保留最近 5 份升级备份；传 0 可关闭本次自动清理
 flower-trellis update --backup-retention 5
 
@@ -84,6 +93,7 @@ flower-trellis -v
 |------|------|
 | `init` | 安装 Trellis 并叠加强化包(默认命令,裸跑等同 `init`) |
 | `update` | 升级 Trellis,并按新版本重新叠加强化包 |
+| `trellis` | 项目级关闭、恢复或检查全部平台中的 Trellis 集成 |
 | `self-check` | 输出启动更新检查 JSON,供 Codex / Claude Code hook 和 AI 自动化读取 |
 | `self-update` | 受控升级 flower-trellis 并对目标项目执行完整 `flower-trellis update` 重叠加 |
 | `update-check` | 管理 `.flower/settings.json` 内的启动更新策略和提示节流 |
@@ -107,6 +117,30 @@ flower-trellis -v
 
 未指定平台时,交互模式会弹出多选菜单(默认勾选 Claude Code + Codex);也可直接传 `--claude` / `--codex` / `--cursor` / `--devin` / `--zcode` / `--trae` / `--omp` / `--grok` / `--kimi` / `--snow` 等指定,或用 `-y` 跳过菜单。`--windsurf` 仍作为 Devin 的旧别名透传给 Trellis。其余未识别的 flag(如 `-u`、`-f`、`--template`、`--with-statusline`)一律透传给 Trellis。
 
+## 项目级关闭与恢复
+
+`flower-trellis trellis disable` 是整个项目的真正关闭，不是只跳过一次 Hook。它会在一次事务中移除全部已配置平台可发现的 Trellis Skills、Agents、Commands、Workflows、Hooks、Extensions、平台配置入口，以及 `AGENTS.md` 中的 Trellis 管理块。开关始终作用于整个项目，不提供平台级参数，也不会留下不同平台一开一关的混合状态。
+
+关闭不会删除 `.trellis/tasks/`、`.trellis/spec/`、`.trellis/workspace/`、当前任务或 `.flower/plugins.json` / `plugin-lock.json` / `state.json`。恢复材料保存在 gitignored 的 `.flower/trellis-control.json` 和 `.flower/trellis-detached/`；它们记录原始字节、文件 mode、所有权和关闭前后摘要。当前会话已经加载的上下文无法被命令撤回，因此 disable 或 enable 完成后都需要重启 AI 会话。
+
+```bash
+# 只读预演，显示将 detach 的全部入口
+flower-trellis trellis disable --dry-run --json --target .
+
+# 真正关闭；修改过的独占受管文件默认会在写盘前阻断
+flower-trellis trellis disable --target .
+
+# 查看 enabled / disabled / drifted / repair-required / not-initialized
+flower-trellis trellis status --json --target .
+
+# 精确恢复关闭前现场，再运行当前版本的 update 和 Plugin replay
+flower-trellis trellis enable --target .
+```
+
+共享 JSON 与 `AGENTS.md` 采用结构化恢复，关闭期间新增的无关用户配置会保留。无法安全拆分的修改默认冲突并保持零写入；`--force` 只处理恢复证据完整时的独占文件冲突、共享 JSON 恢复冲突或 drifted 重收敛，用户现场会先保存到 detached 恢复证据中。`repair-required` 表示控制状态或恢复材料已经不可信，disable/enable 即使带 `--force` 也会拒绝覆盖，必须先依据诊断修复证据。
+
+项目处于 disabled 时，`flower-trellis update`、`self-update` 的项目更新链，以及 `plugin add/update/remove/replay` 会临时恢复必要入口，完成写操作后再次 detach，并校验最终仍为 disabled；外部 Plugin 内容不会被当作 Trellis 入口删除。直接运行上游 `trellis update` 不经过这一控制面，可能重新生成入口，此时 `flower-trellis trellis status` 会报告 `drifted`。`disable` 也不等同于 `uninstall`：历史数据和恢复能力会继续保留。
+
 ## Flower Plugin
 
 Flower Plugin 是 flower-trellis 的标准运行时格式。GitHub 公共仓库可自动识别 Flower、Codex、Claude Code 与 Skill-only 包，并先规范化为标准 Flower package，再进入同一套来源解析、依赖锁定、能力校验、内容投影、事务写入和卸载所有权。外部 `skills/` 与 Claude legacy `commands/*.md` 可导入；hooks、agents、MCP、LSP、monitor、bin、settings、themes、output styles 和 apps 只展示兼容性诊断，不会执行。
@@ -119,7 +153,7 @@ flower-trellis plugin
 
 交互管理器采用 `发现 / 已安装 / 来源 / 问题` 四个页签。Trellis 项目的 `发现` 页会展示 `flower/skill-garden` 内置入口，按 Enter 直接管理工作流强化与可选通用技能；原 `flower-trellis skill` 命令继续保留为高级兼容入口。`发现` 同时合并全部已启用来源的 Plugin，并保留来源标签和即时搜索；未登录 GitLab 来源会直接进入 Device Flow，GitHub 公共来源无需登录。`来源` 页的“新增来源”可选择 GitHub 公共仓库或 GitLab Marketplace；GitHub 会先在临时缓存中下载固定快照、检测格式、展示可导入与忽略组件，确认后才保存。ref 留空时使用仓库默认分支；出现多个格式入口时会要求选择，公开 GitHub 跨仓 Marketplace 条目和 `plugins/*` 多 Plugin 仓库也可识别。
 
-可选通用技能包含 `aliyun-sls-query`，可为 Codex / Claude 项目安装零第三方依赖的阿里云 SLS 查询脚本与排障知识；默认不安装，也不会复制用户私有 AK/SK 配置。
+可选通用技能包含 `aliyun-dms-query` 与 `aliyun-sls-query`：前者通过阿里云 DMS 查询纳管数据库，并让写操作以数据变更工单进入审批流；后者提供零第三方依赖的阿里云 SLS 查询脚本与排障知识。两者都支持 Codex / Claude 项目，默认不安装，也不会复制用户私有 AK/SK 配置。
 
 安装、更新和卸载都会先展示 dry-run、依赖、capability 和目标文件变化，确认后才写入项目。Plugin 作者使用的 `plugin init`、`plugin validate` 继续保留在高级命令中，不占用普通用户的管理器首页。
 

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

@@ -1,6 +1,6 @@
 ---
 name: trellis-check-all
-description: "统一 Check-All 入口：确认范围与运行上下文，按 requested/effective depth 选择 light/full profile，执行三件套落地、实现假设、完整性与规范审查；低风险文档漂移可自动修复并在报告中列出，其它问题 collect-all 后一次确认修复范围。触发：检查、轻量检查、全面检查、提交前检查、check-all、从 PRD/三件套到代码过一遍。"
+description: "统一 Check-All 入口：确认范围与运行上下文，按 requested/effective depth 选择 light/full profile，执行三件套落地、实现假设、完整性与规范审查；区分主路径 CHK、兜底 FBK 与文档漂移 DOC，低风险文档漂移可自动修复。触发：检查、轻量检查、全面检查、提交前检查、check-all、从 PRD/三件套到代码过一遍。"
 ---
 # Check All 统一入口
 
@@ -15,7 +15,7 @@ description: "统一 Check-All 入口：确认范围与运行上下文，按 req
 1. 确认本轮检查范围、task artifacts 或 untracked state、项目规范和运行上下文。
 2. 解析 `requested_depth`，生成 `check_profile`，决定 `effective_depth=light|full`。
 3. 按有效深度读取并执行对应 profile。
-4. 全程收集普通问题到 `CHK-*`，收集低风险文档漂移到 `DOC-*`。
+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`。
@@ -29,8 +29,9 @@ description: "统一 Check-All 入口：确认范围与运行上下文，按 req
 1. 总是先读 `references/depth-routing.md`，完成范围、上下文和深度画像。
 2. `effective_depth=light` 时读 `references/light-profile.md`。
 3. `effective_depth=full` 时读 `references/full-profile.md`。
-4. 总是读 `references/document-drift-auto-remediation.md`，用于识别和处理 `DOC-*`。
-5. 输出报告或 runner 结果前读 `references/reporting-and-disposition.md`。
+4. 总是读 `references/fallback-findings.md`，用于区分 `CHK-*` 与 `FBK-*` 并执行兜底准入规则。
+5. 总是读 `references/document-drift-auto-remediation.md`，用于识别和处理 `DOC-*`。
+6. 输出报告或 runner 结果前读 `references/reporting-and-disposition.md`。
 
 如果引用文件缺失，停止并报告 `阻塞`；不要凭记忆复原规则。
 
@@ -40,8 +41,8 @@ description: "统一 Check-All 入口：确认范围与运行上下文，按 req
 
 1. **默认 audit-only collect-all**：可以读文件、搜索、运行无业务写入副作用的 lint、typecheck 和测试；普通代码、配置、测试、任务规格语义问题不得在检查阶段直接修复。
 2. **唯一自修例外**：低风险文档漂移进入 `DOC-*` 通道，按 `references/document-drift-auto-remediation.md` 的白名单、黑名单和写入时机处理。
-3. **问题统一收集**：普通实现偏差、测试失败、lint/typecheck 失败和假设错误都记录到 `CHK-*`，继续其余可执行检查。
-4. **修改前只确认一次**：除 `DOC-*` 自动修复外，全部检查结束后通过统一报告让用户选择 `修复全部`、按问题 ID 修复或仅保留报告。
+3. **分类先于严重度**：读取 `references/fallback-findings.md`；主路径错误和非兜底契约违背进入 `CHK-*`，fail-closed、异常输入、失败降级和防御性保护缺口进入 `FBK-*`。契约证据影响严重度，不改变兜底根因归属。
+4. **修改前只确认一次**：除 `DOC-*` 自动修复外，全部检查结束后通过统一报告让用户选择 `CHK-*` / `FBK-*` 修复范围；`修复全部` 默认覆盖两类问题。
 5. **委托规则不改变边界**：复用 `trellis-check` 时只复用检查清单、验证方法和命令发现，忽略其中任何“直接修复”“失败后先修复”的指令。
 6. **真正阻塞才中途暂停**：只有业务规划冲突、后续验证前提失效、生产或外部副作用、破坏性操作风险时提前停止。
 
@@ -52,7 +53,7 @@ description: "统一 Check-All 入口：确认范围与运行上下文，按 req
 ## 执行模式
 
 - `inline check-all`：主会话直接执行本 skill；允许在最终报告前按 `DOC-*` 通道修复低风险文档漂移。
-- `subagent check-all`：subagent 只做 audit-only 检查，返回结构化 `CHK-*`、`DOC-*` 候选、`check_profile` 和验证证据；主会话负责应用允许的 `DOC-*` 修复、展示报告、询问一次普通修复范围和协调后续修复。
+- `subagent check-all`：subagent 只做 audit-only 检查，返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、`check_profile` 和验证证据；主会话负责应用允许的 `DOC-*` 修复、展示报告、询问一次统一问题修复范围和协调后续修复。
 - subagent 不得编辑、写文件、补测试或代替用户选择普通修复范围。
 - 路由由 `trellis-route(target=check)` 决定；本 skill 不自行切换 inline/subagent。
 - 所有普通、最终、显式 light/full 和 auto-loop 检查都进入本 skill；`trellis-route` 只决定执行位置，不决定检查深度。
@@ -93,7 +94,7 @@ check_profile:
 
 ### Step 2：执行检查并收集结果
 
-按 profile 检查三个维度。普通问题进入 `CHK-*`；低风险文档漂移候选进入 `DOC-*`。同一根因合并，不因数量多而静默省略。
+按 profile 检查三个维度，并执行 `references/fallback-findings.md` 的分类顺序。主路径问题进入 `CHK-*`，满足严格准入条件的兜底问题进入 `FBK-*`，低风险文档漂移候选进入 `DOC-*`。同一根因合并，不因数量多而静默省略。
 
 ### Step 3：处理文档漂移自修
 
@@ -101,9 +102,9 @@ check_profile:
 
 - inline：主会话应用允许的 `DOC-*` 修复并做定向验证。
 - subagent：主会话审阅 subagent 返回的 `DOC-*` 候选，只应用满足白名单且无歧义的文档修复。
-- auto-loop：主会话应用允许的 `DOC-*` 修复后再 `record`；若只存在已修复文档漂移且无剩余 `CHK-*`，结果可为 `ok`，摘要必须包含自动修复说明。
+- auto-loop：主会话应用允许的 `DOC-*` 修复后再 `record`；若只存在已修复文档漂移且无剩余 `CHK-*` / `FBK-*`，结果可为 `ok`，摘要必须包含自动修复说明。
 
-不满足自动修复条件的文档问题转为 `CHK-*` 或剩余风险，按普通修复范围处理。
+不满足自动修复条件的文档问题根据根因转为 `CHK-*`、`FBK-*` 或剩余风险，按普通修复范围处理。
 
 ### Step 4：统一报告与分流
 
@@ -112,7 +113,7 @@ check_profile:
 - `check_profile`；
 - 三个维度状态；
 - 自动修复的 `DOC-*` 内容；
-- 剩余 `CHK-*` 问题；
+- 剩余 `CHK-*` 主路径问题与 `FBK-*` 兜底问题；
 - 已执行验证和未覆盖风险；
 - 与当前结论匹配的唯一下一步。
 
@@ -123,6 +124,9 @@ check_profile:
 - 入口默认加载 full profile，导致 `auto` 被 full 语气带偏。
 - 发现一个普通问题就暂停询问一次。
 - 把 `trellis-check` 的自动修复指令带入普通 `CHK-*`。
+- 先按严重度决定 `CHK-*` / `FBK-*` 通道，混淆根因性质与影响等级。
+- 把纯偏好、无具体场景或无法验证收益的“更健壮”建议记录为 `FBK-*`。
+- 因兜底行为已写入契约就把保护路径根因改列为 `CHK-*`。
 - subagent 直接修改工作区。
 - 把需求变更、验收标准、产品语义或设计取舍伪装成文档漂移自动修复。
 - light 未命中完整穷举条件仍继续 light。

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

@@ -94,7 +94,7 @@ check_profile:
 - 权限、鉴权、安全、资金、并发、时序、状态机或回滚；
 - workflow、skill、command、hook 注入或生成快照；
 - 安装、升级、发布、push/commit 工作流控制面；
-- 正在重检既有 full `CHK-*` 修复结果；
+- 正在重检既有 full `CHK-*` / `FBK-*` 修复结果；
 - light 执行中发现未知 dirty path、真实影响面扩大或关键验证缺口。
 
 **light eligibility 必须全部满足**：

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

@@ -18,7 +18,7 @@
 | 修复 | 精确说明要写入、更新或删除的内容 |
 | 验证 | 修复后的静态检查、链接检查或重读确认 |
 
-`DOC-*` 不占用 `CHK-*` 编号。自动修复失败或越界时，转成 `CHK-*` 或剩余风险。
+`DOC-*` 不占用 `CHK-*` 或 `FBK-*` 编号。自动修复失败或越界时，根据根因转成 `CHK-*`、`FBK-*` 或剩余风险。
 
 ---
 
@@ -47,7 +47,7 @@
 
 ## 禁止自动修复
 
-以下情况必须进入 `CHK-*`、剩余风险或阻塞，不得自动改：
+以下情况不得自动改，必须根据根因进入 `CHK-*`、`FBK-*`、剩余风险或阻塞：
 
 - PRD 需求、Acceptance Criteria、业务规则、UI 文案要求发生实质变更；
 - design 的 API、数据模型、数据流、rollback 或 tradeoff 需要重新决策；
@@ -61,7 +61,7 @@
 
 ## 写入时机
 
-1. 先完成所有可继续的检查，收集 `CHK-*` 和 `DOC-*`。
+1. 先完成所有可继续的检查，收集 `CHK-*`、`FBK-*` 和 `DOC-*`。
 2. 在最终报告前应用符合白名单的 `DOC-*` 修复。
 3. 修复后执行对应验证，例如重读文件、检查链接、确认路径存在或运行无副作用的静态命令。
 4. 报告中展示“自动修复”区，列出每个 `DOC-*` 的文件、修复内容和验证结果。
@@ -80,6 +80,6 @@ subagent 模式只返回 `DOC-*` 候选；主会话按同一规则决定是否
 
 ## 失败处理
 
-- 自动修复无法唯一确定：保留为 `CHK-*` 或剩余风险，等待用户确认。
-- 自动修复验证失败：记录为 `CHK-*`，报告失败文件和验证命令。
+- 自动修复无法唯一确定：根据根因保留为 `CHK-*`、`FBK-*` 或剩余风险，等待用户确认。
+- 自动修复验证失败：根据根因记录为 `CHK-*` 或 `FBK-*`，报告失败文件和验证命令。
 - 自动修复后发现影响面扩大：停止继续自修，按普通问题模型报告。

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

@@ -0,0 +1,69 @@
+# Fallback Findings
+
+本文件定义 `CHK-*` 主路径问题与 `FBK-*` 兜底问题的根因边界。分类发生在严重度评估之前；分类完成后，两类问题都根据当前实际影响分配 P0/P1/P2，并进入同一个修复与严格通过门禁。
+
+---
+
+## 分类顺序
+
+按以下顺序处理每个独立根因：
+
+1. 符合 `DOC-*` 自动修复白名单：交给文档漂移通道。
+2. 根因位于 fail-closed、异常输入、失败路径降级、防御性权限或数据保护、容错或故障可观测性保护：记录为 `FBK-*`。
+3. 根因位于主路径逻辑、非兜底需求或契约、验证、真实数据流、兼容性或发布集成：记录为 `CHK-*`。
+4. 证据不足以确认问题或保护场景：标记 `部分验证`、`阻塞` 或剩余风险，不得猜测分类。
+5. 只有风格偏好、主观重构建议或泛化“更健壮”表述，且没有具体可达场景与验证收益：不报告。
+
+契约是否明确不决定通道。即使 PRD、design、implement、spec 或公开契约已经要求某个兜底行为，只要根因仍是保护路径缺口，就记录为 `FBK-*`；该契约只用于加强证据、影响与严重度判断。
+
+---
+
+## `FBK-*` 根因范围
+
+以下根因优先归入 `FBK-*`：
+
+- fail-closed 保护缺失、失效、被绕过或错误回退为放行；
+- 畸形、缺失、重复、冲突、越界或未知输入没有按声明边界处理；
+- 外部依赖、读取、解析、迁移或平台能力失败时缺少受控降级；
+- 防御性权限、隐私、数据完整性、覆盖或删除保护存在缺口；
+- 有具体失败场景和验证方式的额外容错或故障可观测性兜底缺口。
+
+安全、权限或数据问题若根因不在保护路径，仍可归入 `CHK-*`。分类看根因，不看“安全问题通常更严重”之类标签。
+
+---
+
+## `FBK-*` 严格准入
+
+每个 `FBK-*` 必须同时具备：
+
+1. **具体位置**：可定位到文件、契约、命令结果或明确的数据流边界。
+2. **可达场景**：说明什么异常、失败或保护条件会触发，不能只写“理论上可能”。
+3. **问题证据**：证明当前保护缺失、错误或可被绕过；仅有改进想法不算证据。
+4. **保护收益**：说明修复后避免的错误放行、数据损害、权限扩大、失控失败或诊断盲区。
+5. **验证方式**：给出可执行测试、命令、故障注入或明确手动步骤。
+
+任一项缺失时，不得为了“先记下来”而生成 `FBK-*`。需要更多环境或业务证据时使用 `部分验证`、`阻塞` 或剩余风险；纯偏好直接不报告。
+
+---
+
+## `CHK-*` 根因范围
+
+以下根因归入 `CHK-*`：
+
+- 主路径功能逻辑错误、非兜底需求或公开契约违背；
+- lint、typecheck、测试失败，或缺少当前验收必需的验证；
+- 真实数据流断点、字段或类型不匹配、兼容性错误；
+- 发布、构建、集成或分发链路阻塞；
+- 无法归入具体保护路径的其它已证实问题。
+
+不得把修复困难、影响较低或场景少见当作改列 `FBK-*` 的理由。
+
+---
+
+## 严重度与处置
+
+- `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 路径。
+- `仅保留报告` 可以显式停止修复，但不能把未解决问题改写成通过。

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

@@ -120,6 +120,8 @@ full 提取所有适用条目。每条记录来源位置，实际阅读对应代
 
 验证失败时记录命令、退出状态和关键错误到统一问题集合，继续其它独立验证。可能写业务数据或外部系统的验证不直接运行，按真正阻塞规则处理。
 
+所有发现候选按 `references/fallback-findings.md` 先判定 `CHK-*` / `FBK-*`，再为两类问题分配严重度。严重度不得反向决定通道；不满足具体场景、证据、保护收益和验证方式的泛化建议不报告。
+
 ---
 
 ## Full 通过条件
@@ -129,4 +131,4 @@ Full 通过必须同时满足：
 - 所有适用 PRD / design / implement 条目已映射到实现或明确 `N/A`；
 - 所有触发的假设 Dimension 已完成源码或真实契约核对；
 - 项目规范、复用、依赖、同层一致性和验证命令已覆盖实际变更范围；
-- 无 `CHK-*`、无阻塞、无部分验证、无实质剩余风险。
+- 无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险。

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

@@ -59,6 +59,8 @@ untracked 上下文没有 task artifacts，本维度标记 `N/A`，不得根据
 
 在 Check-All 内执行时，`trellis-check` 中任何直接修复、补测试、反复修到通过的指令一律失效。验证失败记录为 `CHK-*` 并继续其它独立验证。
 
+所有发现候选按 `references/fallback-findings.md` 先判定 `CHK-*` / `FBK-*`，再为两类问题分配严重度。不得因场景极端、修复困难或影响较低改变根因通道；不满足兜底准入条件的泛化建议不报告。
+
 ---
 
 ## Light 通过条件
@@ -68,6 +70,6 @@ Light 通过必须同时满足：
 - 所有受影响规划条目已核对；
 - 所有触发的假设维度状态为 `通过` 或合理的 `N/A`；
 - 定向验证已运行并通过，或明确说明无需运行的原因；
-- 无 `CHK-*`、无阻塞、无部分验证、无实质剩余风险。
+- 无 `CHK-*`、无 `FBK-*`、无阻塞、无部分验证、无实质剩余风险。
 
 存在未覆盖但不影响局部结论的内容时，必须在“未覆盖与风险”中说明。

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

@@ -6,6 +6,10 @@
 
 ## 统一问题模型
 
+先按 `references/fallback-findings.md` 判定 `CHK-*` / `FBK-*`，再为两类问题分配 P0/P1/P2。分类表达根因性质，严重度描述当前实际影响；两者都不改变问题必须进入修复和 strict pass 门禁的处置规则。
+
+### `CHK-*` 主路径问题
+
 每个独立根因使用固定字段：
 
 | 字段 | 规则 |
@@ -20,7 +24,25 @@
 | 位置 | 同一根因的全部受影响位置 |
 | 验证 | 修复后的命令或手动验证步骤 |
 
-同一根因的多个位置合并到一个问题。报告按严重度排序，但不得因此重排已经分配的 ID。新根因使用下一个 ID。
+### `FBK-*` 兜底问题
+
+每个满足严格准入条件的独立兜底根因使用固定字段：
+
+| 字段 | 规则 |
+| --- | --- |
+| ID | 首次记录时依次分配 `FBK-001`、`FBK-002`；当前修复/重检循环中不重新编号 |
+| 严重度 | 与 `CHK-*` 使用同一 P0/P1/P2 影响尺度 |
+| 标题 | 描述具体保护路径根因，不写泛化“增强健壮性” |
+| 来源 | prd/design/implement/spec/assumption/verification |
+| 证据 | 保护缺失、错误或可绕过的 `file:line`、实际契约或命令结果 |
+| 兜底场景 | 可达的异常、失败、越权、数据损害或诊断盲区场景 |
+| 影响 | 当前缺口的用户、数据、安全或工程影响 |
+| 保护收益 | 修复后恢复或新增的明确保护结果 |
+| 建议 | 推荐修复方式，不在检查阶段执行 |
+| 位置 | 同一根因的全部受影响位置 |
+| 验证 | 修复后的测试、故障注入、命令或手动验证步骤 |
+
+`CHK-*` 与 `FBK-*` 分开编号。同一根因的多个位置合并到一个问题；报告按严重度排序，但不得因此重排已经分配的 ID。新根因使用对应通道的下一个 ID。
 
 ---
 
@@ -31,7 +53,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 ```markdown
 ## Trellis Check-All 结果
 
-[<通过/未通过/阻塞>] <N> 个维度 · CHK <N> · 自动修复 DOC <N> · P0 <N> / P1 <N> / P2 <N> · 验证 <通过>/<总数>
+[<通过/未通过/阻塞>] <N> 个维度 · CHK <N> · FBK <N> · 自动修复 DOC <N> · P0 <N> / P1 <N> / P2 <N> · 验证 <通过>/<总数>
 
 工作：<任务名称 | Untracked work: work-id | 无活动工作>
 范围：<文件数与层级摘要；包含自动修复产生的文档 diff>
@@ -40,11 +62,11 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 
 ### 维度结果
 
-| 维度 | 状态 | 问题 | 验证 |
-| --- | --- | ---: | --- |
-| 三件套实现 | <通过/未通过/部分验证/阻塞/N/A> | <N> | <摘要> |
-| 实现假设 | <通过/未通过/部分验证/阻塞/N/A> | <N> | <摘要> |
-| 完整性与规范 | <通过/未通过/部分验证/阻塞/N/A> | <N> | <摘要> |
+| 维度 | 状态 | CHK | FBK | 验证 |
+| --- | --- | ---: | ---: | --- |
+| 三件套实现 | <通过/未通过/部分验证/阻塞/N/A> | <N> | <N> | <摘要> |
+| 实现假设 | <通过/未通过/部分验证/阻塞/N/A> | <N> | <N> | <摘要> |
+| 完整性与规范 | <通过/未通过/部分验证/阻塞/N/A> | <N> | <N> | <摘要> |
 
 ### 自动修复
 
@@ -52,7 +74,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 | --- | --- | --- |
 | DOC-001 | <文件与修复内容> | <通过/失败/未执行> |
 
-### 问题清单
+### 主路径问题
 
 - [ ] `CHK-001` `[P1]` <标题>
   - 来源：<来源>
@@ -62,16 +84,28 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
   - 位置：<全部受影响位置>
   - 验证：<验证命令或步骤>
 
+### 兜底问题
+
+- [ ] `FBK-001` `[P1]` <标题>
+  - 来源：<来源>
+  - 证据：<file:line / 契约 / 命令结果>
+  - 兜底场景：<可达异常或失败场景>
+  - 影响：<影响>
+  - 保护收益：<修复后的明确保护结果>
+  - 建议：<修复建议>
+  - 位置：<全部受影响位置>
+  - 验证：<验证命令或步骤>
+
 ### 未覆盖与风险
 
 - [<部分验证/阻塞/N/A>] <说明>
 
 ### 修复批次
 
-批次 1：<问题 ID> · <修复目标>
+批次 1：<CHK/FBK 问题 ID> · <修复目标>
 修复后：定向验证 -> Check-All 重检
 
-操作：`修复全部`、`修复 CHK-001,CHK-003`、`仅保留报告`
+操作：`修复全部`、`修复 CHK-001,FBK-002`、`仅保留报告`
 
 ### 下一步
 
@@ -81,10 +115,12 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 展示规则：
 
 - 没有 `DOC-*` 自动修复时省略“自动修复”区。
-- 没有 `CHK-*` 时省略“问题清单”“修复批次”和操作行；如果存在自动修复，仍展示自动修复和验证。
-- 有 `CHK-*` 时只在报告末尾提供一次修复范围选择，不再逐项提问。
+- 没有 `CHK-*` 时省略“主路径问题”区；没有 `FBK-*` 时省略“兜底问题”区。
+- `CHK-*` 或 `FBK-*` 任一存在时展示“修复批次”，并只在报告末尾提供一次修复范围选择，不再逐项提问。
+- `修复全部` 始终覆盖全部 `CHK-*` 与 `FBK-*`；精确修复可以混合两类 ID。
+- `仅保留报告` 只表示停止修复，不改变未通过结论或剩余风险。
 - interactive 标准报告必须以“下一步”段结束；停止等待不等于省略引导。
-- 独立问题不得因数量多而静默省略；先合并同根因重复项，再完整列出剩余问题。
+- 独立 `CHK-*` 或 `FBK-*` 不得因数量多而静默省略；先合并同根因重复项，再完整列出剩余项。
 - 报告不得包含 commit message、拟提交/暂存文件、commit-only 决策或提交确认。
 - light 通过正式满足 Phase 2.2 检查门禁；未执行维度必须标记 `N/A`，不得伪装为已验证。
 
@@ -92,24 +128,25 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 
 ## 修复与重检
 
-用户选择修复范围后：
+用户选择 `修复全部`、混合精确问题 ID 或其它明确修复范围后：
 
 1. 主会话复用当前 task 已有的合法 implement route；untracked 则重新直接读取个人 pref。不存在合法 route 时进入 `trellis-route(target=implement)`，不得自行默认 inline/subagent。
 2. 修复过程中不对每个问题重复确认。
 3. 新增业务歧义、破坏性风险或范围扩张时才暂停，并一次性说明受影响问题。
 4. 完成定向验证后复用当前 check route 重新执行 Check-All。
-5. 原问题沿用 ID；新根因继续递增编号。上次 `effective_depth=full` 时，本次最小深度为 full。
+5. 原 `CHK-*` / `FBK-*` 沿用各自 ID；新根因在对应通道继续递增编号。上次 `effective_depth=full` 时，本次最小深度为 full。
 
 修复完成后输出：
 
 ```markdown
 ## Trellis Check-All 修复结果
 
-[<完成/部分完成/失败>] CHK 修复 <完成>/<计划> · DOC 自动修复 <N> · 验证 <通过>/<总数> · 剩余问题 <N>
+[<完成/部分完成/失败>] CHK 修复 <完成>/<计划> · FBK 修复 <完成>/<计划> · DOC 自动修复 <N> · 验证 <通过>/<总数> · 剩余 CHK <N> · 剩余 FBK <N>
 
 | 问题 | 修复 | 验证 |
 | --- | --- | --- |
 | CHK-001 | <已修复/未修复/阻塞> | <通过/失败/未执行> |
+| FBK-001 | <已修复/未修复/阻塞> | <通过/失败/未执行> |
 | DOC-001 | <已自动修复/未修复/阻塞> | <通过/失败/未执行> |
 
 ### 未修复与风险
@@ -123,9 +160,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-*` 时停留在修复/重检循环。
+检查通过后的动作由下方 `Interactive Post-Check Stop Gate` 判断：普通交互停止等待，符合 direct Git 严格通过条件时同轮进入 Phase 3.3 `trellis-update-spec`，再到 Phase 3.4 `trellis-push`。仍有 `CHK-*` 或 `FBK-*` 时停留在修复/重检循环。
 
-untracked helper 不记录 Check-All 证据。普通严格通过但尚未继续时保持 `stage=check`；只有 direct Git 同轮继续或用户后续明确继续时才 `advance --stage spec`。有 findings、部分验证、阻塞或报告后的新编辑时，先 `advance --stage implement` 再返回实现。
+untracked helper 不记录 Check-All 证据。普通严格通过但尚未继续时保持 `stage=check`；只有 direct Git 同轮继续或用户后续明确继续时才 `advance --stage spec`。有剩余 `CHK-*`、`FBK-*`、部分验证、阻塞或报告后的新编辑时，先 `advance --stage implement` 再返回实现。
 
 ---
 
@@ -134,13 +171,13 @@ untracked helper 不记录 Check-All 证据。普通严格通过但尚未继续
 validated auto-loop 复用相同的画像、profile、`DOC-*` 通道和问题模型，但不展示普通模式的修复选择：
 
 - 有 `DOC-*` 且可自动修复：主会话先应用并验证；当前任务 `implement.md` / `brief.md` 的每个实际变化都追加精确 `--doc-remediation-file`，再决定最终 `ok|failed|blocked`。
-- 有剩余 `CHK-*`：向 runner `record --result failed --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含最高严重度、问题 ID、根因、受影响文件和已自动修复的 `DOC-*`。
+- 有剩余 `CHK-*` 或 `FBK-*`：向 runner `record --result failed --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含最高严重度、两类问题 ID、根因、受影响文件和已自动修复的 `DOC-*`。
 - 真正需要用户产品决策、越权、生产副作用或破坏性安全决策：使用同样深度字段 `record --result blocked`，随后按 runner 状态停止。
-- 无剩余问题：`record --result ok --effective-check-depth <light|full> --check-depth-reason <summary>`，摘要包含自动修复数量。
+- 无剩余 `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 不渲染交互式下一步段、不提示用户回复“继续”、不等待普通修复范围选择。
 - 不修改 runner 的 fix/recheck 预算、commit-only 授权或队列行为。
 
-subagent 只返回结构化报告、`DOC-*` 候选和 `check_profile`；主会话收到后必须完成允许的 `DOC-*` 处理，再完成匹配 action 的 `record + next`。
+subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `check_profile`；主会话收到后必须完成允许的 `DOC-*` 处理，再完成匹配 action 的 `record + next`。
 
 ---
 
@@ -149,15 +186,15 @@ subagent 只返回结构化报告、`DOC-*` 候选和 `check_profile`；主会
 非 validated auto-loop 先输出完整标准报告，再在本 Gate 内按以下顺序分流：
 
 1. 只从触发本轮完成链的最新用户消息识别 direct Git intent：明确请求普通 push，或用户主动 `commit-only`。不得从历史消息、任务标题、摘要、dirty 状态或 auto-loop 内部 action 推断。
-2. direct Git 只有在 Check-All 整体结论通过、剩余 `CHK-*` 为 0、无阻塞、无部分验证、无待用户接受的实质剩余风险时才算严格通过。允许存在已成功验证的 `DOC-*` 自动修复；标准报告输出后，同一轮进入 Phase 3.3 `trellis-update-spec`；`no-op|written` 再由其加载 `trellis-push`，`needs-review` 停止。
-3. findings、blocked、部分验证或实质剩余风险均不满足条件：输出标准报告并停止，不运行 Update-Spec，也不生成 Git 计划。原始 Git 请求不授权自动修复普通问题、忽略问题或扩大 Git 权限。
+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 权限。
 4. 没有匹配 direct Git intent 的普通 interactive 检查保持原行为：报告后立即停止并等待用户选择。
 
 ### 交互式下一步引导
 
 所有 interactive 标准报告都必须在末尾输出 `### 下一步`，并按以下首个命中分支给出一个明确主动作：
 
-1. 有剩余 `CHK-*`：提示用户回复 `修复全部`、精确问题 ID 或 `仅保留报告`；不得重复提出逐项确认。
+1. 有剩余 `CHK-*` 或 `FBK-*`：提示用户回复 `修复全部`、混合精确问题 ID 或 `仅保留报告`；不得重复提出逐项确认。
 2. 有 blocked、部分验证或实质剩余风险：指出解除阻塞所需的精确决策、授权或验证，以及完成后重新运行 Check-All；涉及生产、外部系统或破坏性副作用时只引导用户授权，不自行执行。
 3. direct Git 严格通过：说明本轮正在进入 `trellis-update-spec`，不要求用户再次回复“继续”或确认 Git 计划。
 4. 无 direct Git intent 且严格通过：提示用户回复 `继续`，下一轮进入 `trellis-update-spec`，再由 `trellis-push` 生成提交计划。
@@ -167,10 +204,11 @@ subagent 只返回结构化报告、`DOC-*` 候选和 `check_profile`；主会
 允许 Check-All 标准报告输出的内容只有：
 
 - 各维度状态、问题数和问题清单；
+- `CHK-*` 主路径问题和 `FBK-*` 兜底问题的证据、影响与验证；
 - `DOC-*` 自动修复内容和验证；
 - 已执行验证及结果；
 - 未覆盖验证和剩余风险；
 - 总体结论；
-- 与当前结论匹配的唯一主动作引导；有问题时是一次修复范围选择，部分验证/阻塞时是补充决策或验证，通过时是 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-flower-update/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: trellis-flower-update
+description: "手动检查和执行已安装 Flower/Trellis 强化包升级。用于用户明确要求更新或升级 flower-trellis、Flower、Trellis 强化包、skill-garden 快照、项目 flower 版本追平，或自动更新提示被稍后/跳过后仍想在对话里升级时。不要用于用户说想发版、发布版本、release、打 tag、npm publish 或修改 package 版本号；这些属于项目发版流程。"
+---
+
+# Trellis Flower Update
+
+用于用户主动要求升级已安装的 Flower/Trellis 强化层时。自动 SessionStart 提示的 snooze、skip 和 cooldown 只是不主动打扰，不能阻止用户显式要求升级。
+
+本 skill 不是发版入口。用户说“我想发版了”、release、打 tag、npm publish、更新 package 版本号或准备发布包时，不使用本 skill；按当前项目的 release SOP、`trellis-release` 或发布规范处理。
+
+## Workflow
+
+1. 确认目标项目。用户给出路径时使用该路径，否则使用当前工作目录。
+2. 运行人工检查，默认强制刷新远端版本证据：
+
+```bash
+flower-trellis self-check --json --manual --force-remote --target <target>
+```
+
+3. 解析 JSON：
+   - `update_available`：展示当前版本、推荐版本、release notes 摘要和 `commands.recommended`。
+   - `project_out_of_sync`：展示当前 Flower/Trellis 与项目记录的差异，并展示 `commands.recommended`。
+   - `up_to_date`：说明当前安装和项目记录已一致。
+   - `disabled` / `offline` / `skipped`：说明原因；不要靠重置缓存伪造可执行状态。
+4. 写入前遵守确认和安全门槛：
+   - 用户当前消息已经明确要求执行升级时，可以执行 `commands.recommended`。
+   - 用户只是询问、查看或比较版本时，只展示结果并等待确认。
+   - `safety.reasons` 非空时，先说明风险，再等待用户明确确认。
+5. 执行推荐命令后读取 `<flower-update-result>`。如果结果要求 `run_trellis_push_confirmation`，进入 `trellis-push`，展示文件和 commit message 后等待确认。
+
+## Rules
+
+- 不直接读写 `.flower/update-check.tmp`。
+- 不使用 `update-check reset`、`snooze` 或 `skip` 作为升级绕过手段。
+- 不运行 `npm run release`、不打 tag、不 publish，也不修改 `package.json` 版本号。
+- 不把 `self-check --manual` 用在 SessionStart 自动 hook；自动路径必须继续尊重提示节流。
+- 目标项目有脏文件、活动任务或命令缺失时，按 `safety.reasons` 报告并等待用户确认。

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` 或 `部分验证`。没有可验证的当前报告时使用 `未运行`，不得从历史消息、摘要或 dirty 状态猜测通过。
+- Check-All：根据当前标准报告与实际 diff 标记为 `通过`、`未运行`、`已失效`、`存在阻断 findings`、`blocked` 或 `部分验证`。只有剩余 `CHK-*` 与 `FBK-*` 均为 0 才能标记为 `通过`；没有可验证的当前报告时使用 `未运行`，不得从历史消息、摘要或 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：<通过 / 未运行 / 已失效 / 存在阻断 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 正文；`未运行`、`已失效`、findings、blocked、部分验证或 `needs-review` 同时计入风险区。
+- 完成链证据始终显示当前状态，但不重复 Check-All 报告或 Spec review 正文；`未运行`、`已失效`、任一剩余 `CHK-*` / `FBK-*`、blocked、部分验证或 `needs-review` 同时计入风险区。
 - 无活动 task、untracked 或 `commit-only` 时省略进度动作。
 - 不重复展示检查结果、规范复核、归档或其他阶段的详细信息。
 - 生成前无法确定的内容和增删行写“生成后计算”，不得填预测值。

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

@@ -200,7 +200,7 @@ helper 写入规则：保留另一个 target 的 runtime 决策和偏好；覆
 | `inline implement` | `Skill({skill: "trellis-before-dev"})` 加载 spec；task 再读任务文档，untracked 读取 helper 状态与实际 scope → 主线程实施 → 跑必要验证 → 回到 Phase 2.1 completion contract |
 | `subagent implement` | 按下方当前平台执行配方调用 `trellis-implement`；task 使用 `Active task:`，untracked 使用下方自包含 `Untracked work:` 契约；主 agent 收到结果后回到 Phase 2.1 completion contract |
 | `inline check-all` | `Skill({skill: "trellis-check-all"})` |
-| `subagent check-all` | 读取 catalog 当前平台条目，只调用 `checkAll.target` 声明的专用 audit-only `trellis-check-all` 角色，并按 `checkAll.launch` 启动；subagent 只返回 `CHK-*` / `DOC-*` 候选，不写文件。目标缺失、host 未发现或资格不成立时停止并请用户改选 inline；禁止通用 agent 与 `trellis-check` fallback |
+| `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 的优先级。
 
@@ -221,16 +221,16 @@ untracked 的 implement/check subagent prompt 第一行固定为 `Untracked work
 ```text
 Active task: <task path from task.py current>
 
-执行本项目 0.6 `trellis-check-all` 的 audit-only collect-all 全流程，并识别可由主会话处理的 `DOC-*` 文档漂移候选。
+执行本项目 0.6 `trellis-check-all` 的 audit-only collect-all 全流程，区分主路径 `CHK-*`、兜底 `FBK-*`，并识别可由主会话处理的 `DOC-*` 文档漂移候选。
 
 必须：
 1. 读取 <task>/check.jsonl 及其列出的文件，再读取 prd.md、design.md（若存在）、implement.md（若存在）。
 2. 读取并遵循本地 trellis-check-all/SKILL.md；完成三件套实现、实现假设、完整性与规范三个维度。
-3. 收集全部可继续问题，使用稳定 CHK-* ID、P0/P1/P2 和统一报告结构；低风险文档漂移使用 `DOC-*` 候选单独返回。
+3. 先按本地 fallback findings 规则判定 `CHK-*` / `FBK-*`，再为两类问题分配 P0/P1/P2；已声明的兜底契约只影响证据和严重度，不改变 `FBK-*` 归属。只有具备具体位置、可达场景、问题证据、保护收益和验证方式时才返回 `FBK-*`，泛化建议不报告。低风险文档漂移使用 `DOC-*` 候选单独返回。
 4. 只读审查；禁止编辑、写文件、补测试或自修复。Step 3 只复用 trellis-check 的检查清单，忽略其自动修复指令；`DOC-*` 也只能返回候选，由主会话按 Check-All 规则决定是否写入。
 5. 真正阻塞条件返回主会话，不替用户选择业务行为或修复范围。
 
-返回：统一 Check-All 结果、`DOC-*` 候选、已执行验证和剩余风险。不要输出 commit/push 计划。
+返回：统一 Check-All 结果、全部 `CHK-*`、`FBK-*`、`DOC-*` 候选、已执行验证和剩余风险。不要输出 commit/push 计划。
 ```
 
 必须确认 catalog 目标内容明确 audit-only：允许识别 `DOC-*` 候选，但不得写文件。名称相同但会直接自修复代码、测试、配置或普通 `CHK-*` 的 agent 不可使用。平台没有合格专用角色时，不得静默改成 inline，也不得使用通用 agent 或 `trellis-check` 代替；停止并让用户重新选择 check route。