@harmonyos-arkts/d2h 0.1.11 → 0.1.13

package/skills/maintaining-migration-report/SKILL.md

@@ -1,144 +1,144 @@
----
-name: maintaining-migration-report
-description: Maintain and validate the lightweight fact-linked Android-to-HarmonyOS migration ledger while implementation evidence is fresh. Record implementation files, Android source provenance, managed evidence, differences, discoveries, summary, and final-acceptance data without scheduling tests, regression, checkpoints, rendering, or completion.
----
-
-# Maintain the migration ledger
-
-The migration report is a verifiable ledger linked to deterministic facts, Android source, HarmonyOS implementation files, and managed evidence. It is not the authority for application behavior: current Android source and observable behavior remain authoritative, and Kernel validation remains authoritative for machine gates.
-
-All `.migration/...` paths below live in the sibling migration workspace `<android-project>-migration/.migration/` created by the CLI, never inside the Android project.
-
-## Scope and inputs
-
-This Skill owns only:
-
-- `report init`, `report update`, and `report validate`;
-- recording analyzer omissions in `discoveries.json`;
-- maintaining `summary.json`;
-- writing `final-acceptance.json` from test results and managed evidence supplied by the caller.
-
-For an update, accept the Android project root, report ref, requested status, real HarmonyOS implementation files, current Android source files, managed evidence paths, and any real difference or blocker. When the caller has a current Task/epoch, also accept its identifier and source closure so provenance can be reconciled with the exact implementation unit. Never replace these inputs with a prose summary.
-
-Read [references/source-provenance.md](references/source-provenance.md) whenever an item becomes `implemented` or `verified`. Read [references/final-acceptance.md](references/final-acceptance.md) when maintaining final acceptance.
-
-## Invariants
-
-- Treat `.migration/spec/facts/` and `.migration/spec/index.json` as immutable analyzer output. Never edit them to make validation pass.
-- The JSON files under `.migration/report/` are lightweight overlays. Preserve stable refs, fact labels, and control-entry ownership generated by the CLI.
-- Do not edit `.migration/report/index.json` or `validation.json`; host scripts own indexes, hashes, counts, and validation output.
-- A mapping must name the concrete HarmonyOS file and symbol that performs the behavior. Imports, comments, ref strings, registries without executable wiring, generated hashes, stubs, and test-only symbols are not implementations.
-- Compilation alone does not prove that a page, control, handler, navigation path, Dialog, or business function works.
-- `implemented` and `verified` items require current Android `sourceProvenance`; a prose description or stale hash is insufficient.
-- `verified` and passed final-acceptance tests require fresh Kernel-managed evidence. Never hand-write, copy, or modify receipts or archived artifacts.
-- A receipt supports a ref only when `scope.coveredRefs` contains it, the structured result has a non-zero execution count with zero failures, errors, and ignored cases, the target matches, and archived artifacts pass integrity checks.
-
-## Initialize and select work
-
-Run once when no report exists:
-
-```text
-droid2hmos report init <android-project>
-```
-
-Start from `.migration/report/index.json`. Select only the shards relevant to the caller's current implementation or review. Follow each shard's `factsFile`, then read the Android source named by the fact and current source closure. Read additional Android source when facts are ambiguous or may omit behavior.
-
-## Update one item
-
-Update while implementation and source context are fresh. Preserve `ref`, `kind`, `factLabel`, and `controlRef`. Maintain only:
-
-- `status`: `pending`, `implemented`, `verified`, or `blocked`;
-- `harmonyosFiles[]`: project-relative files containing reachable implementation;
-- `sourceProvenance[]`: current Android files and CLI-computed hashes;
-- `testEvidence[]`: managed evidence whose `scope.coveredRefs` contains the ref;
-- `difference`: `null` unless a real behavior difference or blocker exists.
-
-Use the safe update interface:
-
-```text
-droid2hmos report update <android-project> --ref <ref> [--status <status>] [--harmony-file <path>...] [--android-source <path>...] [--evidence <path>...] [--difference <text>|--clear-difference]
-```
-
-The command must resolve exactly one existing ref and validates project files and source membership before writing. Use `--android-source` for every Android file that informed the implementation. If a current Task/epoch source closure exists, reconcile it before update; a closure member that affects the behavior but is absent from `sourceProvenance` is unresolved, not silently ignored.
-
-Use statuses strictly:
-
-- `pending`: not implemented;
-- `implemented`: reachable implementation and source provenance exist, but item-specific runtime verification is incomplete;
-- `verified`: implementation, provenance, and relevant managed evidence all exist and validate;
-- `blocked`: implementation or verification is impossible for the concrete reason in `difference`.
-
-If evidence is missing or invalid, keep the item at `implemented` (or `blocked` when appropriate) and return a verification request. Do not run a targeted test or full regression from this Skill.
-
-## Record analyzer omissions
-
-When Android source proves that deterministic facts missed a page, control, entry, interaction, or business feature, append a semantic record to `.migration/report/discoveries.json`. Include a unique `discovered.*` ref, kind, concise label, Android source evidence, implementation files, status, test evidence, and optional difference. Do not inject it into immutable facts.
-
-Validate immediately after changing discoveries. A discovery is not automatically verified merely because its file exists.
-
-## Maintain final acceptance
-
-Only write final-acceptance results supplied by the caller from a real managed test run. Follow [references/final-acceptance.md](references/final-acceptance.md). This Skill checks schema, stable refs, `coveredRefs`, receipt freshness and integrity, and consistency between test status and blockers.
-
-It does not decide when application-wide regression should run, choose or expand its scope, execute the suite, or decide whether the workflow may advance.
-
-## Maintain the user summary
-
-`summary.json` is the only free-form user summary. Keep it concise and limited to:
-
-- `summary`: what has been migrated and what the validated evidence supports;
-- `incomplete`: remaining behavior, why it remains, and user impact;
-- `nextSteps`: concrete work still required;
-- optional `additionalSections` for meaningful platform differences, risks, or usage notes.
-
-Before updating the summary, run `report validate` and read `.migration/report/validation.json`. The prose must agree with that machine result:
-
-- if validation says the ledger is incomplete or final acceptance is not passed, describe it as partial/incomplete;
-- do not relabel pending or blocked behavior as harmless without a recorded decision;
-- do not duplicate calculated counts, mappings, test inventories, or blocker lists owned by the renderer;
-- do not add fields outside the current summary or final-acceptance schemas.
-
-## Validate and return
-
-After every semantic update, run:
-
-```text
-droid2hmos report validate <android-project>
-```
-
-Return the validation result without converting failure into success. `valid: true, complete: false` is acceptable during migration and does not authorize a completion claim.
-
-Return a structured result:
-
-```json
-{
-  "status": "completed | partial | failed",
-  "changedFiles": [],
-  "sourceFiles": [],
-  "evidence": [],
-  "domainChecks": [],
-  "unresolved": [],
-  "verificationRequests": [],
-  "suggestedRemediation": [],
-  "details": {
-    "updatedRefs": [],
-    "validation": {},
-    "taskId": null,
-    "epochId": null
-  }
-}
-```
-
-`status` describes ledger maintenance only. It does not mean regression passed or migration completed. Missing provenance, invalid receipts, closure mismatches, schema failures, and report gaps belong in `unresolved`; requested test or review work belongs in `verificationRequests`.
-
-## Boundaries
-
-This Skill never:
-
-- decides when targeted tests or full regression run;
-- calls `droid2hmos test`, `checkpoint create`, `complete`, or `report render`;
-- changes test scope or marks a failed, ignored, zero-execution, stale, or damaged result as passed;
-- decides an outer workflow state or announces migration completion;
-- uses report field completeness to override Android source, observable behavior, or Kernel denial.
-
-The caller owns workflow transitions, test execution, checkpoint timing, completion gates, visual/business judgment, and final report delivery.
+---
+name: maintaining-migration-report
+description: Maintain and validate the lightweight fact-linked Android-to-HarmonyOS migration ledger while implementation evidence is fresh. Record implementation files, Android source provenance, managed evidence, differences, discoveries, summary, and final-acceptance data without scheduling tests, regression, checkpoints, rendering, or completion.
+---
+
+# Maintain the migration ledger
+
+The migration report is a verifiable ledger linked to deterministic facts, Android source, HarmonyOS implementation files, and managed evidence. It is not the authority for application behavior: current Android source and observable behavior remain authoritative, and Kernel validation remains authoritative for machine gates.
+
+All `.migration/...` paths below live in the sibling migration workspace `<android-project>-migration/.migration/` created by the CLI, never inside the Android project.
+
+## Scope and inputs
+
+This Skill owns only:
+
+- `report init`, `report update`, and `report validate`;
+- recording analyzer omissions in `discoveries.json`;
+- maintaining `summary.json`;
+- writing `final-acceptance.json` from test results and managed evidence supplied by the caller.
+
+For an update, accept the Android project root, report ref, requested status, real HarmonyOS implementation files, current Android source files, managed evidence paths, and any real difference or blocker. When the caller has a current Task/epoch, also accept its identifier and source closure so provenance can be reconciled with the exact implementation unit. Never replace these inputs with a prose summary.
+
+Read [references/source-provenance.md](references/source-provenance.md) whenever an item becomes `implemented` or `verified`. Read [references/final-acceptance.md](references/final-acceptance.md) when maintaining final acceptance.
+
+## Invariants
+
+- Treat `.migration/spec/facts/` and `.migration/spec/index.json` as immutable analyzer output. Never edit them to make validation pass.
+- The JSON files under `.migration/report/` are lightweight overlays. Preserve stable refs, fact labels, and control-entry ownership generated by the CLI.
+- Do not edit `.migration/report/index.json` or `validation.json`; host scripts own indexes, hashes, counts, and validation output.
+- A mapping must name the concrete HarmonyOS file and symbol that performs the behavior. Imports, comments, ref strings, registries without executable wiring, generated hashes, stubs, and test-only symbols are not implementations.
+- Compilation alone does not prove that a page, control, handler, navigation path, Dialog, or business function works.
+- `implemented` and `verified` items require current Android `sourceProvenance`; a prose description or stale hash is insufficient.
+- `verified` and passed final-acceptance tests require fresh Kernel-managed evidence. Never hand-write, copy, or modify receipts or archived artifacts.
+- A receipt supports a ref only when `scope.coveredRefs` contains it, the structured result has a non-zero execution count with zero failures, errors, and ignored cases, the target matches, and archived artifacts pass integrity checks.
+
+## Initialize and select work
+
+Run once when no report exists:
+
+```text
+droid2hmos report init <android-project>
+```
+
+Start from `.migration/report/index.json`. Select only the shards relevant to the caller's current implementation or review. Follow each shard's `factsFile`, then read the Android source named by the fact and current source closure. Read additional Android source when facts are ambiguous or may omit behavior.
+
+## Update one item
+
+Update while implementation and source context are fresh. Preserve `ref`, `kind`, `factLabel`, and `controlRef`. Maintain only:
+
+- `status`: `pending`, `implemented`, `verified`, or `blocked`;
+- `harmonyosFiles[]`: project-relative files containing reachable implementation;
+- `sourceProvenance[]`: current Android files and CLI-computed hashes;
+- `testEvidence[]`: managed evidence whose `scope.coveredRefs` contains the ref;
+- `difference`: `null` unless a real behavior difference or blocker exists.
+
+Use the safe update interface:
+
+```text
+droid2hmos report update <android-project> --ref <ref> [--status <status>] [--harmony-file <path>...] [--android-source <path>...] [--evidence <path>...] [--difference <text>|--clear-difference]
+```
+
+The command must resolve exactly one existing ref and validates project files and source membership before writing. Use `--android-source` for every Android file that informed the implementation. If a current Task/epoch source closure exists, reconcile it before update; a closure member that affects the behavior but is absent from `sourceProvenance` is unresolved, not silently ignored.
+
+Use statuses strictly:
+
+- `pending`: not implemented;
+- `implemented`: reachable implementation and source provenance exist, but item-specific runtime verification is incomplete;
+- `verified`: implementation, provenance, and relevant managed evidence all exist and validate;
+- `blocked`: implementation or verification is impossible for the concrete reason in `difference`.
+
+If evidence is missing or invalid, keep the item at `implemented` (or `blocked` when appropriate) and return a verification request. Do not run a targeted test or full regression from this Skill.
+
+## Record analyzer omissions
+
+When Android source proves that deterministic facts missed a page, control, entry, interaction, or business feature, append a semantic record to `.migration/report/discoveries.json`. Include a unique `discovered.*` ref, kind, concise label, Android source evidence, implementation files, status, test evidence, and optional difference. Do not inject it into immutable facts.
+
+Validate immediately after changing discoveries. A discovery is not automatically verified merely because its file exists.
+
+## Maintain final acceptance
+
+Only write final-acceptance results supplied by the caller from a real managed test run. Follow [references/final-acceptance.md](references/final-acceptance.md). This Skill checks schema, stable refs, `coveredRefs`, receipt freshness and integrity, and consistency between test status and blockers.
+
+It does not decide when application-wide regression should run, choose or expand its scope, execute the suite, or decide whether the workflow may advance.
+
+## Maintain the user summary
+
+`summary.json` is the only free-form user summary. Keep it concise and limited to:
+
+- `summary`: what has been migrated and what the validated evidence supports;
+- `incomplete`: remaining behavior, why it remains, and user impact;
+- `nextSteps`: concrete work still required;
+- optional `additionalSections` for meaningful platform differences, risks, or usage notes.
+
+Before updating the summary, run `report validate` and read `.migration/report/validation.json`. The prose must agree with that machine result:
+
+- if validation says the ledger is incomplete or final acceptance is not passed, describe it as partial/incomplete;
+- do not relabel pending or blocked behavior as harmless without a recorded decision;
+- do not duplicate calculated counts, mappings, test inventories, or blocker lists owned by the renderer;
+- do not add fields outside the current summary or final-acceptance schemas.
+
+## Validate and return
+
+After every semantic update, run:
+
+```text
+droid2hmos report validate <android-project>
+```
+
+Return the validation result without converting failure into success. `valid: true, complete: false` is acceptable during migration and does not authorize a completion claim.
+
+Return a structured result:
+
+```json
+{
+  "status": "completed | partial | failed",
+  "changedFiles": [],
+  "sourceFiles": [],
+  "evidence": [],
+  "domainChecks": [],
+  "unresolved": [],
+  "verificationRequests": [],
+  "suggestedRemediation": [],
+  "details": {
+    "updatedRefs": [],
+    "validation": {},
+    "taskId": null,
+    "epochId": null
+  }
+}
+```
+
+`status` describes ledger maintenance only. It does not mean regression passed or migration completed. Missing provenance, invalid receipts, closure mismatches, schema failures, and report gaps belong in `unresolved`; requested test or review work belongs in `verificationRequests`.
+
+## Boundaries
+
+This Skill never:
+
+- decides when targeted tests or full regression run;
+- calls `droid2hmos test`, `checkpoint create`, `complete`, or `report render`;
+- changes test scope or marks a failed, ignored, zero-execution, stale, or damaged result as passed;
+- decides an outer workflow state or announces migration completion;
+- uses report field completeness to override Android source, observable behavior, or Kernel denial.
+
+The caller owns workflow transitions, test execution, checkpoint timing, completion gates, visual/business judgment, and final report delivery.

