创建研究任务

新建页的核心不是一张普通表单，而是生成一份 Research Contract。只有通过服务端预检的契约才能创建和启动任务。页面会在本机自动保存未完成草稿；也可以从历史任务复制配置，但输入文件和全局模型设置不会复制。

1. Research goal

• Task title：最长 120 个字符，用于左侧任务列表和导出名称。
• What should this run establish?：可验证的目标，最好同时说明对象、范围和成功条件。
• Research questions：每行一个问题，帮助 Reasoner 组织研究，但不代替正式验收条件。

一个合适的写法是：

Title: Reference ring boundary scan
Goal: Locate the positive-x survival/loss boundary after 128 turns
Question: What interval brackets the transition?

不要只写“研究一下这个数据”。系统无法从含糊目标推导出明确的成功条件。

若选择 Copy configuration from a previous task，会复制目标、问题、工作流、能力、约束、验收条件和预算。系统只保留当前仍可用的 capability，并清空输入文件，避免无意复用旧数据。

2. Scientific workflow

这三项都是可选的额外完成条件：

• Enable hypothesis verification：允许任务创建版本化假设、验证计划、审批、验证请求和结果。关闭时，Runtime 会拒绝相关动作。
• Require scientific artifacts for completion：除所有指标满足外，还要求选定种类的产物存在。可选 analysis_result、evidence、scientific_claim、hypothesis、verification_plan、verification_result、scientific_report。
• Require reusable final predictor：要求最终存在经过评价的模型和推理程序，并遵守 file-predictor-v1 的输入/输出文件接口。

页面上的 Authorize pipeline 只是一次性勾选已安装的 Analysis、Knowledge、Verification 和 Report capabilities；它不会绕过权限确认。指标仍由 CriteriaEngine 判断，科学产物检查只负责额外的完整性门槛。

3. Capabilities

能力按领域实验、执行与训练、评价、分析、知识与验证、报告与可视化分组。勾选意味着这份契约允许 Reasoner 调用该 capability；没有勾选的能力即使已经安装，也会被 Runtime 拒绝。

每张卡片会显示：

• 稳定 capability 名称和提供插件；
• Core/Domain 分类、领域和可信指标标志；
• 消耗与产出的科学产物种类；
• capability 可报告的指标。

Capability constraints 是高级选项，用 JSON 限制特定输入组合。例如强制所有 evaluation 数据使用固定网格：

{
  "beam.xsuite.generate_stability_dataset": [
    {
      "when": {"dataset_role": "evaluation"},
      "require": {"num_turns": 128}
    }
  ]
}

每个 capability 对应规则数组，每条规则只能包含对象形式的 when 与 require。不需要约束时保留 {}。

4. Input artifacts

可一次导入多个文件，最多 20 个。CSV、JSON、Parquet 自动归为 DATASET，Python 文件归为 source.python，其他文件归为 OTHER。桌面端只把文件内容导入 ArtifactStore，不把原始主机路径写进契约。

导入后核对文件名、类型和字节数。预览阶段会计算 SHA-256；启动后每个输入都是不可变研究产物。需要跨 action 使用时，插件以 Artifact ID 声明输入，Runtime 校验 Run 归属、可见性和哈希后再放入工作区。

5. Acceptance criteria

至少需要一条条件，也可以增加多条；所有条件都满足才可能成功。运算符支持 >=、>、<=、<、==，同一 metric 只能出现一次。

指标名来自已选 capability 的 metric_outputs。本地执行器可以由生成程序在 result.json 中报告普通自定义指标，因此选择执行器时页面也允许输入自定义 metric。

打开 Require trusted metric 后，普通求解插件或生成代码报告的同名值不能满足条件；必须由声明了 trusted_metrics 的可信评价插件发布。例如：

balanced_accuracy >= 0.90, trusted required

这适合模型评价，防止被训练程序自行宣称的分数直接结束任务。

6. Research budget

桌面页可直接设置 Actions、Experiments、Failures、Solver calls、Training runs、Training samples、Model calls 和 Model tokens。空白表示“不设置该项”，不是零。打开 Unlimited budget 会移除所有预算上限；这不会移除 capability、策略或验收规则。

建议第一次运行先给出小而足够的限额。到达限额时任务进入 BUDGET_EXHAUSTED，记录不会丢失，可以在控制室增加对应限额并原子地继续。

配置文件还支持 wall time、CPU/GPU hours、Reasoner calls/tokens、代码生成/修复次数和修复尝试等更完整字段，见研究配置文件。

7. Review and start

Review Research Contract 会让 Control API 校验：

• 目标、指标、预算和文件格式；
• capability 是否已启用并可能产生验收指标；
• trusted 条件是否有可信 producer；
• 模型 provider/profile 和路由是否存在；
• workflow、final predictor 和 constraint 是否自洽；
• 上传文件的大小与哈希。

预览中逐项检查插件、能力、所有指标、模型、执行器、路由、输入哈希和 warning。点击 Start Research 后，系统先创建不可变 RunCreated 事件，再启动后台研究循环。若只想创建不启动，应改用 CLI 的 new 或 Control API 的“create”与“start”两个独立调用。

修改验收条件

运行中不能修改。先暂停任务，在控制室 State → Edit acceptance criteria 中从已报告 metric 选择或输入新名称，保存后系统写入可审计 revision 并立即重新评估现有证据。历史终态不会被悄悄改写：已成功任务若不再满足新条件，会显示“在旧条件下完成”的提示。