flower-trellis 0.6.8-beta.0 → 0.6.8-beta.1

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

@@ -145,8 +145,6 @@ interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动
 - **批次 1**：<CHK/FBK 问题 ID> · <修复目标>
 - **修复后**：定向验证 -> Check-All 重检
 
-操作：`修复全部`、`修复 CHK-001,FBK-002`、`接受当前报告全部风险并继续`、`接受风险 CHK-001,FBK-002 并继续`、`仅保留报告`
-
 ### 下一步
 
 <按下方 `Interactive Post-Check Stop Gate` 输出一个明确、可执行的主动作>
@@ -163,7 +161,7 @@ interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动
 - 没有 `DOC-*` 自动修复时省略“自动修复”区。
 - 没有 `CHK-*` 时省略“主路径问题”区；没有 `FBK-*` 时省略“兜底问题”区。
 - 同时存在两类问题时，`### 主路径问题` 及其全部 `CHK-*` 必须完整出现在 `### 兜底问题` 及其全部 `FBK-*` 之前；不得按全局严重度排序反转或交错两个区块。
-- 存在未处置 `CHK-*` 或 `FBK-*` 时展示“修复批次”，并只在报告末尾提供一次处置选择，不再逐项提问。
+- 存在未处置 `CHK-*` 或 `FBK-*` 时，“修复批次”只说明分组与验证安排，处置选择统一在报告末尾“下一步”中提供一次，不再逐项提问。
 - `修复全部` 始终覆盖全部 `CHK-*` 与 `FBK-*`；精确修复可以混合两类 ID。
 - 风险接受可混合两类 ID；“接受当前报告全部风险”覆盖全部剩余问题，包括 P0，无固定句式。全部有效接受后才形成“通过·已接受风险”。
 - interactive 标准报告必须以“下一步”段结束；停止等待不等于省略引导。

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

@@ -144,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

@@ -50,49 +50,48 @@
 ## 共用展示规则
 
 - 计划与结果模板中的字段行必须使用 `- **字段**：值` 列表项。这些行在 Markdown 段落内会被折叠成一段，不得改回裸段落行，也不得依赖行尾空格换行。
-- 「任务记录」是与各仓库区平级的独立 `###` 小节，仅普通模式且存在活动任务时整节展示；不再用方括号条件行代替小节标题。
-- 单仓 `planned` 不超过 8 个文件时完整列出。
+- 计划中的「任务记录」是与各仓库区平级的独立 `###` 小节，仅普通模式且存在活动任务时整节展示；不再用方括号条件行代替小节标题。
+- 计划中单仓 `planned` 不超过 8 个文件时完整列出。
 - 超过 8 个时按目录归组，最多 12 行；用户要求展开时展示同一 exact set。
 - 顶部仓库/commit/file 总数包含独立任务记录提交所在 Git root、该提交及其 exact files；任务记录文件使用相同的 8 文件展示阈值和展开规则。
 - 计划中的保留变更按仓库计数：不超过 8 项时逐项标注 `[untracked]`、`[unstaged]`、`[staged]`；超过 8 项时将非 staged 项按目录与 Git 状态汇总数量，每仓最多 12 行，必要时合并到上级目录。同一路径计数一次，兼有 staged/unstaged 时同时标注。
