android2harmony 0.1.4 → 0.1.6

package/skills/a2h-ui-transfer/scripts/package.json

@@ -0,0 +1,3 @@
+{
+  "type": "module"
+}

package/skills/hmos-fix-build-errors/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: hmos-fix-build-errors
-description: Build a HarmonyOS project via CLI and automatically fix compile errors in a loop until the build succeeds. Default unsigned HAP; pass --signed to build a signed HAP (signing config must already exist in the project's build-profile.json5).
+description: Build a HarmonyOS project via CLI and automatically fix compile errors in a loop until the build succeeds. Default unsigned HAP; pass --signed to build a signed HAP (signing config must already exist in the project's build-profile.json5). Allowed to be called only in Android-to-HarmonyOS migration scenarios.
 argument-hint: <harmony_project_dir> [deveco-studio-path] [--signed]
 allowed-tools: Agent, Read, Write, Edit, Glob, Grep, Bash
 type: tool

package/skills/hmos-incremental-ui-align/README.md

@@ -31,10 +31,10 @@ HarmonyOS-Android UI 自动对齐流水线。
    - 两台设备建议都保持亮屏解锁
 
 2. **运行时依赖**
-   - 采集脚本 `page_capture.ts` 与寻路脚本 `app_feature_verify.ts` 均为 TypeScript 版，用 Node 直接运行（Node ≥ 22.18 或 ≥ 23.6，原生剥离类型，无需编译、零第三方依赖）。确认 `node --version` 即可，无需 Python / uv。
+   - 采集脚本 `page_capture.js` 与寻路脚本 `app_feature_verify.js` 为零第三方依赖的 Node 脚本（`.js` 即源码、零编译、`node` 直跑；路径在不在 `node_modules` 下都能跑，无原生剥类型问题）。确认 `node --version`（≥ 22.18）即可，无需 Python / uv。
 
 3. **模型配置**（寻路导航用）
-   与自测共用同一个多模态模型。插件场景下由 `a2h_app_feature_verify` 工具从 host 解析 key 并经 stdin 注入 `app_feature_verify.ts`（`--model-stdin`），key 不进环境变量、不泄露给 adb/hdc 子进程，无需单独配置。直接 `node` 运行（调试）时：`ht init` 把模型四要素写入 `~/.hometrans/config.json` 的 `autotest.unified_model`（并导出 `HOMETRANS_MODEL_*` 环境变量），脚本优先读 stdin → `--api-key` → 环境变量 → config.json；都没有时兼容老版本 `GLM_API_KEY`（走智谱 GLM 端点）。
+   与自测共用同一个多模态模型。插件场景下由 `a2h_app_feature_verify` 工具（参数为顶层字段、key 注入由工具处理：key 从 host 解析、经 stdin 注入 `app_feature_verify.js`、不进环境变量、不泄露给 adb/hdc 子进程），无需单独配置。直接 `node` 运行（调试）时：`ht init` 把模型四要素写入 `~/.hometrans/config.json` 的 `autotest.unified_model`（并导出 `HOMETRANS_MODEL_*` 环境变量），脚本优先读 stdin → `--api-key` → 环境变量 → config.json；都没有时兼容老版本 `GLM_API_KEY`（走智谱 GLM 端点）。
 
 4. **鸿蒙 SDK 路径**（给改码阶段查 API 用）
    取自 OS 环境变量 `OHOS_SDK_PATH` / `HMS_SDK_PATH`（为空时由 `DEVECO_SDK_HOME` 派生），由 `ht init` 写入机器环境变量；例如 DevEco Studio 自带的 `E:\DevEco Studio\sdk\default\openharmony\ets`。
@@ -122,10 +122,10 @@ skill 会严格按 `SKILL.md` 里的流水线跑：
 
 ### Step 1 · 双端页面采集
 1.1 解析你的需求，拆成一组「基础页」，每个基础页有 `android_nav_path` 和 `hmos_nav_path`
-1.2 对每个基础页，两端分别：`app_feature_verify.ts` 寻路 → 成功后 `page_capture.ts` 截图 + dump view tree
+1.2 对每个基础页，两端分别：`app_feature_verify.js` 寻路 → 成功后 `page_capture.js` 截图 + dump view tree
 1.3 扫描基础页 view tree，发现 tab、弹窗、下拉等交互元素，自动对每个子状态再采集一遍
 1.4 扫描安卓源码里的动画/Toast/语音传感器等 API，产出 `dynamic_ui_inventory.md`（截图和 view tree 抓不到这些效果）
-1.5 识别多状态组件（如语音输入的 idle/recording/cancelling），读源码建 `state_model.md`，用 `page_capture_burst.ts` 连续采帧捕捉每个状态的代表帧
+1.5 识别多状态组件（如语音输入的 idle/recording/cancelling），读源码建 `state_model.md`，用 `page_capture_burst.js` 连续采帧捕捉每个状态的代表帧
 1.6 鸿蒙端页面不存在时，寻路会失败，对应目录留空（Step 2 会改从源码读）
 
 产物目录结构：
@@ -156,7 +156,7 @@ skill 会严格按 `SKILL.md` 里的流水线跑：
 所有尺寸都会以 `126px (3.0x → 42vp)` 的格式同时给出原始 px、**从各自 `meta.json` 读到的真实设备密度**、换算后的 vp（不再假设固定 3x）。
 
 ### Step 3 · 改鸿蒙源码
-- 跑 `node ./scripts/extract_checklist.ts --task-dir "{task_dir}"` 确定性地从所有 `UI_comparison.md` 抽取 diff 项，生成 `{task_dir}/fix_checklist.md`（唯一 source of truth），并核对脚本输出的 `items >= diff_rows` 对账报告，避免人工枚举漏项
+- 跑 `node ./scripts/extract_checklist.js --task-dir "{task_dir}"` 确定性地从所有 `UI_comparison.md` 抽取 diff 项，生成 `{task_dir}/fix_checklist.md`（唯一 source of truth），并核对脚本输出的 `items >= diff_rows` 对账报告，避免人工枚举漏项
 - 先探测工程状态管理范式（V1/V2，工程级判定一次）：新工程/0→1 转换默认 V2，已有 V1 的工程沿用 V1
 - 按范式读对应文档：V1 读 `references/MVVM开发文档/`，V2 读 `references/MVVM开发文档V2/`（详见 `references/MVVM开发文档V2/_范式选择说明.md`）
 - 读 `page_align.md` 学习转换规则
@@ -177,10 +177,10 @@ skills/hmos-incremental-ui-align/
 ├── page_align.md               # Step 3 的转换规则
 ├── diff_analysis.md            # 内部说明
 ├── scripts/
-│   ├── app_feature_verify.ts   # 寻路工具（TypeScript，Node 直跑）
-│   ├── page_capture.ts         # view tree + 截图采集工具（TypeScript，Node 直跑，含密度换算）
-│   ├── page_capture_burst.ts   # 连续帧采集工具（多状态组件用，TypeScript，Node 直跑）
-│   ├── extract_checklist.ts    # 确定性 diff→checklist 抽取工具（TypeScript，Node 直跑）
+│   ├── app_feature_verify.js   # 寻路工具（.js 源码，Node 直跑）
+│   ├── page_capture.js         # view tree + 截图采集工具（.js 源码，Node 直跑，含密度换算）
+│   ├── page_capture_burst.js   # 连续帧采集工具（多状态组件用，.js 源码，Node 直跑）
+│   ├── extract_checklist.js    # 确定性 diff→checklist 抽取工具（.js 源码，Node 直跑）
 │   └── navigation-capure.md    # 各脚本的调用约定
 └── references/
     ├── UI_Analysis_Template.md                # Step 2 分析模板（含动态UI/多状态章节）
@@ -197,19 +197,19 @@ skills/hmos-incremental-ui-align/
 
 ## 单独运行脚本（调试用）
 
-跳过 skill 手动跑采集（直接 `node` 运行不经工具，模型 key 需来自 `~/.hometrans/config.json` 的 `autotest.unified_model` 或 `HOMETRANS_MODEL_*` 环境变量；插件场景应改用 `a2h_app_feature_verify` 工具，key 经 stdin 注入不泄露）：
+跳过 skill 手动跑采集（直接 `node` 运行不经工具，模型 key 需来自 `~/.hometrans/config.json` 的 `autotest.unified_model` 或 `HOMETRANS_MODEL_*` 环境变量；插件场景应改用 `a2h_app_feature_verify` 工具，参数与 key 注入由工具处理）：
 
 ```powershell
-# 安卓寻路（TypeScript 版，Node ≥ 22.18/23.6 直跑，无需 uv / PYTHONIOENCODING）
-node Agents/hmos-ui-align/scripts/app_feature_verify.ts `
+# 安卓寻路（.js 源码，`node …/app_feature_verify.js` 直跑）
+node skills/hmos-incremental-ui-align/scripts/app_feature_verify.js `
   --device adb `
   --app "Salt Player" `
   --package "com.salt.music" `
   --prompt "进入首页-点击AI智能填报-点击专业筛选按钮" `
   --max-steps 15
 
-# 安卓采集（TypeScript 版，Node ≥ 22.18/23.6 直跑，无需 uv / PYTHONIOENCODING）
-node Agents/hmos-ui-align/scripts/page_capture.ts --device adb -o ./tmp/android_page_1_xxx
+# 安卓采集（.js 源码，`node …/page_capture.js` 直跑）
+node skills/hmos-incremental-ui-align/scripts/page_capture.js --device adb -o ./tmp/android_page_1_xxx
 
 # 鸿蒙同理，把 --device adb 换成 --device hdc
 ```
@@ -239,7 +239,7 @@ A: 目前流水线是端到端的。如果只想要分析产物，跑完 Step 2
 A: 能。Step 1.4 会扫描安卓源码里的动画/Toast/语音传感器 API，产出 `dynamic_ui_inventory.md`；Step 2.3 会生成对应的「Dynamic / Transient UI Comparison」diff 表；Step 3 逐条修复时会写入真实的 ArkUI `animateTo()` / `promptAction.showToast()` 等实现。
 
 **Q: 像"按住说话"这种有多个状态的组件怎么对齐？**
-A: Step 1.5 会先建 `state_model.md`（状态枚举 + 转移条件 + 每状态属性，均需溯源到源码行号），再用 `page_capture_burst.ts` 连续采帧抓每个状态的代表帧。单击、松开长按等手势可自动触发；长按保持/拖拽/语音等手势需要人工在设备上操作，skill 会打印操作说明等你确认。
+A: Step 1.5 会先建 `state_model.md`（状态枚举 + 转移条件 + 每状态属性，均需溯源到源码行号），再用 `page_capture_burst.js` 连续采帧抓每个状态的代表帧。单击、松开长按等手势可自动触发；长按保持/拖拽/语音等手势需要人工在设备上操作，skill 会打印操作说明等你确认。
 
 ---
 

package/skills/hmos-incremental-ui-align/SKILL.md

@@ -16,11 +16,11 @@ You are writing ArkTS codes.
 - If mock data is required, write them in `{harmony_project_dir}/entry/src/main/ets/model/` according to the hmos MVVM mode (V1 or V2, per the paradigm detected in Step 3.1).
 - Do not make any other changes unrelated to the user's requirements.
 
-**Skill scripts** (TypeScript, run directly with `node` — Node ≥ 22.18/23.6, no build step, no third-party deps; all paths relative to this skill's root):
-- `navigation_tool` = `./scripts/app_feature_verify.ts`
-- `capture_tool` = `./scripts/page_capture.ts`
-- `burst_capture_tool` = `./scripts/page_capture_burst.ts` — continuous view-tree+screenshot capture at ~1s intervals, for multi-state components (Step 1.5)
-- `checklist_tool` = `./scripts/extract_checklist.ts` — deterministically extracts all diffs from `UI_comparison.md` files into `fix_checklist.md` (used in Step 3)
+**Skill scripts** (`.js` sources, run with `node`; no build step, no third-party deps; all paths relative to this skill's root):
+- `navigation_tool` = `./scripts/app_feature_verify.js`
+- `capture_tool` = `./scripts/page_capture.js`
+- `burst_capture_tool` = `./scripts/page_capture_burst.js` — continuous view-tree+screenshot capture at ~1s intervals, for multi-state components (Step 1.5)
+- `checklist_tool` = `./scripts/extract_checklist.js` — deterministically extracts all diffs from `UI_comparison.md` files into `fix_checklist.md` (used in Step 3)
 
 ## Step 0: Resolve Inputs
 
@@ -46,13 +46,13 @@ Resolve each value along the standard chain — **OS environment variable first,
 | `OHOS_SDK_PATH` | `env.OHOS_SDK_PATH` | HarmonyOS SDK ETS API reference (Step 3) | path exists on disk |
 | `HMS_SDK_PATH` | `env.HMS_SDK_PATH` | HMS SDK ETS API reference (Step 3) | path exists on disk |
 
-The model config is injected automatically: in the plugin context the `a2h_app_feature_verify` tool resolves the key from the host and pipes it to `scripts/app_feature_verify.ts` over stdin (`--model-stdin`), so the key never sits in an env var and is not visible to the spawned adb/hdc subprocesses — you do not read or pass the key by hand. For a direct `node scripts/app_feature_verify.ts` run (no tool, e.g. debugging), the script still resolves `--api-key` → `HOMETRANS_MODEL_*` env → `~/.hometrans/config.json` → `GLM_API_KEY`; ensure one of those is set. For `OHOS_SDK_PATH` / `HMS_SDK_PATH`, if both the env var and `~/.hometrans/config.json` are empty but `DEVECO_SDK_HOME` is set (env or `env.DEVECO_SDK_HOME` in config.json), derive them as `<DEVECO_SDK_HOME>/default/openharmony/ets` and `<DEVECO_SDK_HOME>/default/hms/ets`.
+The model config is injected automatically: in the plugin context the `a2h_app_feature_verify` tool (navigation params passed as top-level fields `app`/`package`/`device`/`prompt`/`task`/`feature`/… — see `scripts/navigation-capure.md` for the field list) resolves the key from the host and pipes it to `scripts/app_feature_verify.js` over stdin, so the key never sits in an env var and is not visible to the spawned adb/hdc subprocesses — you do not read or pass the key by hand. For a direct `node scripts/app_feature_verify.js` run (no tool, e.g. debugging), the script still resolves `--api-key` → `HOMETRANS_MODEL_*` env → `~/.hometrans/config.json` → `GLM_API_KEY`; ensure one of those is set. For `OHOS_SDK_PATH` / `HMS_SDK_PATH`, if both the env var and `~/.hometrans/config.json` are empty but `DEVECO_SDK_HOME` is set (env or `env.DEVECO_SDK_HOME` in config.json), derive them as `<DEVECO_SDK_HOME>/default/openharmony/ets` and `<DEVECO_SDK_HOME>/default/hms/ets`.
 
 For each value that is still missing/empty (or a path that does not exist) after both the env var and `~/.hometrans/config.json`, **stop and ask the user to provide a value**, then use what they give for this run. Suggest running `ht init` to persist them as machine environment variables for next time.
 
 ### Step 0.1: Auto-derive App Names & Package Names
 
-`android.app_name` / `android.package` / `harmony.app_name` / `harmony.package` are required for navigation (passed to the `a2h_app_feature_verify` tool as `--app` / `--package`). They are not provided as inputs — resolve them from the project dirs (`android_project_dir` / `harmony_project_dir`) as follows.
+`android.app_name` / `android.package` / `harmony.app_name` / `harmony.package` are required for navigation (passed to the `a2h_app_feature_verify` tool as the `app` / `package` fields). They are not provided as inputs — resolve them from the project dirs (`android_project_dir` / `harmony_project_dir`) as follows.
 
 **`app_name` matters because it is the launcher label the navigator taps to open the app** — when the resolved label is a localized resource and a Chinese (`zh`) variant exists, prefer the Chinese value (devices are typically zh-CN).
 
@@ -74,7 +74,7 @@ After resolving all four, briefly echo them to the user (e.g. `android.app_name=
 
 ## Step 1: Capture All Related Pages on Android & HarmonyOS Devices
 
-Read `scripts/navigation-capure.md` to learn the usage of `scripts/app_feature_verify.ts` (navigation) and `scripts/page_capture.ts` (capture).
+Read `scripts/navigation-capure.md` to learn the usage of `scripts/app_feature_verify.js` (navigation) and `scripts/page_capture.js` (capture).
 
 ### Step 1.1: Parse User Request and Build Capture Plan
 Analyze the user's description and build a list of **base pages** to capture.
@@ -89,8 +89,8 @@ Create the timestamped output directory and per-page sub-directories following t
 
 ### Step 1.2: Capture Base Pages
 For each base page in the plan, on **both** Android and HarmonyOS devices:
-1. Use the `a2h_app_feature_verify` tool to navigate to the page (it runs `scripts/app_feature_verify.ts` with the model key piped over stdin, so the key is not leaked into env/argv).
-2. On success, use `scripts/page_capture.ts` to capture the view tree and screenshot.
+1. Use the `a2h_app_feature_verify` tool to navigate to the page: pass the navigation params as top-level fields (`app`, `package`, `device`, and one of `prompt`/`task`/`feature`; the tool description lists all fields). See `scripts/navigation-capure.md` for the navigation prompt rule and capture workflow.
+2. On success, use `scripts/page_capture.js` to capture the view tree and screenshot.
 3. For HarmonyOS pages that don't exist yet, navigation will fail — leave the directory empty (expected).
 
 ### Step 1.3: Discover and Capture Interactive States
@@ -102,7 +102,7 @@ After capturing each base page, scan its view tree for **interactive elements th
 
 **For each interactive element found:**
 1. Create a separate capture directory: `{platform}_page_{i}_{base_name}_{state_type}_{state_name}` (e.g., `android_page_1_detail_tab_city`, `android_page_1_detail_popup_filter_identity`).
-2. Navigate to the base page (reuse the same nav path), then append the click action to trigger the state change. Capture with `scripts/page_capture.ts`.
+2. Navigate to the base page (reuse the same nav path), then append the click action to trigger the state change. Capture with `scripts/page_capture.js`.
 3. Repeat for **both** Android and HarmonyOS devices.
 4. Each captured state is treated as a separate page pair in Step 2 and Step 3.
 
@@ -177,8 +177,8 @@ The model MUST include:
 
 **For auto-capturable states** (single tap, simple long-press then release):
 1. Navigate to the component's page
-2. Start `scripts/page_capture_burst.ts` (see `scripts/navigation-capure.md` for burst workflow)
-3. Trigger the state via the `a2h_app_feature_verify` tool
+2. Start `scripts/page_capture_burst.js` (see `scripts/navigation-capure.md` for burst workflow)
+3. Trigger the state via the `a2h_app_feature_verify` tool (navigation params as top-level fields)
 4. Select representative frames from burst output
 
 **For non-auto-capturable states** (long-press hold, drag, pan, sensor, voice):
@@ -231,7 +231,7 @@ Firstly, make sure whether the page exists, then:
  - device density (read from the page's `meta.json` → `density_factor`; e.g. 3.0)
  - converted dp/vp value (px ÷ density_factor)
  Format: "126px (3.0x → 42vp)". Never write bare px or vp without the other.
- **Density source**: `scripts/page_capture.ts` records the real device density into each capture directory's `meta.json` (`dpi` and `density_factor`). Read `density_factor` from there per page — do NOT assume 3x. Android and HarmonyOS captures may have different densities, so convert each side using its own `meta.json`. If a page's `meta.json` is missing `density_factor`, fall back to 3.0 and note the assumption.
+ **Density source**: `scripts/page_capture.js` records the real device density into each capture directory's `meta.json` (`dpi` and `density_factor`). Read `density_factor` from there per page — do NOT assume 3x. Android and HarmonyOS captures may have different densities, so convert each side using its own `meta.json`. If a page's `meta.json` is missing `density_factor`, fall back to 3.0 and note the assumption.
  **MANDATORY OUTPUT**: Write the result to `android_page_{i}_{name}/UI_Analysis.md`，写完后确认文件已创建。
  **This step is NEVER skippable** — even if the HarmonyOS counterpart is empty, the Android analysis must still be written.
 
@@ -278,7 +278,7 @@ MUST verify:
 2. If any `UI_comparison.md` is missing or contains only a status note without a component table, go back to Step 2 and complete it. For pages where HarmonyOS was not captured, read the source code to generate `UI_Analysis_from_code.md` first, then regenerate the comparison with a proper component-level diff table.
 3. Generate `{task_dir}/fix_checklist.md` **deterministically** by running the extraction script — do NOT hand-enumerate diffs from the comparison tables (manual enumeration is the main cause of missed items):
 ```bash
-node ./scripts/extract_checklist.ts --task-dir "{task_dir}"
+node ./scripts/extract_checklist.js --task-dir "{task_dir}"
 ```
 The script parses ALL five table types in every `UI_comparison.md` (main static component table, Dynamic / Transient UI, State Machine, Per-Transition, Per-State Visual), skips rows whose Diff cell is empty / "一致" / "-", splits a row carrying multiple diffs (separated by `；`, `;`, or `<br>`) into separate items, and tags items with `[DYNAMIC]` / `[STATE]` / `[TRANSITION]` prefixes. It prints a per-page reconciliation table (`diff_rows` vs `items`).
 

package/skills/hmos-incremental-ui-align/references/State_Model_Template.md

@@ -63,12 +63,12 @@ For states that cannot be auto-captured, provide step-by-step instructions:
 
 ```
 State S1 (recording):
-1. Run: node ./scripts/page_capture_burst.ts --device adb -o {output_dir} --duration 5
+1. Run: node ./scripts/page_capture_burst.js --device adb -o {output_dir} --duration 5
 2. On device: long-press the microphone button and HOLD
 3. Wait for burst to complete, then release
 
 State S2 (cancelling):
-1. Run: node ./scripts/page_capture_burst.ts --device adb -o {output_dir} --duration 5
+1. Run: node ./scripts/page_capture_burst.js --device adb -o {output_dir} --duration 5
 2. On device: long-press mic → drag finger UP past the cancel threshold
 3. Wait for burst to complete, then release
 ```