@pennixrv/trellis 0.7.0-beta.50 → 0.7.0-beta.51

package/dist/migrations/manifests/0.7.0-beta.51.json

@@ -0,0 +1,9 @@
+{
+  "version": "0.7.0-beta.51",
+  "description": "最终方案复核先于封口，一次明确答复批准封口与推进",
+  "breaking": false,
+  "recommendMigrate": false,
+  "changelog": "规划流程先展示完整方案，再征询封口并批准推进或补充修改；原生 seal/approve/start 保留任务、版本与摘要门禁，同步继续、重规划和平台入口。",
+  "migrations": [],
+  "notes": "不新增任务状态或批准字段，不迁移历史任务。已有充分授权继续复用；用户修改的生成资产和第三方工作流仍遵守原生更新保护。"
+}

package/dist/templates/common/bundled-skills/trellis-meta/references/customize-local/change-task-lifecycle.md

@@ -25,7 +25,7 @@ Task lifecycle includes creation, start, context configuration, finish, archive,
 | Change task parsing/search | `.trellis/scripts/common/task_utils.py`. |
 | Change active task behavior | `.trellis/scripts/common/active_task.py`. |
 | Select context without starting | Native `task.py select`; preserve phase/branch and drain live Channel work first. |
-| Seal and record later approval of a material plan | Native `task.py plan seal/approve`; reserved `meta.planning`, owned by `common/task_planning.py`. |
+| Seal the displayed plan after final confirmation and record its implementation approval | Native `task.py plan seal/approve`; reserved `meta.planning`, owned by `common/task_planning.py`; an explicit combined approval needs no second confirmation. |
 
 ## lifecycle hooks
 

package/dist/templates/common/bundled-skills/trellis-meta/references/customize-local/change-workflow.md

@@ -50,9 +50,9 @@ If the user wants only one platform to avoid sub-agents, first confirm whether t
 | `status` | Artifact state | Resume at |
 | --- | --- | --- |
 | `planning` | `prd.md` missing | Phase 1.1 (load `trellis-brainstorm`) |
-| `planning` | lightweight task with `prd.md` complete | ask for start review, then run `task.py start` |
+| `planning` | lightweight task with `prd.md` complete | present final plan, ask to seal and approve proceeding or supplement/revise, then native seal/approve/start; reuse sufficient authorization |
 | `planning` | complex task missing `design.md` or `implement.md` | complete missing planning artifacts |
-| `planning` | complex task has `prd.md`, `design.md`, and `implement.md` | ask for start review, then run `task.py start` |
+| `planning` | complex task has `prd.md`, `design.md`, and `implement.md` | present final plan, ask to seal and approve proceeding or supplement/revise, then native seal/approve/start; reuse sufficient authorization |
 | `in_progress` | no implementation in conversation history | Phase 2.1 (`trellis-implement`) |
 | `in_progress` | implementation done, no `trellis-check` run | Phase 2.2 (`trellis-check`) |
 | `in_progress` | check passed | Phase 3.3 (spec update) → 3.4 (commit) |

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/task-system.md

@@ -44,7 +44,7 @@ The Trellis task system is stored entirely under `.trellis/tasks/` in the user p
 | `commit` / `pr_url` | Commit and PR information after completion. |
 | `meta` | Extension fields. |
 | `meta.execution_class` / `meta.delivery_mode` | Explicit task classification; planned/change-bearing start needs current material-plan approval. |
-| `meta.planning` | Reserved native material revision, seal, and later approval; use plan seal/approve, never generic metadata. |
+| `meta.planning` | Reserved native material revision, seal, and explicit approval of the displayed plan; use plan seal/approve, never generic metadata. |
 
 ## Parent / Child Task Trees
 
@@ -111,7 +111,7 @@ Rules:
 python3 ./.trellis/scripts/task.py create "<title>" --description "<one-line summary>" --slug <slug>
 python3 ./.trellis/scripts/task.py select <task>
 python3 ./.trellis/scripts/task.py plan seal <task>
