三层运行时 · round2 终报

Z3 全文↑ Z2 条目

轮次报告全文 · 逐字真源投影

本页是轮次报告的逐字投影（仅隐私清洗，零改写）。渲染不了的元素退化为代码块原文。

时点提示：本页是仓内文件 adhoc_jobs/context_infra_base_tooling_buildout_20260615/phase_skill_trace_runtime_20260609/optimization_round2_20260610/FINAL_REPORT.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。

Final Report — phase/skill/trace runtime 优化第二轮（Goal-Loop 接力段，2026-06-10）

任务锚：T827 ｜需求真源：PROMPT_ANTHOLOGY.md（O-01~O-16、R3-01~R3-27、R4-01~R4-04）｜过程账本：GOAL.md「当前状态」节（24 轮唤醒逐轮记录，本报告全部内容可在账本与 receipts 台账中找到落点）

一段话结论

本轮把 phase_session_driver（用 tmux 驱动 Claude Code session 自动跑多阶段任务的确定层工具）从「三连败、每次失败原因不明」修到「生产可用」：今天全天 8 次 driver 生命周期，修复完成后的 7 次全部完整闭合、零失败、零放弃，其中 5 次是 Codex 协调者在我们之外自发使用（有机采用），启动全部一次成功。修复过程共揭开六层互相叠加的缺陷，每层都按「可复用机制」原则修复（用户 R4-03 要求），没有引入任何针对单一通道的特异补丁。监护循环已按用户指令在核验无问题后停止。

(b) 原始需求：Prompt 逐字原文

本接力段的任务来源是用户在驱动权交接时的指令（完整逐字冻结于 PROMPT_ANTHOLOGY.md §1c，编号 R4-01~R4-04；全项目需求谱系 O-01~O-16 与 R3-01~R3-27 同在该文件）：

关于这个任务，之前已经做过测试了，但现在的 context 快要满了，我希望在新的 context 下继续执行。

另外，请把唤醒频率改为大约半个小时一次。我们需要去迭代这个项目并发现其中的问题。在迭代过程中，更好的一种实现方式应该是添加一些可复用的资源，不要去做那种非常特异化的补充，因为这样做意义不大。我们更多地应该从可复用性和实现的有效性上来考虑整体的实现方案。

请你继续完成任务。任务的来源是我之前在那个 session 中让它整理出来的 prompt，以及它产出的一些 goal。我会把这两部分整合在一起，以便更好、更完整地实现我们的任务。

收尾指令（2026-06-10 21:2x）：

你可以去检查一下那些任务在执行过程中的使用情况。……如果确实没问题的话，就可以停止这个唤醒了。你可以使用写 Final Report 的 skill，给我们的实习项目写一个 Final Report 吧。

本轮的工作方式（任务怎么做的）

据上述指令，本 session 以约 30 分钟一轮的自唤醒循环驱动迭代，每轮固定动作：收后台实现切片 → 亲跑六测试套件验收（不信 worker 自报）→ 端到端重跑 → 把结果与下一步写进 GOAL.md 状态账（跨 session 持久真源）。实现一律派给 Codex（gpt-5.5 X-High）后台执行，验收、取证、根因判断、报告由本 session 亲做。测试只走 claude-zai / claude-kimi / codex 订阅通道。

(a) 专业术语注释

driver = phase_session_driver，在 tmux 里启动一个 Claude Code（下称 CC）session、投递初始任务、在 phase 边界注入推进指令、检测完成后退出的看门进程。pause_at_boundary = 被驱动 session 每完成一个 phase 停一下、由 driver 投递下一阶段指令的运行模式。receipt = 确定层工具写入统一台账的调用凭据（带 TR-编号），是全部验证的证据来源，开头任务锚里的「receipts 台账」即此。nonce 认领 = driver 在初始任务文本里埋一个一次性随机标记（nonce），扫描新出现的 session 记录文件、找到含该标记者，即确认投递真正生效。deliver_and_confirm = 本轮抽出的投递原语：投递动作 × 下游效应确认谓词 × 有界补回车重试，重试次数以 submit_retries 字段记进 receipt。canary = 给 Codex 注入 skill 时埋的标记 token，在其会话记录里扫到即证明 skill 被真实读取。

(c) 实现逻辑 + 为什么有效：六层缺陷与对应机制

每层缺陷都由一次真实端到端失败暴露，按「失败 → 取证 → 通用机制修复 → 重跑验证」推进。贯穿六层的有效性原理是一条：判断系统状态只用可观察的下游效应，不用对内部行为的假设——就绪不猜「等多久够」而看 tmux 原生信号，投递成功不信「命令返回 0」而看 nonce 被认领，skill 被用不信自报而看 canary/receipt。这使每个机制对任意通道与未来失败类型成立（用户 R4-03 的可复用性要求正是经此兑现）：

