flower-trellis 0.6.7 → 0.6.8-beta.1

package/README.md

@@ -172,7 +172,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-dms-query` 与 `aliyun-sls-query`：前者通过阿里云 DMS 查询纳管数据库，并让写操作以数据变更工单进入审批流；后者提供零第三方依赖的阿里云 SLS 查询脚本与排障知识。两者都支持 Codex / Claude 项目，默认不安装，也不会复制用户私有 AK/SK 配置。
+可选通用技能包含 `aliyun-ops`，统一提供阿里云 DMS、SLS 与 MSE 查询和排障能力，DMS 写操作通过数据变更工单进入审批流。通用技能需手动选择启用，不会复制用户私有 AK/SK 配置。Codex 通用技能安装到 `.agents/skills`，Claude 安装到 `.claude/skills`；已有 `.codex` 或 `.agents` 时使用共享目标，已有 `.claude` 时使用 Claude 目标，三个目录都不存在时默认同时安装两份。空目录也可通过 Skill Garden 入口管理通用技能，无需初始化 Trellis。
 
 安装、更新和卸载都会先展示 dry-run、依赖、capability 和目标文件变化，确认后才写入项目。Plugin 作者使用的 `plugin init`、`plugin validate` 继续保留在高级命令中，不占用普通用户的管理器首页。
 
@@ -381,7 +381,9 @@ flower banner → 平台多选菜单 → Trellis 原生交互(模板 / monorepo
 
 - **通用技能**:`flower-trellis update` 会用新版快照覆盖仓库中已经启用的 common skill,
   未启用项不会自动安装;若某个已安装 common skill 已从新版快照移除,更新会精确删除其
-  `.codex/skills` / `.claude/skills` 或历史 `.agents/skills` 副本。
+  `.agents/skills` / `.claude/skills` 或历史 `.codex/skills` 副本。安装或更新对应技能时，
+  旧 `.codex/skills` 会迁移到 `.agents/skills`，兼容旧技能名称；新副本写入成功后才清理旧目录。
+  新旧同名技能仍按随包快照替换，不合并自定义内容；停用会清理该技能的新旧精确目录。
 
 ## 开发
 

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

@@ -85,15 +85,7 @@ untracked helper 只存游标：findings 或新编辑回 `implement`；通过且
 
 ### Step 4：统一报告与分流
 
-读取 `references/reporting-and-disposition.md`。报告先自然说明实际改动及行为影响，再展示：
-
-- `check_profile`；
-- 三个维度状态；
-- 自动修复的 `DOC-*` 内容；
-- 剩余 `CHK-*` 主路径问题与 `FBK-*` 兜底问题；
-- 每个剩余问题的未处置或已接受风险状态；
-- 已执行验证、未覆盖风险和 `[上线后验证]`；
-- 与当前结论匹配的唯一下一步。
+读取 `references/reporting-and-disposition.md`，按其完整模板与分流规则在对话中输出报告；默认不新建报告文件，落盘例外由该 reference 定义。
 
 ---
 

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

@@ -34,6 +34,8 @@
 - 不改操作步骤、责任边界、安全提示、协议字段或对外承诺，且可由重读或静态检查验证；
 - 用户没有明确要求本轮绝对只读。
 
+任务状态同步只更新已有文档中的过期事实；不得借 `task-status`、`check-record` 或 `mechanical-link` 新建检查报告并追加引用。报告落盘条件见 `references/reporting-and-disposition.md`。
+
 典型例子：
 
 - `brief.md` 漏掉 diff 已证明的实现范围，或 `implement.md` 状态机械过期；

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

@@ -56,7 +56,7 @@
 4. 已接受问题继续完整展示证据、影响、建议和验证，标题行末尾追加 `` `[已接受风险]` `` 标签；不得删除条目、改列 `DOC-*` 或伪报已修复。
 5. `strict pass` 只用于剩余 `CHK-*` / `FBK-*` 均为 0。所有剩余问题均已被有效接受，且无 blocked、无阻断型部分验证、无未接受的实质剩余风险时，结论为 `通过·已接受风险`。
 6. blocked、阻断型部分验证和无法唯一对应当前报告范围的实质剩余风险不是 `CHK-*` / `FBK-*` 处置状态，不能借风险接受绕过；`[上线后验证]` 不属于风险接受对象。
-7. `仅保留报告` 表示停止处置并等待，不等于接受风险；只有带明确接受语义的用户回复才改变问题处置状态。
+7. `仅保留报告` 表示停止处置并等待，不等于接受风险，也不授权写文件；只有带明确接受语义的用户回复才改变问题处置状态。
 
 ## 验证阶段
 
@@ -68,6 +68,10 @@
 
 ## 输出：统一检查报告
 
+报告默认在对话中完整展示，不得为了缩短回复、提供链接、留存结论或同步任务状态新建 `check-report.md` 等附件，也不得用附件链接代替应展示的内容。
+
+仅用户明确要求导出或已确认的交付约定要求文件时，由主会话保存，不得自行补写约定。Maven、auto-loop 沿用各自机器证据契约，不额外生成 Markdown。已有报告不自动删除或复制。
+
 interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动、行为影响和结论，再展示证据与问题：
 
 - 依据当前审查范围的最终 diff 和已读实现，覆盖 staged、unstaged、未跟踪文件及必要的子仓；复用检查时收集的材料，不额外启动 Diff Brief 流程或重复扫描。
@@ -141,8 +145,6 @@ interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动
 - **批次 1**：<CHK/FBK 问题 ID> · <修复目标>
 - **修复后**：定向验证 -> Check-All 重检
 
-操作：`修复全部`、`修复 CHK-001,FBK-002`、`接受当前报告全部风险并继续`、`接受风险 CHK-001,FBK-002 并继续`、`仅保留报告`
-
 ### 下一步
 
 <按下方 `Interactive Post-Check Stop Gate` 输出一个明确、可执行的主动作>
@@ -150,6 +152,7 @@ interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动
 
 展示规则：
 
+- strict pass 且无剩余问题时可紧凑表述，保留模板顺序、画像、维度、实际验证、DOC（如有）、风险和下一步，省略空区块；不得缩减实际检查范围。有问题或已接受风险时完整展示问题字段与处置。
 - 报告头部“工作/范围/画像/结论”和“修复批次”必须使用 `- ` 列表项，不得改为裸行或依赖行尾空格。
 - 每个问题必须由一个四级标题承载，固定顺序为 `` #### `<ID>` `<严重度>` `<来源>` <标题> ``。仅 `已接受风险` 的问题在标题末尾追加 `` `[已接受风险]` ``；待处理不加标签。`来源` 与 `处置` 都不再单独占行。
 - 不得改用 `- [ ]` / `- [x]` 列表项承载问题条目。终端渲染器会把松散列表压平，相邻条目会糊成一段无法分辨；只有标题这类块级元素才能稳定产生视觉分隔。修复状态由“修复结果”表格表达，不靠 checkbox。
@@ -158,10 +161,9 @@ interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动
 - 没有 `DOC-*` 自动修复时省略“自动修复”区。
 - 没有 `CHK-*` 时省略“主路径问题”区；没有 `FBK-*` 时省略“兜底问题”区。
 - 同时存在两类问题时，`### 主路径问题` 及其全部 `CHK-*` 必须完整出现在 `### 兜底问题` 及其全部 `FBK-*` 之前；不得按全局严重度排序反转或交错两个区块。
