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

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

@@ -44,7 +44,7 @@
 
 `FBK-*` 分类只由具体位置、可达场景和问题证据三项硬准入决定。保护收益与验证方式属于报告完整度；缺少环境时保留 ID 和已有证据，标记 `部分验证`，不得伪报 strict pass。
 
-`CHK-*` 与 `FBK-*` 分开编号。同一根因的多个位置合并到一个问题；报告按严重度排序，但不得因此重排已经分配的 ID。新根因使用对应通道的下一个 ID。每个问题的处置状态默认为待处理且不加标签，只有 `已接受风险` 才在条目标题行末尾追加 `` `[已接受风险]` `` 标签。`仅保留报告` 不改变处置状态，相关问题仍不加标签。处置状态不改变 ID、通道和严重度。
+`CHK-*` 与 `FBK-*` 分开编号。同一根因的多个位置合并到一个问题；严重度排序只在各自通道内部生效，每个通道内部按 `P0 -> P1 -> P2` 展示，但不得因此重排已经分配的 ID。跨通道报告顺序固定为完整 `CHK-*` 区块在前、完整 `FBK-*` 区块在后；禁止因 FBK 严重度更高、分类时先判断 FBK、发现先后或 ID 分配时机而 FBK-first、交错两类问题或省略分区标题。新根因使用对应通道的下一个 ID。每个问题的处置状态默认为待处理且不加标签，只有 `已接受风险` 才在条目标题行末尾追加 `` `[已接受风险]` `` 标签。`仅保留报告` 不改变处置状态，相关问题仍不加标签。处置状态不改变 ID、通道和严重度。
 
 ## 风险接受
 
@@ -144,6 +144,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 - 每个问题的受影响位置合并进 `证据`，不再单列「位置」行。`证据` 写成不带值的 `- **证据**` 后接子项列表，一个受影响 `file:line` 一条子项，不得用 `；` 把多个位置堆进一行，也不得只写概括性描述。
 - 没有 `DOC-*` 自动修复时省略“自动修复”区。
 - 没有 `CHK-*` 时省略“主路径问题”区；没有 `FBK-*` 时省略“兜底问题”区。
+- 同时存在两类问题时，`### 主路径问题` 及其全部 `CHK-*` 必须完整出现在 `### 兜底问题` 及其全部 `FBK-*` 之前；不得按全局严重度排序反转或交错两个区块。
 - 存在未处置 `CHK-*` 或 `FBK-*` 时展示“修复批次”，并只在报告末尾提供一次处置选择，不再逐项提问。
 - `修复全部` 始终覆盖全部 `CHK-*` 与 `FBK-*`；精确修复可以混合两类 ID。
 - 风险接受可以混合两类 ID；只有全部剩余问题都已有效接受时才形成“通过·已接受风险”。

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

@@ -67,6 +67,8 @@ python3 ./.trellis/scripts/task_progress.py status --json || true
 git status --short --untracked-files=all -- <task-dir>
 ```
 
+若 `task_progress.py status` 返回 `taskStatus=completed`，立即按需读取 `references/completed-task-recovery.md`，由该 reference 完成只读 preflight 并返回“恢复计划 / 显式 finish-work / 阻断”之一。在得到结果前不得进入普通业务规划，也不得重复已经成功的业务 Git 动作。reference 缺失、不可读或证据无法闭合时失败关闭；`task.json.progress` 只作诊断，不能单独选择恢复动作。
+
 不得把默认 `git status --short` 可能返回的 `?? <task-dir>/` 折叠目录当成 exact file、展示条目或 pathspec。无活动 task 时仍可提交相关代码，但不生成任务进度。untracked 命中时，结合当前请求、work summary 和实际 diff 判断业务 `planned` 文件归属，计划同时显示 work id；无法明确归属的文件只能保留或作为风险。存在活动 task 时，结合 `brief.md`、`implement.md`、当前 diff 与本轮执行范围生成一行语义进度；同时识别当前任务目录中已存在且可归属的 dirty/untracked 产物，供 Step 5 生成任务记录 exact files。不得从旧进度推断 Git 动作。
 
 ## Step 2：预检与文件归属
@@ -196,7 +198,7 @@ auto-loop 内部链失败时向调用方返回全部已完成仓库提交和失
 
 ## Step 5：同步任务进度
 
-仅普通模式且存在活动 task 时由本 skill 执行。untracked、用户 `commit-only` 与 auto-loop 内部 `commit-only` 都跳过本 Step；Auto-Loop runner 在 action record/next 后按自身契约写入本地 `task.json.progress`，不属于这里的任务进度提交或推送。全部业务仓库成功后先写完整进度并保持 `in_progress`，只在任务进度 commit/push 成功后原子请求 `in_progress -> completed`；已有仓库成功而后续仓库失败时只写 partial 进度，明确 completed、失败位置、next 和 notes，状态保持 `in_progress`。尚未发生成功 Git 动作就失败时，不记录虚假的 completed steps；只有父仓仍可安全提交并推送时才允许记录 failure notes。
+仅普通模式且存在活动 task 时由本 skill 执行。untracked、用户 `commit-only` 与 auto-loop 内部 `commit-only` 都跳过本 Step；Auto-Loop runner 在 action record/next 后按自身契约写入本地 `task.json.progress`，不属于这里的任务记录提交或推送。全部业务仓库成功后一次原子写入最终 progress 与完成态，再提交并推送任务记录；已有仓库成功而后续仓库失败时只写 partial 进度，明确 completed、失败位置、next 和 notes，状态保持 `in_progress`。尚未发生成功 Git 动作就失败时，不记录虚假的 completed steps；只有父仓仍可安全提交并推送时才允许记录 failure notes。
 
 新进度固定为：
 
@@ -218,18 +220,19 @@ auto-loop 内部链失败时向调用方返回全部已完成仓库提交和失
 - 父仓分支、upstream 和冲突状态安全。
 - 推送不会携带无法归属的历史 ahead commits。
 
-全部业务 commit/push 成功时先通过 helper 写入最终 progress，但不得携带 `--complete`：
+全部业务 commit/push 成功时，通过 helper 用同一份最终 progress 原子写入 `progress`、`status=completed` 与 `completedAt`：
 
 ```bash
 python3 ./.trellis/scripts/task_progress.py write \
   --task <task-dir> \
   --progress-json '<progress-json>' \
