Agent Workflow v0.18.19

Agent Workflow v0.18.19

本版本是 v0.18.18 之后的 patch 版本，主线是修复 Windows 上「杀进程 → 重试建不起来 → 任务停摆」的死链（RFC-356，issue #13）、让意图构建（Intent Builder）看得见完整的工作流图校验（RFC-358），以及任务列表页在两个数据库 provider 上收敛为同一份查询（RFC-357）。同时 PostgreSQL provider 的统一抽象（RFC-359）持续推进，本版本修掉了一批只在 PostgreSQL 上出现的功能缺陷。

本版本不含新的 SQLite 数据库迁移（迁移端点仍为 0223）。PostgreSQL 基线（0000_rfc349_baseline）重采，已经完成 RFC-349 cutover 的 PostgreSQL 部署需要重做 cutover，详见文末「升级说明」。

主要更新

Windows：杀进程后重试建不起来、任务停摆（RFC-356 / issue #13）

用户在 Windows + v0.18.14 上报的三行现场——「超时杀进程 → iso worktree 删除失败（Invalid argument，留待 GC）→ 重试重建 iso worktree 报 already exists」——经源码对账确认是一条必然复现的死链，不是偶发。本版本从三处同时堵上：

• 残留工作树回收阶梯：iso 工作树的丢弃改为「git worktree remove --force → 退避重试的目录删除 + git worktree prune → 报告 blocked」三档阶梯，不再是一发 git worktree remove 失败就只 warn 一句「留待 GC」（而 iso GC 明确跳过活跃 / 非终态任务，那句承诺对活着的任务从不成立）。「丢了注册项的残留目录」（git worktree remove 报 is not a working tree）现在也能被清掉——这是此前平台完全无法自愈的形态。
• iso 键代际自愈：旧 iso 确实清不掉时，重试自动改用新一代 iso 键（{原键}-2、-3…）建树并继续，不再以 iso-recreate-failed 把节点和整条工作流永久钉死。wrapper iso 的 resume 路径同样自愈——此前 Windows 上每次 resume 都撞同一堵墙、永久 wedge，也就是 issue 标题里的「循环调度停摆」。
• Windows 进程树归属真正接线：RFC-254 早已写好的 Job Object 归属代码在生产路径上一次都没有被调用，于是杀树一直落在 taskkill /pid <pid> /T /F 这个快照枚举降级档（新 fork 的后代直接逃逸），而 isProcessTreeAlive 在 Windows 上恒返回 null（平台无从知道树是否死透）。本版本把 Job Object 接到 spawn 上：杀树走 TerminateJobObject 的内核级原子终止，杀树之后仍能查内核确认存活数，并在回收工作树之前于预算内等待树静默。没有 FFI 的 Windows ARM64 保持 taskkill 降级，降级事实在 daemon 启动时 warn 一次，也会出现在失败诊断里。
• 失败信息会自证：真的清不掉时，iso-recreate-failed 的消息会带上残留路径、最后一次错误与本机 Job Object 可用性，而不是一行光秃秃的错误码。
• 连带修复：handleTaskIdOf 此前用 split('/') 解析由 join() 生成的路径，在 Windows 上恒返回 'unknown'，导致带子模块的仓库其 worktree-scoped 池锚点全部串台、按 taskId 的清理永远匹配不上。

意图构建看得见工作流图校验（RFC-358）

起于用户实证「意图创建的东西过不了校验」。此前意图链路只跑第一层校验（句柄 / 挂载 / 模板语法 / tempRef 环），真正的工作流图校验（端口存在性、wrapper 边界、fanout 结构、clarify 多重性、call 闭环与自调用、模板变量来源、agent 的 skill / MCP / plugin 闭包，共 108 个错误码）从生成到落库一次都不跑——于是意图侧全绿落库，坏在编辑器或启动时才暴露，agent 全程看不见、也无法自愈。

• 变更集里的工作流 op 现在会被解析成可校验候选并跑完整图校验：agent 以变更后形态参与，同批新建的 skill / MCP / plugin 注入闭包，同批新建的被调工作流按名字 + id 双键注入 call 闭包，currentWorkflow 补齐自调用与环判据。
• error 以 <opId>: 前缀汇入既有 blocking 列表，draft 期就看得见并禁止提交；warning 单独成段呈现，超出上限时显式标注截断。
• 图修复轮：图校验报 error 时自动接一轮让模型自修（预约与 settle 同事务，无 in-flight 空窗）；只有图校验的 error 会触发，第一层报错不再自动重跑。
• copy 操作不再丢 sidecar；提交期补一道二次硬拦。
• 改动 agent 时，其下游影响面会在确认页列出（知情不拦截）。

任务列表页：一份查询，两个 provider（RFC-357）

起于用户反馈「切了 PostgreSQL，任务列表还是卡」。对账结论不是「PostgreSQL 慢」，而是这一页在两个 provider 上是两份实现，PostgreSQL 那份从来没有过 RFC-311 的任何一项优化：三个数据源各发一次 limit: 10_000 的裸查询、把 workflow_snapshot（整份工作流定义 JSON，每行上百 KB）等大列一起搬过来、失败任务再逐行 N+1，然后过滤 / 搜索 / 排序 / 分页 / facets 全在 JS 里做。