-python3 ./.trellis/scripts/task.py plan approve <task> --revision <n> --basis "<actual later approval>"
+python3 ./.trellis/scripts/task.py plan approve <task> --revision <n> --basis "<actual approval of the displayed plan>"
 python3 ./.trellis/scripts/task.py start <task>
 python3 ./.trellis/scripts/task.py current --source
 python3 ./.trellis/scripts/task.py add-context <task> implement <file> <reason>

package/dist/templates/common/commands/continue.md

@@ -56,7 +56,7 @@ Run only when the phase or routing rule is missing; otherwise reuse it.
 - `status=in_progress` + a material unresolved decision → record the reason and run `task.py replan <task> "<reason>"`; do not ask a native question during implementation.
 - `status=planning` + `prd.md` only → decide whether the task is lightweight or complex. Lightweight can move to **1.4** review; complex returns to **1.1** to add `design.md` + `implement.md`.
 - `status=planning` + complex artifacts complete + sub-agent jsonl not curated (empty, or only a legacy `_example` placeholder row) → **1.3**
-- `status=planning` + required artifacts complete + required jsonl curated or inline mode → for change-bearing work, run the Planning Seal closure pass, then **1.4**; require later explicit implementation approval for the current sealed revision and use native plan seal/approve/start. `analysis_only` work completes its evidence and archives without this path. A replan invalidates change-bearing approval; minor progress edits do not.
+- `status=planning` + required artifacts complete + required jsonl curated or inline mode → for change-bearing work, run the Planning Seal closure pass without sealing, present the final plan, then ask through `pennix-decision-grill` whether to seal and approve proceeding or supplement/revise. Explicit combined approval authorizes native seal/approve/start for that same plan at **1.4**; reuse existing sufficient authorization without asking again. Feedback stays in planning; material changes require renewed final review. `analysis_only` work completes its evidence and archives without this path. A replan invalidates change-bearing approval; keep minor progress edits outside frozen plan documents.
 - `status=in_progress` + implementation not started → **2.1**
 - `status=in_progress` + implementation done, not yet checked → **2.2**
 - `status=in_progress` + check passed → **3.3** (spec update) → **3.4** (commit)

package/dist/templates/common/commands/start.md

@@ -45,7 +45,7 @@ From Step 1 you know the current task and status. Check the task directory:
 - **Active task with `task.json.meta.delivery_mode = "analysis_only"`** → keep `planning`, complete the PRD's bounded evidence work, then verify the no-change boundary, commit task artifacts, and archive directly. Do not run `task.py start`; any protected-target change needs a separate change-bearing task.
 - **Active task status `planning` + no `prd.md`** → Phase 1.1. Load the `trellis-brainstorm` skill.
 - **Active task status `planning` + `prd.md` exists** → stay in Phase 1. Lightweight tasks can be PRD-only; complex tasks need `design.md` + `implement.md`. Load the relevant Phase 1 step detail before `task.py start`.
