@harmonyos-arkts/d2h 0.1.26 → 0.1.27

package/skills/d2h-spec-generate/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: d2h-spec-generate
-description: Generate page-scoped Android-to-HarmonyOS spec.md files from migration Facts, `.migration/utg/page.json`, source code, existing HarmonyOS implementation, and selected versioned plan inputs. Use when pages, dialogs, sheets, or page modes need evidence-backed development specifications without copied UI artifacts. Scope, ordering, waves and batches come from the input plan; execution state is maintained by the caller.
+description: Generate page-scoped Android-to-HarmonyOS spec.md files from migration Facts, `.migration/utg/page.json`, source code, and existing HarmonyOS implementation. Use when pages, dialogs, sheets, or page modes need evidence-backed development specifications without copied UI artifacts. Milestones, waves and development scope are planned after generation.
 ---
 
 # Page Spec generation
 
-Generate one implementation-ready `spec.md` for every selected Android page, dialog, sheet, and behaviorally distinct page mode. The AI verifies evidence mapping and behavior by reading the actual migration workspace and source code. Page/Spec boundaries, dependencies, development order, waves and batches are supplied by the selected plan; return discrepancies instead of replanning.
+Generate one implementation-ready `spec.md` for every Android page, dialog, sheet, and behaviorally distinct page mode. The AI determines page boundaries, evidence mapping, dependencies and initial order from page.json, Facts and source. User-selected development scope, milestones and waves are handled after full generation.
 
 Do not invoke task-planning, graph-generation, migration, or page-validation scripts. Do not modify Android source, HarmonyOS source, `.migration/spec/`, `.migration/utg/`, `.migration/tasks/`, or the migration report.
 
@@ -20,29 +20,24 @@ Resolve these paths before writing:
 - `harmony_root`: `.migration/config.json.harmonyProject`, resolved relative to `migration_root` when not absolute, unless explicitly supplied.
 - `legacy_tasks_root`: optional `<migration_root>/.migration/tasks`; use existing briefs, core facts, source context, and acceptance files only as read-only evidence from an older flow.
 - `output_root`: default `<migration_root>/.migration/page-specs`.
-- `plan`: pages.json v2 and features.json absolute paths, selected revision/hash and explicit spec_ids; preserve their scope_refs/checks, page packages, round_id/batch_id and allowed implementation paths. Missing or changed inputs return needs-input/needs-revision.
-
-Use the public `d2h workflow contract generation` for input/output bindings. Consume artifacts, not the producer Skill or its private resources.
-
 Facts are the deterministic structured evidence baseline extracted from Android source. They support scope discovery, entity and interaction linkage, report initialization, and omission checks, but unresolved items and extraction gaps mean they are not substitutes for reading Android source and, where necessary, observing runtime behavior. Legacy Task artifacts are read-only indexes from the older flow. Existing HarmonyOS files and tests are implementation evidence, not proof that a behavior is complete.
 
 ## Output contract
 
-Each page unit contains only `spec.md`. The input `pages.json` and caller-owned `batch_report.json` live at the output root; this Skill writes page Specs and the generation binding only:
+Each page unit contains only `spec.md`. `pages.json` and the initial `batch_report.json` live at the output root:
 
 ```text
 .migration/page-specs/
 ├── pages.json
-├── batch_report.json  # caller-owned execution ledger, read-only
-├── generation.json   # generated content binding
-├── <plan.package-A>/
+├── batch_report.json
+├── page_0001_<name>-<id>/
 │   └── spec.md
-├── <plan.package-B>/
+├── page_0002_<name>-<id>/
 │   └── spec.md
 └── ...
 ```
 
-Use the stable package directories supplied by the plan. Re-running against unchanged evidence must preserve existing directory names and the selected order; evidence of incorrect boundaries or dependencies is returned as a proposed plan revision, not applied here.
+Preserve existing page identities and package directories when evidence is unchanged; return source-proven mismatches for reconciliation without resetting execution history.
 
 ## Workflow
 
@@ -55,21 +50,21 @@ Use the stable package directories supplied by the plan. Re-running against unch
 5. Read the current migration report to understand existing mappings and unresolved items, without treating report status as proof of implementation.
 6. Inspect HarmonyOS route registration, `.ets`/`.ts` components, shared state, resources, and tests to distinguish existing implementation from planned work.
 
-### 2. Verify planned page units with AI reasoning
+### 2. Determine page units with AI reasoning
 
 1. Start from `page.json.pages[]`, then join each page node to Facts surfaces, entries, controls, and interactions by stable ref, declared source, transition, and source behavior.
-2. Verify that independently reachable pages, dialogs, sheets, and behaviorally distinct add/edit or selection modes have explicit planned ownership when they have their own user-visible lifecycle or acceptance flow. Return missing or incorrect ownership as a revision request.
+2. Treat independently reachable pages, dialogs, sheets, and distinct add/edit or selection modes as separate units when they have their own lifecycle or acceptance flow.
 3. Prefer exact ref or normalized identity matches between `page.json.pages[].node_id` and Facts surfaces. Then use labels, `declared_at`, parent relations, navigation steps, source symbols, controls, and Android source behavior.
 4. Never assign behavior from name similarity alone. Record ambiguous mappings in the owning Spec under “未决项与平台差异”.
 5. `capture=false`, an empty `expected`, or a `skip_reason` does not remove a source-proven page. Use those fields as evidence limitations and verify the page through Facts and Android source.
-6. Do not create a fake page for background-only capabilities. Verify the planned ownership of startup, notification, widget, receiver, persistence, or other shared responsibilities and list downstream consumers; return missing ownership instead of assigning it here.
-7. A planned package may contain several independent Specs. Verify each selected member against its actual lifecycle and behavior ownership; do not merge identities or silently expand the selection.
+6. Do not create a fake page for background-only capabilities. Assign startup, notification, widget, receiver, persistence, or other shared responsibilities to the earliest real page that needs them and list downstream consumers.
+7. Split aggregate packages by actual page lifecycle and behavior ownership, keeping one complete Spec per page unit.
 
-### 3. Consume development order
+### 3. Determine initial page order
 
-Read scope, ownership, dependencies, order, rounds and page batches from the selected pages.json. Do not recalculate scores, change members, create groups, rename packages, or write another plan. Cite the planned order, dependencies and rationale in each Spec. Source-proven conflicts return proposed_plan_updates and evidence to the caller.
+Place evidence-backed prerequisites before consumers, then sort by `page_score = enablement × 9 + ordinary_reachability × 6 + shallowness × 5`, breaking ties by stable page_id. Each rating is 0–5: enablement measures shared correctness impact, ordinary_reachability measures accessibility in normal app state, and shallowness measures page-navigation depth. Record evidence and rationale for each rating; this initial order is a reference for subsequent planning.
 
-Generation may run in multiple writing passes to fit the available context, but those passes do not change development batches, budgets, spec_id/round_id/batch_id, or independent acceptance identities.
+Before writing Specs, create pages.json with `schema_version: d2h-page-plan/v1`. Each page has consecutive one-based order, page_id, kind, package (`page_NNNN_<name>-<id>`), page_path, spec_refs, req_refs, dependencies, page_score and decision_ledger entries for the three ratings with evidence. Every page.json node must be covered or have an explicit exclusion/unmatched reason. Keep existing task identities when resuming.
 
 ### 4. Verify source before writing
 
