@harmonyos-arkts/d2h 0.1.21 → 0.1.26

package/skills/d2h-spec-generate/references/spec-content.md

@@ -2,15 +2,13 @@
 
 生成新页面文档、细化当前轮次或审查实施内容时读取 [spec-template.md](../assets/spec-template.md)。模板恢复原页面 Spec 中已使用的七个核心章节：页面范围、开发顺序、页面功能、UI 操作与验收、Android 证据、HarmonyOS 实现范围、未决项与平台差异；在此基础上增加当前增量流程的稳定范围、轮次、批次及逐 spec_id 内容。
 
-这次复用原模板的内容要求，不恢复旧的固定 page_score 排序、带序号目录、逐页全量实现或手写 batch_report 状态。pages.json、features.json 和 execution.json 的职责不变；模板不改变计划 schema，也不证明实际应用已经验收。
-
 ## 生成组织
 
 1. 从选定计划读取完整功能范围去向、稳定 spec_id、依赖、轮次与同轮同页的 page_batches，不重新决定或改写计划。优先通过分组复用上下文，不以减少 Spec 数量或压缩文档为目标。
-2. 每页目录仍只有一份 spec.md；from-plan 模式的七个公共章节保留原布局并置于所有成员块之外，各成员的来源与实现细节保留在自己的稳定块内；页面共用入口、状态与证据写一次，当前轮次的每个 Spec 使用 `### Spec: <spec_id>` 稳定标题，逐项写清范围、行为、异常、数据、副作用及检查。一个文件含多个 Spec 不等于合成一个执行/验收单元。
-3. 按计划组细化当前轮次潜在派发成员，包括组内尚待提供者解锁的消费者。未知契约保留开工问题，不臆造接口。组内成员分别完整，不用组摘要替代。
+2. 每页目录仍只有一份 spec.md；当前流程的七个公共章节保留原布局并置于所有成员块之外，各成员的来源与实现细节保留在自己的稳定块内；页面共用入口、状态与证据写一次，当前轮次的每个 Spec 使用 `### Spec: <spec_id>` 稳定标题，逐项写清范围、行为、异常、数据、副作用及检查。一个文件含多个 Spec 不等于合成一个执行/验收单元。
+3. 只细化调用方在固定版本上选定的成员；其中可以包含尚待提供者解锁的消费者，但不能因其属于同组就自行扩大选择。未知契约保留开工问题，不臆造接口。选定成员分别完整，不用组摘要替代。
 4. 远期内容保留真实已知的范围、前置、验收目标、延期去向与待细化内容，不提前扩成完整实施工单。已授权范围仍须符合 scope_refs 覆盖要求；到达轮次前补齐内容与工作包。
-5. 一个组可以包含一个或多个 Spec，数量按行为、复用、依赖、风险和预算决定。归拢不能抹去独立验收身份，紧密关联的同一闭环也不机械按控件拆分。不同页面或轮次保持不同 batch_id。
+5. 开发组、成员数量、依赖、风险权衡和预算以选定计划为准，生成方不重新分组。可为上下文容量分次完成正文，但不改变 spec_id/round_id/batch_id、范围或验收身份，也不创建新的开发批次。分组证据由 pages.json 维护，正文只引用计划身份；发现问题返回修订请求。
 
 ## 写入前核验（延续原生成要求）
 
@@ -27,7 +25,7 @@
 - 每个范围有唯一负责 Spec，文档与 scope_refs、轮次/批次成员一致；未选范围有去向，没有被“合并”隐去。
 - 每个 check 都有可执行场景、入口/输入、操作、明确断言及验证层级/时机。断言不能只写“正常”“成功”或“符合预期”。
 - 正常与必要失败分支、数据读写与共享生命周期、HarmonyOS 路径、契约边界及阻塞问题足以可靠实施；背景可引用，核心行为不能仅写“同上”。
-- 同页修订只更新受影响 Spec 章节，保留其他成员、已验收身份和历史。补解释文字不自动撤销验收；改范围、checks 或共享契约按语义修订和 reconcile 处理。
+- 同页修订只更新受影响 Spec 章节，保留其他成员、已验收身份和历史。补解释文字不自动撤销验收；改范围、checks 或共享契约由调用方按实际影响修订计划并衔接账本。
 
 内容缺失时主 Agent 返回具体 spec_id/check_id 和待补内容，不派发该成员。现有 readiness_gaps 校验工作包字段与接口等结构约束，并不解析 Markdown、证明章节语义完整；不能因为模板标题存在或程序通过就省略此审查。若后续需要程序化内容门禁，应另行设计显式策略，不能假装当前已有。
 

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