+  --complete \
   --json
 ```
 
-部分成功时调用同一 helper，并写入精确恢复位置。用户 `commit-only`、auto-loop 内部 `commit-only` 和尚未发生任何成功业务 Git 动作的失败都不得由本 skill 请求 complete；auto-loop 的本地完成态由 Auto-Loop runner 自己写入，不经过本步骤。helper 写入失败时任务保持原状态，不得继续任务进度提交或报告完成。
+部分成功时调用同一 helper，但不得携带 `--complete`，并写入精确恢复位置。用户 `commit-only`、auto-loop 内部 `commit-only` 和尚未发生任何成功业务 Git 动作的失败都不得由本 skill 请求 complete；auto-loop 的本地完成态由 Auto-Loop runner 自己写入，不经过本步骤。helper 写入失败时任务保持原状态，不得继续任务记录提交或报告完成。
 
-然后只提交并推送首次确认的当前任务 exact files；该集合包含 helper 更新后的 `task.json`，以及首次计划时已存在且可归属的当前任务 dirty/untracked 产物：
+helper 成功后，只提交并推送首次确认的当前任务 exact files；该集合包含完成态 `task.json`，以及首次计划时已存在且可归属的当前任务 dirty/untracked 产物：
 
 ```bash
 git add -- <current-task-exact-files>
@@ -237,19 +240,16 @@ git commit --only -m "chore(task): update <task-name> progress" -- <current-task
 git push origin <current-branch>
 ```
 
-该动作属于用户已确认的普通 push 计划，不增加第二次确认。提交后必须验证 commit 只包含首次确认的当前任务 exact files；其他任务和无关 dirty/staged 文件保持原状。如果写入、提交或推送失败，不回滚已成功的业务 Git 动作，并单独报告进度同步失败；任务必须保持 `in_progress`，不得进入完成态。
+该动作属于用户已确认的普通 push 计划，不增加第二次确认。提交后必须验证 commit 只包含首次确认的当前任务 exact files，且 `task.json` 已包含同一份最终 progress、`status=completed` 与 `completedAt`；其他任务和无关 dirty/staged 文件保持原状。
 
-只有进度 commit 和 push 都成功后，才用同一份最终 progress 原子写入本地 `status=completed` 和 `completedAt`：
+失败时保留真实现场，不 reset、amend、revert 或制造 dirty 回滚：
 
-```bash
-python3 ./.trellis/scripts/task_progress.py write \
-  --task <task-dir> \
-  --progress-json '<same-final-progress-json>' \
-  --complete \
-  --json
-```
+- helper 失败：任务保持 `in_progress`，不得创建任务记录 commit。
+- helper 成功但任务记录 commit 失败：保留本地 `completed` 与当前任务 exact dirty，后续按 Step 1 的任务记录 commit 恢复路径重新验证和确认；不得重复业务提交或 helper 写入。
+- 任务记录 commit 成功但 push 失败：任务目录应为 clean，并保留可归属的 ahead commit；后续只重试该 commit 的 push，不重复业务提交、helper 写入或任务记录 commit。
+- 任务记录 push 成功：本任务产生的当前任务目录变更必须 clean；不得再写入第二份预归档完成态。
 
-该完成态写入不再创建第二个 progress commit；它作为活动任务的预归档生命周期变化保留，由显式 `trellis-finish-work` 的 archive bookkeeping commit 承接。如果完成态写入失败，远端最终 progress 已同步，但任务仍为 `in_progress`；报告完成态激活失败并允许精确重试该 helper，禁止重新执行已成功的业务 push 或 progress push。
+任何恢复都必须验证当前分支、upstream、HEAD、`@{u}..HEAD`、任务记录 commit message 与 exact file set，以及 `task.json` 的最终完成态。无法证明归属时停止，不把未知 ahead 或 dirty 当作可恢复任务记录。
 
 ## Step 6：结果
 

package/enhancements/0.6/.agents/skills/trellis-push/references/completed-task-recovery.md

@@ -0,0 +1,19 @@
+# Completed Task Recovery
+
+本 reference 只在 `task_progress.py status` 返回 `taskStatus=completed` 时加载。它是普通任务记录发布恢复的唯一详细语义 owner；`trellis-continue`、completed workflow-state 和 `trellis-finish-work` 不复制本分支矩阵。
+
+## Evidence
+
+固定当前任务路径与 `task.json`，读取文件级任务状态、当前分支、upstream、`HEAD`、`@{u}..HEAD` 的提交消息与文件集合，以及 `python3 ./.trellis/scripts/auto_loop.py status --verbose`。所有恢复都必须验证 exact task、最终 progress、`completedAt`、分支和提交归属；progress 文本不能替代 runtime 或 Git 证据。
+
+## Outcomes
+
+按以下优先级只返回一个结果：
+
+1. **显式 finish-work，auto-loop**：健康的终态或 recent auto-loop run 的 `pending_archive.tasks_awaiting_archive` 精确包含当前任务，记录的本地提交仍可验证，且任务 dirty 仅为 runner 在提交后写入的 `<task-dir>/task.json` progress/lifecycle bookkeeping。停止 Push，不得把该本地完成态改成普通远端 push。
+2. **任务记录 commit + push 恢复计划**：没有有效 auto-loop handoff；当前任务 exact files 仍 dirty，`task.json` 已包含合法最终 progress、`status=completed` 与 `completedAt`，且文件集合可由首次确认或重新确认闭合。不得重复 helper 写入或业务提交。
+3. **任务记录 push-only 恢复计划**：当前任务目录 clean；upstream 存在；`@{u}..HEAD` 中存在消息、exact file set 和完成态均可归属的任务记录 commit。只推送该已存在提交，不创建新 commit。
+4. **显式 finish-work，普通已同步**：当前任务目录 clean；upstream 存在；`@{u}..HEAD` 没有提交修改当前任务。普通任务记录已经同步，不再执行 Push。
+5. **阻断**：runtime 与 Git 矛盾、auto-loop marker 无健康 handoff、缺少普通路径 upstream、任务 dirty 超出 exact files、未知 ahead 修改任务，或提交消息/文件集合/分支无法闭合。报告具体证据缺口，不 push、不归档，也不猜测完成来源。
+
+恢复计划仍使用 `trellis-push` 的既有一次确认、执行前漂移检查和结果模板。这里只决定完成态恢复范围，不新增状态、持久化字段或自动确认。

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

@@ -43,7 +43,7 @@
 - **仓库**：<repository-name> · 分支：`<branch>` -> `<upstream>`
 - **计划提交**：<当前任务 exact files 或分组摘要>
 - **进度**：completed=<...> | partial=<...> | next=<...>
-- **执行**：<commit -> push -> progress commit -> progress push>
+- **执行**：<business commit/push -> `task_progress.py write --complete` -> task-record commit -> task-record push>
 
 确认执行请回复 `确认`。可调整：`只提交`、`修改 message`、`展开文件`。
 ```