@@ -82,7 +77,7 @@ Generation may run in multiple writing passes to fit the available context, but
 
 ### 5. Write only `spec.md`
 
-Use these headings in every page Spec. For incremental members, keep this seven-section content and use [the detailed template](assets/spec-template.md) and [content requirements](references/spec-content.md) to bind each selected spec_id/check_id to its own complete behavior and acceptance block. F-xxx labels remain page-local behavior labels, not replacements for planned identities:
+Use these headings in every page Spec, preserving complete behavior, exception paths and acceptance assertions. F-xxx labels identify page-local behaviors:
 
 ```markdown
 # <页面名称> 迁移 Spec
@@ -99,7 +94,7 @@ Use these headings in every page Spec. For incremental members, keep this seven-
 
 - 顺序：<NNNN>
 - 前置依赖：<无或其他页面标识/共享能力>
-- 排序理由：<引用输入计划中的依赖、顺序和依据>
+- 排序理由：<引用页面依赖、初始顺序和依据>
 
 ## 页面功能
 
@@ -134,15 +129,21 @@ Use these headings in every page Spec. For incremental members, keep this seven-
 
 When a page has no independent interaction, write one display/reachability feature and acceptance sequence instead of leaving the feature sections empty.
 
-### 6. Review and record generated content
+### 6. Initialize the execution ledger
 
-After the selected Specs are complete, follow [the generation handoff](references/from-plan.md) to verify their source coverage and selected input hash, then use public `d2h workflow generation` to record generation.json for the explicit members. This records content identity, not semantic approval or runtime acceptance.
+After all page Specs exist, create the initial batch_report.json with the bundled renderer:
+
+```bash
+python scripts/build_batch_report.py \
+  --pages-plan <output_root>/pages.json \
+  --output-root <output_root>
+```
 
-Do not initialize or update batch_report.json, generate task state, or infer completion from existing HarmonyOS files or local test artifacts. The caller owns the sole execution ledger and its events. Return missing inputs, unresolved behavior, and proposed plan updates with concrete source evidence; do not reset history or fabricate ready/accepted status.
+The renderer requires pages.json v1 and one spec.md per package. Tasks start pending/not_run/not_run; do not infer completion from existing implementation or tests. Never rerun initialization over an existing ledger, reset history, or fabricate acceptance. Return input/Spec mismatches for reconciliation; milestone/wave planning and execution updates belong to the subsequent skills.
 
 ## Quality gates
 
-- Every selected source-proven page, dialog, sheet, and behaviorally distinct mode has exactly one `spec.md`, or its planned ownership is explicitly assigned to another Spec.
+- Every source-proven page, dialog, sheet, and behaviorally distinct mode has exactly one `spec.md`, or its ownership is explicitly assigned to another Spec.
 - Every distinct interaction has a unique `F-xxx`, and feature IDs match UI operation/acceptance sections one-to-one.
 - Each feature states a user action and observable result, not an implementation instruction.
 - Navigation, state changes, persistence, destructive confirmation, external intents, cancellation, dismissal, and error behavior remain explicit.
@@ -150,8 +151,8 @@ Do not initialize or update batch_report.json, generate task state, or infer com
 - Existing HarmonyOS code or tests never cause a feature to be marked complete without current build and executed test evidence.
 - Uncertainty remains explicit. Do not invent control names, outcomes, source mappings, runtime captures, or implementation status.
 - Each planned package directory contains exactly one file named `spec.md`.
-- `output_root` keeps caller-owned inputs and ledger, generation.json, derived reading views, and planned page directories; it contains no copied UI evidence, UI design, or invented validation artifact.
-- Every selected member agrees with its planned directory, scope and checks; supplied execution records are read-only. No task or summary state is written by this Skill.
+- `output_root` contains pages.json, batch_report.json and page directories; it contains no copied UI evidence, UI design, or invented validation artifact.
+- Every page has one matching task in batch_report.json; IDs, directories, Spec paths and task counts agree. Existing execution results and history are preserved.
 - Spec generation does not mark a task complete. Implementation, current build/test evidence and acceptance remain the caller’s separate execution gates.
 
 ## Result
@@ -164,6 +165,6 @@ Return:
 - unreachable pages, capture-disabled nodes, and pages with incomplete arrival rules in `page.json`;
 - ambiguous mappings and unmatched Facts;
 - unresolved selector steps;
-- the absolute generation.json path and caller-owned `batch_report.json` path when supplied;
-- the selected input versions, generated/updated/reused spec_ids, status and evidence-backed unresolved/requests/proposed_plan_updates;
+- the absolute `batch_report.json` path;
+- status and evidence-backed unresolved items or requests;
 - the absolute `output_root`.

package/skills/d2h-spec-plan/SKILL.md

@@ -1,33 +1,37 @@
 ---
 name: d2h-spec-plan
-description: 基于已确认功能范围、选定架构和分析证据规划增量 HarmonyOS Spec，组织里程碑、目标轮次及同页批次，评估依赖、成本与测试风险。用于首次规划、详细规格生成后的分组复核，以及新证据下的局部修订和事后评估；保留决策与版本记录，不负责用户选型、详细规格生成或运行时派发。
+description: 基于已确认功能范围、选定架构和已有页面规格规划里程碑与波次。用于首次排期、生成后绑定及后续局部修订；保留页面范围、规格和执行历史，不负责 Spec 划分、生成、开发或验收。
 ---
 
 # Spec 规划
 
-消费已确认的功能范围（features.json）、选定架构和分析结果，组织“里程碑 → 目标轮次 → 同页批次 → Spec”。本技能负责规划当前轮次的 Spec 范围、依赖、成本、验收和测试安排，或在新证据下修订受影响的计划。范围和架构选择、运行时派发仍由 d2h 主代理负责。
+消费已确认的功能范围、选定架构和已有分析，组织“里程碑 → 波次 → 已有页面任务”。本技能将已确认范围映射到已有任务，安排任务排序、交付目标、里程碑和波次；页面划分、依赖、初始顺序、Spec 内容及初始账本由规格生成流程负责，逐页实施和验收由页面开发流程负责。
 
-1. 里程碑（Milestone）: 由版本化功能计划定义的目标阶段，通常对应一个发布版本或主要功能集。
-2. 目标轮次（Target Round）: 在里程碑下的一轮可验证交付，定义本轮目标、范围和必要前置。
-3. 同页批次（Same-Page Batch）: 在同一目标轮次内，将适合共同实施和交付的同页 Spec 合理分组，复用上下文、代码及测试准备，明确分组依据和预算，保留各自验收身份。
-4. Spec 规划项: 可独立追踪、实现和验收的行为单元；规划时确定稳定身份、范围边界、依赖和验收目标，详细规格由生成能力展开。
+1. 里程碑（Milestone）: 用户确认范围内的阶段目标。
+2. 波次（Wave）: 里程碑内一组按计划顺序推进的完整页面任务，明确目标、必要前置和结束条件。
+3. 页面任务: 引用已有 pages.json 的 page_id、order、package 及执行账本任务 ID，不新建 spec_id 或拆分一个页面的开发闭环。
 
-保留 Spec 独立验收身份，详细规格生成后复核分组；具体粒度、分组与调整方法按需读取参考。
+## 开发范围与排序
+
+将用户已确认范围映射到已生成任务，仅把已选范围及获授权的必要前置纳入波次；其余任务明确排除，保留规格和账本，不参与本次完成判断。
+
+必要前置涉及未选或明确排除的独立功能，或同一 Spec 混合已选和未选功能时，返回具体范围冲突，由调用方处理，不自行扩大范围或整份派发。
+
+按用户目标、优先级和实际依赖确定任务排序，划分里程碑和波次；页面归属及生成时的顺序仅作参考。排序不得绕过前置，页面范围或依赖有误时返回调用方处理。
 
 ## 风险与测试安排
 
-逐 Spec 评估失败影响、共享范围、实现不确定性和下游依赖，明确测试需求、验证方式及时机；不新增专项测试时记录依据，低风险仍须核对验收目标。具体分级与安排按需读取参考，已有明确测试要求不得取消。
+记录波次成本、风险、外部条件及结束时需要核对的页面验收结果，不改变逐页构建、测试、提交和验收要求。页面未完成不能因波次收尾而跳过；阶段完成必须引用执行账本和当前证据。
 
 ## 交付与记录
 
-每次规划或复评交付正式计划及简短评审记录，关联输入来源和计划版本，说明主要划分、分组、风险及测试安排的依据。生成后复核即使维持原计划，也保留结论；修订时保留旧版本、稳定身份和变更原因。执行结果由主 Agent 记录，本技能引用实际证据复评，不维护执行账本。记录要求与事后评估方法按需读取参考。
+里程碑、波次、排序和纳入/排除任务统一保存到 `batch_report.json.planning`，由主 Agent 核对后原位写入；修订前将旧规划完整追加到 planning_history。开发与恢复只读取该账本，不维护独立的当前 plan.json。
 
-## 按需参考
+分析及评审保存在 `<migration_root>/.migration/spec-planning/analysis.md` 和 `planning-review.md`，调用方指定目录时沿用其路径。pages.json 和 spec.md 只读，规划更新不修改账本任务结果、证据或执行历史。交接账本绝对路径及 planning 的 revision/hash；在途任务先由主 Agent 处置，仅调序不使既有验收失效，范围变化另行复核。
 
-以下仅引用对应章节的规划规则；参考中尚未整理的生成、派发、执行账本和看板流程暂不纳入本次大纲。
+## 按需参考
 
-- 拆分 Spec、组织批次或生成详细规格后复核分组时，参考 [控制 Spec 粒度与重复分析](references/planning-method.md#控制-spec-粒度与重复分析)。保留独立交付与验收边界，不按控件或文件机械拆分。
-- 确定轮次目标、必要前置、延期去向、成本风险和验收条件时，参考 [每轮需要回答的问题](references/round-scope-assessment.md#每轮需要回答的问题)。超出已确认范围的调整建议交主 Agent 确认。
-- 规划多个 Spec 共用的状态与能力时，参考 [跨 Spec 共享状态](references/work-packets.md#跨-spec-共享状态)。明确生产者、消费者、初始化、生命周期和检查关系，沿用已选架构，不代替技术方案设计。
-- 评估 Spec 风险、决定是否新增测试及验证时机时，参考 [分层验证与定向修复](references/work-packets.md#分层验证与定向修复)。
-- 交付计划、记录复核或变更、事后评估时，参考 [规划交付与评审记录](references/planning-review.md)。
+- 正式规划时，参考 [规划工作](references/planning-method.md#规划工作)；写入计划时核对 [计划格式](references/plan-contract.md)。
+- 确定波次目标、前置及结束条件时，参考 [每轮需要回答的问题](references/round-scope-assessment.md#每轮需要回答的问题)。
+- 核对页面依赖和原验证要求时，参考 [共享状态与验证安排](references/work-packets.md)。
+- 交付计划、复核及变更时，参考 [规划交付与评审记录](references/planning-review.md)。

package/skills/d2h-spec-plan/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
-  display_name: "页面轮次与增量 Spec 规划"
-  short_description: "根据已确认的功能范围与架构，结合分析结果规划增量 Spec 和波次"
-  default_prompt: "Use $d2h-spec-plan to author or revise an incremental Spec plan from caller-confirmed feature scope and architecture plus existing analysis, preserving completed scope without starting development."
+  display_name: "里程碑与波次规划"
+  short_description: "根据已确认范围与已有页面任务规划里程碑和波次"
+  default_prompt: "Use $d2h-spec-plan to plan milestones and waves over existing page tasks, preserving their scope, identities, generation and development contracts while ordering execution by user goals and dependencies."

package/skills/d2h-spec-plan/references/plan-contract.md

@@ -1,13 +1,38 @@
 # 计划产物契约
 
-`pages.json` v2 是稳定的产物协议，不属于某个计划生产者。字段与兼容规则由公共工具维护：
+里程碑、波次、任务排序和本次开发范围保存在 `.migration/page-specs/batch_report.json` 的 planning 字段，作为执行与恢复时的唯一规划依据。tasks、summary、regression 及已有证据和历史保留；不另行维护当前 plan.json。
 
-```text
-d2h workflow contract plan
-d2h workflow contract scope
-d2h workflow validate --planning-only --plan <pages.json> --features <features.json>
+以下为账本新增字段示例，不是完整账本，不能据此覆盖已有文件：
+
+```json
+{
+  "planning": {
+    "schema_version": "d2h-milestone-plan/v1",
+    "revision": 1,
+    "phase": "bound",
+    "sha256": "<planning-content-sha256>",
+    "sources": [{"path": "/abs/features.json", "sha256": "<file-sha256>"}],
+    "milestones": [{"milestone_id": "usable", "goal": "基础路径可用", "rationale": "用户确认目标"}],
+    "excluded_tasks": [],
+    "waves": [{
+      "wave_id": "wave-1", "milestone_id": "usable", "goal": "首页及必要前置可用",
+      "task_ids": ["PAGE-0001"],
+      "prerequisites": ["账本任务声明的前置已满足"],
+      "exit_criteria": ["所引任务完成实现、构建及验收，并有当前证据"],
+      "rationale": "按用户目标和依赖安排执行顺序"
+    }]
+  },
+  "planning_history": []
+}
 ```
 
