| name | design-xdof-generalization-evals |
| description | Build the XDOF-1000 semantic summary, task-scoped assets, compositional-generalization task library, preset evaluation panels, repeat-resolved task series, and interactive rollout scoring. Use when extracting semantics/assets, generating or labeling tasks, assigning G1-G5/GD, auditing coverage, selecting an evaluation set, generating an evaluation task series, or recording action-event progress. Authorize next-round mutation only for the exact trimmed message “开始下一轮任务生成”, and final candidate-library export only for “收口导出最终候选库”. |
构建 XDOF 组合泛化评测体系
A. 区分当前状态与阶段依赖
A1. 使用三种状态
按以下含义解释本文中的状态，不要混淆“尚未实现”和“尚未定稿”：
| 状态 | 含义 | 执行要求 |
|---|
implemented | 已存在按当前口径生成并验证的产物 | 直接使用；上游变化时重新验证 |
specified | 标准已经确认，但对应产物尚未生成或流程尚未实际执行 | 实现时必须遵守，不得当作待讨论方案随意改动 |
pending | 方向或依赖已知，但参数、方法或结论尚未确认 | 不得自行补造为正式规则；保留占位并等待校准或讨论 |
A2. 当前项目状态
| 阶段 | 状态 | 当前产物或说明 |
|---|
| 任务语义总结 | implemented | ../task_semantic_summary.md；已按资产层级口径重新校准 |
| Task-scoped 资产清单 | implemented | ../task_asset_inventory.md；区分独立资产、可交互组件和非资产 mention |
| 互斥任务资产组 | implemented | ../task_asset_groups.md；组内可用资产与机器注册表一致 |
| Source action evidence 目录 | implemented | references/source_action_evidence.jsonl；覆盖 41 个原任务，引用已按对象/关系噪声筛选 |
| Source relation evidence 目录 | implemented | references/source_relation_evidence.jsonl；覆盖 41 个原任务，记录 source/target、访问状态及人工确认的噪声标签 |
| 各资产组候选评测任务库 | implemented | Round 4 已关闭，Workbench 为 complete；250/250 条人工物理审核通过任务已导出到 ../candidate_task_library/，总览和覆盖报告分别为 ../candidate_task_library.md 与 ../candidate_task_library_coverage.md |
| 人工审核界面 | implemented | 本地 FastAPI 单审阅员页面；支持任务物理审核、可选拒绝反馈、组级汇总、人工 refill plan 轮次总览，以及只审核跨组传播的 global physical rule |
| G1-G5 任务级标签体系 | implemented | 250 条最终候选任务均带逐轴 degree 与任务特定证据，覆盖与 quota 一致 |
B/S/M/K 难度特征 | implemented | 250 条最终候选任务均已由 G vector 和轴间耦合判断得到一致特征 |
GD0-GD3 映射 | implemented | 250 条最终候选任务均已按确定性 profile/K 映射，覆盖为 25/100/80/45；GD4 暂不使用 |
| 预设驱动评测集选择器 | implemented | 从最终 250 条候选库按五种 preset 选择 40/100/150/250 条可复现面板；规模与 GD 为硬约束，其余为能力优先的软平衡 |
| 循环次数确定与评测任务系列生成 | implemented | 8766 按 Library→Preset→Seed 溯源选择评测集，以统一值或逐任务方式确定 N_*，在其 series_and_results/ 下生成完全展开的任务系列 |
| 交互式 rollout 评分 | implemented | 8767 按 Library→Preset→Seed→Series 选择，以 GD→任务侧栏导航，并按整体零进度或完成前沿事件的 1-5 局部分数记录进度；支持断点、多 run、draft 分数预览、部分锁定与克隆续评 |
| 结果聚合目标 | implemented | draft Run 可按需预览已保存结果；locked Run 按任务等权生成总体、GD 与 GD×G 原始/挑战双分数，不使用资产组权重，缺失结果不按0分计入 |
| 能力维度聚合计算 | implemented | xdof_progress_aggregation_v3 对总体/GD 按任务 S 修正、对 GD×G 按当前能力 degree 修正；8767、locked Run manifest 与评分 Markdown 一致 |
若实际产物状态发生变化，先更新本表，再更新对应章节；不要因为标准写入 skill 就把它误标成 implemented。
A3. 按依赖顺序执行
按以下依赖顺序工作，不要跳过尚不存在或未经验证的上游产物：
原始 LeRobot 数据
-> task_semantic_summary.md
-> task_asset_inventory.md
-> agent-authored asset_registry.jsonl
-> source_action_evidence.jsonl + source_relation_evidence.jsonl
-> task_asset_groups.md
-> agent 逐资产组生成候选任务并标注 G1-G5 与难度特征，完成一组即发布
-> 人工与生成并行，按资产组队列逐条接受/拒绝物理可行性
-> accepted pool 覆盖统计与缺口
-> 更新生成约束并按缺口补充，循环至完成或确认结构性缺口
-> 按 preset、候选库 hash 和 seed 隔离的评测任务面板
-> 确定循环参数并展开为评测任务系列
-> 逐 rollout 记录 action-event 完成前沿和任务级进度
-> 按整体难度和泛化能力聚合的评测结果
把前三份 Markdown 视为数据理解层，把候选任务库、标签和评测集视为评测设计层。上游口径改变时，检查并更新所有受影响的下游产物。面向用户的完整操作、恢复方法和验收清单见《XDOF-1000 组合泛化评测系统用户手册》。
原始数据根目录固定为：
/mnt/xdof_1000/Potato/yam_202605_lerobot
将正式分析产物写到本 skill 父目录。候选库运行状态写入 ../candidate_task_workbench/，最终机器可读任务写入 ../candidate_task_library/。使用本地程序完成文件枚举、JSONL/parquet 读取、计数和一致性校验；由当前 agent 完成语义归纳、实体消歧和标签判断。除非用户明确授权，不要调用外部 LLM 或把数据发送到外部服务。
B. 已实现的数据理解流程
B1. 生成 task_semantic_summary.md
B1.1 枚举和抽样
枚举数据根目录下所有包含 meta/tasks.jsonl、meta/episodes.jsonl 和 episode parquet 的 coarse task 目录。每个 coarse task 独立处理，不用一个任务的标签解释另一个任务。
默认对每个任务均匀抽取 5 条 episode：首条、约 1/4、中间、约 3/4、末条。数据量过少时去重索引，并记录实际样本数。当前 41 个任务的既有总结共检查 41 x 5 = 205 条 episode；除非数据集发生变化或用户要求，不要重新随机抽样。
B1.2 恢复真实 subtask sequence
不要把 meta/episodes.jsonl 的 tasks 数组当作时序序列；它只是该 episode 出现过的标签集合，且会丢失重复次数。按以下方式恢复顺序：
- 读取 episode parquet 中逐帧的
task_index。
- 用该任务
meta/tasks.jsonl 中的 task_index -> task 映射还原文本。
- 对连续相同的
task_index 做 run-length compression，只保留段落顺序。
- 保留非连续重复，以恢复多物体循环和反复操作。
- 过滤控制、复位和质量标签，再归纳语义事件。
默认过滤以下裸标签或纯控制操作：
reset both arms
mistake
adjust
trim
Arm the device.
仅过滤完全等于 adjust 的裸标签；保留 Adjust the insole in the shoe 等带有明确对象和任务语义的动作。不要仅因文本含 distractor 就过滤：如果移除非目标物是建立正确初态或最终内容所必需的步骤，例如从咖啡胶囊篮中移走非胶囊物体，则保留。对其他疑似控制标签逐条判断，不要用过宽的关键词删除有效动作。
B1.3 归纳任务语义
综合 coarse task 名称和 5 条抽样 sequence，提取：
- 代表性核心 subtask sequence；
- 多物体循环，用
(... ) x N 表示；
- 一句话任务语义，包括操作对象、主要交互和最终目标；
- 标注粒度变化、别名、缺失目标和异常/污染 episode。
代表性 sequence 是跨样本的语义归纳，不是任选一条 episode 的逐段复制。若不同 episode 是同一物理任务的粗细两套标签，合并语义并记录粒度差异；若出现真正不同的任务内容，标记污染，不把它并入核心语义。
当 subtask 文本不足以恢复目标时，明确写出未知项，不自行补造。例如目标单词、颜色到容器的映射、旋钮档位或精细折纸步骤未被标签编码时，应保留这一限制。只有在需要消歧且用户允许时才检查图像/视频，并注明视觉证据。
B1.4 输出和校验
在 ../task_semantic_summary.md 中输出每任务一行的总表，至少包含 Coarse task、示例 subtask sequence 和 任务语义，再单列数据质量与解释注意事项。校验：
- 数据目录中的每个 coarse task 恰好出现一次；
- 没有多余或重复任务；
- 每个任务都有 sequence、语义和抽样覆盖记录；
- 已知异常 episode、循环丢失风险和文本无法表达的目标均被保留。
B2. 生成 task_asset_inventory.md
严格使用两步法：
task_semantic_summary.md
-> 确定任务意图和核心资产
每个任务完整 meta/tasks.jsonl
-> 找全所有原始物体 mention，并补充核心以外资产
不要为找资产而读取全部 episode sequence，也不要仅依赖语义总结中的示例 sequence。示例足以确定意图和初始核心资产，但全量 tasks.jsonl 才是原始物体 mention 的覆盖基准。
B2.1 提取和规范化资产
逐任务扫描完整 meta/tasks.jsonl 的所有 task 文本，提取物理实体及有独立事件证据的实体组件。完整判定流程、反例和注册 schema 见 asset_interpretation.md；生成或修订资产清单时必须先读该 reference。
只在同一任务内部规范化：
- 合并拼写错误、大小写、单复数和明确同义词；
- 把
folded skirt、rolled towel 等状态变体归回实体；
- 不把位置、形状、状态和区域另建资产，如
top corner、wrinkles、opening of the pillowcase；
- 将资产形态分为
independent_asset 和 interactive_component；后者必须有独立充当 action object/tool/source/target/goal participant 的原始证据，并记录父资产和 interaction mode；
- 将只出现于父物体描述中的从属名词归为
contextual_qualifier，不建立资产 ID；trash bin with a bag inside 整体建立为 trash_bin，机器层可记录 bag_inside，但资产清单及人可见任务文本必须保留该原始表述；
- 对无法消歧的
object、item 等只保留为 non_asset_mentions 中的 annotation placeholder，不猜成具体物体，也不建立可生成资产 ID；
- 对串任务污染中的实体保留 non-asset mention 并明确标注“污染”，但不得将其注册为该 coarse task 的资产；
- 类别/集合泛称若只是已注册实例的上位词，不额外建立一个
generic_* 物体实例；
- 分开验证“物体存在”“核心性”“来源/目标角色”：某容器被单独移动只能证明它存在，不能证明其他物体从中取出；
- 同一任务中的近义容器只有在不存在共现/关系反证时才能合并。若原始标签同时区分二者或描述二者间关系，如
roll_the_ties 的 storage box 与 bin，必须建立不同资产；
- 原始标签仅写泛称时，canonical name 保持原始可证名称，不用常识补成更具体的部件名，如不得把咖啡机的
container 改称 capsule holder。
- 资产身份与拓扑是两层信息。所有
interactive_component 还必须记录 allowed_primary_actions、independently_relocatable、content_region 和 content_access_requires；父子关系不能只作为 UI 注释。
articulated 与 fixed_control 默认固定在 parent 上，不得独立 pick/remove/place。detachable 只有在原始证据或用户基于实物确认后才可拆装；原始标签与已确认实物结构冲突时，将标签列入 relation evidence 的 noisy evidence，不用它扩展任务。- 固定 component 的 content region 可以作为物品 source/target，但必须先满足访问状态。父装配体与固定子区域不是两个并列容器，禁止无证据的
parent container -> child content region 或反向转移。
- 嵌套独立资产与固定 component 必须区分。
inner container 可从已打开的 surgical kit 取出并更新位置；AG09 drawer 和 paper-box box lid 则不可独立移动。
B2.2 区分核心和非核心资产
将以下资产标为核心：
- 完成任务目标直接需要的操作对象、工具、目标容器或装置；
- 仅用于提供初始物体的来源容器，如袜子任务的
bin、圣诞树任务的 storage box；
- 原始
tasks.jsonl 明确出现的任务特定临时放置、辅助承载或支撑物，如翻煎饼任务的 tray、衣架任务的 clothesline。
不得根据 coarse task 名称、日常场景常识或“通常会有”补造资产。尤其不能因任务涉及枕头和枕套就推断存在 bed；该任务原始标签只支持 workspace board/table。资产缺少原始 mention 时，只有用户基于实物明确确认后才能登记，并需记录人工证据来源。
将以下真实且可消歧资产标为非核心：
- 通用工作区
workspace board/table/surface，除非工作面本身就是任务处理目标；
- distractor；
- 虽被提及但不属于任务核心流程的可选或外围物体/组件。
污染物和无法消歧泛称不是“非核心资产”，而是非资产 mention。外围容器即使真实存在，也不得在没有关系证据时被候选任务用作其他物体的来源或目标。
来源容器和任务特定临时承载物不得仅因“可替换”或“不出现在最终状态”而降为非核心。这是当前核心/非核心口径中的明确结论。
B2.3 保持 task scope
给资产使用以下逻辑身份：
xdof_1000::<task_id>::<canonical_local_asset_name>
同名资产在不同任务中必须是不同条目。禁止把整个数据集的资产 merge 成一张去重后的全局物体表；最终文档必须按任务单独列出核心和非核心资产。
在 ../task_asset_inventory.md 中为每个 coarse task 建立核心资产、非核心资产和“非资产 mention / 状态”三行。同步维护 asset_registry.jsonl，保证 41 个 source task 和所有 task-scoped 资产一致。
B3. 生成 task_asset_groups.md
以完整 coarse task 为不可拆分分组单位，根据主要主题、场景和资产可共同布置性，把任务及其全部 task-scoped 核心/非核心资产合并为若干任务资产组。
遵守以下约束：
- 一个任务只能进入一个资产组；
- 不拆分任务，也不把一个任务的不同资产分到不同组；
- 分组依据是任务主要意图和执行场景，不是单个同名资产；
- 跨场景任务按主要目标选择唯一归属，并记录有歧义的决定；
- 组内可以汇总 task-scoped 资产集合，但仍不得按 local name 合并跨任务同名资产；
- 新任务加入时优先扩充语义匹配的现有组，只在确有独立场景时新增组。
在 ../task_asset_groups.md 中先输出资产组总览，再为每组逐任务列出核心和非核心资产。当前 41 个任务已经形成 10 个互斥组；除非数据或分组口径改变，沿用已有 AG01-AG10 ID。
设原任务集合为 T、各组任务集合为 G_i，必须验证：
union(G_i) = T
G_i intersect G_j = empty, for all i != j
同时验证每组的资产集合仅是成员任务的 task-scoped 资产并集，不产生跨任务 identity 合并。
C. 已确定的评测规范
本部分规则均已确认，规范状态为 specified；对应产物是否已经执行以 A2 为准。新增或修订候选任务、标签和正式评测集时必须继续遵守这些规则。
C1. 固定评测标注口径
将一个完整评测任务作为唯一标注单位。可以分析任务中的事件、子任务和状态变化来获得证据，但不要给每个子任务单独建立一套正式标签。
允许一个评测任务同时具有多个泛化能力标签。对每个能力分别给出 0-3 的偏移程度，再由活跃能力数量、各能力程度和能力间耦合派生整体泛化难度。不要把“泛化能力类型”和“整体难度等级”合并成单一类别。
只使用以下五个主要泛化能力：
G1_entity_role_binding：实体—角色绑定泛化。G2_local_interaction：局部交互泛化。G3_local_state_transition：局部状态转移泛化。G4_cross_event_dependency：跨事件依赖泛化。G5_goal_constraint：目标约束泛化。
暂不把语言表述、场景/视觉变化、纯物理执行难度设为泛化能力标签。必要时把它们记为控制变量或审计备注，避免污染主标签。
C2. 使用数据基准
先读取以下相对本 skill 的文件：
../task_semantic_summary.md：确定 41 个已有任务的意图、典型事件和语义。../task_asset_inventory.md：确定每个原任务的 task-scoped 核心与非核心资产。../task_asset_groups.md：确定 10 个互斥资产组及任务归属。references/asset_registry.jsonl：确定候选任务可引用的唯一机器资产白名单。
原始数据位于 /mnt/xdof_1000/Potato/yam_202605_lerobot。当“某个交互、状态转移或依赖是否已出现”无法从语义总结可靠判断时，检查相关任务的完整 meta/tasks.jsonl，不要只依赖示例 sequence。
以整个原始数据集为已见基准，而不只以候选任务所属资产组为基准。资产组用于约束可用资产和组织评测系列；泛化偏移则相对于全部已有任务判断。
保持资产身份为：
xdof_1000::<source_task_id>::<canonical_local_asset_name>
不要因为两个原任务中的资产同名就把它们视为同一条资产记录。一个候选评测任务只能属于一个资产组，但可以组合该组内不同原任务的 task-scoped 资产。
C3. 建立任务表示
把原任务和候选任务都抽象为任务图：
Task = (entities, roles, interactions, transitions, events, dependencies, goals)
entities：参与任务的具体 task-scoped 资产。roles：source、target、container、tool、support、item 等任务语义角色。interactions：角色归一化后的局部动作/关系原子，如 insert(item, container)。transitions：单个事件内部的 (object_or_relation, state_before, action, state_after)。action_event_sequence：完成任务所需的有序语义级原子动作事件；只作为任务级判断证据，不单独打标签。dependencies：事件间必需的 precedence、enablement、condition、loop 或 recovery 边。goals：最终状态谓词及其合取、计数、排序、空间或容差约束。
每个 action event 只允许一个 action predicate，并只操作一个物体实例；事件文本必须写明该物体及完成动作所需的来源、目标或意图关系。把 pick up and place、insert and align 等复合动作拆开，禁止用 insert three flowers、place every item 等集合动作掩盖实例级事件。多实例操作使用 {"repeat": 3, "action_events": [...]} 或 {"repeat": "N_<class>", "action_events": [...]}；正整数表示确切次数，N_<class> 表示场景中全部适用实例，重复块是控制结构而不是 action event。人审时渲染为 (event_A -> event_B) x 3/N_<class>。
sequence 必须覆盖 instruction 所需的完整操作链；递归检查重复块内事件仍满足单动作和单实例规则。sequence 的书写顺序不自动等于 G4，只有任务必需的新依赖才标 G4。
为每个候选任务找到一个或多个最接近的原任务作为 source_anchors。记录：
single_anchor：主要由一个已有任务派生。multi_anchor：组合两个或更多已有任务的成分。
source_scope 是结构描述，不是额外泛化能力。不要仅因 multi_anchor 自动提高任一 G 标签；应检查到底改变了哪些任务图成分。
C4. 判定五种泛化能力
G1：实体—角色绑定泛化
判断已有实体类别或具体资产是否被绑定到未见的任务语义角色。比较时固定抽象交互和目标，关注“谁承担什么角色”。
- 新物体替代已见 source、target、container、tool 或 support 角色，标记 G1。
- 仅改变颜色、位置、数量或同类实例，不自动构成 G1。
- 新角色绑定同时带来新交互时，可同时标 G1 和 G2，但必须分别给出证据。
G2：局部交互泛化
判断角色归一化后的局部动作或关系原子是否为新组合。关注“两个角色如何交互”，而不是具体由哪个物体承担角色。
- 新的
action(role_a, role_b[, tool]) 或新局部空间/接触关系，标记 G2。
- 只更换执行同一交互的实体，通常只标 G1。
- 只改变交互前后的状态语义，而交互算子本身已见，不自动标 G2；检查 G3。
G3：局部状态转移泛化
判断单个事件内部的状态转移是否未见：
(object_or_relation, state_before, action, state_after)
G3 关注一条局部状态转移边，例如从 unseated 变为 partially_seated。单事件任务也可以具有 G3。
- 不要仅因多个已见转移被排成新顺序就标 G3。
- 不要仅因动作名称新颖就标 G3；必须明确前状态和后状态的变化。
- 关系状态也可作为状态，如
separate -> connected 或 open -> sealed。
G4：跨事件依赖泛化
判断两个或更多事件之间是否出现未见的任务必需依赖：
(event_A, dependency_type, event_B)
依赖类型包括 precedence、enablement、conditional branch、loop、recovery 等。G4 关注事件之间如何连线，而不是事件内部如何改变状态。
- 若各局部转移都已见，但必须按新的先后或使能关系组合，只标 G4，不标 G3。
- 若局部转移和事件依赖都新，可同时标 G3 与 G4，并分别引用证据。
- 文本中出现
then 不等于 G4。只有任务语义、成功条件或物理约束要求该顺序时才算依赖。
边界示例：若“插入插头”和“旋转旋钮”都已见，而新任务要求插头完全就位后才允许旋转旋钮，则局部转移可为 G3=0，新的使能边属于 G4。若任务还要求一个从未见过的“部分插入并锁止”状态转移，则同时具有 G3。
G5：目标约束泛化
判断最终成功状态的谓词或谓词组合是否未见。关注“最终必须同时满足什么”。
- 新增计数、排序、分组、精确空间关系、状态合取或容差约束，标记 G5。
- 只改变执行顺序而最终目标不变，不自动标 G5；检查 G4。
- 目标谓词相同但换了实体绑定，通常检查 G1，而不是自动标 G5。
C5. 标注每种能力的偏移程度
对每个 Gi 独立给出整数程度：
| 程度 | 统一含义 |
|---|
0 | 该维度没有相对原数据的实质偏移。 |
1 | 一个局部、直接、证据清晰的新原子或新绑定。 |
2 | 同一维度有多个新原子，或一个跨多实体/关系的显著新组合。 |
3 | 该维度出现系统性、条件性、嵌套或强耦合的新结构。 |
使用下列维度特定准则校准统一定义：
| 标签 | 1 | 2 | 3 |
|---|
| G1 | 一个实体—角色新绑定 | 多个新绑定或角色互换 | 多角色协同且绑定相互制约 |
| G2 | 一个新局部交互原子 | 多个新交互或多实体交互 | 条件性/工具介导/强耦合交互系统 |
| G3 | 一个新局部状态转移 | 多个新转移 | 多资产联合关系状态的复杂转移 |
| G4 | 一条新依赖边 | 多条新边或新 DAG | 条件分支、循环、恢复或嵌套依赖 |
| G5 | 一个新目标谓词 | 多个新谓词或新合取 | 全局、条件性或高耦合目标约束系统 |
程度表示相对于已有数据的语义偏移，不表示机器人运动有多难，也不直接等于子任务数量。每个非零程度必须附带：
- 候选任务中的新成分；
- 对照的 source anchor；
- 为什么不是相邻的其他 G 标签；
- 能定位到原始 sequence 时给出相应证据。
C6. 记录整体难度特征
先记录以下充分统计量：
d = [d1, d2, d3, d4, d5]
B = count(di > 0) # 泛化能力广度
S = sum(di) # 总偏移量
M = max(di) # 最大单轴偏移
K in {0,1,2,3} # 活跃泛化轴之间的耦合程度
按以下标准标记 K：
K0：各非零轴可以独立理解；若 B < 2，固定为 K0。K1：多个新成分共享实体或角色，但没有必需依赖。K2：一个泛化成分使能或约束另一个泛化成分。K3：泛化成分之间存在条件、嵌套、反馈或恢复式耦合。
不要混淆 G4 与 K：G4 描述任务事件之间的新依赖；K 描述多个活跃泛化能力之间是否相互依赖。
将 B/S/M/K 作为已确定的任务级难度特征，并按以下结构确定性映射整体泛化难度：
GD0：B0。GD1：B1-[1]；或 B2-[1,1] 且 K0。GD2：B1-[2]；B2-[1,1] 且 K1；或 B2-[2,1] 且 K0。GD3：B1-[3]；B2-[2,1] 且 K1；或 B3-[1,1,1]。
核心库只允许 K0/K1；B1 固定 K0。禁止 B2-[2,2]、B2 中 degree 3、B3 中 degree 2/3、B4/B5。overall_level 必须等于 quota slot 的确定性 GD，不再使用 pending_calibration。GD4 暂不进入核心候选库或正式集。
整体泛化难度不得混入纯物理执行难度。另记 execution_difficulty_note，用于提示精细操作、可达性、遮挡、柔性物体或长时程执行风险，但不参与当前 G 标签和 GD 派生。
C7. 生成候选任务库
优先采用“先广泛生成候选任务库，再按标签选择评测集”的模式。只有在标签覆盖出现明确缺口时，才定向生成指定标签组合的补充任务。
C7.1 生成任务语义
用一句中文 task_semantics 概括完整主目标，只引用 proposal 中登记资产并保留 canonical 表述。使用完成主目标的最小资产集合，不补造 affordance、属性、初态、容量或 contextual qualifier；生成前按资产注册表、拓扑和 relation evidence 建立初始状态图。数量、方向、状态形容词、重复次数和同义措辞不构成新任务；核心资产、source/target、action chain 和定性 goals 相同即视为重复。详细生成与去重规则见 candidate_workbench.md。
C7.2 生成 Task instruction
用一条英文祈使句给出完整任务总 prompt，明确 canonical source、target、tool、container 和成功约束，但不展开成低层脚本，也不写 G 标签或评测解释。只有场景保证时才写精确数量，不假设未建立的初态或关系。instruction 的每项要求必须同时出现在 task graph/final goals 和人可见 event text 中；按 task_representation_consistency.md 审查数量、关系、状态、顺序和完整性。
C7.3 生成 Action event sequence
Action sequence 使用 stateful_v2 + evidence_grounded_v1 + topology_grounded_v1。每个事件由 agent 同时编写一个 action、一个主要实例的自然语言 text 与结构字段；拿取/拆离和放置/安装分开，所有必需开合、中转、工具切换、最终放置和显式空间关系必须完整出现。重复块用整数或 N_<class>，每轮包含单实例完整链且不泄漏抓持。Core action 与所有 source/target 关系必须提供可回查 evidence；状态连续性、父子拓扑、区域访问、双臂抓持和动作族必须一致。详细 schema 见 candidate_workbench.md、action_language.md 与 task_representation_consistency.md。
C7.4 校验三者一致性
逐任务双向检查：语义概括 instruction；instruction 每项要求均由 sequence、task graph 和 goals 实现；sequence 不含额外任务。冲突时修正任务设计，不用措辞掩盖，也不由脚本从一个字段模板化生成另一个字段。机械校验不能替代 agent 语义复审。
C7.5 采用多轮人工物理可行性闭环
候选库目标为 250 个经人工接受的 quota slots，资产组任务数为 20/28/20/30/30/30/35/18/27/12。GD0/GD1/GD2/GD3 为 25/100/80/45，B0/B1/B2/B3 为 25/138/70/17。完整 group incidence、profile、K、逐轴 degree 和 degree-3 placement 以 evaluation_design_v2.md 与 references/quota_v2.json 为准。
每个 slot 直接记录 profile_class、target_G_profile、target_K 和 target_GD。调度器只能求解这些精确配额，不得通过软成本自行决定 breadth、K 或 GD。Agent 生成任务时使用完成单一主目标所需的最小资产集合，不追求单任务覆盖组内全部资产；不为满足 G4/G5 人为增加中转、复位、精细布局或独立子任务拼接。
每组发布前必须执行两层多样性检查：第一层以 quantity-invariant semantic_fingerprint 硬性排除同一核心任务；第二层查看共享 action template、source/target pattern 或 goal structure 的高相似簇，由 agent 判断是否只是换物体或叠加无关目标。硬重复不得发布，高相似簇只在确实评测不同 G1-G5 成分且证据独立时保留。
逐资产组生成任务并完成实际 G 标签后，只把新 proposal 放入 pending_feasibility_review。审核服务在整个生成阶段持续运行；agent 每完成一组就发布到有序审核队列，不等待当前组审核，可继续生成其余组。网页无队列时显示“暂无审核需求”并自动轮询；始终审核队首资产组，提交该组后锁定决定并自动进入下一组。读取 candidate_workbench.md 并严格使用其中的队列状态机、反馈 schema、并发写入边界和命令。逐任务界面展示任务语义、instruction、按原始 source task 分组的 Assets 来源，以及 action-event sequence；资产来源表示身份出处而非 source_anchors，component 必须显示注册 parent，同名跨任务资产不得合并。workspace_board 仍是任务内部可引用的真实支撑资产，但为了减轻审核负担不在 Assets 来源卡片中显示。人工选择：
human_feasibility_accepted：实际资产和机器人条件支持这些交互与状态；human_feasibility_rejected：语义上可以描述，但实际资产或执行条件不支持。
拒绝时可选填写“拒绝原因”和“下一轮建议”，二者均非必填，不选择问题 event。全组决定完成后先查看拒绝汇总，再提交并生成组级 JSON/Markdown 反馈报告。所有拒绝都保留最小结构签名；非空人工原因和建议固定为原资产组的 active reviewer guidance。Agent 可从同组反馈提炼 derived_group_constraint，通过来源与 accepted-conflict 检查后在该组自动生效；只有拟跨 AG01-AG10 传播的 global_physical_rule 需要网页人工选择“批准全局生效”或“保持组内生效”。完整作用域、审核和 schema 见 feedback_scope_and_global_rules.md。人工接受不代表人工审核了 G 标签、任务图或文字质量。
后续轮只补 accepted pool 的空 slot，已接受任务不重复展示。某组填满后自动停止；未填满组由人工在组级汇总和轮次总览选择 continue_refill 或 pause_refill。接受率和 slot 尝试次数只作统计，不触发停止。pause_refill 不关闭 slot 且持续到人工恢复；continue_refill 只决定下一轮。Agent 发布完本轮任务后必须运行 seal-round-generation；只有 generation sealed、队列为空且全部批次提交后才显示轮次总览。计划确认前可修改，确认后 close-round/prepare-next-round 才能继续。若所有缺口组暂停，只有网页二次人工确认才能 complete_with_gaps。完整状态、API 和幂等规则见 candidate_workbench.md。
只有最新用户消息去除首尾空白后严格等于“开始下一轮任务生成”时，才完整读取并执行 next_round_generation.md 与 feedback_scope_and_global_rules.md。任何前后缀、别名、讨论或状态询问都不授权写操作。获得精确授权后先运行幂等的 prepare-next-round；若本轮未 sealed 或 refill plan 未确认，暂停并提示用户完成对应步骤。收口与反馈分析完成后，下一轮简报只包含选择继续的资产组。完成一个 active 资产组即发布，继续生成其他组而不等待审核，全部发布后 seal 本轮。
只有最新用户消息去除首尾空白后严格等于“收口导出最终候选库”时，才完整读取并执行 finalize_candidate_library.md。该入口只关闭已经完成审核的候选库、标记 Workbench 完成、导出并验证候选库；不得运行评测集选择器。任何近似表达只允许讨论或只读检查，不授权 finalize-library。
若一个“全部已决定但未提交”的批次因 action sequence 规范升级而整体修订，使用 revise-completed-batch：旧反馈和拒绝签名被保存，新批次清空决定并显示 prior-review 状态；此前接受只允许保持任务语义、instruction、slot、G 标签和难度不变后细化序列。批次提交必须携带 batch_id，同一 ID 可幂等重试。
若一个尚未提交的活跃批次需要因全局动作语言规范升级而统一重审，使用 revise-active-batch：替换后的 proposal 必须保留 ID 和 slot，旧暂存决定会清空并写入 prior_review，页面从 P001 重新审核。该命令不能改动 accepted pool 或已提交反馈。
C7.6 保持 agent 与脚本的职责边界
使用以下已实现工具：
scripts/candidate_workbench.py：生成纯 quota slots、导入 agent proposals、提交批次、计算覆盖、终止和导出；scripts/review_app.py：在 127.0.0.1 提供任务物理审核、可选拒绝反馈、组级汇总，以及仅针对 global physical rule 的跨组生效审核；scripts/validate_candidate_workbench.py：只读校验 workbench。
Quota slot 只能包含 slot_id、资产组、控制标记、profile class、目标 G profile、目标 K/GD、generation band、priority 和静态 status。脚本不得读取三份数据理解文档来生成任务，也不得产生或修改语义、instruction、action events、task graph、source anchors、G 标签或证据。Agent 必须相对全部 41 个原任务判断实际 profile；不匹配目标 slot 时移动到匹配空 slot 或重写任务，不得迎合配额强行解释。
C8. 输出任务级标签
每个候选任务至少记录：唯一 ID、唯一资产组、instruction、task semantics、带来源和角色的 task-scoped assets、原子 action-event sequence、final goals、source anchors/scope、完整 task graph、G1-G5 degree 与证据、B/S/M/K/GD、semantic signature、执行难度备注、生成轮次/目标 slot，以及 pending_feasibility_review | human_feasibility_accepted 状态。完整字段定义见 candidate_workbench.md；被拒任务不作为完整候选任务保存。
计算字段必须与五个 degree 一致。若所有 degree 都为 0，该任务是已见能力的复现/控制任务，可保留为 GD0 候选，但不要宣称它评测新泛化。
C9. 审核标签
逐任务检查：任务级标注单位和事件原子性；资产来源/角色/唯一组；最近 source anchors；G1/G2、G3/G4 和 G5 边界；每个非零 degree 的独立证据；B/S/M/K 一致性；是否误把语言、视觉或纯物理难度计入 G。证据模糊时回查完整 tasks.jsonl 并降低 label_confidence；低置信度任务不进入正式评测集。
C10. 构建评测集并定义聚合目标
完整 250 条候选库形成后，使用 list-eval-presets 查看 quick-diagnostic、standard-balanced、generalization-stress、extended-balanced 和 full-library，再用 select-eval --preset <id> --seed <n> 生成面板。只有任务数与 GD 分布是硬约束；选择器依次优化 G1-G5 degree 平衡、资产组/profile 参考分布以及 source anchor、资产和序列长度多样性。相同候选库、preset 和 seed 必须可复现，不同面板按候选库 hash/preset/seed 共存。完整算法、规模、产物和比较口径见 evaluation_design_v2.md；机器配置见 evaluation_presets.json。
选择面板后，按 evaluation_series_and_scoring.md 使用 8766 依次选择 Library→Preset→Seed，在具体 <evaluation-set>/series_and_results/ 内确定 N_* 并生成完全展开的评测任务系列；Dashboard 采用单一创建入口，已有 Series 可只读折叠查看，并仅在完整 ID 二次确认后级联删除其 Run。8767 依次选择 Library→Preset→Seed→Series 后创建模型 run；draft Run 可安全重置，draft/locked Run 仅在完整 ID 确认后永久删除，locked Run 的修正仍通过克隆。当前步骤只确定循环次数，不规定背景、光照或物品初始位姿。单次 rollout 可记为整体零进度，或以完成前沿事件 N 和当前事件分数 s in 1..5 计算 ((N-1)+s/5)/T；任务分数先对其 rollout 算术平均。源评测集四个核心文件不可改写。
Draft Run 可以按需计算 xdof_progress_aggregation_v3 阶段性预览；预览只使用已经点击“保存本次 Rollout 并继续”的 results，即时暂存 drafts 不进入预览，也不写入 Run manifest 或评分 Markdown。面板打开时，后续每次正式保存 rollout 都刷新预览。没有已保存结果时不生成预览。
Run 可以在未完成全部 rollout 时锁定。锁定前必须选择 exclude_missing 或 fill_zero：前者要求至少一个已保存结果/有效暂存，并把缺失项排除出聚合；后者把全部缺失项标为系统补零、按0进度计入。锁定事务先转存暂存再应用策略，并在 state、manifest、Markdown 和聚合中记录策略及补零数。人工整体零进度不得与系统补零混淆；锁定后原 Run 不可修改，克隆时系统补零项恢复为未评测以便继续。
任务先对已有 rollout 进度算术平均；没有任何结果的任务标为未评测，不进入总体、GD 或 GD×G 分母，也不按0分处理。总体、GD 和 GD×G 均以任务等权，不读取或修正资产组，也不按活跃能力数拆分任务权重。一个多标签任务完整进入所有 degree>0 的对应能力桶；无有效样本的 GD/能力单元和 GD0 的 G1-G5 为 N/A。聚合必须同时报告计划/实际任务数、计划/已完成 rollout 数以及完整/部分覆盖状态。
总体、各 GD 和每个 GD×G 单元均输出原始平均进度分与挑战达成分。总体/GD 以任务总泛化负荷 S=sum(degree_g) 修正，S0/S1/S2/S3 的 (weight,exponent) 固定为 (1,1)、(1,1)、(1.25,0.8)、(1.5,2/3)；GD×G 只使用当前能力轴 degree，degree 1/2/3 使用后三组参数。挑战分公式均为 100*sum(w*P_t^gamma)/sum(w)；它是挑战达成指数而非实际 action-event 平均进度。全失败为0、全成功为100，GD0 挑战分等于原始分。能力单元任务数 0/1-2/3-4/>=5 分别标为 not_applicable/low_support/limited_support/supported。
该聚合描述当前已观测结果下的条件表现，不构成单个能力的因果归因。本期不定义完整覆盖与部分覆盖 Run 之间的可比性规则，也不计算 coverage fingerprint、置信区间、显著性或 B/K/Profile 聚合。完整 schema、页面与文件口径见 evaluation_series_and_scoring.md。
C11. 满足最小交付要求
任何交付都必须给出候选任务及唯一资产组、task-scoped 资产角色、source anchors/scope、G1-G5 degree 与证据、B/S/M/K、执行与可观察性说明、人工物理审核状态，以及 accepted pool 的覆盖统计和结构性缺口。
D. 待校准和待讨论事项
本部分属于 pending。只记录已经明确的依赖和约束，不提前填写未经数据或讨论支持的参数。
D1. 未来 GD4 挑战扩展
GD4 不属于当前 250 条候选库或五种 GD0-GD3 评测预设。只有用户后续明确要求挑战集时，才单独定义允许的 B4/B5、K2/K3 或更强耦合结构；不得把它们混入当前核心分数。
D2. 未来统计区间与高级比较
当前确定性聚合已经按 C10 实现。置信区间、同 Series 配对显著性、多因素统计模型和跨 Series 标定仍为未来扩展；未经单独确认不得改变 xdof_progress_aggregation_v3 的任务等权、缺失结果排除、双分数或 S/degree 参数。
E. 维护已确认口径和状态
把本 SKILL.md 作为该项目流程、细节和结论口径的操作性单一事实来源。后续讨论中，当用户明确表示某项方案“定下来”“没问题”“按此执行”或要求写入口径时：
- 将结论更新到对应工作流、定义、边界、schema 或审核清单中；
- 同步修改受影响的上下游规则，避免正文、示例和输出格式互相矛盾；
- 只把已确认结论写入 B 或 C，把尚在讨论的方案放入 D 并标为
pending；
- 若新结论推翻旧结论，替换旧口径而不是并列保留冲突版本；
- 若 skill 的触发范围发生变化，同步更新 frontmatter description 和
agents/openai.yaml；
- 实际产物完成、规范确认或 pending 项解决时，同步更新 A2 状态表；
- 每次实质更新后运行
quick_validate.py，并检查无 TODO、任务数一致、公式字段一致。
不要在 skill 中堆叠对话记录或冗长决策历史；保留最终可执行结论、必要边界和能防止误标的最小示例。