package/skills/maintaining-migration-report/references/final-acceptance.md

@@ -1,48 +1,48 @@
-# Final acceptance ledger contract
-
-`final-acceptance.json` records application-wide test results already produced by the caller. It does not schedule regression and does not decide that migration is complete.
-
-## Required shape
-
-```json
-{
-  "reportShardVersion": "1.2.0",
-  "kind": "final-acceptance",
-  "status": "pending | passed | failed",
-  "tests": [
-    {
-      "ref": "acceptance.create-note-from-launcher",
-      "name": "从启动页进入首页并完成新增笔记",
-      "status": "passed | failed",
-      "evidence": [".migration/evidence/managed/test-harmony-all-<fingerprint>.json"]
-    }
-  ],
-  "blockers": [],
-  "notes": []
-}
-```
-
-Only these fields are allowed by `schemas/final-acceptance.schema.json`. `blockers` and `notes` are concise strings; do not add run IDs, commit hashes, nested blocker objects, or legacy aliases.
-
-## Inputs from the caller
-
-The caller supplies:
-
-- the managed receipt from the application-wide suite it chose to run;
-- the exact stable refs actually asserted by that suite;
-- the structured execution totals and target device;
-- any failed scenarios or external blockers;
-- concise notes supported by observation.
-
-Do not add every report ref to make coverage appear complete. A receipt may support only refs in its actual `scope.coveredRefs`.
-
-## Recording rules
-
-- Each test has a stable, unique, non-empty `ref` and a user-readable `name`.
-- A `passed` test has at least one fresh managed receipt whose `scope.coveredRefs` contains that exact ref.
-- The structured result must report a non-zero execution count and zero failures, errors, and ignored cases.
-- The receipt must match current HarmonyOS source, facts and target device, and every archived artifact must pass size and SHA-256 checks.
-- `status: passed` is invalid when tests are empty, any test failed, evidence is stale or damaged, coverage is absent, or blockers remain.
-- When evidence is missing or invalid, record `pending` or `failed` according to observed results and return the gap; never synthesize a pass.
-
-After writing, run `droid2hmos report validate <android-project>` and return its result unchanged. The caller, not this Skill, decides workflow state, runs any additional regression, invokes completion gates, and renders or delivers the final report.
+# Final acceptance ledger contract
+
+`final-acceptance.json` records application-wide test results already produced by the caller. It does not schedule regression and does not decide that migration is complete.
+
+## Required shape
+
+```json
+{
+  "reportShardVersion": "1.2.0",
+  "kind": "final-acceptance",
+  "status": "pending | passed | failed",
+  "tests": [
+    {
+      "ref": "acceptance.create-note-from-launcher",
+      "name": "从启动页进入首页并完成新增笔记",
+      "status": "passed | failed",
+      "evidence": [".migration/evidence/managed/test-harmony-all-<fingerprint>.json"]
+    }
+  ],
+  "blockers": [],
+  "notes": []
+}
+```
+
+Only these fields are allowed by `schemas/final-acceptance.schema.json`. `blockers` and `notes` are concise strings; do not add run IDs, commit hashes, nested blocker objects, or legacy aliases.
+
+## Inputs from the caller
+
+The caller supplies:
+
+- the managed receipt from the application-wide suite it chose to run;
+- the exact stable refs actually asserted by that suite;
+- the structured execution totals and target device;
+- any failed scenarios or external blockers;
+- concise notes supported by observation.
+
+Do not add every report ref to make coverage appear complete. A receipt may support only refs in its actual `scope.coveredRefs`.
+
+## Recording rules
+
+- Each test has a stable, unique, non-empty `ref` and a user-readable `name`.
+- A `passed` test has at least one fresh managed receipt whose `scope.coveredRefs` contains that exact ref.
+- The structured result must report a non-zero execution count and zero failures, errors, and ignored cases.
+- The receipt must match current HarmonyOS source, facts and target device, and every archived artifact must pass size and SHA-256 checks.
+- `status: passed` is invalid when tests are empty, any test failed, evidence is stale or damaged, coverage is absent, or blockers remain.
+- When evidence is missing or invalid, record `pending` or `failed` according to observed results and return the gap; never synthesize a pass.
+
+After writing, run `droid2hmos report validate <android-project>` and return its result unchanged. The caller, not this Skill, decides workflow state, runs any additional regression, invokes completion gates, and renders or delivers the final report.