-本 Skill 输出轻量 Spec 条目、依赖、轮次/批次、已知工作包约束和验收概要；详细正文与生成绑定由独立生成能力维护。新计划开启 spec_generation_policy=required-v1。生成输入输出读取 d2h workflow contract generation。规划校验不要求页面目录或 spec.md 已存在，规划方法见 [planning-method.md](planning-method.md)。调用方负责派发、维护 batch_report.json 和生成报告；规划不创建执行状态。
+- planning 可在全量规格及账本生成后添加，不要求修改生成脚本。无该字段的已有账本按既有任务顺序执行；已确认选择开发范围或已有 planning 时，不得因 planning 缺失、无效或非 bound 而回退全量开发。生成前的功能草案只记入分析，不能伪造任务或账本。
+- milestones、waves 的 ID 各自唯一，wave.milestone_id 必须指向已声明里程碑。本次纳入任务在 waves[].task_ids 中恰好出现一次，必须存在于 tasks[]；未纳入任务在 excluded_tasks 记录 task_id 和 reason。两者不重叠，合计覆盖全部账本任务；混合已选/未选行为及前置授权冲突未解决时不能标为 bound。
+- 执行顺序由 milestones、所属 waves 及 task_ids 的数组顺序确定，任务前置必须先于消费者。任务 ID、生成时的 order、Spec 路径及目录不随排序改变；里程碑和波次不复制任务执行状态。
+- sources 保存已确认范围等输入的路径与字节 SHA-256。planning.sha256 只对 planning 去掉 sha256 后的内容计算：`sha256(json.dumps(content, sort_keys=True, ensure_ascii=False).encode('utf-8'))`；任务状态、证据及整个账本哈希不参与，避免每次执行使规划身份变化。
+- spec-plan 交付 planning 内容，由主 Agent 核对引用、范围、依赖及当前账本后原位写入；写入前重新读取并确认账本未被其他执行更新，发生变化先复核，不覆盖新历史。首次添加仅新增规划字段；修订先将旧 planning 完整追加到 planning_history，再增加 revision、计算新哈希并更新 planning，保留 tasks、证据和执行历史。无实质变化不增版；在途任务先交调用方处理，不能静默切换其执行版本。
+- worker 在 tasks[].history 的本次执行记录中保存 planning_ref：revision、sha256、milestone_id、wave_id。重新排期不能覆盖旧执行关联；仅调整排序不使既有验收失效，范围变化须复核，不能自动沿用旧验收。
+- summary 继续统计全量任务；本次、里程碑及波次进度从 planning 的成员与 tasks 的当前结果关联计算。未选任务保留状态，不标通过、不阻塞本次交付，本次范围完成不等于全量迁移完成。
+- 历史 plan.json 只作归档。迁移时核对实际任务和历史，再将完整规划写入账本；存在两处规划且不一致时返回冲突，不按文件更新时间猜测有效版本。开发和恢复读取账本 planning，不读取归档计划。
 
