Loop 工作流

术-运行时 · 术层 skill 全文

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

name: workflow-controller-loop
description: 当任务需要受控 Loop 工作流时使用：保留用户需求、按任务路由 Skill、用 task card 拆分工作、维护 Controller 生命周期 Phase / User Requirement Phase / Agent Unit Phase，基于证据验证、拆分文件产生检查和效果审查、跨 session 恢复，或协调 sub-agent 而不把所有内容塞进一个 prompt。适用于多步骤任务、先审查再设计、先调研再实现、长跑/可恢复任务，以及任何最终结论必须回连显式用户需求的任务。

Loop 工作流

这个 Skill 只定义 Controller 协议：保存用户需求、选择最小执行面、分派任务卡、记录事实、组织审查，并决定下一步反应。它不拥有 runtime executor、scheduler、聊天记录检索、长上下文分片、外部 post-loop audit 或具体领域 pipeline。

不要为简单任务、有界任务、可恢复任务或子任务创建多套 Loop 机制。执行面只改变落盘和协作强度，不改变 Controller 的职责。

职责边界

最短操作路径

每次触发时先做这些步骤：

1. 判断执行面：inline、task_loop 或 recoverable_overlay；非 inline 必须先确定 loop_home，所有 Loop 文件都写在这个专门目录内。
2. 为非 inline Loop 先写 provisional PHASES.md：至少登记 Loop-level Phase intake/source_collection，再开始需求取证。Phase registry 是 Loop 的控制属性，不等到需求分析完成后才出现。
3. 保存用户原文和后续需求增量。长 session、历史 session 或大材料先用 retrieval / long-context scale-up 收集 source manifest 和 coverage receipt。
4. 在信息收集足以说明任务本质后，再写 REQUIREMENTS.md，区分“做什么”和“怎么做”，并把需求拆成 task-execution Phases。
5. 做行动权限检查：区分当前信息足以支持 answer、dispatch、proposal、implementation、scheduler_change 还是 promotion。诊断信息充分不等于有权修改正式 Skill、改 automation 或宣布 promotion。
6. 对持续 / 可恢复 Loop，先完成 Bootstrap，但 Bootstrap 的成功条件包括持续工作入口：创建工作目录、控制文件、TASKS/T001...、task-local AGENT_RUNS/.../prompt.md、read_paths.txt、预期 result.md / receipt.yaml、next_prompt.codex.md、SCHEDULER_DECISION.md、恢复入口，并创建/验证 scheduler 或 verified fallback；若调度面暂不可用，必须在当前 turn 安排首个可执行 Unit 或写明没有任何允许继续动作。Bootstrap 不写 STOP.codex，也不能以“准备完成”替代持续工作启动。
7. Bootstrap 结束点是 Unit 入口，不是用户任务执行。Controller 在 Bootstrap 中不得直接完成用户任务的大规模分类、覆盖检查、测试设计、实现修补、正式 Skill/Protocol patch 或 closure 判断；若这些动作被需要，必须先进入 TASKS/Txxx.md 定义的 Unit，由受控任务 Agent / Review Agent 或显式单 Agent 例外完成。
8. 如果需要 runtime executor 或 scheduler，先选择相应 runtime/schedule skill；Controller 只写业务契约和证据边界。持续 / 可恢复 Loop 必须显式登记 scheduler 决策，默认每个 Loop Unit 之间用 20 分钟级 heartbeat，除非用户指定其他 cadence。
9. 如果需要隔离、sub-agent、测试或恢复，就写 TASKS/Txxx.md；每个 Loop Unit 最多同时承载 3 个方向、最多 5 个原子任务，并写清下一 Unit 的候选方向。任务卡必须声明 agent_roster，至少显式判断是否需要 controlled_task_agent 与 review_agent；不拆分时必须写 single_agent_exception、替代 review 面和风险接受理由。
10. 测试 case 数量不能在启动 prompt 或 Bootstrap 里过早固定；必须在 source coverage、requirement analysis 和 run strategy 后，通过 TEST_COVERAGE_PLAN.md 决定，并让测试 phase 的 task card 明确读取 workflow_real_task_test_case_design.md 与 drafts/workflow_solid_decision_review.md。
11. 结束前用证据检查每条适用需求，只声称证据支持的范围；非 inline Loop 收束前必须生成或更新 reports/FINAL_REPORT.html。

控制环

重复下面的控制环，直到 closure 或明确停止条件：

1. 框定：确定 loop_home，登记 Loop-level Phase，保存用户原文，定义当前 waypoint 和停止条件。持续 / 可恢复 Loop 的初始 waypoint 是 Bootstrap，状态应是 active_awaiting_first_wakeup 或等价 active 状态，而不是业务完成态。
2. 取证：如果需求来自多个 session、长材料或旧任务记录，先建立 source manifest、coverage artifact 和 residual ledger，再定义 requirements。大 context 必须显式接入 retrieval / long-context scale-up。
3. 路由：只选择当前任务需要的 Skill。每个任务卡优先 0 到 2 个 Skill。
4. 分派：只有在隔离、sub-agent、审查或恢复有收益时，才创建任务卡；一个 Unit 的任务方向不得超过 3 个，原子任务不得超过 5 个。
5. 执行：每个任务只产出一个下游会消费的产物。
6. 文件检查：先确认本轮承诺产生的文件、trace、runtime projection、review artifact 是否真实存在且可解析。
7. 效果审查：再由独立 reviewer 或主 agent 的独立审查视角对照需求、Phase 预期产物、证据和错误记录决定下一步反应。
8. 记录：只写必要的任务文件、round evolution record 和确定层事实。
9. 收束：只报告证据支撑的结论。若测试只完成 primary case，默认只能声明 primary_case_complete 或 stage_complete，不能声明 whole user task complete。

诚实汇报不是停止策略。发现问题、缺证据、产物不合格或测试不足时，Controller 首要职责是把问题转成可执行的 repair / continue / branch / test Unit，并继续推进用户需求；只有在没有任何允许的读取、修复、测试、proposal-only、adhoc/no-mutation 或调度动作时，才进入精确 await_user 或 block。对用户报告问题时必须同时说明已经执行的修复、下一步修复 dispatch，或为什么所有继续路径都被权限、外部系统、破坏性风险、凭据或用户明确停止要求阻断。

执行面

下面不是三种 Loop 类型，而是同一控制环的落盘和协作强度。

旧草案里的 direct_pass 只是 inline 执行面。旧草案里的 nested_loop 不是激活层级；只有当子目标有独立成功标准、证据和停止条件时，才创建子任务卡。该子任务若还需要独立恢复，再加 recoverable_overlay。

Loop Home 与文件位置

task_loop 和 recoverable_overlay 必须先声明 loop_home，所有控制文件、证据、agent run、report 和 trace 都放在这个目录下；不要把 Loop 文件散落到 repo root、全局 tmp/ 或多个无索引目录。

如果用户要求对一个新任务"使用 Loop"或"开启 Loop"，即使已有高度相似的 completed Loop，也必须创建新的 first-class loop_home。旧 Loop 只能作为 source unit 或 parent directory；除非用户明确说 resume / continue 该具体 Loop，不得复用旧 Loop 的 active control state。

选择规则：

• 已有项目/adhoc job 的后续 Loop：放到该项目目录下的独立子目录，例如 adhoc_jobs/<job>/<loop_slug>_<YYYYMMDD>/ 或既有 loop/。
• 新的 sustained Loop：优先放 adhoc_jobs/<topic>_<YYYYMMDD>/；创建新的 adhoc_jobs/ 顶层主题前，先按 rules/WORKSPACE.md 的 adhoc_jobs 创建前自检扫描既有目录。
• 冻结后的审查报告：面向用户的报告放 contexts/survey_sessions/；若审查本身需要持续 Loop，仍要有独立 loop_home 存放控制面。
• 测试 fixture 里的 nested .loop_trace/ 只能算 fixture 输出，不能替代一条 first-class Loop 的 loop_home。

CONTROL.md 顶部必须写出：

loop_home:
loop_class: controller_loop | validation_lane | fixture_loop | report_only
source_sessions: []

Chat History 检索 Loop 时，先找用户给出的 session id，再从该 session 的报告或 rollout 回到 loop_home；没有 session id 时，用 rg -n "loop_home:|source_sessions:|phase_registry:|Current next action" adhoc_jobs contexts/survey_sessions 定位候选。

Loop 文件夹入口图

每个新 Loop 的 CONTROL.md 或 README.md 必须写出本目录的 folder map，说明恢复 agent 应该如何消费 Loop 文件夹，而不是让执行者从历史对话猜读法。最小 folder map：

如果 Loop 目录有 START_PROMPT.md 或历史 Protocol 文件，Controller 必须写清它们只是启动 / 协议来源，后续运行主要依靠 PHASES.md、TASKS/、protocol_visibility、SCHEDULER_DECISION.md 和 next_prompt.codex.md 引导不同 Agent 读取对应内容；不能让普通执行 Agent 只靠启动 prompt 或目录名判断职责。Controller 不需要阅读所有 Protocol；若它为了路由读取了某个 Protocol，必须把该 Protocol 的操作性要求投影到对应消费 Agent 会读的 phase 文件、task card、test plan、review 或 next prompt。Protocol 只停留在 Controller 上下文、START_PROMPT.md 或报告里，按缺失指导处理。

Fresh process 恢复某个 Unit 时，repository startup handshake 是 Unit read contract 的一部分：先按 AGENTS.md 读取强制启动文件，再通过 rules/skills/INDEX.md 做本轮 Skill 路由。这个 handshake 和选中的 Skill effect 必须投影到 TASKS/Txxx.md、agent read_paths.txt、receipt.yaml、read-compliance review 和 next_prompt.codex.md；不能只存在于对话或 Controller 隐含记忆中。