package/skills/maintaining-migration-report/references/source-provenance.md

@@ -1,66 +1,66 @@
-# Android source provenance
-
-Use this contract whenever a report item becomes `implemented` or `verified`. Provenance binds a claim to current Android source; it does not prove runtime behavior and does not by itself prove that source was read before target code was written.
-
-## Required inputs
-
-For each report ref collect:
-
-- the Android project root and exact report ref;
-- every Android source file that informed the behavior, including manifests, Kotlin/Java, XML and relevant resources;
-- the real HarmonyOS implementation files;
-- the current Task and epoch identifiers when the caller has them;
-- the current Task source closure, when available.
-
-A prose summary, fact label, earlier report, or generated plan can help locate source but cannot replace current files.
-
-## Safe update
-
-Use the CLI so it verifies source membership and computes hashes:
-
-```text
-droid2hmos report update <android-project> \
-  --ref <report-ref> \
-  --status implemented \
-  --harmony-file <harmony-file> \
-  --android-source <android-file> \
-  [--android-source <android-file>...]
-```
-
-`--android-source` records whole-file provenance. Prefer whole files when a symbol cannot be located deterministically. If the active host provides a schema-aware way to record precise ranges, every range must include `symbol`, `startLine`, and `endLine` and must satisfy `migration-report-item.schema.json`; do not bypass the safe update path with an ad hoc report edit.
-
-## Source-closure reconciliation
-
-When a current Task/epoch source closure exists:
-
-1. compare its members with the Android files actually read for the behavior;
-2. include every behavior-relevant member in `--android-source`;
-3. treat a newly discovered relevant file as a closure/epoch issue for the caller to resolve;
-4. do not silently add an unrelated file merely to satisfy a count;
-5. do not mark the item `implemented` or `verified` while a relevant closure member is missing from provenance.
-
-`report validate` generates `.migration/audit/android-source-manifest.json` and checks managed file membership and hashes. When a Task Plan is available it also reconciles report provenance with the plan's source closure.
-
-## Evidence levels
-
-- `declared-hash-validated`: the declared file is in the managed Android project and its SHA-256 matches the current file. This is the normal CLI guarantee.
-- `observed-order-audited`: available only when a trusted host/runner supplies ordered Read/Write events for the same session and epoch and D1 passes.
-- `enforced-prewrite`: not provided by the current CLI; ordinary writes are not intercepted before they occur.
-
-Project-created `.migration/audit/source-events.jsonl` is not a trusted event source and must not upgrade the evidence level.
-
-## D1 and D2 audits
-
-D1 writes `.migration/audit/source-order-audit.json`:
-
-- `passed`: trusted events show declared Android reads before the first target write in the same session/epoch;
-- `red-flag`: reads are missing, late, concurrent in an invalid action group, malformed, or inconsistent; report validation fails;
-- `unavailable`: no trusted event source exists; hash evidence remains usable, but read-before-write must not be claimed.
-
-D2 writes `.migration/audit/literal-drift-audit.json`. It deterministically samples up to five implemented/verified refs and compares selected strings, colors, values and simple conditions. D2 warnings require source and behavior review; they are not automatic failures because i18n, resource renaming, unit conversion, theming, and equivalent refactors can be valid.
-
-## Existing reports
-
-`report init` upgrades supported older reports by adding empty `sourceProvenance` arrays without fabricating history. Existing `implemented` or `verified` claims remain invalid until current Android sources are declared and validation passes.
-
-Return provenance or closure gaps to the caller as `unresolved`. This Skill does not create a checkpoint or invoke completion after provenance validation.
+# Android source provenance
+
+Use this contract whenever a report item becomes `implemented` or `verified`. Provenance binds a claim to current Android source; it does not prove runtime behavior and does not by itself prove that source was read before target code was written.
+
+## Required inputs
+
+For each report ref collect:
+
+- the Android project root and exact report ref;
+- every Android source file that informed the behavior, including manifests, Kotlin/Java, XML and relevant resources;
+- the real HarmonyOS implementation files;
+- the current Task and epoch identifiers when the caller has them;
+- the current Task source closure, when available.
+
+A prose summary, fact label, earlier report, or generated plan can help locate source but cannot replace current files.
+
+## Safe update
+
+Use the CLI so it verifies source membership and computes hashes:
+
+```text
+droid2hmos report update <android-project> \
+  --ref <report-ref> \
+  --status implemented \
+  --harmony-file <harmony-file> \
+  --android-source <android-file> \
+  [--android-source <android-file>...]
+```
+
+`--android-source` records whole-file provenance. Prefer whole files when a symbol cannot be located deterministically. If the active host provides a schema-aware way to record precise ranges, every range must include `symbol`, `startLine`, and `endLine` and must satisfy `migration-report-item.schema.json`; do not bypass the safe update path with an ad hoc report edit.
+
+## Source-closure reconciliation
+
+When a current Task/epoch source closure exists:
+
+1. compare its members with the Android files actually read for the behavior;
+2. include every behavior-relevant member in `--android-source`;
+3. treat a newly discovered relevant file as a closure/epoch issue for the caller to resolve;
+4. do not silently add an unrelated file merely to satisfy a count;
+5. do not mark the item `implemented` or `verified` while a relevant closure member is missing from provenance.
+
+`report validate` generates `.migration/audit/android-source-manifest.json` and checks managed file membership and hashes. When a Task Plan is available it also reconciles report provenance with the plan's source closure.
+
+## Evidence levels
+
+- `declared-hash-validated`: the declared file is in the managed Android project and its SHA-256 matches the current file. This is the normal CLI guarantee.
+- `observed-order-audited`: available only when a trusted host/runner supplies ordered Read/Write events for the same session and epoch and D1 passes.
+- `enforced-prewrite`: not provided by the current CLI; ordinary writes are not intercepted before they occur.
+
+Project-created `.migration/audit/source-events.jsonl` is not a trusted event source and must not upgrade the evidence level.
+
+## D1 and D2 audits
+
+D1 writes `.migration/audit/source-order-audit.json`:
+
+- `passed`: trusted events show declared Android reads before the first target write in the same session/epoch;
+- `red-flag`: reads are missing, late, concurrent in an invalid action group, malformed, or inconsistent; report validation fails;
+- `unavailable`: no trusted event source exists; hash evidence remains usable, but read-before-write must not be claimed.
+
+D2 writes `.migration/audit/literal-drift-audit.json`. It deterministically samples up to five implemented/verified refs and compares selected strings, colors, values and simple conditions. D2 warnings require source and behavior review; they are not automatic failures because i18n, resource renaming, unit conversion, theming, and equivalent refactors can be valid.
+
+## Existing reports
+
+`report init` upgrades supported older reports by adding empty `sourceProvenance` arrays without fabricating history. Existing `implemented` or `verified` claims remain invalid until current Android sources are declared and validation passes.
+
+Return provenance or closure gaps to the caller as `unresolved`. This Skill does not create a checkpoint or invoke completion after provenance validation.

