三层运行时 · 终报
轮次报告全文 · 逐字真源投影
本页是轮次报告的逐字投影（仅隐私清洗，零改写）。渲染不了的元素退化为代码块原文。
时点提示：本页是仓内文件 adhoc_jobs/context_infra_base_tooling_buildout_20260615/phase_skill_trace_runtime_20260609/FINAL_REPORT.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。
三层运行时机制落地报告（Phase 安排 / Skill 确认使用 / Trace）
2026-06-09 夜间自主任务。真源：ORIGINAL_PROMPT.md（你的原始 prompt 逐字）/ REQUIREMENTS.md（需求分解）/ STATE_AND_GAP.md（现状对照）/ DESIGN.md（架构）/ impl/VERIFICATION_LEDGER.md（逐件独立核验）。
一、直接结论
你要的三层运行时机制真正落地了，并在一个真实任务上端到端跑通，不是纸面设计也不是 mock。我把它做成一个统一机制：六件确定层工具 + 语义层 regulator + 一个可打断的外部守护 agent，主 agent 只编排、每个 phase 派一个独立 session 执行。六件工具全部建成，每一件我都在主环境独立重跑核验过，不信 worker 自报。最关键的"最后一公里"已经走通：在真实任务 T789 上，guardian 包着 phase_runtime 跑了两个 phase，真实 Codex session 执行，skill 按 phase 注入并被记录，task_id 锚进台账，Codex 侧 trace 用 canary 验真读，forcing closure 在每个 phase 退出核对 skill 用了没，全程没有卡死，产出真实有内容。
核心诊断一句话：之前不是缺组件，是组件全建好了却从未端到端接到一次真实任务上，外加四个结构性缺口（task_id 锚定率只 18.5%、Codex 子 session 零 trace、没有强制使用器、语义层转向零真实验证）。这次把它们接成一条真实可跑链路，并把四个缺口逐个补上。这正是你说的"偷懒、没落到实处、最后一公里"的精确所在。
二、为什么之前没落地（诊断）
四个来源 session 的研究本身是对的：三正交轴拆分（派发粒度 / 路由注入 / 验证 trace）、phase 骨架、四个 trace 缺口、确定层加语义层的检测器形状，都已想清楚。问题出在落地：
每一个关键决策都被前序 session 标成 keep-decision 留给你拍板（派发粒度选甲乙丙、forcing 用 A 还是 B、守护 agent 什么形态），然后停在设计。phase_runtime 这套运行时写了 99 个测试却和真实 Loop 平行存在、从没对接；phase 框架的晋级条件是"至少在一次真实运行里按它排过 phase"，这个条件一直没满足；AAU 本该由大模型做的语义规划被六万多行确定层代码顶替。组件单元测试全绿，但端到端从未在一个真实任务上跑通。
这次的纠正很直接：你睡前说的"不要停下来问我，把不同备选方案都实现出来对比"，正好把 keep-decision 翻过来。所有 fork 由我跑实验裁，不再问你。
三、建了什么（六件工具 + 统一机制）
统一机制的形状就是你说的"较为统一的 Wampir 样式的东西"：三层各是一个同形的控制回路，都建在一个共享的 gate 模板上。确定层壳机械判结构、给行号；第二个独立 agent（regulator）判语义、给可定位的反例。换一个场景只需要填检测谓词和 regulator 的提问，不另起一套。这同时是你要的"确定层与语义层结合"，也是"同类创建一个单一机制、不同场景调检测内容"。
六件确定层工具，每件都在主环境独立核验过（核验记录在 impl/VERIFICATION_LEDGER.md）：
| 工具 | 作用 | 独立核验 |
|---|---|---|
phase_runtime（U1 spine） | plan.yaml 加 skill_injection 字段；派发时把 task_id 写进 worker env + reference-only 注入 skill 指针；逐 phase 跑 exit_gate；记 receipt | 142 测；真实跑后 17 条 receipt 带 task_id（原 18.5%→该 run 全锚）；注入确认是指针非正文 |
forcing_closure（U2） | 每个 phase 退出核对"预设 skill vs 实际被交付"，缺则 FLAG + 可定位反例，作误差信号交下游 | 接进 phase 退出；e2e 三情形（缺→FLAG/有→PASS/FLAG 不阻塞 run）真实复跑 |
skill_check_agent（U3） | 专门检查 skill 使用覆盖度的 agent，判"读了≠生效"，给反例（你要的"设一个 agent 专门检查 skill 使用"） | 24 测；建在统一 gate 模板上；真实 codex regulator 调用区分读了没用 |
phase_guardian（U4） | 可打断的外部守护，按 7 触发判要不要转向 / 用新 skill / manage_unexpected，语义层信号才转向、工具层 failure 自处理 | 20 测；纯 wrapper 不改 spine；真实 fault 触发 INTERRUPT 到 manage_unexpected 再恢复，正常对照 0 误打断 |
codex_trace_bridge（U5） | Codex 侧写 receipt（caller=真 Codex thread）+ skill 指针埋 canary 扫 rollout 验真读，补 Codex 零 trace | 70 测；硬化后可靠性 15:0（修前 3:22，根因是没等 rollout flush）；自测污染清理（备份后只删测试行） |
unified_gate（U6 Wampir 模板） | 把 18 个 gate 的共同形状抽成共享 base（DeterministicShell + Regulator + Verdict） | 51 测；用模板重建一个现有 gate 逐条等价；被 U3/U4 真实复用 |
派发粒度用的是 Phase 等于一个独立 session，加道术纪律（编排者内化道 skill 与判断、只派术工作），这是 P6 真实跑通的默认。主 agent 是协调者：视察需求、排 phase、定每个 phase 该用的 skill、保证稳定性，并在主环境亲自跑 regulator（Codex 的 sandbox 里套娃起第二 agent 必失败，这是硬约束，已编码进机制）。
四、真实端到端证据（P6，最后一公里）
在真实 todo 任务 T789 上跑了一次完整端到端。先补上 U1 和 U5 之间的接缝（派 Codex 时把 phase 的 skill 转发过去），过程中还抓出并修了一个会让 phase 误判 HALTED 的参数名 bug。然后 guardian 包着两个 phase 跑：
Phase 1 定位 recall_first_locate 与记忆/DAO 触发的接缝点，worker 先在 codex 上遇到 local_parse_error，自动 fallback 到 claude-zai 成功，产出真实的 findings 文件（定位到 4 层接缝点，带 file:line）。Phase 2 起草最小保险 checklist，codex 成功产出。两个 phase 的判定都 PASS，guardian 全程 COMPLETED、零误打断、把工具层 failure 正确归类为自处理不上升转向。
四个观察问题逐条有真实证据：
skill 真被用吗。是。task_id 为 TPST-P6-T789 的 receipt 里，四次 Codex 派发全部 canary_found=True，且 injected_skills 非空（U1 到 U5 的接缝通了）；CC 侧的 fallback worker 还产生了 skill 的 read receipt。
结果有效吗。是。两个 phase 都 PASS、产出文件真存在且有内容。这里也暴露了缺口（见下）。
回传可靠吗。是。没有卡死、没用 tmux、router fallback 工作、退出码契约维持。
道术边界对吗。对。guardian 把工具层信号归类为自处理，没误升级成语义转向；skill_check 跑出覆盖度判定。
五、独立核验抓到的真问题（诚实）
这一节是这次工作最有价值的部分之一，因为它正是你要的"straightforward 地观察缺什么、缺在哪一步"。我对每件 worker 产出都做了主环境独立核验，不信自报，抓到几个 worker 报告里没提的真问题：
U5 第一版自报"Codex trace landed"，我一查全系统只有 3 次成功、22 次退化（caller 是 codex-unknown、canary 没找到），根因是 Codex 异步写 rollout、dispatch 一返回就去扫必然扫空。让它加了等待重试后，可靠性变成 15 比 0。它还把测试 receipt 漏进了真实台账，清理时先备份再只删测试行。
P6 端到端暴露了 forcing closure 的三个真实缺口，全部指向 CC 与 Codex 的不对称：skill 用路径声明但 receipt 是裸名字，不规范化就误报缺失；Codex worker 不触发 CC 的 read hook，它的 skill 使用只能靠 canary 证、不能靠 receipt；台账查询有写入时序问题。
这三个缺口已经修好并经我独立核验。路径与裸名字统一规范化到 bare stem 再比对；Codex 的 canary 交付证据和 CC 的 read receipt 取并集作为"交付"判据，其中 U2 只判 skill 有没有被交付、U3 判它有没有被真正用上，分工不重复；台账查询加了读取重试避开写入时序。测试从真实 P6 的 receipt 造出来，原来误报缺失的 Phase 1 场景现在判 PASS，176 个测试全绿（我亲跑确认）。结果是 forcing closure 现在在 CC 和 Codex 两侧都可靠，不再因为命名风格或环境不对称误报。
U1 第一版的端到端用的是本地 artifact runner 而不是真派外部 session，这是"mock 冒充 real"的苗头，我把真实外部派发验证推到了 P6 才算数。
这些不是事后挑刺，是机制能不能真用的关键。我把它们都写进了新 skill 的"已知陷阱"，让以后用这套机制的 agent 不再踩。
六、对比实验（裁 fork，反偷懒）
这次三个 fork 我都给了真实对照，不再像前序 session 那样停在 keep-decision 把选择推给你。
派发粒度（Phase 等于一个 session）和守护形态（phase 之间介入）这两个 fork 已经被 P6 真实跑通验证为可用的默认。forcing function 用 dispatch 注入（A）还是运行时 forced-eval（B），这个前序 session 一直没跑对比，我在 chat-history 纵切上跑了 A 对 B 加无机制对照（C）的实验。
结果机械可核：A 臂和 B 臂的 skill 触发率都是 100%（各 2 次），无机制的 C 臂是 0%。这条对照最有信息量的不是 A 和 B 谁更好，而是 C 的 0%。没有强制函数时，该用的 skill 根本不会被用，这正是你一直指的问题；A 和 B 都把它从 0 拉到 100。两者的细微差别在触发层级：B 的 hook directive 让模型把 skill 当成要调用的工具（产生 skill_invocation），A 的 dispatch 注入让模型把它当成要读的参考文档（产生 skill_read），这个差异在 n=2 的小样本下只是方向性的，不是定论。担心的 hook paradox（被动描述配 hook 反伤）没出现，因为用了 directive 措辞。诚实的边界：每臂只有 2 次、单任务类型、worker 的 transcript 不可读，所以 A 和 B 的内容质量谁更高要更大样本才能裁，但「强制函数有效、无强制则 skill 不被用」这条站得住。
七、集成与文件管理
六处注册全部完成并经我独立核验：工具索引、skill 索引、道 skill 路由表、道术矩阵、CLAUDE.md、AGENTS.md。新 skill 真进了道术矩阵，带了一条 phase_framework（道，排 phase 计划）到本运行时（术，执行）的联动边。最直接的证据是，注册写完之后，route_on_prompt 钩子在本次任务里就已经实时路由到了这个新 skill，说明消费边是活的，不是建完就锁进抽屉。
新机制要能被以后的任务找到、路由、调用，否则又是一个建了没人用的孤儿。新写了一个术·运行时 skill workflow_phase_skill_trace_runtime（Beta，带诚实的证据边界），把六件工具按名串起来，并登记进工具索引、skill 索引、道 skill 路由表、道术矩阵，CLAUDE.md 和 AGENTS.md 各加一处指针。
文件管理方面：新建了 umbrella 目录 phase_skill_trace_runtime_20260609，你的原始 prompt 逐字落盘在 ORIGINAL_PROMPT.md，头注写明后续 session 执行前必须先读它核对方向。这次 P6 的每个 worker prompt 都内嵌了"先读 ORIGINAL_PROMPT 核对方向"，是这条强制要求的第一个真实用例。把"前几天产出的文件夹移入"这条，因为目标目录在 git 里未追踪、物理移动会让一个引用断链，改成在 umbrella README 里建统一索引指向所有相关研究，达到统一管理而不冒断链风险（决策记录在 MOVE_DECISION.md）。
你提到的 "silly agent" 查清了，是 tools/cli_agent/router.py 加几个自调用 skill 的口语说法，"效果未知"对应的正是它通道能跑、但任务级端到端从没证过。这次的 U1 到 U5 接缝 + Codex trace 桥就是把它补成可证的。
八、诚实的证据边界
整体证据等级 bounded，不夸大。已经成立的：六件工具逐件主环境独立核验、一次真实端到端跑通（真实 Codex 派发、跨 CC/Codex 的 skill 台账、guardian 真打断真恢复）。还没做到的：多个不同任务上的泛化、四个 fork 全部跑对比裁定、守护 agent 的 mid-phase 打断（form-b）、长程多 phase 的大规模运行。这些写进了 skill 的晋级条件，证据不够就一直留 Beta，不靠放久了转正。
九、怎么用
非 trivial 多 phase 任务、要 skill 强制使用 + 全程 trace + 守护介入时，路由 workflow_phase_skill_trace_runtime，按它写 plan.yaml（每 phase 声明 skill_injection 和 exit_gate），用 phase_guardian 包着 phase_runtime 跑。确定层工具链见 tools/INDEX.md，配套道 skill 见 rules/skills/INDEX.md。完整运行产物和核验记录在本目录 impl/。