Repository startup handshake 与被选中的 Skill / Protocol 路由读取默认属于 preflight_context，不是 task-local evidence。任务卡必须把它们和 evidence_context 分开记录。除非任务卡显式把某个 preflight source 提升为 promoted_preflight_evidence，执行 Agent 不能用它形成业务判断；但只要它被标为 mandatory preflight 且没有被用作 evidence，就不应被当作普通 forbidden read。若某个来源连 preflight 也禁止，任务卡必须写成 forbidden_even_as_preflight。

Folder map 的默认恢复顺序服从当前 Unit 的 state authority。若最新 next_prompt.codex.md 明确声明 CONTROL.md、PHASES.md、runtime projection（如 loop_state.codex.json、loop_runs.codex.jsonl）或 PROGRESS.md stale 并要求跳过，它在该 Unit 内覆盖上表的默认读取时机。任务卡、read paths、receipt、result 和 review 必须一致记录 stale sources 未读、forbidden reads 未触碰、以及该 Unit 的 scheduler 或 manual resume expectation。

持续 Loop、监控与报告

当用户要求持续推进、定时唤醒、heartbeat、20 分钟左右检查、跨 session 继续或最终 HTML report 时，默认选择 recoverable_overlay，并把它当作 sustained Loop 处理。

sustained Loop 的 wake-up 面不能留给后续执行 Agent 从历史实践推断。Controller 必须先做 Bootstrap，再进入业务 Unit。Bootstrap 建立运行环境：创建 loop_home、保存用户原文、写初始 CONTROL.md / PHASES.md / REQUIREMENTS.md / TASKS/T001... / task-local AGENT_RUNS/.../prompt.md / read_paths.txt / 预期 result.md 和 receipt.yaml / next_prompt.codex.md / SCHEDULER_DECISION.md / HANDOFF.md / loop_state.codex.json，并把状态设为 active_awaiting_first_wakeup 或等价 active 状态。Bootstrap 不写 STOP.codex，也不把 primary case、准备文件或一个 positive run 当作完成。

Bootstrap 只拥有初始化和 Unit 入口权限。它可以创建第一个 Unit 的任务卡、agent roster、bounded context package、read/forbidden path、输出/receipt contract 和 next prompt；它不能直接替代第一个 Unit 做分类、信息综合、实现覆盖检查、测试设计、修补正式文件或宣布用户任务完成。若 Controller 在 Bootstrap 中需要更多判断，它必须把判断写成当前 Unit 的受控任务 Agent 或 Review Agent contract。

Bootstrap 只有在持续工作入口可恢复时才算完成：

• App automation / heartbeat 已创建或更新，并有可检查的 scheduler receipt；或
• local cron / launchd / CI / codex exec fallback 已完成首次成功验证，或状态明确为 created_pending_first_success 且当前 turn 继续执行首个 Unit；或
• 外部权限、凭据、破坏性风险或工具面缺失使调度不可创建，同时 SCHEDULER_DECISION.md 写出 blocked authority、manual resume plan、当前 turn 可继续动作；或
• 没有任何允许的调度、fallback、manual resume 或 current-turn Unit，才能进入精确 block。

因此，active_awaiting_first_wakeup 不是“准备好了但无人会醒来”。它必须指向真实 scheduler / verified fallback / manual resume 入口，以及首个业务 Unit 的 task card 和 next prompt。

Controller 必须在第一个业务 Unit 之前写出 scheduler_skill: codex_schedule_loop、scheduler_cadence: heartbeat_20m 或明确的用户指定 cadence，并记录 scheduler 已创建 / 已更新 / 暂不可设置的原因；具体 automation、cron、resume 和观测写法由 codex_schedule_loop 决定。若无法设置 scheduler，仍写 SCHEDULER_DECISION.md 并把 status 标成 blocked 或 not_available，说明 blocked authority、resume plan、可继续的无调度隔离动作；不能静默改成 current-turn complete。

SCHEDULER_DECISION.md 至少包含：

schedule_required: true | false
status: created | updated | blocked | not_required | not_available
schedule_surface:
cadence:
schedule_created: true | false
receipt_path:
blocked_reason:
resume_plan:
first_wakeup_task:
why_safe_to_continue_without_scheduler:

sustained Loop 必须直接创建或维护这些控制面，而不是让后续执行 Agent 从历史实践里推断：

• CONTROL.md：当前 lane、round、wip limit、scheduler skill、20 分钟级默认 cadence、下一次唤醒 / resume pointer、停止条件。
• SCHEDULER_DECISION.md：调度是否必需、是否已创建；如果 blocked，则在同一文件写明凭什么可以无调度继续或停止。
• PHASES.md：Phase registry、当前 Phase、进入/退出条件、转向候选和审查判定。
• PROGRESS.md：每轮完成了什么、问题是什么、哪些需求状态变化。
• HANDOFF.md / next_prompt.codex.md：下一次唤醒从哪些磁盘事实恢复。
• SOURCE_MANIFEST.* / REQUIREMENT_EVIDENCE.md：长 session、历史 session 或大材料的原文来源、coverage receipt、未覆盖项和需求证据链。
• .loop_trace/：规范事实日志和 runtime projection 的来源。
• AGENT_RUNS/ 或 runs/agents/：每个隔离 agent 调用的 prompt、输入清单、输出、stderr/log、review receipt。
• evidence/debug/：运行时、调度、测试、环境和判断问题。
• evidence/reviews/round_<N>_review.md：round review，内含 file-production、effect-review、next-step-plan section；复杂或独立 reviewer 场景可拆成多个 review 文件。
• reports/FINAL_REPORT.html：非 inline Loop 的默认最终交付物，从第一轮就建立 living target；用户没要求 HTML 时也至少在收束前生成本地 HTML。

next_prompt.codex.md 不是状态摘要。只要 Loop 不是 completed / valid STOP，它必须投影下一次恢复要执行的 Phase-bound Unit contract，让恢复 agent 不需要从旧对话或 Controller 长文里猜 Agent Unit Phase：

sustained_loop_invariant:
  restore_state_first: true
  execute_one_bounded_business_unit_or_diagnose_block: true
  review_before_phase_advance_or_stop: true
  write_next_prompt_before_yield: true
repository_startup_handshake:
  required: true
  startup_instruction_source: AGENTS.md
  mandatory_startup_files:
    - rules/SOUL.md
    - rules/USER.md
    - rules/WORKSPACE.md
    - rules/COMMUNICATION.md
    - rules/git_safety.md
    - rules/skills/INDEX.md
  skill_routing_source: rules/skills/INDEX.md
  selected_skill_paths: []
  preflight_use: non_evidentiary_by_default
  evidentiary_promotion_required: true
  forbidden_even_as_preflight: []
  must_be_projected_to:
    - task_card
    - agent_read_paths
    - agent_receipt
    - read_compliance_review
state_authority:
  authoritative_source: latest_next_prompt | CONTROL.md | PHASES.md | runtime_projection
  stale_sources: []
  stale_sources_must_not_be_read: false
  override_reason:
  receipt_output_agreement_required: true
skill_routing_trace:
  index_read_required: true
  selected_skills:
    - skill_path:
      use_mode:
      expected_effect:
      authority_boundary:
  must_appear_in:
    - task_card
    - receipt
    - result_or_decision_packet
phase_bound_next_unit:
  current_phase_only: true
  hide_future_phase_details: true
  stop_after_expected_writes: true
  must_not_start_next_phase: true
  task_phase_plan_id:
  controller_phase_id:
  user_requirement_phase_id:
  agent_unit_phase_id:
  task_card_path:
  decision_packet_path:
  next_unit_goal:
  why_this_unit_fits_controller_phase:
  why_this_unit_fits_user_requirement_phase:
  phase_context_brief:
    phase_goal:
    current_progress:
    relevant_user_requirement_excerpt:
    accepted_background_facts: []
    non_goals: []
    claim_ceiling:
  bounded_context_package:
    context_budget: phase_summary_plus_task_relevant_background
    include_full_user_prompt: false
    include_full_phase_plan: false
    required_background_items:
      - item_id:
        path_or_source:
        why_needed_for_this_unit:
        how_to_read:
        must_be_used_in: []
  unit_scope:
    directions: []      # 1-3 only
    atomic_tasks: []    # target 3-5; fewer allowed for review/gate; more must be deferred
    deferred_directions: []
    deferred_atomic_tasks: []
    task_volume_policy:
      target_atomic_tasks: "3-5"
      avoid_too_small: true
      if_more_than_five: defer_or_split
      if_less_than_three: justify_gate_or_review_scope
  agent_unit_phase_plan:
    - phase_id: restore_contract
      must_read: []
      must_output: []
    - phase_id: collect_or_execute
      must_read: []
      must_output: []
    - phase_id: produce_artifact
      must_output: []
    - phase_id: self_check
      must_check: []
    - phase_id: handoff_review
      must_write: []
  reviewer_sequence:
    - read_compliance_reviewer
    - artifact_reviewer
    - execution_effectiveness_reviewer
    - solid_decision_reviewer
    - next_step_planner
  required_read_paths: []
  role_roster:
    - agent_id:
      role: controlled_task_agent | review_agent | verifier | controller
      objective:
      prompt_path:
      read_paths_path:
      output_path:
      receipt_path:
      may_read: []
      forbidden_read: []
      must_output: []
      decision_authority:
  single_agent_exception:
    allowed: false
    reason:
    review_substitute:
    risk_acceptance:
  required_information_use:
    - item_id:
      source:
      must_be_read: true
      must_be_cited_or_used_in: []
      verification_method: read_receipt_and_output_trace
      output_trace_required: true
      receipt_field:
  receipt_output_agreement:
    forbidden_reads_match_role_contract: true
    stale_state_handling_matches_state_authority: true
    required_information_use_traced_in_outputs: true
    scheduler_or_manual_resume_matches_scheduler_expectation: true
    consumer_protocol_receipt_gate_status_recorded: true
  consumer_protocol_receipt_gate:
    required: true
    evidence_inputs:
      task_card_path:
      phases_path:
      agent_read_paths_path:
      agent_receipt_path:
      read_compliance_review_path:
    fail_reaction: repair_read_contract_or_rerun_unit
  forbidden_read_paths: []
  expected_write_paths: []
  scheduler_expectation:
    schedule_surface:
    schedule_status:
    receipt_path:
    next_wakeup_or_manual_resume:
  forbidden_shortcuts:
    - status_only_next_prompt
    - phase_advance_without_effect_review
    - scheduler_stop_without_closure_or_block
    - closure_without_decision_packet_when_required
    - future_phase_execution_details
    - next_next_task_instructions