-- **Existing task selected by explicit intent but not bound** → use native `task.py select` for context only. Drain already dispatched Channel units before a real task switch. Planned/change-bearing start requires native plan seal and matching later approval for this task's current material revision; selecting or recovering context does not approve implementation.
+- **Existing task selected by explicit intent but not bound** → use native `task.py select` for context only. Drain already dispatched Channel units before a real task switch. Planned/change-bearing work presents the final plan and asks whether to seal and approve proceeding or supplement/revise before native seal/approve/start; reuse an existing sufficient authorization. Selecting or recovering context does not approve implementation.
 - **Active task status `in_progress`** → Phase 2 step 2.1. Load the step detail:
   ```bash
   {{PYTHON_CMD}} ./.trellis/scripts/get_context.py --mode phase --step 2.1 --platform {{CLI_FLAG}}

package/dist/templates/common/skills/brainstorm.md

@@ -2,7 +2,7 @@
 
 ## Non-Negotiable Planning Contract
 
-A request to build, implement, fix, refactor, or "go ahead" is not approval to leave planning. Task-creation consent is also not implementation approval.
+An initial request to build, implement, fix, or refactor is not approval to leave planning. Task-creation consent is also not implementation approval. An explicit response approving the displayed final plan may authorize sealing and implementation together.
 
 For every non-trivial task, the user must respond at least once after the initial request before implementation begins. If no clarification is needed, that response must approve the final planning summary described below.
 
@@ -85,7 +85,7 @@ Use a concise title from the user's request. Both the title and `--description`
 5. If the user requests independent subnode evidence, first freeze the dispatch plan in the task: question, evidence-unit mapping and grouping rationale, brief scope/stop conditions/destinations, concurrency and FIFO refill/acceptance method. Obtain the user's explicit approval of that frozen plan before any spawn/send. This approval covers only the listed evidence dispatch; material changes to units, scope, method, owner, risk, or acceptance require reapproval. Main-session evidence work may continue while dispatch approval is pending.
 6. When a needed answer returns, persist it and the affected dependencies, recheck evidence, and continue the same task. Before substantial evidence work, save the current decision, known answers, missing facts, return point and stop condition. Use bounded local/web evidence or explicitly approved independent subnodes; they establish facts, not user decisions. An empty ready frontier can mean missing evidence, not planning closure. Do not create a second lifecycle for the same decision chain.
 7. For `analysis_only`, record and verify the declared evidence and no-change boundary in planning; do not require `design.md`, `implement.md`, a Planning Seal, implementation approval, or `task.py start` merely because the research is complex.
-8. For change-bearing work, resolve material decisions, create/update complex-task artifacts, run the requirement convergence and PRD passes, then close and present the Planning Seal. Stop before implementation. Only a later explicit approval for this task's current sealed revision authorizes native plan approval and `task.py start`. Initial requests, parent-task approvals, and design answers do not qualify. Material changes require `task.py replan` and approval of its newly sealed revision; progress and wording edits do not.
+8. For change-bearing work, resolve material decisions, create/update complex-task artifacts, and run the requirement convergence and PRD passes plus the Planning Seal closure pass without invoking seal. Present the final plan, then use the Final Plan Review below. Only explicit approval of this displayed plan authorizes native seal/approve/start. Initial requests, parent-task approvals, and ordinary design answers do not qualify. Material changes return to final review; use `task.py replan` only when already in progress. Keep progress and non-material corrections outside byte-frozen plan documents.
 
 When changing the active task only for planning, use native `task.py select`,
 not start. `create --no-start` intentionally preserves the old pointer. Follow
@@ -166,10 +166,18 @@ Before final review, verify all of the following:
 
 For `analysis_only`, keep the task PRD bounded to evidence and the protected-target no-change boundary; it may omit `design.md` and `implement.md` and does not need an implementation review or approval. Change-bearing tasks retain their applicable evidence, convergence, final review, and fresh implementation approval gates.
 
-The final planning summary must show Goal, In Scope, Out of Scope, Acceptance Criteria, Key Decisions, relevant Risks or Deferred Items, and artifact status.
+The final planning summary must show Goal, In Scope, Out of Scope, Acceptance Criteria, Key Decisions, relevant Risks or Deferred Items, artifact status, actual targets/owners, validation, release/install impact, rollback, and completion boundary.
 
 For change-bearing work, the Planning Seal closure pass reconciles task artifacts, targets, branches, dependencies, release, validation, rollback, dynamic facts, and material decisions before implementation; unresolved implementation ambiguity invalidates the seal. This closure pass is not an eligibility or completion gate for `analysis_only` evidence work.
 
+## Final Plan Review
+
+For planned change-bearing work, present the final plan before invoking `plan seal`, then use `pennix-decision-grill` under the host interaction contract to ask whether to **seal and approve proceeding** or **supplement/revise the plan**. Explicit equivalent free text qualifies; no fixed phrase or button is required. Completed design questions or an empty decision frontier do not replace this whole-plan review.
+
+Combined approval authorizes only this task's displayed plan: run native `plan seal`, use its returned revision for `plan approve` with the actual non-sensitive reply as basis, then `task.py start`. Do not ask for the same implementation approval again. Feedback keeps the task in planning until the revised plan is presented and explicitly confirmed. A seal-only request permits only sealing. An empty/cancelled response or a recommended option is not approval.
+
+If the plan changes materially after presentation, return to final review before sealing or implementing. If a command fails, inspect the receipt and current state; do not blindly reseal a successfully sealed plan. Resume an existing sufficient authorization without another confirmation. Direct small work and `analysis_only` retain their existing paths.
+
 ## Artifact Rules
 
 `prd.md` records requirements and acceptance:
@@ -223,6 +231,6 @@ Before declaring change-bearing planning ready:
 - Repository-answerable questions have been answered; blocking implementation questions are resolved.
 - Complex change-bearing tasks have `design.md` and `implement.md`; sub-agent-dispatch implementation tasks have curated manifests.
 - The Planning Seal and final summary cover the implementation target, validation, and rollback.
-- The user subsequently approved this task's current sealed plan.
+- The final plan was presented before sealing and explicitly approved for this task; its matching native seal/approval gates must pass before start.
 
 For `analysis_only`, verify the declared evidence deliverable and protected-target no-change boundary, then proceed to complete the research in planning without an implementation summary approval. Do not start change-bearing implementation merely because the user originally requested it.

package/dist/templates/copilot/prompts/brainstorm.prompt.md

@@ -6,7 +6,7 @@ description: "Guide requirements discovery for a Trellis task after task-creatio
 
 ## Non-Negotiable Planning Contract
 
-A request to build, implement, fix, refactor, or "go ahead" is not approval to leave planning. Task-creation consent is also not implementation approval.
+An initial request to build, implement, fix, or refactor is not approval to leave planning. Task-creation consent is also not implementation approval. An explicit response approving the displayed final plan may authorize sealing and implementation together.
 
 For every non-trivial task, the user must respond at least once after the initial request before implementation begins. If no clarification is needed, that response must approve the final planning summary described below.
 
@@ -64,7 +64,7 @@ Use a concise title from the user's request. Both the title and `--description`
 5. If the user requests independent subnode evidence, first freeze the dispatch plan in the task: question, evidence-unit mapping and grouping rationale, brief scope/stop conditions/destinations, concurrency and FIFO refill/acceptance method. Obtain the user's explicit approval of that frozen plan before any spawn/send. This approval covers only the listed evidence dispatch; material changes to units, scope, method, owner, risk, or acceptance require reapproval. Main-session evidence work may continue while dispatch approval is pending.
 6. When a needed answer returns, persist it, recheck evidence, and continue the same task.
 7. For `analysis_only`, record and verify the declared evidence and no-change boundary in planning; do not require a Planning Seal, implementation approval, or `task.py start` merely because the research is complex.
-8. For change-bearing work, resolve material decisions, create/update complex-task artifacts, run the requirement convergence and PRD passes, then close and present the Planning Seal. Stop before implementation. Only later explicit approval of this task's current sealed revision authorizes native plan approval and `task.py start`; material changes require `task.py replan` and approval of its newly sealed revision.
+8. For change-bearing work, resolve material decisions, complete artifacts, run the requirement convergence and PRD passes without sealing, and present the final plan including targets/owners, acceptance, risks, validation, release/install, rollback and completion boundary. Then use `pennix-decision-grill` under the host interaction contract to ask whether to seal and approve proceeding or supplement/revise. Explicit combined approval of this same plan authorizes native `plan seal`, `plan approve` using its actual revision and reply, then `task.py start`; do not repeat the same approval. Feedback keeps planning; seal-only permits no approve/start. Equivalent explicit free text qualifies; empty/cancelled replies and recommended options do not. Material changes require renewed final review, using `task.py replan` only when already in progress. Inspect failed command receipts before continuing, do not blindly reseal, and reuse existing sufficient authorization on resume.
 
 Do not invent a project-specific product/spec hierarchy. If the repository already has product, domain, or spec docs, use them. If it does not, proceed with the evidence that exists.
 
@@ -155,7 +155,7 @@ Before declaring change-bearing planning ready:
 - Repository-answerable questions have been answered; blocking implementation questions are resolved.
 - Complex change-bearing tasks have `design.md` and `implement.md`; sub-agent-dispatch implementation tasks have curated manifests.
 - The Planning Seal and final summary cover the implementation target, validation, and rollback.
-- The user subsequently approved this task's current sealed plan.
+- The final plan was presented before sealing and explicitly approved for this task; its matching native seal/approval gates must pass before start.
 
 For `analysis_only`, verify the declared evidence deliverable and protected-target no-change boundary, then proceed to complete the research in planning without an implementation summary approval.
 

package/dist/templates/trellis/scripts/common/task_planning.py

@@ -134,4 +134,4 @@ def require_start_approval(data: dict[str, Any], task_dir: Path) -> None:
     if execution == "planned" and delivery == "change_bearing":
         record = _require_seal(data, task_dir)
         if type(record.get("approved_revision")) is not int or record.get("approved_revision") != record["revision"] or not record.get("approval_basis"):
-            raise PlanningError("current sealed plan has no matching later implementation approval; use task.py plan approve only after the user's approval")
+            raise PlanningError("current sealed plan has no matching implementation approval; use task.py plan approve only after the user explicitly approves the displayed plan")

package/dist/templates/trellis/scripts/task.py

@@ -1047,11 +1047,11 @@ def main() -> int:
     p_select = subparsers.add_parser("select", help="Select a task without changing its phase")
     p_select.add_argument("dir", help="Existing active task directory")
 
-    p_plan = subparsers.add_parser("plan", help="Seal or record later approval of a material plan")
+    p_plan = subparsers.add_parser("plan", help="Seal a reviewed material plan or record its explicit approval")
     plan_sub = p_plan.add_subparsers(dest="plan_command", required=True)
     p_seal = plan_sub.add_parser("seal", help="Seal the current material plan revision")
     p_seal.add_argument("dir", help="Planning task directory")
-    p_approve = plan_sub.add_parser("approve", help="Record actual later user approval")
+    p_approve = plan_sub.add_parser("approve", help="Record actual user approval of the displayed plan")
     p_approve.add_argument("dir", help="Planning task directory")
     p_approve.add_argument("--revision", type=int, required=True)
     p_approve.add_argument("--basis", required=True, help="Short non-sensitive basis for real approval")

package/dist/templates/trellis/workflow.md

@@ -22,11 +22,13 @@
 
 除边界清晰的研究外，使用 `pennix-decision-grill` 筛选涉及用户实质取舍的选择；一个实质选择即可触发。它负责渐进提问方法，不负责任务生命周期。先处理依赖已满足且有证据支撑的选择，再处理影响和优先级；一次询问一至三个相互独立且连贯的决策，回答后重新评估。不要询问可直接查明的事实或已经确定的实现细节。在执行有界本地/网络证据工作或明确批准独立子节点前保存决策检查点。可执行前沿为空可能表示缺少证据，不表示方案已封口。
 
-对于 planned/change-bearing 工作，先收敛决策和必要任务资产，运行原生 `task.py plan seal <task>`，展示实质方案并停在实施前。只有之后用户明确批准**当前任务当前封口版本**，才可运行 `task.py plan approve <task> --revision <n> --basis "<简短且不含敏感信息的实际批准依据>"`，然后运行 `task.py start`。最初的交付请求、父任务批准和设计答复都不构成实施批准。`--allow-empty-context` 只覆盖上下文清单，不覆盖批准门禁。原生记录负责结构约束，对话真实性仍由 Agent 负责。
+对于 planned/change-bearing 工作，先收敛决策和必要任务资产，展示最终方案的目标、范围、修改目标与负责组件、关键决定、验收与验证、风险、发布/安装、回退及完成点，再按 `pennix-decision-grill` 的宿主交互合同征询“封口并批准推进”或“补充／修改方案”。明确合并授权后，才依次运行原生 `task.py plan seal <task>`、使用实际 revision 的 `task.py plan approve <task> --revision <n> --basis "<简短且不含敏感信息的实际批准依据>"`、`task.py start`。授权只覆盖同一任务刚展示的方案，不重复索取同一实施批准。最初的交付请求、父任务批准和普通设计答复都不构成实施批准。`--allow-empty-context` 只覆盖上下文清单，不覆盖批准门禁。原生记录负责结构约束，对话真实性仍由 Agent 负责。
 
-实质范围、owner、风险、公开行为或验收变化必须运行 `task.py replan`，重新封口、展示并取得新版本批准。对已封口的 planning 任务重新封口会产生新的实质版本。措辞、格式、进度和执行证据不会自动使封口失效。通用 create/set-meta 不能预填保留的 `meta.planning` 记录。
+补充意见保持 planning，更新方案后重新展示确认；用户明确只同意封口时仅 seal，不 approve/start。明确表达相同意图的自由文本有效，不要求固定口令；空回执、取消和推荐项不算批准。seal/approve/start 失败先核对原始回执及实际状态，不盲目重做已成功的 seal。已有充分且范围一致的授权在普通继续或恢复时复用。
 
-用户明确要求向 `in_progress` 任务增加内容时，只有该内容服务于同一任务、保持实际 owner 和目标不变、规模小、可逆且风险低，并且实质上不改变已封口的范围、owner、风险、公开行为、数据完整性、凭据、部署/发布路径或验收，才可在当前阶段继续。将请求、分类、owner、验收和验证写入未封口执行记录；该请求只授权这一项明确增加的内容。任何条件不满足或不清楚时，保留当前结论，记录 `decision-needed`，使用原生 `task.py replan`，走重新封口和后续批准路径。
+实质范围、owner、风险、公开行为、部署路径或验收变化必须重新规划；in_progress 任务使用原生 `task.py replan`，planning 任务直接更新材料。重新展示方案、取得明确确认后再 seal/approve/start；旧批准不覆盖新方案。对已封口的 planning 任务重新封口会产生新的实质版本。封口文档按字节摘要冻结，进度和非实质修正写入未封口执行记录。通用 create/set-meta 不能预填保留的 `meta.planning` 记录。
+
+用户明确要求向 `in_progress` 任务增加内容时，只有该内容服务于同一任务、保持实际 owner 和目标不变、规模小、可逆且风险低，并且实质上不改变已封口的范围、owner、风险、公开行为、数据完整性、凭据、部署/发布路径或验收，才可在当前阶段继续。将请求、分类、owner、验收和验证写入未封口执行记录；该请求只授权这一项明确增加的内容。任何条件不满足或不清楚时，保留当前结论，记录 `decision-needed`，使用原生 `task.py replan`，回到最终方案复核。
 
 使用原生 `task.py select <task>` 只选择上下文：它不改变阶段或分支，不触发 after_start Hook，也不授予实施权限。`create --no-start` 有意保留之前的指针。切换前保存旧检查点；存在活动 Channel 工作时，按 `trellis-channel` 的多目标流程暂停补充并排空已派发单元和预留，保留待处理单元及旧阶段。不要终止/重试或自动重启用户停止的任务。普通继续/压缩恢复保留检查点快速路径。
 
@@ -246,7 +248,7 @@ Phase 3: Finish  → verify, update spec, commit, and wrap up
 [workflow-state:planning]
 加载 `trellis-brainstorm`；保持 planning。
 如果 `task.json.meta.delivery_mode = "analysis_only"`，无论复杂度或跨 owner 范围如何，都完成有界证据工作；PRD 必须写明证据交付物和受保护目标不变边界。不要运行 Planning Seal 或等待实施批准。涉及受保护目标的建议必须另建 change-bearing 任务。
-对于 `analysis_only`，无论复杂度或跨 owner 范围如何，都完成有界证据工作；PRD 必须写明证据交付物和受保护目标不变边界。不要运行 Planning Seal 或等待实施批准。对于 change-bearing 工作，轻量任务可以使用 `prd.md`；复杂任务在实施审查前需要 `design.md`、`implement.md` 和 Planning Seal。研究建议和开放的产品选择可以记录，但不要将其封口为实施决策。持久化定义请求所需的答复，并继续同一规划循环。
+对于 change-bearing 工作，轻量任务可以使用 `prd.md`；复杂任务在最终复核前需要 `design.md` 和 `implement.md`。先展示方案，再征询“封口并批准推进”或“补充／修改方案”；明确合并授权后才原生 seal/approve/start，同一方案不重复确认。研究建议和开放的产品选择可以记录，但不要将其封口为实施决策。持久化定义请求所需的答复，并继续同一规划循环。
 多交付物范围：考虑父任务和可独立验证的子任务；依赖必须写入子任务资产，不能从树结构位置推断。
 子代理模式：在 start 前维护 `implement.jsonl` 和 `check.jsonl` 作为 spec/研究清单。
 planned/change-bearing start 需要原生 plan seal，以及对当前任务当前实质版本的匹配批准。选择上下文不构成批准。
@@ -259,7 +261,7 @@ planned/change-bearing start 需要原生 plan seal，以及对当前任务当
 [workflow-state:planning-inline]
 加载 `trellis-brainstorm`；保持 planning。
 如果 `task.json.meta.delivery_mode = "analysis_only"`，无论复杂度或跨 owner 范围如何，都完成有界证据工作；PRD 必须写明证据交付物和受保护目标不变边界。不要运行 Planning Seal 或等待实施批准。涉及受保护目标的建议必须另建 change-bearing 任务。
-对于 `analysis_only`，无论复杂度或跨 owner 范围如何，都完成有界证据工作；PRD 必须写明证据交付物和受保护目标不变边界。不要运行 Planning Seal 或等待实施批准。对于 change-bearing 工作，轻量任务可以使用 `prd.md`；复杂任务在实施审查前需要 `design.md`、`implement.md` 和 Planning Seal。研究建议和开放的产品选择可以记录，但不要将其封口为实施决策。持久化定义请求所需的答复，并继续同一规划循环。
+对于 change-bearing 工作，轻量任务可以使用 `prd.md`；复杂任务在最终复核前需要 `design.md` 和 `implement.md`。先展示方案，再征询“封口并批准推进”或“补充／修改方案”；明确合并授权后才原生 seal/approve/start，同一方案不重复确认。研究建议和开放的产品选择可以记录，但不要将其封口为实施决策。持久化定义请求所需的答复，并继续同一规划循环。
 多交付物范围：考虑父任务和可独立验证的子任务；依赖必须写入子任务资产，不能从树结构位置推断。
 Inline 模式跳过 JSONL 整理；阶段二通过 `trellis-before-dev` 读取任务资产和 spec。
 planned/change-bearing 任务开始前需要原生 plan seal，以及对当前任务当前实质版本的匹配批准。选择上下文不构成批准。
@@ -278,6 +280,7 @@ planned/change-bearing 任务开始前需要原生 plan seal，以及对当前
 子代理派发协议适用于所有平台和所有子代理，包括使用原生 Codex `SubagentStart` 注入上下文并以子代理侧读取为后备的模式、Gemini/Qoder/Copilot/Reasonix/Trae/Grok/Kimi Code/DeepSeek Harness、由 Hook 支持的 ZCode/Snow 以及 `trellis-research`：每个派发提示都必须先写 `Active task: <task path from task.py current>`，再写角色指令。Grok Build 使用 `spawn_subagent`，并将 `subagent_type` 设为 Trellis Agent 名称（例如 `trellis-implement`）。Kimi Code 派发内置 `coder` / `explore` 子代理，并提供对应的 `.kimi-code/skills/trellis-<role>/SKILL.md` 指令。DeepSeek Harness 要求子代理恰好加载一次对应的 `.dsh/skills/trellis-agent-<role>/SKILL.md`，再按能力选择同步路径。如果可选伴随插件提供 `trellis_wait`，使用默认可继续的后台模式派发 `subagent`，继续独立工作；依赖门即将满足时，对每个依赖子代理 ID 调用一次 `trellis_wait`，每次调用都要等到 DSH 排入该子代理的原生结算通知后才返回。没有 `trellis_wait` 时，从一开始就为每个子代理设置 `run_in_background: false`，避免依赖门越过它。不得用 shell sleep、轮询循环、`job_output`、重复 `list_agents` 或其他长命令模拟等待，也不得让后台子代理脱离事件驱动的等待路径。
 
 [workflow-state:in_progress]
+实质重规划后先完善并展示方案，征询封口并批准推进或补充意见，明确确认后才 seal/approve/start；已有充分授权不重复询问。
 满足上述 in_progress 条件、且由用户明确要求的有界增补，留在当前阶段，并记录到未封口执行记录。出现实质未决选择时，立即解释影响和建议，停止依赖该选择的动作并记录 `decision-needed`。运行原生 `task.py replan <task> "<reason>"` 回到规划，再使用阻塞式提问工具并重新封口/批准新的实质版本。不要延后该选择，也不要手动修改任务状态。
 `trellis-implement` / `trellis-research` 表示通过平台子代理机制派发的角色，不是主会话自行加载的 Skill（Claude Code 使用 Task/Agent 工具，不使用 Skill 工具）。`trellis-update-spec` 是 Skill。`trellis-check` 同时存在于两种入口；代码变更后验证时优先使用 Agent/角色入口。
 DeepSeek Harness 的角色指令以互不冲突的 `trellis-agent-implement` / `trellis-agent-check` / `trellis-agent-research` Skill 分发到 `.dsh/skills/`。主会话不得自行加载；要求子代理恰好加载一次对应角色 Skill。提供 `trellis_wait` 时，使用默认后台模式，继续独立工作，然后对每个依赖子代理 ID 调用一次 `trellis_wait`，消费原生结算通知后才进入依赖门。未提供时，从一开始就为每个子代理设置 `run_in_background: false`。不得轮询、sleep 或启动没有事件驱动等待路径的后台子代理。
@@ -291,6 +294,7 @@ DeepSeek Harness 的角色指令以互不冲突的 `trellis-agent-implement` / `
      [workflow-state:in_progress]；主会话直接编辑代码，不派发子代理。 -->
 
 [workflow-state:in_progress-inline]
