创建研究任务
新建页默认采用“一句话开干”：写清楚想解决的问题，按需附上数据集、lattice、求解器源码、一个求解器文件夹或其他研究文件，然后直接开始。用户不需要先认识 capability、验收指标或插件清单。这里的“插件”始终指 Scientific Agent 项目插件。
系统仍会在后台生成并冻结一份完整的 Research Contract。已连接的 Scientific Reasoner 先输出一份严格结构化、不带授权的意图草案；确定性控制代码再决定附件角色、capability lease、provider pin、验收条件、预算和交付物。编译计划作为 autonomous-plan.json 保存，使用 autonomous-task-plan-v2 并记录规划来源与摘要，因此语义解读、插件选择和完成条件都可检查、可审计。
默认入口：一句话开干
默认页只要求两个决策：
- 任务描述：最多 32,000 个字符。写清研究对象、希望得到什么、关键数值要求和交付形式。例如“用这份数据寻找候选公式，给出适用范围与可信度，最后写报告”。
- 附件：可选，最多 20 个，每个文件或编码后的文件夹当前最多 10 MiB。文件先暂存并显示大小、哈希和识别类型；所选文件夹保留
directory_bundle身份并只占一个附件名额，ZIP 仅作为内部传输编码；全部就绪后才能开始。
Runtime 会自动采用一套宽松的统一执行上限。当前自主任务至少预留 2,000 次求解器调用和 250,000 个训练样本，并同时保留 action、experiment、失败、模型调用、token 与 12 小时 wall time 的有限保险丝。它只负责限制失控的资源消耗，不选择、暗示或改变研究策略；实际值可在 Control Room 的 Budget 页签审查。
只要应用仍在运行，切换到任务详情、设置等其他页面再返回时，任务描述、附件对象、上传进度和重试身份都会保留在当前会话的内存草稿中；已经暂存的文件不会重复上传。任务创建成功后草稿会清空，重启应用也会清空，因此原始 File 对象不会写入浏览器持久存储。
点击开始后，首页会立即进入 Planning Control Room，后续步骤以 Timeline 展示。Runtime 会严格按以下顺序处理：
- 对附件做有界静态结构分析，生成脱敏附件画像与规范化 capability 摘要；
- 调用已连接的 Scientific Reasoner，把任务描述和这些摘要拆成子任务、数据角色、能力需求、验收建议、置信度和澄清问题；
- 由确定性编译器对照真实项目插件注册表校验草案，决定 capability lease，按插件 ID、版本、operation 和实现摘要固定 provider，并生成有效预算与最终验收/交付合同；
- 只有上述步骤成功后，才会按需安装或启用本地受批准 Catalog 中的项目插件，创建 Run 与不可变输入产物，清理已提交的暂存附件，并进入研究循环；
- 成功后自动准备面向用户的导出包；明确要求可调用工具且已勾选发布权限时，可走受控的 predictor 插件发布流程；若静态画像确认
solver_bundle且已勾选同一权限，则走独立的外部求解器适配插件发布流程。
规划模型不会收到附件原始字节、表格行、源码正文或任意压缩包成员的原始正文，只会收到经过白名单约束和长度限制的静态画像。原生求解器包是一个明确的有界例外：后端最多从 README/usage 文件合计读取 64 KiB，并只检查 ELF、PE、Mach-O 的有界文件头；README 摘要会标成不可信用户文档，只能辅助推断命令行、输入和输出协议，不能成为模型指令或执行授权。画像阶段既不运行二进制，也不整体解压归档。模型输出仍只是语义草案，无权安装/启用插件、选定具体 provider、签发 lease、创建 Run、修改预算或授权执行。附件中的 ZIP 或 Python 文件不会被悄悄当成已有插件。
验收提示始终只是建议。Runtime 会直接从用户原文独立解析指标、比较方向、数值阈值和可信度要求，并在计划 warning 中逐条记录模型提示是被接受还是被拒绝。仅由模型提出、与原文不一致或试图降低可信度的门槛，不能进入最终验收合同。
如果置信度过低或存在阻断性澄清问题，Planning Control Room 会进入“等待输入”，以黄色 Timeline 卡片提出具体问题；用户可以补充信息，也可以明确授权采用合理默认值继续。这是规划输入状态，不显示成 Control API 报错。研究合同被接受前，不会变更插件、创建 Research Run、提交输入产物，也不会消耗训练或打包预算。模型调用或结构化校验失败则保留为可重试的规划失败；Desktop 不会悄悄回退到关键词规则。
模型给出的能力名只用于审计对照。即使名称在 Catalog 中精确且唯一命中，也不能因此新增 lease、选择生成能力、压掉确定性的兼容匹配或触发安装；未被独立推导选中的名称只记录 warning，不会再把清晰任务判成无效。模型自行提出但无法匹配的抽象需求也只作审计记录；只有从已确认意图和可信输入独立推导出的缺失能力才能阻断创建。复用 Runtime 生成代码、发布新的持久插件、降级到有界符号基线分别需要独立勾选相应权限；三个开关默认关闭，绝不从原文关键词推断。首次准备依赖会移出 API 事件循环执行，因此即使 PySR 等环境安装较慢，Desktop 的健康与其他状态接口仍能响应，创建按钮也会显示能力准备阶段。
成功后，autonomous-plan.json 的 planning 对象会记录规划来源、prompt 版本、已校验草案、脱敏模型调用记录，以及只包含 provider、model、context hash、prompt version 的稳定 model_provenance 摘要。顶层 plan_digest 是对编译计划规范化 JSON 计算的 SHA-256，会把这组稳定谱系摘要与 lease、验收门槛、有效预算和交付物绑定在一起；完整调用遥测仍独立保留供审计，其中时延、token、重试和 request ID 等波动字段不进入摘要。
对带标签表格模型，描述中的“误差 5% 以内”会转成可信 relative_rmse <= 0.05；lattice 存活模型是二分类，同一门槛对应可信 balanced_accuracy >= 0.95。只有求解器源码而没有独立数据时，系统无法伪造盲测集：参考求解器误差标记为非可信，计划还会要求 routing_policy_verified >= 1 和 hybrid_speedup >= 1；即使用户没写误差门槛，这两个条件也不会消失。没有数值阈值时，系统同时使用 Runtime 自有的 task_completion 条件；插件和生成代码不能上报它，只有所需交付物与最终 predictor 门槛全部通过后，Runtime 才会记录完成。
求解器基准采用窄化的 reference-solver-benchmark-v1 协议：action 必须引用角色为 reference_solver 的不可变附件、上报全部非 Runtime 验收指标，解析到唯一的一组模型与 inference.source.python，并产出唯一一份预测输出。模型/推理源码既可以由该 action 同时产出，也可以作为前一训练 action 的声明式 Artifact 输入。Runtime 会另行签发 predictor.evaluation 收据，把这些产物、基准结果和求解器的 Artifact ID 与 SHA-256 绑定起来，但收据仍明确标记为非可信。这解决的是最终模型冻结和发布的血缘闭环，并不把 agent 自己编写的基准程序伪装成独立评价器；需要可信误差时仍应提供独立带标签数据。
附件如何使用
CSV/TSV、JSON、Python、常见 lattice 文本、目录和 ZIP 会得到非执行式结构摘要；未知格式保持为不透明附件。Python 只解析语法树，不导入模块；目录会报告识别出的源码成员和确定性允许角色，普通 ZIP 只检查成员元数据，候选求解器还会做上述有界 README/原生文件头读取，但不会执行或整体解压；完整 SHA-256 在写入任务前再次校验。创建成功后，暂存副本会被清理，任务保存的是 ArtifactStore 中的不可变输入。合法暂存文件默认保留 24 小时；损坏、被篡改或 symlink 条目不会被清理器猜测性递归删除。
使用 选择文件夹 时，Web 与 Desktop 都发送 source_kind=directory，后端验证单一根目录并识别为 directory_bundle；固定 ZIP 只承担不可变传输，不再成为业务类型。上传仍强制以下上限：最多 512 个普通文件、编码前合计 50 MiB、编码后最多 10 MiB、路径最多 32 层且 UTF-8 路径不超过 1,024 字节。危险路径、多个根、规范化后重复的路径、读取中发生变化的文件和超限内容会在暂存前拒绝；Desktop 原生选择还会拒绝 symlink 与其他特殊文件。WebUI 支持混合拖入文件和文件夹：普通文件分别暂存，每个顶层文件夹作为一个目录附件；如果浏览器不提供拖入目录项，则改用 选择文件夹。执行时，Runtime 会再次检查归档结构，并把通过检查的 directory_bundle 安全物化为目录；普通项目 capability 与 Local Executor 中的生成程序收到的都是这个目录路径，而不是要求它们自行打开传输 ZIP。
生成程序的命令行参数由 Runtime 统一管理。若 action 声明了 Artifact 输入但没有显式的非空 arguments，Runtime 会按逻辑名稳定生成 --<logical-name> {artifact:<logical_name>} 参数对，并把同一份合同同时交给 Code Author 和 Local Executor；例如 training_npz 会得到 --training-npz。目录 bundle 对应的是安全解包后的目录路径。如果生成或修复后的 Python 通过 argparse 要求了 Runtime 命令中不存在的必填选项，校验会拒绝该源码并在预算允许时触发有限 schema repair，而不会等到执行时才因缺少参数失败。
Web File API 不提供 Unix mode，因此 Web 的目录传输会把条目标为普通非执行文件；这不会阻止受支持的二进制求解器。Runtime 包装器在隔离工作区内通过有界、路径检查的物化后，会确保计划选定的二进制可执行，并且只调用这一路径。Desktop 原生编码会保留普通文件已有的 Unix 执行位。手工 ZIP 仍按 zip_archive 处理；危险路径、重复项、symlink、加密项、膨胀风险或项目插件 manifest 会阻止它升格为 solver_bundle。
表格回归任务会在进入研究上下文之前固定最终盲测分片。Reasoner 只能看到带标签的训练行和不含目标列的最终输入；原始完整标签文件不会保存为研究可见产物，最终标签只对 Runtime 白名单中的回归评价器可见。同一 predictor 的完全相同重试会重放结果，不同 predictor 不能反复探测同一最终标签。当前 CSV 约定把除 sample_id 外的最后一列当作目标变量，请把预期的数值因变量放在最后；Runtime 会把选择记录在 sealed_holdout_targets 中。符号回归会为该目标排序多个公式，但暂不从自然语言改选目标，也不会自动轮流把每一列都当目标。
当前真正可执行的上传 lattice 只接受 data-only UTF-8 Xsuite Line.to_dict JSON（也可位于顶层 line 字段）。MAD-X、Elegant .lte、.seq、.tfs 等文本会被结构化识别，但若没有对应的 *_to_xsuite_json 项目能力，任务创建会明确失败；系统不会猜测转换或执行 lattice 源码。
系统会根据附件与目标分配角色，而不是仅看扩展名。例如：
- lattice 加粒子初值与圈数要求，会优先租用 Xsuite 跟踪能力，并要求模型、报告和使用材料；
- 表格数据加“候选公式、范围、可信度”，会优先租用符号回归、评价与报告能力；
- 求解器源码加“误差 5% 以内的加速工具”，会规划数据生成、训练、显式非可信的参考求解器基准、求解器回退与最终工具交付。
- 带 README 和 ELF/PE/Mach-O 可执行文件的求解器文件夹，在勾选 允许发布可复用插件 后，可规划
file-solver-adapter-v1兼容层、Local Executor 冒烟验证和固定项目插件发布；它不会被误当成需要训练模型的 surrogate。
这些是常见计划，不是固定模板。最终以任务内保存的编译计划和实际启用的 capability 为准。
可复用工具与生成插件
只有任务明确要求“可直接调用的工具”“后续复用”或同类交付时，计划才会要求可复用最终 predictor 和项目插件。训练任务必须先产出符合 file-predictor-v1 的模型、推理源码、精确评价产物和结构化 model card，并通过契约中的评价与交付门槛。成功后，Runtime 的固定 publisher 才能把这些已验收产物封装为带摘要校验的项目插件；安装或导出前，Control 会把冻结模型、推理源码、评价、已接受输出、哈希和状态中的指标逐项与 attestation 对齐。研究 Reasoner 不能直接写插件注册表，也不能把任意上传源码变成插件入口。
发布成功的插件显示为 origin=generated，通过与其他受管理插件相同的安装校验和 worker 启用流程，model card 会让后续任务按附件列名与类型做保守匹配；存在多个兼容候选时不会静默任选。导出包会包含报告、冻结模型、最小调用示例、使用说明，以及发布事件精确绑定的生成插件 ZIP。生成任务可把这些材料分别声明为 MINIMAL_EXAMPLE 和 USAGE_GUIDE；Runtime 只接受 UTF-8、语法有效且包含实际可执行调用代码的 .py 最小示例，使用说明则必须明确覆盖 input、output、domain 和 fallback。未通过校验的文件不会被提交为交付产物，也不能满足完成条件。Artifact type 名称读取时不区分大小写，但保存与 API 输出使用规范拼写。只要求分析报告的任务不会无意义地产生插件。若科学研究成功但插件发布或导出失败，控制室会把“研究成功”和“交付失败”分别显示，不会假装工具已经可用。
生成插件中的 predictor 会在 Linux、macOS 和 Windows 的独立 action workspace 中作为普通子进程执行。Runtime 会过滤凭据环境变量并校验资产摘要、超时和输出大小，但这不是操作系统沙箱；进程仍拥有当前用户的文件系统和网络权限。Runtime 生成的普通本地作业当前申请 8,192 MiB 内存；POSIX 上由 Local Executor 施加进程地址空间上限，并把 MemoryError、分配失败或受限进程的 SIGKILL 归为内存失败。自动生成作业的默认超时会随声明的求解器调用数从 300 秒起增加，最高 7,200 秒；action 显式给出的更严格超时仍优先。
上传的原生求解器走独立的适配器发布闭环。只要静态画像确认 solver_bundle，再勾选现有 允许发布可复用插件 权限即可进入该路径；任务原文即使写了“生成插件”也不能代替这个开关。Code Author 可以依据不可信 README 文档编写一个独立 Python 兼容层，固定接受 --solver-root、--solver-executable、--input 和 --output。合同要求 Local Executor 以普通子进程用文档化的 help/version 或示例命令完成有界冒烟测试，生成绑定精确 solver_bundle_sha256 与 adapter_source_sha256 的通过记录。固定 runtime.solver_adapter.publish 只接受原始 bundle、adapter source 和 validation 三个不可变来源，并校验 validation 声明的通过状态、接口、摘要和 Artifact 谱系；内嵌/外置 attestation 再绑定三者的 Artifact ID、SHA-256 和所有包内文件。Control 在安装前重新校验这些身份，随后走普通的受管理安装和 worker 启用检查；若同 ID/版本已经安装，还要求已安装 attestation 一致。验证记录与 attestation 都不是冒烟测试实际执行的独立证明。
这里的摘要与 attestation 证明的是“发布包来自哪三个精确产物”，不是代码签名或安全结论。ExternalBinarySecurityReviewer 是可替换接口；当前默认策略明确记录为 permissive_deferred，允许继续发布，但 independent_binary_review_performed=false，没有执行恶意软件扫描、签名验证、来源认证或独立二进制安全审查。适配器验证和安装后调用都以当前用户权限作为普通子进程执行。
高级创建：显式 Research Contract
需要亲自选择每个 capability、指标、工作流门槛和预算字段时，使用新建页上的 高级研究合同，或直接访问 /create/advanced。高级页的未完成字段同样会在当前应用会话内跨页面保留，并在成功启动后清空；也可以从历史任务复制配置，但输入文件和全局模型设置不会复制。只有通过服务端预检的契约才能创建和启动任务。
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 并立即重新评估现有证据。历史终态不会被悄悄改写：已成功任务若不再满足新条件，会显示“在旧条件下完成”的提示。