如果下一步需要执行、修复、测试、审查或继续调度，但 next_prompt.codex.md 没有 phase_bound_next_unit、没有 agent_unit_phase_id、没有 task card / required read paths，文件产生检查必须判 partial 或 fail。Controller 不能只写“考虑下一 phase”；必须写清这是在当前 Controller Lifecycle Phase 和 User Requirement Phase 下运行的哪个 Agent Unit Phase。

next_prompt.codex.md 只能暴露当前 Unit 所需知识。它可以列出 deferred direction 的名称，不能写出下一 Phase 的执行步骤、case 细节、oracle、patch 步骤或 scheduler 操作。若当前 Unit 完成后仍需下一 Phase，由 Review / Next-Step Planner 写下一份 prompt；当前执行 Unit 不应同时知道并执行下一个 Phase。

Next-Step Planner 不能只写“下一 Unit 要做什么”。它必须生成一个 bounded context package：给出当前 Phase 的宏观目标、当前进度、与本 Unit 相关的用户需求摘录、已接受背景事实、非目标和 claim ceiling；再列出本 Unit 必须使用的信息项、读取方式和必须出现在产物中的使用痕迹。这样避免 context 太少导致偏航，也避免把完整需求和未来 Phase 泄漏给执行 Unit。

Next-Step Planner 还必须检查 protocol_projection：本轮依赖的 Protocol / Draft skill 是否已经出现在下一 Unit 实际会读的文件中。若 Controller 读过某个 Protocol，但对应执行者、测试设计者、reviewer 或 scheduler 只收到摘要或完全收不到操作性要求，下一步反应必须是 repair_read_contract 或 repair_next_prompt，不能 advance。

3-5 个原子任务是推荐工作量与默认上限，不是要求每次机械拆到 3 个。Review / gate 类 Unit 可以少于 3 个，但必须说明 scope；超过 5 个时必须拆分或 deferred，不能让执行 Unit 自行扩张。Next Prompt 应提供 Phase 概况和任务相关背景，而不是只提供 3-5 条孤立动作。

后续 Unit 必须证明自己使用了 required information。Read-Compliance Reviewer 只检查是否读到；Information-Use Reviewer 或 Effectiveness Reviewer 必须检查这些信息是否被引用、用于决策、用于产物字段或进入 residual。若 required_information_use 中任何必用信息没有使用痕迹，相关 Phase advance、closure、promotion 或 broad claim 必须判 repair 或 rerun。

持续 Loop 每轮都要记录「修改了什么、为什么改、遇到什么问题、如何处理、还有什么未验证」。最终 HTML report 必须综合这些记录、Phase/转向历史、测试方法和证据边界；不允许只输出 Markdown 或对话总结。报告内容与可读性可调用 bestpractice_final_report，但 Controller 持有“必须生成 report”的交付约束。

非 Loop 但与 Loop 相邻的 Skill 只按职责触发：Scheduler 只设置唤醒面，runtime executor 只负责 agent 调用和 durable runtime evidence，history retrieval 只找历史记录，review skill 只做冻结任务或 reviewer 的外部审查。Controller 负责把这些结果接入当前 round 的需求、证据和下一步反应。

信息收集与 Requirement 定义

当任务来自多个 session、长聊天记录、历史 Loop、已有报告或大目录时，不能先凭摘要定义任务再补证据。Controller 必须先建立 intake lane：

1. USER_PROMPTS/ 保存当前用户原文和每次后续需求增量；如果原文在历史 session，保存 raw path、session id、line anchor 或稳定摘录。
2. SOURCE_MANIFEST.* 枚举所有被要求检查的原始来源、token 估算、是否已读、谁读、输出路径和 coverage receipt。
3. 对超过单 agent 稳定 context 的材料，先用 bestpractice_chat_history_retrieval 定位 raw source，再用 workflow_long_context_scale_up 做分片覆盖、null baseline、no-finding receipt 和 residual ledger。
4. REQUIREMENT_EVIDENCE.md 把原文要求映射到证据来源，明确哪些是用户直接要求、哪些是 assistant 推断、哪些仍缺原文支持。
5. 信息足以说明任务本质后再写 REQUIREMENTS.md。REQUIREMENTS.md 只写“做什么”和验收边界；“怎么做”放 CONTROL.md、TASKS/ 或 TESTS.md。

如果 intake 没有覆盖某个来源，不能把该来源对应要求标成 covered。可以继续执行已覆盖的隔离任务，但必须把缺失来源写入 residual ledger 和 next action。

信息收集必须标注等级，避免把“找到可能在哪里”误报成“已经理解内容”：

Level 1 本质是 search task。Level 1 Unit 的输出应是 locator manifest 或 source universe，不是 implementation requirement。只有 Level 2/3 之后，Controller 才能结合用户需求给出实现要求并安排 Task Phase。

Phase 1 / information_search 必须增加 context_coverage 属性。这个属性衡量“可能相关 context 的位置是否足够覆盖”，不衡量内容理解是否正确：

context_coverage:
  objective: possibility_coverage_first
  context_budget_strategy: locate_before_read
  source_families_expected: []
  source_families_searched: []
  query_patterns_used: []
  candidate_paths: []
  no_hit_receipts: []
  residual_source_families: []
  false_positive_tolerance: high
  false_negative_tolerance: low
  clean_review_context_path:
  coverage_risk: low | medium | high

context_coverage 的默认策略是宁可多保留候选位置，也不要过早排除可能相关 source。Locator Unit 只产出路径、source family、命中/未命中 receipt、搜索策略和 residual，不读取正文，不裁剪候选为“最终足够”。这保留 clean context，避免把大材料塞进执行 Unit。

从一个信息收集等级进入下一等级前，必须经过 Solid Decision sufficiency gate：

solid_decision_sufficiency_gate:
  gate_scope: source_locator | source_reading | requirement_mapping
  input_artifacts:
    - SOURCE_MANIFEST.*
    - locator_manifest
    - no_hit_receipts
    - residual_ledger
    - context_coverage
  allowed_decisions:
    - continue_search
    - begin_source_reading
    - begin_requirement_mapping
    - block_or_await_user
  weakest_evidence_class:
  missing_source_families: []
  forbidden_phase_advance_if_missing: true
  reviewer_must_consume: drafts/workflow_solid_decision_review.md

这个 gate 只判断“是否允许进入下一信息等级 / Phase”，不判断用户任务完成。若 missing_source_families 仍包含高诊断价值来源，下一步必须是 continue_search 或明确 residual，不能开始需求整理。

复杂需求进入 task card 前必须先做需求归组：

requirement_grouping:
  grouping_basis: same_kind | broad_cross_cutting | dependency_chain | test_lane | external_resource
  grouped_req_ids: []          # 同类组可多个
  broad_req_ids: []            # 覆盖面广的需求必须单独成为 singleton
  max_req_ids_per_subagent: 2  # 同类需求默认每个 sub-agent 最多处理两个需求点
  singleton_agent_required: true | false
  assignment_reason:
  deferred_req_ids: []

同类需求下，一个 sub-agent 默认最多检查两个需求点；超过两个时拆多个 task card 或 agent run。覆盖点广、影响 Controller 设计、Phase 策略、read policy、scheduler、promotion gate 或跨模板字段的需求必须单独指派 singleton reviewer。分组完成后仍要做 merge review：确认每个用户需求 id 有 owner、输出路径、claim ceiling 和 residual 状态。

信息收集可以由多个 Unit 共同完成；它不要求在启动时已经完成最终用户需求拆解，但必须先有可审查的临时取证边界。进入多 Unit 信息收集前，Controller 必须写 INFORMATION_COLLECTION_PLAN.md，或在 SOURCE_MANIFEST.* 中保留等价 section：

provisional_task_contract:
  original_prompt_refs: []
  current_unknowns: []
  forbidden_early_assumptions: []
decision_value_frontier:
  - frontier_id:
    requirement_anchor:
    candidate_problem_frame:
    evidence_that_would_change_next_action:
    source_family:
    diagnosticity: high | medium | low
    stop_or_shift_trigger:
collection_units:
  - unit_id:
    controller_phase_id:
    provisional_user_requirement_phase_id:
    agent_unit_phase_id:
    directions: []      # 1-3 only
    atomic_tasks: []    # 1-5 only
    required_read_paths: []
    forbidden_read_paths: []
    expected_outputs: []
coverage_merge:
  merge_reviewer:
  evidence_to_requirement_mapping_path: REQUIREMENT_EVIDENCE.md
  residual_ledger_path:
  no_hit_receipts: []