@@ -79,7 +79,7 @@
 
 ### 任务进度
 
-- **状态**：<✓ 已同步并进入 completed · `<progress-hash>` / ✓ partial 已同步且保持 in_progress / · 已跳过 / ❌ 同步失败，不得报告完成>
+- **状态**：<✓ completed 已提交并推送 · `<task-record-hash>` / ✓ partial 已同步且保持 in_progress / · 已跳过 / ❌ 任务记录 commit 待恢复 / ❌ 任务记录 push 待恢复 / ❌ 同步失败，不得报告完成>
 - **记录**：<N> 个当前任务文件
 - **进度**：completed=<...> | partial=<...> | next=<...>
 - **失败原因**：<原因和恢复动作>（仅失败时显示）
@@ -94,3 +94,6 @@
 
 - untracked 结果用“无任务状态”替代“任务进度”，展示 work id 与 `<已清理/保留待恢复>`；不生成或暗示 task progress commit。
 - 部分完成时必须明确列出已成功仓库、失败仓库/步骤、当前分支和下一恢复动作。业务结果与 progress sync 状态不得合并成一个模糊结论。
+- 普通成功结果必须确认本任务产生的当前任务目录变更 clean；其它 retained dirty 仍按原状态逐项展示。
+- helper 成功但任务记录 commit 失败时，结果写“任务记录 commit 待恢复”，说明本地 `completed` 与 exact task dirty 已保留；任务记录 commit 成功但 push 失败时写“任务记录 push 待恢复”，说明 clean ahead commit 已保留。两种情况都不得暗示需要重复业务提交或 helper 写入。
+- validated auto-loop local completion 不渲染本模板，也不得被普通结果文案描述为任务记录 push 待恢复。

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

@@ -44,7 +44,7 @@
 
 `FBK-*` 分类只由具体位置、可达场景和问题证据三项硬准入决定。保护收益与验证方式属于报告完整度；缺少环境时保留 ID 和已有证据，标记 `部分验证`，不得伪报 strict pass。
 
-`CHK-*` 与 `FBK-*` 分开编号。同一根因的多个位置合并到一个问题；报告按严重度排序，但不得因此重排已经分配的 ID。新根因使用对应通道的下一个 ID。每个问题的处置状态默认为待处理且不加标签，只有 `已接受风险` 才在条目标题行末尾追加 `` `[已接受风险]` `` 标签。`仅保留报告` 不改变处置状态，相关问题仍不加标签。处置状态不改变 ID、通道和严重度。
+`CHK-*` 与 `FBK-*` 分开编号。同一根因的多个位置合并到一个问题；严重度排序只在各自通道内部生效，每个通道内部按 `P0 -> P1 -> P2` 展示，但不得因此重排已经分配的 ID。跨通道报告顺序固定为完整 `CHK-*` 区块在前、完整 `FBK-*` 区块在后；禁止因 FBK 严重度更高、分类时先判断 FBK、发现先后或 ID 分配时机而 FBK-first、交错两类问题或省略分区标题。新根因使用对应通道的下一个 ID。每个问题的处置状态默认为待处理且不加标签，只有 `已接受风险` 才在条目标题行末尾追加 `` `[已接受风险]` `` 标签。`仅保留报告` 不改变处置状态，相关问题仍不加标签。处置状态不改变 ID、通道和严重度。
 
 ## 风险接受
 
@@ -144,6 +144,7 @@ interactive 模式完成所有可继续检查和允许的 `DOC-*` 自动修复
 - 每个问题的受影响位置合并进 `证据`，不再单列「位置」行。`证据` 写成不带值的 `- **证据**` 后接子项列表，一个受影响 `file:line` 一条子项，不得用 `；` 把多个位置堆进一行，也不得只写概括性描述。
 - 没有 `DOC-*` 自动修复时省略“自动修复”区。
 - 没有 `CHK-*` 时省略“主路径问题”区；没有 `FBK-*` 时省略“兜底问题”区。
+- 同时存在两类问题时，`### 主路径问题` 及其全部 `CHK-*` 必须完整出现在 `### 兜底问题` 及其全部 `FBK-*` 之前；不得按全局严重度排序反转或交错两个区块。
 - 存在未处置 `CHK-*` 或 `FBK-*` 时展示“修复批次”，并只在报告末尾提供一次处置选择，不再逐项提问。
 - `修复全部` 始终覆盖全部 `CHK-*` 与 `FBK-*`；精确修复可以混合两类 ID。
 - 风险接受可以混合两类 ID；只有全部剩余问题都已有效接受时才形成“通过·已接受风险”。

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