-- 存在未处置 `CHK-*` 或 `FBK-*` 时展示“修复批次”，并只在报告末尾提供一次处置选择，不再逐项提问。
+- 存在未处置 `CHK-*` 或 `FBK-*` 时，“修复批次”只说明分组与验证安排，处置选择统一在报告末尾“下一步”中提供一次，不再逐项提问。
 - `修复全部` 始终覆盖全部 `CHK-*` 与 `FBK-*`；精确修复可以混合两类 ID。
 - 风险接受可混合两类 ID；“接受当前报告全部风险”覆盖全部剩余问题，包括 P0，无固定句式。全部有效接受后才形成“通过·已接受风险”。
-- `仅保留报告` 只表示停止处置，不改变未通过结论或剩余风险。
 - interactive 标准报告必须以“下一步”段结束；停止等待不等于省略引导。
 - 独立 `CHK-*` 或 `FBK-*` 不得因数量多而静默省略；先合并同根因重复项，再完整列出剩余项。
 - 报告不得包含 commit message、拟提交/暂存文件、commit-only 决策或提交确认。
@@ -205,7 +207,7 @@ interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动
 <按下方 `Interactive Post-Check Stop Gate` 输出一个明确、可执行的主动作>
 ```
 
-检查通过后的动作由下方 `Interactive Post-Check Stop Gate` 判断：普通交互停止等待，符合 direct Git strict pass 或已接受风险通过条件时同轮进入 Phase 3.3 `trellis-update-spec`，再到 Phase 3.4 `trellis-push`。仍有未处置 `CHK-*` 或 `FBK-*` 时停留在处置/重检循环。
+重检后按下方 `Interactive Post-Check Stop Gate` 分流；仍有未处置 `CHK-*` 或 `FBK-*` 时停留在处置/重检循环。
 
 untracked helper 不存检查证据或风险接受。普通通过后保持 `stage=check`；direct Git 同轮继续或用户明确继续才 `advance --stage spec`。未处置 `CHK-*` / `FBK-*`、阻断型部分验证、阻塞或新编辑先 `advance --stage implement`；仅 `[上线后验证]` 不回退。
 
@@ -246,14 +248,6 @@ subagent 只返回结构化 `CHK-*`、`FBK-*`、`DOC-*` 候选、报告和 `chec
 
 停止边界只控制是否自动推进，不能让报告在没有下一步提示的情况下结束。
 