每个 collection Unit 只能回答它被分派的来源族、问题框架或证据 frontier，不能独立宣布需求拆解完成。多个 Unit 的输出必须先经过 merge review：把原文锚点、coverage receipt、no-hit / negative pool、residual ledger 和可能改变任务解释的证据汇入 REQUIREMENT_EVIDENCE.md。只有 merge review 证明“当前证据足以说明任务本质”后，Controller 才能把临时取证边界提升为 REQUIREMENTS.md 和正式 User Requirement Phase。

没有最终需求拆解时，信息收集的依据不是完整 requirement list，而是 provisional_task_contract、用户原始 prompt、已知任务对象、candidate problem frame、decision-value frontier 和 source universe。收集到的信息必须用覆盖证据保证来源准确和覆盖面：每条重要结论指向原始 source、reader、chunk / line anchor、coverage receipt；没有命中的合理来源要写 no-hit receipt；仍未覆盖的来源族写入 residual ledger，不能被摘要或模型判断隐式替代。

Context 授权与全量审查上下文

执行 Unit 和 Review Unit 的 context 权限不同：

• 执行 Unit 只读取上一份 next_prompt.codex.md、自己的 TASKS/Txxx.md、phase-local 文件、明确摘出的用户需求片段和 required read paths。它不能读取完整用户需求、完整 Phase 设计、hidden oracle、全量 source manifest 或下一 Phase 的任务细节，除非 task card 明确授权。
• Review Agent / Next-Step Planner 才能读取完整 Phase 要求、完整用户需求、REQUIREMENT_EVIDENCE.md、SOURCE_MANIFEST.*、residual ledger、必要的 Protocol / Solid Decision Skill 和执行 Unit 的 receipt。它用全量 context 判断当前 Unit 是否足够、是否转 Phase、是否继续找遗漏。

每张任务卡必须显式写：

context_grant:
  execution_context:
    allowed_sources: []
    user_requirement_excerpt_path:
    previous_next_prompt_path:
    phase_context_brief_path:
    bounded_context_package_path:
    full_user_prompt_allowed: false
    full_phase_plan_allowed: false
    future_phase_details_allowed: false
  review_context:
    full_user_prompt_allowed: true
    full_phase_plan_allowed: true
    source_manifest_allowed: true
    residual_ledger_allowed: true
    solid_decision_skill_allowed: true

Review Agent 生成下一份 prompt 时，应把完整上下文蒸馏成 bounded context package，而不是把完整上下文原样传给执行 Unit。这个 package 必须足以让下一个 Unit 理解“当前 Phase 中为什么做这 3-5 个建议原子任务”，但不能暴露下一 Phase 的执行计划。

初始阶段不要过早融合 User Requirement Phase。Bootstrap 和最初的 locator Unit 属于 Loop-native Phase：controller_phase_id=information_search，user_requirement_phase_id=provisional_unknown 或等价占位，agent_unit_phase_id=restore_contract/collect_locator/produce_locator/self_check/handoff_review。只有 Solid Decision sufficiency gate 允许进入需求映射后，才把用户需求 Phase 融入 Task Phase Plan。

Phase 注册与转向

非 inline Loop 必须维护 Phase registry。Phase 有三个模块，三者都由 Controller 登记，但具体执行交给对应 Worker 或 Unit：

• Controller Lifecycle Phase：Controller 自身的生命周期位置，兼容旧字段 loop_level_phase_id。默认目录是 information_search、requirement_analysis、task_execution、environment_test、continuous_optimization、final_report。Controller 在这层只调度，不亲自完成大规模抽取、实现或测试。
• User Requirement Phase：用户任务内部的动态编排，兼容旧字段 task_phase_id。它把用户 prompt 中的先后顺序、Worker 分配、Test 目标、Phase 转换条件和预期产物插入 Controller 生命周期。
• Agent Unit Phase：单个 Worker / sub-agent / reviewer 的本地执行阶段，例如 restore_contract、collect_or_execute、produce_artifact、self_check、handoff_review。它必须落到 AGENT_RUNS/ 的 task-local package。

执行时应把前两层投影成一个用户可读的任务级 Phase 计划，而不是让恢复 agent 在两个并列轴之间猜测。推荐概念模型是两层：

• Task Phase Plan：融合 Controller Lifecycle gate 和 User Requirement Phase。它描述整个用户任务从取证、需求建模、执行、测试、优化到收束的贯穿式安排。controller_phase_id 在这里是控制门或生命周期 gate；user_requirement_phase_id 是任务特异工作阶段。兼容字段继续保留，但 PHASES.md 应提供 task_phase_plan 或等价视图，让每个任务级 Phase 同时写清 control_gate、owns_req_ids、预期产物、退出条件和状态。
• Agent Unit Phase Plan：每个原子 Unit 内部的局部执行阶段。它只约束这个 Unit 如何恢复契约、读材料、产出、self-check、交给 reviewer，不替代任务级 Phase。

最小 task_phase_plan 视图：

task_phase_plan:
  - task_phase_plan_id:
    control_gate: information_search | requirement_analysis | task_execution | test_coverage_planning | environment_test | continuous_optimization | final_report
    user_requirement_phase_id:
    purpose:
    owns_req_ids: []
    entry_criteria: []
    exit_criteria: []
    evidence_required: []
    expected_outputs: []
    consumed_instruction_files:
      - path:
        section:
        consumed_by_role:
        reason:
    phase_local_rules: []
    status: pending | active | ready_for_review | passed | repair_needed | blocked | skipped

新 Loop 应优先让 next_prompt.codex.md、task card 和 decision packet 绑定到 task_phase_plan_id，同时保留 controller_phase_id / user_requirement_phase_id 以兼容旧产物。旧 Loop 中 task_phase_id 仍视为 user_requirement_phase_id 的 legacy alias，不要求历史重写；但后续恢复 prompt 必须把下一 Unit 投影到任务级 Phase 和 Agent Unit Phase。

不要把 Phase 特定指导只写在 START_PROMPT.md。启动 prompt 只是 Bootstrap 入口；它会很快从执行者上下文中消失。创建 PHASES.md 时使用 templates/PHASES.md 的结构。所有会影响某个 Phase 行为的规则，必须投影到该 Phase 后续 Unit 实际读取的文件：

文件产生检查要确认这些阶段指导已经落入对应消费文件；如果某条阶段规则只存在于 START_PROMPT.md 或 controller 长文，下一 Unit 无法从自己的 read set 看到它，判为 partial，并调度 repair Unit 把规则投影到正确文件。

即使用户没有显式说“分阶段”或“转向”，也至少注册 Controller Lifecycle Phase；只要任务存在多方向、多验收口径、先后依赖或可能从测试转实现/从实现转审查，就要注册 User Requirement Phase；只要派出隔离 agent，就要记录 Agent Unit Phase。

Controller Lifecycle 默认 Phase 的职责和预期产物：

最小格式：

phase_registry:
  - phase_id: P001
    phase_kind: controller_lifecycle | user_requirement | agent_unit
    compatibility_aliases: []
    purpose:
    owns_req_ids: []
    entry_criteria: []
    exit_criteria: []
    evidence_required: []
    expected_outputs:
      - path:
        content_must_show:
        checked_by:
    status: pending | active | ready_for_review | passed | repair_needed | blocked | skipped
    turn_options:
      on_pass:
      on_partial:
      on_fail:
      on_block:
current_controller_phase_id:
current_user_requirement_phase_id:
current_agent_unit_phase_id:

每个 Phase 下的 Loop Unit 必须写：

unit_scope:
  unit_id:
  task_phase_plan_id:
  controller_phase_id:          # old alias: loop_level_phase_id
  user_requirement_phase_id:    # old alias: task_phase_id
  agent_unit_phase_id:
  directions: []   # 1-3 only
  atomic_tasks: []  # 1-5 only
  why_these_directions:
  deferred_directions: []
  deferred_atomic_tasks: []
  next_unit_candidates: []

不要让单个 Unit 同时处理超过 3 个方向或 5 个原子任务。超过上限时，先由 Controller 定性排序：当前 Unit 做最能改变下一步决策的 1-3 个方向和 1-5 个原子任务，其余写入 deferred directions / deferred atomic tasks。Unit 内部可以并行派生 sub-agent，但每个 sub-agent 仍要有自己的 agent_unit_phase_id、prompt、read path、result、log 和 receipt。

效果审查必须给出 Phase decision：

phase_decision: stay | advance | repair | branch | await_user | close
controller_phase_decision: stay | advance | repair | branch | await_user | close
user_requirement_phase_decision: stay | advance | repair | branch | await_user | close
current_controller_phase_id:
current_user_requirement_phase_id:
current_agent_unit_phase_id:
next_phase_id:
turn_reason:
missing_evidence_to_advance: []
final_report_update_required: true | false

转向规则：

• advance 只能在当前 Phase 的 exit_criteria 和 evidence_required 被证据满足时发生。
• repair 用于当前证据显示方向对但证据不足，例如 task_quality_delta: INDETERMINATE 应转入构建 shared task-quality lane，而不是 close。
• branch 用于用户需求允许多方向并行或互斥候选都仍开放；必须写清选择理由和未选方向的保留/丢弃原因。
• await_user 必须有精确 waiting_scope 和 resume_conditions；不能因为 formal promotion 受阻就停止允许的 adhoc/no-mutation/testing Phase。
• close 前必须完成 closure review，并确认 reports/FINAL_REPORT.html 已生成或更新。
• claim boundary 只限制能说什么，不决定下一阶段做什么；unsupported claim 或 residual 必须进入 next_allowed、repair Phase 或明确的用户等待边界。

Unit 与审查 Agent 拆分