@@ -1,38 +1,33 @@
 ---
 name: d2h-spec-plan
-description: Plan reviewable incremental HarmonyOS scope, dependencies, waves and acceptance outlines from versioned scope and architecture. Revise after user adjustments or scope expansion. Returns a versioned plan and gaps; does not generate detailed spec.md, dispatch workers or maintain execution state.
+description: 基于已确认功能范围、选定架构和分析证据规划增量 HarmonyOS Spec，组织里程碑、目标轮次及同页批次，评估依赖、成本与测试风险。用于首次规划、详细规格生成后的分组复核，以及新证据下的局部修订和事后评估；保留决策与版本记录，不负责用户选型、详细规格生成或运行时派发。
 ---
 
-# 增量 Spec 规划
+# Spec 规划
 
-把明确的交付范围转为可评审、可调整的增量计划。先提出波次供用户调整，再按选定版本交给独立生成能力展开详细规格；已有明确授权时无需重复确认。消费的是产物和调用参数，不要求先运行指定技能，也不加载其他技能。缺少领域结论时返回请求，由调用方决定如何补齐。
+消费已确认的功能范围（features.json）、选定架构和分析结果，组织“里程碑 → 目标轮次 → 同页批次 → Spec”。本技能负责规划当前轮次的 Spec 范围、依赖、成本、验收和测试安排，或在新证据下修订受影响的计划。范围和架构选择、运行时派发仍由 d2h 主代理负责。
 
-## 输入
+1. 里程碑（Milestone）: 由版本化功能计划定义的目标阶段，通常对应一个发布版本或主要功能集。
+2. 目标轮次（Target Round）: 在里程碑下的一轮可验证交付，定义本轮目标、范围和必要前置。
+3. 同页批次（Same-Page Batch）: 在同一目标轮次内，将适合共同实施和交付的同页 Spec 合理分组，复用上下文、代码及测试准备，明确分组依据和预算，保留各自验收身份。
+4. Spec 规划项: 可独立追踪、实现和验收的行为单元；规划时确定稳定身份、范围边界、依赖和验收目标，详细规格由生成能力展开。
 
-- 版本化 `features.json`：稳定功能/范围 ID、用户选择、优先级、里程碑、来源与版本。已有有效清单直接复用，不重新分析功能或改写授权。
-- Android 源码、现有实现及目标工程定位；Facts、UTG 到达/采集计划、架构上下文和既有证据按当前任务需要读取。UTG 的 `page.json` 不是业务页面或开发任务队列，不能逐节点转换成 Spec。
-- 修订时提供旧计划/Spec、范围差异和当前能力/在途摘要。执行账本可以提供只读线索，不由本 Skill 修改。
+保留 Spec 独立验收身份，详细规格生成后复核分组；具体粒度、分组与调整方法按需读取参考。
 
-需要字段定义或结构校验时使用公共工具 `d2h workflow contract plan`、`d2h workflow contract scope`、`d2h workflow validate --planning-only --plan <pages.json> --features <features.json>`。这是显式工具依赖；工具不可用时返回缺少的能力，不加载其他 Skill 或自行安装工具。
+## 风险与测试安排
 
-## 按任务读取
+逐 Spec 评估失败影响、共享范围、实现不确定性和下游依赖，明确测试需求、验证方式及时机；不新增专项测试时记录依据，低风险仍须核对验收目标。具体分级与安排按需读取参考，已有明确测试要求不得取消。
 
-| 任务 | 本 Skill 的参考 |
-|---|---|
-| 初次规划、范围/依赖/批次组织变化 | [planning-method.md](references/planning-method.md) |
-| 接收目标目录、所有权与共享边界 | [architecture-handoff.md](references/architecture-handoff.md) |
-| 评估本轮范围、最小前置与验收 | [round-scope-assessment.md](references/round-scope-assessment.md) |
-| 细化实施工作包和共享接口约束 | [work-packets.md](references/work-packets.md) |
+## 交付与记录
 
-## 输出与边界
+每次规划或复评交付正式计划及简短评审记录，关联输入来源和计划版本，说明主要划分、分组、风险及测试安排的依据。生成后复核即使维持原计划，也保留结论；修订时保留旧版本、稳定身份和变更原因。执行结果由主 Agent 记录，本技能引用实际证据复评，不维护执行账本。记录要求与事后评估方法按需读取参考。
 