@@ -67,6 +67,8 @@ python3 ./.trellis/scripts/task_progress.py status --json || true
 git status --short --untracked-files=all -- <task-dir>
 ```
 
+若 `task_progress.py status` 返回 `taskStatus=completed`，立即按需读取 `references/completed-task-recovery.md`，由该 reference 完成只读 preflight 并返回“恢复计划 / 显式 finish-work / 阻断”之一。在得到结果前不得进入普通业务规划，也不得重复已经成功的业务 Git 动作。reference 缺失、不可读或证据无法闭合时失败关闭；`task.json.progress` 只作诊断，不能单独选择恢复动作。
+
 不得把默认 `git status --short` 可能返回的 `?? <task-dir>/` 折叠目录当成 exact file、展示条目或 pathspec。无活动 task 时仍可提交相关代码，但不生成任务进度。untracked 命中时，结合当前请求、work summary 和实际 diff 判断业务 `planned` 文件归属，计划同时显示 work id；无法明确归属的文件只能保留或作为风险。存在活动 task 时，结合 `brief.md`、`implement.md`、当前 diff 与本轮执行范围生成一行语义进度；同时识别当前任务目录中已存在且可归属的 dirty/untracked 产物，供 Step 5 生成任务记录 exact files。不得从旧进度推断 Git 动作。
 
 ## Step 2：预检与文件归属
@@ -196,7 +198,7 @@ auto-loop 内部链失败时向调用方返回全部已完成仓库提交和失
 
 ## Step 5：同步任务进度
 
-仅普通模式且存在活动 task 时由本 skill 执行。untracked、用户 `commit-only` 与 auto-loop 内部 `commit-only` 都跳过本 Step；Auto-Loop runner 在 action record/next 后按自身契约写入本地 `task.json.progress`，不属于这里的任务进度提交或推送。全部业务仓库成功后先写完整进度并保持 `in_progress`，只在任务进度 commit/push 成功后原子请求 `in_progress -> completed`；已有仓库成功而后续仓库失败时只写 partial 进度，明确 completed、失败位置、next 和 notes，状态保持 `in_progress`。尚未发生成功 Git 动作就失败时，不记录虚假的 completed steps；只有父仓仍可安全提交并推送时才允许记录 failure notes。
+仅普通模式且存在活动 task 时由本 skill 执行。untracked、用户 `commit-only` 与 auto-loop 内部 `commit-only` 都跳过本 Step；Auto-Loop runner 在 action record/next 后按自身契约写入本地 `task.json.progress`，不属于这里的任务记录提交或推送。全部业务仓库成功后一次原子写入最终 progress 与完成态，再提交并推送任务记录；已有仓库成功而后续仓库失败时只写 partial 进度，明确 completed、失败位置、next 和 notes，状态保持 `in_progress`。尚未发生成功 Git 动作就失败时，不记录虚假的 completed steps；只有父仓仍可安全提交并推送时才允许记录 failure notes。
 
 新进度固定为：
 
@@ -218,18 +220,19 @@ auto-loop 内部链失败时向调用方返回全部已完成仓库提交和失
 - 父仓分支、upstream 和冲突状态安全。
 - 推送不会携带无法归属的历史 ahead commits。
 
-全部业务 commit/push 成功时先通过 helper 写入最终 progress，但不得携带 `--complete`：
+全部业务 commit/push 成功时，通过 helper 用同一份最终 progress 原子写入 `progress`、`status=completed` 与 `completedAt`：
 
 ```bash
 python3 ./.trellis/scripts/task_progress.py write \
   --task <task-dir> \
   --progress-json '<progress-json>' \
+  --complete \
   --json
 ```
 
-部分成功时调用同一 helper，并写入精确恢复位置。用户 `commit-only`、auto-loop 内部 `commit-only` 和尚未发生任何成功业务 Git 动作的失败都不得由本 skill 请求 complete；auto-loop 的本地完成态由 Auto-Loop runner 自己写入，不经过本步骤。helper 写入失败时任务保持原状态，不得继续任务进度提交或报告完成。
+部分成功时调用同一 helper，但不得携带 `--complete`，并写入精确恢复位置。用户 `commit-only`、auto-loop 内部 `commit-only` 和尚未发生任何成功业务 Git 动作的失败都不得由本 skill 请求 complete；auto-loop 的本地完成态由 Auto-Loop runner 自己写入，不经过本步骤。helper 写入失败时任务保持原状态，不得继续任务记录提交或报告完成。
 
-然后只提交并推送首次确认的当前任务 exact files；该集合包含 helper 更新后的 `task.json`，以及首次计划时已存在且可归属的当前任务 dirty/untracked 产物：
+helper 成功后，只提交并推送首次确认的当前任务 exact files；该集合包含完成态 `task.json`，以及首次计划时已存在且可归属的当前任务 dirty/untracked 产物：
 
 ```bash
 git add -- <current-task-exact-files>
@@ -237,19 +240,16 @@ git commit --only -m "chore(task): update <task-name> progress" -- <current-task
 git push origin <current-branch>
 ```
 
-该动作属于用户已确认的普通 push 计划，不增加第二次确认。提交后必须验证 commit 只包含首次确认的当前任务 exact files；其他任务和无关 dirty/staged 文件保持原状。如果写入、提交或推送失败，不回滚已成功的业务 Git 动作，并单独报告进度同步失败；任务必须保持 `in_progress`，不得进入完成态。
+该动作属于用户已确认的普通 push 计划，不增加第二次确认。提交后必须验证 commit 只包含首次确认的当前任务 exact files，且 `task.json` 已包含同一份最终 progress、`status=completed` 与 `completedAt`；其他任务和无关 dirty/staged 文件保持原状。
 
-只有进度 commit 和 push 都成功后，才用同一份最终 progress 原子写入本地 `status=completed` 和 `completedAt`：
+失败时保留真实现场，不 reset、amend、revert 或制造 dirty 回滚：
 
-```bash
-python3 ./.trellis/scripts/task_progress.py write \
-  --task <task-dir> \
-  --progress-json '<same-final-progress-json>' \
-  --complete \
-  --json
-```
+- helper 失败：任务保持 `in_progress`，不得创建任务记录 commit。
+- helper 成功但任务记录 commit 失败：保留本地 `completed` 与当前任务 exact dirty，后续按 Step 1 的任务记录 commit 恢复路径重新验证和确认；不得重复业务提交或 helper 写入。
+- 任务记录 commit 成功但 push 失败：任务目录应为 clean，并保留可归属的 ahead commit；后续只重试该 commit 的 push，不重复业务提交、helper 写入或任务记录 commit。
+- 任务记录 push 成功：本任务产生的当前任务目录变更必须 clean；不得再写入第二份预归档完成态。
 
-该完成态写入不再创建第二个 progress commit；它作为活动任务的预归档生命周期变化保留，由显式 `trellis-finish-work` 的 archive bookkeeping commit 承接。如果完成态写入失败，远端最终 progress 已同步，但任务仍为 `in_progress`；报告完成态激活失败并允许精确重试该 helper，禁止重新执行已成功的业务 push 或 progress push。
+任何恢复都必须验证当前分支、upstream、HEAD、`@{u}..HEAD`、任务记录 commit message 与 exact file set，以及 `task.json` 的最终完成态。无法证明归属时停止，不把未知 ahead 或 dirty 当作可恢复任务记录。
 
 ## Step 6：结果
 

package/enhancements/0.6/.claude/skills/trellis-push/references/completed-task-recovery.md

@@ -0,0 +1,19 @@
+# Completed Task Recovery
+
+本 reference 只在 `task_progress.py status` 返回 `taskStatus=completed` 时加载。它是普通任务记录发布恢复的唯一详细语义 owner；`trellis-continue`、completed workflow-state 和 `trellis-finish-work` 不复制本分支矩阵。
+
+## Evidence
+
+固定当前任务路径与 `task.json`，读取文件级任务状态、当前分支、upstream、`HEAD`、`@{u}..HEAD` 的提交消息与文件集合，以及 `python3 ./.trellis/scripts/auto_loop.py status --verbose`。所有恢复都必须验证 exact task、最终 progress、`completedAt`、分支和提交归属；progress 文本不能替代 runtime 或 Git 证据。
+
+## Outcomes
+
+按以下优先级只返回一个结果：
+
+1. **显式 finish-work，auto-loop**：健康的终态或 recent auto-loop run 的 `pending_archive.tasks_awaiting_archive` 精确包含当前任务，记录的本地提交仍可验证，且任务 dirty 仅为 runner 在提交后写入的 `<task-dir>/task.json` progress/lifecycle bookkeeping。停止 Push，不得把该本地完成态改成普通远端 push。
+2. **任务记录 commit + push 恢复计划**：没有有效 auto-loop handoff；当前任务 exact files 仍 dirty，`task.json` 已包含合法最终 progress、`status=completed` 与 `completedAt`，且文件集合可由首次确认或重新确认闭合。不得重复 helper 写入或业务提交。
+3. **任务记录 push-only 恢复计划**：当前任务目录 clean；upstream 存在；`@{u}..HEAD` 中存在消息、exact file set 和完成态均可归属的任务记录 commit。只推送该已存在提交，不创建新 commit。
+4. **显式 finish-work，普通已同步**：当前任务目录 clean；upstream 存在；`@{u}..HEAD` 没有提交修改当前任务。普通任务记录已经同步，不再执行 Push。
+5. **阻断**：runtime 与 Git 矛盾、auto-loop marker 无健康 handoff、缺少普通路径 upstream、任务 dirty 超出 exact files、未知 ahead 修改任务，或提交消息/文件集合/分支无法闭合。报告具体证据缺口，不 push、不归档，也不猜测完成来源。
+
+恢复计划仍使用 `trellis-push` 的既有一次确认、执行前漂移检查和结果模板。这里只决定完成态恢复范围，不新增状态、持久化字段或自动确认。

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

@@ -43,7 +43,7 @@
 - **仓库**：<repository-name> · 分支：`<branch>` -> `<upstream>`
 - **计划提交**：<当前任务 exact files 或分组摘要>
 - **进度**：completed=<...> | partial=<...> | next=<...>
-- **执行**：<commit -> push -> progress commit -> progress push>
+- **执行**：<business commit/push -> `task_progress.py write --complete` -> task-record commit -> task-record push>
 
 确认执行请回复 `确认`。可调整：`只提交`、`修改 message`、`展开文件`。
 ```