一个 Loop Unit 最多执行或检查 3 个方向、5 个原子任务。方向可以是并行的，但必须有共同的 Phase 目标和统一的下一步决策点。典型方向包括 source coverage、requirement interpretation、implementation gap、test validity、phase transition、report completeness。原子任务是 Unit 内可独立完成和核验的小动作，例如读一个 source chunk、补一个 schema 字段、检查一个测试 fixture、修一个状态不一致点。

每个 Unit 必须显式声明 agent roster。默认至少判断两个角色：controlled_task_agent 负责当前 Unit 的具体执行或窄范围分析，review_agent 负责读取当前 Unit 的任务契约、执行产物、receipt 和必要证据，判断 read/context compliance、artifact/effect、claim ceiling、repair/continue/advance 反应，并给出下一 Unit 的 next_prompt.codex.md 输入。若某个 Unit 不拆出独立任务 Agent 或 Review Agent，必须写 single_agent_exception，说明为什么单 Agent 足够、用什么 review substitute、接受什么风险，以及这个例外不能用于 closure、promotion、scheduler stop 或 broad claim。

广义 side agent、顾问型并行分析或 Controller 自己综合结果，不等同于 Unit 内 agent 编排。只有当 agent 被绑定到当前 TASKS/Txxx.md、有明确 role、bounded read paths、forbidden reads、输出路径、receipt、review sequence 和下游消费者时，才算作当前 Unit 的任务 Agent / Review Agent。

审查默认按时序拆成五个 reviewer 职能。可以由多个 sub-agent 分别执行，也可以由主 agent 在隔离 factpack 上按独立小节执行；不能把它们混成一段进展总结。

1. Read-Compliance Reviewer：核验当前 Unit 是否读取了 task / phase 要求的文件、是否避开 forbidden paths、是否有 read_paths.txt 和 receipt.yaml。
2. Artifact Reviewer：核验当前 Phase 预设产物是否生成、非空、可解析，并检查内容是否覆盖用户初始需求对应片段。
3. Information-Use Reviewer：核验 required_information_use 中每个信息项是否被读取并实际用于输出、判断或 residual；只读不使用不能通过。
4. Execution Effectiveness Reviewer：判断当前 Step / Unit 是否对原始需求产生有效变化，区分 requirement_effect_changed、artifact_only、useful_reasoning_only 和 not_measured。
5. Solid Decision Reviewer：调用 drafts/workflow_solid_decision_review.md，基于 read-compliance、artifact review、information-use review、effect review 和 evidence paths 给出 weakest evidence class、claim ceiling 和允许的下一步反应。
6. Next-Step Planner：基于前五项质量判断决定下一步，明确 repair / branch / advance / await_user / close，并生成下一 Unit 的 bounded context package 和 prompt 约束。

专项 reviewer 可按需要增加：

• Requirement Reviewer：只判断需求是否被正确理解和覆盖。
• Phase Reviewer：只判断当前 Phase 是否满足 exit criteria、是否应 advance / repair / branch / await_user / block。
• Evidence/Test Reviewer：只判断文件、测试、真实运行证据是否支撑 claim。
• Report Reviewer：只判断 Final Report 是否忠实反映 Loop 过程、修改、测试和边界。

Controller 聚合 reviewer 结果，做唯一 binding reaction。reviewer 可以建议调整内容，但不能单独宣布 closure、promotion 或 scheduler stop。若 reviewer 报告产物缺失或内容不符合用户 prompt，Controller 必须调度补齐 Unit；若问题属于当前 Loop 机制无法满足，Controller 把它编译成下一 Loop 的迭代任务，而不是直接 closure。

Phase Reviewer 的权限边界必须写清：可以建议调整 Controller Phase、User Requirement Phase 或融合后的 Task Phase Plan；不能改写已经发生的 Agent Unit Phase、task-local receipt、read path 或 execution history。若初始 Phase 设计不完整，Review Agent 应输出 overall_phase_adjustment 和 next_task_phase_plan_id，并保留原 Unit 内部 Phase 为事实历史。

Decision Packet 门禁

当审查发现会影响收束、Phase 推进、await_user、block、promotion、scheduler stop，或任何 residual / unsupported-claim 处理时，Controller 在做 binding reaction 前必须写入或消费 Decision Packet。

Decision Packet 是低熵调度产物。它不是最终报告，也不能替代文件检查或效果审查。它把审查发现绑定到 Controller 的下一步行动：

decision_packet_id:
created_at:
source_unit:
task_anchor:
  user_original_anchor:
  requirement_ids: []
  forbidden_claims: []
phase_position:
  controller_lifecycle_phase_id:
  user_requirement_phase_id:
  agent_unit_phase_id:
evidence_state:
  produced_artifacts: []
  native_evidence: []
  overlay_evidence: []
  controller_inference: []
  missing_evidence: []
  generalization_level:
gap_state:
  satisfied_requirements: []
  partial_requirements: []
  unmet_requirements: []
  blocked_requirements: []
  deferred_requirements: []
review_result:
  read_compliance_review:
  artifact_review:
  requirement_effect_review:
  phase_compliance_review:
  solid_decision_review:
    path:
    weakest_evidence_class:
    claim_ceiling:
    decision_stability:
binding_next_action:
  reaction: repair | continue_execution | continue_test | branch | advance | await_user | block | close
  next_unit_task:
  next_unit_owner_role:
  required_read_paths: []
  forbidden_read_paths: []
  max_atomic_tasks:
  claim_ceiling:
state_consistency:
  requirements_md_status:
  ledger_status:
  phases_status:
  closure_allowed:

硬门禁：

• 如果 gap_state.unmet_requirements 非空，binding_next_action.reaction 不能是 close，除非每个未满足项都被明确标成 blocked、在 deferred_requirements 中关联具体 next unit / backlog id，或被已记录的用户需求增量取代。
• 如果 evidence_state.missing_evidence 非空，相关需求不能标成 covered，相关声明必须低于 packet 的 claim ceiling。
• 如果某项能力只有 overlay evidence，Controller 不能声称 native capability。
• 如果 state_consistency.requirements_md_status、ledger_status、phases_status 或 closure review 互相冲突，closure_allowed 为 false，binding_next_action.reaction 不能是 close。
• 如果仍存在允许的 repair、bounded test、source collection、proposal-only 或下一 Unit，binding_next_action.reaction 不能仅因为发现问题就写成 await_user、block 或 close。它必须选择 repair、continue_execution、continue_test 或 branch，并写出下一 Unit 契约。
• 如果必需的 read-compliance review 缺失或失败，packet 不能绑定 advance、close、promotion、scheduler stop 或 broad claim，除非缺失读取被明确判定为不适用。
• 如果 packet 会影响 advance、close、await_user、block、promotion、scheduler stop、Final Report 状态或 broad claim 措辞，它必须消费 drafts/workflow_solid_decision_review.md，并包含 weakest evidence class 与 claim ceiling。缺少 solid-decision review 时，packet 不完整。
• binding_next_action.reaction 是必填字段。没有这个字段的审查总结不是 Controller decision。

小 Unit 可以把这个 packet 内嵌在 round review 中；closure-sensitive round 应写成 decision_packets/<id>.md，或放在 .loop_trace/factpacks/ 中，并从 round evolution event 引用。

测试 lane 的继续与停止

如果用户要求在 Loop 中优化、测试或验证某类 Skill / runtime / agent 行为，单个 bounded case、chunk、fixture 或 residual arbitration 完成，不等于整个测试 lane 应该等待用户。只要仍有明确的允许范围、剩余测试项和可记录的下一步，Controller 必须继续选择下一项测试、记录选择理由，并推进执行。

如果当前任务是在优化 Loop Skill、review 协议、runtime/scheduler 或 Chat History 找 Loop 的能力，必须在真实数据和真实运行环境上测试：至少使用一个真实 session/rollout、一个真实 Loop home/workpad、真实 source files 和真实 review/report artifacts。synthetic sample、grep-only dry-run 或历史报告复述只能作为预检，不能作为最终测试证据。

测试覆盖范围不能在启动 prompt 或 Bootstrap 中提前固定。Controller 必须先完成 source coverage、requirement analysis、run strategy，再在进入 environment_test 前写 TEST_COVERAGE_PLAN.md。具体 case 选择、真实环境重建、read isolation、negative/mutation guard、claim ceiling 和 stop certificate 规则由 workflow_real_task_test_case_design.md 与 drafts/workflow_solid_decision_review.md 承载，并被写入 TEST_COVERAGE_PLAN.md 的 phase-consumed section。

真实条件测试必须落实成 Controller 可消费的契约，而不是把测试方法合并进 Controller。Controller 的职责是把测试 phase 的 task card / protocol visibility / read contract 设置好，并要求 reviewer 检查 TEST_COVERAGE_PLAN.md 是否实际消费了上述 skill；测试执行 arm 的具体 forbidden reads 和 leakage response 不写在 Controller 长文里。

Primary case、environment-test evidence categories、test-round receipt、single-case closure exceptions 和 await_user 边界都由 workflow_real_task_test_case_design.md 与 drafts/workflow_solid_decision_review.md 的 phase-consumed contract 决定。Controller 只检查这些 contract 是否被 TEST_COVERAGE_PLAN.md、round review、Decision Packet 和 next_prompt.codex.md 实际消费；如果仍有允许测试、修复、补取证或 scheduler 动作，不能把完成一个 case 写成默认停止。

需求增量与 awaiting_user

持续 Loop 中后续用户消息默认是同一个 Loop 的 requirements delta，不是新任务，也不是自动 approval block。收到新需求时必须：

1. 保存用户原文或可复核摘要到 USER_PROMPTS/。
2. 给新增要求分配新 requirement id，追加到 REQUIREMENTS.md，并标明它修正了哪些旧判断。
3. 更新 CONTROL.md、HANDOFF.md、next_prompt.codex.md 和 runtime projection，让下一轮从最新要求恢复。
4. 重新判断 awaiting_user 是否仍成立。