-- `pages.json` v2：范围映射、Spec 身份、依赖、轮次、固定同页批次、实现位置、工作包、成本和测试安排。
-- 便于评审的波次摘要：目标、范围、前置、延期、估算与验收概要。摘要从 pages.json 派生，不成为第二份计划真源。
-- 新增 `spec_generation_policy=required-v1`。本 Skill 不写 spec.md 或 generation.json；生成任务的输入/输出见公共 `d2h workflow contract generation`。
-- 返回 `status`（planned / needs-input / needs-revision）、`artifacts`、`changes`、`unresolved` 与 `requests`。修订差异明确受影响/保留的 Spec、批次与范围；请求说明所需知识、接口、工程或验证结论及消费者，不指定下一项 Skill。
+## 按需参考
 
-调用方维护用户范围及交付目标。只在独立交付、解锁依赖、风险差异或跨轮延期需要时拆 Spec，按源码与真实行为归并页面；不从模块名、控件或 UTG 节点机械拆分。缺口阻止相应成员开工，不冒充已实现或已验收。
+以下仅引用对应章节的规划规则；参考中尚未整理的生成、派发、执行账本和看板流程暂不纳入本次大纲。
 
-版本变化保留稳定 ID 和历史；已有在途成员时先返回修订建议，由调用方处置派发与状态再应用。MVP 扩展到核心时复用仍有效的分析和架构，保留已完成 Spec、目录和历史，仅规划新增范围与受影响依赖；范围缺口返回调用方，不机械重跑前置阶段。
-
-规划不写 `execution.json`，不生成执行报告或看板，不选择 worker，不决定构建/测试时机的实际执行，不判定验收通过。
+- 拆分 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)。

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

@@ -1,4 +1,4 @@
 interface:
   display_name: "页面轮次与增量 Spec 规划"
-  short_description: "围绕目标组织页面轮次、同页开发批次、依赖和测试计划"
-  default_prompt: "Use $d2h-spec-plan to read the feature plan and source evidence, then author or revise a reviewable v2 wave plan, preserving user choices and completed scope. Return fixed IDs, dependencies and acceptance outlines; do not write detailed spec.md."
+  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."

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

@@ -8,6 +8,6 @@ d2h workflow contract scope
 d2h workflow validate --planning-only --plan <pages.json> --features <features.json>
 ```
 
-本 Skill 输出轻量 Spec 条目、依赖、轮次/批次、已知工作包约束和验收概要；详细正文与生成绑定由独立生成能力维护。新计划开启 spec_generation_policy=required-v1。生成输入输出读取 d2h workflow contract generation。规划校验不要求页面目录或 spec.md 已存在，规划方法见 [planning-method.md](planning-method.md)。调用方执行事件、派发和生成报告；规划不创建执行状态。
+本 Skill 输出轻量 Spec 条目、依赖、轮次/批次、已知工作包约束和验收概要；详细正文与生成绑定由独立生成能力维护。新计划开启 spec_generation_policy=required-v1。生成输入输出读取 d2h workflow contract generation。规划校验不要求页面目录或 spec.md 已存在，规划方法见 [planning-method.md](planning-method.md)。调用方负责派发、维护 batch_report.json 和生成报告；规划不创建执行状态。
 
 结构校验通过不代表源码理解、授权范围、架构归属或实际行为已通过人工复核。只使用已给定输入，不根据产物缺失猜测执行状态或强制运行特定生产技能。

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

@@ -1,18 +1,18 @@
 # 增量范围、页面轮次与评估方法
 
-创建计划或因新依赖、范围/归拢变化修订语义时读取本参考。仅执行状态更新不重做规划。写入机器可读计划时读取 [plan-contract.md](plan-contract.md)。
+创建计划、收到详细 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`；缺失的源码行为仍需记录。无源码的用户新增需求可引用用户来源，缺失证据保持未决。
-- 仍有效的架构上下文与已有工程记录：按 [架构交接](architecture-handoff.md) 核对所有者、目录和风险；不重新选方案。
-- 既有 pages.json、execution.json 和页面 spec.md；迁移报告和既有实现只提供线索，不能证明当前通过。
+- 仍有效的架构上下文与已有工程记录：核对调用方已确认的所有者、目录和风险；不擅自重新选方案。
+- 既有 pages.json、batch_report.json 和页面 spec.md；迁移报告和既有实现只提供线索，不能证明当前通过。
 
 ## 规划工作
 