-结构校验通过不代表源码理解、授权范围、架构归属或实际行为已通过人工复核。只使用已给定输入，不根据产物缺失猜测执行状态或强制运行特定生产技能。
+analysis.md 与 planning-review.md 的来源、修订及评审规则见 [规划交付与评审记录](planning-review.md)。本模式由 AI 核对，不以增量 Spec v2 的 workflow validate --planning-only 冒充此账本关联已通过校验。

package/skills/d2h-spec-plan/references/planning-method.md

@@ -1,72 +1,22 @@
-# 增量范围、页面轮次与评估方法
-
-创建计划、收到详细 Spec 后复核分组，或因新依赖、范围/归拢变化修订语义时读取本参考。仅执行状态更新不重做规划。写入机器可读计划时读取 [plan-contract.md](plan-contract.md)。
-
-## 输入与证据
-
-- migration_root、Android/HarmonyOS 工程绝对路径；默认从 `.migration/config.json` 解析。
-- `.migration/feature-planning/features.json`：schema、revision 和输入文件内容哈希。
-- `.migration/spec/index.json`、Facts、unresolved、`.migration/utg/page.json`；缺失的源码行为仍需记录。无源码的用户新增需求可引用用户来源，缺失证据保持未决。
-- 仍有效的架构上下文与已有工程记录：核对调用方已确认的所有者、目录和风险；不擅自重新选方案。
-- 既有 pages.json、batch_report.json 和页面 spec.md；迁移报告和既有实现只提供线索，不能证明当前通过。
+# 里程碑与波次规划方法
 
 ## 规划工作
 