awaiting_user 只在没有允许的隔离行动时使用：例如需要 formal promotion、破坏性操作、外部凭据、用户必须选择的互斥方向，且没有 adhoc/no-mutation 测试可以继续。若用户已经要求在隔离目录、adhoc job、只读 fixture 或 proposal-only surface 里继续测试或实现，Controller 必须把状态改回 active，并把 formal-write 边界记录为 next_forbidden，不能让 formal approval 阻塞所有后续工作。

当等待判断被发现过宽时，下一轮必须把它记录为 issue_class: controller_prompt_risk，并写入 effect review：原等待条件是什么、为什么被新需求解除、哪些 formal 边界仍然禁止。

轮次推进规则

来源材料只用于维护本 skill 的设计，不作为执行 Agent 的必读上下文。执行者只需要按下面的直接规则工作：

• 每个有意义的 round 只能选择一个主动作：classify、prepare_fixture、execute、rerun_or_recheck、synthesize、review 或 close。
• classification、source triage、fixture prep、status report 和 synthesis 可以降低未知数，但不能自动关闭需求。
• 每轮必须写清本轮做了什么、证据在哪里、错误属于哪一层、语义效果是什么、下一轮允许做什么、禁止做什么。
• 每轮先做文件产生检查，再做效果审查，再写 next-step planning。文件存在、JSON 可解析、测试 PASS 只证明确定层有效；需求是否被满足由独立 review 判断。
• 每个 agent 调用必须有独立 prompt 和 task-local run directory。执行者、coverage reviewer、effect reviewer 和 final report writer 不共享隐式上下文；reviewer 默认只读 requirements、问题文件、artifact list、test result 和 factpack。
• 每个 Unit 最多 5 个原子任务。Reviewer 可以要求拆分或补齐；Controller 只调度补齐，不把多个缺口合并成一个大包执行。
• 当前 Loop 的默认探索方式是原子任务卡加 requirements audit。不要把 AutoResearch 当作 root Loop 或默认实践方法。
• 需要 heartbeat、cron、codex exec resume 或 project automation 时，Controller 只写业务状态、停止条件和 next prompt 需要恢复的磁盘事实；具体调度由 codex_schedule_loop 决定。sustained Loop 默认每个 Loop Unit 后 20 分钟级唤醒；如果无法设置 scheduler，必须把原因和下一步写入 CONTROL.md / HANDOFF.md，不能只留下隐式 next prompt。
• 如果 Loop 本身是在测试或改进 Loop/AAU/AOU 这类持续系统，必须把测试用例构建也当成 Loop 产物：用真实历史 prompt、当时可见文件、真实输出和后续纠错记录建立 fixture；每轮同时记录单次运行检查和宏观持续优化检查。
• 测试不能只证明过程文件存在。必须区分 shared task-quality lane、AAU/Loop 专属 artifact/protocol lane、anti-cheat lane、reconstruction fidelity、cheat path、anti-cheat check、mutation/negative control。只有 shared task-quality lane 改善时，才能声称任务质量提升；wrapper-only protocol lane 最多支持可审计性、边界诚实性或恢复能力提升。

AAU Integration 2、Library Distillation、历史职责漂移和 AutoResearch 的来源说明放在 references/LOOP_DESIGN_SOURCES.md。维护本 skill 时可以读取；执行普通 Loop 时不需要读取。

task_loop 必要文件

USER_PROMPTS/
SOURCE_MANIFEST.tsv
INFORMATION_COLLECTION_PLAN.md # 多 Unit intake 时必需；也可作为 SOURCE_MANIFEST.* 的等价 section
REQUIREMENT_EVIDENCE.md
REQUIREMENTS.md
CONTROL.md
TASKS/
TESTS.md
PHASES.md
PHASE_OUTPUTS.md     # 可选；也可作为 PHASES.md 中的 expected_outputs section
TEST_COVERAGE_PLAN.md # 测试 / 验证类 Loop 必需；具体 section 按 workflow_real_task_test_case_design phase contract 写入
AGENT_RUNS/          # 或 runs/agents/；隔离 agent prompt/result/log
decision_packets/    # closure-sensitive review-to-dispatch gates; optional inline for small rounds
evidence/
reports/FINAL_REPORT.html
HANDOFF.md          # 仅 recoverable、await_user、pause、closure、compaction、跨 session 时创建
SCHEDULER_DECISION.md # sustained / recoverable Loop 必需；blocked / unavailable 也写在此文件

CONTROL.md 只记录当前控制面。它可以引用 task card：

action_authority:
  action_type: answer | dispatch | proposal | implementation | scheduler_change | promotion
  evidence_sufficient_for:
  approved_decision_path:
  allowed_next_action:
  forbidden_next_action:
active_tasks:
  - task_id: T001
    controller_phase_id:
    user_requirement_phase_id:
    agent_unit_phase_id:
    task_card_path: TASKS/T001.md
    status: planned | running | completed | blocked

不要把完整 task card 或完整历史塞进 CONTROL.md。任务细节放进 TASKS/Txxx.md，证据放进 evidence/，长历史放进 review artifact 或 trace 派生 factpack。

如果 action_type 是 implementation、scheduler_change 或 promotion，approved_decision_path 必须指向用户授权、已审查的 proposal、version decision 或明确任务卡。缺少授权路径时，下一步只能降级为 answer、dispatch 或 proposal。

确定层

recoverable_overlay 使用：

.loop_trace/
  events.jsonl
  state.json
  runs.jsonl
  indexes/
    agents.jsonl
    files.jsonl
    skills.jsonl
    tests.jsonl
    decisions.jsonl
    runtime.jsonl
  factpacks/
  snapshots/

.loop_trace/events.jsonl 是唯一规范原始事实日志。indexes/ 下的文件只是派生视图，必须能从 events.jsonl 重建。不要把原始事实拆成多个互不相干的日志。

如果接入现有 Codex 或 Claude 可恢复 Loop 运行时，必须保留 loop_state.codex.json、loop_runs.codex.jsonl、next_prompt.codex.md、STOP.codex 的语义。它们是 runtime compatibility projection 或别名，可以由 .loop_trace/ 生成，但不是 Controller 原生 trace 的替代。

每个有意义的 round 至少记录这些事实：

round_evolution:
  controller_phase_id:
  user_requirement_phase_id:
  agent_unit_phase_id:
  phase_decision: stay | advance | repair | branch | await_user | close
  controller_phase_decision: stay | advance | repair | branch | await_user | close
  user_requirement_phase_decision: stay | advance | repair | branch | await_user | close
  next_phase_id:
  action_kind: classify | prepare_fixture | execute | rerun_or_recheck | synthesize | review | close | other
  atomic_tasks_completed: []
  atomic_tasks_deferred: []
  did_what:
  evidence_paths: []
  issue_class: task_core_defect | runtime_or_wrapper_defect | test_or_evaluator_glue | fixture_or_source_limitation | model_task_failure | controller_prompt_risk | no_issue
  semantic_effect: requirement_effect_changed | artifact_only | useful_reasoning_only | not_measured
  next_allowed: []
  next_forbidden: []
  read_compliance_verdict:
  solid_decision_review_path:
  weakest_evidence_class:
  claim_ceiling:
  decision_packet_path:
  binding_next_action:

classification、source triage、fixture prep 和 synthesis 都不能自动计为 execution coverage。真实执行覆盖必须有对应的 execution evidence、review evidence 和 closure boundary。

只有在工程化恢复或 review 输入时，才读取详细 trace 协议：protocols/FILE_AND_TRACE_CONTRACT.md。

Skill 路由

Skill 路由在每次 dispatch 前进行，不在启动时一次性为所有未来任务预选。

drafts/workflow_requirement_decomposition_core.md、workflow_real_task_test_case_design.md、drafts/workflow_solid_decision_review.md 和 drafts/workflow_what_to_how_execution_bridge.md 是 Loop 相邻方法 skill，不计入普通执行 Unit 的局部执行 skill 预算。Controller 可以在对应 Phase 的 task card 中显式授权读取它们；它们的输出进入 phase artifact、review、execution plan 或 Decision Packet，不能绕过 Controller 直接决定 closure。

Skill 正交性审查

当用户要求处理重复 skill、职责边界不清、入口混淆或“非正交”时，当前 Loop 的主目标就是正交性修复，而不是普通流程优化。Controller 必须先建立 boundary matrix，再决定是否修改 skill：

orthogonality_matrix:
  - skill:
    trigger_surface:
    runtime_environment:
    owns:
    does_not_own:
    upstream_inputs:
    downstream_consumers:
    overlapping_skills: []
    confusion_mode:
    routing_decision: keep_separate | narrow_trigger | delegate | deprecate | merge
    required_patch:
    validation_fixture:

判定规则：

• 内容边界和运行环境都算正交性。Codex 调 Claude Code、Claude Code 调 Codex、调度器、Chat History、Long Context、Loop 后审查、agent 通信基底即使内容相邻，只要运行面或拥有的状态不同，就应保持独立入口。
• 不要因为两个 skill 都提到 loop、review、context 就合并；先问谁拥有需求、谁拥有覆盖、谁拥有 verdict、谁拥有 runtime、谁拥有 wakeup、谁拥有 presentation。
• 只有发现具体混淆模式时才 patch：例如 trigger 误导、authority 边界缺失、review 越权、runtime 抢 closure、coverage 被写成 verdict、报告生成入口不明。
• 每个 patch 必须有验证 fixture：历史 prompt routing replay、真实 workpad、semantic fixture、agent isolation test 或 deterministic grep/schema check。
• 如果某个相邻 skill 已经正交，只记录 keep_separate 和理由，不为了“去重”删除或合并。

