flower-trellis 0.6.5 → 0.6.7

package/README.md

@@ -184,9 +184,13 @@ flower-trellis plugin
 |------|------|
 | `.flower/plugins.json` | 可提交;只记录用户直接声明的 Plugin |
 | `.flower/plugin-lock.json` | 可提交;记录固定版本、完整依赖图、来源与完整性摘要 |
+| `.flower/.gitignore` | 可提交;保护本机数据并放开共享记录 |
 | `.flower/state.json` | 本机;记录实际平台、生成路径、ownership 与 Patch provenance |
+| `.flower/settings.json` | 本机;保存个人更新偏好 |
 | `.flower/cache/`、`.flower/transactions/` | 本机;可清理缓存与事务恢复证据 |
 
+安装或升级内置 Skill-Garden 时，已有根 `.gitignore` 会幂等维护 Flower 共享规则，允许正常提交上述声明、锁和局部忽略文件；重复升级不会重复添加。状态、个人设置和缓存仍被忽略，不会自动暂存或提交。根 `.gitignore` 不存在时不额外创建它。
+
 `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 诊断，不会转成登录提示。
@@ -218,7 +222,7 @@ flower-trellis plugin validate .flower-plugin --subject plugin --json
 flower-trellis plugin add flower/flower-plugin-author --platform codex --json
 ```
 
-旧 `.trellis/.flower-manifest.json` 只作为迁移证据读取。下一次完整 init/update 会把期望、锁定和本机状态迁移到 `.flower/`,保留旧文件供核对;普通 `flower-trellis update` 重放已锁定版本,只有显式 `plugin update` 才解析外部 Plugin 新版本。
+旧 `.trellis/.flower-manifest.json` 在下一次增强安装或升级时完成一次迁移：保留必要的更新策略和缓存，写入现代记录后事务性删除旧文件，失败恢复。现代配置优先；显式 `--no-enhance` 不提前删除未经迁移的旧记录。普通 `flower-trellis update` 重放已锁定版本，只有显式 `plugin update` 才解析外部 Plugin 新版本。
 
 ### 升级备份保留
 
@@ -251,12 +255,16 @@ flower-trellis plugin add flower/flower-plugin-author --platform codex --json
 - Codex:向 `.codex/hooks.json` 的 `SessionStart` 追加 `.trellis/scripts/flower_update_hook.py`。
 - Claude Code:只向 `.claude/settings.json` 的 `SessionStart` `startup` matcher 追加该 hook,不挂 `clear` / `compact`。
 
-启动 hook 不会直接安装 npm 包,也不会直接改项目文件。它只调用:
+启动 hook 不会直接安装 npm 包，也不会直接改项目文件。它先检查本机 CLI；CLI 可用时继续调用：
 
 ```bash
 flower-trellis self-check --json --target .
 ```
 
+团队成员克隆已提交升级文件的项目后，即使没装 Flower CLI，同一 Python hook 也会读取项目锁并注入 `<flower-cli-bootstrap>`。助手先展示锁定版本和 `npm install -g flower-trellis@<版本>`，成员确认后才安装，验证 CLI 后继续原请求。全局安装沿用现有的本机 Trellis 命令同步，不隐式升级项目内容。版本未知、缺少 Node/npm 或安装失败时会说明原因，不猜 latest、不自动提权、不循环安装。
+
+自动入口需要 Python 可用且 Codex/Claude 启用 hooks；其他平台可通过 `trellis-flower-update` 调用同一检测脚本的 `--bootstrap-only` 模式。成员拒绝安装后，本次对话不重复追问。
+
 发现可更新或项目已铺版本不一致时,向 AI 注入 `<flower-update>` 上下文。无更新、离线、关闭检查、npx 临时运行时默认不打扰;同一更新提示会按本机提示节流状态降噪。
 
 检查分两层:
@@ -296,7 +304,7 @@ tmp 中保存本地运行缓存:
 }
 ```
 
-旧项目如果已经在 manifest 的 `updateCheck` 里带有缓存字段,新版本会先读取兼容,并在下一次写入时清理这些旧字段。
+旧项目 manifest 的 `updateCheck` 在升级前仍可兼容读取；增强迁移成功后必要配置转入现代位置，旧 manifest 文件删除。
 
 `policy` 可选:
 
@@ -353,7 +361,7 @@ flower banner → 平台多选菜单 → Trellis 原生交互(模板 / monorepo
 
 - **统一品牌头部**:Trellis 子进程在伪终端(`node-pty`)中运行,其原生的模板 / monorepo / 冲突等交互完整保留,但重复打印的启动 banner 被过滤,全程只呈现一个 flower banner。
 - **按平台铺设技能**:Claude 铺到 `.claude/skills`,Codex / Gemini 等铺到 `.agents/skills`;并做平台后处理:Codex 兼容清理旧 `config.toml` 的 `[features.multi_agent_v2]`,在保留上游 hooks 的基础上补全 `SessionStart`;Claude Code 只在 `startup` SessionStart 挂载启动更新检查。
-- **幂等执行**:0.6 Patch 使用受管 marker 原位升级，完整预检通过后只写 changed 文件，首次修改前备份到 `.trellis/.backup-flower/`；技能资产覆盖式铺设，并通过 `.trellis/.flower-manifest.json` 精确清理已淘汰路径。0.5/old 继续使用兼容注入路径。
+- **幂等执行**:0.6 Patch 使用受管 marker 原位升级，完整预检通过后只写 changed 文件；技能资产和现代 `.flower/state.json` 记录进入同一插件事务，通过路径 ownership 与摘要精确清理淘汰内容。0.5/old 继续使用兼容注入路径，旧 manifest 只用于迁移识别。
 - **结构化 Patch**:Trellis 0.6 的 workflow、skill、hook 与平台配置统一通过 `insert / replace / remove` 预检后应用；selector/baseline 或已知最终协议冲突时在写入前停止。
 - **上线事项账本**:强化包通过 Finish-Work Patch 在归档前智能识别 SQL、配置、批处理 / 部署脚本 / 数据修复、外部系统 / 依赖平台等上线事项,必要时写入任务 `release.md`;`trellis-release` 可在正式上线前核对任务文档、`release.md` 和 git 证据,生成 `YYYY-MM-DD-<release-slug>.md` 格式的版本 / 批次操作单。
 - **安全中止**:`Ctrl+C` 取消后不会继续叠加。

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

@@ -10,18 +10,6 @@ description: "统一 Check-All：按 requested/effective depth 路由 light/full
 
 ---
 
-## 入口职责
-
-1. 确认本轮检查范围、task artifacts 或 untracked state、项目规范和运行上下文。
-2. 解析 `requested_depth`，生成 `check_profile`，决定 `effective_depth=light|full`。
-3. 按有效深度读取并执行对应 profile。
-4. 按根因把发现分为 `CHK-*`、`FBK-*`、`DOC-*`，再为前两类分配 P0/P1/P2。
-5. 报告前处理允许自修的事实漂移并展示结果。
-6. 按 interactive / validated auto-loop 边界输出下一步或执行 `record + next`。
-7. untracked helper 只存游标：findings 或新编辑回 `implement`；通过且 disposition 继续时才 `advance --stage spec`。
-
----
-
 ## 必读引用
 
 按需加载引用文件，不要提前读取未命中的 profile：
@@ -43,7 +31,7 @@ description: "统一 Check-All：按 requested/effective depth 路由 light/full
 2. **唯一自修例外**：低风险事实漂移进入 `DOC-*` 通道，按 `references/document-drift-auto-remediation.md` 的白名单、黑名单和写入时机处理。
 3. **分类先于严重度**：读取 `references/fallback-findings.md`；主路径错误和非兜底契约违背进入 `CHK-*`，fail-closed、异常输入、失败降级和防御性保护缺口进入 `FBK-*`。契约证据影响严重度，不改变兜底根因归属。
 4. **处置只确认一次**：统一报告后选择 `CHK-*` / `FBK-*` 修复范围或接受风险；`修复全部` 覆盖两类，接受风险不得隐藏发现。
-5. **委托不改边界**：复用 `trellis-check` 的清单和验证方法，忽略其直接修复指令。
+5. **共享验证**：两个 profile 共用 `references/verification.md`；同一追踪与有效验证证据跨维度复用，检查保持只读。
 6. **真正阻塞才中途暂停**：业务规划冲突、前提失效，或当前结论必需验证涉及未授权生产/外部/破坏性副作用时暂停；发布后验收只记 `[上线后验证]`，不执行、不阻断。
 
 中途停止时也要使用统一问题模型，报告已完成范围和阻塞原因；只询问解除阻塞所需的业务或安全决策。
@@ -74,18 +62,11 @@ description: "统一 Check-All：按 requested/effective depth 路由 light/full
 
 ## 顶层流程
 
-### Step 0：范围、上下文与深度画像
+untracked helper 只存游标：findings 或新编辑回 `implement`；通过且 disposition 继续时才 `advance --stage spec`。
 
-读取 `references/depth-routing.md` 并执行完整 Step 0。输出固定画像：
+### Step 0：范围、上下文与深度画像
 
-```yaml
-check_profile:
-  context: interactive | auto-loop
-  requested_depth: auto | light | full
-  effective_depth: light | full
-  confidence: high | fallback-full | escalated
-  reasons: [string]
-```
+执行 `references/depth-routing.md` 的完整 Step 0，按其格式生成 `check_profile`。
 
 ### Step 1：读取对应 profile
 
@@ -98,17 +79,13 @@ check_profile:
 
 ### Step 3：处理事实漂移自修
 
-读取 `references/document-drift-auto-remediation.md`。在最终报告前：
-
-- inline：主会话应用允许的 `DOC-*` 修复并做定向验证。
-- subagent：主会话审阅 subagent 返回的 `DOC-*` 候选，只应用满足白名单且无歧义的修复。
-- auto-loop：主会话应用允许的 `DOC-*` 修复后再 `record`；若只存在已修复事实漂移且无剩余 `CHK-*` / `FBK-*`，结果可为 `ok`，摘要必须包含自动修复说明。
+按 `references/document-drift-auto-remediation.md` 的白名单和证据规则，由主会话处理允许的 DOC 并定向验证；subagent 仅返回候选。完成后再报告或交给 reporting reference 的 auto-loop 分流。
 
 不满足自动修复条件的文档问题根据根因转为 `CHK-*`、`FBK-*` 或剩余风险，按普通修复范围处理。
 
 ### Step 4：统一报告与分流
 
-读取 `references/reporting-and-disposition.md`。报告必须展示：
+读取 `references/reporting-and-disposition.md`。报告先自然说明实际改动及行为影响，再展示：
 
 - `check_profile`；
 - 三个维度状态；
@@ -123,12 +100,10 @@ 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/full-profile.md

@@ -1,6 +1,6 @@
 # Full Profile
 
-Full 是完整验收映射和全影响面审查。只有 `check_profile.effective_depth=full` 时读取本文件。
+Full 是完整验收映射和全影响面审查。只有 `check_profile.effective_depth=full` 时读取本文件；共享验证规则见 `references/verification.md`。
 
 ---
 
@@ -12,9 +12,9 @@ untracked 上下文没有 task artifacts，本 Step 标记 `N/A`；不得把 sum
 
 - PRD Requirement / Acceptance Criteria：行为基线。
 - Design API、数据模型、数据流、关键决策和 rollback：技术基线。
-- Implement 有序步骤、review gate 和 rollback point：落地基线。
+- Implement 中未被前两者覆盖的产物、review gate 和 rollback point：补充基线。
 
-full 提取所有适用条目。每条记录来源位置，实际阅读对应代码后再判断。
+full 提取所有适用条目。同一行为在多份文档中重复出现时合并验收，保留全部来源位置；不同约束、边界场景或相互冲突的要求不得合并丢失。实际阅读对应代码后再判断。
 
 ### 1.2 必查类型
 
@@ -22,7 +22,7 @@ full 提取所有适用条目。每条记录来源位置，实际阅读对应代
 | --- | --- |
 | `prd.md` | AC、需求、业务规则、UI 文案、边界和异常场景 |
 | `design.md` | API 路径/方法/字段、数据模型、数据流、关键 tradeoff、rollout/rollback |
-| `implement.md` | 有序步骤是否落地、review gate 是否满足、rollback point 是否可用 |
+| `implement.md` | 补充产物是否落地、review gate 是否满足、rollback point 是否可用；不重复核对已覆盖的实现步骤 |
 
 `implement.md` 中的 validation command 在本步骤只做静态前提核对；真实运行归 Step 3。
 
@@ -41,6 +41,8 @@ full 提取所有适用条目。每条记录来源位置，实际阅读对应代
 
 文案要求逐字一致时，对照最终有效文案来源；不要强制要求文案必须直接写在组件字面量中。
 
+同一条调用链只追踪一次，记录实现位置和关键边界证据，供 Step 2 与 Step 3 复用。后续只补尚未覆盖的约束、调用方、异常分支或失效证据；不得因复用而跳过独立的验收判断。
+
 ### 1.4 记录结果
 
 发现偏差、缺失、部分实现或文案不一致时，写入统一问题集合并继续。不要在此步骤询问“先修还是继续检查”。
@@ -49,14 +51,14 @@ full 提取所有适用条目。每条记录来源位置，实际阅读对应代
 
 ## Step 2：实现假设验证
 
-根据实际变更选择适用 Dimension。每个适用 Dimension 都要确认源码或真实契约证据，不能凭记忆通过。
+根据实际变更选择适用 Dimension。每个适用 Dimension 都要确认源码或真实契约证据，不能凭记忆通过。先复用 Step 1 的追踪结果，再核对本维度新增的约束；验证命令需求统一交给 Step 3，不在各 Dimension 分别运行。
 
 ### Dimension A：API Contract
 
 **Trigger**：新增或修改已有 API 调用、请求参数或响应解析。
 
 - 读取 Controller/Handler 和 DTO/Schema，确认实际请求、响应结构。
-- 找到项目内同 API 或同模式调用作为参考。
+- 契约仍有歧义时，补查项目内同 API 或同模式调用。
 - 确认参数名、类型、默认值、分页字段和起始页码。
 - 覆盖正常、空值、零值和错误响应。
 
@@ -67,7 +69,7 @@ full 提取所有适用条目。每条记录来源位置，实际阅读对应代
 - 确认容器关闭或切换时是否销毁子组件。
 - 确认受控值、初始化值和外部状态绑定。
 - 确认状态保持/重置行为符合规划。
-- 对照项目内相同容器的既有用法。
+- 状态约定仍不明确时，补查项目内相同容器的既有用法。
 
 ### Dimension C：Data History
 
@@ -87,54 +89,13 @@ full 提取所有适用条目。每条记录来源位置，实际阅读对应代
 - 覆盖缺省、空值、零值、特殊字符和错误传播。
 - 分层代码分别正确不等于整条链路正确，必须连起来核对。
 
-### Dimension E：Verification Tests
-
-**Trigger**：Dimension A-D 任一适用。
-
-- 自动化测试优先；可重复的手动步骤、静态检查或定向命令也可作为验证证据。
-- 优先覆盖最脆弱的参数名、嵌套结构、历史数据和空值路径。
-- 测试存在时实际运行；未运行不能报告通过。
-- 仅缺少自动化测试文件不得生成 `CHK-*`；项目 spec、风险等级或回归概率明确要求自动化覆盖时，缺失测试仍记录问题。
-- 缺少完成当前结论所必需的充分证据时记录 `CHK-*`，等待用户确认修复范围后再补充验证或测试。
-
 发现假设错误时写入统一问题集合并继续其它可执行检查。只有该错误让后续检查前提失效时，才按“真正阻塞”规则暂停。
 
 ---
 
 ## Step 3：完整性、规范与项目验证
 
-读取 `.agents/skills/trellis-check/SKILL.md`（Claude-only 项目读取对应 `.claude` 副本），复用以下内容：
-
-- 适用 spec 的读取方法；
-- lint、typecheck、测试等项目验证命令；
-- 测试覆盖、跨层数据流、复用、依赖和同层一致性检查；
-- debug logging、warning suppression 和类型安全绕过检查。
-
-### Audit-Only 覆盖规则
-
-在 Check-All 内执行时，下列 `trellis-check` 指令一律失效：
-
-- “Fix any failures before proceeding”；
-- “fix them directly”；
-- “Report and Fix”；
-- 任何要求检查 agent 直接编辑、补测试或反复修到通过的语句。
-
-验证失败时记录命令、退出状态和关键错误到统一问题集合，继续其它独立验证。可能写业务数据或外部系统的验证不直接运行：当前结论所必需且提交前原则上可完成时标记阻断型 `部分验证` 或 `阻塞`；本质依赖部署后、生产环境或真实外部状态时登记 `[上线后验证]`，不得自动执行。
-
-### Maven Evidence 复用
-
-实际变更位于 Maven reactor 时，按 `maven_verify.py` 的 evidence schema 只读执行：
-
-```bash
-python3 ./.trellis/scripts/maven_verify.py check --latest --require-plan <final-plan.json>
-```
-
-- `reusable`：核对 lifecycle、模块、消费者、测试、附属制品和 skip 项后纳入验证证据。
-- `partial`：记录未覆盖的 module/consumer/test/artifact 或更高 lifecycle 要求。
-- `stale`：记录源码、测试、POM、外部父 POM、Git 或工具链失效原因。
-- `failed` / `blocked`：保留命令退出或证据损坏事实，不把未执行验证写成通过。
-
-Check-All 与 dedicated subagent 都是 audit-only：不得调用 `maven_verify.py plan/run`，不得运行任何会写 `target/`、本地仓库或缓存的 Maven goal。缺少可复用 evidence 时，输出由主会话或 implement 路径执行的精确重跑计划需求；不得默认 `clean package/install`、`-amd` 或全 reactor。
+执行 `references/verification.md` 的共享清单，汇总 Step 1/2 和项目 spec 的验证需求，复用有效证据并只执行未覆盖的必要命令。数据流沿用前两步证据，不重新完整追踪。
 
 所有发现候选按 `references/fallback-findings.md` 先判定 `CHK-*` / `FBK-*`，再分配严重度。严重度不得反向决定通道；不满足三项硬准入的泛化建议不报告，保护收益或验证环境不完整则保留 FBK 并标记报告缺口。
 

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

@@ -1,18 +1,14 @@
 # Light Profile
 
-Light 是局部且可穷举的检查，不是“少看一点”的检查。只在 `check_profile.effective_depth=light` 时读取本文件。
+Light 是局部且可穷举的检查，不是“少看一点”的检查。只在 `check_profile.effective_depth=light` 时读取本文件；共享验证规则见 `references/verification.md`。
 
 ---
 
 ## 适用边界
 
-只有同时满足以下条件才继续 light：
+沿用 depth-routing 的 light 准入：闭合的语义范围、可穷举的规划与引用/状态/回归路径、无行为性 hard-full；载体名称不得单独触发升级。有定向验证，或变更确定不改变行为。
 
-- 变更属于闭合的语义范围；同一真实源的多个机械投影可归入该范围；
-- 受影响规划条目、直接引用点、状态传播和回归路径能完整列出；
-- 没有行为性 hard-full 信号，载体名称不得单独触发升级；
-- 有定向验证，或变更确定不改变行为；
-- 承接既有 full 报告的局部修复时，原 finding、修复路径、直接引用点和回归路径均可闭合，且定向验证足以覆盖后续 diff。
+承接既有 full 报告的局部修复时，原 finding、修复路径和回归范围须闭合，定向证据须覆盖后续 diff。
 
 执行中发现任一边界不成立，记录升级原因，切换到 `references/full-profile.md`。
 
@@ -22,15 +18,17 @@ Light 是局部且可穷举的检查，不是“少看一点”的检查。只
 
 untracked 上下文没有 task artifacts，本维度标记 `N/A`，不得根据事项摘要伪造验收条目；直接进入实现假设和完整性/规范检查。
 
-只提取受影响的 PRD / design / implement 条目。每条必须记录来源位置，并阅读对应实现后判断：
+只提取受影响的 PRD / design / implement 条目。同一行为合并验收并保留全部来源位置；不同约束、边界场景或冲突要求不得合并丢失。阅读对应实现后判断：
 
 - 需求、AC、业务规则是否被本次局部变更影响；
 - design 中相关 API、字段、数据流、rollback 是否仍成立；
-- implement 中与本次 diff 直接相关的步骤是否落地；
+- implement 中与本次 diff 直接相关、且前两者未覆盖的产物、review gate 和 rollback point 是否落地；
 - UI 文案要求逐字一致时，对照最终有效文案来源。
 
 未被本次变更触达且无直接依赖的规划条目标记 `N/A`，不得伪装为 full 已验证。
 
+同一条调用链只追踪一次，后续维度复用实现位置和边界证据，只补未覆盖项或失效证据；复用不省略独立的验收判断。
+
 ---
 
 ## 维度 2：实现假设
@@ -43,31 +41,14 @@ untracked 上下文没有 task artifacts，本维度标记 `N/A`，不得根据
 | Component Context | Modal、Drawer、Tab 或条件渲染容器内修改有状态组件 | 确认销毁/保留、受控值、初始化值和重置行为 |
 | Data History | 新增、修改或重新解释持久化字段 | 确认 null/零值/历史记录降级；按验证阶段区分阻断型 `部分验证` 与 `[上线后验证]` |
 | Data Flow Trace | 变更跨越 UI/API/Service/Storage 中两个或更多边界 | 连起来核对参数名、类型、嵌套层级和错误传播 |
-| Verification Tests | A-D 任一适用 | 自动化测试优先；也可使用可重复的手动步骤、静态检查或定向命令覆盖关键假设 |
-
-未触发的 Dimension 标记 `N/A`。
 
-仅缺少自动化测试文件不得生成 `CHK-*`。已有测试时应实际运行；项目 spec、风险等级或回归概率明确要求自动化覆盖时，缺失测试仍记录问题。否则只有缺少完成当前结论所必需的充分证据时才记录 `CHK-*`，模糊的“手动看过”不构成证据。
+未触发的 Dimension 标记 `N/A`。触发维度先复用已有追踪结果，再补其新增约束；验证命令需求统一交给维度 3，不在各 Dimension 分别运行。
 
 ---
 
 ## 维度 3：完整性、规范与项目验证
 
-读取 `.agents/skills/trellis-check/SKILL.md`（Claude-only 项目读取对应 `.claude` 副本），只复用与本次局部变更相关的：
-
-- 适用 spec 的读取方法；
-- 定向 lint、typecheck、测试或格式检查命令；
-- 复用、依赖、同层一致性、debug logging、warning suppression 和类型安全绕过检查。
-
-在 Check-All 内执行时，`trellis-check` 中任何直接修复、补测试、反复修到通过的指令一律失效。验证失败记录为 `CHK-*` 并继续其它独立验证。
-
-实际变更位于 Maven reactor 时，按 `maven_verify.py` 的 evidence schema 只调用：
-
-```bash
-python3 ./.trellis/scripts/maven_verify.py check --latest --require-plan <final-plan.json>
-```
-
-`reusable` 计入定向验证；`partial` / `stale` / `failed` / `blocked` 记录精确验证缺口、原因和所需计划。Check-All 是 audit-only，不得调用 `plan` / `run` 或任何 Maven goal；Maven model/goal 可能写 `target/`、本地仓库或缓存。没有 Maven evidence 时不得无条件全仓构建，报告由主会话或 implement 路径执行的精确重跑需求。
+执行 `references/verification.md` 中本次局部变更触发的检查，统一复用有效证据并执行未覆盖的定向验证。数据流沿用前两维证据，不重新完整追踪。
 
 所有发现候选按 `references/fallback-findings.md` 先判定 `CHK-*` / `FBK-*`，再分配严重度。不得因场景极端、修复困难或影响较低改变根因通道；不满足三项硬准入的泛化建议不报告，保护收益或验证环境不完整则保留 FBK 并标记报告缺口。
 

package/enhancements/0.6/.agents/skills/trellis-check-all/references/maven-evidence.md

@@ -0,0 +1,14 @@
+# Maven Evidence
+
+仅 Maven 变更加载本文件，按既有 evidence schema 只读核对 final evidence：
+
+```bash
+python3 ./.trellis/scripts/maven_verify.py check --latest --require-plan <final-plan.json>
+```
+
+- `reusable`：核对 lifecycle、模块、消费者、测试、附属制品和 skip 项后计入证据。
+- `partial`：记录未覆盖的 module/consumer/test/artifact 或更高 lifecycle 要求。
+- `stale`：记录源码、测试、POM、外部父 POM、Git 或工具链失效原因。
+- `failed` / `blocked`：保留失败或证据损坏事实，不把未执行验证写成通过。
+
+主会话和 dedicated subagent 都不得调用 `plan` / `run` 或任何 Maven goal，也不得运行会写 `target/`、本地仓库或缓存的构建。缺少可复用证据时报告由 implement 路径执行的精确重跑需求，不默认 `clean package/install`、`-amd` 或全 reactor。

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

@@ -68,11 +68,18 @@
 
 ## 输出：统一检查报告
 
-interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复后，严格按以下顺序输出：
+interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动、行为影响和结论，再展示证据与问题：
+
+- 依据当前审查范围的最终 diff 和已读实现，覆盖 staged、unstaged、未跟踪文件及必要的子仓；复用检查时收集的材料，不额外启动 Diff Brief 流程或重复扫描。
+- 按行为说明改前后的差异，只有证据支持时才描述旧行为；无行为变化时说明文档、测试或生成物调整，不罗列文件。
+- 区分已实现、已验证和仍未解决的内容；计划中的功能不得写成已经交付，未归属本次范围的 dirty 不得混入。阻塞或重大问题在开头说明，不能被改动介绍掩盖。
+- 自然段不另设固定字段或空项，按复杂度展开。重检只解释本轮修复及其影响。随后保留完整问题、风险和下一步。
 
 ```markdown
 ## Trellis Check-All 结果
 