+实质重规划后先完善并展示方案，征询封口并批准推进或补充意见，明确确认后才 seal/approve/start；已有充分授权不重复询问。
 流程：`trellis-before-dev` → 编辑 → `trellis-check` → 验证 → `trellis-update-spec` → 提交（阶段 3.4）→ `/trellis:finish-work`。
 满足上述 in_progress 条件、且由用户明确要求的有界增补，留在当前阶段，并记录到未封口执行记录。出现实质未决选择时，立即解释影响和建议，停止依赖该选择的动作并记录 `decision-needed`。运行原生 `task.py replan <task> "<reason>"` 回到规划，再使用阻塞式提问工具并重新封口/批准新的实质版本。不要延后该选择，也不要手动修改任务状态。
 Inline 模式不派发 implement/check 子代理。
@@ -403,7 +407,7 @@ brainstorm Skill 会引导你：
 - 让 `prd.md` 专注于需求和验收标准
 - 复杂任务在开始实施前生成 `design.md` 和 `implement.md`
 - 对阅读量大的工作拆成证据单元，并在继续前持久化每个单元的结论或恢复点
-- 在 change-bearing 实施审查或 `task.py start` 前，对任务资产运行 Planning Seal 收口检查，并锁定目标、分支、依赖、发布、验证、回滚、动态事实处理和实施决策；`analysis_only` 不使用此门禁
+- 在 change-bearing 最终方案复核前，对任务资产运行 Planning Seal 收口检查，核对目标、分支、依赖、发布、验证、回滚、动态事实处理和实施决策；检查不调用 seal，明确最终确认后才封口；`analysis_only` 不使用此门禁
 
 考虑拆分父子任务时：
 - 一个请求包含多个可独立验证的交付物时使用父任务。