-1. 消费调用方提供的稳定功能/范围项及来源映射，不把 P0/P1/P2 当用户优先级或交付层。校验功能计划，读取当前阶段全部功能及用户顺序。功能的新增、排除、阶段和优先级由调用方维护，本技能不能静默修改。用户指定 MVP/核心/全量或局部范围时读取公共 `d2h workflow contract delivery`，先核对 delivery 与 scope_items 实际授权，不从优先级或轮次名称推断选用层。
+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 的最小能力闭包。边以源码和契约为据，已有能力通过有效证据复用；不将启动动画、找回密码等同页扩展自动提前。每项能力指定一个选定提供者，替代方案不全部强制实现。跨越用户范围、依赖未来阶段或冲突的显式顺序，先返回上游调整建议。拒绝组合依赖环。
@@ -20,13 +20,35 @@
 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. AI 根据同页、状态/组件/文件耦合和测试准备复用决定 page_batches，写 goal、rationale、max_specs、max_effort_hours、opportunistic_hours（默认 0）。每个 Spec 恰好归属一个同页同轮批次，归拢不合并验收 ID 或绕过能力门禁。批次收缩后出现跨页交错依赖环时拆分页面访问，不能强行整页闭环。页面 scope_complete 仅表示已核对全部约定范围，true 时附 scope_evidence_refs；未分配后续范围时为 false，不能靠已生成 Spec 全通过就声称页面完善。
+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. 只写 pages.json v2 和派生评审摘要，开启 spec_generation_policy=required-v1，运行 planning-only 校验；将计划路径、revision/hash、选定 round/batch/spec_ids 交调用方。计划刷新后重新确定生成选择；不因用户改波次就重建已完成身份。需要执行账本、报告、详细规格或在途处置时交调用方处理。
+11. 先保存按用户授权创建/修订的 features.json，再写 pages.json v2 和派生评审摘要，开启 spec_generation_policy=required-v1。按格式核对，工具可用时补充 planning-only 校验并如实报告是否执行；将计划路径、revision/hash、选定 round/batch/spec_ids 交调用方。计划刷新后重新确定生成选择；不因用户改波次就重建已完成身份。默认完成计划即交调用方处理；详细规格由调用方交生成能力展开。执行账本、报告、其他能力和在途处置仍交调用方处理。
+
+## 生成后分组复核
+
+这是同一计划的后续评审，不另建分组计划、状态文件或执行账本，也不要求等全量 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 不新增运行状态或冒充派发门禁。
+
+例如同页两个 Spec 初排在一个批次，详细展开后发现其中一个依赖另一页尚未提供的能力，应核实依赖并拆分页面访问或调整先后，保留各自身份和证据；不能为了维持原批次而绕过前置，也不能把生成时的上下文分段直接写成新开发批次。
+
+## 已有产物复核与缺口修订
+
+1. 先记录调用方允许的动作和用户确认的范围。用户要求沿用已有范围时，读取已保存的功能计划、旧计划和 Spec；不重新套用交付预设。原始清单缺少当前范围字段时返回格式缺口，不从优先级、实现状态或 release_stage 猜选中项；仅可在用户明确授权下复核已有范围，不把它称为新清单契约已通过。
+2. 核对来源文件、规范化内容哈希、计划版本及逐成员正文绑定。总范围哈希变化时先定位实际差异，区分成员范围/验收/依赖变化和无关修改；不直接改哈希消除失效。详细正文保持原样，绑定是否可复用交由生成结果的逐成员规则核对。没有旧范围快照时明确无法证明无影响。
+3. 延期功能仍保留真实验收目标。顶层 acceptance 为空时，可从同一功能已有 scope_items 的明确验收目标整理补齐，并记录来源、差异和版本；没有依据则返回具体问题，不能写“后续实现并验证”等占位句通过校验。即便只补元数据，也要核对计划引用是否需要同步。
+4. 分组缺少备选方案说明时，根据当前依赖、页面归属、所有权和用户约束形成当前复核结论，不补造历史取舍。明确说明这是本次新增依据；实质修订按版本规则保留差异。复核收益描述是否与依赖一致，例如详情依赖列表导航时，不能声称两者在数据层完成后即可同时开工。
+5. Facts、UTG 或架构产物缺失时，区分本次复核可验证的结构与尚未证实的行为/归属。可使用已有且有来源的结论；用户禁止重跑分析时不调用分析能力或补造文件。仅缺某个标准文件不否定其他有效架构来源，但目标路径、共享所有权或必要接口无依据时，必须返回受影响成员的 requiredInputs，不能声明开发就绪。
+6. 无需改变语义时保留 Spec、目录与计划版本，交付派生复核摘要；需要修订时只修改有依据的范围和计划，列明保留及受影响成员。用户禁止重新生成时，正文失效成员保持待处理并返回请求，不自动重写或重新登记为有效。仅复核不初始化执行账本。
 
 ## 详细规格交接
 