-- 计划外 staged 项始终逐项单列，不计入分组摘要；真正风险在独立“风险”区逐项展示，两者均不受行数限制。分组、展开均只改变展示，不改变 exact set 或确认范围。
+- 计划中的计划外 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` 流程承接。
+- 计划的完成链证据始终显示当前状态，但不重复 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 结果用“无任务状态”替代“任务进度”，展示 work id 与 `<已清理/保留待恢复>`；不生成或暗示 task progress commit。
+- 仅普通模式且存在活动任务时显示“任务记录”行；没有实际 commit hash 时省略 hash，不填占位值。用户 `commit-only` 的仓库行只写当前分支与本地提交，不显示推送箭头或暗示已同步远端。
+- untracked 结果用“无任务状态”行替代“任务记录”，展示 work id 与 `<已清理/保留待恢复>`；不生成或暗示 task progress commit。没有保留变更、失败或风险时省略对应行或章节。
 - 部分完成时必须明确列出已成功仓库、失败仓库/步骤、当前分支和下一恢复动作。业务结果与 progress sync 状态不得合并成一个模糊结论。
-- 普通成功结果必须确认本任务产生的当前任务目录变更 clean。其它 retained dirty 已核对保持原状时，每仓只报告数量与结论，不重复清单；计划外 staged 项仍逐项确认保留状态。异常或未核验项列出路径、实际状态和处理情况，不得笼统声称全部保持原状；用户要求展开时沿用共用规则。
+- 普通成功结果必须确认本任务产生的当前任务目录变更 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、关键决定和验收条件。
 
 ## 不要做
 

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

@@ -17,7 +17,7 @@ description: "Audit task planning artifacts (prd.md, plus design.md and implemen
 ## 核心原则（不可违反）
 
 1. **原始需求文档是唯一权威** — PRD 必须忠实反映原始需求；Design / Implement 必须忠实反映 PRD，不得自行"理解"、"推演"或"发挥"
-2. **逐条对照，不跳不漏** — 每一层都做正反双向校验（正向看上层有的下层是否覆盖；反向看下层有的能否回溯到上层）
+2. **逐条对照，不跳不漏** — 每一层都做正反双向校验（正向看下层内容能否回溯到上层依据；反向看上层内容是否被下层完整覆盖）
 3. **标记偏差类型** — 区分"缺失 / 曲解 / 发挥过度 / 措辞不准 / 越界 / 跨层漂移"
 4. **文案必须逐字一致** — 原始需求中出现的用户可见文案（按钮文字、提示语、Toast、弹窗内容、表头、placeholder 等）必须在 PRD、Design、Implement 三个文档中**逐字一致**；任何一处不一致直接标记为 ❌ 曲解（不是 ⚠️ 措辞偏差），因为前端会照搬最后看到的版本实现
 5. **只改偏差，不改结构** — 修正内容错误，不改变文档整体格式框架
@@ -103,9 +103,9 @@ python3 ./.trellis/scripts/task.py list
 - 跳过 Step 3.6
 - 不要编造 wave 或 task 候选
 
-### Step 3: 原始需求 ↔ prd.md（正向准确性校验）
+### Step 3: prd.md → 原始需求（正向准确性校验）
 
-将原始需求文档分解为独立条目（逐个需求点 / AC / 功能点），然后逐条在 `prd.md` 中查找对应描述。
+将 `prd.md` 中的需求描述分解为独立条目（逐个需求点 / AC / 功能点），逐条回溯原始需求文档中的依据，核对含义和用户可见文案，识别曲解与自行新增的内容。
 
 对每一条标记状态：
 
@@ -115,13 +115,12 @@ python3 ./.trellis/scripts/task.py list
 | ⚠️ 措辞偏差 | 意思基本对，但措辞可能引起歧义 | 原始："下一行" → PRD："下一条未完结任务" |
 | ❌ 曲解 | PRD 理解错了原始需求的意思 | 原始："按当前列表排序" → PRD："按 taskNo 正序" |
 | ❌ 文案不一致 | UI 可见文案与原始需求不逐字一致（按钮、提示语、Toast、弹窗、表头、placeholder 等） | 原始：提示"确认提交？" → PRD："确认保存？" |
-| 🔴 缺失 | 原始需求有，PRD 里完全没提 | — |
 | 🟡 自行发挥 | PRD 写了原始需求没有的内容 | — |
 
-### Step 3.5: 覆盖度扫描（反向，原始 → PRD）
+### Step 3.5: 原始需求 → prd.md（反向覆盖度扫描）
 
-Step 3 是**正向检查**（PRD 里的内容 → 原始文档里是否有）。
-Step 3.5 是**反向检查**（原始文档里本次版本的变更 → PRD 里是否覆盖）。
+Step 3 检查 PRD 中已写内容的依据与准确性。
+本步从原始需求文档出发，逐条检查本次校验范围内的需求是否完整写入 PRD，识别遗漏与部分覆盖；涉及版本变更时，按下列步骤补齐全文中的变更内容并核对覆盖。
 
 #### 3.5.1 识别本次版本的所有变更内容
 
@@ -341,18 +340,18 @@ Step 3.5 是**反向检查**（原始文档里本次版本的变更 → PRD 里
 
 ---
 
-### 一、原始需求 ↔ prd.md（准确性）
+### 一、prd.md → 原始需求（准确性）
 
 #### 总览
-- 原始需求条目数: N
+- PRD 需求条目数: N
 - ✅ 准确: X 条 ｜ ⚠️ 措辞偏差: X 条 ｜ ❌ 曲解: X 条
-- ❌ 文案不一致: X 条 ｜ 🔴 缺失: X 条 ｜ 🟡 自行发挥: X 条
+- ❌ 文案不一致: X 条 ｜ 🟡 自行发挥: X 条
 
 #### 逐条对照（仅列出非 ✅ 项）
 ##### <需求点>
 - **原始需求**: <原文摘抄 + 位置>
 - **PRD 描述**: <PRD 中的对应内容 + 位置>
-- **状态**: ❌ / ⚠️ / 🔴 / 🟡
+- **状态**: ❌ / ⚠️ / 🟡
 - **问题**: <说明>
 
 ---
@@ -360,7 +359,7 @@ Step 3.5 是**反向检查**（原始文档里本次版本的变更 → PRD 里
 ### 二、原始需求 → prd.md（覆盖度）
 
 #### 总览
-- 原始文档本次版本变更总数: N
+- 本次校验的原始需求 / 版本变更条目数: N
 - ✅ 已覆盖: X ｜ 🔴 未覆盖: X ｜ ⚠️ 部分覆盖: X
 
 #### 未覆盖 / 部分覆盖
@@ -445,8 +444,8 @@ Step 3.5 是**反向检查**（原始文档里本次版本的变更 → PRD 里
 
 ### 六、结论
 
-- **可发布**：✅ 全绿 / ⚠️ 仅有措辞偏差，可进入 Phase 2
-- **需修正**：存在 ❌ / 🔴 / 🟡 偏差，转 Step 8 修正清单
+- **可发布**：✅ 全绿 / ⚠️ 仅有措辞偏差，可进入 Phase 2；符合 Step 4 / 5 判定要求的 🟡 实现必需保留理由说明，本身不影响通过
+- **需修正**：存在 ❌ / 🔴 / 🟡 自行发挥等实际偏差，转 Step 8 修正清单
 - **覆盖缺口**：未覆盖的变更需要补任务还是补 PRD，等用户决策
 ```
 
