autowonder 0.3.2 → 0.3.4

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.2 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.4 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.2 connect --ws-url <wss-endpoint> --token <executor-token> --executor-id <executor-id> --provider qodercn
+npx -y autowonder@0.3.4 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 登录状态。
@@ -43,6 +43,8 @@ daemon 还会响应服务端的 `CONVERSATION_COMMANDS_PROBE` 帧，用独立会
 
 ## 自主记忆（Qoder 执行器）
 
+评论续接已有会话时，Qoder / QoderCN 子进程也会收到本次派单的最新平台记忆投影、当前 `MEMORY.md` 路径与记忆策略，避免复用旧进程的提示或旧 capsule 路径。数字人身份仍为必填；平台记忆内容不能替代缺失或空白的身份配置。
+
 Qoder 系列执行器的跨派单记忆由平台托管。服务端在派单里下发记忆快照与同步路径，daemon 按该路径拉取快照，把记忆文档投影到本次任务的 capsule（`state/memory/`），并以 `AUTOWONDER_MEMORY_DIR` 注入 provider 子进程；任务执行期间产生的记忆变更经本地 journal 增量回传服务端，索引整理由服务端下发的维护租约驱动。本机历史遗留的 Qoder 记忆（provider 配置根下的 `AGENTS.md`、`MEMORY.md`、`memories.md`，单文件上限 4 MiB）会在派单执行时经脱敏后导入平台，凭据字段与私钥会被替换为 `[REDACTED]`；该导入是机会式的，失败只记调试日志并延后重试，不影响任务本身。
 
 记忆写入被服务端校验拒绝时，runtime 只提取已知的校验码与行号（不夹带服务端响应正文）连同修复方法反馈给模型；只有确实存在待修复写入时才允许一次有界修复，普通业务任务不会因此多出反思回合。隔离维护会话开始时会读取当时最新的 `MEMORY.md`（业务回合可能已修正索引），维护只有在同步队列清空且索引整理目标达成后才算完成。
@@ -79,6 +81,14 @@ daemon 默认启用本地工作区 GC：启动 30 秒后开始检查，之后每
 
 任务工作区里的 Git 策略（是否允许提交/推送与工作区边界）由 runtime 安装的自包含钩子强制执行：默认策略不依赖 runtime 二进制或任务配置继续存在，因此历史任务残留不会让普通的 `git commit` / `git push` 失败，策略禁止时分别以退出码 `73` / `74` 拒绝提交与推送，提交还要求 HEAD 位于具名分支（detached 时以 `77` 拒绝）。安装是幂等的，只有确实声明了打包触发的仓库才会链式调用 runtime。daemon 启动时会在 15 秒预算内把本执行器历史 capsule 中可核对的旧版包装脚本迁移为这种自包含形式；模板、配置或元数据不完整的历史一律保留现场，不做全机扫描，也不恢复用户原有的 `hooksPath`。
 
+## 中断派单恢复
+
+daemon 重启或崩溃后重新接管未完成的派单时，runtime 不会直接把工作区交给恢复执行：先按 capsule 的尝试目录识别并清理上一进程遗留的 provider 进程组，确认没有归属进程组残留后才进入执行；清理结果不确定时保持该派单的恢复归属并按退避重试，不会把工作区让给服务端的替代任务，也不会在遗留进程仍可能写入时确认取消。等待服务端认领期间不占用执行槽位。
+
+恢复时只有存在与步骤 attempt 匹配的持久化完成回执（`state/step-uploads/<step>/attempt-N.json`，即该步骤已发布并被远端 ref 代表）才会复用已完成的步骤；只存在于本地进度快照里的「已完成」不再被采信，无法证明的步骤会回退为待执行并重新运行，同时发出 `recovery_unproven_step_completions` 事件。恢复执行与首次派发一样上报步骤与运行事件，保留的完成步骤会显式发出 `step_reused`，时间线不需要客户端从游标推断。
+
+恢复执行前会把工作目录规范化为绝对路径并解析符号链接（Qoder 会话按物理目录索引），因此通过符号链接别名派发的任务在重启后仍能找到并续接原会话。
+
 ## 自动更新
 
 安装首个支持自动更新的正式版本后，daemon 会直接查询 npm 的 `autowonder/latest`。首次检查会随机分散在启动后的 30～90 秒，之后约每 5 分钟检查一次并加入随机抖动；npm 临时错误会指数退避，HTTP 429/503 的 `Retry-After` 会被遵循。发现更高的稳定版本时，它会在后台下载 npm tarball，校验 SHA-512 SRI、包版本和平台二进制；只有在没有运行/恢复任务且结果 outbox 已收到服务端确认时，才会暂停接单、原子切换二进制并自动重启。启动失败会恢复上一个二进制。
@@ -148,7 +158,7 @@ mv "$queue/.assignment.tmp" "$queue/assignment.json"
 也可以直接提交到本地 API：
 
 ```bash
-npx -y autowonder@0.3.2 dispatch ./assignment.json
+npx -y autowonder@0.3.4 dispatch ./assignment.json
 ```
 
 ## 上传工单附件
