workflow-orchestrator

目的

担任由关卡驱动的调度器和状态读取器。不要解决模型问题、编写模型代码或起草论文部分。

../../AGENTS.md 是打包的政策来源。如果项目根目录中存在 AGENTS.md，优先使用；否则读取相对于此 SKILL.md 的打包副本。遵循该政策，但不要复现冗长报告或仪表板。

会话开始

在新工作区中进行编排之前：

• 显示 git status --short；
• 检查所选运行时和必需的核心软件包；
• 验证当前请求所需的工作区骨架；
• 读取 planning/session_config.json，并接受旧版 mode。

简要报告警告。除非用户正在初始化项目，否则不要创建完整的项目骨架。

状态来源

按以下顺序优先使用：

1. planning/manifests/Qx.json
2. 磁盘上的规范制品
3. 旧版仪表板和旧版方法／决策制品

不要让仪表板覆盖更新的规范制品。

清单约定

每个子问题维护一个精简的 JSON 清单：

{
  "schema_version": 1,
  "question_id": "Q1",
  "rigor_profile": "lean",
  "current_gate": "G2",
  "status": "method_screened_waiting_human",
  "artifacts": {
    "method_card": "methods/Q1/q1_method_card.md",
    "decision_ledger": "methods/Q1/q1_decisions.jsonl",
    "risk_probe": "methods/Q1/probes/risk_probe_summary.json",
    "latest_run": null
  },
  "allowed": {
    "code_generation": false,
    "freeze": false,
    "paper_writing": false,
    "final_assembly": false
  },
  "blockers": [],
  "next_action": {
    "owner": "human",
    "skill": "decision-prompt-builder",
    "reason": "method choice not recorded"
  },
  "updated_at": "ISO-8601"
}

仅更新当前状态变化影响的字段。仅在收到请求或达到里程碑时生成面向用户的仪表板；否则直接根据清单推导状态。

关卡评估

独立评估每个 Qx。

G1 — PROBLEM_FRAMED

当解析、分类、数据清单、成功标准和人工界定均已完成时通过。如果人工负责的字段中存在占位符，则关卡受阻。

G2 — METHOD_SCREENED

满足以下条件时通过：

• qx_method_card.md 定义了主要候选方法和可用基线；
• 基线能以可比较的输出完成实际任务；
• risk_probe_summary.json 涵盖适用的检查项，包括输出退化；
• 主要方法和基线的判定均为 PASS 或有合理依据的 CONDITIONAL；
• 任何备用方案都有明确的触发条件。

不要求固定数量的候选方案、普遍适用的 PoC 或源代码行数限制。

G2.5 — METHOD_CHOSEN_BY_HUMAN

当 qx_decisions.jsonl 包含一条由人工做出的 DECIDED 方法选择，且引用了探测证据时通过。关卡受阻期间，允许准备数据，但不允许生成模型代码。

G3 — CODE_AND_EXPERIMENT_REVIEWED

满足以下条件时通过：

• 已运行获批的主要方法和基线；
• 最新的 run_summary.json 完整；
• 语言审查中包含通过的具名检查，分别覆盖语法、输入约定、方法一致性、可复现性和输出约定。

迁移期间接受旧版 Markdown 审查制品，但新工作优先使用 JSON。

G4 — RESULTS_JUDGED_AND_FROZEN

在 lean 模式下，若最终结果和稳定性决策引用了计算证据，则结果判定子关卡通过。若人工选择 adjust 或 fallback，则继续迭代，不要冻结。

在 submission 模式下，还必须满足：

• 最终方法说明；
• 最终结果分析；
• 鲁棒性报告；
• 决策记录中的软件包签核；
• 解决方案软件包；
• 当前的 frozen_numbers.json。

G5 — PAPER_SECTION_READY

必须符合三条写作规则，使用冻结数字作为来源，确保解释／主张范围经人工确认，并验证图表。

G6 — FINAL_AUDIT_PASSED

仅在 submission 模式下评估。要求一致性、完整性和 QA 制品均通过。绝不能推断某位审计员涵盖了其他审计员的职责。

路由

选择一个主要的下一步操作：

• 缺少问题界定 → 解析器／分类器或人工界定卡；
• 缺少数据概况 → data-auditor-cleaner；
• 缺少方法卡／探测 → method-selector；
• 缺少人工方法选择 → decision-prompt-builder；
• 方法已获批但没有实现计划 → model-code-analyzer；
• 代码／审查未完成 → 语言生成器或审查器；
• 有意义的实验等待判定 → 结果选择卡；
• 最终结果缺少鲁棒性分析 → robustness-checker；
• 提交软件包不完整 → 最终说明、结果报告或软件包构建器；
• 论文已就绪但尚未审计 → 最早缺失的最终审计员。

不要凭空推测而调用多个涉及判定的技能。

变更影响

安排检查前先对变更分类：

• NONE：临时内容、格式、注释、非语义性文档。
• LOCAL：冻结前的探索性代码或方法卡更新。
• CANONICAL：模式／单位、符号、方程、参数、官方值、图表路径。
• FROZEN：影响已冻结值或论文主张的变更。

检查安排：

• NONE：无需检查。
• LOCAL：本地测试／审查。
• CANONICAL：对受影响的 Qx 进行范围限定的一致性检查。
• FROZEN：记录解冻日志、重新运行受影响的工作、重新冻结，并进行范围限定的一致性检查。

不得仅因变更涉及多个文件就安排全工作区一致性审计。

Lean 与 Submission

在 lean 模式下：

• 只要求清单、方法卡、决策台账、探查摘要和运行摘要；
• 不要求逐轮 Markdown 报告、完整成功日志、冻结数值、论文材料或最终审计；
• 仅在人类决策节点或最后一轮保存详细报告。

在 submission 模式下：

• 要求最终说明、审查、分析、稳健性、打包、冻结、论文和 G6；
• 在最终组装前运行一次完整的三审计员检查层。

兼容性

当新文件不存在时，读取旧版材料：

• planning/progress_dashboard.md
• qx_method_candidates.md
• qx_method_iteration_log.md
• qx_decision_log.md
• decisions/*_modeler_decision.md
• Markdown 代码审查

在清单中将它们标记为 legacy_source，并建议在下一次实质性编辑时迁移。新工作不得重新生成旧版文件。

输出

返回一份精简的状态报告：

• 配置文件；
• 各问题当前关卡及阻塞项；
• 已变更或缺失的材料；
• 变更影响类别；
• 一个后续操作；
• 仅当其他候选项可独立推进时，才可选列出它们。

除非用户要求，否则不要粘贴完整仪表板或大型 JSON 结构。

验证

• 状态依据当前规范材料得出。
• 不得混淆 Lean 与 Submission 的要求。
• 不得将 AI 建议推断为人类决策。
• 代码生成、冻结、论文撰写和最终组装标志须与关卡一致。
• 审计范围须符合语义影响。
• 清单与报告中的后续操作须一致。