@@ -454,7 +453,7 @@ Step 3.5 是**反向检查**（原始文档里本次版本的变更 → PRD 里
 
 ### Step 8: 一次性完整修正清单（一次确认 → 批量落盘）
 
-把所有 ❌ / 🔴 / 🟡 / ❌-文案 / 命名漂移 / 边界漂移 汇总为**单一修正清单**，按"目标文件 + 修正项"组织：
+把所有需修正的实际偏差（包括曲解、越界、缺失、自行发挥、文案不一致和跨层漂移）汇总为**单一修正清单**，按"目标文件 + 修正项"组织。符合 Step 4 / 5 判定要求的 🟡 实现必需保留理由说明，不进入修正清单：
 
 ```markdown
 ## 修正清单（请一次性确认；确认后我将批量更新三个文件）

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

@@ -145,8 +145,6 @@ interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动
 - **批次 1**：<CHK/FBK 问题 ID> · <修复目标>
 - **修复后**：定向验证 -> Check-All 重检
 
-操作：`修复全部`、`修复 CHK-001,FBK-002`、`接受当前报告全部风险并继续`、`接受风险 CHK-001,FBK-002 并继续`、`仅保留报告`
-
 ### 下一步
 
 <按下方 `Interactive Post-Check Stop Gate` 输出一个明确、可执行的主动作>
@@ -163,7 +161,7 @@ interactive 完成检查与允许的 DOC 修复后，先自然说明实际改动
 - 没有 `DOC-*` 自动修复时省略“自动修复”区。
 - 没有 `CHK-*` 时省略“主路径问题”区；没有 `FBK-*` 时省略“兜底问题”区。
 - 同时存在两类问题时，`### 主路径问题` 及其全部 `CHK-*` 必须完整出现在 `### 兜底问题` 及其全部 `FBK-*` 之前；不得按全局严重度排序反转或交错两个区块。
-- 存在未处置 `CHK-*` 或 `FBK-*` 时展示“修复批次”，并只在报告末尾提供一次处置选择，不再逐项提问。
+- 存在未处置 `CHK-*` 或 `FBK-*` 时，“修复批次”只说明分组与验证安排，处置选择统一在报告末尾“下一步”中提供一次，不再逐项提问。
 - `修复全部` 始终覆盖全部 `CHK-*` 与 `FBK-*`；精确修复可以混合两类 ID。
 - 风险接受可混合两类 ID；“接受当前报告全部风险”覆盖全部剩余问题，包括 P0，无固定句式。全部有效接受后才形成“通过·已接受风险”。
 - interactive 标准报告必须以“下一步”段结束；停止等待不等于省略引导。