-1. 先核对调用方交接的已确认功能清单、范围和来源版本，再消费 `should_develop=true` 的稳定功能/范围项及来源映射，不把 P0/P1/P2、release_stage 当作用户范围选择。校验功能计划，读取当前阶段全部功能及用户顺序。功能事实来自只读清单；本技能仅记录清单所表达的范围变化，保留阶段、人工优先级和顺序，不静默修改。
-2. 核验页面、Dialog、Sheet、独立模式的正式入口和源码。页面作为归属索引；一页可包含多个稳定 spec_id，跨页增量指定唯一归属并保留引用。既有页面目录保持稳定；新目录用稳定 page_id 衍生，调整顺序不改路径。规划只登记稳定页面归属，不创建目录或 spec.md。功能与页面多对多；以 scope_id 关联行为、真实入口、源码和非页面副作用，未决映射不得猜测。
-3. 从核心用户路径拆出可独立验收增量，例如基本登录与其他登录方式分开。每个轻量 Spec 条目写 scope、排除/延后归属、验收概要与稳定 check_id、源证据、实现位置和已知共享约束，不展开全部操作及异常正文。按 scope_items 为每项授权范围建立唯一 scope_refs/checks 映射；保留全量功能覆盖，整项未生成 Spec 的功能在 dispositions 中记录，部分延后范围继续保留在清单；已授权且清晰的 included 功能必须有 Spec。具备独立交付/验收价值的成员优先保留身份并用 page_batches 分组，不能为减少数量合并成内容摘要。
-4. 递归展开 requires/provides 的最小能力闭包。边以源码和契约为据，已有能力通过有效证据复用；不将启动动画、找回密码等同页扩展自动提前。每项能力指定一个选定提供者，替代方案不全部强制实现。跨越用户范围、依赖未来阶段或冲突的显式顺序，先返回上游调整建议。拒绝组合依赖环。
-5. 对每个 Spec 给出五项 0–5 评分及证据：里程碑贡献 M、解锁 U、用户价值 V、风险消减 R、反馈 F。价值分 `6M+5U+4V+3R+2F`；优先指数除以含实现、测试、集成和预期返工的 worker 小时。记录 low/expected/high、置信度及剩余日历耗时（含必要验证等待），缺乏可靠估算时明确说明范围和不确定性。只评增量收益，不重复领取既有能力收益。
-6. 评估工作量、并行性、文件耦合、契约成熟度及验证资源，写 recommended_workers、owned_paths、rationale。本版本实际只有一个实现 worker，人数建议用于复盘，不自动开放并发。
-7. 设计测试时机：四项风险各 0–3（影响、共享、不确定性、依赖放大）。数据损失、鉴权、启动、共享契约或合计≥8，所有当前增量 checks 即时执行；其他 checks 分为 immediate 与 batch。提供给下游的能力契约必须属于 immediate。最晚验证点为该 Spec 所属里程碑，测试准备和执行成本计入估算。不为未实现的 deferred 功能提前编写完整测试。
-8. 按 [轮次范围评估](round-scope-assessment.md) 明确本轮目标、范围映射、必要前置、暂缓去向、成本风险和验收条件，复用 rounds.rationale 记录。为每个上游里程碑设计有明确目标与 goal_checks 的页面轮次：baseline 先完成真实基础可用路径，incremental 按优先级增强，completion（如有）完成约定范围。轮次可按需增减，不能擅自改变用户里程碑；新计划使用 `dispatch_mode=page-batches`。每轮只包含目标需要的页面；同一页面跨轮次保留结构与状态，不重新生成覆盖。
-9. 逐 round/page_batch 在现有 rationale 和派生评审摘要中保留带版本来源、精确成员理由、备选与未选原因、收益假设和风险，版本修订保留旧证据。生成前根据同页、状态/组件/文件耦合和测试准备复用初排 page_batches，已有有效详细 Spec 时直接结合其证据；初排也须满足现有计划结构和证据要求。收到本轮详细 Spec 后按下节复核，再交付开发安排。批次写 goal、rationale、max_specs、max_effort_hours、opportunistic_hours（默认 0）。每个 Spec 恰好归属一个同页同轮批次，归拢不合并验收 ID 或绕过能力门禁。批次收缩后出现跨页交错依赖环时拆分页面访问，不能强行整页闭环。页面 scope_complete 仅表示已核对全部约定范围，true 时附 scope_evidence_refs；未分配后续范围时为 false，不能靠已生成 Spec 全通过就声称页面完善。
-10. 当前轮次只细化到可评审的目标、行为概要、不变量、实施所有权和检查层级。未知接口、平台结论与验收细节返回缺口，不用空数组伪装已核验。生成方若发现需补充工作包或依赖，返回 proposed_plan_updates，由计划维护者判断后按 revision 修订。
-11. 先保存按用户授权创建/修订的 features.json，再写 pages.json v2 和派生评审摘要，开启 spec_generation_policy=required-v1。按格式核对，工具可用时补充 planning-only 校验并如实报告是否执行；将计划路径、revision/hash、选定 round/batch/spec_ids 交调用方。计划刷新后重新确定生成选择；不因用户改波次就重建已完成身份。默认完成计划即交调用方处理；详细规格由调用方交生成能力展开。执行账本、报告、其他能力和在途处置仍交调用方处理。
-
-## 生成后分组复核
+1. 核对 migration_root、已确认功能范围、选定架构、现有分析及用户优先级；已有有效来源直接复用，不重新分析、选型或创建目标工程。
+2. 页面生成前只按功能目标记录里程碑草案、必要前置和待绑定范围，不预设页面数、Spec 数或任务 ID。草案不作为开发输入。
+3. 页面生成后完整读取pages.json、各页面 spec.md 和现有执行账本，固定页面计划路径、内容哈希及已有任务身份。规格缺失或账本不一致时返回具体缺口，不代替生成方修补。
+4. 按用户目标、优先级及实际依赖确定任务排序，划入里程碑和波次；页面归属及生成时的顺序作为辅助依据。本次纳入的每个任务恰好归属一个波次，未纳入任务单独记录原因；完整页面闭环不跨波次拆开；若与用户目标冲突，说明最小冲突及可行的阶段边界，不能静默改用户范围或绕过前置。
+5. 记录各波次目标、页面成员理由、前置、延后去向、成本风险及结束条件。估算缺少依据时明确未知，不为排期新增逐 Spec 评分、共享契约或检查 ID。
+6. 交付完整 planning 内容，由主 Agent 核对后原位更新 batch_report.json，修订前追加 planning_history，不覆盖任务结果及历史。分析和评审写入 spec-planning 目录，交接账本路径及规划 revision/hash；执行、恢复和波次进度只关联账本内 planning 与 tasks。
 
-这是同一计划的后续评审，不另建分组计划、状态文件或执行账本，也不要求等全量 Spec 生成完。仅规划时交付初排及待复核范围即可返回；调用方交回本轮详细规格后继续复核，不能因生成方没有提出问题就默认已完成。
+## 生成后绑定与复核
 
-1. 核对调用方选定的计划版本/hash、生成结果和本次拟开工的 spec_ids（可为一个批次或轮次）；复用仍有效的详细 Spec，不为评审重生成。版本过期或选定成员的规格缺失时返回具体缺口，不把未审查部分表述为最终开发安排；远期未生成范围不阻塞本轮。
-2. 逐成员核验完整行为/异常与验收、requires/provides、共享状态和接口、owned_paths、测试准备、估算及批次预算。检查跨批次依赖环、同组相互阻塞、重复准备与共同修改风险。详细 Spec 是核验线索，结论仍回溯源码、架构契约或用户来源；不能把生成文本本身当成已证实的实现事实。
-3. 用现有 rationale 与评审摘要解释保留或调整的理由。新增依据记录可定位引用与版本，不新增运行时字段；引用详细 Spec 时指明成员/章节及内容哈希，并关联其原始证据。变更评审说明原分组、调整、影响成员、备选及风险；没有新证据不为了优化外观而重新分组。
-4. 分组、依赖、预算或依据存在实质变化时修订 pages.json revision，重新核对格式，工具可用时重跑 planning-only 校验，并交付新版本/hash。保留用户授权与顺序、稳定 spec_id/check_id、目录和独立验收，不通过合批扩大范围。涉及范围或 Spec 边界的语义变化时明确返回受影响成员及需重新生成的内容，由调用方重新选定版本；不自动循环生成。
-5. 无实质变化时保留计划及生成绑定，派生摘要记录复核对象、版本、依据、结论与未决项；不为标记“已看过”而制造计划修订。发生修订时按现有绑定规则核对受影响成员，不因批次顺序变化就一律重写全部 Spec。已有在途工作只返回建议，交调用方处理在途释放、版本核对和历史，不写执行账本。
-6. 开发前由调用方核对本轮复核结论、有效计划与详细规格一致，相关缺口已处置。公共 validate/generation 工具只检查各自的结构、引用及内容身份，不自动证明分组合理或完成这次语义复核；本 Skill 不新增运行状态或冒充派发门禁。
+功能级草案在规格生成流程完成后绑定实际 page_id、order、package 和任务 ID。核对任务覆盖、计划排序和依赖，并记录不能在完整页面单位下满足的细粒度目标；不要求生成方消费新计划或更改正文布局。
 
-例如同页两个 Spec 初排在一个批次，详细展开后发现其中一个依赖另一页尚未提供的能力，应核实依赖并拆分页面访问或调整先后，保留各自身份和证据；不能为了维持原批次而绕过前置，也不能把生成时的上下文分段直接写成新开发批次。
+页面计划或规格变化时，复核受影响波次，保留未变化的身份和历史。修订里程碑与波次不会使已有页面规格重新生成；出现来源或行为错误时返回对应流程处理，不用新哈希覆盖旧关联来伪装有效。
 
 ## 已有产物复核与缺口修订
 
