@harmonyos-arkts/d2h 0.1.22 → 0.1.27

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

@@ -1,46 +1,22 @@
-# 增量范围、页面轮次与评估方法
-
-创建计划或因新依赖、范围/归拢变化修订语义时读取本参考。仅执行状态更新不重做规划。写入机器可读计划时读取 [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；迁移报告和既有实现只提供线索，不能证明当前通过。
+# 里程碑与波次规划方法
 
 ## 规划工作
 
-1. 消费调用方提供的稳定功能/范围项及来源映射，不把 P0/P1/P2 当用户优先级或交付层。校验功能计划，读取当前阶段全部功能及用户顺序。功能的新增、排除、阶段和优先级由调用方维护，本技能不能静默修改。用户指定 MVP/核心/全量或局部范围时读取公共 `d2h workflow contract delivery`，先核对 delivery 与 scope_items 实际授权，不从优先级或轮次名称推断选用层。
-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. AI 根据同页、状态/组件/文件耦合和测试准备复用决定 page_batches，写 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 交调用方。计划刷新后重新确定生成选择；不因用户改波次就重建已完成身份。需要执行账本、报告、详细规格或在途处置时交调用方处理。
-
-## 详细规格交接
-
-公共契约见 `d2h workflow contract generation`。已有有效详细 Spec 可复用；当前轮次只生成新增或受影响成员，远期保留验收概要。生成方消费选定计划，不重新排序、不修改范围、不初始化旧页面账本。发现来源、依赖或共享接口问题时向调用方返回修订请求，不直接调用规划能力。
-
-原生依赖先核对 Facts 的 native-libs.json，再以源码 JNI 入口、System.loadLibrary、CMake/ndk-build 和实际 .so/.a 证据复核。存在 C/C++ 依赖时返回原生依赖 domainRequests，记录源码重编/patch、JNI→NAPI 或闭源替代处置，明确负责 Spec 和共享能力消费者；Facts 未检出不能代替源码核验，缺失库或降级进入未决项，不静默丢弃。
+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。
 
-涉及平台能力或不确定 @kit/@ohos API 时返回 knowledgeRequests，列出待查 API、当前证据与期望结论，收到文档 title/uri 后引用到增量。不能从页面名称猜行为、从 source-derived 路径声称运行验证，或从已有代码自动推导完成。
+## 生成后绑定与复核
 
-已有基础 Spec 验收后，后续完善读取原页面和功能剩余 scope_items，新增增量 Spec；不得将基础 Spec 扩成不断变化的整页任务。完整规则见 [plan-contract.md](plan-contract.md) 的“逐项范围映射与完成语义”。
+功能级草案在规格生成流程完成后绑定实际 page_id、order、package 和任务 ID。核对任务覆盖、计划排序和依赖，并记录不能在完整页面单位下满足的细粒度目标；不要求生成方消费新计划或更改正文布局。
 
+页面计划或规格变化时，复核受影响波次，保留未变化的身份和历史。修订里程碑与波次不会使已有页面规格重新生成；出现来源或行为错误时返回对应流程处理，不用新哈希覆盖旧关联来伪装有效。
 
-## 控制 Spec 粒度与重复分析
+## 已有产物复核与缺口修订
 
-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，不以渐进细化掩盖遗漏。
-- 计划给出页面共享上下文的证据与所有权；详细正文由生成方按固定范围展开。摘要与结构校验不证明当前运行通过。
+用户禁止分析或开发时只使用已有有效输入，记录缺口，不调用分析、构建、测试或开发能力。结构检查和文档存在都不证明页面已实现或波次已完成。

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

@@ -0,0 +1,23 @@
+# 规划交付与评审记录
+
+首次交付、生成后绑定、排期修订或事后评估时读取。页面范围、正文和开发验收仍以规格生成或页面开发流程产物为准。
+
+## 独立分析产物目录
+
+里程碑与波次保存在 batch_report.json.planning，旧版本追加到 planning_history；`<migration_root>/.migration/spec-planning/` 的 analysis.md 保存当前分析，planning-review.md 按带时区评审时间追加记录。调用方显式指定其他迁移产物目录时沿用实际路径，不写入 Skill 安装目录或应用源码目录。
+
+analysis.md 记录用户目标、已确认范围与架构、输入路径/版本/字节哈希、页面到里程碑/波次的映射、计划顺序及前置核对、取舍、成本风险、未决项和实际检查结果。draft 明确待绑定范围，不能声称已安排真实页面任务。
+
+## 首次交付与绑定
+
+交付账本 planning 更新及分析，返回账本绝对路径、planning revision/hash、来源版本、纳入任务和未决项。生成完成后核对真实页面任务再绑定；保持规格、目录及账本任务身份，单独记录执行排序依据，不能只在对话交付结论。
+
+## 变更复评
+
+修订前将旧 planning 完整追加到账本 planning_history，analysis.md 及来源引用保存到 history/<带时区评审时间>-<唯一标识>/，或引用可定位的 Git 版本。记录触发证据、变化及保留的成员、新旧版本、对已生成页面和实际在途工作的影响；无实质变化只追加复核结论。
+
+旧增量 Spec 计划保留为历史来源，不自动改写其身份或执行记录。已有旧目录评审时保留并引用，不覆盖或删除。目录不可写或输入不完整时明确失败原因，不宣称落盘完成。
+
+## 事后评估
+
+只读取已有页面账本及实际实施、验证、返工和等待证据，比较阶段安排与真实结果。区分排期问题、页面实现问题和外部影响；无实测对照不编造收益。结论更新分析并追加评审，需要调整后续排期时再显式修订账本 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 与用户待办作为线索，不能替换用户优先级、授权或运行证据。
-
-旧计划无 delivery 或未接新分析报告时，保留可验证的既有用户选择并说明限制；无明确用户选择时交上游建立默认核心范围，不把旧 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. 用户调整范围、交付目标、优先级或顺序；先由功能清单技能修订上游。
-2. 新源码/平台证据表明原行为不可行、能力提供者需更换或最小依赖闭包变化。
-3. SDK/SO、App ID、权限/签名配置、设备或测试资源缺口，使本轮目标无法按原条件验收。
-4. 实际实现、返工、测试或等待已使原预算/截止验证点失效，或已交付轮次出现影响后续目标的回归。
+默认先考虑真实基础可用路径，无登录项目按实际入口组织。功能级草案不改变页面边界；生成时的页面顺序只是排序参考；正式波次只能引用完整页面任务。
 
-先记录触发证据、受影响范围/Spec/轮次及当前固定版本，判断能否在原契约内修复。仅需正常修复或补证据时继续原计划；只有规划语义变化才修订。复评可以明确“保持原计划”，此时不为记录一次评估而虚增 revision 或重置执行。
+## 记录与复评
 
-需要修订时返回 changes 与缺口；调用方按公共执行契约处理归档、在途任务/窗口及 reconcile。保留已验收 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,61 +1,13 @@
-# 自足工作包、共享状态与实际接口
+# 共享状态与验证安排
 
-创建或细化当前轮次、处理开工缺口、设计跨 Spec 状态流时读取。计划字段归 pages.json；接口回执归 execution.json。context 裁剪输出，不另建可编辑工单真源。
+## 跨页面依赖
 
-## 开工就绪
+读取已有页面规格及架构中的共享所有者、数据通道、初始化和生命周期，以此解释波次前置。共享基础仍归规格生成流程确定的页面负责，不另建共享能力 Spec、检查 ID 或 requires/provides 协议。
 
-新计划使用 `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 阻止相关成员进入窗口，不能夹带进同页批次。
+保留逐页实现、managed build、Hypium 测试、报告与提交闭环。阶段结束只核对页面验收结果及用户目标，不将本应即时执行的页面检查延到波次末尾。
 
-工作包复用 scope、evidence_refs、owned_paths、requires/provides 和 checks。AI 按任务补齐 UI 入口与路由参数、数据表/键/副作用、逻辑模块及目标文件；纯后台/算法能力不虚构页面。源码仍是行为细节依据，摘要用于定位与交接。远期延期需求不提前写大工单。
-
-## 跨 Spec 共享状态
-
-仅在多个 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 都存在不能证明状态已传递；必须明确谁写、谁读、何时生效及失效，并用消费者断言覆盖状态变化。
-
-## 真实接口交接
-
-提供者实现并形成当前候选后，主 Agent 阅读代码核对实际导出符号、参数/返回及错误语义，以 interface 事件记录代码文件及哈希、symbols、summary、reviewer。运行时确认由调用方按公共 `d2h workflow contract execution` 执行；本 Skill 不记录事件。这不是预先编造的签名，也不是运行证据。提供者只有接口回执有效、当前构建和即时契约测试有效，才解锁消费者。
-
-candidate 或接口文件变化、failed/invalidate/repair 会撤销接口有效性。context 不交接过期接口；共享契约或工作包语义通过 reconcile 修订并重置相关成员，保留历史。程序检查文件身份，不解析符号真实性或证明实际调用关系，主 Agent 负责语义核验。
-
-## 分层验证与定向修复
-
-分层是选择验证成本的计划，不改变通过标准。当前正式 test evidence 仍只支持受管 Python 设备执行；静态检查、算法向量和服务探针可前置发现问题，但尚无 CLI 证据适配，不能用于正式 PASS。鉴权、启动、共享契约和其他高风险行为仍即时验证，低风险成员按窗口合批。
-
-只修复并重跑失败的准备步骤，避免重新提取已完成需求；同一候选可共享构建安装和真实结果。主 Agent 对高风险且缺证据的行为优先检查反例，如失效令牌、重复提交、返回后状态丢失，不为每项重复启动多轮主观评审。候选变化仍保守撤销旧验证，影响范围复用需后续 CLI 协同。
-
-## 与完整 Spec 的关系
-
-implementation_brief 是结构化计划/派发摘要，不替代详细行为、操作、证据与逐 check 断言。规划先提供已核验的概要及缺口；生成方按公共 `d2h workflow contract generation` 展开正文，缺少实施字段时提出修订建议。新策略额外核对逐成员生成绑定，但 readiness_gaps 仍不验证 Markdown 语义；AI/人工须审查。worker 根据固定 spec_id 补读详细文档，不根据摘要猜测。
+高风险、平台差异和测试准备记录在排期依据中，不能减免规格要求，也不能因里程碑需要而新增另一套执行门禁。历史 PASS、静态校验或页面存在不能代替当前实现和设备证据。

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 完成鸿蒙实现、受管构建检查、作用域提交与证据交接"
-  default_prompt: "Use $d2h-spec-develop to implement the assigned HarmonyOS Specs and return scoped code, build and test evidence, commits, and unresolved requests."
-
-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 和最小调整建议，由调用方决定修订与重新派发。