三层运行时统一机制（Phase 安排 / Skill 确认使用 / Trace）

术-运行时 · 术层 skill 全文

本页是 <code>rules/skills/drafts/workflow_phase_skill_trace_runtime.md</code> 的逐字投影（仅隐私清洗，零改写）。

name: workflow_phase_skill_trace_runtime
description: 把一个非 trivial 多 phase 任务真正跑起来的运行时（术·运行时，配套确定层工具链）。两个模式：模式A=交互式钩子链（默认入口，live）——用户敲 claude（或 claude -p 非交互）后，hook 自动注入排 phase 指令、逐 turn 注入当前 phase 的 skill 要求、Stop 驱动器机械核验义务并自动推进 phase、全程 receipt 留痕；模式B=spawn 派发（内部机制）——主 session 经 session_dispatch / phase_runtime 派独立 phase-session 或 skill-session（Codex/CC），dispatch 时注入 + canary 验证。区别于 workflow_phase_framework（道，怎么排 phase 计划），本 skill 是那份计划怎么被机械执行下去。
type: Workflow（术·运行时 / 三层统一机制执行面）
status: draft (Beta) — 模式A 已 live 接线（settings.json Stop + UserPromptSubmit，2026-06-09 W2，commit a14a3eb2f）；晋级前需 ≥2 个真实任务经模式A 端到端（含 1 个非交互 claude -p）+ 模式B 对比实验
created: 2026-06-09
updated: 2026-06-09 (W2 两模式重构，取代「每 phase 派独立 session 为默认」的旧框定；旧版见 git 历史)

三层运行时统一机制（Phase 安排 / Skill 确认使用 / Trace）

一句话

一个非 trivial 任务排成几个 phase 依次穿过：每个 phase 有必用 skill 与机械 exit 判据，进入时要求被注入、退出时被确定层核验、推进自动发生、全程动作锚 task_id 留痕。入口是用户的交互式（或 -p 非交互）CC/Codex session 本身（corrected frame）；派发独立 session 是服务它的内部机制。

模式A：交互式钩子链（默认入口，live）

载体 = CC 的 UserPromptSubmit + PostToolUse + Stop 三个 hook（全部已接线，确定层必发）。从冷启动到完成：

1. 自动 arm：非 trivial prompt（≥200 字符或 ≥2 条 dao 路由命中）触发 arm 指令注入：按 workflow_phase_framework 排 phase 计划写成 plan.yaml（schema = tools/phase_runtime/plan_loader.py，每 phase 带 skill_injection.dao_skills/shu_skills + exit_criteria），然后 python3 -m tools.phase_state.cli arm --plan <plan.yaml> --session <sid>。确认 trivial 用 ... decline --session <sid> --reason <原因>。
2. 逐 phase 注入：每条 prompt，route_on_prompt 读本 session cursor，注入当前 phase 的必用 skill 指针 + task_prompt 重锚（每 turn 重注不去重，候选 B）。
3. 记录：usage_hook 给本 session 的 skill 读取/调用 receipt 打 phase / phase_id 标签；task_id 来自 dispatch env 或 todo 锚。
4. Stop 驱动器（自动推进，核心）：每个 turn 结束 stop_phase_check.py 机械核验当前 phase——required_skills 是否有本 session 本 phase 的 receipt + artifact_exists: / artifact_contains: exit 判据。未满足 → 写 correction + exit 2 阻断停止（agent 继续干，缺口逐条可操作）；满足 → 自动 advance，还有下一 phase 就带着新 phase 要求继续；全部完成 → 发 phase_plan_complete 事件放行。被阻断时先跑 python3 -m tools.phase_state.cli status --session <sid> 看缺口。防卡死：每 phase 最多 3 次、全程最多 12 次阻断，超限发 phase_drive_giveup（FLAG）放行；CC 自身另有连续 block 上限兜底。
5. 纠正桥：Stop 写的 correction 在下一条 UserPromptSubmit 被一次性注入（中断/resume 也不丢）。

适用：CC 交互式与 claude -p 非交互（hook 同样触发）。Codex 交互式无 hook，只有 AGENTS.md 静态指引 + 事后 rollout 解析（不对称如实呈现）。

模式B：spawn 派发（内部机制；Codex 象限与重型子事务的主形态）

主 session（编排者）把 phase 或 skill 子事务派给独立 session 执行，clean context：