• 抽出一份 dialect 参数化的页查询给两个 provider 共用；services/taskOperations.ts（1,196 行 SQLite 专属裸 SQL）整文件删除并归位。
• 分叉带来的用户可见缺陷一并修掉：页签计数不再随选中的页签变（facets 数改在 view 之前算，前端飞行期沿用旧值）；启动来源筛选在 PostgreSQL 上「事件」/「API」不再 400、「定时」不再漏子任务；层级与排序不再写死。
• 前端 WebSocket 失效改为按帧增量：task.status / task.deleted 就地 patch，其余仍走失效 + 30s 低频对账。
• CI 新增一条真 PostgreSQL 窄 lane（假 pool 只断言 SQL 文本，证明不了它在真库上跑不跑得动）。

PostgreSQL provider 统一抽象持续推进（RFC-359，进行中）

RFC-359 的目标是「provider 是一个抽象，而不是一个 if」——不再允许出现两种数据库一好一坏的分支。本版本落地的部分已经修掉一批只在 PostgreSQL 上出现的功能缺陷：

• 评审与澄清可用：评审决定 / 评论增改删 / 文档选择、快速澄清决定、反问下发、延迟提问自动派发全部收敛为一份实现跑在统一事务原语上，PostgreSQL 上「评审无法通过 / 驳回、澄清无法回答」以及路由 500 的问题消失。
• 任务能跑起来：八处 owner 围栏此前把「未显式传执行上下文」当作无主，节点的第一次写就被自己 claimed 的 owner 拒掉（每个任务在铸出 node_run 前必死）；effect 账本对冻结 token 做等值判定导致首次心跳后所有 effect 写入被拒。两条都已改成与 SQLite 同规则。
• 启动与恢复对齐：boot 恢复四步（撤销旧 owner / 收割孤儿 run / 修 runtime session lease / 清算 effect）、删除认领崩溃恢复、归档与工作区维护恢复、技能启动屏障、定时载荷治愈、webhook 投递恢复等，PostgreSQL daemon 现在与 SQLite 入口同序执行同一份实现。
• 其他 PostgreSQL 专属修复：坏定义的工作流在 PostgreSQL 上也能删除（并补齐两道此前缺失的删除守卫）；count/sum 相关计数、NULL 排序、用户搜索召回等差异随合一消除；PostgreSQL daemon 的系统身份改为正式 admit，四条 daemon 自用路径不再抛 foreign-legacy-actor-projection；数据库迁移会话不再继承在线请求超时，验证查询失败不再被记成不变量违规。
• 一份实现：约 150 对孪生适配器已合掉大半（task-execution / resource-catalog / collaboration / identity-access / memory / integration / source-control / event-center / code-capability / digital-employee / development-automation 各批），数千行 PostgreSQL 副本退役；双引擎测试 harness 让每个合一批次在两种数据库上各跑一遍，四个 CI 分片各带真 PostgreSQL。

其他修复

• 数字员工 / 开发任务（mission）停在 working 不动：根因是事实写回被并发挤掉后没有重试，以及悬挂在 prepared 的自治 effect 被决策去重吞掉；reconcile 路径上同族的无校验 OCC 写回一次扫干净。
• 终态维护的水位覆盖判据只对最高代际比 digest，冲突归类为 busy（不再误判）。
• 修复重启会杀掉「已回答澄清」续跑的问题（补回 RFC-187 T13 的复活路径）、收尾轮丢派单、系统消息分类判据丢失、流中断的重跑不进账本等一批合一过程中暴露的回归。
• 意图链路：apply 层 changeset 校验收成一份（SQLite 不再裸 JSON.parse）；services/intent/ 5,136 行整目录删除、路由迁入模块并收成 decode-call-map（RFC-355）。

升级说明

• 无新增 SQLite 迁移：迁移端点仍为 0223。仍建议升级前备份数据库。
• PostgreSQL 基线重采（重要）：webhook_deliveries 的两条部分唯一索引与 user_identities 的 provider+subject 唯一索引此前只存在于 SQLite 迁移、没有进入 drizzle 声明，PostgreSQL 侧因此没有去重键。本版本补上声明并重采了 PostgreSQL 基线（contractDigest 变更）。已经完成 RFC-349 cutover 的 PostgreSQL 部署需要重做 cutover；PostgreSQL 增量迁移能力仍在 RFC-359 W5 中，尚未提供。
• Windows 行为变更（RFC-356，均为有意变更）：
  • daemon 进程退出（含崩溃 / 被强杀 / 优雅停机的超预算幸存者）时，在跑的 runtime 子进程会随 Job Object 关闭被内核一并终止——此前它们会留成孤儿、等下次启动收割。
  • 正常成功退出的运行，其幸存后代也会在收尾时被终止（它们正是持有工作树句柄的那一批）。
  • 被杀掉的运行，其结束时间会晚最多 2s（等待进程树静默）；正常退出的运行时序逐字不变。
  • 磁盘上可能多出一个暂时清不掉的残留 iso 目录（自愈换新路径的代价），它会在任务终态时由既有 iso GC 一并删除。
  • Windows ARM64（无 FFI）保持 taskkill /T /F 降级，不新增平台专属杀树路径。
• POSIX 平台行为不变：macOS / Linux 上杀树仍走进程组，时序逐字不变。
• 不要在升级后的数据库上直接回退旧二进制：需要降级时，请停机、换回旧 binary，并恢复升级前备份。

完整变更记录：v0.18.18...v0.18.19