-允许 Check-All 标准报告输出的内容只有：
-
-- 各维度状态、问题数和问题清单；
-- `CHK-*` 主路径问题和 `FBK-*` 兜底问题的证据、影响与验证；
-- `DOC-*` 自动修复内容和验证；
-- 已执行验证及结果；
-- 未覆盖验证、`[上线后验证]` 和剩余风险；
-- 总体结论；
-- 与当前结论匹配的唯一主动作引导；有未处置 `CHK-*` 或 `FBK-*` 时是一次修复或风险接受选择，部分验证/阻塞时是补充决策或验证，通过时是 Phase 3.3 / Phase 3.4 指向。
+标准报告仅包含上方统一模板定义的检查内容和本 Gate 的唯一主动作。
 
 Check-All 不新增 direct Git 摘要或 Git 计划；这些仍由 Update-Spec 与 Push 所有。`[上线后验证]` 交给 Push 风险摘要和既有 `trellis-release` / `release.md`。

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

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

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

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

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

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

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

@@ -118,7 +118,9 @@ git log @{u}..HEAD --oneline 2>/dev/null || true
 
 命令必须是受版本控制的稳定入口，并且本地、确定性、可重复、无外部副作用。工作目录和预期影响路径必须可审计；只有名称相似、mtime、目录邻近或惯例不足以执行。禁止任意 shell 字符串、管道、重定向、命令替换、push、release、deploy、archive、凭证和生产数据操作；证据不足时失败关闭。
 