@@ -79,7 +79,7 @@
 
 ### 任务进度
 
-- **状态**：<✓ 已同步并进入 completed · `<progress-hash>` / ✓ partial 已同步且保持 in_progress / · 已跳过 / ❌ 同步失败，不得报告完成>
+- **状态**：<✓ completed 已提交并推送 · `<task-record-hash>` / ✓ partial 已同步且保持 in_progress / · 已跳过 / ❌ 任务记录 commit 待恢复 / ❌ 任务记录 push 待恢复 / ❌ 同步失败，不得报告完成>
 - **记录**：<N> 个当前任务文件
 - **进度**：completed=<...> | partial=<...> | next=<...>
 - **失败原因**：<原因和恢复动作>（仅失败时显示）
@@ -94,3 +94,6 @@
 
 - untracked 结果用“无任务状态”替代“任务进度”，展示 work id 与 `<已清理/保留待恢复>`；不生成或暗示 task progress commit。
 - 部分完成时必须明确列出已成功仓库、失败仓库/步骤、当前分支和下一恢复动作。业务结果与 progress sync 状态不得合并成一个模糊结论。
+- 普通成功结果必须确认本任务产生的当前任务目录变更 clean；其它 retained dirty 仍按原状态逐项展示。
+- helper 成功但任务记录 commit 失败时，结果写“任务记录 commit 待恢复”，说明本地 `completed` 与 exact task dirty 已保留；任务记录 commit 成功但 push 失败时写“任务记录 push 待恢复”，说明 clean ahead commit 已保留。两种情况都不得暗示需要重复业务提交或 helper 写入。
+- validated auto-loop local completion 不渲染本模板，也不得被普通结果文案描述为任务记录 push 待恢复。

package/enhancements/0.6/overrides/conflicts.json

@@ -606,10 +606,10 @@
           "<!-- BEGIN skill-garden patch trellis-continue-task-progress-recovery v0.6 -->\n## Step 1.5: Recover Saved Task Progress",
           "python3 ./.trellis/scripts/task_progress.py status --json",
           "Never rebind the session or task automatically.",
-          "Progress never overrides the task `status`, planning artifacts, or workflow ordering.",
+          "Progress never overrides the task `status`, planning artifacts, workflow ordering, auto-loop runtime, or Git publication evidence.",
           "taskStatus=completed",
           "task_progress.py reopen --task <task-name> --json",
-          "`status=completed` (observable after successful final-progress sync)",
+          "Enter the `trellis-push` completed-task preflight",
           "### Planning Resume Gate",
           "enter `trellis-brainstorm` before using artifact presence",
           "wait for a current explicit user confirmation before `task.py start`"
@@ -631,10 +631,10 @@
         "values": [
           "<!-- BEGIN skill-garden patch trellis-continue-task-progress-recovery v0.6 -->\n## Step 1.5: Recover Saved Task Progress",
           "python3 ./.trellis/scripts/task_progress.py status --json",
-          "Do not infer a Phase from progress",
+          "Do not inspect or classify completed Git recovery here",
           "taskStatus=completed",
           "task_progress.py reopen --task <task-name> --json",
-          "`status=completed` (observable after successful final-progress sync)",
+          "Enter the `trellis-push` completed-task preflight",
           "### Planning Resume Gate",
           "enter `trellis-brainstorm` before using artifact presence",
           "wait for a current explicit user confirmation before `task.py start`"
@@ -896,7 +896,7 @@
           "Do not add a parallel workflow injector",
           "<!-- BEGIN skill-garden patch trellis-meta-managed-continue-recovery v0.6 -->\n## `/trellis:continue` Recovery Ownership",
           "never bind a session automatically",
-          "A `completed` task points only to explicit `trellis-finish-work` and archive",
+          "A `completed` task enters the `trellis-push` completed-task preflight",
           "Direct edits are valid only for unowned local sections"
         ]
       },
@@ -922,7 +922,7 @@
           "Do not add a parallel workflow injector",
           "<!-- BEGIN skill-garden patch trellis-meta-managed-continue-recovery v0.6 -->\n## `/trellis:continue` Recovery Ownership",
           "never bind a session automatically",