+<用自然语言说明实际改动、行为影响和检查结论；不逐文件罗列，不复述规划>
+
 [<通过/通过·已接受风险/未通过/阻塞>] <N> 个维度 · CHK <N>（接受 <N>）· FBK <N>（接受 <N>）· 自动修复 DOC <N> · P0 <N> / P1 <N> / P2 <N> · 验证 <通过>/<总数>
 
 - **工作**：<任务名称 | Untracked work: work-id | 无活动工作>
@@ -177,6 +184,8 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 ```markdown
 ## Trellis Check-All 修复结果
 
+<用自然语言说明本轮实际修复、修复后的行为和重检结论>
+
 [<完成/部分完成/失败>] CHK 修复 <完成>/<计划> · FBK 修复 <完成>/<计划> · DOC 自动修复 <N> · 验证 <通过>/<总数> · 剩余 CHK <N> · 剩余 FBK <N>
 
 | 问题 | 修复 | 验证 |

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

@@ -0,0 +1,29 @@
+# Verification
+
+Light / Full 共用本清单，检查范围由当前 profile 决定。复用 Step 0 已读规范和前两维的源码证据，不再加载 `trellis-check` 或继承其自修复流程。
+
+## 完整性与规范
+
+- 按受影响包的 spec Quality Check 核对本次变更；已读且未变化的规范直接复用。
+- 核对漏改的调用方、批量修改遗漏、生成或分发产物、导入路径、循环依赖和同概念的行为一致性；数据流复用前两维追踪，仅补未覆盖边界。
+- 检查遗留 debug logging、warning suppression、类型安全绕过及项目明确禁止的模式。
+- 格式、语法和静态类型由已覆盖当前范围的工具结果证明；人工只补工具未覆盖的语义风险。
+- 不因新增函数就要求一份对应单测，也不因两处值相同就要求抽公共常量。只有真实的回归或一致性风险、错误抽象、遗漏同步或项目明确约定才构成检查依据；不得要求与本次任务无关的重构。
+
+## 统一验证与证据复用
+
+1. 汇总验收、假设维度和项目 spec 的验证需求。自动化测试优先；可重复的手动步骤、静态检查或定向命令也可作为证据，覆盖关键参数、历史数据、空值和错误路径。
+2. 优先核对已有实际命令输出，包括实现阶段和先前检查的结果：命令、工作目录、覆盖范围、退出状态明确，且相关源码、测试、配置和工具链未变化才可复用。只写“测试通过”的摘要、测试文件存在或无法确认适用范围均不足以复用。
+3. 相同工作目录、命令参数、环境与被测内容的验证只执行一次；覆盖关系明确时复用较完整的结果，多个维度引用同一证据。不同条件不得去重，测试过滤范围、跳过项和未执行项不能算作已覆盖。
+4. 缺失、失败或失效的证据按当前范围补跑必要命令；未变化且已覆盖的检查不重复运行。失败保留退出状态和关键错误，继续其它独立验证；无法完成必需验证时如实标记 `部分验证` 或 `阻塞`。
+5. 仅缺少自动化测试文件不得生成 `CHK-*`；项目 spec、风险等级或回归概率明确要求自动化覆盖时，缺失测试仍记录问题。缺少完成当前结论所必需的充分证据时记录 `CHK-*`；不得用证据复用跳过必需回归或伪报已运行。
+
+同一证据可以支持多个维度，报告中的验证次数按实际独立验证统计，不按引用次数累加。新编辑或 DOC 修复后重新判断受影响证据，仅复查变化及其依赖；影响面不闭合时按 depth-routing 升级。
+
+## 只读边界
+
+Check-All 不直接修复代码、配置或测试。只执行无业务写入副作用的验证；可能写业务数据或外部系统的命令不运行，按 reporting reference 区分阻断型部分验证与 `[上线后验证]`。专用 subagent 还必须遵守其宿主的只读工具限制。
+
+### Maven Evidence
+
+实际变更位于 Maven reactor 时才读取 `references/maven-evidence.md`。主会话和 dedicated subagent 都不得调用 `plan` / `run` 或任何 Maven goal，只读核对现有 final evidence。

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

@@ -12,26 +12,29 @@ description: "手动检查和执行已安装 Flower/Trellis 强化包升级。
 ## Workflow
 
 1. 确认目标项目。用户给出路径时使用该路径，否则使用当前工作目录。
-2. 运行人工检查，默认强制刷新远端版本证据：
+2. 检查 `flower-trellis` 是否可执行。缺失或入口异常且目标项目存在 `.trellis/scripts/flower_update_hook.py` 时，先运行目标项目的检测脚本：`python3 <target>/.trellis/scripts/flower_update_hook.py --bootstrap-only --target <target>`（路径按当前 shell 引用，Python 命令沿用项目配置）。遵循返回的 `<flower-cli-bootstrap>`：先征得当前成员确认，再安装锁定版本并验证；当前对话已授权这次安装时不重复确认。脚本不存在时说明项目缺少安装引导入口，不猜版本安装。未安装成功则停止依赖 CLI 的步骤，不循环追问或安装。
+3. CLI 可用后运行人工检查，默认强制刷新远端版本证据：
 
 ```bash
 flower-trellis self-check --json --manual --force-remote --target <target>
 ```
 
-3. 解析 JSON：
+4. 解析 JSON：
    - `update_available`：展示当前版本、推荐版本、release notes 摘要和 `commands.recommended`。
    - `project_out_of_sync`：展示当前 Flower/Trellis 与项目记录的差异，并展示 `commands.recommended`。
-   - `up_to_date`：说明当前安装和项目记录已一致。
+   - `up_to_date`：说明 CLI 与项目版本记录一致；版本记录不等于受管内容完整性验证。
+   - `project_unknown`：说明 CLI 未发现新版，但项目 Flower 版本无法确认。linked worktree 进入 `trellis-worktree` 的 Flower Preparation，通过 `prepare --inherit-flower --source <source>` 补齐可验证记录后重新检查；来源缺失或冲突时如实报告，不推定需要重装。
    - `disabled` / `offline` / `skipped`：说明原因；不要靠重置缓存伪造可执行状态。
-4. 写入前遵守确认和安全门槛：
+5. 写入前遵守确认和安全门槛：
    - 用户当前消息已经明确要求执行升级时，可以执行 `commands.recommended`。
    - 用户只是询问、查看或比较版本时，只展示结果并等待确认。
    - `safety.reasons` 非空时，先说明风险，再等待用户明确确认。
-5. 执行推荐命令后读取 `<flower-update-result>`。如果结果要求 `run_trellis_push_confirmation`，进入 `trellis-push`，展示文件和 commit message 后等待确认。
+6. 执行推荐命令后读取 `<flower-update-result>`。如果结果要求 `run_trellis_push_confirmation`，进入 `trellis-push`，展示文件和 commit message 后等待确认。
 
 ## Rules
 
 - 不直接读写 `.flower/update-check.tmp`。
+- 无论远端查询结果如何，都单独说明 `project.flowerVersionStatus=unknown`；不得用本机 CLI 版本替代项目安装证据。
 - 不使用 `update-check reset`、`snooze` 或 `skip` 作为升级绕过手段。
 - 不运行 `npm run release`、不打 tag、不 publish，也不修改 `package.json` 版本号。
 - 不把 `self-check --manual` 用在 SessionStart 自动 hook；自动路径必须继续尊重提示节流。

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

@@ -227,7 +227,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-*`，不要求异常已实际发生；保护收益和验证方式属于报告完整度。提交前应完成但证据不足时标记阻断型部分验证；本质依赖部署后、生产环境或外部系统的验收返回 `[上线后验证]`，不得执行且不得误标为阻断。泛化建议不报告。低风险事实漂移使用 `DOC-*` 候选单独返回。
-4. 只读审查；禁止编辑、写文件、补测试或自修复。Step 3 只复用 trellis-check 的检查清单，忽略其自动修复指令；`DOC-*` 也只能返回候选，由主会话按 Check-All 规则决定是否写入。
+4. 只读审查；禁止编辑、写文件、补测试或自修复。按 Check-All profile 的共享验证清单复用源码和验证证据；`DOC-*` 也只能返回候选，由主会话按 Check-All 规则决定是否写入。
 5. 真正阻塞条件返回主会话，不替用户选择业务行为或修复范围。
 
 返回：统一 Check-All 结果、全部 `CHK-*`、`FBK-*`、`DOC-*` 候选、已执行验证和剩余风险。不要输出 commit/push 计划。

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

