autowonder 0.2.159 → 0.2.161

package/README.md

@@ -6,10 +6,10 @@ AutoWonder 本地 agent runtime。安装后启动 daemon，持续轮询本地 as
 
 ```bash
 # Qoder CLI（模型使用 provider model ID；Context Window 使用固定档位）
-npx -y autowonder@0.2.159 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.2.161 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.2.159 connect --ws-url <wss-endpoint> --token <executor-token> --executor-id <executor-id> --provider qodercn
+npx -y autowonder@0.2.161 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 时需要 Node.js 20+；runtime 会在缺少 `qodercli` 时自动通过 npm 安装，并在尚未登录时打开 Qoder 浏览器登录。runtime 会继承当前用户的 HOME、环境变量和 CLI 登录状态。
@@ -76,6 +76,29 @@ daemon 建立连接时和每次心跳定时检查时发出的 `HEARTBEAT` 帧都
 
 标准安装还支持服务端把整批执行机升级到指定的**已发布版本**（不再依赖各台机器安装时选定的版本），能力位为 `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、安装事务与回滚。对执行机用户无新增参数或环境变量。
 
+## 任务环境变量快照
+
+平台可在派单（`dispatch` 帧）与会话回合（`CONVERSATION_TURN` 帧）里附带任务级环境变量快照（`environmentVariables`），经已认证的执行器 WebSocket 下发；runtime 会把快照叠加到 provider 子进程环境之上，任务按平台下发的取值运行。同名变量按不区分大小写的方式覆盖，保证同一任务在 Linux/macOS 与 Windows 上取值一致。
+
+- 变量名必须是合法标识符（`[A-Za-z_][A-Za-z0-9_]*`），否则派单在执行任何副作用之前失败。
+- runtime 与 provider 自有的变量不接受快照覆盖：`AUTOWONDER_*` 前缀（如 `AUTOWONDER_SCRATCH_DIR`、`AUTOWONDER_WORKSPACE_ROOT`），以及 `CODEX_HOME`、`CLAUDE_CONFIG_DIR`、`QODER_CONFIG_DIR`、`QODERCN_CONFIG_DIR`、`QODER_INTEGRATION_ID`、`QODER_HOST_SERVICE_NAME`。
+- 快照取值不写入本机磁盘：assignment 信封只保留 `ABSENT` / `EMPTY` / `REQUIRED` 状态标记，崩溃恢复时标记为 `REQUIRED` 的派单需要平台重新下发快照；本机历史遗留的明文信封会在读取时被改写为不含取值的标记形式。
+- 会话回合适用同一套规则，并把快照摘要并入 Qoder 进程复用指纹：快照变化时不会复用带旧环境的热进程。
+- 对执行机用户无新增命令行参数或环境变量。
+
+## 产物发布边界
+
+daemon 默认启用显式发布边界（`explicit_refs_v1`）：上传集合由完成请求里的精确引用与平台已知的交付契约推导，不再对 typed 产物目录做整树扫描，目录层级本身不再是发布依据。
+
+- `AUTOWONDER_SCRATCH_DIR` 指向当前 capsule 的 `artifacts/scratch/`，用于中间数据、临时命令输出和诊断工作文件；这些文件保持本地，不封存也不上传。
+- `AUTOWONDER_ARTIFACTS_OUTPUT_DIR` 指向 `artifacts/output/`，是候选产物的暂存区：把文件放进该目录不等于它会发布，未被引用的文件不会被读取、哈希、复制或上传，checkpoint 也不会携带。
+- 每一步尝试会把通过 admission 的集合封存为不可变快照（`artifacts/attempts/<step>/attempt-N/publish-manifest.json`）；删除文件后重新封存，新快照不再包含它，已由远端 receipt 代表的文件只引用、不重传。
+- 超预算的文本证据（如整段原始命令输出）会让步骤以 `fix_required` 结束，并在任何上传请求之前返回 `ARTIFACT_BUDGET_EXCEEDED`、`ARTIFACT_CLASS_REQUIRED`、`ARTIFACT_FILE_TOO_LARGE` 等稳定错误码；正确处置是发布精简报告或改用交付产物路径，而不是放宽本机限制。
+- 服务端可在派单里下发更严格的限制（`artifactProtocolVersion` = 2，以及每请求文件数与字节数、单文件、文本证据单文件与总量上限）；字段缺省时 runtime 使用保守默认值，旧服务端与旧执行器组合行为不变。
+- `AUTOWONDER_ARTIFACT_SELECTION_MODE=legacy_all_typed` 仅供平台 operator 在线上事故回滚时使用（设置后需重启 daemon），会恢复旧的目录级收集语义及其资源放大风险，问题解除后应立即移除；不得把它下发给客户 SDLC、Agent、Soul、提示词或 assignment 配置。
+
+checkpoint 使用 `autowonder.runtimeCheckpoint.v2`：相同 digest 的已发布字节只保存一份，恢复前在隔离 staging 中完整校验 manifest 与 payload 的对应关系。v2 reader 兼容历史 v1 checkpoint；旧版 runtime 会因 schema 不匹配拒绝 v2，需要回滚旧版时应选择保留的 v1 checkpoint，不能把 v2 改标成 v1。
+
 ## 发布构建
 
 `npm run build` 和发布脚本只接受没有已跟踪或未跟踪改动的 Git worktree。脚本会把准确的 release commit 克隆到仓库外的 detached checkout，再从该目录构建六个平台（darwin/linux/windows × amd64/arm64）的 daemon。