-1. 先记录调用方允许的动作和用户确认的范围。用户要求沿用已有范围时，读取已保存的功能计划、旧计划和 Spec；不重新套用交付预设。原始清单缺少当前范围字段时返回格式缺口，不从优先级、实现状态或 release_stage 猜选中项；仅可在用户明确授权下复核已有范围，不把它称为新清单契约已通过。
-2. 核对来源文件、规范化内容哈希、计划版本及逐成员正文绑定。总范围哈希变化时先定位实际差异，区分成员范围/验收/依赖变化和无关修改；不直接改哈希消除失效。详细正文保持原样，绑定是否可复用交由生成结果的逐成员规则核对。没有旧范围快照时明确无法证明无影响。
-3. 延期功能仍保留真实验收目标。顶层 acceptance 为空时，可从同一功能已有 scope_items 的明确验收目标整理补齐，并记录来源、差异和版本；没有依据则返回具体问题，不能写“后续实现并验证”等占位句通过校验。即便只补元数据，也要核对计划引用是否需要同步。
-4. 分组缺少备选方案说明时，根据当前依赖、页面归属、所有权和用户约束形成当前复核结论，不补造历史取舍。明确说明这是本次新增依据；实质修订按版本规则保留差异。复核收益描述是否与依赖一致，例如详情依赖列表导航时，不能声称两者在数据层完成后即可同时开工。
-5. Facts、UTG 或架构产物缺失时，区分本次复核可验证的结构与尚未证实的行为/归属。可使用已有且有来源的结论；用户禁止重跑分析时不调用分析能力或补造文件。仅缺某个标准文件不否定其他有效架构来源，但目标路径、共享所有权或必要接口无依据时，必须返回受影响成员的 requiredInputs，不能声明开发就绪。
-6. 无需改变语义时保留 Spec、目录与计划版本，交付派生复核摘要；需要修订时只修改有依据的范围和计划，列明保留及受影响成员。用户禁止重新生成时，正文失效成员保持待处理并返回请求，不自动重写或重新登记为有效。仅复核不初始化执行账本。
-
-## 详细规格交接
-
-生成交接提供计划/范围绝对路径、revision/hash、选定成员及来源上下文；接收正文、generation.json 和证据/修订建议。已有有效详细 Spec 可复用；当前轮次只生成新增或受影响成员，远期保留验收概要。生成方消费选定计划，不重新排序、不修改范围、不初始化旧页面账本。发现来源、依赖或共享接口问题时向调用方返回修订请求，不直接调用规划能力。
-
-原生依赖先核对 Facts 的 native-libs.json，再以源码 JNI 入口、System.loadLibrary、CMake/ndk-build 和实际 .so/.a 证据复核。存在 C/C++ 依赖时返回原生依赖 domainRequests，记录源码重编/patch、JNI→NAPI 或闭源替代处置，明确负责 Spec 和共享能力消费者；Facts 未检出不能代替源码核验，缺失库或降级进入未决项，不静默丢弃。
-
-涉及平台能力或不确定 @kit/@ohos API 时返回 knowledgeRequests，列出待查 API、当前证据与期望结论，收到文档 title/uri 后引用到增量。不能从页面名称猜行为、从 source-derived 路径声称运行验证，或从已有代码自动推导完成。
-
-已有基础 Spec 验收后，后续完善读取原页面和功能剩余 scope_items，新增增量 Spec；不得将基础 Spec 扩成不断变化的整页任务。完整规则见 [plan-contract.md](plan-contract.md) 的“逐项范围映射与完成语义”。
-
-
-## 控制 Spec 粒度与重复分析
-
-先判断 Spec 是否拆分过细，再对独立 Spec 分组；不因成员较小就合组。分组限于同轮同页，依据实际依赖、共享状态、文件耦合、测试准备及批次预算，记录共同实施和交付的收益与风险。跨页 Spec 可共同支撑同轮目标，分别进入各自页面批次。
-
-详细规格生成后，复核上述依据及成员验收边界；有实质变化时只调整受影响的分组，保留稳定身份和历史，无变化不重排。缺少依赖或依据时返回具体缺口，不能为了维持批次而绕过前置；实际派发由主 Agent 组织。
-
-Spec 按用户可观察行为划分，不按控件、文件或单条断言拆分。仅在可独立交付、需提前解锁下游、风险/验证时机不同或明确跨轮延期时拆开，并在 Spec 写明拆分理由。例如输入校验、按钮等待状态和基本失败反馈可共同属于“基础登录”，无需各建 Spec；独立登录方式或约定会话恢复可后续新增。
+旧增量计划中的 specs、page_batches、requires/provides 和执行状态仅作历史来源，不能改名后当作本模式的新页面计划。先取得规格生成流程产生的实际页面任务，再核对账本任务引用并写入 planning；不自动迁移或重置旧执行状态。
 
-- 同一阶段、共同交付且耦合紧密的新范围优先归入一个 Spec，一个 Spec 可以拥有多个 scope_refs 和 checks。有独立验收价值的 Spec 先考虑同页批次复用，不因数量多直接归并；确属同一闭环且尚未执行的过细 Spec 可在显式修订中归并，保留 retired_specs 和历史；已验收 Spec 不为降低数量而改写。
-- 已有多个有独立验收价值的 Spec，通过同页固定窗口由同一 worker 连续实施，复用理解与测试准备；仍遵守预算、优先级和能力门禁，不用合批抢跑未来轮次。
-- 估算包括上下文理解、重复分析、交接及测试成本，不只算写代码。没有实际收益的拆分不采用；不设置未经实测的最小时长或 token 阈值。
-- 远期未排期需求保留 scope_id、行为描述、验收目标和延期去向；到授权阶段再细化实现方案与测试资产。已排期 included 范围仍须有 Spec，不以渐进细化掩盖遗漏。
-- 页面 spec.md 保留简短共享上下文：入口、状态/组件契约、能力与负责 Spec、源码定位、关联文件及已核验版本。每个增量只补变化与检查，不复制整页背景；摘要提供定位，不证明当前运行通过。
+用户禁止分析或开发时只使用已有有效输入，记录缺口，不调用分析、构建、测试或开发能力。结构检查和文档存在都不证明页面已实现或波次已完成。

package/skills/d2h-spec-plan/references/planning-review.md

@@ -1,35 +1,23 @@
 # 规划交付与评审记录
 
-首次交付、详细规格生成后复核、变更复评或事后评估时读取。正式范围、依赖和顺序以 pages.json 为准；评审记录解释决策，不另建可编辑计划或执行账本。
+首次交付、生成后绑定、排期修订或事后评估时读取。页面范围、正文和开发验收仍以规格生成或页面开发流程产物为准。
 
-## 首次交付
+## 独立分析产物目录
 
-- 保存 pages.json，关联已确认的 features.json、选定架构、分析来源及版本；记录用户目标、优先级和约束，来源缺失时明确限制。
-- 在计划同目录保存 planning-review.md，按评审时间追加条目，标明任务类型、计划路径及 revision/hash、来源版本和涉及的里程碑、轮次、batch_id、spec_id。
-- 复用计划中的 rationale、估算和测试安排，补充主要划分及分组的依据、实际考虑的备选、取舍、风险和未决项。不复制全量计划，不补造历史决策。
-- 列出本次交付路径、校验方式和实际结果，以及需要调用方确认或补齐的事项；结构检查不代表语义正确或实现已验收。
+里程碑与波次保存在 batch_report.json.planning，旧版本追加到 planning_history；`<migration_root>/.migration/spec-planning/` 的 analysis.md 保存当前分析，planning-review.md 按带时区评审时间追加记录。调用方显式指定其他迁移产物目录时沿用实际路径，不写入 Skill 安装目录或应用源码目录。
 
