workflow_phase_framework
道-方法 · 道层 skill 全文
本页是 <code>rules/skills/drafts/workflow_phase_framework.md</code> 的逐字投影（仅隐私清洗，零改写）。
时点提示：本页是仓内文件 rules/skills/drafts/workflow_phase_framework.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。
报告元数据（frontmatter）
name: workflow_phase_framework
description: Loop/AAU 运行时的总领 phase 框架（道）。给一次任务运行定义 canonical phase 序列——信息锚定 → 用户需求分析(独立阶段) → 精准阅读 → 决定执行 phase → [非线性贯穿] → 真实条件验证——并强制每个 phase 带需求锚 + 机械可验证的充分性误差信号 + 独立调控者，而非"执行完即算完成"的空壳。用于设计或裁剪一次 Loop/AAU 运行的 phase 计划、判一份 phase 计划是否良构。
type: Workflow（道层 / 总领框架）
status: draft (Beta) — 晋级前需在 ≥1 次真实 Loop/AAU 运行里按本框架排过 phase 计划并过 phase_framework_gate，且证据到 bounded 以上
created: 2026-06-05
version: 0.3.1 (draft) — 0.3.0：final_report 收尾 phase 加「todo 注册回执」exit 谓词（DP-TODO-4 / Q22 / R9-21）+ 收口义务文本，配 `check_closeout_registration` gate（2026-07-06 W5-C / T1137-T1138）；0.3.1：final_report phase 补一条 campaign 级收口 opt-in 谓词 `gate_pass:closure_review_gate:<path>`（P9.2，TSM r6 D2 设计，向后兼容不改既有两条 gate）通用 Phase 框架（Loop/AAU 总领性）
一句话
一次任务运行不是"把活干完"，是依次穿过几个 phase，每个 phase 都是一个充分性控制回路：有一个从需求派生的锚、一个执行者自己算不出的机械误差信号判它"够没够"、一个执行者无法自我满足的停机谓词、一个独立调控者做语义判断。本框架定义 canonical phase 序列 + 每个 phase 的良构判据，是 Loop/AAU 运行时（术层 workflow_controller_loop / AAU Daemon）要执行的 phase 计划的设计准则。
何时用
- 启动一次 Loop / AAU 运行，要给任务排 phase 计划（哪些 phase、什么顺序、每个 phase 何时算过）。
- 判一份已有的 phase 计划 /
PHASES.md/task_phase_plan是否良构（用配套检测器phase_framework_gate）。 - 设计运行时转向（phase 转换条件、非线性回退）时，确认每个转换有锚、有误差信号。
非 trivial 任务运行前先按 _DAO_ROUTING 路由到本框架定 phase 计划；单步琐碎任务不必。
不做什么（边界）
- 不执行 phase：本框架是道层（怎么排、每个 phase 何时算过），不调度、不跑 Worker。执行调度归术层
workflow_controller_loop和 AAU Daemon。 - 不替代各 phase 的专项道 skill：每个 phase 内部"怎么做"由它路由到的道 skill 负责（见下表），本框架只管"序列 + 锚 + 误差信号 + 停机"。
- 不规定固定步骤：phase 序列是 canonical 默认，按需求裁剪（见 P-02 裁剪纪律）。框架约束的是结果（每个保留的 phase 必须良构），不是死序。
核心原理：每个 phase 是一个充分性控制回路（理论母体 P-04）
完整原理见 contexts/survey_sessions/requirement_anchored_context_sufficiency_architecture_20260531_manual.md（session bf292209 落盘）。框架据此立四条不可让渡的约束，正是它们把"phase 序列"从空骨架变成受控运行：
- 需求是锚，不是背景。需求把无穷的潜在工作
C_∞收束成一组有界、可逐条核验的覆盖义务（proof obligations）。每个 phase 服务于其中某几条义务，这组义务就是该 phase 充分性误差信号的来源。没有需求锚的 phase 无法判"够没够"。 - "够了"是机械误差信号，不是执行者的感觉。执行 agent 算不出"我做够了没"——那是与原任务同等代价、且从内部不可见的推断（"看到相关内容就以为够了"是已命名的失效模式 REF-002）。所以每个 phase 的 exit 判据必须是 harness 可机械核验的信号：覆盖义务核验（每条义务有命中 / none-found / 缺口）、边际增益门（连续 N 轮覆盖率增量 < ε → 停机候选）、或等价的可枚举 verdict。
- 误差信号必须可操作（actionable）。粗粒度的"不够"（1-bit）救不了（实证 0.444 无改善）；必须给可定位的具体反例——哪条义务没覆盖、缺在哪——执行者才改得动（实证升到 0.82–0.94，假 DONE 3/3→1/3）。这条来自 P-05 决定性发现。
- 停机权不在执行 agent 手里。Done 谓词由独立调控者持有：
状态∈目标区 AND verdict=pass AND 独立或确定性核验已做 AND 残差已声明 AND 状态已落盘。unmet非空一律禁止 close，必须输出 repair/branch/continue/await_user/block 之一。语义判断（"这段够不够"）外包给独立 verifier，且只在窄问题 + 信息隔离（forbidden_read 含执行者的成功叙事 / 最终答案，防污染）+ 可枚举 verdict 上做；确定层（Daemon / 检测器）只维护 ledger、判边界、机械阻断非法 DONE，不做语义判断。投票退出核心——满额一致 ≠ 充分（不可验证主观判断的从众翻转率 89%）。
这四条是框架的承重墙。一份 phase 计划若每个 phase 只写"做 X"而无锚、无机械误差信号、靠执行者自报完成，它过不了 phase_framework_gate，因为那正是"空骨架过形式闸门"的失效本身。
Canonical phase 序列
默认序列与每个 phase 的锚、路由道 skill、充分性 exit 判据。phase 名用用户原始命名。
| # | Phase | 锚（必须达到什么） | 路由道 skill（怎么做） | 充分性 exit 判据（机械误差信号） |
|---|---|---|---|---|
| 1 | 信息锚定 | 把开放域收束成有界搜索：枚举 in-scope 信息源 + 由需求首过生成搜索锚点（正向需求 / 反向风险 / 设计机制 / 边界四类） | workflow_recall_first_locate（召回纪律）→ workflow_long_context_scale_up（大输入分片 + 覆盖证明） | 召回覆盖证明：每个搜索锚点有命中或 none-found 记录；NO_KEYWORD 兜底跑过；先证"没漏"再进下一 phase |
| 2 | 用户需求分析（独立阶段） | 产出完整覆盖义务集：hard / negative / success_effect / deliverable + proof obligations；独立成 phase，绝不折进执行 | workflow_requirement_decomposition_core（拆解）+ workflow_requirement_analysis_quality（消息覆盖 MC1-4 + 质量 Q1-4，配 requirement_analysis_gate） | 消息覆盖核验：所有用户消息 raw turn 都对账、无塌缩、无 recency/重要性偏置；过 requirement_analysis_gate |
| 3 | 精准阅读 | 按第 2 phase 的覆盖义务深读已定位信息，逐条义务标 satisfied/partial/unmet/blocked/deferred | workflow_precise_reading（以义务为单位读 + gap_state 五分类 + 证据锚；大输入路由 workflow_long_context_scale_up） | 覆盖义务逐条有 gap_state；独立 verifier（RP-C 型，forbidden_read 含执行者答案）核每条 hard 义务有命中或 none-found；配 precise_reading_gate |
| 4 | 决定执行 phase | 据需求 + 已读信息定第一真实切片 + 方法路径 + 验证计划 | workflow_what_to_how_execution_bridge（What→How + 第一切片）+ workflow_solid_decision_review（证据强度 → claim ceiling → 允许的下一步） | 第一切片是真实可跑非占位；执行决策有证据强度标注；联动/取舍判断走 solid_decision 门 |
| — | [非线性]（贯穿，非独立 phase） | 见下方 P-03 非线性纪律 | workflow_manage_unexpected（遇阻动作阶梯）+ workflow_unit_decomposition_and_context_injection（重排时的分解 + context 隔离） | 每次非线性转向仍锚回原需求；block 可证伪（已试动作阶梯有据） |
| 5 | 真实条件验证 | 在真实入口、真实条件上验证产物对原需求产生 effect | workflow_real_task_test_case_design（真实入口 + read isolation + oracle + negative/mutation guard）+ workflow_solid_decision_review（最终判级） | 独立或确定性核验已做（非执行者自报）；effect 锚回原需求；残差 + claim ceiling 声明；三态收口 complete/bounded_incomplete/blocked |
序列与术层对齐：workflow_controller_loop 的 Controller Lifecycle gate（information_search / requirement_analysis / task_execution / environment_test / continuous_optimization / final_report）是更粗的控制门，本框架的 6 phase 落进它的 task_phase_plan（每个 phase 写清 control_gate / owns_req_ids / exit_criteria / evidence_required / status）。框架不取代 controller_loop schema，是给它的 phase 设计加锚 + 误差信号约束。
跨 closure 联动综合（在「真实条件验证」之后）：一次运行产出多个 closure 的真实运行证据、要判断哪些能联动成系统时，路由 workflow_solid_decision_phase（本序列「真实条件验证」之后的综合落点：每条联动判断带证据强度标注 + 锚机械误差信号非投票 + 疑问→补料闭环）。它对每条联动判断调用 workflow_solid_decision_review 定级，不重写五级表。
Final Report 收尾 phase（产出报告的任务）：任务若产出交付报告，在「真实条件验证」之后追加一个 final_report 收尾 phase，exit 用 gate_pass:check_report_completeness:<报告路径>——它自动跑 RC1-5（含 RC5 before/after 架构图检查），报告不过这套内容 + 可视化检查就不让 workflow 收口，gate 失败时把可定位反例（缺 before 侧 / delta 没标注等）写进 gap。该 phase 路由报告写作 skill（workflow_report_writing_matrix → 道 workflow_change_visualization × 术 bestpractice_markdown_report）。gate_pass:<gate_id>:<arg> 是 exit_criteria 的第三种谓词（除 artifact_exists / artifact_contains），只跑注册过的 gate（真源 tools/phase_runtime/gate_registry.py，白名单非任意命令）。按 P-02 裁剪：不产出报告的任务省略此 phase 并记一句理由。
收口义务（DP-TODO-4 / Q22 / R9-21，本 phase 的语义层义务，由下面的注册回执 gate 机械兜底）：收口 = 报告 + 按域注册残差 + 报告附 T-id 清单。新需求走 todo intake --program <slug>（四件套脊柱），已冻结需求的执行残差走 todo add --req-id <REQ-XX-NN> 回链；报告末尾必须附本 run 触发/收尾的 T-id 清单，让「注册了什么」可被机械对账（grep 一把审计）。这条义务的现实背景：07-04~05 整轮 campaign 新线程零自主注册，全靠用户追问——注册是纯语义层义务时 agent 稳定滑过（确定层有完成信号、语义层没有，DP-TODO-4 根因），所以必须配一个机械 exit 谓词兜底。
注册回执 exit 谓词（T1137 中央 wiring）：final_report phase 的 exit_criteria 除 check_report_completeness 外，加 gate_pass:check_closeout_registration:<报告路径>——它跑 tools/rr4_capture/closeout_predicate.py，机械判定收口证据：PASS 当且仅当报告含 RESIDUALS: none 显式声明（零残差逃生口），或含 UNPROCESSABLE: ... reason=<为何真不可处理>（真不可处理逃生口），或 contexts/todo/logs/todo_events.jsonl 存在本 session_id 的 todo_added 注册事件（session_id 取自 $CLAUDE_SESSION_ID 或报告里的 REGISTRATION_RECEIPT: todo=<T-id> 行）。逃生口必须有：否则门压力诱发编造注册（dark_context S1 门实验实证「门压力→编造，靠存在性守卫抓获」）。bare REGISTRATION_RECEIPT 行不再单独放行——必须有 events.jsonl 的事件回执背书，防自报造假。这一条把 SES-3 留下的中央 wiring 接通：任何走本框架的 session，其 final_report phase 的 exit_criteria 能机械要求注册回执，不再依赖 agent 自觉。消费侧抽查（防假注册）由审查 phase 对照「报告残差节 vs 注册 T-id 清单」一一对应（判断 Agent 构件族消费侧校验）。
Campaign 级收口 exit 谓词（P9.2 opt-in，TSM r6 D2 设计）：以上两条 gate 检查的是这一次 run 自己的报告；如果 final_report phase 收的是一次 campaign 的整体域关闭（即将产出 closure/CLOSURE_.md 这类带 doc_type: campaign_closure 或 CLOSED claim 的文档），可以再加一条 gate_pass:closure_review_gate:<收口或审查文档路径>——它跑 tools/closure_review_gate/check.py 的 close 组合 mode，机械核验该文档携带的 independent_review: 指针（审查者≠实现者 + 异构通道 + forbidden_read 成功叙事 + 差异表对账行）是否真实、完整。这条是 opt-in：写了才在这次 run 里生效；对存量的、不经过 phase 计划的手写收口习惯，普遍覆盖面由 tools/test_health/closure_review.py 的 closure_review.forced_close 记分牌探针承担（固定扫 adhoc_jobs//closure/*.md，与本 phase 是否被走过无关）。
序列内的耦合（诚实）：信息锚定（1）和需求分析（2）紧耦合——需求锚才能生成搜索锚点，但完整需求分析又要在初步信息上做。default 序列把需求首过放进 phase 1 生成锚点、完整分析独立成 phase 2，二者的回环由非线性承担（深一层需求分析锐化搜索锚点 → 回 phase 1 补采）。这不是矛盾，是受控迭代。
P-02 裁剪纪律：phase 按需求裁剪，但裁剪要有据
canonical 序列是默认不是义务。按需求裁剪：单一明确需求免"用户需求分析"phase；不要求验证的任务免"真实条件验证"phase；运行中可调整 phase。
硬约束：裁剪 = 显式记录理由，不是静默跳过。phase 计划里每个被省略的 canonical phase 要有一句"因 X 省略"（X 锚回需求特征，如"单一需求、无需独立分析"）。静默跳过和"裁剪有据"在确定层看不出区别，所以判据落在"省略处有无记录理由"。
P-03 非线性纪律（Phase 5 能力，贯穿而非独立 phase）
非线性是运行时能力，不是序列里的一格：
- 遇意外先解决再回主线：路由
workflow_manage_unexpected的动作阶梯（换路径 → 移资源 → 降级 → proposal/no-mutation → 仅全堵死才精确 block 且举证已试动作）。解决后回到中断处的需求锚。 - 遇难题系统性尝试多方法再决定下一步：不在第一条路撞死就 block；列候选路径、各试、据结果定下一步。
- 动态调整运行顺序：phase 可重排、回退、插入，但每次转向后当前 phase 仍要满足其良构判据（锚 + 误差信号不因转向而丢）。
非线性不豁免控制回路：转向后的 phase 同样要良构。"动态"约束的是顺序，不是"可以没有锚和误差信号"。
验收标准（一份 phase 计划是否良构）
配套检测器 phase_framework_gate（确定层壳 PF1-PF3 + regulator PF4，工具路径查 tools/INDEX.md）。一个无上下文 agent 拿这四条也能判一份 phase 计划过没过：
- PF1 需求锚（确定层）：phase 计划引用了需求锚（任务冻结的 What / proof obligations 来源），且每个 phase 声明它服务哪几条覆盖义务 / req。无锚 = FLAG。
- PF2 exit 判据非空壳（确定层）：每个保留的 phase 有
exit_criteria，且不是空、不是纯"done/完成/ok"、引用了证据或覆盖信号。空或纯"完成" = FLAG。 - PF3 裁剪有据（确定层）：每个被省略的 canonical phase 有一句锚回需求的省略理由。静默省略 = FLAG。
- PF4 exit 判据是真误差信号还是空壳（regulator，语义）：独立第二 agent（codex:high，forbidden_read 含执行者成功叙事）判每个 phase 的 exit 判据是不是机械可验证 + 可操作的充分性信号（覆盖义务核验 / 边际增益 / 独立核验），还是"执行了 X 即算完成"这种执行者能自我满足的清单项。FLAG 时给可定位反例（哪个 phase、为何空壳、怎样才算真信号）。
fail-safe：检测器任一项不可判（regulator 通道失败等）→ UNKNOWN → 当 FLAG 处理，不放行。
可用资源
- 路由的各 phase 道 skill：见 canonical 序列表，按名引用，skill 路径查
rules/skills/INDEX.md。 - 配套检测器：
phase_framework_gate，工具路径查tools/INDEX.md。 - 术层运行时：
workflow_controller_loop（Task Phase Plan schema + phase_decision + reviewer_sequence）、AAUDESIGN_FINAL_v3（Requirement Anchor / Context Gate / RP-C 四值 verdict / Final Boundary）。 - 理论母体：
requirement_anchored_context_sufficiency_architecture_20260531_manual.md。
诚实 claim ceiling / 缺口
- 证据等级 bounded：本框架是设计综合（基于 P-04 母体 + AAU DESIGN_FINAL_v3 + controller_loop 现有 phase 模型 + 已 landed 的各 phase 道 skill），未经真实 Loop/AAU 大规模 runtime 验证。晋级 production 需 ≥1 次真实运行按本框架排 phase 计划且过门。
- 精准阅读 phase 已建专项道 skill
workflow_precise_reading（drafts/Beta，配precise_reading_gate），本框架 Phase 3 缺口已补：它判覆盖义务满足、long_context_scale_up判原文读到，分工不重复。skill 本身仍 bounded（未经真实 Loop runtime 大规模验证）。 - surprise 探针（主动猎盲点替代投票消盲点）在 P-04 母体里是新提案、未实现，本框架列为可选误差信号、不强制。
- P-04（控制回路理论母体）原理已落盘但"未与 60 条 / 工作 session 对账"；本框架引用其原理，未重做对账。