autowonder 0.3.22 → 0.3.23

package/README.md

@@ -6,10 +6,10 @@ AutoWonder 本地 agent runtime。安装后启动 daemon，持续轮询本地 as
 
 ```bash
 # Qoder CLI（模型使用 provider model ID；Context Window 使用固定档位）
-npx -y autowonder@0.3.22 connect --ws-url <wss-endpoint> --token <executor-token> --executor-id <executor-id> --provider qoder --model qmodel_latest --reasoning-effort medium --context-window 260000
+npx -y autowonder@0.3.23 connect --ws-url <wss-endpoint> --token <executor-token> --executor-id <executor-id> --provider qoder --model qmodel_latest --reasoning-effort medium --context-window 260000
 
 # Qoder CLI CN
-npx -y autowonder@0.3.22 connect --ws-url <wss-endpoint> --token <executor-token> --executor-id <executor-id> --provider qodercn
+npx -y autowonder@0.3.23 connect --ws-url <wss-endpoint> --token <executor-token> --executor-id <executor-id> --provider qodercn
 ```
 
 `connect` 会安装当前 npm 包内置的 daemon，并使用页面生成的 WebSocket endpoint、Token 和执行器 ID 建立连接。客户端只支持通过 Qoder 系列 CLI 启动（`qoder` 对应 `qodercli`，`qodercn` 对应 `qodercn`），其他 `--provider` 取值会在启动 daemon 前直接报错拦截并提示 `Unsupported provider`。选择 Qoder CLI 或 Qoder CLI CN 时需要 Node.js 20+；runtime 会在缺少对应 CLI 时自动通过 npm 安装，并在尚未登录时打开浏览器登录。runtime 会继承当前用户的 HOME、环境变量和 CLI 登录状态。
@@ -119,6 +119,8 @@ npx -y autowonder@latest connect ...
 
 同版本空闲时用新参数 exec；切换到更高稳定版本要求二进制安装在 `~/.autowonder/bin/autowonder-daemon`，复用 npm tarball SHA-512、包版本、平台二进制和候选自检，再原子切换。失败保留原程序并在支持的故障路径回滚，不支持在线降级。源码构建仅支持保持当前版本的参数应用，Windows 不声明在线应用能力。旧客户端需要先本地安装一次支持版本。
 
+启动命令可携带可选的 `restartMode`，取值为 `WHEN_IDLE` 或 `FORCE`。未提供时仅在本机完全空闲时应用，繁忙时拒绝并回执失败；`WHEN_IDLE` 会立即关闭接单入口，等待运行中任务与会话结束后再重启，等待期间每 30 秒以 `EXECUTOR_RESTART_RESULT` 的 `WAITING_IDLE` 状态回执；`FORCE` 同样立即关闭接单入口，但不等运行中任务，仍要求结果 outbox 可读后立即重启。非法取值会在产生任何重启副作用前被拒绝。Linux/macOS 执行器在心跳中通过 `EXECUTOR_RESTART_POLICY_V1` 声明支持该策略。
+
 工作目录切换前必须没有运行/恢复任务，且原目录的结果 outbox 已全部确认；默认本地队列仍有待执行或已领取任务时也会拒绝切换。目标目录必须可写；历史任务文件保留在原目录，不自动迁移或删除。未指定目录和名称时在线应用沿用当前值，仅更新其他参数不会移动本地队列。
 
 候选版本缓存在 `~/.autowonder/updates/`；当前二进制和单个回滚副本位于 `~/.autowonder/bin/`。`GET /health` 会返回 `daemonVersion`、`updateState`、`updateTarget` 和 `updateError`。
@@ -127,7 +129,7 @@ daemon 建立连接时和每次心跳定时检查时发出的 `HEARTBEAT` 帧都
 
 同一批 `HEARTBEAT` 帧还带上 `model` 字段，取值为 daemon 当前生效的默认模型（`--model` 经 `AUTOWONDER_MODEL` 注入的 `cfg.DefaultModel`，即派单未指定模型时实际使用的取值）；该值为空时字段不出现在帧里。服务端据此在执行器列表展示每台执行机当前使用的底层模型，与上面的 `version` 上报同一条通路。对执行机用户同样无新增参数或环境变量。
 