-          "A `completed` task points only to explicit `trellis-finish-work` and archive",
+          "A `completed` task enters the `trellis-push` completed-task preflight",
           "Direct edits are valid only for unowned local sections"
         ]
       },
@@ -946,7 +946,7 @@
           "<!-- BEGIN skill-garden patch trellis-meta-managed-task-readiness v0.6 -->",
           "Saved progress is advisory recovery evidence only.",
           "<!-- BEGIN skill-garden patch trellis-meta-managed-active-task-lifecycle v0.6 -->\n## Active Task And Lifecycle",
-          "in_progress -> trellis-push final progress commit/push -> local completed",
+          "in_progress -> business push -> atomic final progress + completed -> task-record commit/push",
           "never bind a session automatically"
         ]
       },
@@ -970,7 +970,7 @@
           "<!-- BEGIN skill-garden patch trellis-meta-managed-task-readiness v0.6 -->",
           "Saved progress is advisory recovery evidence only.",
           "<!-- BEGIN skill-garden patch trellis-meta-managed-active-task-lifecycle v0.6 -->\n## Active Task And Lifecycle",
-          "in_progress -> trellis-push final progress commit/push -> local completed",
+          "in_progress -> business push -> atomic final progress + completed -> task-record commit/push",
           "never bind a session automatically"
         ]
       },
@@ -992,7 +992,7 @@
           "Change normal completion activation",
           "| Change interruption recovery or candidate rebinding | `trellis-continue` owns the user decision, `task_progress.py` owns candidate evidence, and `task.py start` with `.trellis/scripts/common/active_task.py` owns the explicit session bind; never bind a candidate automatically. |",
           "<!-- BEGIN skill-garden patch trellis-meta-managed-lifecycle-modification-steps v0.6 -->\n## Modification Steps",
-          "final progress synchronization before local completion",
+          "normal final progress and completion written atomically before the task-record commit/push",
           "change the canonical Patch/skill/helper source"
         ]
       },
@@ -1014,7 +1014,7 @@
           "Change normal completion activation",
           "| Change interruption recovery or candidate rebinding | `trellis-continue` owns the user decision, `task_progress.py` owns candidate evidence, and `task.py start` with `.trellis/scripts/common/active_task.py` owns the explicit session bind; never bind a candidate automatically. |",
           "<!-- BEGIN skill-garden patch trellis-meta-managed-lifecycle-modification-steps v0.6 -->\n## Modification Steps",
-          "final progress synchronization before local completion",
+          "normal final progress and completion written atomically before the task-record commit/push",
           "change the canonical Patch/skill/helper source"
         ]
       },
@@ -1604,8 +1604,8 @@
         "type": "required-literal",
         "values": [
           "<!-- BEGIN skill-garden patch workflow-state-completed v0.6 -->",
-          "Business push and task progress are complete.",
-          "Do not resume implementation, Update-Spec, or trellis-push automatically.",
+          "Business work and final task progress are complete",
+          "Enter the `trellis-push` completed-task preflight for the single next hop",
           "task_progress.py reopen --task <task-name> --json"
         ]
       },
@@ -1621,7 +1621,7 @@
         "type": "required-literal",
         "values": [
           "Skill-Garden-managed project",
-          "After successful task-progress push, before explicit archive",
+          "After completion write, before Push-owned recovery preflight or archive",
           "Do not run upstream `trellis update` expecting a direct edit to managed output to persist."
         ]
       },

package/enhancements/0.6/overrides/patches/skills/trellis-continue/task-progress-recovery/completed-route-content.md

@@ -1 +1 @@
-- `status=completed` (observable after successful final-progress sync) → explicit `trellis-finish-work` archive flow; do not resume Phase 2 or Phase 3.3/3.4
+- `status=completed` -> enter the `trellis-push` completed-task preflight. It either prepares publication recovery, points to explicit `trellis-finish-work`, or blocks on ambiguous evidence. Do not resume Phase 2 or Phase 3.3.

package/enhancements/0.6/overrides/patches/skills/trellis-continue/task-progress-recovery/content.md

@@ -9,11 +9,11 @@ python3 ./.trellis/scripts/task_progress.py status --json
 Treat the structured result as advisory recovery evidence only:
 
 - For `status=ok` with `taskStatus=in_progress`, relay only `summary.partialStep`, `summary.nextStep`, and notes that are necessary to resume safely.
-- For `status=ok` with `taskStatus=completed`, do not resume Phase 2 or Phase 3.3/3.4. Point only to explicit `trellis-finish-work` archive, unless the user explicitly requests rework.
-- For `status=candidates`, relay each healthy candidate with its `taskStatus` plus necessary `invalidCandidates` or `scanWarnings`, and suggest an explicit rebind when appropriate. A completed candidate points to finish-work/archive, not implementation. Never rebind the session or task automatically.
+- For `status=ok` with `taskStatus=completed`, do not resume Phase 2 or Phase 3.3. Enter the `trellis-push` completed-task preflight; it is the one-hop owner that either prepares publication recovery, points to explicit `trellis-finish-work`, or blocks on ambiguous evidence.
+- For `status=candidates`, relay each healthy candidate with its `taskStatus` plus necessary `invalidCandidates` or `scanWarnings`, and suggest an explicit rebind when appropriate. After explicit rebind, a completed candidate uses the same Push preflight. Never rebind the session or task automatically.
 - For `status=no-progress` or `status=no-current-task`, continue without inventing saved progress. For `status=error`, report the structured blocker instead of guessing.
 
-Progress never overrides the task `status`, planning artifacts, or workflow ordering. Do not infer a Phase from progress, restore a previous push mode, or resume Git/commit orchestration from it.
+Progress never overrides the task `status`, planning artifacts, workflow ordering, auto-loop runtime, or Git publication evidence. Do not inspect or classify completed Git recovery here, infer a Phase from progress, restore a previous push mode, or resume Git/commit orchestration from progress text.
 
 To rework a completed task, first obtain an explicit user decision, then run:
 

package/enhancements/0.6/overrides/patches/skills/trellis-finish-work/exact-bookkeeping/content.md

@@ -9,9 +9,11 @@ Before moving files, record:
 - The active task source path, task name, and `task.json.children`.
 - Current branch, upstream, `HEAD`, upstream HEAD, and `@{u}..HEAD`.
 - `baseline_synced=true` only when an upstream exists and the initial `HEAD` equals upstream HEAD.
+- File-level `git status --short --untracked-files=all -- <current-task-dir>` and commits in `@{u}..HEAD` that modify the current task when an upstream exists.
+- `python3 ./.trellis/scripts/auto_loop.py status --verbose` output needed to identify a healthy terminal `pending_archive.tasks_awaiting_archive` handoff for this exact task.
 - Existing staged paths outside this task so they can be verified after scoped commits.
 