层	暴露现场	根因	可复用机制（修复）
1 启动崩溃无留痕	run1：裸 traceback、零 receipt	启动路径无 fail-safe	切片 3.2：启动全程 try/except，人话错误 + driver_error receipt + 清理半成品
2 环境不一致+取证缺失	run2：jsonl_ready_timeout（TR-001881），现场被清理无从取证	tmux 非 login shell 缺 profile 环境；失败先清理后取证	切片 3.3：所有通道经 login shell 启动；preflight 错误分类；失败取证 bundle 先于清理进 receipt；--keep-on-failure 保留现场；就绪窗可配
3 wrapper 潜伏 bug	run3：取证 bundle 显示 tmux server 整体消失；持留 pane 复现抓到临终输出	claude-zai 脚本空数组展开在 bash 3.2 + set -u 下秒死，仅无参调用触发（router 等历史调用方总是带 -p 等参数，所以从未暴露）	守卫展开修 claude_zai.sh 与同病的 claude_opus.sh（修模式非修单点；kimi 用 "$@" 天然免疫）
4 就绪信号用错	wrapper 修好后 run3 复跑仍超时：健康的 CC 空闲时不写 session jsonl	「等新 jsonl 再投递」是死锁协议，旧实现靠并发 session 的假阳性误打误撞	切片 3.4：就绪改 pane 信号、投递后才等 jsonl 认领；pipe-pane 常驻日志使 server 死后仍有取证
5 生死/活动谓词错	run4：1.1 秒误报 pane 死亡，而保留现场里 CC 健康待机	启动是 exec 链，pane 进程本身就是 claude，「查子进程」谓词必然误判；同一谓词在看护循环里又因 CC 常驻 helper 恒为真，停滞看门狗失效	切片 3.5：生死=tmux has-session（与进程树形状解耦），活动=jsonl mtime 主信号 + pane 内容 hash 兜底；session 消失当场裁决
6 投递不可靠	run5：prompt 粘进输入框未提交（人工补回车救活）；20 分钟后边界推进指令同样卡住（第二实例）	bracketed-paste TUI 会吞紧跟的回车，一次性投递无确认无重试	切片 3.6+3.7：抽统一原语 deliver_and_confirm——投递动作 × 下游效应确认谓词 × 有界补回车重试，初始 prompt（确认=nonce 认领）与边界推进（确认=jsonl 新活动）两路径同走；重试次数记进 receipt

每个切片落地都经过同一套验收：本 session 亲跑六套件（最终 381 passed 0 skip）、亲读改动 file:line、可复用性泄漏审查（grep 证零通道分支、零 UI 文本探测、零魔法等待值）。

(d) 变更前后对比（之前 vs 之后）

启动协议的变化（第 4、6 层合并视图）：

flowchart LR
  subgraph before [修复前]
    A[tmux new-session] --> B[等新 jsonl 出现<br/>实为死锁,靠假阳性偶通] --> C[paste + 紧跟 Enter<br/>Enter 常被吞,无确认]
  end
  subgraph after [修复后]
    D[preflight 验通道命令] --> E[login shell 启动<br/>pipe-pane 落盘取证] --> F[has-session 稳定窗就绪] --> G[paste → 延迟 → Enter] --> H{nonce 认领?}
    H -- 否,每10s --> I[补 bare Enter<br/>计入 submit_retries] --> H
    H -- 是 --> J[driver_started<br/>进看护循环]
  end

运行结果的变化（全部可在 receipts 台账复核）：

维度	修复前（今晨）	修复后（11:46 起）
端到端	run1~run4 四连败，前两次连失败原因都取证不到	8 次生命周期 7 闭合 + 1 健康在跑，零失败
失败可见性	裸 traceback / 静默死亡	每次失败有错误分类 + 取证 bundle + receipt（含 pane 临终输出）
投递可靠性	回车被吞即永久卡死，需人工发现并救活	自动重试，run6 启动时回车再次被吞、原语 1 次重试自动救活（TR-002034 submit_retries=1）
第三方使用	无	Codex 协调者自发串驱 5 个 session（它为每个被驱动 session 开一个名为 cc-relay-c1~c5 的 tmux 中继窗口），启动全部一次成功（16:08~21:10 持续）
运行模式覆盖	仅交互式 continuous 有先例	pause_at_boundary（run6 零人工全链）与 continuous（run7，Stop 驱动器自动推进、零外部 nudge）双模式 live 证据