-`retained` 只是内部集合名。用户可见输出统一写“保留未提交的变更（dirty）”，并逐项标注 `[untracked]`、`[unstaged]`、`[staged]`。unknown ahead、branch/upstream 异常、归属不确定等真正需要处理的事项单独进入“风险”区；普通 retained dirty 不默认视为阻塞。
+`retained` 只是内部集合名。用户可见输出统一写“保留未提交的变更（dirty）”，按输出 reference 的阈值展示；内部始终保留 exact paths 和 Git 状态，分组摘要不得用于 pathspec 或替代校验。unknown ahead、branch/upstream 异常、归属不确定等真正需要处理的事项单独进入“风险”区；普通 retained dirty 不默认视为阻塞。
+
+普通模式和用户 `commit-only` 的计划与校验基线默认保存在当前执行上下文。仅跨进程校验或中断恢复确需落盘时，才在 Git 忽略的 runtime 目录保存一份必要的临时 JSON；已有可复用记录时不另建副本。不得仅为缩短对话、提供链接或展示完整清单生成 `retained.md` 等清单附件，也不把临时计划写入任务产物或提交范围。auto-loop 沿用 runner 的既有持久化契约，不增加额外清单。
 
 普通模式允许 `retained` 存在。执行前记录计划外 staged set，提交后确认这些 staged 文件仍保持原状。用户明确要求新增文件时，重新生成计划并确认，不能在执行中静默扩大范围。
 
@@ -142,7 +144,7 @@ auto-loop 内部 `commit-only` 不渲染交互式计划或结果，也不再次
 
 每个仓库按计划顺序执行。执行前重新检查 planned files、当前分支、HEAD、upstream、冲突状态、staged、全部 dirty paths 和 retained 摘要；任一关键条件变化都停止当前执行并重新规划。普通模式仅 `retained` 内容变化时可更新说明；auto-loop 内部模式的 retained 内容必须保持不变。
 
-计划包含本地生成命令时，前置仓成功后按计划执行命令，再复用本节现有预检。命令成功、后续仓全部 dirty paths 都在预计 exact files 内且 retained 摘要未漂移时直接继续；否则停止并重新生成计划。预计文件最终 clean 时不强行提交。
+计划包含本地生成命令时，前置仓成功后按计划执行命令，再复用本节现有预检。命令成功、后续仓全部 dirty paths（auto-loop 内部 `commit-only` 扣除已登记且验证未变化的 retained paths）都在预计 exact files 内且 retained 摘要未漂移时直接继续；否则停止并重新生成计划。预计文件最终 clean 时不强行提交。
 
 auto-loop retry/resume 时，读取调用方提供的已完成仓库提交，逐个验证 repository、commit object、message 和文件集合仍符合当前任务证据，并确认当前分支/HEAD 变化可由这些提交解释。验证通过的提交直接跳过；验证失败立即 blocked，不重复提交。确定性生成入口可以安全重跑，以当前 Git 状态重新规划后续步骤。
 

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

@@ -30,9 +30,8 @@
 [生成（多仓需要时显示）：前置仓成功后，在 `<working-directory>` 运行 `<exact local command>`；预计只影响 <后续仓 exact files 或分组摘要>]
 
 ### 保留未提交的变更（dirty，仅数量大于 0 时显示）
-- [untracked] <path>
-- [unstaged] <path>
-- [staged] <path>
+- <按共用规则逐项展示或按仓库、目录、Git 状态汇总数量>
+- [staged] <repository/path>（仅存在时逐项显示，兼有未暂存修改时同时标注 [unstaged]）
 
 ### 风险（仅数量大于 0 时显示）
 - <Check-All / Update-Spec 风险，或 unknown ahead / branch-upstream / attribution risk>
@@ -45,55 +44,54 @@
 - **进度**：completed=<...> | partial=<...> | next=<...>
 - **执行**：<business commit/push -> `task_progress.py write --complete` -> task-record commit -> task-record push>
 
