@stalfh233/omc-cli 0.4.11 → 0.4.13

package/README.md

@@ -246,12 +246,12 @@ src/        args/support/plan/read/write/package/context（治理管道）
 
 ## npm 分发
 
-本包（`@stalfh233/omc-cli`，可执行命令仍是 `omc`）通过公共 npm registry 分发。`omc-core` 是 `omc-cli` 的内部依赖，发布时先发 `omc-core`，再发 `omc-cli`；两者版本保持一致。当前版本为 `0.4.11`，尚未宣称 `1.0.0` 稳定契约。
+本包（`@stalfh233/omc-cli`，可执行命令仍是 `omc`）通过公共 npm registry 分发。`omc-core` 是 `omc-cli` 的内部依赖，发布时先发 `omc-core`，再发 `omc-cli`；两者版本保持一致。当前版本为 `0.4.13`，尚未宣称 `1.0.0` 稳定契约。
 
 ### 使用已发布包
 
 ```bash
-npm install -g @stalfh233/omc-cli@0.4.11
+npm install -g @stalfh233/omc-cli@0.4.13
 omc setup
 omc doctor
 omc help omc-write-hazards
@@ -270,6 +270,10 @@ npm publish --workspace packages/omc-cli
 
 `omc-core` 与 `omc-cli` 版本保持一致；发布前先用 `git tag vX.Y.Z` 记录该版本。新包首次发布进入 npm staged-publishing 审核队列，需维护者在 npmjs.com 用交互式 2FA 批准后真实版本才可见。
 
+### 输出编码
+
+stdout 是机器解析的 JSON：Windows 上默认把非 ASCII 转义成 `\uXXXX`（纯 ASCII，在 GBK 控制台也不会乱码，等价于 Python `json.dumps(ensure_ascii=True)`），Linux/macOS 保持原始 UTF-8。UTF-8 终端想要可读中文时设 `OMC_ASCII_STDOUT=0`。`--out` 文件、artifact、stderr、CloudPivot 请求体始终是原始 UTF-8。
+
 ### 版本策略
 
 - `0.2.x`：继续演进 CLI/覆盖清单/配置契约，允许新增能力和必要的行为修复。

package/dist/cli-contract.js

@@ -13,14 +13,21 @@ export function envelope(status, result, requestId, error = null) {
 /**
  * The single stdout serialization for every envelope.
  *
- * On zh-CN Windows, PowerShell decodes a native process's bytes with the legacy
- * console code page and mangles UTF-8 Chinese ("付文�?"), which forces callers
- * into a "write to file, then re-read" workaround. When `OMC_ASCII_STDOUT`
- * resolves on, non-ASCII is escaped to `\uXXXX`: stdout stays pure ASCII and
- * decodes identically under any code page while still parsing to the original
- * string. It is on by default only on win32, so Linux output keeps its smaller
- * UTF-8 bytes. Override with `OMC_ASCII_STDOUT=1|0`. Artifacts keep raw UTF-8 —
- * they are files, not a console stream. See `CONTEXT.md` → Agent-facing CLI.
+ * stdout is machine-parsed JSON, so it must decode identically for ANY consumer
+ * regardless of the ambient console code page. On zh-CN Windows the console is
+ * GBK (cp936), and a native process's bytes are decoded with that code page — by
+ * the terminal for direct output, and by PowerShell's `[Console]::OutputEncoding`
+ * for `$x = omc …` / `omc … > f` / `omc … | …`. Raw UTF-8 Chinese is mangled
+ * there (verified on Windows PowerShell 5.1 AND PowerShell 7.6). Escaping every
+ * non-ASCII code unit to `\uXXXX` makes stdout pure ASCII, so it survives any
+ * code page and still `JSON.parse`s back to the original string. This is the
+ * same conservative default as Python's `json.dumps(ensure_ascii=True)`.
+ *
+ * Escaping is ON by default only on win32; POSIX keeps its smaller raw UTF-8
+ * bytes. Override with `OMC_ASCII_STDOUT=1|0` (set `0` on a UTF-8 terminal to
+ * get readable Chinese). `--out` files, artifacts, stderr, and the CloudPivot
+ * wire stay raw UTF-8 — they are not a code-page-bound console stream. See
+ * `CONTEXT.md` → Agent-facing CLI.
  */
 export function asciiStdout() {
     const override = process.env.OMC_ASCII_STDOUT;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stalfh233/omc-cli",
-  "version": "0.4.11",
+  "version": "0.4.13",
   "description": "CloudPivot 8.6 configuration capability CLI — governed, fail-closed, coverage-manifest bounded.",
   "type": "module",
   "bin": {
@@ -51,7 +51,7 @@
   },
   "dependencies": {
     "commander": "14.0.3",
-    "omc-core": "0.4.11",
+    "omc-core": "0.4.13",
     "proper-lockfile": "4.1.2",
     "write-file-atomic": "6.0.0",
     "zod": "^3.23.8",