autowonder 0.3.28 → 0.3.29

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -6,10 +6,10 @@ AutoWonder 本地 agent runtime。安装后启动 daemon,持续轮询本地 as
6
6
 
7
7
  ```bash
8
8
  # Qoder CLI(模型使用 provider model ID;Context Window 使用固定档位)
9
- npx -y autowonder@0.3.28 connect --ws-url <wss-endpoint> --token <executor-token> --executor-id <executor-id> --provider qoder --model qmodel_latest --reasoning-effort medium --context-window 260000
9
+ npx -y autowonder@0.3.29 connect --ws-url <wss-endpoint> --token <executor-token> --executor-id <executor-id> --provider qoder --model qmodel_latest --reasoning-effort medium --context-window 260000
10
10
 
11
11
  # Qoder CLI CN
12
- npx -y autowonder@0.3.28 connect --ws-url <wss-endpoint> --token <executor-token> --executor-id <executor-id> --provider qodercn
12
+ npx -y autowonder@0.3.29 connect --ws-url <wss-endpoint> --token <executor-token> --executor-id <executor-id> --provider qodercn
13
13
  ```
14
14
 
15
15
  `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 登录状态。
@@ -87,7 +87,7 @@ daemon 默认启用本地工作区 GC:启动 30 秒后开始检查,之后每
87
87
 
88
88
  `~/autowonder_workspaces`(可由 `--workspace-root` 或 `AUTOWONDER_WORKSPACE_ROOT` 修改)保存每个任务独立的工作文件和 checkout/worktree;`~/.autowonder/git-object-cache/v1` 保存可供多个任务复用 Git 历史对象的本地 bare mirror。每个任务仍会得到所请求准确 commit 的独立工作区。已缓存的固定 commit 可以不查询远端;允许联网时,`HEAD`、branch 或 tag 等可移动 ref 会在每次 materialization 时向远端解析为准确 commit,仅在 mirror 缺少该对象时 fetch。缓存优化失败时,只有其临时目录已经完成可验证的干净回滚才会回退到原有的远端完整 clone 流程;若无法证明干净回滚,则会保留现场并返回错误,不进入回退。任何路径都不会发布不完整的目标目录;已经存在的任务仓库只做校验,不会被 fetch、reset、clean、checkout 或覆盖。本版本不会自动淘汰 Git 对象缓存,工作区 GC 也不会删除该缓存。
89
89
 
90
- 任务包 `repos.json` 可为仓库声明继承来源 revision 的回退列表(`sourceRevisionFallbackRefs`):当派单要求的继承 revision 已无法解析为 commit(例如上游分支被删除或强推)时,runtime 会按该列表依次回退物化,命中后以回退 commit 作为该仓库本次使用的来源继续执行,并发出 `repo_source_revision_abandoned` 事件(含仓库、回退 commit 与原因)。只有「ref 无法解析」会触发回退——传输、权限、工作区归属与策略类失败不触发;声明了固定 base commit 的仓库不使用回退。该能力对执行机用户无新增参数或环境变量。
90
+ 任务包 `repos.json` 可为仓库声明继承来源 revision 的回退列表(`sourceRevisionFallbackRefs`):当派单要求的继承 revision 已无法解析为 commit(例如上游分支被删除或强推)时,runtime 会按该列表依次回退物化,命中后以回退 commit 作为该仓库本次使用的来源继续执行,并发出 `repo_source_revision_abandoned` 事件(含仓库、回退 commit 与原因)。只有「ref 无法解析」会触发回退——传输、权限、工作区归属与策略类失败不触发;声明了固定 base commit 的仓库不使用回退。该能力对执行机用户无新增参数或环境变量。来源 revision 产物里的 `checkoutVerification: "required"` 表示远端探测未能确认 HEAD(不等于 HEAD 未发布),下游应在开始验收前物化该精确 HEAD;旧消费方仍按原有远端校验逻辑处理。
91
91
 
92
92
  任务工作区里的 Git 策略(是否允许提交/推送与工作区边界)由 runtime 安装的自包含钩子强制执行:默认策略不依赖 runtime 二进制或任务配置继续存在,因此历史任务残留不会让普通的 `git commit` / `git push` 失败,策略禁止时分别以退出码 `73` / `74` 拒绝提交与推送,提交还要求 HEAD 位于具名分支(detached 时以 `77` 拒绝)。安装是幂等的,只有确实声明了打包触发的仓库才会链式调用 runtime。daemon 启动时会在 15 秒预算内把本执行器历史 capsule 中可核对的旧版包装脚本迁移为这种自包含形式;模板、配置或元数据不完整的历史一律保留现场,不做全机扫描,也不恢复用户原有的 `hooksPath`。
93
93
 
@@ -101,6 +101,8 @@ daemon 重启或崩溃后重新接管未完成的派单时,runtime 不会直
101
101
 
102
102
  完成交付进入 `uploading` 后,永久性上传失败(产物超限、权限拒绝或其他已判定的终态错误)不再被外层自动重试循环持续重投:runtime 记录终态失败、停止该派单的重试,并保留本次业务结果与产物责任等待平台处置;只有可恢复错误才按 30 秒退避继续。取消请求贯穿完成交付与启动恢复——上传阶段的取消会立即把该派单标记为已取消并释放待发布结果,恢复 worker 在启动前或上传重试过程中被取消时不再继续投递,对已进入终态且没有活跃处理器的派单会按幂等成功回应该取消。启动恢复中只做纯上传/发布结果的派单状态显示为 `uploading`,其被拒绝的上传仍以服务端权威所有权栅栏为准,不在本地凭空创建新的业务失败或结果身份。
103
103
 
104
+ 暂停也走同一条持久化回执链路:`TASK_PAUSED` 只有在服务端确认接受后才从结果 outbox 删除,未接受时保留并可重发;服务端再次下发同一派单的暂停指令时,runtime 直接从 capsule 中已落盘的暂停结果(`runtime-result.json`,先校验租户、工单、派单、attempt 与 checkpoint 回执)重放该回执,而不要求暂停协调器仍留在内存里等待,因此 daemon 重启或回执丢失都不会让等待该派单返工的一方永久挂起。
105
+
104
106
  ## 自动更新
105
107
 
106
108
  daemon 不会自行追新:后台自动更新策略默认关闭,且没有环境变量可以重新开启,因此 daemon 不会主动查询 npm 的 `autowonder/latest`、下载、安装或重启。版本由平台决定,见下文的服务端指定版本升级;没有服务端升级指令时,即使本地配置了更短的检查周期也不会产生任何 npm 请求。
@@ -179,7 +181,7 @@ mv "$queue/.assignment.tmp" "$queue/assignment.json"
179
181
  也可以直接提交到本地 API:
180
182
 
181
183
  ```bash