-Unrelated planning tasks, old archives, and files from other windows remain untouched. They do not require classification and do not block finish-work. Stop and return to Phase 3.4 only when the current task still has uncommitted business files, or when Git is unsafe because of detached HEAD, conflicts, rebase, or another blocking state.
+Unrelated planning tasks, old archives, and files from other windows remain untouched. They do not require classification and do not block finish-work. Stop when publication or the validated auto-loop handoff cannot be proven, when the current task has uncommitted files outside the exception below, or when Git is unsafe because of detached HEAD, conflicts, rebase, or another blocking state.
 
 Follow the steps below in order.
 
@@ -26,9 +28,17 @@ python3 ./.trellis/scripts/task_progress.py status --task <task-name> --json
 Read the current task's `task.json` as the authoritative lifecycle record. Continue only when `taskStatus=completed` and `completedAt` is present. Progress text is recovery evidence and never substitutes for the task status.
 
 - `in_progress`: stop and return to Phase 3.4 `trellis-push`; finish-work must not manufacture completion.
-- `completed`: keep the active task pointer until archive succeeds, then continue below.
+- `completed`: keep the active task pointer until archive succeeds, then apply the archive eligibility gate below before continuing.
 - Missing, corrupt, or any other status: fail closed and report the exact blocker.
 
+This skill decides only whether archive is allowed; it does not classify the normal task record into commit recovery versus push recovery. Progress text is diagnostic only.
+
+- **Validated auto-loop exception**: a healthy terminal or recent run has `pending_archive.tasks_awaiting_archive` containing the exact current task, its recorded local commits still validate, and current-task dirty is only `<task-dir>/task.json` with the runner-owned progress/lifecycle change after that commit. This branch may continue without a task-record remote push. Extra task dirty, missing commit evidence, task mismatch, or contradictory runtime evidence blocks archive.
+- **Normal synchronized completion**: continue only when the current-task directory is clean, an upstream exists, and no commit in `@{u}..HEAD` modifies the current task.
+- **Any other normal or ambiguous state**: stop before release audit and enter `trellis-push` completed-task preflight. That owner decides whether task-record commit/push recovery is possible or evidence remains blocked; finish-work must not reproduce its recovery matrix.
+
+`trellis-finish-work` must not recommit or push the normal task record itself. The auto-loop exception authorizes only archival of the validated runner bookkeeping diff; it does not authorize unrelated dirty files or an automatic push of auto-loop commits.
+
 ### 2. Decision Audit
 
 Run:

package/enhancements/0.6/overrides/patches/skills/trellis-meta/managed-workflow-owners/active-task-lifecycle-content.md

@@ -12,14 +12,14 @@ If the platform or shell environment has no stable session identity, `task.py st
 
 `task.json.status` and the planning artifacts are authoritative. `task.json.progress` is narrow recovery evidence owned by `task_progress.py`; it must not override status, infer a workflow phase, restore a previous push mode, or resume Git orchestration.
 
-When no active pointer exists, `trellis-continue` may surface healthy `in_progress` or `completed` progress candidates, together with necessary invalid-candidate or scan diagnostics. The user must explicitly choose a task before the session is rebound; the recovery flow must never bind a session automatically. A completed candidate points to `trellis-finish-work` and archive; rework requires an explicit `completed -> in_progress` reopen.
+When no active pointer exists, `trellis-continue` may surface healthy `in_progress` or `completed` progress candidates, together with necessary invalid-candidate or scan diagnostics. The user must explicitly choose a task before the session is rebound; the recovery flow must never bind a session automatically. After explicit rebind, a completed candidate enters the `trellis-push` completed-task preflight, which owns publication recovery and the handoff to explicit `trellis-finish-work`. Rework requires an explicit `completed -> in_progress` reopen.
 
 The normal completion boundary is:
 
 ```text