@@ -505,7 +509,7 @@ python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" check "<path>" "<reas
 
 此步骤仅适用于 change-bearing 任务。符合条件的 analysis-only 任务保持 `planning`，完成证据工作后不运行 `task.py start`，直接进入阶段 3.3。
 
-完成 Planning Seal 收口检查、资产审查以及上文适用的原生 plan seal/approve 门禁后，将任务状态切换为 `in_progress`：
+完成 Planning Seal 收口检查并展示最终方案，取得“封口并批准推进”的明确授权后，原生 plan seal，再以实际 revision 记录 approve；门禁通过后将任务状态切换为 `in_progress`，不重复索取同一实施批准：
 
 ```bash
 python3 ./.trellis/scripts/task.py start <task-dir>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pennixrv/trellis",
-  "version": "0.7.0-beta.50",
+  "version": "0.7.0-beta.51",
   "description": "AI capabilities grow like ivy — Trellis provides the structure to guide them along a disciplined path",
   "type": "module",
   "main": "./dist/index.js",
@@ -34,7 +34,7 @@
     "inquirer": "^9.3.7",
     "undici": "^6.21.0",
     "zod": "^4.4.2",
-    "@pennixrv/trellis-core": "0.7.0-beta.50"
+    "@pennixrv/trellis-core": "0.7.0-beta.51"
   },
   "devDependencies": {
     "@eslint/js": "^9.18.0",