每个 task card 记录：

selected_skills:
  - skill_path:
    use_mode: call_directly | absorb_principle | reject
    covers_req_ids: []
    reason_now:
    local_instruction:
    expected_artifact_effect:
    authority_boundary:
    skill_effect_checked_by:

一个 Skill 只有改变了产物、决策、测试或下游消费方式，才算真实使用。审查时丢掉装饰性的 Skill 提及。

读写边界

执行 Agent 只读自己的任务卡和列明的 source path。默认不读完整 .loop_trace/、judge-only oracle、closure draft、无关任务卡或控制器的成功叙事。

Protocol 和 review skill 文件也必须走读权限分配。任务卡必须有 protocol_visibility：列出本 Unit 可读的 protocol / review skill、允许角色、允许 Phase、理由和禁止 protocol。drafts/workflow_requirement_decomposition_core.md 默认只在复杂 information_search / requirement_analysis、Requirement Reviewer、Controller requirement arbitration 中可读。workflow_real_task_test_case_design.md 默认只在 test_coverage_planning、environment_test、测试设计者、Evidence/Test Reviewer 或明确测试 Loop/AAU/AOU 的 protocol audit Unit 中可读；普通 task_execution 执行者不读测试方法协议。drafts/workflow_solid_decision_review.md 默认只给 Solid Decision Reviewer、Effectiveness Reviewer、Next-Step Planner 和 Controller decision gate 使用。drafts/workflow_what_to_how_execution_bridge.md 默认只给 execution planning、repair planning、real-condition validation planning 和 Next-Step Planner 使用，用来把明确目标转成首个真实切片和验证反应；它不能单独裁决 closure、promotion 或 scheduler stop。ROUND_FILE_AND_EFFECT_REVIEW.md / REVIEW_AND_CLOSURE.md 默认给 reviewer / Controller 收束用，不给普通执行 Agent。分配角色或处理 protocol 泄漏时读取 protocols/READ_POLICY.md。

每个消费 Agent 的任务卡必须带 consumer_protocol_receipt_gate。这个 gate 是受控信息注入的最小强制面：它不假定平台会自动阻止缺读，而是要求任务卡、实际读取记录、receipt、read-compliance review 和 next-step reaction 形成闭环。

consumer_protocol_receipt_gate:
  applies_to_roles: []
  checks:
    - repository_startup_handshake_completed
    - skill_routing_source_recorded
    - preflight_context_classified_separately_from_evidence_context
    - task_card_has_protocol_visibility
    - required_read_contract_lists_phase_instruction_files
    - required_read_contract_lists_repository_startup_files
    - agent_read_paths_contains_required_protocols
    - agent_read_paths_contains_required_startup_and_skill_routing_sources
    - state_authority_source_recorded
    - stale_sources_absent_when_marked_stale
    - forbidden_protocols_absent
    - forbidden_reads_absent
    - forbidden_even_as_preflight_absent_or_explicitly_justified
    - receipt_records_phase_ids_and_protocols
    - receipt_records_startup_skill_state_and_scheduler_fields
    - receipt_classifies_actual_reads_by_preflight_evidence_forbidden
    - required_information_use_has_output_trace
    - receipt_output_agreement_matches_result_or_decision_packet
    - read_compliance_verdict_pass_before_effect_review
  evidence_inputs:
    task_card_path:
    phases_path:
    agent_read_paths_path:
    agent_receipt_path:
    read_compliance_review_path:
  pass_condition: all_checks_pass_or_not_applicable_with_reason
  fail_reaction: repair_read_contract_or_rerun_unit

consumer_protocol_receipt_gate 必须出现在当前 Unit 会读取的 TASKS/Txxx.md 或等价任务本地包中，并被审查者在读取合规段复核。缺少该门禁时，不能 advance、close、晋级、停止调度或写宽泛声明；下一步只能是修复任务卡、读取契约、下一轮提示词，或在证据已污染时重跑/降级。

UCR candidate 指针：unit_context_runtime 提供上述 Unit 读取合规与差异化 context 注入的 candidate 级运行时实现，工具入口见 tools/INDEX.md。读取合规客观验证由 adhoc_jobs/workflow_controller_loop_evolution_20260505/unit_runtime_unified_mechanism_20260529/ucr/read_compliance_verifier.py 提供；executor/reviewer/verifier 等角色的 bounded context package 构造与仓外隔离 staging 分别由同目录下的 package_builder.py 和 context_stager.py 提供；端到端编排入口是 ucr/unit_runner.py。当前只作为 bounded/candidate 运行时指针使用，不等同于 production 写入或 closure/promotion 裁决。

Phase Runtime candidate 指针（Phase 5 slice 1，2026-06-06，T785）：phase_runtime 提供把上述 task_phase_plan 从纯协议变成可运行运行时的 candidate 级实现的第一切片——线性 phase loop。它逐 phase 走 plan，每 phase 用 UCR build_unit_packages 做 phase-aware 差异化 context 注入，收口跑机械 exit gate（确定性覆盖义务核验 + AAU ReviewPointAgent RP-C 独立 verdict 双门），过双门才 advance、否则 repair，末 phase 走 FinalCompletionGate close，全程写 .loop_trace/events.jsonl。工具入口见 tools/INDEX.md（tools/phase_runtime/）。复用 aau_v2 ledger/review/final_boundary/runners + UCR package_builder，不重写。当前只作为 bounded/candidate 运行时指针：仅实现 slice 1 线性 backbone，非线性 phase 转向（slice 2）/ runtime hook（slice 4）/ 充分性增益门（slice 3）/ 方法论 skill（G5）均未实现，不等同于 production 写入或 closure/promotion 裁决。

Phase Runtime slice 2 Candidate A 指针（Phase 5 slice 2，2026-06-06，T794）：在 slice 1 decide() seam 上加可插拔 PhaseDecisionStrategy（tools/phase_runtime/phase_decision.py）。LinearStrategy 复刻 slice 1 线性路径（13 回归测试不变），LadderStrategy（strategy_ladder.py）把本 schema 的 phase_decision 全值域（branch / branch_back / await_user）实现为 workflow_manage_unexpected 的动作阶梯：repair→branch→branch_back→downgrade→block。run_plan 由 for-loop 改 cursor while-loop。branch_back = 用户确认的 rollback 语义：以 hand-off 重做上游 phase（fresh dispatch 带 disclosed tried/known attempts），不做 in-process 状态重置、不截断 append-only ledger、不删已写产物。死循环守卫（同墙无增量）+ pivot 预算 + REENTRY_CAP 保证强终止；穷尽阶梯落合法 block receipt（复用 premature_block 检测器离线核 C1-C4）。

Phase Runtime slice 2 Candidate B 指针（Phase 5 slice 2，2026-06-06，T795）：第二个非线性决策策略 GateStallStrategy（tools/phase_runtime/strategy_gate_stall.py）接同一 PhaseDecisionStrategy 接口，是带类型门的状态机：Abort 门（不安全约束 permission/credential/destructive_risk/user_stop 立即停、保状态、不试阶梯）/ Pre-flight 门（后端未就绪 external_system 有界重试）/ Revision 门（对 issue_count = len(unmet)+len(missing_items) 做显式 stall 检测：在降则 repair、停滞则 replan 重入[上游有 fallback 走 branch_back hand-off、否则 downgrade]、超 stall_reentry_cap 才升级）/ Escalation 门（→await_user + 合法 block receipt）。与 Candidate A 的差异：A 靠同墙无增量守卫、B 靠显式 stall 计数（三候选最强 dead-loop 守卫）；A 对不安全约束仍试阶梯、B 的 Abort 门立即停。rollback 语义同 A（branch_back = hand-off 重做上游 + disclosed attempts，非 in-process 重置）。真实 codex demo：三 attempt issue_count 不降 → stall 守卫触发 → 合法 block（premature_block PASS）；确定性 demo：进展感知 repair → DONE（独立 gate 背书）。零改 LinearStrategy/LadderStrategy/phase_runtime.py（orchestrator while-loop 已对任意策略 dispatch）、零新增 EVENT_TYPES、34 pytest（24 回归不变 + 10 新）。 仅 Candidate A+B landed；Candidate C(T796)/候选对比测试与 keep-decision(T797) 未实现，keep-decision 由 4-demo 对比测试定、不纸面拍。

Phase Runtime slice 2 Candidate C 指针（Phase 5 slice 2，2026-06-06，T796）：第三个非线性决策策略 DagStrategy（tools/phase_runtime/strategy_dag.py）接同一 PhaseDecisionStrategy 接口，是声明式依赖图重排：plan 的 phase 加 optional depends_on 边变成 DAG，运行时 dag_ready/dag_blocked 对应 OpenSpec ArtifactGraph getNextArtifacts/getBlocked（READY/BLOCKED/DONE 三态）。PASS 标 DONE 并 branch 到下一个 READY 节点；某 phase 阻塞时让位、先跑一个独立的 READY 兄弟节点（动态调整运行顺序 = P-03 字面诉求）；穷尽重排+重试后沿依赖边 branch_back hand-off 重做上游（复用 A 的 rollback 语义、非 in-process 状态重置）；全堵死落合法 block receipt（过 premature_block 检测器）。死循环守卫 = 结构无环 + 每 phase 让位次数受 reorder_attempt_cap 限 + REENTRY_CAP，强终止。与 A/B 的差异：A 命令式阶梯、B 类型门 stall 计数、C 声明式 DAG 重排，最贴「动态调整顺序」。真实 codex demo：reorder（P2 阻塞 → 跑独立兄弟 P3 → 回 P2 → 沿 dep 边 rollback → 合法 block，premature_block PASS）+ diamond（P1→{P2,P3}→P4 join → COMPLETED，独立 RP-C 背书）。零改 LinearStrategy/LadderStrategy/GateStallStrategy/phase_runtime.py、phase_decision.py 仅加 done_phase_ids 一字段、plan_loader.py 加 optional depends_on、零新增 EVENT_TYPES、44 pytest（34 回归不变 + 10 新）。 A/B/C 三候选全 landed。