-in_progress -> trellis-push final progress commit/push -> local completed
-completed -> explicit trellis-finish-work -> archive
+in_progress -> business push -> atomic final progress + completed -> task-record commit/push
+completed -> trellis-push completed-task preflight -> recovery or explicit trellis-finish-work -> archive
 completed -> explicit reopen -> in_progress
 ```
 
-Partial pushes, user `commit-only`, auto-loop internal commits, and progress-sync failures remain `in_progress`. `trellis-finish-work` archives an already completed task; it does not manufacture completion from progress text.
+Partial pushes, user `commit-only`, and normal helper failures remain `in_progress`. Auto-loop internal commits keep their separate local completion and `pending_archive` contract. `trellis-finish-work` independently enforces archive eligibility for direct invocation, but does not reproduce Push recovery classification or manufacture completion from progress text.

package/enhancements/0.6/overrides/patches/skills/trellis-meta/managed-workflow-owners/continue-recovery-content.md

@@ -7,6 +7,6 @@ Stable boundaries are:
 - With no active task pointer, surface each healthy candidate with its `taskStatus` and only the diagnostics needed to distinguish invalid progress or scan failures. Suggest an explicit rebind when appropriate; never bind a session automatically.
 - A `planning` task returns through `trellis-brainstorm` readiness, a refreshed `brief.md`, and the task-start review gate before implementation.
 - An `in_progress` task resumes from current artifacts and validated workflow evidence. Implement/check execution goes through `trellis-route`; saved progress must not infer a phase or restore Git behavior.
-- A `completed` task points only to explicit `trellis-finish-work` and archive. Rework requires an explicit reopen before implementation, and material scope changes require refreshed planning artifacts and Brief approval.
+- A `completed` task enters the `trellis-push` completed-task preflight. That owner either prepares publication recovery, points to explicit `trellis-finish-work`, or blocks on ambiguous evidence. Rework requires an explicit reopen before implementation, and material scope changes require refreshed planning artifacts and Brief approval.
 
 When changing recovery behavior, update `trellis-continue`, `task_progress.py`, the relevant workflow owner/state, and final-output tests together. Keep detailed progress schemas, command arguments, and error matrices in the owner skill/helper rather than duplicating them here.

package/enhancements/0.6/overrides/patches/skills/trellis-meta/managed-workflow-owners/continue-recovery-managed-baseline.md

@@ -13,6 +13,7 @@
 | `in_progress` | implementation done, no unified Check-All run | Phase 2.2 (`trellis-route(target=check)` → `trellis-check-all`) |
 <!-- END skill-garden patch trellis-meta-managed-continue-check-route v0.6 -->
 | `in_progress` | check passed | Phase 3.3 (spec update) → 3.4 (commit) |
-| `completed` | task is still in active tree | Phase 3.5 (run `/trellis:finish-work` to archive) |
+| `completed` | normal task-record commit/push pending | Phase 3.4 (`trellis-push` recovery) |
+| `completed` | normal task record synchronized or validated auto-loop `pending_archive` | Phase 3.5 (run `/trellis:finish-work` to archive) |
 
 When you add a custom status (e.g. `in-review`), add a `[workflow-state:in-review]` block in `.trellis/workflow.md` for the per-turn breadcrumb AND extend this route table — usually by editing the `/trellis:continue` command file (`.{platform}/commands/trellis/continue.md` or equivalent) to add a row that decides where to resume from. Without the route entry, `/trellis:continue` will fall through to a default branch and the user will not land on the step you intended.

package/enhancements/0.6/overrides/patches/skills/trellis-meta/managed-workflow-owners/lifecycle-modification-content.md

@@ -2,7 +2,7 @@
 
 1. Confirm the current task and inspect `task.json`, planning artifacts, saved progress, and the current workflow state.
 2. Identify the exact lifecycle writer and owner. Do not treat `task.py`, progress text, a state block, and an owner skill as interchangeable sources of truth.
-3. Preserve the stable sequence: Brief review before planning activation; final progress synchronization before local completion; explicit finish-work after completion; explicit reopen before rework.
+3. Preserve the stable sequence: Brief review before planning activation; normal final progress and completion written atomically before the task-record commit/push; completed tasks routed through the Push-owned publication preflight; finish-work limited to archive eligibility and bookkeeping; explicit reopen before rework.
 4. For project-local behavior, edit the narrow local owner. For Flower/Skill-Garden-managed behavior, change the canonical Patch/skill/helper source and then synchronize snapshot, compiled targets, and dogfood.
 5. Update every affected caller, guard, recovery path, conflict assertion, and final-output test. A status transition is incomplete if another entry can bypass or contradict it.
 6. Re-run the relevant task lifecycle, Patch conflict, compiled-target, and idempotency checks before relying on the new behavior.

package/enhancements/0.6/overrides/patches/workflow/runtime-contract-reference/completed-content.md

@@ -1,10 +1,9 @@
 <!-- Per-turn breadcrumb: shown while status='completed'.
-     Normal trellis-push has completed all business pushes, synchronized final
-     task progress, and then activated completed locally. The task remains active until an explicit
-     trellis-finish-work archive succeeds. -->
+     The task remains active until the Push-owned completed preflight resolves
+     publication recovery or explicit trellis-finish-work archive succeeds. -->
 
 [workflow-state:completed]
-Business push and task progress are complete. Do not resume implementation, Update-Spec, or trellis-push automatically.
-Run `/trellis:finish-work` only when explicitly requested; it verifies the completed record and archives the task without rewriting completion metadata.
+Business work and final task progress are complete, but `status=completed` alone does not prove that a normal task-record commit was pushed. Do not resume implementation or Update-Spec automatically.
+Enter the `trellis-push` completed-task preflight for the single next hop. It either prepares publication recovery, points to explicit `/trellis:finish-work`, or blocks on ambiguous evidence; this state does not inspect Git or auto-loop details itself.
 For rework, obtain an explicit user decision and run `task_progress.py reopen --task <task-name> --json` before returning to `in_progress`. Material scope changes still require refreshed planning artifacts and Brief approval.
 [/workflow-state:completed]

package/enhancements/0.6/overrides/patches/workflow/runtime-contract-reference/customizing-trellis-content.md

@@ -18,7 +18,7 @@ All tag blocks live in the `## Phase Index` section above, immediately after eac
 | Codex inline Phase 1 | `[workflow-state:planning-inline]` |
 | Phase 2 + Phase 3.2–3.4 (implementation + check + wrap-up) | `[workflow-state:in_progress]` (after Phase 2 summary) |
 | Codex inline Phase 2 + Phase 3.2–3.4 | `[workflow-state:in_progress-inline]` |
-| After successful task-progress push, before explicit archive | `[workflow-state:completed]` (observable active lifecycle state) |
+| After completion write, before Push-owned recovery preflight or archive | `[workflow-state:completed]` (observable active lifecycle state) |
 
 ### Changing the per-turn prompt text
 

package/enhancements/MANIFEST.json

@@ -1,7 +1,7 @@
 {
-  "syncedAt": "2026-08-12T01:19:49.853Z",
+  "syncedAt": "2026-08-12T04:29:06.144Z",
   "syncedFrom": "vendor/skill-garden",
-  "sourceCommit": "a44be043f3e00a74a430bfbaf17ca3ad0249a7a4",
+  "sourceCommit": "51d880f77b9caa0cf5602ecf889903b7adf71b23",
   "common": {
     "codexSkills": [
       "aliyun-ops",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "flower-trellis",
-  "version": "0.6.1-beta.0",
+  "version": "0.6.1-beta.1",
   "description": "一键安装/升级 Trellis 并自动融合 skill-garden 强化包(默认 Claude + agents)",
   "type": "module",
   "bin": {
@@ -70,9 +70,9 @@
     "commit-and-tag-version": "^12.7.3"
   },
   "flowerReleaseNotes": {
-    "version": "0.6.1-beta.0",
+    "version": "0.6.1-beta.1",
     "source": "CHANGELOG.md",
-    "body": "### ✨ 新功能 Features\n\n* **trellis:** 升级上游至 0.6.14 ([556285b](https://github.com/SilentFlower/flower-trellis/commit/556285b68c5723e13f7d55f4c801022c82e3b011))\n\n\n### 🐛 修复 Bug Fixes\n\n* **telemetry:** 补全开发者身份回退 ([1f95dfe](https://github.com/SilentFlower/flower-trellis/commit/1f95dfea26ce8117e437d973369ad6140fa17843))\n\n\n### ♻️ 重构 Refactor\n\n* **flower:** 同步 Push 输出模板分层 ([b340825](https://github.com/SilentFlower/flower-trellis/commit/b340825036a782679e14f74f8064664966f0a1bf))",
+    "body": "### ✨ 新功能 Features\n\n* **flower:** 同步任务完成态与检查报告优化 ([bb364bc](https://github.com/SilentFlower/flower-trellis/commit/bb364bc6af341ec23368ab94b798e677cc9580bb))",
     "truncated": false
   },
   "optionalDependencies": {