package/skills/managing-d2h-toolchain/SKILL.md

@@ -1,24 +1,24 @@
----
-name: managing-d2h-toolchain
-description: 独立检查、安装或升级迁移所需的精确版本 AppGraph 与 droid2hmos CLI。
----
-
-# 管理迁移工具链
-
-本 Skill 是迁移流程检查和维护 AppGraph、droid2hmos 的入口。`toolchain.json` 声明精确 npm 坐标及必需的命令能力；`environment-requirements.json` 声明主机环境约束。其他 Agent/Skill 只使用通过检查的 CLI，不自行选择版本或安装。以下脚本随 Skill 一起复制，直接由 Node.js 执行。
-
-## 检查与安装
-
-在本 Skill 目录运行（Windows 可使用 `node.exe`）：
-
-```sh
-node scripts/manage-toolchain.mjs check
-node scripts/manage-toolchain.mjs install
-```
-
-1. 首先运行 `check`。脚本读取同目录 `toolchain.json`，分别调用 `appgraph --version`、`droid2hmos --version` 和清单中声明的命令能力探针，逐项报告指定版本、实际版本及能力。全部符合时退出码为 0；缺失或不符时退出码为 1。
-2. `check` 失败时运行 `install`。脚本只对缺失、版本或能力不符的工具执行 `npm install --global <精确坐标>@<精确版本>`，随后重新检查。已符合要求的工具不会重装。安装失败或安装后仍不符合要求时停止迁移并报告错误；不能静默使用其他版本。
-3. 已存在的全局 npm link 默认受保护。需要替换链接时，调用方须明确要求 `node scripts/manage-toolchain.mjs install --force`；它会重新安装清单中的全部精确版本。脚本不会修改链接指向的源码目录。
-4. 安装完成后再运行一次 `check`，通过后才交给 `preparing-migration-workspace`。项目级 `droid2hmos preflight` 仍由准备 Skill 执行。
-
-首次使用本 Skill 时，要求 Node.js 22.5–24.x 和 npm 可用。工具已符合清单要求时，`check` 直接通过，`install` 不重复安装。修改依赖版本时只修改本目录的 `toolchain.json`，同步更新环境约束和测试。其他 Skill 不执行 `npm install -g`、`npm update` 或浮动版本安装。
+---
+name: managing-d2h-toolchain
+description: 独立检查、安装或升级迁移所需的精确版本 AppGraph 与 droid2hmos CLI。
+---
+
+# 管理迁移工具链
+
+本 Skill 是迁移流程检查和维护 AppGraph、droid2hmos 的入口。`toolchain.json` 声明精确 npm 坐标及必需的命令能力；`environment-requirements.json` 声明主机环境约束。其他 Agent/Skill 只使用通过检查的 CLI，不自行选择版本或安装。以下脚本随 Skill 一起复制，直接由 Node.js 执行。
+
+## 检查与安装
+
+在本 Skill 目录运行（Windows 可使用 `node.exe`）：
+
+```sh
+node scripts/manage-toolchain.mjs check
+node scripts/manage-toolchain.mjs install
+```
+
+1. 首先运行 `check`。脚本读取同目录 `toolchain.json`，分别调用 `appgraph --version`、`droid2hmos --version` 和清单中声明的命令能力探针，逐项报告指定版本、实际版本及能力。全部符合时退出码为 0；缺失或不符时退出码为 1。
+2. `check` 失败时运行 `install`。脚本只对缺失、版本或能力不符的工具执行 `npm install --global <精确坐标>@<精确版本>`，随后重新检查。已符合要求的工具不会重装。安装失败或安装后仍不符合要求时停止迁移并报告错误；不能静默使用其他版本。
+3. 已存在的全局 npm link 默认受保护。需要替换链接时，调用方须明确要求 `node scripts/manage-toolchain.mjs install --force`；它会重新安装清单中的全部精确版本。脚本不会修改链接指向的源码目录。
+4. 安装完成后再运行一次 `check`，通过后才交给 `preparing-migration-workspace`。项目级 `droid2hmos preflight` 仍由准备 Skill 执行。
+
+首次使用本 Skill 时，要求 Node.js 22.5–24.x 和 npm 可用。工具已符合清单要求时，`check` 直接通过，`install` 不重复安装。修改依赖版本时只修改本目录的 `toolchain.json`，同步更新环境约束和测试。其他 Skill 不执行 `npm install -g`、`npm update` 或浮动版本安装。

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

@@ -1,16 +1,16 @@
-{
-  "schemaVersion": 1,
-  "tools": {
-    "node": { "minimum": "22.5.0", "maximumExclusive": "25.0.0" },
-    "python": { "minimum": "3.10.0" },
-    "git": null,
-    "npm": null,
-    "java": null,
-    "python-json5": null,
-    "appgraph": { "minimum": "0.0.10", "maximumExclusive": "0.0.11" },
-    "droid2hmos": { "minimum": "0.0.11", "maximumExclusive": "0.0.12" },
-    "hvigor": null,
-    "ohpm": null,
-    "devecocli": null
-  }
-}
+{
+  "schemaVersion": 1,
+  "tools": {
+    "node": { "minimum": "22.5.0", "maximumExclusive": "25.0.0" },
+    "python": { "minimum": "3.10.0" },
+    "git": null,
+    "npm": null,
+    "java": null,
+    "python-json5": null,
+    "appgraph": { "minimum": "0.0.11", "maximumExclusive": "0.0.12" },
+    "droid2hmos": { "minimum": "0.0.12", "maximumExclusive": "0.0.13" },
+    "hvigor": null,
+    "ohpm": null,
+    "devecocli": null
+  }
+}