@@ -7,7 +7,7 @@ description: "Prepare and diagnose branch-local Trellis usage inside linked Git
 
 Use this skill before normal Trellis routing when the current request is about linked worktrees or parallel branch development.
 
-Each worktree owns the Trellis and platform files checked out by its branch. Never load `.trellis`, `.agents`, `.codex`, `.claude`, or `.flower` from another worktree, and never create whole-directory symlinks between worktrees.
+Each worktree owns the Trellis and platform files checked out by its branch. Load workflow and platform content only from the target branch. Flower installation records may be inherited through the verified CLI preparation below; never create whole-directory symlinks between worktrees.
 
 ## Workflow
 
@@ -19,8 +19,8 @@ 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. Add `--inherit-route-prefs` only when the user wants the same developer's normalized personal route defaults from the current controlling worktree.
+   - `ready-local`: inspect `flower.installation` before continuing. If it is `incomplete`, follow Flower Preparation below; Trellis readiness does not prove Flower installation completeness.
+   - `needs-prepare`: run `flower-trellis worktree prepare --target <target-worktree>` with an explicit developer identity when requested. Include the Flower Preparation options when records are incomplete. Add `--inherit-route-prefs` only when the user wants the same developer's normalized personal route defaults.
    - `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.
@@ -38,7 +38,7 @@ flower-trellis worktree create --target <path> --branch <branch> [--base <ref>]
   --task-title <title> --task-slug <slug>
 ```
 
