Evolve Check

Evolve-Check（收尾评估协议）

定位：self-evolve 的伴随形态。self-evolve = 用户显式发起的深度轮（全库观测/ 攒批/聚合）；本协议 = 任何内容流程收尾自动执行的轻量检查——用户说"沉淀 vllm-ascend 的 closed issue"，issue-ingest 跑完收尾即触发本协议，不看用户是否 另说"改进系统"。演进是隐形执行策略的一部分；本文自包含执行参数。

本地执行说明：本 skill 是收尾协议，非独立用户入口。内容流程（issue-ingest / to-reference / to-postmortem / diagnose / knowledge-groom）收尾时，agent read 本文件并遵循下方流程；用户说"这次做完有什么可改进的/值得沉淀的"也可直接触发。

何时触发（收尾钩子）

任何内容流程完成主体目标后、出最终报告前执行一次，成本目标近零（无信号即止）：

• issue-ingest：沉淀与标记完成后；
• to-reference / to-postmortem：草稿产出、落盘后；
• diagnose：不强制每次收尾跑本协议（高频 + 已有内建 evolving：未命中起草候选 case、源码揭示稳定结构事实顺手走 to-reference、反馈捕获写 feedback_pending）—— 其 L2/L3 视角（反复 miss 同族、流程摩擦）由 S2 replay（s2_replay.py --todo） 与深度轮归因事件信号覆盖，见 /skill:self-evolve §二；
• knowledge-groom：批审产出后。

触发不需要用户说"跑自演进"——它是流程的默认收尾步骤（同 diagnose 写 trace 的 地位）。如果一轮内容执行本身就是自演进深度轮的一部分（self-evolve 驱动），跳过本 协议（深度轮已含观测）。

评估步骤（先扫信号，无信号即止）

第 1 步：读本轮执行现场（不重扫全库、不读 case 全文——token 预算，原则九）：

• 优先读统一执行记录（走脚本，别内联 python——内联版两种环境都会崩： 有记录时 at 被 PyYAML 解析成 datetime 不可下标，新 worktree 里文件根本不存在）： python3 scripts/tail_exec_log.py（默认尾部 3 条；--n 5 / --skill evolve-check / --json） ——拿"本轮做了什么"（替代凭 agent 记忆）：
• 产出：本轮新增 case/reference/卡 id（从记录 products 提取，不重扫全库）；
• 过程中有没有：miss（diagnose/replay 未命中）、重复手动动作、流程摩擦、执行错、 新数据源/新 issue 类型首次出现——这些在 decision_reason 未提及时由 agent 现场补判断；
• 无执行记录时：脚本打印一行「无执行记录」并 exit 0——这是正常退化路径，不是报错 （内容 skill 忘了落记录、或本轮是历史流程/外部动作）。按它给的口径如实标注"无执行记录， 基于现场判断"，不假装有数据（诚实退化）。内容 skill 收尾应落记录（见各 skill「收尾」节）； 修好记录缺失比在本步硬猜更有价值。
• exec-log 是同一克隆共享的（主检出 metrics/skill-exec-log.yaml，所有 worktree 共写共读； .gitignore 运行时件）：所以"这里为空"= 这个克隆还没有任何收尾记录，而不是"本 worktree 没跑"。脚本输出自带路径与共享范围标注，不要把读数说成全系统读数——跨克隆/跨机不聚合， 要跨机得让聚合值（--summary）进 metrics/timeline.yaml。

第 2 步：对照触发条件表——命中的信号才继续，无命中直接出报告（加一行 "evolve-check：无演进信号"），不为产卡而产卡（原则四/十）。

第 3 步：产卡 + 自行验证（有信号时，agent 自动完成，不等用户）：

