cj-tauri 1.1.2 → 2.0.0

package/README.md

@@ -5,6 +5,7 @@
 WebView 宿主、IPC 双向桥（`invoke` / `resolve` / `event`）、能力安全模型（capability 白名单）。
 
 - 仓库与完整文档：<https://atomgit.com/qq8864/cj-tauri>
+- 当前版本：**2.0.0**（主版本：删除了已失效的 `setHostFactory` / `requireInjectedHost`，见文末「2.0.0 变更」）
 - 当前状态：**Windows（WebView2）、Linux（WebKitGTK）与鸿蒙 PC（ArkWeb）均已实机跑通**
 
 ## 前置条件：仓颉 SDK
@@ -13,7 +14,7 @@ WebView 宿主、IPC 双向桥（`invoke` / `resolve` / `event`）、能力安
 把你的应用编译出来。所以请先装 SDK（验证版本 **1.2.0**，含 **stdx**），并让本包能找到它：
 
 ```bash
-# Linux / macOS
+# Linux
 export CANGJIE_HOME=/opt/cangjie/cangjie
 
 # Windows cmd
@@ -21,7 +22,15 @@ set CANGJIE_HOME=D:\Program Files (x86)\Cangjie
 ```
 
 不设 `CANGJIE_HOME` 时，本包会探测常见安装位置（Windows `D:\Program Files (x86)\Cangjie`、
-Linux `/opt/cangjie/cangjie`）。装好后自检：
+Linux `/opt/cangjie/cangjie`）。另外两个变量视情况给：
+
+| 变量 | 什么时候需要 |
+|---|---|
+| `CJ_TAURI_ROOT` | 不在 cj-tauri 仓库内运行、又找不到框架根目录时（`create` 要把框架路径写进工程） |
+| `CANGJIE_STDX` | 应用的 `cjpm.toml` 用 `${CANGJIE_STDX}` 展开 stdx 路径；本包会从框架/工程的 toml 里探测，探不到就照此变量 |
+| `CANGJIE_STDX_OHOS` | 只在构建鸿蒙工程时用（鸿蒙版 stdx，`build-hap.sh` 按它找动态库） |
+
+装好后自检：
 
 ```bash
 npx cj-tauri info        # 打印框架 / 项目 / stdx / SDK / cjpm / C 桥 的解析结果
@@ -33,46 +42,69 @@ npx cj-tauri info        # 打印框架 / 项目 / stdx / SDK / cjpm / C 桥 的
 ## 用法
 
 ```bash
-npx cj-tauri create myapp          # 创建项目（默认模板：内联 HTML，零 Node）
+npx cj-tauri create myapp --template app     # 内联 HTML，零 Node（缺省模板）
 cd myapp
-npx cj-tauri dev                   # 构建 C 桥 + cjpm build + 启动窗口
+npx cj-tauri sync                            # 按清单派生 targets/ 骨架（首次；重跑幂等）
+npx cj-tauri dev                             # 构建 C 桥 + cjpm build + 启动窗口
 
-npx cj-tauri create myapp-vue --template vue      # Vue 3 + Vite
+npx cj-tauri create myapp-vue --template vue      # Vue 3 + Vite（前端工程在 assets/ui/）
 npx cj-tauri create myapp-react --template react  # React 18 + Vite
 