-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.
+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, Flower transfer source/action/paths and pending target validation, and excluded local state. Flower records are included in the same plan fingerprint; content mismatch after checkout rolls back creation. 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
@@ -50,17 +50,29 @@ flower-trellis worktree create --target <path> --branch <branch> [--base <ref>]
 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.
 
+## Flower Preparation
+
+Use the initiating worktree as the source. In a new session already inside the target, use `git worktree list --porcelain` to locate the same repository's main worktree. If it is the target itself or no suitable source is known, report unavailable evidence; do not combine records from arbitrary branches.
+
+```bash
+flower-trellis worktree prepare --target <target> --inherit-flower --source <source> [--developer <name>] --json
+```
+
+The CLI fills missing `plugins.json`, `plugin-lock.json`, and `state.json` only after matching the source installation and target managed content. It may inherit normalized `settings.json` policy for the same developer. Existing target records take precedence; files remain independent after preparation. Create includes this transfer automatically.
+
+Read `localStateTransfer.flower`: `inherited` or `preserved` completes preparation; `unavailable` means installation evidence is still missing, not that the project is up to date. Pure Trellis remains usable. Invalid records, incompatible target versions, disabled/recovery state, or content drift require reporting the reason and paths; do not overwrite records, copy plugin content, or install updates to bypass the conflict. Re-run status after repair.
+
 ## Safety Rules
 
 - `status` is read-only.
 - 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.