-公共契约见 `d2h workflow contract generation`。已有有效详细 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 未检出不能代替源码核验，缺失库或降级进入未决项，不静默丢弃。
 
@@ -37,10 +59,14 @@
 
 ## 控制 Spec 粒度与重复分析
 
+先判断 Spec 是否拆分过细，再对独立 Spec 分组；不因成员较小就合组。分组限于同轮同页，依据实际依赖、共享状态、文件耦合、测试准备及批次预算，记录共同实施和交付的收益与风险。跨页 Spec 可共同支撑同轮目标，分别进入各自页面批次。
+
+详细规格生成后，复核上述依据及成员验收边界；有实质变化时只调整受影响的分组，保留稳定身份和历史，无变化不重排。缺少依赖或依据时返回具体缺口，不能为了维持批次而绕过前置；实际派发由主 Agent 组织。
+
 Spec 按用户可观察行为划分，不按控件、文件或单条断言拆分。仅在可独立交付、需提前解锁下游、风险/验证时机不同或明确跨轮延期时拆开，并在 Spec 写明拆分理由。例如输入校验、按钮等待状态和基本失败反馈可共同属于“基础登录”，无需各建 Spec；独立登录方式或约定会话恢复可后续新增。
 
 - 同一阶段、共同交付且耦合紧密的新范围优先归入一个 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

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

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

@@ -1,12 +1,12 @@
 # 轮次范围评估与复评
 
-新建轮次，或新证据已影响目标可达性、范围选择、依赖、预算或验证窗口时读取。功能清单技能维护授权范围；本技能在这些约束内评估轮次；主 Agent 根据实际状态调度和触发复评。普通状态更新、单次可修复错误或候选变化本身不要求重做规划。
+新建轮次，或新证据已影响目标可达性、范围选择、依赖、预算或验证窗口时读取。原始功能清单只读，本技能按用户明确选择维护范围并评估轮次；主 Agent 根据实际状态调度和触发复评。普通状态更新、单次可修复错误或候选变化本身不要求重做规划。
 
 ## 评估输入
 
-固定本次 features.json 路径、revision/hash、delivery 及用户顺序；读取当前 pages.json、候选与事件序号、已有有效证据、未决问题和资源条件。分析报告的 P0/P1/P2、可行性、渠道/承载、SDK 与用户待办作为线索，不能替换用户优先级、授权或运行证据。
+固定本次 features.json 路径、revision/hash、delivery 及用户顺序；读取当前 pages.json、候选与账本版本（有事件序号时同时交接）、已有有效证据、未决问题和资源条件。分析报告的 P0/P1/P2、可行性、渠道/承载、SDK 与用户待办作为线索，不能替换用户优先级、授权或运行证据。
 
-旧计划无 delivery 或未接新分析报告时，保留可验证的既有用户选择并说明限制；无明确用户选择时交上游建立默认核心范围，不把旧 included 集合直接当作用户已选全量。涉及范围变化按版本协议修订，不改在途窗口；不为补评估强制重跑分析或重置账本。
+已有计划缺少交付配置或分析输入时，保留已确认范围并返回缺口；需要用户调整范围时返回所需范围确认请求，由调用方组织确认后再交回，不把旧 included 集合或默认项直接当作本次授权。涉及范围变化按版本协议修订，不改在途窗口；不为补评估强制重跑分析或重置账本。
 
 ## 每轮需要回答的问题
 
@@ -37,13 +37,13 @@
 
 主 Agent 在以下变化已影响轮次安排时交回本技能：
 