1. 查重 + 同组件先例咨询（防重提被拒方案——skill-impact 咨询语义； 论证可选层 docs/evolution-pipeline.md §12a）：python3 scripts/ev_proposal.py --list ——同 trajectory/同 target 已有在池卡 → 合并不新建（候选水位超限时只记信号不产卡）； 同时查本卡要改的组件（skill 步骤 / triage 分支 / script）在历史卡里的结局： --list 定位同组件卡 → 读其 decisions——该组件被改过 / 回滚过 / 有 rejected 结论 = 该方向已试过 → 不重复方案（改提新方向，或记信号不产卡）；E6 落地后改用 scripts/ev_proposal.py --impact 聚合视图（组件×尝试×结局）一次查全；
2. 产骨架：python3 scripts/ev_proposal.py --new → 填字段（layer / title / source_signals 带 trajectory / hypothesis / predicted_effect / validation / risk / principle_refs），trajectory 必须指到本轮执行出处（产出文件 id / replay 结果 / trace）； predicted_effect 必须带 measure——预测的出处：一条命令 + 期望 （expect_exit 或 expect_stdout 至少一项），让任何 reviewer 一条命令就能 复核预测是否成立（scripts/ev_measure.py <卡号> --run；三态退出码 = 符合 / 被证伪 / 无法判定）。真不可度量时如实声明 reason，不要编一条命令。 预测写不出可复现口径，通常说明它还不是一个可证伪的假设——先改预测。 与 trajectory 的分工：trajectory 管问题可回放，measure 管预测可复现；
3. 自行验证执行（评估自动化的核心——agent 自己验证，不把验证推给人）：
   • 按影响面分级选门禁（docs/eval.md「门禁分级」可选论证层，下述为执行值）： 检索/路由/候选选择面改动 → golden 子集前后对照（2-5 条受影响 fixture， 非全量；基线缓存复用，只跑改后侧）或 S2 replay（scripts/replay_golden.py / scripts/s2_replay.py），数据通过才算 eval solid；检索/路由层候选在 arena selection 池可用时（scripts/eval_arena.py --stats/--gate，论证见 docs/evolution-eval-arena.md 可选层）：golden 无回归 + val 命中/路由严格提升 才判 solid（门控判定是数据门槛，不替代 dual 双签）； 交互/追问/指引面改动（不改变候选选择）→ 跑 ixn 对口样本（scripts/ixn_replay.py， 2-3 条针对性）或小型探针，不跑检索 golden； 纯文档/注释 → 不跑 replay，scan + 人审；
   • 不能即时判定的（真实反馈类 content/fix）：完成实现 + S2 佐证，如实标注 "已实现待真实确认"（现场有效性进观察窗，事后结算）；
   • 先跑一遍自己的 measure（scripts/ev_measure.py <卡号> --run）：判据跑不通 或期望对不上的预测，不算验证——先修判据或如实改预测，别把不可复现的预期留在卡上；
4. agent 判断（EV 卡 = agent 决策档案，不含 git 合入态/待办态）：
   • eval solid → validated（采纳：改动保留，进流程层攒批/PR 供人审）；
   • eval 不成立 / 实验失败 → rejected（不采纳：留结论，改动不保留）；
   • 发现更好方向 → 新卡 supersede 本卡（superseded）；
   • 产卡即执行（无 candidate 待办态）——方案成形才产卡，产卡状态 in_experiment 开始执行；执行或验证完成而卡仍停 in_experiment = 卡不完整（见第 3.5 步）。

第 3.5 步：生命周期完整性（卡 = proposal→action→eval→decision 的 agent 决策档案）：