-同一批 `HEARTBEAT` 帧还带上进程级固定的 `startedAt`（重连不重置）与继承自 re-exec 的 `restartRequestId`，并在能力位里声明 `EXECUTOR_RESTART_V1`（Windows 不声明）；接入自动更新的 daemon 额外声明 `EXECUTOR_UPDATE_RESTART_V1`。服务端可据此下发 `EXECUTOR_RESTART`（带 `executorId`、`requestId`、ISO UTC `issuedAt` 与布尔 `update`）。本机只接受 `executorId` 与自身一致、未过期且未处理过的请求，不接收任何远端 shell 命令、可执行路径或下载地址，并以 `EXECUTOR_RESTART_RESULT`（`UPDATING` / `RESTARTING` / `FAILED`）回执，真正是否成功以下一次心跳为准。重启走既有的接单闸门：有运行中任务或结果 outbox 未确认可读时不重启，re-exec 失败会重新开放接单；`update=true` 复用既有的 registry、完整性校验、候选 self-check、安装事务与回滚，仅标准安装的正式版支持远端拉取新版本，已是最新版的请求仍会重启，且该操作不应用平台上保存的启动配置改动。对执行机用户同样无新增参数或环境变量。
+同一批 `HEARTBEAT` 帧还带上进程级固定的 `startedAt`（重连不重置）与继承自 re-exec 的 `restartRequestId`，并在能力位里声明 `EXECUTOR_RESTART_V1` 与 `EXECUTOR_RESTART_POLICY_V1`（Windows 均不声明）；接入自动更新的 daemon 额外声明 `EXECUTOR_UPDATE_RESTART_V1`。服务端可据此下发 `EXECUTOR_RESTART`（带 `executorId`、`requestId`、ISO UTC `issuedAt` 与布尔 `update`）。本机只接受 `executorId` 与自身一致、未过期且未处理过的请求，不接收任何远端 shell 命令、可执行路径或下载地址，并以 `EXECUTOR_RESTART_RESULT`（`UPDATING` / `WAITING_IDLE` / `RESTARTING` / `FAILED`）回执，真正是否成功以下一次心跳为准。重启走既有的接单闸门：有运行中任务或结果 outbox 未确认可读时不重启，re-exec 失败会重新开放接单；`update=true` 复用既有的 registry、完整性校验、候选 self-check、安装事务与回滚，仅标准安装的正式版支持远端拉取新版本，已是最新版的请求仍会重启，且该操作不应用平台上保存的启动配置改动。对执行机用户同样无新增参数或环境变量。
 
 标准安装还支持服务端把整批执行机升级到指定的**已发布版本**（不再依赖各台机器安装时选定的版本），能力位为 `EXECUTOR_UPDATE_V1`。服务端下发 `EXECUTOR_UPGRADE`（带 `executorId`、`requestId`、ISO UTC `issuedAt` 与 `targetVersion`），本机只接受 `executorId` 与自身一致、`requestId` 非空且不超过 80 字符、`issuedAt` 在前后 1 分钟以内、且 `targetVersion` 为三段纯数字正式版的请求。升级按 `accepted` → `downloading` → `draining` → `applying` → `success` 逐阶段回执 `EXECUTOR_UPGRADE_RESULT`（含 `requestId`、`phase` 与该进程启动时的 `currentVersion`；新版本以下一个进程的首次心跳为准），失败则以 `failed` 帧带上错误原因——目标版本不受支持、请求过期、本机构建不支持远端升级等都会显式回执而不是静默丢弃。registry 按请求的版本号解析元数据并要求返回值与请求版本严格一致；请求版本低于当前版本时拒绝执行（服务端升级永不回滚整批执行机），已缓存但版本不符的候选不会被采用。`requestId` 会跨 re-exec 传递，服务端重放的同一请求不会触发第二次升级；同一 `requestId` 同时只允许一次尝试在飞，失败后可重试。升级复用既有的接单闸门、完整性校验、候选 self-check、安装事务与回滚。对执行机用户无新增参数或环境变量。
 
@@ -175,7 +177,7 @@ mv "$queue/.assignment.tmp" "$queue/assignment.json"
 也可以直接提交到本地 API：
 
 ```bash
-npx -y autowonder@0.3.22 dispatch ./assignment.json
+npx -y autowonder@0.3.23 dispatch ./assignment.json
 ```
 
 ## 上传工单附件