182
- npx -y autowonder@0.3.28 dispatch ./assignment.json
184
+ npx -y autowonder@0.3.29 dispatch ./assignment.json
183
185
  ```
184
186
 
185
187
  ## 上传工单附件
@@ -187,7 +189,7 @@ npx -y autowonder@0.3.28 dispatch ./assignment.json
187
189
  把本地需求/设计文档直接上传到工单,避免在会话里传递大文件:
188
190
 
189
191
  ```bash
190
- npx -y autowonder@0.3.28 workitem upload --server-url <autowonder-server-url> --workitem-id <id> --file <filepath-1> --file <filepath-2> --json
192
+ npx -y autowonder@0.3.29 workitem upload --server-url <autowonder-server-url> --workitem-id <id> --file <filepath-1> --file <filepath-2> --json
191
193
  ```
192
194
 
193
195
  上传令牌通过 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)。
@@ -197,7 +199,7 @@ npx -y autowonder@0.3.28 workitem upload --server-url <autowonder-server-url> --
197
199
  把工单上已有的需求/设计文档下载到本地目录,再用本地文件工具阅读,避免把大文件或二进制附件搬进会话上下文:
198
200
 
199
201
  ```bash
200
- npx -y autowonder@0.3.28 workitem download --server-url <autowonder-server-url> --workitem-id <id> --file <name-or-id> --output-dir <dir> --json
202
+ npx -y autowonder@0.3.29 workitem download --server-url <autowonder-server-url> --workitem-id <id> --file <name-or-id> --output-dir <dir> --json
201
203
  ```
202
204
 
203
205
  下载令牌通过 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)。
@@ -207,7 +209,7 @@ npx -y autowonder@0.3.28 workitem download --server-url <autowonder-server-url>
207
209
  把需求/设计文档上传到 7x24 定时任务,用法与工单附件一致(同一套上传令牌与预检规则):
208
210
 
209
211
  ```bash
210
- npx -y autowonder@0.3.28 scheduled-task upload --server-url <autowonder-server-url> --scheduled-task-id <id> --file <filepath-1> --file <filepath-2> --json
212
+ npx -y autowonder@0.3.29 scheduled-task upload --server-url <autowonder-server-url> --scheduled-task-id <id> --file <filepath-1> --file <filepath-2> --json
211
213
  ```
212
214
 
213
215
  上传令牌同样通过 `autowonder.workitem_cli_upload_token` 签发(令牌为用户级,对当前可修改的任意定时任务生效),经 `--token` 或 `AUTOWONDER_UPLOAD_TOKEN` 传入;退出码约定与 `workitem upload` 相同。
@@ -215,8 +217,8 @@ npx -y autowonder@0.3.28 scheduled-task upload --server-url <autowonder-server-u
215
217
  ## 管理 daemon
216
218
 
217
219
  ```bash
218
- npx -y autowonder@0.3.28 status
219
- npx -y autowonder@0.3.28 stop
220
+ npx -y autowonder@0.3.29 status
221
+ npx -y autowonder@0.3.29 stop
220
222
  ```
221
223
 
222
224
  默认 API 是 `http://127.0.0.1:34989`,日志位于 `~/.autowonder/daemon.log`。npm 包不包含任何 agent、MCP 或服务端凭证。
@@ -239,7 +241,7 @@ daemon 内置独立于工作区 GC 的保留清扫:默认每小时运行一次
239
241
  ## 调试
240
242
 
241
243
  ```bash
242
- npx -y autowonder@0.3.28 connect ... --debug
244
+ npx -y autowonder@0.3.29 connect ... --debug
243
245
  ```
244
246
 
245
247
  `--debug` 会让 CLI 以 `AUTOWONDER_DEBUG=1` 启动 daemon,把完整的 daemon 与 agent 活动(runtime 事件流、provider 事件解码、重试退避与会话门等待、空闲时的阻塞点)同时输出到控制台和会话调试日志。调试日志不做脱敏,仅用于本机排障;不传 `--debug` 时该环境变量不会注入。
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "autowonder",
3
- "version": "0.3.28",
3
+ "version": "0.3.29",
4
4
  "description": "AutoWonder local runtime — execute AI agent dispatch packages on your machine",
5
5
  "bin": {
6
6
  "autowonder": "bin/cli.js"