-1. 用户调整范围、交付目标、优先级或顺序；先由功能清单技能修订上游。
-2. 新源码/平台证据表明原行为不可行、能力提供者需更换或最小依赖闭包变化。
+1. 用户调整范围、交付目标、优先级或顺序，由本 Skill 根据实际选择修订范围计划；仅代码事实变化或分析遗漏时请求调用方补充分析，不以重跑分析覆盖用户决定。
+2. 用户调整架构边界，或新源码/平台证据表明原行为不可行、能力提供者需更换或最小依赖闭包变化；评估计划影响，需要技术重设计时返回调整请求。
 3. SDK/SO、App ID、权限/签名配置、设备或测试资源缺口，使本轮目标无法按原条件验收。
 4. 实际实现、返工、测试或等待已使原预算/截止验证点失效，或已交付轮次出现影响后续目标的回归。
 
 先记录触发证据、受影响范围/Spec/轮次及当前固定版本，判断能否在原契约内修复。仅需正常修复或补证据时继续原计划；只有规划语义变化才修订。复评可以明确“保持原计划”，此时不为记录一次评估而虚增 revision 或重置执行。
 
-需要修订时返回 changes 与缺口；调用方按公共执行契约处理归档、在途任务/窗口及 reconcile。保留已验收 Spec、稳定 ID、旧 rationale 与历史证据；未来轮次只细化到范围、目标和风险，不提前展开完整实施工单。重排不自动扩大用户范围，也不隐式改变 worker 的固定派发版本。
+需要修订时返回 changes 与缺口；调用方处理归档、在途任务/窗口及计划与账本的版本衔接。保留已验收 Spec、稳定 ID、旧 rationale 与历史证据；未来轮次只细化到范围、目标和风险，不提前展开完整实施工单。重排不自动扩大用户范围，也不隐式改变 worker 的固定派发版本。
 
-向用户说明：触发原因 → 保持/调整哪些范围 → 前置与成本影响 → 新的验收条件 → 需用户决定的取舍（如有）。
+向调用方说明：触发原因 → 保持/调整哪些范围 → 前置与成本影响 → 新的验收条件 → 需用户决定的取舍（如有）。

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

@@ -1,28 +1,6 @@
-# 自足工作包、共享状态与实际接口
+# 共享状态与验证安排
 
-创建或细化当前轮次、处理开工缺口、设计跨 Spec 状态流时读取。计划字段归 pages.json；接口回执归 execution.json。context 裁剪输出，不另建可编辑工单真源。
-
-## 开工就绪
-
-新计划使用 `work_packet_policy: "required-v1"`。每个 Spec 提供：
-
-```json
-{
-  "implementation_brief": {
-    "behavior_notes": ["输入、状态转移、结果与必要失败路径"],
-    "invariants": ["本次行为不能破坏的约束"],
-    "known_pitfalls": ["从源码或实际失败确认的风险"],
-    "open_questions": []
-  },
-  "testing": {
-    "layers": [{"check_id": "login/basic", "layer": "device", "reason": "真实鉴权与导航"}]
-  }
-}
-```
-
-behavior_notes 非空；其余三个数组必须存在，无适用内容经核对后写 []。open_questions 只放阻止可靠实现的未决问题，非阻塞背景放 behavior_notes。testing.layers 唯一且完整覆盖本 Spec 的 checks；layer 为 static/logic/integration/device，reason 非空。可暂存不完整计划，但 derive.readiness_gaps 阻止相关成员进入窗口，不能夹带进同页批次。
-
-工作包复用 scope、evidence_refs、owned_paths、requires/provides 和 checks。AI 按任务补齐 UI 入口与路由参数、数据表/键/副作用、逻辑模块及目标文件；纯后台/算法能力不虚构页面。源码仍是行为细节依据，摘要用于定位与交接。远期延期需求不提前写大工单。
+规划跨 Spec 状态或评估风险与测试安排时，按入口指定章节读取。计划约束归 pages.json；实际接口、执行证据与验收由调用方维护。
 
 ## 跨 Spec 共享状态
 
@@ -44,18 +22,14 @@ behavior_notes 非空；其余三个数组必须存在，无适用内容经核
 
 producer 提供指定 capability，每个 consumer 必须 requires 它；checks 包含每个参与 Spec 的实际检查，不得越界。channel/payload/initialization/lifecycle 缺失时参与者不能开工。登录和首页 UI 都存在不能证明状态已传递；必须明确谁写、谁读、何时生效及失效，并用消费者断言覆盖状态变化。
 
-## 真实接口交接
-
-提供者实现并形成当前候选后，主 Agent 阅读代码核对实际导出符号、参数/返回及错误语义，以 interface 事件记录代码文件及哈希、symbols、summary、reviewer。运行时确认由调用方按公共 `d2h workflow contract execution` 执行；本 Skill 不记录事件。这不是预先编造的签名，也不是运行证据。提供者只有接口回执有效、当前构建和即时契约测试有效，才解锁消费者。
-
-candidate 或接口文件变化、failed/invalidate/repair 会撤销接口有效性。context 不交接过期接口；共享契约或工作包语义通过 reconcile 修订并重置相关成员，保留历史。程序检查文件身份，不解析符号真实性或证明实际调用关系，主 Agent 负责语义核验。
-
 ## 分层验证与定向修复
 
