pipeline-eval-report

Pipeline Eval Report

把一次真实 pipeline 执行转成可复核的质量、成本和归因证据。正确性门禁先判断产物能否指导下游正确完成任务；Token、耗时和文档体积随后用于比较效率。

产物

每个评测 run 写入 pipeline-data/runs/{pipeline_run_id}/：

• manifest.json：任务、版本、执行器、输入与被评产物的静态身份。
• events.jsonl：追加式阶段事实、评分、门禁和知识事件。
• telemetry.json：模型调用、Token、费用、耗时、工具和 phase 归属。
• grading.json：rubric 分项结果、P0/P1/P2 扣分及证据。
• evaluation-report.md：面向人的精简结论。

历史引导 run 使用 storage_profile: bootstrap-json-v0，只保留 manifest.json 与 events.jsonl 作为进化账本。新建评测 run 一律写齐上述五个核心文件；validator 对 bootstrap profile 执行只读兼容校验。

关键失败、扣分和优化依据写入 pipeline-data/knowledge/entries/{knowledge_id}.json。完整字段和一致性规则见 references/artifact-contract.md；报告渲染前读取 assets/evaluation-report-template.md。

最短路径

1. 先判定 run 身份并创建或续用 pipeline_run_id。
2. 冻结题面、rubric、skill 和候选产物的路径、版本与 SHA-256。
3. 从 Mavis 或其他 provider 真源提取完整执行遥测。
4. 按 rubric 逐项检查语义，记录可定位证据。
5. 应用正确性门禁，定位问题最早进入 pipeline 的阶段。
6. 写五类 run 产物和知识条目。
7. 运行 scripts/validate_run.py，通过后交付报告路径与结论。

1. 判定 pipeline run

将以下行为登记为 pipeline run：

• 生产任务、评测任务、修复任务或回放任务触发了一个或多个 pipeline phase。
• 外部 Agent 已经生成 spec、req、代码或验证产物，当前工作负责追认、评审或补齐遥测。
• 同一用户目标由 x-spec → x-req 等多个 skill 连续完成；它们属于一个 run 内的多个 phase。

身份规则：

• 一个用户任务对应一个 pipeline_run_id。
• 同一任务的反馈、修订、重评分和修复继续使用原 run，并增加 stage_attempt。
• 同题目的独立重放使用新 run，并通过 parent_run_id、baseline_run_id 或 comparison 字段关联。
• Mavis Session、Codex rollout 等 provider ID 保存为 source_session_id；pipeline_run_id 负责跨执行器关联事件、报告和知识。
• 追认历史执行时，先按 source ID、任务 hash 和 workspace 搜索已有 manifest，复用匹配 run。

新 ID 使用 prun-{uuid}-{sequence}。Mavis ID 具有 32 位 UUID 十六进制主体时，可以插入标准 UUID 连字符形成稳定映射；同一 source 始终得到同一候选 ID，最终仍需检查仓库内唯一性。

在分析前写 run_started 或 run_recognized 事件。后续事实按发生顺序追加，历史事件保持原文。

2. 建立证据边界

完整读取并区分：

• 题面或用户需求：定义目标行为和范围。
• evaluator-only 答案、rubric、隐藏 Harness：定义评分与反例，只供评审阶段读取。
• 候选产物：spec、req、代码、测试、verify 或 QA 证据。
• 运行事实：Session、工具调用、命令退出码、测试结果、Token 与耗时。
• pipeline 版本：skill、模板、validator、模型和仓库 SHA。

执行器与 grader 保持信息隔离。报告记录 rubric 是否对执行器隐藏。可变或仓库外的文本产物复制到 run 的 artifacts/ 后再评分；大型产物记录不可变存储引用和 SHA-256。