@@ -183,7 +185,7 @@ npx -y autowonder@0.3.22 dispatch ./assignment.json
 把本地需求/设计文档直接上传到工单，避免在会话里传递大文件：
 
 ```bash
-npx -y autowonder@0.3.22 workitem upload --server-url <autowonder-server-url> --workitem-id <id> --file <filepath-1> --file <filepath-2> --json
+npx -y autowonder@0.3.23 workitem upload --server-url <autowonder-server-url> --workitem-id <id> --file <filepath-1> --file <filepath-2> --json
 ```
 
 上传令牌通过 MCP 工具 `autowonder.workitem_cli_upload_token` 签发，经 `--token` 或 `AUTOWONDER_UPLOAD_TOKEN` 环境变量传入。`--file` 可重复指定多个文件；`--json` 输出机器可读结果。失败时按错误类型返回不同退出码（401→3、403→4、404→5、409→6、413→7、其他 4xx→8、网络/重定向→9）。
@@ -193,7 +195,7 @@ npx -y autowonder@0.3.22 workitem upload --server-url <autowonder-server-url> --
 把工单上已有的需求/设计文档下载到本地目录，再用本地文件工具阅读，避免把大文件或二进制附件搬进会话上下文：
 
 ```bash
-npx -y autowonder@0.3.22 workitem download --server-url <autowonder-server-url> --workitem-id <id> --file <name-or-id> --output-dir <dir> --json
+npx -y autowonder@0.3.23 workitem download --server-url <autowonder-server-url> --workitem-id <id> --file <name-or-id> --output-dir <dir> --json
 ```
 
 下载令牌通过 MCP 工具 `autowonder.workitem_cli_download_token` 签发（与上传令牌相互独立），经 `--token` 或 `AUTOWONDER_DOWNLOAD_TOKEN` 环境变量传入。`--file` 可重复指定文档名或 artifact id，省略则下载该工单的全部附件；`--output-dir` 默认为当前目录；`--json` 输出机器可读结果，含每个文件的 `id`、`name`、`path`、`size`。退出码约定与 `workitem upload` 相同（401→3、403→4、404→5、409→6、413→7、其他 4xx→8、网络/重定向→9）。
@@ -203,7 +205,7 @@ npx -y autowonder@0.3.22 workitem download --server-url <autowonder-server-url>
 把需求/设计文档上传到 7x24 定时任务，用法与工单附件一致（同一套上传令牌与预检规则）：
 
 ```bash
-npx -y autowonder@0.3.22 scheduled-task upload --server-url <autowonder-server-url> --scheduled-task-id <id> --file <filepath-1> --file <filepath-2> --json
+npx -y autowonder@0.3.23 scheduled-task upload --server-url <autowonder-server-url> --scheduled-task-id <id> --file <filepath-1> --file <filepath-2> --json
 ```
 
 上传令牌同样通过 `autowonder.workitem_cli_upload_token` 签发（令牌为用户级，对当前可修改的任意定时任务生效），经 `--token` 或 `AUTOWONDER_UPLOAD_TOKEN` 传入；退出码约定与 `workitem upload` 相同。
@@ -211,8 +213,8 @@ npx -y autowonder@0.3.22 scheduled-task upload --server-url <autowonder-server-u
 ## 管理 daemon
 
 ```bash
-npx -y autowonder@0.3.22 status
-npx -y autowonder@0.3.22 stop
+npx -y autowonder@0.3.23 status
+npx -y autowonder@0.3.23 stop
 ```
 
 默认 API 是 `http://127.0.0.1:34989`，日志位于 `~/.autowonder/daemon.log`。npm 包不包含任何 agent、MCP 或服务端凭证。
@@ -235,7 +237,7 @@ daemon 内置独立于工作区 GC 的保留清扫：默认每小时运行一次
 ## 调试
 
 ```bash
-npx -y autowonder@0.3.22 connect ... --debug
+npx -y autowonder@0.3.23 connect ... --debug
 ```
 
 `--debug` 会让 CLI 以 `AUTOWONDER_DEBUG=1` 启动 daemon，把完整的 daemon 与 agent 活动（runtime 事件流、provider 事件解码、重试退避与会话门等待、空闲时的阻塞点）同时输出到控制台和会话调试日志。调试日志不做脱敏，仅用于本机排障；不传 `--debug` 时该环境变量不会注入。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "autowonder",
-  "version": "0.3.22",
+  "version": "0.3.23",
   "description": "AutoWonder local runtime — execute AI agent dispatch packages on your machine",
   "bin": {
     "autowonder": "bin/cli.js"