-分层是选择验证成本的计划，不改变通过标准。当前正式 test evidence 仍只支持受管 Python 设备执行；静态检查、算法向量和服务探针可前置发现问题，但尚无 CLI 证据适配，不能用于正式 PASS。鉴权、启动、共享契约和其他高风险行为仍即时验证，低风险成员按窗口合批。
+逐 Spec 根据失败影响、共享范围、实现不确定性及下游依赖评估风险，引用源码、架构或已有缺陷作为依据，不按代码量或 Spec 大小直接判断是否需要测试。
 
-只修复并重跑失败的准备步骤，避免重新提取已完成需求；同一候选可共享构建安装和真实结果。主 Agent 对高风险且缺证据的行为优先检查反例，如失效令牌、重复提交、返回后状态丢失，不为每项重复启动多轮主观评审。候选变化仍保守撤销旧验证，影响范围复用需后续 CLI 协同。
+- 高风险：涉及鉴权、数据丢失、启动主路径、共享契约，或失败会阻断下游能力时，安排专项测试，覆盖关键成功、失败及状态变化；在依赖方使用前验证相关契约。
+- 一般风险：新增或改变可观察行为时，安排对应行为测试；互不阻塞的检查可在批次结束时合并执行，保留逐 Spec 的验收对应关系。
+- 低风险：仅文案、样式或不改变行为的局部调整，且无共享影响时，可不新增专项自动化测试；说明理由，安排适用的静态检查、人工核验或已有测试回归，仍须核对验收目标。已有测试覆盖需指明用例及适用范围，不能把历史通过当作本次结果。
 
-## 与完整 Spec 的关系
+计划记录风险依据、是否新增测试、验证方式、关键检查、执行时机和必要准备；缺少环境或证据时保留未决，不以低风险代替验证。详细规格或实现证据改变风险判断时局部复评，实际执行与验收由主 Agent 组织，已有明确测试要求不因风险分级而取消。
 
-implementation_brief 是结构化计划/派发摘要，不替代详细行为、操作、证据与逐 check 断言。规划先提供已核验的概要及缺口；生成方按公共 `d2h workflow contract generation` 展开正文，缺少实施字段时提出修订建议。新策略额外核对逐成员生成绑定，但 readiness_gaps 仍不验证 Markdown 语义；AI/人工须审查。worker 根据固定 spec_id 补读详细文档，不根据摘要猜测。
+分层是选择验证成本的计划，不改变通过标准。按检查目的选择静态、逻辑、集成或设备验证；涉及真实平台行为时保留必要设备验证，不能用静态检查替代。高风险反例可包括失效令牌、重复提交或返回后状态丢失；共同准备和测试执行可以复用，验收仍逐 Spec 对应。

package/skills/managing-d2h-toolchain/environment-requirements.json

@@ -8,7 +8,7 @@
     "java": null,
     "python-json5": null,
     "appgraph": { "minimum": "0.0.11", "maximumExclusive": "0.0.12" },
-    "droid2hmos": { "minimum": "0.0.17", "maximumExclusive": "0.0.18" },
+    "droid2hmos": { "minimum": "0.0.18", "maximumExclusive": "0.0.19" },
     "hvigor": null,
     "ohpm": null,
     "devecocli": null

package/skills/managing-d2h-toolchain/toolchain.json

@@ -9,7 +9,7 @@
     },
     "droid2hmos": {
       "package": "@harmonyos-arkts/droid2hmos",
-      "version": "0.0.17",
+      "version": "0.0.18",
       "capabilities": { "analyze-android": ["--help"], "preflight": ["--help"], "status": ["--help"] }
     }
   }

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

@@ -1,7 +0,0 @@
-interface:
-  display_name: "HarmonyOS Spec Development Loop"
-  short_description: "按 spec.md 完成单页面受管开发、测试与提交闭环"
-  default_prompt: "Use $d2h-spec-develop to serially implement ordered HarmonyOS page tasks from pages.json, batch_report.json, and spec.md in the current agent without delegating page work to subagents."
-
-policy:
-  allow_implicit_invocation: true

package/skills/d2h-spec-develop/references/worker-workflow.md