-## 生成后复核
+analysis.md 记录用户目标、已确认范围与架构、输入路径/版本/字节哈希、页面到里程碑/波次的映射、计划顺序及前置核对、取舍、成本风险、未决项和实际检查结果。draft 明确待绑定范围，不能声称已安排真实页面任务。
 
-记录本次读取的详细规格及生成结果版本、覆盖成员、依赖与分组复核结论。维持原计划时也追加记录，说明依据和未决项，不为记录复核而虚增计划 revision。未审查的成员不能标为已复核。
+## 首次交付与绑定
 
-需要调整时交付受影响范围和建议；详细正文由生成方维护，实际派发和执行状态交调用方处理。
+交付账本 planning 更新及分析，返回账本绝对路径、planning revision/hash、来源版本、纳入任务和未决项。生成完成后核对真实页面任务再绑定；保持规格、目录及账本任务身份，单独记录执行排序依据，不能只在对话交付结论。
 
 ## 变更复评
 
-修改正式计划前保留旧版本及其来源引用，可使用可定位的 Git 提交或独立版本快照；仅覆盖文件并增加 revision 不足以保留历史。修订后记录：
+修订前将旧 planning 完整追加到账本 planning_history，analysis.md 及来源引用保存到 history/<带时区评审时间>-<唯一标识>/，或引用可定位的 Git 版本。记录触发证据、变化及保留的成员、新旧版本、对已生成页面和实际在途工作的影响；无实质变化只追加复核结论。
 
-- 触发原因、证据及原计划版本。
-- 新旧安排差异、受影响和保留的成员、变更依据。
-- 成本、风险、测试安排及已有详细规格需要重新核对的部分。
-- 用户确认来源（涉及范围或架构取舍时）、新计划版本及未决事项。
-
-稳定身份和已完成历史继续保留；已有在途任务时先返回建议，由主 Agent 处理后再应用，不自行修改执行账本。
+旧增量 Spec 计划保留为历史来源，不自动改写其身份或执行记录。已有旧目录评审时保留并引用，不覆盖或删除。目录不可写或输入不完整时明确失败原因，不宣称落盘完成。
 
 ## 事后评估
 
-由调用方提供对应计划版本及 batch_report.json 中的实际实施、验证、返工、等待和缺陷证据，通过稳定 Spec/批次身份关联，记录证据路径及适用代码版本。
-
-比较估算与实际偏差、分组的重复准备与切换成本、依赖遗漏、测试风险判断与实际缺陷。区分计划问题、实现问题和外部环境影响，给出有证据的局部改进建议；没有实测成本或有效对照时说明无法判断收益，不编造节省比例或把历史 PASS 当作当前结果。
-
-评估追加到 planning-review.md；需要改变后续安排时再按变更规则修订正式计划。实际执行与验收结果仍由主 Agent 维护。
+只读取已有页面账本及实际实施、验证、返工和等待证据，比较阶段安排与真实结果。区分排期问题、页面实现问题和外部影响；无实测对照不编造收益。结论更新分析并追加评审，需要调整后续排期时再显式修订账本 planning。

package/skills/d2h-spec-plan/references/round-scope-assessment.md

@@ -1,49 +1,22 @@
-# 轮次范围评估与复评
+# 波次范围评估与复评
 
-新建轮次，或新证据已影响目标可达性、范围选择、依赖、预算或验证窗口时读取。原始功能清单只读，本技能按用户明确选择维护范围并评估轮次；主 Agent 根据实际状态调度和触发复评。普通状态更新、单次可修复错误或候选变化本身不要求重做规划。
-
-## 评估输入
-
-固定本次 features.json 路径、revision/hash、delivery 及用户顺序；读取当前 pages.json、候选与账本版本（有事件序号时同时交接）、已有有效证据、未决问题和资源条件。分析报告的 P0/P1/P2、可行性、渠道/承载、SDK 与用户待办作为线索，不能替换用户优先级、授权或运行证据。
-
-已有计划缺少交付配置或分析输入时，保留已确认范围并返回缺口；需要用户调整范围时返回所需范围确认请求，由调用方组织确认后再交回，不把旧 included 集合或默认项直接当作本次授权。涉及范围变化按版本协议修订，不改在途窗口；不为补评估强制重跑分析或重置账本。
+新建波次，或用户目标、页面计划、依赖及环境变化影响排期时读取。不改变已有页面生成、开发与验收行为。
 
 ## 每轮需要回答的问题
 
 | 内容 | 交付要求 |
 |---|---|
-| 目标与边界 | 用户能完成什么路径，属于哪个里程碑及交付目标；本轮明确不包含什么 |
-| 本轮范围 | 列出 feature_id/scope_id、关联 Spec 和页面批次；解释选择理由，不只报 Spec 数量 |
-| 必要前置 | requires/provides 的最小能力闭包、提供者与当前证据；区分复用已验证能力、需本轮实现、外部缺口 |
-| 暂缓与未决 | 列出未进入本轮的相关范围、原因及后续轮次/上游处置；未授权或 unassigned 不强行排期 |
-| 成本与风险 | 实现/测试/集成/上下文成本、low/expected/high 与置信度；指出关键路径、资源等待和主要风险 |
-| 验收与结束条件 | 关联 goal_checks、各 Spec checks、验证层级和目标路径；成员 accepted 后仍须 round_accept，不用说明文字代替证据 |
-
-默认先寻找真实基础可用路径，如“启动 → 基本登录 → 主页面雏形”；无登录项目按实际入口组织。完整启动动画、其他登录方式等扩展不阻塞基础首页，除非源码证明其为必要前置。MVP/核心/全量是范围层级，baseline/incremental/completion 是里程碑内轮次，二者不能机械对应。
-
-不要为证明闭环而预支未知平台能力。必要能力超出授权范围、依赖未来阶段或与显式顺序冲突时，输出最小调整建议及证据，返回调用方更新范围产物；用户真正需要取舍时由主 Agent 询问。获准前不改范围、不生成越权派发。
-
-## 记录位置与一致性
-
-复用现有产物，不增加第二份轮次计划或执行账本：
-
-- pages.json 的 rounds[].goal、rationale、goal_checks 保存轮次目标、选择/暂缓依据和验收入口。rationale 简要注明评估所依据的功能版本及关键不确定性，不补造 schema 字段。
-- 本轮成员由 page_batches[].round_id/spec_ids 确定，范围由 Spec.scope_refs 确定，前置由 requires/provides 确定；同一范围不重复认领。
-- 受影响页面 spec.md 保持“范围项 → 轮次 → 批次 → Spec → checks”表，补本轮边界、暂缓去向、成本/风险与证据定位。跨页共用轮次引用同一 round_id；全局目标以 rounds 为准，避免各页分别作出冲突决策。
-- 工时估算由 Spec.effort 汇总，批次受 max_effort_hours 等预算约束；worker 工时、剩余日历耗时、实际派发跨度分开。不能直接把并行/等待工时相加当总用时，缺可靠数据就说明未知。
-- batch_report.json 与看板只读取同一计划和当前派生状态，不手写覆盖派生报告。评估说明不代表已开始、已交付或已验收。
-
-## 执行中复评
-
-主 Agent 在以下变化已影响轮次安排时交回本技能：
+| 目标与边界 | 用户本阶段能完成什么，依据哪个已确认目标 |
+| 页面成员 | 引用已有 page_id、order、package 和账本任务 ID，解释任务排序及波次划分 |
+| 必要前置 | 页面依赖和外部条件；不能将未验证能力写成已满足 |
+| 暂缓与冲突 | 后续页面去向；完整页面无法拆成细粒度里程碑时明确冲突 |
+| 成本与风险 | 估算来源、不确定性和等待条件；无实测不编造节省比例 |
+| 结束条件 | 本波页面按对应流程完成、执行账本及当前证据一致，阶段目标得到核对 |
 