Codex 侧（R3-21 对比实验）：派 Codex 重做一个 git 域历史检索任务（非 runtime 自指），ground truth 由本 session 事先离线锚定且不落任何 worker 可搜索的文件。结果四轴全过：答案与 GT 精确一致且落到 raw 行号（本 session 亲跑其复核命令验证）、注入的两个检索 skill 被 canary 证实真读（TR-002092）、派发链 receipt 完整、产物可见完整的召回纪律（机械枚举计数、候选前逐条负向排除）。对照历史 Codex 零 skill 零留痕的基线，过程差异每条有锚。诚实标注：n=1 观察性结论，未做无注入对照臂，不下因果断言。

遇到的问题（完整记录）

取证现场会自毁：tmux 在 pane 进程退出时连 server 一起带走，事后 capture-pane 什么都拿不到（run3 的 bundle 里 capture 为空就是这样产生的）。教训固化成机制：pipe-pane 从启动起持续落盘，失败 bundle 读日志尾部，现场死了证据还在。
同一个 bug 两副面孔：回车被吞先在初始投递出现（run5 启动），修了那一条路径后又在边界推进指令上复发（run5 中段，卡 20 分钟）。第二实例促成了把「投递并确认」抽成统一原语而不是各修各的，这正是可复用原则的直接收益。
两次人工干预的诚实账：run5 的启动和边界推进各靠一次人工回车救活，因此 run5 只计为机制链验证，干净通过的结论建立在 run6（全程零人工）上。
被驱动任务的内容瑕疵：run6 的 delta 报告把 driver_complete 拼成 driver_completed 导致漏数一条事件，并据此写了「driver 缺正常结束事件」的错误结论。已在账本标注，提醒下游读该产物时注意；这是被驱动模型（glm-5.1，zai 订阅通道的执行模型）的输出质量问题，与 driver 机制无关。
误判停滞一次（自纠）：监护轮曾因 30 分钟无生命周期事件怀疑 session 停滞，按双源纪律（receipt 活动 + jsonl mtime + 进程存活）复核后确认是正常长任务，未误干预。

与需求的对账（残差诚实标注）

O-08 推进稳定（重中之重）：driver 轨道 landed；continuous 模式 Stop 驱动器经 run7 与多个第三方 session 的 block→补足→advance→complete 负反馈链验证。
O-09 skill 精准：注入与留痕双边工作（CC 侧 usage_hook、Codex 侧 canary）；残差=phase_trigger_diff 数据仍全部来自单一触发源（stop_hook），多源覆盖待后续。
O-10 自省检查：本轮所有验收都走「执行者自报 + 独立亲核」双层，但作为常驻机制的 async 审判环仍是设计态。
O-14 真实落地：第三方有机采用已发生（5 次），但 GOAL 验收锚「≥3 个非自指 armed session 完整走链」严格口径下仍未达成——今天的完整链全部在 runtime/landing 自指域内，需要非管线域的有机使用积累，这不是再派切片能制造的。
R4-03 可复用：六层修复全部通过泄漏审查；deliver_and_confirm、取证 bundle、login-shell 启动对任意通道与未来注入路径成立。

Look-back 自检清单

产出本报告前的真实核对（非凭记忆）：重读 GOAL.md 状态账全部 24 轮条目核对时间线与 TR-编号；亲跑全天 driver 生命周期对账命令（receipts 台账聚合：8 started / 7 complete / 0 giveup / 3 error 全在修复前）；逐项核对六层表格的 file:line 与切片 REPORT 一致；02601c6e 在跑状态以 21:10:05 的 phase_block receipt 实查确认；报告初稿经零背景 sub-agent 卡点扫描（6 条全部修复）+ check_report_completeness 确定层 gate 过检后交付。

收尾状态与指针

监护循环按用户指令于 21:3x 核验无问题后停止（最后一轮全量对账：8 started / 7 complete / 0 giveup / 0 undelivered / 错误仅修复前 3 条）。在跑的 02601c6e（cc-relay-c5）由其 Codex 协调者与 driver 看门狗继续看护，不需要本循环。cron hourly 兜底 job 仍在（7 天自动过期），其每轮按 GOAL 调度形态节只做核对。

延续工作的入口：GOAL.md（状态账 + 检查清单）、PROMPT_ANTHOLOGY.md（需求真源）、impl_slice3_2~3_7/REPORT.md（各切片实现细节）、r3_21_codex_redo/COMPARISON_VERDICT.md（Codex 对比裁定）、contexts/runtime/phase_state/failures/ 与 pane_logs/（全部失败取证原件）。

← 返回报告库 · Base Tooling buildout 轮次