@@ -1,26 +0,0 @@
-# Spec 实施与结果交接
-
-只处理输入明确指派的 Spec。先核对计划/范围版本、Git 基线、允许路径和成员；存在冲突时返回具体缺口，不覆盖用户修改。派发数据字段见公共 `d2h workflow contract dispatch`，本 Skill 不要求任何规划技能先运行。
-
-## 理解与实施
-
-1. 阅读页面 spec.md 中当前 spec_id/check 的完整行为、异常、操作、源码依据与实现范围，定向追踪 Android 入口、状态、数据副作用和导航。页面共享摘要用于定位，不能代替源码理解。
-2. 沿用已给定的目标模块、目录、资源规范和状态/生命周期边界。接口缺失、所有权不清或与实际代码冲突时，返回带源码定位的 requiredInputs / planChangeRequests，不自行改方案或扩大范围。
-3. 同一窗口沿用页面上下文，逐成员实施。提供者形成实际代码后返回真实符号、路径、参数/错误语义与生命周期说明，等待调用方确认当前能力再实施消费者；不能用规划签名猜接口。
-4. 实现真实可达的 UI、导航、业务状态、数据效果和要求的失败路径。每个 check 对应实际行为、稳定语义定位和结果断言；不得添加测试替代控件、固定成功值、吞错或不可达页面。
-5. 当前范围涉及平台 API、原生库、身份/资源/i18n 等未知问题时，返回领域请求：问题、来源、当前尝试、所需结论及消费者。调用方提供结论后继续，不在此加载其他技能。
-
-## 构建、检查与提交
-
-- 依据输入项目配置运行已授权的 `droid2hmos build harmony <ANDROID_PROJECT>`，命令非交互且有超时，保留真实命令、退出状态、时间、日志、HAP 路径和哈希。
-- 已提供可执行测试资产且授权本次检查时，可直接运行受管 CLI，保留实际断言、设备、执行数、原始报告和 managedEvidence。缺少测试设计、资产、设备或需共享安装窗口时返回 verificationRequests，不能只写测试未跑却报告通过。
-- 即时契约和高风险检查必须有实际结果，缺口交调用方组织验证；低风险合批待测明确列出，不暗示已验收。静态检查/服务探针不能代替正式设备证据。
-- 修复本范围实现或检查缺陷，保留现有理解与原始失败证据。真实外部问题在诊断和有限重试后可返回 blocked；实现错误不能改写为平台差异。
-- 仅暂存当前实现、资源、必要共享修改和实际测试资产。构建及已要求的即时检查通过后创建或交回作用域提交；允许明确标注待合批验证的实现提交，不把它称为验收提交。残留本任务修改、用户文件及其他任务修改分别列明，不一并提交。
-- 实现提交与后续状态/证据记录分开，由调用方维护后者，避免提交 ID 自引用。当前候选变化后的旧 HAP/证据是否失效由公共运行时维护，不把旧结果绑定新代码。
-
-## 返回
-
-逐 spec_id/check 返回：实际修改与可达行为、接口与消费者、提交/源码身份、构建和测试证据、未执行检查与原因、剩余缺口、请求及用户修改保留情况。耗时未知填 null，不编造节省比例。
-
-不选择下一个批次，不更新执行账本、阶段状态或任何报告。调用方独立核对实现、断言、当前候选、HAP 和设备身份后记录状态与决定验收。

package/skills/d2h-spec-plan/references/architecture-handoff.md

@@ -1,9 +0,0 @@
-# 目标工程与架构上下文
-
-接收的是已给定的目标工程、模块/目录所有权、共享边界、关键链和风险，不要求该输入来自特定架构技能或特定回执文件。源码、现有工程、用户提供的结构、已确认方案均可作为来源；调用方在完整迁移中负责核对授权和来源新鲜度。
-
-把当前 Spec 的实际实现位置写入 allocation.owned_paths，页面共享背景引用归属、共享接口与风险依据。一个模块可以承接多个 Spec，模块依赖不能机械转换成 requires/provides。
-
-功能来源通过稳定 feature_id/scope_id 与来源引用关联，inventory 的数组位置或架构候选页名不是业务身份。UTG page.json 提供节点可达性和到达/采集依据，不等于最终业务页面清单。
-
-目标路径、所有权或必需共享契约缺失时返回 requiredInputs / unresolved；独立请求可以先形成带缺口的草案，不能假造确认或宣称可开工。架构边界变化返回受影响 Spec 和最小调整建议，由调用方决定修订与重新派发。