-npx cj-tauri create myohos --template ohos        # 鸿蒙 PC（2in1）工程：ArkWeb 宿主 + build-hap.sh
+npx cj-tauri create myohos --template ohos        # 鸿蒙 PC：同一份业务代码 + targets/ohos
 npx cj-tauri create myohos --template ohos --bundle com.example.myapp --label "我的应用"
 
 npm i -g cj-tauri                  # 也可以全局安装，之后直接用 cj-tauri <子命令>
 ```
 
+**一份业务代码，骨架按目标派生**——`create` 只生成清单与业务侧，平台骨架是 `sync` 的产物：
+
+```
+myapp/
+├── cj-tauri.toml           # 应用清单——单一真相（id/version/窗口/资产/能力目录）
+├── cjpm.toml               # 业务包（static 库；骨架以 path 依赖引用）
+├── src/main.cj             # 业务装配点 build(): AppSpec（零平台知识）
+├── assets/
+│   ├── ui/index.html       # 前端页面（任意 Web 技术栈）
+│   └── capabilities/default.json   # 能力白名单（命令 / 事件 / 权限集）
+└── targets/                # cj-tauri sync 生成（勿手改；check 判漂移）
+    ├── desktop/            #   桌面可执行（launcher 调 build()）
+    └── ohos/               #   鸿蒙 hap 工程（DevEco + build-hap.sh）
+```
+
 | 子命令 | 作用 |
 |---|---|
-| `create <项目名> [--template app\|vue\|react\|ohos]` | 生成工程（桌面模板：`src/` + `ui/` + `capabilities/` + `cjpm.toml`；`ohos` 见下一节） |
-| `dev` | 构建 C 桥 + `cjpm build` + 启动应用；Vite 模板会接管 dev server（HMR）；鸿蒙工程转交 `build-hap.sh` |
-| `build` | 构建 C 桥 + `cjpm build`；鸿蒙工程转交 `build-hap.sh` |
-| `run` | 运行已构建产物；鸿蒙工程转交 `build-hap.sh --install`（构建 + 装机 + 启动） |
-| `info` | 环境自检（排障先跑它） |
+| `create <项目名> [--template app\|vue\|react\|ohos]` | 生成统一工程（清单 + `src/` + `assets/`）；`--bundle` / `--label` 只对 `ohos` 模板有意义，缺省由项目名推导 |
+| `sync [desktop\|ohos]` | 按清单派生 `targets/` 骨架（缺省两端都派生；幂等重跑） |
+| `dev` | 构建 C 桥 + `cjpm build` + 启动应用；Vite 模板会接管 dev server（HMR） |
+| `build` | 构建 C 桥 + `cjpm build`；鸿蒙端在 `targets/ohos` 里 `bash build-hap.sh` |
+| `run` | 运行已构建产物；鸿蒙端 `bash build-hap.sh --install`（构建 + 装机 + 拉起） |
+| `check` | 校验 `cj-tauri.toml`（id / 窗口 / 资产存在）+ `targets/` 骨架漂移 + 插件三方比对 |
+| `info [--json]` | 环境自检（排障先跑它）；`--json` 只输出插件清单，机器可读 |
+| `doctor` | 环境自检逐行给结论（每条自带「缺了就怎么办」） |
 | `help` | 帮助 |
 
 ## 鸿蒙 PC（`--template ohos`）
 
 同一套框架换个宿主：桌面用 WebView2 / WebKitGTK，鸿蒙 PC 用 **ArkWeb**，上层页面、命令层、能力校验不用改。
+`--template ohos` 生成的仍是那种**统一工程**（`cj-tauri.toml` + `src/` + `assets/`），只是清单里带鸿蒙端信息
+（`[app] id` 就是 `bundleName`）；DevEco 工程是 `sync` 的产物，落在 `targets/ohos/`：
 
 ```bash
-npx cj-tauri create myohos --template ohos
+npx cj-tauri create myohos --template ohos --bundle com.example.myapp --label "我的应用"
 cd myohos