+- `prepare` initializes target-local state and registry metadata. By default it reads no other worktree. Explicit Flower inheritance requires the same canonical Git common dir and verified installation content. Personal route/settings inheritance additionally requires the same developer and preserves existing target preferences.
 - `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.
+- Root tracked, staged, untracked, and conflict state is not included in the selected base commit or stashed. Only the explicitly planned Flower record whitelist may be inherited separately; source plugin content is never copied to make its records match the target.
+- Personal inheritance is limited to normalized `.trellis/.route-prefs.tmp` and Flower update policy. Route preferences accept only legal `implement` and `check` values in fixed order; never copy raw preference bytes or update-check caches.
+- Do not inherit session/current-task state, pre-check/untracked/auto-loop/Ralph state, agent temporary state, Flower control/detached state, `.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

@@ -10,18 +10,6 @@ description: "统一 Check-All：按 requested/effective depth 路由 light/full
 
 ---
 
-## 入口职责
-
-1. 确认本轮检查范围、task artifacts 或 untracked state、项目规范和运行上下文。
-2. 解析 `requested_depth`，生成 `check_profile`，决定 `effective_depth=light|full`。
-3. 按有效深度读取并执行对应 profile。
-4. 按根因把发现分为 `CHK-*`、`FBK-*`、`DOC-*`，再为前两类分配 P0/P1/P2。
-5. 报告前处理允许自修的事实漂移并展示结果。
-6. 按 interactive / validated auto-loop 边界输出下一步或执行 `record + next`。
-7. untracked helper 只存游标：findings 或新编辑回 `implement`；通过且 disposition 继续时才 `advance --stage spec`。
-
----
-
 ## 必读引用
 
 按需加载引用文件，不要提前读取未命中的 profile：
