feat(ohos): emit/Channel event bridge, webview drag-drop, bridge facade migration, and cross-platform gating

.claude/skills/ohos-bridge-arch/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: ohos-bridge-arch
+description: openharmony-ability bridge 插件新架构适配指南——新增桥接能力(ArkTS 插件 + Rust facade)与适配新 Tauri 插件模块到 OHOS 的完整流程、注册链路、HAR 重建、已知坑与验证方法
+---
+
+# ohos-bridge-arch：bridge 插件架构适配
+
+openharmony-ability 已完成 pluginize 重构(解耦方案 v1→v3):旧 ArkHelper TSFN 通道**已全部删除**,所有系统能力走 **typed bridge plugin** 模式。本 skill 是新增/修改 OHOS 系统能力时的架构速查与操作手册。
+
+## 架构总览
+
+```
+ArkTS (openharmony-ability)
+  native_ability/src/main/ets/ability/type.ets
+    PluginBase / AsyncPluginBase / SyncPluginBase (抽象基类)
+  plugins/<name>/src/main/ets/<Name>Plugin.ets   ← 15 个桥接插件
+    id="ohos.<name>"  requires=["ability"]  invokeAsync(action, payload)
+
+Rust (openharmony-ability)
+  crates/ability/src/bridge/mod.rs
+    trait BridgePlugin (AsyncBridge / SyncBridge 双模式)
+    impl_bridge_napi_type! 宏
+    OpenHarmonyApp::bridge() -> Result<BridgeRuntime>
+    BridgeRuntime::call_async::<P, Req, Resp>(action, req)
+  crates/plugin-<name>/           ← 类型化 facade crate(如 ClipboardClient)
+  crates/ability/src/<name>.rs    ← 核心特权能力可内联在 ability crate
+    (account.rs / updater.rs 先例,不建新 crate)
+
+注册链路
+  EntryAbility.ets bridgePlugins 数组 new LazyPlugin(() => new XxxPlugin())
+  ├─ tauri-cli 模板: crates/tauri-cli/templates/mobile/open-harmony/
+  │    entry_{desktop,mobile}/.../EntryAbility.ets.hbs   ← 改后须重装 cli
+  └─ examples/api: gen/ohos/entry_{desktop,mobile}/.../EntryAbility.ets
+       (gen 不重生成时手改可持久,但 re-init 会覆盖 → 改模板为准)
+```
+
+**当前 15 插件**:app-control / account / autostart / clipboard / deep-link / files / global-shortcut / menu / permission / resource / statusbar / updater / url / webview / window(pack-plugins.ps1 `$plugins` 列表)。
+
+**核心特权 vs 通用插件**:15 插件中 **13 个**建 `plugin-*` facade crate,**2 个**(account/updater)按核心特权定性内联 ability crate,经 `HuaweiAccount::new(&OpenHarmonyApp) -> Result<Self>` / `app.updater() -> Result<Updater>` 消费。account(非 default)与 updater(default 中)由 feature cfg 门控。
+
+## 场景 A:新增一个桥接能力(标准步骤)
+
+1. **ArkTS 插件**(5 文件,从 `plugins/clipboard/` 复制改):
+   - `plugins/<name>/oh-package.json5`(name=`@ohos-rs/ability-plugin-<name>`,deps `@ohos-rs/ability: file:../../native_ability`)
+   - `src/main/ets/<Name>Plugin.ets`:继承 `AsyncPluginBase`,`id = "ohos.<name>"`,`requires = ["ability"]`,`invokeAsync` 按 action 分发
+   - `index.ets` / `build-profile.json5` / `src/main/module.json5`(module=`plugin_<name>`)
+2. **pack-plugins.ps1**:`$plugins` 数组追加一行 + 计数注释同步(如 15→16)
+3. **Rust 侧**:
+   - 通用能力:新建 `crates/plugin-<name>/`,参照 `plugin-clipboard`(BridgePlugin impl + `#[napi(object)]` Req/Resp struct + `impl_bridge_napi_type!` + `call_async`)
+   - 核心特权:内联 `crates/ability/src/<name>.rs`,破坏性 API `Xxx::new(&OpenHarmonyApp) -> Result<Self>` 持 BridgeRuntime
+4. **EntryAbility 注册**:cli 模板 .hbs 加 import + `new LazyPlugin(() => new XxxPlugin())`;gen/ohos 两个 EntryAbility.ets 手动同步(或重 init)
+5. **重建 HAR + 构建部署**(见下)
+
+## 场景 B:适配新 Tauri 插件模块到 OHOS
+
+把 plugins-workspace 的一个插件(如 notification/sql/nfc)适配到鸿蒙。bridge 层(场景 A)只是其中一环,完整流程:
+
+### 0. 前置判断
+- 能力**需要系统能力**(ArkTS API)→ 先按场景 A 补 bridge 层,再做本流程
+- **纯 JS/Rust 逻辑**(无系统能力调用)→ 只需 cfg 接入(步骤 1-3),无 bridge 层
+
+### 1. 上游结构分析
+读插件 `plugins/<name>/src/`:`lib.rs`(cfg 矩阵)、`commands.rs`(命令面)、`desktop.rs`/`mobile.rs`(平台实现分层)。产出:哪些命令需要 OHOS 实现、复用 desktop 还是 mobile 层逻辑。
+
+### 2. 选接入形态(两个已验证先例)
+- **形态 1——既有插件补 OHOS**(clipboard-manager/notification 先例):平台层文件内加 `#[cfg(target_env = "ohos")]` 专属段调用 facade;`lib.rs` 的门控从 `cfg(desktop)` 扩成 `cfg(any(desktop, target_env = "ohos"))`、原 desktop 段收紧为 `cfg(all(desktop, not(target_env = "ohos")))`。适合插件已有跨平台分层、OHOS 可复用其命令面
+- **形态 2——OHOS 专属新插件**(huawei-account 先例):独立 `src/ohos.rs`(`#[cfg(target_env = "ohos")]`,含 `#[tauri::command]`) + `commands.rs`/`models.rs`,lib.rs 按 target 分流。适合 OHOS 独有能力
+
+### 3. Cargo.toml
+OHOS target 段按形态声明依赖(**path 都是三个 `..`**,从 `plugins-workspace/plugins/<name>/` 解析到仓库根;facade crate 不在 workspace [patch.crates-io] 表内,必须显式带 path):
+```toml
+# 形态 1(经 facade crate)—— clipboard-manager 先例:
+[target.'cfg(target_env = "ohos")'.dependencies]
+openharmony-ability-plugin-clipboard = { path = "../../../openharmony-ability/crates/plugin-clipboard" }
+
+# 形态 2(核心特权,直依赖 ability crate + feature)—— huawei-account 先例:
+[target.'cfg(target_env = "ohos")'.dependencies]
+openharmony-ability = { path = "../../../openharmony-ability/crates/ability", features = ["account"] }
+```
+- Linux 依赖段必须加 `not(target_env = "ohos")`(铁律#2,否则拉 gtk/gio-sys)
+- 若需给 tauri 开 `wry` feature,可用 `cfg(any(target_os = "ios", target_env = "ohos"))` 段(notification 先例:与 iOS 共用声明)
+
+### 4. 桥接层对接(形态内调用方式)
+- 通用能力:经 plugin-* facade 的类型化 client(如 `ClipboardExt::clipboard()`)
+- 核心特权:从 `tauri::ohos::APP` 锁取 app(MutexGuard **在 await 前 drop**),调 `HuaweiAccount::new(&app)`/`app.updater()`
+- 注意 feature unification:消费者可能 `default-features=false` 不开 `wry`——桥接初始化调用若依赖 wry 相关组件需 `#[cfg(feature = "wry")]` 门控(tauri app.rs 先例)
+
+### 5. examples/api 接入
+- `examples/api/src-tauri/Cargo.toml` 加 path 依赖(`../../../../plugins-workspace/plugins/<name>`)
+- 前端测试页 + invoke 命令绑定;需要 JS API 时改插件 `guest-js/` 并重建 dist-js
+
+### 6. 构建与验证
+- **dist-js 防 stale**:run-tests.sh 的 prerequisites 会自动 pnpm build 全部插件 dist-js——手动构建时勿漏(notification dist-js 过期曾致假失败)
+- `cargo check` 双侧(plugins-workspace 内该插件包;注意 workspace patch 块已把 tauri 栈指向本地 fork)
+- 真机验证走 ohos-build skill 流程
+- **grep 盲区教训**:手动测试按钮经 前端→cmd.rs→facade 间接调用,**grep 插件仓源码/autotest 都抓不到**这类调用链;判"是否有消费者"必须追 `#[tauri::command]` 注册表与前端 invoke
+
+### 推荐工作流
+用 ohos-debug skill 的分工:design(方案+上游分析)→audit(复核)→apply(落地)→build(构建部署回归)。
+
+## 构建链路(改 ArkTS 后必须)
+
+
+```bash
+# 1. 重建 HAR(pack.bat 必须经 cmd.exe 显式调用,git bash/PowerShell 直接跑会吃字符静默失败)
+cd /d/xuqiu/tauri-3.0/openharmony-ability
+cmd.exe //c "D:\\xuqiu\\tauri-3.0\\openharmony-ability\\pack.bat"
+# 验证镜像含新代码:
+ls package/src/main/ets/plugins/<name>/   # 应有 <Name>Plugin.ets
+grep -rc "ohos.<name>" package/ | head -3
+
+# 2. 构建(ohpm 同步由 CLI 自动完成,严禁手动 ohpm install)
+cd /d/xuqiu/tauri-3.0/tauri/examples/api/src-tauri
+OHOS_DEVICE_TYPE=desktop bash /d/xuqiu/tauri-3.0/tauri/.claude/skills/ohos-build/scripts/run-tests.sh "" desktop
+```
+
+改 tauri-cli 模板(.hbs)后:`cargo install --path crates/tauri-cli --locked` 重装才对**新** init 生效;重 init 会丢签名/main_pages/module.json5/项目 .ets,须备份恢复(详见 ohos-build skill「init 后补充步骤」)。
+
+## Rust→ArkTS 桥接硬规则(踩过的坑)
+
+| 规则 | 违反后果 |
+|---|---|
+| ArkTS interface 字段名与 NAPI wire **全 camelCase** 对齐 | tray `no valid icon data` / muda `json_data must be a string` 类静默失败 |
+| 取 abilityContext 用 `context.abilityContext` + `requires:["ability"]`;禁止 `getAbilityContext()` global | 恒 null → `abilityInfo of null` |
+| ArkTS 禁 `as any`/`as unknown`(arkts-no-any-unknown);旧代码迁移用 interface cast | ArkTS 编译错 |
+| `#[napi(object)]` 内 `Vec<u8>` 跨桥是 `Array<number>` **非 Uint8Array**;ArkTS 侧 `new Uint8Array(len).set(arr)` 拷贝 | `.buffer.slice()` undefined 崩溃 |
+| serde `Option` 字段加 `skip_serializing_if` | null(非 absent)触发 OHOS API 401 |
+| **主线程禁 block_on / recv / recv_timeout 等 ArkTS 响应**——一律 fire-and-forget(TSFN)或异步事件(emit)回调 | 主线程死锁 THREAD_BLOCK_3S |
+| 返回值走 `Promise<BridgeTypedValue>`(invokeAsync)或 emit 事件,不同步等结果 | 同上 |
+| 跨 await 前先 drop `MutexGuard`(作用域块包住) | !Send 编译错/死锁 |
+| `#[napi]` 生成的 JS 名默认 camelCase;多参数 TSFN 回调用 `FnArgs` 包裹 | 参数错位 |
+| OHOS 代码 `cfg(target_env = "ohos")` 隔离;Linux 依赖加 `not(target_env = "ohos")`(铁律#2) | 拉进 gtk/gio-sys 破坏交叉编译 |
+
+## 验证
+
+- cargo check 双侧 0 error:`cargo check -p openharmony-ability` + `--target aarch64-unknown-linux-ohos`;ability crate 双侧 0 warning
+- hilog 判断桥接断点:ArkTS 方法 ENTER 日志**有** → NAPI 通,问题在 ArkTS/系统层;**无** → Rust 侧断裂(常见:`let _ =` 吞错)
+- 插件注册验证:启动后 `hilog -x | grep -aE '<PluginName>|not installed'` 无 "not installed for 'api_lib'" 报错
+
+## 废弃通道(勿再使用/勿复活)
+
+- ~~ArkHelper TSFN~~:`set_helper` 从未被调用(derive 重构后零调用方),`get_helper()` 恒 None;全部 eager TSFN init 已从 `render/xcomponent.rs` 删除,**不要重新添加**
+- ~~menu/statusbar 旧 channel~~、~~deep-link 旧 API~~、~~cursor 全局~~、~~opener.rs/helper/{opener,window_info,account,updater}.rs~~:均已删除
+- 判死标准:不能只 grep 直接 import——须追 **app handle ext 方法间接调用链**(如 `app.updater()`);且"有消费者"≠"链路通"(曾误判 account/updater 为活代码)
+
+## 相关 skill
+
+- 构建部署全流程 → `ohos-build`
+- 调试工作流(设计/审计/落地/构建分工) → `ohos-debug`
+- 详细设计规范 → `tauri-ohos-design/references/ohos-constraints.md`

.claude/skills/ohos-build/SKILL.md

@@ -23,11 +23,22 @@ cargo tauri ohos run --device-type desktop
 
 一条龙完成：前端构建 → Rust 交叉编译 → HAP 打包签名 → 安装 → 启动。
 
+> **注意**：`run` 是 **attach 模式**——部署启动成功后不退出，持续转发设备日志（适合现场看输出）。后台/脚本调用会一直挂着：要么接受其常驻，要么用 `cargo tauri ohos build` + `install.sh` 分离部署。构建成功与否以 HAP 产物 mtime / 设备 app 启动时间为准，别等命令退出。
+
 `--device-type` 参数：
 - `desktop` — PC/桌面设备（cfg(desktop)，Tray/Menu 功能需要）
 - `mobile` — 手机/平板（cfg(mobile)）
 
-> **注意**：此命令不包含自动测试（VITE_AUTOTEST）和 test-report 拉取。如需自动测试，使用方式二。
+> **注意**：此命令不包含自动测试（不设 `VITE_AUTOTEST`，app 启动后不自动跑套件，需手动点 Run All，为 283 例标准集）。如需自动测试，使用方式二。
+
+### 前端门控双变量（TestRunner.svelte）
+
+| 变量 | 语义 | 谁设置 |
+|---|---|---|
+| `VITE_AUTOTEST` | 自动跑测试（主窗口 mount 即跑，**283 例标准集**） | run-tests.sh、cov-build.sh |
+| `VITE_COVERAGE_TESTS` | 注入覆盖率批次（driver/side-replay/bad-input/fault，共 312 例，合计 595） | 仅 cov-build.sh 插桩形态 |
+
+两变量都不设（方式一/方式三）→ 普通交互 demo，不自动跑测试。
 
 ### 方式二：run-tests.sh（含自动测试）
 
@@ -45,7 +56,7 @@ OHOS_DEVICE_TYPE=desktop bash ${PROJECT_ROOT}/tauri/.claude/skills/ohos-build/sc
    - Rust 交叉编译（aarch64-unknown-linux-ohos，release，--features prod）
    - .so 拷贝 + hvigorw assembleHap（TAURI_OHOS_SKIP_DEVECO_SCRIPT 禁用 tauriPlugin，build-profile.json5 证书签名）
    - 安装已签名 HAP（带 hdc false-success 检测）→ 启动
-4. 等待 30s → 拉取 test-report → 分析结果
+4. 轮询 test-report footer（`*Report generated at end of test run.*`，5s 间隔，最长 `WAIT_SECONDS`=180s）→ 拉取报告 → 分析结果
 
 ### 方式三：cargo tauri ohos build --app（多形态打包）
 
@@ -95,10 +106,52 @@ PR #59 将 app 拆分为 mobile 和 desktop 两个 entry 模块：
 |------|------|
 | `env.sh` | 环境配置：DevEco Studio 路径解析（`DEV_ECO_STUDIO_INSTALL_PATH` 优先 → `DEVECO_HOME` → 自动检测，不落盘）、CC/linker/JAVA_HOME/PATH，必须在其他脚本前 source |
 | `prerequisites.sh` | CLI 不做的开发期前置：pnpm install / build:api / 插件 dist-js / ACL 检查。被 build-ohos.sh 和 run-tests.sh source，不直接执行 |
-| `run-tests.sh` | 一键全流程：HAR 重建 → prerequisites → `cargo tauri ohos run`（build+install+launch，带 hdc false-success 检测）→ 等待 → 拉取报告 → 分析 |
+| `run-tests.sh` | 一键全流程：HAR 重建 → prerequisites → `cargo tauri ohos run`（build+install+launch，带 hdc false-success 检测）→ 轮询报告 footer → 拉取报告 → 分析 |
 | `build-ohos.sh` | prerequisites + `cargo tauri ohos build`（Rust 编译/.so/hvigorw/签名由 CLI 处理）。项目专属 feature 经 `TAURI_BUILD_FEATURES` 传入 |
 | `install.sh` | 仅安装启动（使用已签名 HAP），不构建不签名。日常流程已被 `cargo tauri ohos run` 替代；保留供单独安装场景 |
 
+## openharmony-ability ArkTS 源码修改后的完整生效流程
+
+修改了 `openharmony-ability/` 下的 **ArkTS 源码**（非 Rust）后，HAR 必须重建，否则 entry 模块仍引用 stale HAR（新代码从未编译进 HAP）。
+
+### ⚠️ 必须改真实源，不要改 package/ 镜像
+
+`openharmony-ability/package/` 是 **pack.bat 的产物**，不是源！`pack.bat` 每次运行会：
+1. `rmdir /s /q package\src\main\ets` 删掉整个 package ets 源
+2. 从 `native_ability/src/main/ets/` 重新拷贝
+3. `pack-plugins.ps1` 从 `plugins/<name>/src/main/ets/` 重新拷贝每个插件源，并改写 import 路径（`@ohos-rs/ability` → `../../ability_exports`）
+
+**真实源位置**：
+- 基础能力（ArkHelper/WindowManager/menu.ets/helper/*）：`openharmony-ability/native_ability/src/main/ets/`
+- 桥接插件（WebviewPlugin/StatusbarPlugin/MenuPlugin 等 13 个）：`openharmony-ability/plugins/<name>/src/main/ets/<PluginClass>.ets`
+
+改 package/ 镜像会被下次 pack.bat 覆盖，改动丢失。改源后必须跑 pack.bat 才能让改动进 HAR。
+
+### 完整流程
+
+```bash
+cd ${PROJECT_ROOT}/openharmony-ability
+source ${PROJECT_ROOT}/tauri/.claude/skills/ohos-build/scripts/env.sh
+./pack.bat            # Windows 批处理：同步 native_ability ETS → package/ + 13 插件聚合 + tar 打 ability.har
+# 验证 HAR 含新代码（HAR 是 tar.gz 不是 zip）：
+#   cp ability.har /tmp/x.tar.gz && cd /tmp && mkdir hc && cd hc && tar -xzf x.tar.gz
+#   grep -c "你的标记" package/src/main/ets/...
+cd ${PROJECT_ROOT}/tauri/examples/api/src-tauri
+cargo tauri ohos build --device-type desktop --features prod
+```
+
+`cargo tauri ohos build/run` 内部自动跑 ohpm install 同步依赖（受 `oh-package-lock.json5` 约束）。**严禁手动 `ohpm install` / `rm -rf oh_modules/@ohos-rs+ability`** —— 会删 lock、清空 `oh_modules/@tauri/` junction、误删本地包，导致 00304056 / 00625003。改 HAR 后只需重新 `cargo tauri ohos build`，CLI 会检测 HAR 变化并重新装包。
+
+> 也可用 `run-tests.sh`，其 Step 0 自动检测 openharmony-ability 源码变更并重建 HAR，无需手动 pack。
+
+### pack.bat 执行注意（Windows 批处理吃字符陷阱）
+
+git bash / PowerShell 直接跑 `pack.bat` 会**吃掉前 2 字符**（`set`/`del`/`xcopy` 等行静默 no-op），导致 package 同步不完整但 pack.bat exit=0 假成功。必须用 **cmd.exe 显式调用**：
+```bash
+cmd.exe //c "D:\\xuqiu\\tauri-3.0\\openharmony-ability\\pack.bat"
+```
+跑完后手动校验 package 镜像 diff 是否与源一致，或验证 HAR 内含新代码标记。
+
 ## 模板修改后的完整生效流程
 
 修改了 `crates/tauri-cli/templates/mobile/open-harmony/` 下的模板文件后，需要：

.claude/skills/ohos-build/scripts/env.sh

@@ -80,6 +80,28 @@ export PATH="$DEVECO_HOME/jbr/bin:$PATH:$DEVECO_HOME/tools/hvigor/bin:$DEVECO_HO
 OHOS_CLANG=$(echo "$OHOS_HOME/native/llvm/bin/clang.exe" | sed 's|^/\(.\)/|\U\1:\\|; s|/|\\|g')
 OHOS_SYSROOT=$(echo "$OHOS_HOME/native/sysroot" | sed 's|^/\(.\)/|\U\1:\\|; s|/|\\|g')
 OHOS_AR=$(echo "$OHOS_HOME/native/llvm/bin/llvm-ar.exe" | sed 's|^/\(.\)/|\U\1:\\|; s|/|\\|g')
+
+# 转 8.3 短路径（去除空格），避免 cc-rs 对 CFLAGS 字符串分词时
+# 把 "C:\Program Files\..." 按空格拆断。短路径在本机恒定存在。
+to_short_path() {
+    local p="$1"
+    # 仅当路径含空格时才转；不含空格直接返回原值
+    if [[ "$p" == *" "* ]]; then
+        # powershell FSO ShortPath，失败则回退原值
+        local short
+        short=$(powershell.exe -NoProfile -Command "(New-Object -ComObject Scripting.FileSystemObject).GetFolder('$p').ShortPath" 2>/dev/null | tr -d '\r')
+        if [ -n "$short" ]; then
+            echo "$short"
+            return
+        fi
+    fi
+    echo "$p"
+}
+
+OHOS_CLANG=$(to_short_path "$OHOS_CLANG")
+OHOS_SYSROOT=$(to_short_path "$OHOS_SYSROOT")
+OHOS_AR=$(to_short_path "$OHOS_AR")
+
 export CC_aarch64_unknown_linux_ohos="$OHOS_CLANG"
 export CFLAGS_aarch64_unknown_linux_ohos="--target=aarch64-linux-ohos --sysroot=$OHOS_SYSROOT -D__MUSL__"
 export AR_aarch64_unknown_linux_ohos="$OHOS_AR"

.claude/skills/ohos-build/scripts/rebuild-har-and-deploy.sh

@@ -0,0 +1,37 @@
+#!/bin/bash
+# Rebuild openharmony-ability HAR (DefaultWebview.ets changed) → refresh ohpm+junctions → build HAP → install.
+set -euo pipefail
+
+SKILL_SCRIPTS="/d/xuqiu/tauri-3.0/tauri/.claude/skills/ohos-build/scripts"
+ABILITY_DIR="/d/xuqiu/tauri-3.0/openharmony-ability"
+OHOS_PROJECT="/d/xuqiu/tauri-3.0/tauri/examples/api/src-tauri/gen/ohos"
+
+echo "=== sourcing env.sh ==="
+source "$SKILL_SCRIPTS/env.sh"
+echo "PROJECT_ROOT=$PROJECT_ROOT  OHOS_DEVICE_TYPE=$OHOS_DEVICE_TYPE"
+
+echo "=== 1/4 rebuild HAR ==="
+cd "$ABILITY_DIR"
+ohrs build --arch arm64 --skip-napi-check 2>&1 | tail -8 || true
+bash scripts/pack.sh 2>&1 | tail -4
+tar -czf ability.har package
+ls -la ability.har
+
+echo "=== 2/4 refresh ohpm + @tauri junctions ==="
+cd "$OHOS_PROJECT"
+ohpm install --all 2>&1 | tail -4
+# rebuild @tauri junctions (ohpm install deletes them — SKILL #11)
+mkdir -p oh_modules/@tauri
+for pkg in app notification global-shortcut dialog; do
+  src=""; case $pkg in app) src="tauri" ;; *) src="$pkg" ;; esac
+  [ -d "$src" ] && cmd //c "mklink /J \"oh_modules\\@tauri\\$pkg\" \"$(pwd -W)\\$src\"" 2>/dev/null && echo "  junction @tauri/$pkg -> $src"
+done
+echo "HAR_REFRESH_DONE"
+
+echo "=== 3/4 build-ohos.sh (desktop, VITE_AUTOTEST=false) ==="
+OHOS_DEVICE_TYPE=desktop VITE_AUTOTEST=false bash "$SKILL_SCRIPTS/build-ohos.sh"
+
+echo "=== 4/4 sign-and-install.sh ==="
+bash "$SKILL_SCRIPTS/sign-and-install.sh"
+
+echo "=== ALL_DONE ==="