@@ -96,7 +119,7 @@ mv "$queue/.assignment.tmp" "$queue/assignment.json"
 也可以直接提交到本地 API：
 
 ```bash
-npx -y autowonder@0.2.159 dispatch ./assignment.json
+npx -y autowonder@0.2.161 dispatch ./assignment.json
 ```
 
 ## 上传工单附件
@@ -104,7 +127,7 @@ npx -y autowonder@0.2.159 dispatch ./assignment.json
 把本地需求/设计文档直接上传到工单，避免在会话里传递大文件：
 
 ```bash
-npx -y autowonder@0.2.159 workitem upload --server-url <autowonder-server-url> --workitem-id <id> --file <filepath-1> --file <filepath-2> --json
+npx -y autowonder@0.2.161 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）。
@@ -114,7 +137,7 @@ npx -y autowonder@0.2.159 workitem upload --server-url <autowonder-server-url> -
 把工单上已有的需求/设计文档下载到本地目录，再用本地文件工具阅读，避免把大文件或二进制附件搬进会话上下文：
 
 ```bash
-npx -y autowonder@0.2.159 workitem download --server-url <autowonder-server-url> --workitem-id <id> --file <name-or-id> --output-dir <dir> --json
+npx -y autowonder@0.2.161 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）。
@@ -124,7 +147,7 @@ npx -y autowonder@0.2.159 workitem download --server-url <autowonder-server-url>
 把需求/设计文档上传到 7x24 定时任务，用法与工单附件一致（同一套上传令牌与预检规则）：
 
 ```bash
-npx -y autowonder@0.2.159 scheduled-task upload --server-url <autowonder-server-url> --scheduled-task-id <id> --file <filepath-1> --file <filepath-2> --json
+npx -y autowonder@0.2.161 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` 相同。
@@ -132,8 +155,8 @@ npx -y autowonder@0.2.159 scheduled-task upload --server-url <autowonder-server-
 ## 管理 daemon
 
 ```bash
-npx -y autowonder@0.2.159 status
-npx -y autowonder@0.2.159 stop
+npx -y autowonder@0.2.161 status
+npx -y autowonder@0.2.161 stop
 ```
 
 默认 API 是 `http://127.0.0.1:34989`，日志位于 `~/.autowonder/daemon.log`。npm 包不包含任何 agent、MCP 或服务端凭证。
@@ -141,7 +164,7 @@ npx -y autowonder@0.2.159 stop
 ## 调试
 
 ```bash
-npx -y autowonder@0.2.159 connect ... --debug
+npx -y autowonder@0.2.161 connect ... --debug
 ```
 
 `--debug` 会让 CLI 以 `AUTOWONDER_DEBUG=1` 启动 daemon，把完整的 daemon 与 agent 活动（runtime 事件流、provider 事件解码、重试退避与会话门等待、空闲时的阻塞点）同时输出到控制台和会话调试日志。调试日志不做脱敏，仅用于本机排障；不传 `--debug` 时该环境变量不会注入。

package/package.json

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