• 每步 decisions 记 type：产卡记 {type: proposal}、执行记 {type: action, conclusion: <做了什么/commit/产物>}、 验证记 {type: eval, conclusion: <验证数据/通过与否>}、最终判断记 {type: decision, conclusion: <采纳/不采纳/换方向+依据>}—— 卡能看出生命周期走到哪、凭什么判断；
• status 随执行推进，不靠自觉：方案成形 → 产卡（in_experiment，开始 action + eval）； agent 判断采纳 → validated / 不采纳 → rejected / 换方向 → superseded。执行与验证都完成 而卡仍停 in_experiment = 卡不完整——这条已可机器判定，verify_proposals.py 报两类： ①卡不完整：in_experiment 且已记 action 且 eval 但无 decision（工作做完了、 判断没落；只记了 action、验证还在跑的在途卡不算——那是正常中间态）；②僵尸卡： in_experiment 超 14 天（STALE_DAYS，与面板同口径）仍无 decision。CI 的 proposal-audit job 跑它，卡随 PR 合入即被校验；
• 终态卡必闭合：validated/rejected/superseded 必须有 agent 判断的 decision 记录； validated 后补 actual_cost.tokens（成本审计；无法量化写 0 + note 说明口径）—— 缺了 CI 报审计缺口，面板也标「缺成本」（两处口径一致）；
• 卡必须能追到出处：source_signals 非空且每条带 trajectory（产出文件 id / replay 结果 / trace）——没有出处的卡无法回放归因，CI 直接报错；
• 预测也必须能追到出处：predicted_effect.measure 带命令 + 期望（或如实声明不可度量）。 理由：评审被设计成 30 秒判定（predicted_effect vs 验证结果），而只有散文的预测判不了 ——reviewer 只剩"开全文"或"直接批"两个动作。缺 measure / 有命令无期望 / 命令仍是占位 都会被 CI 报错；存量卡豁免但缺口由 scripts/ev_measure.py --audit 如实报出；
• 仅"观察到的信号"（数据前提未满足 / 无准备执行的具体方案）不产卡——信号记 session 报告/任务状态，条件到（方案成形/数据齐）才产卡执行（防想法清单污染提案账本）。
• 改进动作必须先产 EV 卡（前置元流程，防绕过）：T1 归纳（→ to-reference --ingest-cases）、 T5 扩 reference 家族、以及任何"把执行结果固化为会进诊断上下文的资产"的动作—— 必须先产卡（proposal）→ 执行（action）→ 验证（eval）→ 判断（decision）→ 才随 PR 合入。 禁止直接调 to-reference/to-postmortem 产出词条后无卡合入（教训：MTP/startup 归纳先执行 后补卡——词条已 active 但决策链缺失，人审无据）。内容流程产出草稿进 inbox（待审队列） 不在此列；凡 status: active 直进上下文的产出（reference 词条、triage 改动）必须有 EV 卡决策链。

第 4 步：落收尾记录 + 出说明（并入流程报告，不单独打扰用户）：

1. 先落本协议的收尾记录（顺序不能反：记录落了，"这次协义跑过"才是数据）。 为什么必须落：不落记录时"收尾跑了但无演进信号"与"根本没跑"在数据上完全不可区分， 机制是否在运作无法证伪（收尾记录此前几乎为空，面板与 metrics 都不读 exec-log）。 面板「执行现场」按它显示运行次数与无信号次数。

   python3 scripts/log_skill_exec.py --skill evolve-check \
     --products "<EV-xxxx(validated),...>" \
     --reason "<一句话：命中 T# → 动作 / 收尾无演进信号>" \
     --source <上游 skill：issue-ingest / to-reference / to-postmortem / knowledge-groom> \
     --tokens <估算>
   

   无信号时 --products 留空、--reason 写"收尾无演进信号"（面板据此单列 no-signal 计数）。 落完自查本地不变量：python3 scripts/verify_exec_log.py --check（seq 唯一/字段齐全）。 该脚本不进 CI——exec-log 是 .gitignore 运行时件，CI 上文件不存在，进 CI 只会空转。

2. 出说明：

evolve-check：产出 EV-xxxx（补 case，S2 replay 佐证缺口）→ agent 判断采纳（validated）
或：evolve-check：无演进信号（本轮无新增数据/无流程摩擦/无覆盖缺口）

与 self-evolve 的分工

两者产出同一批池（proposals/ideas/），攒批聚合 PR 供人审时合并处理，不区分来源。

授权边界

• EV 决策是 agent 做的（产卡 + 自验证 + 判采纳/不采纳——本协议第 3/3.5 步）； 卡的 authorization 字段（auto/review/dual）标注的是改动合入的知识层分级（改动随 PR 合入时按此送审），不是 EV 决策需要人逐卡审批；
• 人审发生在目标态完成/降级完成时提的聚合 PR：审整个自演进过程是否 solid（含 rejected 卡——agent 提了 EV、实验发现不行、不采纳，这是诚实记录，人审应接受），不是逐卡审批；
• 指标口径红线保留：产卡不得改评分/指标定义（系统不改自己考卷）；
• 结构级（triage/skill 骨架/新 skill 立项）走 kb/high-risk 双签，本协议只产候选不直改。

边界（不做）

• 不为产卡而产卡：无信号即止；候选水位超限时只记信号不产卡；
• 不代替用户下内容目标：本协议只回答"这次做完能否更好"，不决定"下次做什么"；
• 不碰客户现场、不做批量改库（那是 self-evolve 深度轮 + 人审的范围）。

依赖的能力/工具