-1. 用户调整范围、交付目标、优先级或顺序，由本 Skill 根据实际选择修订范围计划；仅代码事实变化或分析遗漏时请求调用方补充分析，不以重跑分析覆盖用户决定。
-2. 用户调整架构边界，或新源码/平台证据表明原行为不可行、能力提供者需更换或最小依赖闭包变化；评估计划影响，需要技术重设计时返回调整请求。
-3. SDK/SO、App ID、权限/签名配置、设备或测试资源缺口，使本轮目标无法按原条件验收。
-4. 实际实现、返工、测试或等待已使原预算/截止验证点失效，或已交付轮次出现影响后续目标的回归。
+默认先考虑真实基础可用路径，无登录项目按实际入口组织。功能级草案不改变页面边界；生成时的页面顺序只是排序参考；正式波次只能引用完整页面任务。
 
-先记录触发证据、受影响范围/Spec/轮次及当前固定版本，判断能否在原契约内修复。仅需正常修复或补证据时继续原计划；只有规划语义变化才修订。复评可以明确“保持原计划”，此时不为记录一次评估而虚增 revision 或重置执行。
+## 记录与复评
 
-需要修订时返回 changes 与缺口；调用方处理归档、在途任务/窗口及计划与账本的版本衔接。保留已验收 Spec、稳定 ID、旧 rationale 与历史证据；未来轮次只细化到范围、目标和风险，不提前展开完整实施工单。重排不自动扩大用户范围，也不隐式改变 worker 的固定派发版本。
+波次目标、成员、前置和依据写入 batch_report.json.planning；分析与评审写同目录的 analysis.md 和 planning-review.md。实际实现与验收仍由执行账本记录，不复制完成状态。
 
-向调用方说明：触发原因 → 保持/调整哪些范围 → 前置与成本影响 → 新的验收条件 → 需用户决定的取舍（如有）。
+新证据到来时只调整受影响排期，保留用户目标、已有页面身份及历史。执行排序可随排期修订；页面范围或依赖确需改变时返回调用方处理对应产物，不自行修改 pages.json 或重新生成规格。

package/skills/d2h-spec-plan/references/work-packets.md

@@ -1,35 +1,13 @@
 # 共享状态与验证安排
 
-规划跨 Spec 状态或评估风险与测试安排时，按入口指定章节读取。计划约束归 pages.json；实际接口、执行证据与验收由调用方维护。
+## 跨页面依赖
 
-## 跨 Spec 共享状态
+读取已有页面规格及架构中的共享所有者、数据通道、初始化和生命周期，以此解释波次前置。共享基础仍归规格生成流程确定的页面负责，不另建共享能力 Spec、检查 ID 或 requires/provides 协议。
 
-仅在多个 Spec 实际共享状态时写顶层 shared_contracts，不为每个功能强建基础设施。
+缺少必要接口或页面依赖互相冲突时，返回具体页面及证据，交调用方按规格生成或页面开发流程处理。规划不把尚未实现或未经验证的接口视为可复用能力。
 
-```json
-{
-  "state_id": "session",
-  "capability": "session.basic",
-  "producer_spec_id": "login-basic",
-  "consumer_spec_ids": ["home-basic"],
-  "channel": "SessionStore 单一状态通道",
-  "payload": "令牌、用户标识及匿名/有效/过期状态",
-  "initialization": "登录成功持久化；首页订阅并读取快照",
-  "lifecycle": "注销或过期清空并通知消费者",
-  "checks": ["login/persist-session", "home/observe-session"]
-}
-```
+## 验证安排
 
-producer 提供指定 capability，每个 consumer 必须 requires 它；checks 包含每个参与 Spec 的实际检查，不得越界。channel/payload/initialization/lifecycle 缺失时参与者不能开工。登录和首页 UI 都存在不能证明状态已传递；必须明确谁写、谁读、何时生效及失效，并用消费者断言覆盖状态变化。
+保留逐页实现、managed build、Hypium 测试、报告与提交闭环。阶段结束只核对页面验收结果及用户目标，不将本应即时执行的页面检查延到波次末尾。
 
-## 分层验证与定向修复
-
-逐 Spec 根据失败影响、共享范围、实现不确定性及下游依赖评估风险，引用源码、架构或已有缺陷作为依据，不按代码量或 Spec 大小直接判断是否需要测试。
-
-- 高风险：涉及鉴权、数据丢失、启动主路径、共享契约，或失败会阻断下游能力时，安排专项测试，覆盖关键成功、失败及状态变化；在依赖方使用前验证相关契约。
-- 一般风险：新增或改变可观察行为时，安排对应行为测试；互不阻塞的检查可在批次结束时合并执行，保留逐 Spec 的验收对应关系。
-- 低风险：仅文案、样式或不改变行为的局部调整，且无共享影响时，可不新增专项自动化测试；说明理由，安排适用的静态检查、人工核验或已有测试回归，仍须核对验收目标。已有测试覆盖需指明用例及适用范围，不能把历史通过当作本次结果。
-
-计划记录风险依据、是否新增测试、验证方式、关键检查、执行时机和必要准备；缺少环境或证据时保留未决，不以低风险代替验证。详细规格或实现证据改变风险判断时局部复评，实际执行与验收由主 Agent 组织，已有明确测试要求不因风险分级而取消。
-
-分层是选择验证成本的计划，不改变通过标准。按检查目的选择静态、逻辑、集成或设备验证；涉及真实平台行为时保留必要设备验证，不能用静态检查替代。高风险反例可包括失效令牌、重复提交或返回后状态丢失；共同准备和测试执行可以复用，验收仍逐 Spec 对应。
+高风险、平台差异和测试准备记录在排期依据中，不能减免规格要求，也不能因里程碑需要而新增另一套执行门禁。历史 PASS、静态校验或页面存在不能代替当前实现和设备证据。