-确认执行请回复 `确认`。可调整：`只提交`、`修改 message`、`展开文件`。
+确认执行请回复 `确认`。可调整：`只提交`、`修改 message`、`展开文件`、`展开保留变更`。
 ```
 
 ## 共用展示规则
 
 - 计划与结果模板中的字段行必须使用 `- **字段**：值` 列表项。这些行在 Markdown 段落内会被折叠成一段，不得改回裸段落行，也不得依赖行尾空格换行。
-- 「任务记录」是与各仓库区平级的独立 `###` 小节，仅普通模式且存在活动任务时整节展示；不再用方括号条件行代替小节标题。
-- 单仓 `planned` 不超过 8 个文件时完整列出。
+- 计划中的「任务记录」是与各仓库区平级的独立 `###` 小节，仅普通模式且存在活动任务时整节展示；不再用方括号条件行代替小节标题。
+- 计划中单仓 `planned` 不超过 8 个文件时完整列出。
 - 超过 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 状态，并注明由既有 `trellis-release` / `release.md` 流程承接。
+- 计划中的保留变更按仓库计数：不超过 8 项时逐项标注 `[untracked]`、`[unstaged]`、`[staged]`；超过 8 项时将非 staged 项按目录与 Git 状态汇总数量，每仓最多 12 行，必要时合并到上级目录。同一路径计数一次，兼有 staged/unstaged 时同时标注。
+- 计划中的计划外 staged 项始终逐项单列，不计入分组摘要；计划和结果中的真正风险均在独立“风险”区逐项展示，不受行数限制。分组、展开均只改变展示，不改变 exact set 或确认范围。
+- 用户要求“展开保留变更”时在对话中列出同一 exact set 与 Git 状态，不生成清单附件；“展开文件”仍指 planned files。
+- 计划的完成链证据始终显示当前状态，但不重复 Check-All 报告或 Spec review 正文；`未运行`、`已失效`、任一未处置 `CHK-*` / `FBK-*`、blocked、部分验证或 `needs-review` 同时计入风险区。已接受风险的问题也必须按 ID、严重度和影响进入风险区，但不得改标为阻断 finding。`[上线后验证]` 作为非阻断风险逐项保留动作、环境/责任边界和预期结果，不改变 Check-All 状态，并注明由既有 `trellis-release` / `release.md` 流程承接。
 - 无活动 task、untracked 或 `commit-only` 时省略进度动作。
 - 不重复展示检查结果、规范复核、归档或其他阶段的详细信息。
 - 生成前无法确定的内容和增删行写“生成后计算”，不得填预测值。
 
 ## 结果模板
 
-结果复用计划的视觉顺序，先给总览，再逐仓报告实际 commit/push，最后报告任务进度与保留 dirty：
+结果先给结论，每仓一行报告实际提交和推送状态，再报告任务记录与保留变更。全部成功时不重复文件清单、commit message、生成命令、文件统计或完整进度字段：
 
 ```markdown
 ## Trellis Push 结果
 
-[完成 / 部分完成 / 失败] <N> 个仓库 · <N> 个业务 commit
+[推送成功 / 仅本地提交成功 / 部分完成 / 失败]
 
-### 1. <repository-name>
+- **<repository-name>**：`<branch> → <upstream>` · `<short-hash[, short-hash...]>` · <已推送 / 仅本地 / 失败 / 未执行>
+- **任务记录**：`<task-record-hash>` · <completed 已同步 / partial 已同步，仍为 in_progress / commit 待恢复 / push 待恢复 / 同步失败>
+- **保留未提交的变更（dirty）**：<每仓数量与实际核对结论>
 
-- **Commit**：`<short-hash> <actual commit message>`
-- **分支**：`<branch>` -> `<upstream>`
-- **状态**：<✓ 已推送 / · 仅本地提交 / ❌ 失败>
-- **生成**：`<exact local command>` · <✓ 已完成 / ❌ 失败 / · 未执行>（仅多仓需要时显示）
+### 失败与恢复（仅部分完成或失败时显示）
 
-### 任务进度
+- **失败位置**：<仓库/步骤、失败原因；生成失败时包含命令>
+- **已保留**：<成功提交/推送及未完成现场；未执行的后续步骤>
+- **下一步**：<精确恢复动作>
 
-- **状态**：<✓ completed 已提交并推送 · `<task-record-hash>` / ✓ partial 已同步且保持 in_progress / · 已跳过 / ❌ 任务记录 commit 待恢复 / ❌ 任务记录 push 待恢复 / ❌ 同步失败，不得报告完成>
-- **记录**：<N> 个当前任务文件
-- **进度**：completed=<...> | partial=<...> | next=<...>
-- **失败原因**：<原因和恢复动作>（仅失败时显示）
+### 风险（仅存在时显示）
 
-### 保留未提交的变更（dirty，仅存在时显示）
-- [untracked] <path>
-- [unstaged] <path>
-- [staged] <path>
+- <仍适用的风险、异常或未核验项；按共用规则保留必要细节>
 ```
 
 ## 结果补充规则
 