@@ -43,7 +31,7 @@ description: "统一 Check-All：按 requested/effective depth 路由 light/full
 2. **唯一自修例外**：低风险事实漂移进入 `DOC-*` 通道，按 `references/document-drift-auto-remediation.md` 的白名单、黑名单和写入时机处理。
 3. **分类先于严重度**：读取 `references/fallback-findings.md`；主路径错误和非兜底契约违背进入 `CHK-*`，fail-closed、异常输入、失败降级和防御性保护缺口进入 `FBK-*`。契约证据影响严重度，不改变兜底根因归属。
 4. **处置只确认一次**：统一报告后选择 `CHK-*` / `FBK-*` 修复范围或接受风险；`修复全部` 覆盖两类，接受风险不得隐藏发现。
-5. **委托不改边界**：复用 `trellis-check` 的清单和验证方法，忽略其直接修复指令。
+5. **共享验证**：两个 profile 共用 `references/verification.md`；同一追踪与有效验证证据跨维度复用，检查保持只读。
 6. **真正阻塞才中途暂停**：业务规划冲突、前提失效，或当前结论必需验证涉及未授权生产/外部/破坏性副作用时暂停；发布后验收只记 `[上线后验证]`，不执行、不阻断。
 
 中途停止时也要使用统一问题模型，报告已完成范围和阻塞原因；只询问解除阻塞所需的业务或安全决策。