Phase Runtime slice 2 keep-decision 指针（Phase 5 slice 2 收尾，2026-06-06，T797）：4-demo × 4-arm（linear 基线 + A/B/C）确定性对比矩阵（demo_slice2/compare_strategies.py，strategy-blind worker + premature_block 机械核）测得：主 oracle（达好终态最多 + bad-behavior 违例最少）下 A/B/C 打平（各 4/4 好终态、0 违例），三者严格优于 linear 基线（0/4 好终态：可恢复失败也放弃、产不出合法 block）。裁定落正交能力轴 = A 默认 backbone（最小 delta、over-engineering 最低）+ C 服务 P-03 依赖结构 plan（D2 实测唯一在运行中交付「动态调整运行顺序」、reorder 到独立兄弟、mutation 可控）+ B 的 abort 门嫁接进默认（D3 暴露 A 对不安全约束 credential 白跑阶梯，B/C abort-fast 更对）；B 的完整类型门状态机不作第三独立策略保留（over-engineering 最高、安全质量被 A/C 匹配）。证据 = bounded（确定性 worker + 4 合成 demo + 单任务类型）；solid 级 keep-decision 延后到 AAU Daemon 接入真任务后 head-to-head。下一步 = 选定策略（A 默认 + C 供 DAG plan）接 AAU Daemon 3 非线性触发点（4 阶段切换 / 6 role 越界 / 7 tool failure）。报告 reports/T797_phase5-slice2-comparison-keep-decision.md。

Phase Runtime slice 2 keep-decision 落地补丁指针（Phase 5 slice 2，2026-06-06，T798）：T797 keep-decision 的「B abort 门嫁接进默认」已落地实现——LadderStrategy（默认 A，tools/phase_runtime/strategy_ladder.py）在 classify_constraint+wall_key 后加 abort 门，对不安全约束（permission/credential/destructive_risk/user_stop）立即 await_user + 合法 block receipt（不再白跑 repair→branch→downgrade 阶梯），与 B/C abort-fast 对齐；ABORT_CLASSES 合并到 phase_decision.py 单一真源（B 仅 import 合并、行为恒等）。零改 orchestrator(phase_runtime.py)/plan_loader.py/LinearStrategy/DagStrategy 行为，45 pytest（44 回归不变 + 1 新 abort 测试），A abort receipt 过 premature_block（credential 3 步 + permission 4 步全 PASS），对比矩阵 A/B/C 仍各 4/4（keep-decision 不回归）。报告 reports/T798_phase5-slice2-abort-graft.md。

每个隔离 agent 运行使用任务本地目录，避免把提示词、结果和审查混在全局 tmp/：

AGENT_RUNS/
  round_<N>_<role>_<slug>/
    prompt.md
    read_paths.txt
    result.md
    stderr_or_events.log
    receipt.yaml

read_paths.txt 是权限边界，receipt.yaml 至少记录 controller_phase_id、user_requirement_phase_id、agent_unit_phase_id、已覆盖 requirement id、声明使用的来源、缺失/阻塞来源、已完成/延后的原子任务、输出路径、自报限制和建议的下一步反应。Controller 或审查者只消费 result.md 与 receipt，不继承该 agent 的隐藏推理或聊天上下文。

Fresh process 或隔离 agent 的 receipt 还必须记录这些 read-contract 字段，未适用时写明 reason：

mandatory_startup_reads_completed: true | false
startup_instruction_source: AGENTS.md
skill_routing_source: rules/skills/INDEX.md
selected_skill_effect:
actual_read_classes:
  preflight_repository_non_evidentiary: []
  preflight_skill_protocol_non_evidentiary: []
  promoted_preflight_evidence: []
  task_local_evidence: []
  forbidden_source: []
read_use_declaration:
  used_for_task_judgment: []
  read_only_for_operational_routing: []
state_authority_source:
stale_sources_not_read: []
forbidden_sources_not_read: true | false
required_information_use_traced: true | false
scheduler_or_manual_resume_expectation:
consumer_protocol_receipt_gate_status: pass | fail | not_applicable_with_reason
receipt_output_agreement_status: pass | fail | not_applicable_with_reason
claim_ceiling:

如果任务需要更正式的 agent 间交互、固定上下文注入、交接 artifact、禁读策略或 ledger 重放，读取 drafts/workflow_agent_communication_protocol.md，并可参考 adhoc_jobs/agent_communication_protocol_20260521/ 的 AgentContextGrant / HandoffArtifact / ProtocolWorkspace 形态。该协议是通信基底，不属于 AAU、Loop 或某个审查者；Controller 仍持有需求、任务卡、审查和收束。

如果 Agent 需要更多上下文，必须先请求最小 path set。分配角色或处理泄漏时读取：protocols/READ_POLICY.md。

审查与收束

审查的目标是决定下一步反应，不是写进展总结。可选反应包括 keep、repair、continue_execution、continue_test、discard、rethink、redesign_test、advance、await_user、block。

执行 Agent 不能用自己的产物自证通过。凡是本轮涉及用户需求语义、错误归因、final boundary、隐藏 oracle、或是否继续下一轮，都要有独立 review 面：可以是独立 sub-agent、runtime judge、新 session，或主 agent 在隔离 factpack 上做的明确独立审查。审查者读取 factpack、相关证据和允许的 oracle，不继承执行者的成功叙事。

review 链必须显式覆盖 required reads：Read-Compliance Reviewer 先检查 task card、read_paths.txt、receipt 和 phase-consumed files 是否匹配；缺读或越界读不能被后续 Artifact PASS 抹掉。凡是下一步会影响 phase advance、closure、promotion、scheduler stop、await_user / block 或 broad claim，Effectiveness / Solid Decision Reviewer 必须消费 drafts/workflow_solid_decision_review.md 并输出 evidence class、claim ceiling 和 next reaction。

Read-Compliance Reviewer 还必须检查 repository startup handshake、rules/skills/INDEX.md Skill 路由来源、latest-prompt state authority、stale sources 未读、forbidden reads 未触碰、required information use 输出痕迹、scheduler 或 manual resume expectation、consumer_protocol_receipt_gate_status 和 receipt/output agreement。上述字段未通过前，不能 phase advance、closure、promotion、scheduler stop 或写宽泛声明；下一步只能修复 read contract、重跑受污染 Unit，或降低 claim ceiling。

在线审查必须遵守 active repair priority：先修复和继续，再等待或阻塞。artifact_only、not_measured、missing evidence、unsupported claim、protocol leak、Phase guidance 缺失、test coverage 不足、report 不完整，默认都是下一步工作的输入，不是默认 stop reason。只有下列情况才允许把下一步设为 await_user 或 block：

• 继续需要用户选择互斥方向，且没有可并行推进的取证、proposal-only 或 no-mutation 工作。
• 继续需要外部凭据、付费/生产系统、破坏性动作、formal promotion 或用户明确授权。
• 可行 repair / test / source collection 已经尝试并记录，仍被同一外部条件阻断。
• 用户明确要求暂停、只汇报、不继续执行。

如果仍有允许的修复或验证动作，Controller 必须创建或更新 TASKS/Txxx.md、Decision Packet、next_prompt.codex.md 或 scheduler decision，让下一 Unit 继续解决用户需求。

收束必须满足：

• 每条适用需求都有证据、阻塞原因或不适用原因。
• 每个 Phase 都是 passed、skipped（有理由）、blocked（有阻塞）或被后续 Phase 明确接管。
• 当前 Controller Phase 的预期产物已产生；User Requirement Phase 的内容对齐已审查；关键 Agent Unit 有 receipt。
• 测试或审查检查足以改变下一步行动。
• 测试 / 验证类 Loop 已通过 TEST_COVERAGE_PLAN.md、workflow_real_task_test_case_design.md 和 drafts/workflow_solid_decision_review.md：case 覆盖、cross-validation 或其 bounded exception、negative guard、scheduler decision、backlog、completion fact、weakest evidence class 和 claim ceiling 都允许当前 stop scope。单个 primary case pass 默认不能关闭完整用户任务。
• 已选择的 Skill 有可验证效果，或者已在审查中丢弃。
• reports/FINAL_REPORT.html 已生成或更新，包含改动内容、原因、测试方法、Phase/转向历史和证据边界。
• 最终声明区分 requirement_effect_changed、artifact exists、model useful reasoning 和 promotion_ready，并指向证据而不是意图。

做 round review、milestone review 或 closure 时读取：protocols/REVIEW_AND_CLOSURE.md。需要把文件产生检查和效果审查拆开时读取：protocols/ROUND_FILE_AND_EFFECT_REVIEW.md。

如果当前 Loop 的目标是测试 Loop/AAU/AOU/agent runtime 自身，或用户要求根据 test case method 重建测试用例，读取：workflow_real_task_test_case_design.md。

启动 Prompt

真正启动 Controller 时使用 START_PROMPT.md。本文件是压缩后的策略层。START_PROMPT.md 必须与本文件同步维护：intake lane、requirements delta、awaiting_user 重判、task-local AGENT_RUNS/、read-compliance review、文件产生检查、效果审查、solid-decision gate 和 Loop/AAU 测试 lane 不能只存在其中一份。