-- untracked 结果用“无任务状态”替代“任务进度”，展示 work id 与 `<已清理/保留待恢复>`；不生成或暗示 task progress commit。
+- 仅普通模式且存在活动任务时显示“任务记录”行；没有实际 commit hash 时省略 hash，不填占位值。用户 `commit-only` 的仓库行只写当前分支与本地提交，不显示推送箭头或暗示已同步远端。
+- untracked 结果用“无任务状态”行替代“任务记录”，展示 work id 与 `<已清理/保留待恢复>`；不生成或暗示 task progress commit。没有保留变更、失败或风险时省略对应行或章节。
 - 部分完成时必须明确列出已成功仓库、失败仓库/步骤、当前分支和下一恢复动作。业务结果与 progress sync 状态不得合并成一个模糊结论。
-- 普通成功结果必须确认本任务产生的当前任务目录变更 clean；其它 retained dirty 仍按原状态逐项展示。
+- 普通成功结果必须确认本任务产生的当前任务目录变更 clean。其它 retained dirty（含计划外 staged）仍逐项核验，已核对保持原状时每仓只报告数量与结论，不重复清单。异常或未核验项列出路径、实际状态和处理情况，不得笼统声称全部保持原状；用户要求详情时再展示实际文件、message、命令或进度，展开文件仍沿用共用规则。
+- Git 成功不消除现有风险；结果的“风险”区保留仍适用的完成链风险、已接受问题与 `[上线后验证]`，不得因成功摘要而省略。
 - helper 成功但任务记录 commit 失败时，结果写“任务记录 commit 待恢复”，说明本地 `completed` 与 exact task dirty 已保留；任务记录 commit 成功但 push 失败时写“任务记录 push 待恢复”，说明 clean ahead commit 已保留。两种情况都不得暗示需要重复业务提交或 helper 写入。
 - validated auto-loop local completion 不渲染本模板，也不得被普通结果文案描述为任务记录 push 待恢复。

package/enhancements/0.6/.agents/skills/trellis-run-full-chain/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: trellis-run-full-chain
-description: "Run full-chain behavior verification across UI + API + DB — cross-layer (browser driver + HTTP client + DB client), NOT frontend-only e2e like Playwright/Cypress test suites. Input is a 场景-路径-期望 scenario table; executes each row, logs pass/fail, and restores test data when feasible. Triggers: 「跑全链路」「全链路测试」「跨层验证」「跑E2E」「端到端验证」「自动化测试场景」「跑场景测试」「e2e test」. Not for lint/unit/spec-only (use trellis-check); not for frontend-only e2e suites."
+description: "Run full-chain behavior verification across UI + API + DB — cross-layer (browser driver + HTTP client + DB client), NOT frontend-only e2e like Playwright/Cypress test suites. Input is a 场景-路径-期望 scenario table; executes each row, logs pass/fail, and restores test data when feasible. Triggers: 「跑全链路」「全链路测试」「跨层验证」「跑E2E」「端到端验证」「自动化测试场景」「跑场景测试」「e2e test」. Not for lint/unit/spec-only (use trellis-route(target=check) to enter trellis-check-all); not for frontend-only e2e suites."
 ---
 
 # Run Full-Chain Verification — 跨层自动化验证