@@ -74,18 +62,11 @@ description: "统一 Check-All：按 requested/effective depth 路由 light/full
 
 ## 顶层流程
 
-### Step 0：范围、上下文与深度画像
+untracked helper 只存游标：findings 或新编辑回 `implement`；通过且 disposition 继续时才 `advance --stage spec`。
 
-读取 `references/depth-routing.md` 并执行完整 Step 0。输出固定画像：
+### Step 0：范围、上下文与深度画像
 
-```yaml
-check_profile:
-  context: interactive | auto-loop
-  requested_depth: auto | light | full
-  effective_depth: light | full
-  confidence: high | fallback-full | escalated
-  reasons: [string]
-```
+执行 `references/depth-routing.md` 的完整 Step 0，按其格式生成 `check_profile`。
 
 ### Step 1：读取对应 profile
 
@@ -98,17 +79,13 @@ check_profile:
 
 ### Step 3：处理事实漂移自修
 
-读取 `references/document-drift-auto-remediation.md`。在最终报告前：
-
-- inline：主会话应用允许的 `DOC-*` 修复并做定向验证。
-- subagent：主会话审阅 subagent 返回的 `DOC-*` 候选，只应用满足白名单且无歧义的修复。
-- auto-loop：主会话应用允许的 `DOC-*` 修复后再 `record`；若只存在已修复事实漂移且无剩余 `CHK-*` / `FBK-*`，结果可为 `ok`，摘要必须包含自动修复说明。
+按 `references/document-drift-auto-remediation.md` 的白名单和证据规则，由主会话处理允许的 DOC 并定向验证；subagent 仅返回候选。完成后再报告或交给 reporting reference 的 auto-loop 分流。
 
 不满足自动修复条件的文档问题根据根因转为 `CHK-*`、`FBK-*` 或剩余风险，按普通修复范围处理。
 
 ### Step 4：统一报告与分流
 
-读取 `references/reporting-and-disposition.md`。报告必须展示：
+读取 `references/reporting-and-disposition.md`。报告先自然说明实际改动及行为影响，再展示：
 
 - `check_profile`；
 - 三个维度状态；
@@ -123,12 +100,10 @@ check_profile:
 ## 反模式
 
 - 入口默认加载 full profile，导致 `auto` 被 full 语气带偏。
-- 发现一个普通问题就暂停询问一次。
 - 把 `trellis-check` 的自动修复指令带入普通 `CHK-*`。
 - 先按严重度决定 `CHK-*` / `FBK-*` 通道，混淆根因性质与影响等级。
 - 把纯偏好、无具体场景或无法验证收益的“更健壮”建议记录为 `FBK-*`。
 - 因兜底行为已写入契约就把保护路径根因改列为 `CHK-*`。
-- subagent 直接修改工作区。
 - 把需求变更、验收标准、产品语义或设计取舍伪装成文档漂移自动修复。
 - light 未命中完整穷举条件仍继续 light。
 - 无环境证据却把维度标记为通过。