• phase-session：每 phase 一个独立 session + handoff（头部内嵌 ORIGINAL_PROMPT 重锚 + 该 phase dao/shu skills + forbidden_read + exit gate），经 session_dispatch（分派即 trace 事件）或 phase_runtime spine（plan 驱动 + forcing_closure）。turn 内无法重注入、headless 单发、Codex 零 hook 这三种场景下，这是逐 phase 注入的唯一形态。
• skill-session：重型 skill 子事务派独立 session（用户裁定：与 phase-session 正交、可嵌套——phase-session 里可以再派 skill-session）。
• Codex 侧：dispatch 时把 skill 指针埋 canary 注入 prompt，codex_trace_bridge 写 receipt（caller=真 thread UUID + canary_found + injected_skills）并扫 rollout 验真读；Codex worker 会话内的逐条 skill 读不可见（已知缺口，靠 canary 证 delivered + 检查 agent 证 effect 双轨）。

验收标准（无上下文 agent 可自判）

• task_id 真锚：grep <task_id> contexts/tool_receipts/receipts.jsonl 有该 run 的 receipt。
• 模式A 全链事件在台账：arm_directive 注入 receipt → phase_cursor_armed → 各 phase 的 phase_injection / skill 读 receipt（带 phase 标签）→ phase_block / phase_advance_drive → phase_plan_complete。
• 模式B：每条预设 skill 有 CC skill: receipt 或 Codex codex_dispatch receipt 的 canary_found=True。
• 阻断给的缺口可操作（哪条 skill、哪个 artifact、什么命令），不是 1-bit「未完成」。
• 普通 trivial session 零影响（无 cursor 无 marker 的 Stop 永远放行、零写入）。

已知陷阱（全部真实踩过）

• path-vs-name 误报：skill 声明用路径、receipt 是 bare name，比对前统一 Path(x).stem。
• Codex 不触发 CC hook：Codex 的 skill 使用只能靠 canary 证 delivered；forcing/驱动判据必须是「CC receipt 或 Codex canary」的 OR。
• rollout 异步写：dispatch 返回即扫 canary 会扫空，scan 带 wait/retry。
• regulator 必须主环境：任何第二 agent 验证不能在 Codex sandbox 内套娃（Operation not permitted）。
• 派发不返回卡死：每个派发设超时、单点失败不阻塞全局、不用 tmux 回传；dispatch.py 自身超时执行不严（W1/W2 两次超 deadline 不返回，需手动 kill，产物无损；待修）。
• mock 冒充 real：落地判定必须主环境独立重跑 + 真实派发验证，不信自报。
• 测试与 live 共享全局态：跑任何相关测试套件必须走已建隔离（PHASE_STATE_DIR / TOOL_RECEIPTS_LEDGER / CONTEXT_INFRA_ACTIVE_TASK_PATH / dedup dir 全进 tmp），否则污染生产台账与 task 锚（2026-06-09 三伤口实证，W1 根治）。
• phase_guardian 测试套件含真实 regulator 外呼（600s 级，慢 + 烧额度），跑前确认已 mock（test_guardian 已修一处）。

输出规格与可用资源

• 运行产物落任务的 adhoc_jobs 目录；trace 主台账 = contexts/tool_receipts/receipts.jsonl；phase 运行态 = contexts/runtime/phase_state/（gitignored）。
• 确定层工具（按名，路径查 tools/INDEX.md）：phase_state（cursor/cli/stop_phase_check/correction/trace/tags）、session_dispatch、phase_runtime（plan schema + spine + forcing_closure）、phase_guardian、skill_check_agent（读了≠生效 regulator）、codex_trace_bridge、unified_gate、per_task_trigger_diff。
• 配套道 skill：workflow_phase_framework（排计划）、workflow_manage_unexpected（遇阻）、workflow_solid_decision_review（判级）、workflow_unit_decomposition_and_context_injection（拆 unit/注入隔离）。

诚实 claim ceiling

模式A：机制 live 接线 + 全套件隔离测试绿 ×2 + 脚本级端到端（arm→block→advance→complete）跑通；真实无提示冷启动 E2E 见 adhoc_jobs/context_infra_base_tooling_buildout_20260615/phase_skill_trace_runtime_20260609/impl/e2e_probe_t652/（以该目录验证记录为准）。模式B：1 个真实端到端（T789，真实 Codex 派发）+ 6 件工具逐件独立核验。未做：多任务泛化、Stop-自驱 vs /goal vs 定时唤醒 vs 嵌套 phase-session 的对比实验（ORIGINAL_PROMPT 3d，下一步）、Codex 适配器任务级注入段（step 8）。