@@ -8,7 +8,7 @@ description: "Run full-chain behavior verification across UI + API + DB — cros
 以"场景-路径-期望"三列表为输入，逐条跨层执行并验证：UI 驱动 + HTTP 调用 + DB 断言三种能力配合使用。最后汇总结果与**尽力而为**的数据恢复。
 
 > **何时用**：PR 前 UAT、功能端到端验收、单测覆盖不到的跨层流程验证。
-> **何时不用**：只跑 lint/typecheck/spec 合规（去 `trellis-check`）；只做 PRD↔代码静态对照（去 `trellis-check-all`）。
+> **何时不用**：lint/typecheck/spec 合规或 PRD↔代码静态对照，均经 `trellis-route(target=check)` 进入 `trellis-check-all`。
 
 ---
 
@@ -322,8 +322,8 @@ Playbook 内容范围（**跨任务可复用的环境常量**，不含具体场
 
 | 入口 | 形态 | 用途 |
 |------|------|------|
-| `trellis-check` | skill | lint / typecheck / spec 规范 |
-| `trellis-check-all` | skill | PRD→代码 静态对照 + 假设验证 |
+| `trellis-route(target=check)` | skill | 统一质量检查路由（主会话 / 子代理） |
+| `trellis-check-all` | skill | 三件套实现、实现假设、完整性与规范的统一检查 |
 | **`trellis-run-full-chain`** | skill（本技能）| **运行时行为跨层验证（UI+API+DB）** |
 | `trellis-verify-task` | skill | 三件套（prd/design/implement）↔源需求文档 + 跨层一致性对账 |
 

package/enhancements/0.6/.agents/skills/trellis-task-brief/SKILL.md

@@ -17,6 +17,7 @@ description: "从最新 prd.md、design.md、implement.md 生成、刷新、校
 - Phase 1.4 前必须展示完整 brief。默认等待用户确认后再运行 `task.py start`；只有用户明确把当前任务或最终 Brief 与“展示后直接开始 / 不用再次确认 / 视为已确认”绑定时，才可在范围未变化的前提下免除第二次确认。
 - “开始做吧”“按你建议来”“可以创建任务”等普通实现或建任务意图不是 Brief 预授权，不能据此跳过确认。
 - 预授权只依赖当前对话中仍然明确可见的用户表达，不建立跨会话永久偏好，也不写 session runtime。
+- `in_progress` 阶段只读取 brief 和任务材料，不例行重新生成、展示或确认；新会话或压缩恢复同样如此。范围变化沿用 workflow 的既有评审门禁，用户明确要求查看时再完整展示。
 - `in_progress` 阶段发现缺失 brief 时，不自动生成未经 review 的 brief；先读取三件套并建议回补。只有用户明确要求当场回补并 review 时，才继续写回 `brief.md`。
 - 不要机械限制 brief 或对话展示长度；信息完整优先，不能截掉会影响实现判断的范围、约束、风险或验收条件。
 
@@ -109,17 +110,7 @@ Phase 1.4 review 前：
 已按你对当前 Brief 的明确预授权完成复核；范围未扩大、无未解决问题，继续启动任务。
 ```
 
-任务已经是 `in_progress` 时，如果 brief 存在，进入 implement route 前复用同样的完整展示：
-
-```markdown
-当前任务 brief：<task>/brief.md
-
-<brief.md 正文>
-
-下一步：进入 `trellis-route(implement)`。
-```
-
-三个展示场景都完整展示 `brief.md` 正文，不压缩、不摘录、不改写字段结构。压缩重述会丢掉 Non-Goals、关键决定或验收条件中影响实现判断的内容，因此不再使用。
+规划评审或用户明确要求查看时，完整展示 `brief.md` 正文，不压缩、不摘录、不改写字段结构，保留 Non-Goals、关键决定和验收条件。
 
 ## 不要做