@@ -156,7 +166,7 @@ npx -y autowonder@0.3.2 dispatch ./assignment.json
 把本地需求/设计文档直接上传到工单，避免在会话里传递大文件：
 
 ```bash
-npx -y autowonder@0.3.2 workitem upload --server-url <autowonder-server-url> --workitem-id <id> --file <filepath-1> --file <filepath-2> --json
+npx -y autowonder@0.3.4 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）。
@@ -166,7 +176,7 @@ npx -y autowonder@0.3.2 workitem upload --server-url <autowonder-server-url> --w
 把工单上已有的需求/设计文档下载到本地目录，再用本地文件工具阅读，避免把大文件或二进制附件搬进会话上下文：
 
 ```bash
-npx -y autowonder@0.3.2 workitem download --server-url <autowonder-server-url> --workitem-id <id> --file <name-or-id> --output-dir <dir> --json
+npx -y autowonder@0.3.4 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）。
@@ -176,7 +186,7 @@ npx -y autowonder@0.3.2 workitem download --server-url <autowonder-server-url> -
 把需求/设计文档上传到 7x24 定时任务，用法与工单附件一致（同一套上传令牌与预检规则）：
 
 ```bash
-npx -y autowonder@0.3.2 scheduled-task upload --server-url <autowonder-server-url> --scheduled-task-id <id> --file <filepath-1> --file <filepath-2> --json
+npx -y autowonder@0.3.4 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` 相同。
@@ -184,8 +194,8 @@ npx -y autowonder@0.3.2 scheduled-task upload --server-url <autowonder-server-ur
 ## 管理 daemon
 
 ```bash
-npx -y autowonder@0.3.2 status
-npx -y autowonder@0.3.2 stop
+npx -y autowonder@0.3.4 status
+npx -y autowonder@0.3.4 stop
 ```
 
 默认 API 是 `http://127.0.0.1:34989`，日志位于 `~/.autowonder/daemon.log`。npm 包不包含任何 agent、MCP 或服务端凭证。
@@ -193,11 +203,9 @@ npx -y autowonder@0.3.2 stop
 ## 调试
 
 ```bash
-npx -y autowonder@0.3.2 connect ... --debug
+npx -y autowonder@0.3.4 connect ... --debug
 ```
 
 `--debug` 会让 CLI 以 `AUTOWONDER_DEBUG=1` 启动 daemon，把完整的 daemon 与 agent 活动（runtime 事件流、provider 事件解码、重试退避与会话门等待、空闲时的阻塞点）同时输出到控制台和会话调试日志。调试日志不做脱敏，仅用于本机排障；不传 `--debug` 时该环境变量不会注入。
 
-产物上传收到异常响应时，daemon 还会写一条标准日志行 `artifact upload response abnormal dispatchId=...`，不需要 `--debug`，daemon 启动期的 `resume_upload`（复用同一 HTTP 客户端）同样适用。按 dispatch ID 检索即可定位，字段含 `reason`、HTTP `status`、原始与最终 endpoint（去掉 userinfo/query/fragment）、`requestId`（`x-acs-request-id`）、内容类型/编码与声明长度、已读取字节数、`bodyTruncated`、JSON 语法偏移、错误类型和响应体（单行转义文本）。响应体是已读字节的拷贝，不重读、不额外发请求，也不改变重试与错误分类；可识别的凭据与 URL 查询串会替换为 `[REDACTED]`，但未识别的敏感业务内容仍可能残留，诊断日志需限制访问与保留。日志上限 64 KiB，非 2xx 路径仍只读 4 KiB，成功上传不写该日志。覆盖的 `reason` 有 `http_status`、`read_body`、`receipt_too_large`、`rejected_envelope`、`decode_receipt`、`missing_remote_ref`、`invalid_file_receipts`。
-
 `--debug` 之外还有一条由服务端驱动的班组调试日志采集通道，两者互不依赖。runtime 在 `protocolFeatures` 中声明 `DEBUG_LOG_V1`，服务端只会给声明了该能力位的 runtime 下发 `debugLog` 策略；策略在打包时冻结进 assignment（`enabled` / `maxBytes` / `uploadUrl`），执行期不再变化。开启后 runtime 会把本轮完整调试日志写到 capsule 内，单轮硬上限默认 200MB（可由 `debugLog.maxBytes` 覆盖），所在卷剩余空间低于 2GB 时停止写入，单条记录超过 8MB 会被截断并打标记。它是旁路设计：写入队列满时丢行而不反压任务热路径，收尾等待最多 5 秒。回合结束时按 `DIRECT`（对象存储预签名 PUT）或 `RELAY`（服务端中转）通道上传，结果以 `debugLog` 段附在 `TASK_RESULT` 上（`status` 为 `UPLOADED` / `FAILED`，含字节数与 SHA-256）；报告里的错误文本会把 URL 查询串替换为 `<redacted>`，避免执行器令牌或对象存储签名外泄。

package/package.json

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