-bash build-hap.sh --install        # 构建 hap + hdc 装机 + aa start；等价于 npx cj-tauri run
+npx cj-tauri sync ohos             # 派生 targets/ohos（DevEco 骨架 + rawfile 里的页面与能力清单）
+cd targets/ohos
+bash build-hap.sh --install        # 构建 hap + hdc 装机 + aa start
 ```
 
-生成的是标准 DevEco 工程（`entry/` + `AppScope/` + `build-profile.json5` + `hvigorfile.ts`），
+`targets/ohos/` 是标准 DevEco 工程（`entry/` + `AppScope/` + `build-profile.json5` + `hvigorfile.ts`），
 鸿蒙相关的那层很薄：
 
 | 路径 | 作用 |
 |---|---|
 | `entry/src/main/cangjie/main_ability.cj` | UIAbility：`ArkWebRuntime.configure(filesDir)` → 非 UI 线程 `spawn { run() }` → 等宿主登记再 `loadContent` |
-| `entry/src/main/cangjie/index.cj` | `@Component` 的 ArkWeb 宿主 + 双向桥（**必须住应用模块**，框架包引用 ArkUI 会启动即崩） |
-| `entry/src/main/resources/rawfile/` | `index.html`（页面真文件）与 `capabilities.json`（能力清单） |
+| `entry/src/main/cangjie/app_host.cj` | `@Component` 的 ArkWeb 宿主 + 双向桥（**必须住应用模块**，框架包引用 ArkUI 会启动即崩）；调你 `assets/` 里那份业务 `build()` |
+| `entry/src/main/resources/rawfile/` | `index.html` 与能力清单（从 `assets/` 拷进来的真文件） |
 | `build-hap.sh` | 唯一构建入口：探测 DevEco / stdx、`--no-daemon` 跑 hvigor、可选 `--install` |
 
 前置两件事：
@@ -87,7 +119,8 @@ bash build-hap.sh --install        # 构建 hap + hdc 装机 + aa start；等价
 
 已知限制：签名要在 DevEco 里配（命令行不做自动签名，换 `bundleName` 需重新签）；同一份调试签名下两个
 工程会互相顶掉安装位；单窗口、暂无原生对话框（那两条能力位如实返回 0）；没有可用的 C 桥，
-`launchHidden` / 串口 / 托盘这类宿主能力在鸿蒙上不提供。
+`launchHidden` / 串口 / 托盘这类宿主能力在鸿蒙上不提供。改完 `assets/` 里的页面或能力清单要重跑
+`cj-tauri sync ohos`（`targets/` 是生成物，`check` 会报漂移）。
 
 真机上怎么自证它通了（hilog，`CjTauri` tag）：
 
@@ -104,11 +137,24 @@ main window keeps system default 2090x1394 px at density 190% on screen 3120x208
 - **环境自检**：`cjpm` 与 SDK 运行时库的定位、`PATH` / `LD_LIBRARY_PATH` 的拼装都在这里完成；
 - **CLI 本体的获取**：优先用包内预编译二进制（`prebuilt/<平台-架构>/`），没有则把 CLI 源码拷到
   `~/.cache/cj-tauri/<版本>/` 下用本机 `cjpm build` 一次并缓存 —— 不往安装目录写产物，避免全局安装只读；
-- **数据目录**：Linux/macOS 用 `$XDG_CACHE_HOME/cj-tauri`（默认 `~/.cache/cj-tauri`），Windows 用 `%LOCALAPPDATA%\cj-tauri`。
+- **数据目录**：Linux 用 `$XDG_CACHE_HOME/cj-tauri`（默认 `~/.cache/cj-tauri`），Windows 用 `%LOCALAPPDATA%\cj-tauri`。
 
 已知限制：首次 `dev` / `build` 会把 C 桥构建到**框架目录的 `native/`** 下（应用 `cjpm.toml` 的
 链接参数指向那里），所以包安装目录需要可写；如果装在只读路径下，请改用仓库内运行方式。
 
+## 2.0.0 变更
+
+- **不兼容**：删除已失效的公开 API `setHostFactory` / `requireInjectedHost`（框架侧单槽宿主注入）。
+  源码里仍在调用它们的应用会编译失败——那些调用本来也不生效（`requireInjectedHost` 没有任何调用方）。
+  多宿主注入走 `registerHost(HostProvider)`（带优先级），鸿蒙宿主已内置。
+- **修复**：`sync` 生成的工程在 Windows 上编不过（TOML 路径保留反斜杠触发 `errLexEscape`、鸿蒙 entry 的
+  `compile-option` 内层引号未转义、生成源码里 `url=\"…\"` 少一层转义）；`cj-tauri check` 的三方比对在
+  Windows 上因产物名 `main.exe` 恒被跳过；示例 `modbus-poll` 缺串口插件 import。
+- **门禁**：版本校验从五处扩到六处（新增官网 `website/index.html`），并给与 `docs/` 同源的图片 / 图
+  加上了逐字节比对——官网是独立拷贝、此前不在门禁里，正是它漏更的根因。
+
+完整变更见仓库的 `CHANGELOG.md` 的 `[2.0.0] - 2026-10-23`。
+
 ## License
 
 [MIT](https://atomgit.com/qq8864/cj-tauri/blob/main/LICENSE) © 2026 yangyongzhen

package/cjpm.toml

@@ -1,52 +1,52 @@
-[package]
-  cjc-version = "1.0.5"
-  name = "cjTauri"
-  description = "仓颉版 Tauri：轻量跨端混合开发框架（WebView 宿主 + IPC 桥 + 能力安全模型）"
-  version = "1.1.2"
-  target-dir = ""
-  output-type = "static"
-  compile-option = ""
-  override-compile-option = ""
-  link-option = ""
-  package-configuration = {}
-
-[dependencies]
-
-[target.x86_64-unknown-linux-gnu]
-  # -lsqlite3：sqlite 插件直连发行版系统库（D-018 第 8 条）；Windows 侧未落地，故 mingw 段不加
-  link-option = "-Lnative -lcjtbridge -lsqlite3 -lwebkit2gtk-4.1 -lgtk-3 -lgdk-3 -lglib-2.0 -lgio-2.0 -lsoup-3.0 -ljavascriptcoregtk-4.1 -lgobject-2.0"
-
-[target.x86_64-unknown-linux-gnu.bin-dependencies]
-    path-option = ["${CANGJIE_STDX}"]
-
-[target.x86_64-w64-mingw32]
-  # -lsqlite3：sqlite 插件子包需要（导入库 libsqlite3.a 由 sqlite3.def 生成，DLL 本身不入库——
-  # 跑 sqlite 相关测试/应用时本机自备 native/sqlite3.dll；不碰 sqlite 的应用不引用它就不链接）
-  link-option = "-Lnative -lcjtbridge -lsqlite3"
-
-[target.x86_64-w64-mingw32.bin-dependencies]
-    path-option = ["${CANGJIE_STDX}"]
-
-[target.aarch64-linux-ohos]
-  # 鸿蒙目标（真机 / 鸿蒙 PC）：交叉编译工具链与 sysroot 由 DevEco 仓颉套件提供，
-  # 四个路径全部走环境变量展开——hvigor 构建时由插件注入前两个，命令行交叉编译时自行 export 同名变量。
-  # 照抄 DevEco 生成的工程（TestCj2）同一串参数，避免两套口径。
-  # 末尾的 `--dy-std` 不可省：鸿蒙上应用模块（entry）是 `output-type = "dynamic"` 且用动态 std，
-  # 框架包若按默认的静态 std 编，两者混进同一个 .so 就会出现**两套 std 运行时**——表象是
-  # 启动即崩在框架包全局初始化（`cjTauri::package_global_init` → 跨包 `_CGP*` 包初始化符号
-  # 解析到模块内偏移、跳到未映射地址 0x50xxx），窗口起不来且 hilog 只有一行 SIGSEGV。
-  # 只加在鸿蒙段：桌面两平台仍是静态 std，产物形态不变。
-  compile-option = "-B \"${DEVECO_CANGJIE_HOME}/build-tools/third_party/llvm/bin\" -B \"${DEVECO_OH_NATIVE_HOME}/sysroot/usr/lib/aarch64-linux-ohos\" -L \"${DEVECO_OH_NATIVE_HOME}/sysroot/usr/lib/aarch64-linux-ohos\" -L \"${DEVECO_OH_NATIVE_HOME}/llvm/lib/clang/15.0.4/lib/aarch64-linux-ohos\" -L \"${DEVECO_OH_NATIVE_HOME}/llvm/lib/aarch64-linux-ohos\" --sysroot \"${DEVECO_OH_NATIVE_HOME}/sysroot\" --dy-std"
-
-[target.aarch64-linux-ohos.bin-dependencies]
-    # stdx 必须用鸿蒙版（官方发布 cangjie-stdx-ohos-aarch64-<cjc 版本>.zip，桌面版 ABI 不通）；
-    # CANGJIE_OHOS_LIBS 指 DevEco 套件的 api/lib/linux_ohos_aarch64_cjnative/ohos（仓颉标准库 + ohos API 绑定）。
-    #
-    # 后两项是 ArkUI 的**宏库**与 kit 绑定，hvigor 构建时由 cangjie-build-support 注入
-    # （cangjie-path-impl.js 的 getBuildEnvByAbi）：AARCH64_MACRO_LIBS = <sdk>/api/macro/ohos
-    # （`lib-macro_ohos.arkui.state_macro_manage.dll` 就在里面），AARCH64_KIT_LIBS =
-    # .../linux_ohos_aarch64_cjnative/kit。**宏库目录漏挂的症状极具误导性**：`@Component` 的
-    # 声明能解析到（.cjo 在 ohos 目录里），但宏实现库找不到，报的是
-    # `macro evaluation has failed for macro call 'Component'`——看着像「宏不能用在框架包里」。
-    # 命令行交叉编译时这两个变量要自己 export，取值见上。
-    path-option = ["D:/cangjie-stdx-ohos/linux_ohos_aarch64_cjnative/dynamic/stdx", "C:/Users/yang/.cangjie-sdk/6.1/cangjie/api/lib/linux_ohos_aarch64_cjnative/ohos", "${AARCH64_MACRO_LIBS}", "${AARCH64_KIT_LIBS}"]
+[package]
+  cjc-version = "1.0.5"
+  name = "cjTauri"
+  description = "仓颉版 Tauri：轻量跨端混合开发框架（WebView 宿主 + IPC 桥 + 能力安全模型）"
+  version = "2.0.0"
+  target-dir = ""
+  output-type = "static"
+  compile-option = ""
+  override-compile-option = ""
+  link-option = ""
+  package-configuration = {}
+
+[dependencies]
+
+[target.x86_64-unknown-linux-gnu]
+  # -lsqlite3：sqlite 插件直连发行版系统库（D-018 第 8 条）；Windows 侧未落地，故 mingw 段不加
+  link-option = "-Lnative -lcjtbridge -lsqlite3 -lwebkit2gtk-4.1 -lgtk-3 -lgdk-3 -lglib-2.0 -lgio-2.0 -lsoup-3.0 -ljavascriptcoregtk-4.1 -lgobject-2.0"
+
+[target.x86_64-unknown-linux-gnu.bin-dependencies]
+    path-option = ["${CANGJIE_STDX}"]
+
+[target.x86_64-w64-mingw32]
+  # -lsqlite3：sqlite 插件子包需要（导入库 libsqlite3.a 由 sqlite3.def 生成，DLL 本身不入库——
+  # 跑 sqlite 相关测试/应用时本机自备 native/sqlite3.dll；不碰 sqlite 的应用不引用它就不链接）
+  link-option = "-Lnative -lcjtbridge -lsqlite3"
+
+[target.x86_64-w64-mingw32.bin-dependencies]
+    path-option = ["${CANGJIE_STDX}"]
+
+[target.aarch64-linux-ohos]
+  # 鸿蒙目标（真机 / 鸿蒙 PC）：交叉编译工具链与 sysroot 由 DevEco 仓颉套件提供，
+  # 四个路径全部走环境变量展开——hvigor 构建时由插件注入前两个，命令行交叉编译时自行 export 同名变量。
+  # 照抄 DevEco 生成的工程（TestCj2）同一串参数，避免两套口径。
+  # 末尾的 `--dy-std` 不可省：鸿蒙上应用模块（entry）是 `output-type = "dynamic"` 且用动态 std，
+  # 框架包若按默认的静态 std 编，两者混进同一个 .so 就会出现**两套 std 运行时**——表象是
+  # 启动即崩在框架包全局初始化（`cjTauri::package_global_init` → 跨包 `_CGP*` 包初始化符号
+  # 解析到模块内偏移、跳到未映射地址 0x50xxx），窗口起不来且 hilog 只有一行 SIGSEGV。
+  # 只加在鸿蒙段：桌面两平台仍是静态 std，产物形态不变。
+  compile-option = "-B \"${DEVECO_CANGJIE_HOME}/build-tools/third_party/llvm/bin\" -B \"${DEVECO_OH_NATIVE_HOME}/sysroot/usr/lib/aarch64-linux-ohos\" -L \"${DEVECO_OH_NATIVE_HOME}/sysroot/usr/lib/aarch64-linux-ohos\" -L \"${DEVECO_OH_NATIVE_HOME}/llvm/lib/clang/15.0.4/lib/aarch64-linux-ohos\" -L \"${DEVECO_OH_NATIVE_HOME}/llvm/lib/aarch64-linux-ohos\" --sysroot \"${DEVECO_OH_NATIVE_HOME}/sysroot\" --dy-std"
+
+[target.aarch64-linux-ohos.bin-dependencies]
+    # stdx 必须用鸿蒙版（官方发布 cangjie-stdx-ohos-aarch64-<cjc 版本>.zip，桌面版 ABI 不通）；
+    # CANGJIE_OHOS_LIBS 指 DevEco 套件的 api/lib/linux_ohos_aarch64_cjnative/ohos（仓颉标准库 + ohos API 绑定）。
+    #
+    # 后两项是 ArkUI 的**宏库**与 kit 绑定，hvigor 构建时由 cangjie-build-support 注入
+    # （cangjie-path-impl.js 的 getBuildEnvByAbi）：AARCH64_MACRO_LIBS = <sdk>/api/macro/ohos
+    # （`lib-macro_ohos.arkui.state_macro_manage.dll` 就在里面），AARCH64_KIT_LIBS =
+    # .../linux_ohos_aarch64_cjnative/kit。**宏库目录漏挂的症状极具误导性**：`@Component` 的
+    # 声明能解析到（.cjo 在 ohos 目录里），但宏实现库找不到，报的是
+    # `macro evaluation has failed for macro call 'Component'`——看着像「宏不能用在框架包里」。
+    # 命令行交叉编译时这两个变量要自己 export，取值见上。
+    path-option = ["${CANGJIE_STDX_OHOS}", "${CANGJIE_OHOS_LIBS}", "${AARCH64_MACRO_LIBS}", "${AARCH64_KIT_LIBS}"]

package/cli/cjpm.toml

@@ -2,7 +2,7 @@
   cjc-version = "1.0.5"
   name = "cli"
   description = "cj-tauri CLI：脚手架 create / dev / build / run / info"
-  version = "1.1.2"
+  version = "2.0.0"
   target-dir = ""
   output-type = "executable"
   compile-option = ""
@@ -11,3 +11,12 @@
   package-configuration = {}
 
 [dependencies]
+
+[target.x86_64-unknown-linux-gnu.bin-dependencies]
+  path-option = ["${CANGJIE_STDX}"]
+
+[target.x86_64-w64-mingw32.bin-dependencies]
+  # 与根 cjpm.toml 同口径：CLI 也 import stdx.encoding.json，Windows 上缺这一段时
+  # cjpm 报的是 `root package 'cli' imports package 'stdx.encoding.json' … not added as a
+  # dependency in cjpm.toml`（看着像 toml 漏配，其实是 Windows 目标段没声明 stdx）。
+  path-option = ["${CANGJIE_STDX}"]

package/cli/src/doctor.cj

@@ -198,7 +198,8 @@ func cmdDoctor(): Int64 {
     match (projRoot) {
         case Some(proj) =>
             doctorLine(rep, CheckLevel.Ok, "项目根目录", proj, "")
-            match (findAppBinary(proj)) {
+            let newForm = exists(joinPath(proj, "cj-tauri.toml"))
+            match (findAppBinary(proj, newForm)) {
                 case Some(bin) =>
                     if (fwRoot.size > 0 && !appBinaryIsFresh(bin, fwRoot)) {
                                 doctorLine(rep, CheckLevel.Warn, "可执行产物", "${bin} [比框架源码旧]",
@@ -207,7 +208,8 @@ func cmdDoctor(): Int64 {
                         doctorLine(rep, CheckLevel.Ok, "可执行产物", bin, "")
                     }
                 case None =>
-                        doctorLine(rep, CheckLevel.Warn, "可执行产物", "未构建", "`cj-tauri build`")
+                        doctorLine(rep, CheckLevel.Warn, "可执行产物", "未构建",
+                            if (newForm) { "`cj-tauri sync` + `cj-tauri build`" } else { "`cj-tauri build`" })
             }
         case None =>
             doctorLine(rep, CheckLevel.Warn, "项目根目录", "当前不在 cj-tauri 项目内",

package/cli/src/main.cj

@@ -8,15 +8,17 @@ func usage(): Unit {
     println("")
     println("用法:")
     println("  cj-tauri create <项目名> [--template <t>] [--bundle <bundleName>] [--label <应用名>]")
-    println("                             创建新项目（src/ + ui/ + capabilities/ + cjpm.toml）")
-    println("                             模板: app（内联单文件，缺省）/ vue / react")
-    println("                                   ohos（鸿蒙 PC / 2in1：ArkWeb 宿主 + build-hap.sh）")
+    println("                             创建新项目（cj-tauri.toml + src/ + assets/；骨架由 cj-tauri sync 派生）")
+    println("                             模板: app（内联单文件，缺省）/ vue / react（Vite 前端，作为资产）")
+    println("                                   ohos（鸿蒙生态：同形态统一工程，清单决定目标端）")
     println("                             --bundle / --label 只对 ohos 模板有意义（缺省由项目名推导）")
     println("  cj-tauri dev               构建 C 桥 + cjpm build + 启动应用（鸿蒙工程改走 build-hap.sh）")
     println("  cj-tauri build             构建 C 桥 + cjpm build（鸿蒙工程 = 编 hap）")
     println("  cj-tauri run               运行已构建产物（鸿蒙工程 = 装到设备并拉起）")
     println("  cj-tauri info [--json]     环境自检（排障用）；--json 只输出插件清单（机器可读）")
     println("  cj-tauri doctor            环境自检逐行给结论（每条自带「缺了就怎么办」）")
+    println("  cj-tauri check             校验 cj-tauri.toml（id/窗口/资产存在）+ targets 骨架漂移")
+    println("  cj-tauri sync [desktop|ohos]  按清单派生 targets 骨架（缺省两端都派生）")
     println("  cj-tauri help              显示本帮助")
     println("")
     println("环境变量:")
@@ -114,6 +116,12 @@ main(args: Array<String>): Int64 {
     if (sub == "doctor") {
         return cmdDoctor()
     }
+    if (sub == "check") {
+        return cmdCheck()
+    }
+    if (sub == "sync") {
+        return cmdSync(args)
+    }
     eprintln("未知子命令: ${sub}")
     println("")
     usage()