OmO DAG TUI 暂停状态诚实化paused run 头部三态渲染契约resuming / suspended · N active / paused与 lease 机制源码级解析【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent本文围绕 oh-my-openagentOmOomo-senpi适配层的一次真实缺陷修复展开DAG 运行run被会话关闭暂停后TUI 头部仍按原始run.status打印paused而其下方的节点行却显示▶运行中两者互相矛盾。文章完整呈现该修复确立的暂停家族三态渲染契约resuming/suspended · N active/paused、leaseHolderPid从 checkpoint 一路穿透到渲染层的实现链路、signal-0 存活探针的语义以及从 failing-first 单测、真实进程级 QA 驱动到五透镜评审的完整质量证据链。读完你将掌握如何在 TUI 中对正在恢复与真正停摆的暂停 run 做诚实呈现如何用最小侵入纯展示层 可选字段投影修复一个会误导用户的显示缺陷以及 OmO 工程中测试先行 真实表面驱动 前后对照的 QA 方法论。一、缺陷背景头部说暂停车道却说运行中在 OmO 的 DAG 工作流中一次多波次wave执行被会话关闭暂停后TUI 的任务组件头部会直接渲染 checkpoint 中的原始run.status。在恢复-对账resume-reconcile窗口期widget 会打印出这样的矛盾画面⏸ ship-it paused wave 1/1 0/2 done, 1 running ▶ alpha · category:quick · 0s头部声称该 run 已暂停、处于空闲状态而正下方的节点行却声称alpha仍在运行——这两者不可能同时为真。根据证据目录中的缺陷描述README.md根因非常清晰头部直接使用原始run.status渲染没有任何上下文修正真正能化解矛盾的唯一信息——leaseHolderPid恢复租约持有者的宿主机 pid由claimPausedRun写入、在 shutdown pause 时清除——从未离开 checkpoint 记录因此没有任何展示层可以读取它。换句话说引擎内部早已知道这个暂停的 run 正在被另一个进程认领恢复但这条信息被锁在持久化记录里渲染层拿不到只能凭status字段猜于是撒了一个显示层面的谎。二、三态渲染契约暂停家族如何做到诚实修复确立的显示契约定义在 gate-b-review.md 的 Lens 1 中并在 README 中以表格形式固化。当run.status paused时头部状态文案按下述优先级解析条件头部状态文案leaseHolderPid存在且该 pid 存活resuming无存活租约且至少 1 个节点处于running状态suspended · N activeN 运行中节点数其他情况paused与之配套的图标规则同样关键run 级图标整个暂停家族统一使用中性符号·永远不使用⏸。PAUSED_RUN_ICON直接短路NODE_ICONS避免头部⏸与车道▶并存的自相矛盾节点级图标真正运行中的车道仍保留▶不受影响——节点图标描述的是节点自身事实头部图标描述的是 run 级事实二者各司其职。实现位于 dag-status-row-format.ts 的runHeaderRow/pausedStatusTextconst PAUSED_RUN_ICON · // L94暂停家族的 run 级图标故意中性 function runHeaderRow(run: DagStatusRunSnapshot, isAlive: (pid: number) boolean): string { const paused run.status paused const icon paused ? PAUSED_RUN_ICON : (NODE_ICONS[run.status] ?? ○) const name excerptRendererText(normalizeRendererText(run.name), LABEL_MAX) const status paused ? pausedStatusText(run, isAlive) : normalizeRendererText(run.status) return ${icon} ${name} ${status} ${waveLabel(run)} ${countsLabel(run)} } // L152-L156优先级是刻意设计的 function pausedStatusText(run: DagStatusRunSnapshot, isAlive: (pid: number) boolean): string { if (run.leaseHolderPid ! undefined isAlive(run.leaseHolderPid)) return resuming const running run.nodes.reduce((count, node) count (node.state running ? 1 : 0), 0) return running 0 ? suspended · ${running} active : paused }代码注释解释了优先级背后的设计意图存活租约意味着另一个进程已经认领该 run 并正在对账此时再画 paused 会在一帧之内就过期而没有租约时仍处于running的节点是搁浅的工作头部必须直面并承担它们而不是用 paused 把事实藏起来。signal-0 存活探针ESRCH 之外的哲学pid 是否存活由 dag-status-row-format.ts 的isProcessAlive判定采用signal-0 探针// Signal 0 probes existence without delivering anything. ESRCH is the only gone answer: EPERM // means the pid exists under another uid, which still counts as a live lease holder. function isProcessAlive(pid: number): boolean { try { process.kill(pid, 0) return true } catch (error) { return (error as NodeJS.ErrnoException).code ! ESRCH } }要点有三process.kill(pid, 0)不会投递任何信号只是探询进程是否存在因此不存在误杀风险ESRCH是唯一的已消失答案EPERM意味着 pid 存在于另一个 uid 之下仍然计为存活——探针按存在即活而非我可控才活来判定。此外runRows的选项还提供了isProcessAlive注入缝dag-status-row-format.ts测试与 QA 驱动可以替换探针实现而生产环境默认走 signal-0。三、数据通路leaseHolderPid从 checkpoint 穿透到渲染层要让渲染层能分辨resuming/suspended必须先让leaseHolderPid走出 checkpoint。这条通路贯穿四个模块评审文档Lens 1明确点名了每一处且每一处都有对应测试1. 持久化记录DagRunRecordV1新增可选字段manager.ts 中的DagRunRecordV1增加两个可选字段// Resume lease: recovery claims a paused run by writing the claiming host pid here and drops the // field on shutdown pause (see recovery.ts). Absent on records written before the lease existed. readonly leaseHolderPid?: number readonly previousLeaseHolderPid?: number注意可选 缺省即无的设计旧记录legacy没有该字段读取方必须容忍其缺失previousLeaseHolderPid用于租约移交场景下的历史追踪。2. 引擎侧守护liveLeaseHolder决定真实控制流评审文档特别强调这个 pid 不是仅供展示的花瓶字段引擎本身早就在用同源的 pid 决定真实控制流。manager.ts 的liveLeaseHolder就是证明function liveLeaseHolder(record: DagRunRecordV1): boolean { const pid record.leaseHolderPid ?? record.previousLeaseHolderPid if (pid undefined) return false return defaultSignaller.isAlive(pid) }它被用在两处关键决策暂停 run 的修订防护manager.tsif (oldRecord.status paused liveLeaseHolder(oldRecord)) { throw new DagManagerError({ code: invalid_amendment, message: dag run ${selectedRunId} is paused by another live lease, runId: selectedRunId }) }即被另一个存活租约暂停的 run 不允许被修订以及 reducer 中的幂等防护manager.tsif (record.status paused liveLeaseHolder(record)) return record。这说明展示层读取的 pid 与引擎控制流判定的是同一个信任域不是引入新的外部输入。3. 租约生命周期claim 写入、shutdown 清除、release 释放leaseHolderPid的写入与清除由恢复模块 recovery.ts 管理认领claimclaimPausedRun在确认 run 仍为paused且前租约持有者已消失后写入leaseHolderPid: context.hostPid并重写 checkpointrecovery.tsshutdown 暂停清除pauseRunsForShutdown在暂停 run 时把leaseHolderPid一并清除并把旧值记入previousLeaseHolderPid所以被暂停但无租约是一个合法且可判定的状态释放releasereleaseLease仅在fresh.leaseHolderPid context.hostPid时清除字段recovery.ts防止误释放他人租约跳过原因resumePausedRuns遇到live_lease时返回holderPid供上层观察并延迟重试——这正是 dag-runtime.ts 中watchLiveLease的场景前任宿主进程正在退出但仍持有租约时runtime 会 watch 该 pid待其消失后再次触发恢复避免 run 永远停在 paused。4. 快照投影两处projectSnapshot保持对等DagRunSnapshot类型在 types.ts 中新增可选字段注释明确其用途// Host pid holding the resume lease on a paused run. Display surfaces need it to tell a run that // is being resumed right now from one that is genuinely parked. Absent unless a claim is held. readonly leaseHolderPid?: number投影采用spread-guarded写法——字段缺失时完全不出现而非序列化为undefinedmanager.ts 与 handle.ts 两处projectSnapshot完全一致...(record.leaseHolderPid undefined ? {} : { leaseHolderPid: record.leaseHolderPid }),评审文档Lens 1特意点名handle.ts的投影是为对等性parity而加attach/wait返回的快照与 manager 快照行为一致避免同一 run 在不同 API 下呈现不同的事实。5. 桥接 payloadlease_holder_pid走上线缆omo.dag.updated事件体由 dag-snapshot-payload.ts 生成。桥接快照类型同样新增可选leaseHolderPidL51-L53并按既定 wire 契约转为 snake_caseL98...(run.leaseHolderPid undefined ? {} : { lease_holder_pid: run.leaseHolderPid }),这里刻意沿用omo.task.updated已有的 snake_case wire 契约可选字段保持缺失即无绝不序列化为null。这一项的意义在于GUI 查看器如 omo-desktop-app也能实现与 TUI 相同的 resuming/suspended 区分而不仅限于终端组件。6. 渲染层只读缝结构性镜像值得注意的一个实现细节formatter 并没有直接 import 引擎的DagRunSnapshot而是在 dag-status-row-format.ts 本地声明了一个结构性镜像DagStatusRunSnapshot含可选leaseHolderPid?: number并注释说明结构镜像 senpi-task 的 dag 领域契约本地声明以便 widget 保持只读消费者身份无论扩展接入的是哪个 DagManager 实例。 这是 OmO 适配层常见的只读缝模式展示方只依赖形状不依赖具体实例。四、QA 证据链从 failing-first 单测到真实进程级驱动评审文档 Lens 2 对质量证据的判定是 PASS其证据链本身就是一个可复用的 QA 模板。1. Failing-first 单测先红后绿三条显示规则以先写失败的测试形式加入 dag-status-row-format.test.tsdescribe(runRows paused run header honesty, () { const LIVE_PID 4242 const DEAD_PID 4243 const isProcessAlive (pid: number): boolean pid LIVE_PID it(...lease holder alive... header reads resuming under the neutral icon, () { // paused 存活租约 - resuming无 paused无 ⏸运行车道保留 ▶ expect(rendered[0]).toContain(resuming) expect(rendered[0]).not.toContain(paused) expect(rendered[0].startsWith(· )).toBe(true) expect(rendered[0]).not.toContain(⏸) expect(rendered[1]).toContain(▶) }) it(...no live lease and running nodes... suspended with the active count, () { // paused 死租约 2 个 running 节点 - suspended · 2 active expect(rendered[0]).toContain(suspended · 2 active) }) it(...no live lease and no running nodes... still reads paused, () { // paused 死租约 无 running 节点 - 仍为 paused expect(rendered[0]).toContain(paused) }) })红色捕获red-dag-status-row-format.txt12 通过、3 失败即三条显示规则red-typecheck-omo-senpi.txt6 个类型错误因为leaseHolderPid/isProcessAlive尚未上类型red-dag-snapshot-payload.txt9 通过、1 失败lease_holder_pid未上线缆证明这些测试确实在守卫该行为而不是事后照着成品实现编出来的。2. 真实表面驱动dag-paused-header-qa.ts单测之外QA 还提供了一个不依赖任何 stub 的端到端驱动 dag-paused-header-qa.ts其头部注释说明设计目标Drives the REAL surfaces end to end: a real on-diskDagFileStore, the real recovery pause/claim writes that ownleaseHolderPid, the realDagManagersnapshot projection, and the realcreateDagStatusUiwidget render.驱动流程对评审文档与 README 的还原种子写入通过store.writeCheckpoint写入一个status: running的 run节点alpha置为 running真实 shutdown 暂停调用createDagRecovery().pauseRunsForShutdown(PARENT_SESSION)断言租约被清除、状态变为paused真实认领由真正存活的子进程spawn(process.execPath, [-e, setTimeout(() {}, 60000)])执行认领写入leaseHolderPid: livePidCase A渲染 widget 行断言头部含resuming、无⏸、以·开头、运行车道保留▶Case B对子进程SIGKILL并等待退出再用同一存储渲染——死租约分支面对的是真实 pid 从存活到被杀的转换不可能靠 stub 之间的默契通过Case C把 running 节点改写为 pending无运行节点断言头部回落为中性图标下的paused输出 JSON 报告到out-dir任何契约违例都以非零退出码结束。运行结果after-live-dag-header.txt展示了修复前后同一个驱动、同一存储形态下的对照修复前base b9c04adbdformatter 回退result FAIL7 处契约违例 resuming_header: ⏸ ship-it paused wave 1/1 0/2 done, 1 running suspended_header: ⏸ ship-it paused wave 1/1 0/2 done, 1 running paused_header: ⏸ ship-it paused wave 1/1 0/2 done # 三种情境渲染结果完全相同——正是被报告的谎言 修复后result PASS0 失败 resuming_header: · ship-it resuming wave 1/1 0/2 done, 1 running suspended_header: · ship-it suspended · 1 active wave 1/1 0/2 done, 1 running paused_header: · ship-it paused wave 1/1 0/2 done resuming_rows[1]: ▶ alpha · category:quick · 0s - 节点图标不变前后对照的价值在于可归因性同一个驱动、同一个存储形态唯一差异是 formatter 变更因此红绿差异只能由该变更引起。3. 隔离证明与既有失败归因隔离证明isolation-proof.txt驱动的全部文件系统写入面仅限自己的mkdtempSync状态目录与显式 out-dir从不读写 agent 目录。对~/.senpi/agent与~/.omo/agent做整目录 watch驱动运行期间有 25 个路径变化而无驱动运行的对照窗口有 29 个——说明这些 churn 来自本机自身的 agent 会话与驱动无关临时目录在finally中清理不留沙箱残留。既有失败归因baseline-preexisting-failures.txtbun run test:senpi的 14 个失败中有 13 个是既有的无关失败init-deep-advisor、cli-local安装回路、OmO native 身份等其中 11 个在本分支变更 stash 掉之后仍可复现。第 14 个dag-status-ui each state renders its own icon断言的是旧的⏸run 头部契约被更新为新契约其节点图标断言未动而非删除。无敏感信息任何 artifact 中都不出现密钥、token、认证头、环境变量转储或凭据机器相关值只有临时路径和一个瞬态子进程 pid。4. 绿色门禁汇总门禁结果tsgo -p packages/omo-senpi/tsgo -p packages/senpi-task均 exit 0omo-senpitask 组件套件483 通过 / 0 失败63 文件senpi-taskdag 套件243 通过 / 0 失败16 文件双作用域合并726 通过 / 0 失败79 文件五、五透镜评审Gate B 自审记录由于review-workskill5 个并行评审子代理在当前环境不可用、任务子节点也无法派发子代理评审直接对git diff origin/dev...HEAD进行形成这份五透镜记录gate-b-review.mdLens 1 — 目标验证PASS。显示契约逐条核对无误前文三态表leaseHolderPid已穿透manager.ts与handle.ts的projectSnapshot及桥接 payload且各带测试。Lens 2 — QA 证据PASS。红色捕获3 条显示规则失败 6 个类型错误 1 个 payload 失败、绿色捕获、真实前后驱动 JSON、隔离证明、既有失败归因一应俱全证据 README 覆盖 what-tested / observed / why-enough / omitted。Lens 3 — 代码质量一个发现已修复。QA 驱动携带了一个废弃的isAliveOverride参数及遗留的void空操作在 commit7cf5c476中移除驱动重跑 PASStsgo -p packages/omo-senpi保持干净。剩余的类型断言runId as DagRunId、伪造的setWidget对象镜像了 dag-runtime.ts 中适配器自身的接线方式只为在独立脚本中满足 widget 的主机侧接缝。Lens 4 — 安全PASS。无新增输入面、无密钥处理、无日志新增。pid 来自引擎自身 checkpoint与既有的liveLeaseHolder/node-control-context防护同信任域signal-0 探针不投递信号把 pid 加入omo.dag.updatedpayload 与既有 task payload 已向同一查看器暴露宿主 pid 的信任域一致。Lens 5 — 上下文挖掘PASS一条备注。全库搜索 run 状态的其他渲染点dag-commands.ts 的summaryHeader在单行/dag列表中打印原始状态、无逐节点行因此不可能产生本 PR 针对的暂停头部 vs 运行车道矛盾/dag工具消息同样向模型报告事实性记录状态。两者都在显示契约TUI run 头部的声明范围之外而 wire payload 现已携带lease_holder_pidGUI 查看器可实现同样的区分。未发现其他按节点渲染暂停家族的使用方。结论Gate B PASS在一次自查修复之后。Gate C 记录SKIPPEDquota/availability。PR #7322 上从未出现cubic-dev-ai[bot]评审评审列表为空Cubic 自身检查条目报告skipping3s。PR 提交后限时等待 5 分钟产出 0 条评审。按 work-with-pr 循环这是唯一被认可的跳过条件——记录在案而非默默放行。Issues 从来不是跳过的理由且其他任何 gate 均未发现 issues。六、变更边界与兼容性为什么这个修复足够小、足够安全评审文档Lens 3对 shipped-code diff 的界定值得单独强调DagRunRecordV1上两个可选字段并顺带折叠了liveLeaseHolder中一个既有 castDagRunSnapshot与桥接快照各一个可选字段两处 spread-guarded 投影formatter 变更。引擎、WAL、checkpoint、调度器、恢复逻辑一行未动——恢复代码本就在通过本地 cast 写这个 pid这次只是把该事实正式模型化并投影出去。可选字段 缺省即无的组合保证旧记录无leaseHolderPid读取兼容显示层回退到纯paused无租约持有时的 payload 与旧格式字节级一致既有的 omo-desktop-app reducer-contract 测试仍钉住普通 run 的未触及字段集新增字段是纯增量不存在破坏性 schema 变更。Rebase 期间 PR #7320fix/dag-recovery-nonblocking触碰recovery.ts、scheduler.ts与受管omo-task.jsbundle先行合入 dev唯一的冲突是生成的 bundle按 smart-rebase 契约重新生成即可无语义冲突rebase 后重新验证 728 通过 / 0 失败比此前 726 多出的 2 例正是 dev 新增的recovery-nonblocking用例。七、可复用的工程要点从这次修复中可以提炼出几条超越单一 bug 的方法论显示层要撒谎时先找引擎里已有的真相leaseHolderPid一直存在、一直驱动真实控制流只是没被投影。让展示层复用引擎已有的信任域字段比另造一套状态机便宜得多、也安全得多。状态文案的优先级就是业务语义resuming优先于suspended优先于paused每条分支对应一个可判定的物理事实有存活租约 / 有运行节点 / 都没有而不是对status字符串的格式化。图标也是契约的一部分头部·与节点▶的分工把run 级事实与节点级事实解耦中性符号在矛盾窗口期不主张任何运动避免视觉谎言。failing-first 真实表面驱动双保险单测证明规则真实进程级驱动证明用户真正看到的表面用同一个驱动跑 before/after把差异归因到唯一变量。评审记录本身是交付物五透镜记录 Gate C 的显式跳过理由quota 条件 限时等待证据把什么被验证、什么被省略、为什么足够完整留给后人而不是只留一个 PASS 结论。若需继续深入可对照阅读同一证据目录下的 README.md缺陷与契约的完整叙述、formatter 实现 dag-status-row-format.ts、类型定义 types.ts以及驱动脚本 dag-paused-header-qa.ts 与恢复模块 recovery.ts 中租约的写入/清除逻辑。【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OmO DAG TUI 暂停状态诚实化paused run 头部三态渲染契约resuming / suspended · N active / paused与 lease 机制源码级解析【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent本文围绕 oh-my-openagentOmOomo-senpi适配层的一次真实缺陷修复展开DAG 运行run被会话关闭暂停后TUI 头部仍按原始run.status打印paused而其下方的节点行却显示▶运行中两者互相矛盾。文章完整呈现该修复确立的暂停家族三态渲染契约resuming/suspended · N active/paused、leaseHolderPid从 checkpoint 一路穿透到渲染层的实现链路、signal-0 存活探针的语义以及从 failing-first 单测、真实进程级 QA 驱动到五透镜评审的完整质量证据链。读完你将掌握如何在 TUI 中对正在恢复与真正停摆的暂停 run 做诚实呈现如何用最小侵入纯展示层 可选字段投影修复一个会误导用户的显示缺陷以及 OmO 工程中测试先行 真实表面驱动 前后对照的 QA 方法论。一、缺陷背景头部说暂停车道却说运行中在 OmO 的 DAG 工作流中一次多波次wave执行被会话关闭暂停后TUI 的任务组件头部会直接渲染 checkpoint 中的原始run.status。在恢复-对账resume-reconcile窗口期widget 会打印出这样的矛盾画面⏸ ship-it paused wave 1/1 0/2 done, 1 running ▶ alpha · category:quick · 0s头部声称该 run 已暂停、处于空闲状态而正下方的节点行却声称alpha仍在运行——这两者不可能同时为真。根据证据目录中的缺陷描述README.md根因非常清晰头部直接使用原始run.status渲染没有任何上下文修正真正能化解矛盾的唯一信息——leaseHolderPid恢复租约持有者的宿主机 pid由claimPausedRun写入、在 shutdown pause 时清除——从未离开 checkpoint 记录因此没有任何展示层可以读取它。换句话说引擎内部早已知道这个暂停的 run 正在被另一个进程认领恢复但这条信息被锁在持久化记录里渲染层拿不到只能凭status字段猜于是撒了一个显示层面的谎。二、三态渲染契约暂停家族如何做到诚实修复确立的显示契约定义在 gate-b-review.md 的 Lens 1 中并在 README 中以表格形式固化。当run.status paused时头部状态文案按下述优先级解析条件头部状态文案leaseHolderPid存在且该 pid 存活resuming无存活租约且至少 1 个节点处于running状态suspended · N activeN 运行中节点数其他情况paused与之配套的图标规则同样关键run 级图标整个暂停家族统一使用中性符号·永远不使用⏸。PAUSED_RUN_ICON直接短路NODE_ICONS避免头部⏸与车道▶并存的自相矛盾节点级图标真正运行中的车道仍保留▶不受影响——节点图标描述的是节点自身事实头部图标描述的是 run 级事实二者各司其职。实现位于 dag-status-row-format.ts 的runHeaderRow/pausedStatusTextconst PAUSED_RUN_ICON · // L94暂停家族的 run 级图标故意中性 function runHeaderRow(run: DagStatusRunSnapshot, isAlive: (pid: number) boolean): string { const paused run.status paused const icon paused ? PAUSED_RUN_ICON : (NODE_ICONS[run.status] ?? ○) const name excerptRendererText(normalizeRendererText(run.name), LABEL_MAX) const status paused ? pausedStatusText(run, isAlive) : normalizeRendererText(run.status) return ${icon} ${name} ${status} ${waveLabel(run)} ${countsLabel(run)} } // L152-L156优先级是刻意设计的 function pausedStatusText(run: DagStatusRunSnapshot, isAlive: (pid: number) boolean): string { if (run.leaseHolderPid ! undefined isAlive(run.leaseHolderPid)) return resuming const running run.nodes.reduce((count, node) count (node.state running ? 1 : 0), 0) return running 0 ? suspended · ${running} active : paused }代码注释解释了优先级背后的设计意图存活租约意味着另一个进程已经认领该 run 并正在对账此时再画 paused 会在一帧之内就过期而没有租约时仍处于running的节点是搁浅的工作头部必须直面并承担它们而不是用 paused 把事实藏起来。signal-0 存活探针ESRCH 之外的哲学pid 是否存活由 dag-status-row-format.ts 的isProcessAlive判定采用signal-0 探针// Signal 0 probes existence without delivering anything. ESRCH is the only gone answer: EPERM // means the pid exists under another uid, which still counts as a live lease holder. function isProcessAlive(pid: number): boolean { try { process.kill(pid, 0) return true } catch (error) { return (error as NodeJS.ErrnoException).code ! ESRCH } }要点有三process.kill(pid, 0)不会投递任何信号只是探询进程是否存在因此不存在误杀风险ESRCH是唯一的已消失答案EPERM意味着 pid 存在于另一个 uid 之下仍然计为存活——探针按存在即活而非我可控才活来判定。此外runRows的选项还提供了isProcessAlive注入缝dag-status-row-format.ts测试与 QA 驱动可以替换探针实现而生产环境默认走 signal-0。三、数据通路leaseHolderPid从 checkpoint 穿透到渲染层要让渲染层能分辨resuming/suspended必须先让leaseHolderPid走出 checkpoint。这条通路贯穿四个模块评审文档Lens 1明确点名了每一处且每一处都有对应测试1. 持久化记录DagRunRecordV1新增可选字段manager.ts 中的DagRunRecordV1增加两个可选字段// Resume lease: recovery claims a paused run by writing the claiming host pid here and drops the // field on shutdown pause (see recovery.ts). Absent on records written before the lease existed. readonly leaseHolderPid?: number readonly previousLeaseHolderPid?: number注意可选 缺省即无的设计旧记录legacy没有该字段读取方必须容忍其缺失previousLeaseHolderPid用于租约移交场景下的历史追踪。2. 引擎侧守护liveLeaseHolder决定真实控制流评审文档特别强调这个 pid 不是仅供展示的花瓶字段引擎本身早就在用同源的 pid 决定真实控制流。manager.ts 的liveLeaseHolder就是证明function liveLeaseHolder(record: DagRunRecordV1): boolean { const pid record.leaseHolderPid ?? record.previousLeaseHolderPid if (pid undefined) return false return defaultSignaller.isAlive(pid) }它被用在两处关键决策暂停 run 的修订防护manager.tsif (oldRecord.status paused liveLeaseHolder(oldRecord)) { throw new DagManagerError({ code: invalid_amendment, message: dag run ${selectedRunId} is paused by another live lease, runId: selectedRunId }) }即被另一个存活租约暂停的 run 不允许被修订以及 reducer 中的幂等防护manager.tsif (record.status paused liveLeaseHolder(record)) return record。这说明展示层读取的 pid 与引擎控制流判定的是同一个信任域不是引入新的外部输入。3. 租约生命周期claim 写入、shutdown 清除、release 释放leaseHolderPid的写入与清除由恢复模块 recovery.ts 管理认领claimclaimPausedRun在确认 run 仍为paused且前租约持有者已消失后写入leaseHolderPid: context.hostPid并重写 checkpointrecovery.tsshutdown 暂停清除pauseRunsForShutdown在暂停 run 时把leaseHolderPid一并清除并把旧值记入previousLeaseHolderPid所以被暂停但无租约是一个合法且可判定的状态释放releasereleaseLease仅在fresh.leaseHolderPid context.hostPid时清除字段recovery.ts防止误释放他人租约跳过原因resumePausedRuns遇到live_lease时返回holderPid供上层观察并延迟重试——这正是 dag-runtime.ts 中watchLiveLease的场景前任宿主进程正在退出但仍持有租约时runtime 会 watch 该 pid待其消失后再次触发恢复避免 run 永远停在 paused。4. 快照投影两处projectSnapshot保持对等DagRunSnapshot类型在 types.ts 中新增可选字段注释明确其用途// Host pid holding the resume lease on a paused run. Display surfaces need it to tell a run that // is being resumed right now from one that is genuinely parked. Absent unless a claim is held. readonly leaseHolderPid?: number投影采用spread-guarded写法——字段缺失时完全不出现而非序列化为undefinedmanager.ts 与 handle.ts 两处projectSnapshot完全一致...(record.leaseHolderPid undefined ? {} : { leaseHolderPid: record.leaseHolderPid }),评审文档Lens 1特意点名handle.ts的投影是为对等性parity而加attach/wait返回的快照与 manager 快照行为一致避免同一 run 在不同 API 下呈现不同的事实。5. 桥接 payloadlease_holder_pid走上线缆omo.dag.updated事件体由 dag-snapshot-payload.ts 生成。桥接快照类型同样新增可选leaseHolderPidL51-L53并按既定 wire 契约转为 snake_caseL98...(run.leaseHolderPid undefined ? {} : { lease_holder_pid: run.leaseHolderPid }),这里刻意沿用omo.task.updated已有的 snake_case wire 契约可选字段保持缺失即无绝不序列化为null。这一项的意义在于GUI 查看器如 omo-desktop-app也能实现与 TUI 相同的 resuming/suspended 区分而不仅限于终端组件。6. 渲染层只读缝结构性镜像值得注意的一个实现细节formatter 并没有直接 import 引擎的DagRunSnapshot而是在 dag-status-row-format.ts 本地声明了一个结构性镜像DagStatusRunSnapshot含可选leaseHolderPid?: number并注释说明结构镜像 senpi-task 的 dag 领域契约本地声明以便 widget 保持只读消费者身份无论扩展接入的是哪个 DagManager 实例。 这是 OmO 适配层常见的只读缝模式展示方只依赖形状不依赖具体实例。四、QA 证据链从 failing-first 单测到真实进程级驱动评审文档 Lens 2 对质量证据的判定是 PASS其证据链本身就是一个可复用的 QA 模板。1. Failing-first 单测先红后绿三条显示规则以先写失败的测试形式加入 dag-status-row-format.test.tsdescribe(runRows paused run header honesty, () { const LIVE_PID 4242 const DEAD_PID 4243 const isProcessAlive (pid: number): boolean pid LIVE_PID it(...lease holder alive... header reads resuming under the neutral icon, () { // paused 存活租约 - resuming无 paused无 ⏸运行车道保留 ▶ expect(rendered[0]).toContain(resuming) expect(rendered[0]).not.toContain(paused) expect(rendered[0].startsWith(· )).toBe(true) expect(rendered[0]).not.toContain(⏸) expect(rendered[1]).toContain(▶) }) it(...no live lease and running nodes... suspended with the active count, () { // paused 死租约 2 个 running 节点 - suspended · 2 active expect(rendered[0]).toContain(suspended · 2 active) }) it(...no live lease and no running nodes... still reads paused, () { // paused 死租约 无 running 节点 - 仍为 paused expect(rendered[0]).toContain(paused) }) })红色捕获red-dag-status-row-format.txt12 通过、3 失败即三条显示规则red-typecheck-omo-senpi.txt6 个类型错误因为leaseHolderPid/isProcessAlive尚未上类型red-dag-snapshot-payload.txt9 通过、1 失败lease_holder_pid未上线缆证明这些测试确实在守卫该行为而不是事后照着成品实现编出来的。2. 真实表面驱动dag-paused-header-qa.ts单测之外QA 还提供了一个不依赖任何 stub 的端到端驱动 dag-paused-header-qa.ts其头部注释说明设计目标Drives the REAL surfaces end to end: a real on-diskDagFileStore, the real recovery pause/claim writes that ownleaseHolderPid, the realDagManagersnapshot projection, and the realcreateDagStatusUiwidget render.驱动流程对评审文档与 README 的还原种子写入通过store.writeCheckpoint写入一个status: running的 run节点alpha置为 running真实 shutdown 暂停调用createDagRecovery().pauseRunsForShutdown(PARENT_SESSION)断言租约被清除、状态变为paused真实认领由真正存活的子进程spawn(process.execPath, [-e, setTimeout(() {}, 60000)])执行认领写入leaseHolderPid: livePidCase A渲染 widget 行断言头部含resuming、无⏸、以·开头、运行车道保留▶Case B对子进程SIGKILL并等待退出再用同一存储渲染——死租约分支面对的是真实 pid 从存活到被杀的转换不可能靠 stub 之间的默契通过Case C把 running 节点改写为 pending无运行节点断言头部回落为中性图标下的paused输出 JSON 报告到out-dir任何契约违例都以非零退出码结束。运行结果after-live-dag-header.txt展示了修复前后同一个驱动、同一存储形态下的对照修复前base b9c04adbdformatter 回退result FAIL7 处契约违例 resuming_header: ⏸ ship-it paused wave 1/1 0/2 done, 1 running suspended_header: ⏸ ship-it paused wave 1/1 0/2 done, 1 running paused_header: ⏸ ship-it paused wave 1/1 0/2 done # 三种情境渲染结果完全相同——正是被报告的谎言 修复后result PASS0 失败 resuming_header: · ship-it resuming wave 1/1 0/2 done, 1 running suspended_header: · ship-it suspended · 1 active wave 1/1 0/2 done, 1 running paused_header: · ship-it paused wave 1/1 0/2 done resuming_rows[1]: ▶ alpha · category:quick · 0s - 节点图标不变前后对照的价值在于可归因性同一个驱动、同一个存储形态唯一差异是 formatter 变更因此红绿差异只能由该变更引起。3. 隔离证明与既有失败归因隔离证明isolation-proof.txt驱动的全部文件系统写入面仅限自己的mkdtempSync状态目录与显式 out-dir从不读写 agent 目录。对~/.senpi/agent与~/.omo/agent做整目录 watch驱动运行期间有 25 个路径变化而无驱动运行的对照窗口有 29 个——说明这些 churn 来自本机自身的 agent 会话与驱动无关临时目录在finally中清理不留沙箱残留。既有失败归因baseline-preexisting-failures.txtbun run test:senpi的 14 个失败中有 13 个是既有的无关失败init-deep-advisor、cli-local安装回路、OmO native 身份等其中 11 个在本分支变更 stash 掉之后仍可复现。第 14 个dag-status-ui each state renders its own icon断言的是旧的⏸run 头部契约被更新为新契约其节点图标断言未动而非删除。无敏感信息任何 artifact 中都不出现密钥、token、认证头、环境变量转储或凭据机器相关值只有临时路径和一个瞬态子进程 pid。4. 绿色门禁汇总门禁结果tsgo -p packages/omo-senpi/tsgo -p packages/senpi-task均 exit 0omo-senpitask 组件套件483 通过 / 0 失败63 文件senpi-taskdag 套件243 通过 / 0 失败16 文件双作用域合并726 通过 / 0 失败79 文件五、五透镜评审Gate B 自审记录由于review-workskill5 个并行评审子代理在当前环境不可用、任务子节点也无法派发子代理评审直接对git diff origin/dev...HEAD进行形成这份五透镜记录gate-b-review.mdLens 1 — 目标验证PASS。显示契约逐条核对无误前文三态表leaseHolderPid已穿透manager.ts与handle.ts的projectSnapshot及桥接 payload且各带测试。Lens 2 — QA 证据PASS。红色捕获3 条显示规则失败 6 个类型错误 1 个 payload 失败、绿色捕获、真实前后驱动 JSON、隔离证明、既有失败归因一应俱全证据 README 覆盖 what-tested / observed / why-enough / omitted。Lens 3 — 代码质量一个发现已修复。QA 驱动携带了一个废弃的isAliveOverride参数及遗留的void空操作在 commit7cf5c476中移除驱动重跑 PASStsgo -p packages/omo-senpi保持干净。剩余的类型断言runId as DagRunId、伪造的setWidget对象镜像了 dag-runtime.ts 中适配器自身的接线方式只为在独立脚本中满足 widget 的主机侧接缝。Lens 4 — 安全PASS。无新增输入面、无密钥处理、无日志新增。pid 来自引擎自身 checkpoint与既有的liveLeaseHolder/node-control-context防护同信任域signal-0 探针不投递信号把 pid 加入omo.dag.updatedpayload 与既有 task payload 已向同一查看器暴露宿主 pid 的信任域一致。Lens 5 — 上下文挖掘PASS一条备注。全库搜索 run 状态的其他渲染点dag-commands.ts 的summaryHeader在单行/dag列表中打印原始状态、无逐节点行因此不可能产生本 PR 针对的暂停头部 vs 运行车道矛盾/dag工具消息同样向模型报告事实性记录状态。两者都在显示契约TUI run 头部的声明范围之外而 wire payload 现已携带lease_holder_pidGUI 查看器可实现同样的区分。未发现其他按节点渲染暂停家族的使用方。结论Gate B PASS在一次自查修复之后。Gate C 记录SKIPPEDquota/availability。PR #7322 上从未出现cubic-dev-ai[bot]评审评审列表为空Cubic 自身检查条目报告skipping3s。PR 提交后限时等待 5 分钟产出 0 条评审。按 work-with-pr 循环这是唯一被认可的跳过条件——记录在案而非默默放行。Issues 从来不是跳过的理由且其他任何 gate 均未发现 issues。六、变更边界与兼容性为什么这个修复足够小、足够安全评审文档Lens 3对 shipped-code diff 的界定值得单独强调DagRunRecordV1上两个可选字段并顺带折叠了liveLeaseHolder中一个既有 castDagRunSnapshot与桥接快照各一个可选字段两处 spread-guarded 投影formatter 变更。引擎、WAL、checkpoint、调度器、恢复逻辑一行未动——恢复代码本就在通过本地 cast 写这个 pid这次只是把该事实正式模型化并投影出去。可选字段 缺省即无的组合保证旧记录无leaseHolderPid读取兼容显示层回退到纯paused无租约持有时的 payload 与旧格式字节级一致既有的 omo-desktop-app reducer-contract 测试仍钉住普通 run 的未触及字段集新增字段是纯增量不存在破坏性 schema 变更。Rebase 期间 PR #7320fix/dag-recovery-nonblocking触碰recovery.ts、scheduler.ts与受管omo-task.jsbundle先行合入 dev唯一的冲突是生成的 bundle按 smart-rebase 契约重新生成即可无语义冲突rebase 后重新验证 728 通过 / 0 失败比此前 726 多出的 2 例正是 dev 新增的recovery-nonblocking用例。七、可复用的工程要点从这次修复中可以提炼出几条超越单一 bug 的方法论显示层要撒谎时先找引擎里已有的真相leaseHolderPid一直存在、一直驱动真实控制流只是没被投影。让展示层复用引擎已有的信任域字段比另造一套状态机便宜得多、也安全得多。状态文案的优先级就是业务语义resuming优先于suspended优先于paused每条分支对应一个可判定的物理事实有存活租约 / 有运行节点 / 都没有而不是对status字符串的格式化。图标也是契约的一部分头部·与节点▶的分工把run 级事实与节点级事实解耦中性符号在矛盾窗口期不主张任何运动避免视觉谎言。failing-first 真实表面驱动双保险单测证明规则真实进程级驱动证明用户真正看到的表面用同一个驱动跑 before/after把差异归因到唯一变量。评审记录本身是交付物五透镜记录 Gate C 的显式跳过理由quota 条件 限时等待证据把什么被验证、什么被省略、为什么足够完整留给后人而不是只留一个 PASS 结论。若需继续深入可对照阅读同一证据目录下的 README.md缺陷与契约的完整叙述、formatter 实现 dag-status-row-format.ts、类型定义 types.ts以及驱动脚本 dag-paused-header-qa.ts 与恢复模块 recovery.ts 中租约的写入/清除逻辑。【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
