ooooooooooooooooooop 进化提案（Evolution Proposal）
核心规则
本机 Agent 体系已具备进化的全部要素（可变异对象、适应度函数、选择机制、固化管线），缺的是把审计发现转化为受控变异的提案环节。本技能就是那个转化器：
- 只产提案，不直接改：输出是可评审的变更提案（diff + 证据 + 验证命令 + 预期指标），固化必须过人工或既有门禁。
- 证据驱动：每条提案必须锚定 inbox 条目中的量化证据（retries=10 / pollCount=8 / inputTokens=2.5M），无证据不立项。
- 先分析后提案：进入提案前必须先做系统化问题分析（量化基线 → 全量聚合 → 根因分类 → 优先级排序），禁止"看到一条异常就提一条提案"的碎片化处理。
- 根因分类决定对策：沿用 systematic-optimization 的三类根因——缺约束（补约束）、有约束不执行（加执行点检查/门禁）、无法强制（升级到系统层机制）。约定层不执行是经验事实，不是假设：同一反模式反复出现必须升级方案。
- 元规则隔离：AGENTS.md 治理模块（L0）是选择算子本身，本技能永远不直接改它；如需变更 L0，只能作为"人工发起的独立变更"提议，由用户执行。
适用范围与触发边界
触发（满足任一即启用本技能）：
evolution-inbox（~/.agent-broker/topics/skills/evolution-inbox/workspace/inbox.jsonl）存在status: "new"的条目；- 会话中出现已知反模式信号（无 wait 轮询、重试簇、token 热点、压缩风暴）并需要根治而非临时规避；
- 用户明确要求"把最近的经验固化成规则/技能/插件改进"。
不适用：
- 单轮小修改：直接改目标文件即可，不要套提案流程（经 task-mode-router 判级）；
- 无需固化的临时问答；
- L0 治理规则修改：只能由用户人工发起，本技能最多输出"建议变更内容"供用户决定。
工作流程
阶段 1：问题分析（Problem Analysis，完整九步）
本阶段完整执行 systematic-optimization 第 0~5 步（量化→全量列问题→根因→方案→联网借鉴→归纳取舍）。没有数字的"问题"是感觉；不借鉴同类已知解法的方案是闭门造车。禁止跳过本阶段直接选条目提提案。
步骤 1.1 量化基线（第 0 步）
- 读取 inbox 全部条目：
Get-Content ~/.agent-broker/topics/skills/evolution-inbox/workspace/inbox.jsonl，按行解析 JSON。 - 统计全量基线：总条目数、按 pattern 聚合的频次与占比（如
poll 26/390 = 6.7%）、按 severity 分布、按 status 分布。 - 对每个高频 pattern，统计时间分布（策略生效前/后，参考
~/.dsh/AGENTS.md各模块生效时刻），判断是历史存量还是近期增量。 - 记录基线数字（阶段 4 提案、固化后度量对比同口径使用）。
步骤 1.2 全量列问题（第 1 步）
- 按 pattern 分组，每组标注：会话数、量化证据（次数/占比/极端值）、最严重代表条目（sessionId + 具体证据）。
- 区分表象与真问题：表象是症状（如"这个会话轮询 305 次"），真问题是"缺什么机制导致这种症状反复出现"（如"监督等待阶段没有长轮询的硬约束"）。
步骤 1.3 根因分类（第 2 步） 对每个 pattern 判定根因类型（沿用 systematic-optimization 三类）：
| 根因类型 | 特征 | 对策 |
|---|---|---|
| 缺约束 | 根本没有对应的规则/流程/检查 | 补约束（新增规则/技能/门禁） |
| 有约束不执行 | 规则存在但执行者没遵守 | 加执行点检查（skill 硬约束、检测脚本、门禁） |
| 无法强制 | 规则无法被强制执行 | 升级到系统层机制（插件/参数/自动检测） |
判定方法：问三个问题——约束存在吗？存在但没执行吗？为什么没执行（不知道/忘了/没法强制）？第三类"无法强制"是复发问题的常见真根因：规则写在哪不重要，规则拦不拦得住才重要。
步骤 1.4 寻找解决方案（第 3 步，结构性优先） 每提出一个方案先问：这是临时方案还是结构性方案？
- 临时方案：手动清理、这次注意、下次记得（会复发）；
- 结构性方案：自动检测、硬校验、参数门禁、系统拦截（无法绕过）；
- 临时方案只用于止血，必须伴随结构性方案，否则问题必然复发。
步骤 1.5 联网借鉴同类已知解法（第 4 步，必做）
- 先定义问题域，关键词取自根因（如 "agent polling anti-pattern" / "event-driven agent wait" / "long-running task supervision"）。
- 用异步队列（
queue_cli_request/queue_codex_request）+ 单次request_result(wait=60~120)发起联网检索（本机 web_search 余额不足时走 CLI 通道），2~3 个极窄探针（≤100 字、结构化输出）。 - 只回收结构化结果：
机制名 | 出处 | 实现方式 | 来源，不堆砌原文。 - 产出借鉴对照表（机制 | 出处 | 实现 | 来源），写入问题分析摘要。
步骤 1.6 归纳取舍（第 5 步）
- 借鉴方案对照本机场景约束：哪些能移植、哪些不能、怎么改造。
- 最终方案必须标注约束分层（系统层/流程层/约定层，见 systematic-optimization 第 5 步）；约定层条目标注"未强制，待观察"，不得自称已解决；问题反复出现则升级到系统层。
- 按成本/收益取舍，不做过度设计。
步骤 1.7 优先级排序（收敛）
- 按「影响面 × 频率 × 可改进空间」给 pattern 排序；同根因的多个 pattern 合并为一个问题集。
- 本轮只选 1~2 个问题集进入提案（避免一次提案过多导致评审失焦）。
- 将选中问题集涉及的全部 inbox 条目标记
status: "processing"（写回 inbox 对应行，记录proposedBy）。 - 产出问题分析摘要（见输出契约），与提案文档一并落盘。
阶段 2：根因深挖与补丁起草（变异算子，用便宜模型）
- 对选中问题集，结合本机已有规则（
~/.dsh/AGENTS.md8 模块 + 既有 skills）复核阶段 1 的根因分类，确认是新反模式、已知规则的回归还是执行不达标。 - 复用现有工具辅助定位（不重复造轮子）：
- 重试簇 →
dsh-retry-analysis.js（provider × failure code × 消息簇）； - token 热点 →
dsh-token-summary.js（模型/项目/任务类型画像）； - 轮询 → 直接查会话日志中
request_status/job_list的调用序列。
- 重试簇 →
- 起草补丁内容（变异算子）：针对根因，产出最小化的规则/技能/插件/路由改动，遵循 minimal-implementation；明确标注补丁落在哪一层（系统层/流程层/约定层，见 systematic-optimization 第 5 步约束分层），若根因是"有约束不执行"且问题反复出现，方案必须升级到流程层以上。
阶段 3：评审（选择算子，前沿模型）
- 本地静态预检：如果提案涉及技能包，先跑
quality_report.py --strict和validate_repo.py --strict；涉及 DSH 配置先跑dsh-config-sync --check。 - 前沿模型评审（可选用 switchboard）：把提案 + 证据 + 影响面发给前沿模型（如
queue_cli_request+request_result），要求给出 PASS / REJECT / 修改建议。 - 成本与风险自检：估算改动引入的额外 token 成本；检查是否触碰 Non-Goals（如不该动的文件、不该改的元规则）。
阶段 4：产出提案（输出契约）
输出结构（写入 .agent-broker/topics/skills/evolution-inbox/proposals/<yyyy-mm-dd>-<n>.md）：
# 进化提案 #<n>：<标题>
- 来源条目：inbox 行 <序号>（sessionId、pattern、severity）
- 反模式：<模式名> <量化证据>
- 问题分析摘要：<基线数字 + 根因分类 + 是否回归>
- 根因：<一句根因判断 + 根因类型>
- 变更对象：<L1 技能 | L2 插件/preset | L3 路由参数 | L0 元规则[仅建议]>
- 变更内容：<具体 diff 或改动描述 + 约束分层>
- 影响面：<受影响文件、行为、成本>
- 验证命令：<git diff --check + validate_repo --strict + quality_report --strict + 其他>
- 预期指标：<可测量的改进目标，如重试率下降 X%、轮询次数归零>
- 风险与回滚：<风险点 + 回滚方式>
- 评审状态：PENDING（等待人工批准）
阶段 5：交接（不越权固化）
- 把问题分析摘要 + 提案路径 + 提案摘要交给用户/决策层，等人工批准。
- 禁止自行应用 L0/L1 变更；用户批准后由用户或按既有流程执行固化（git 门禁 + 版本号 bump + 跨设备同步）。
- 固化完成后，将 inbox 对应条目标记
status: "applied"（或"rejected"并附原因），保持 inbox 可审计。
输出契约
- 每次处理产出问题分析摘要 + 提案文档两份产物：
- 问题分析摘要（
proposals/<date>-<n>-analysis.md）：基线数字、pattern 聚合表、根因分类表、借鉴对照表（机制|出处|实现|来源，来自联网检索）、方案取舍（含约束分层）、优先级排序、本轮选择的问题集； - 提案文档（
proposals/<date>-<n>.md）：来源证据、根因、变更对象、具体内容、影响面、验证命令、预期指标、风险回滚、评审状态；
- 问题分析摘要（
- 提案必须包含：来源证据、根因（含根因类型）、变更对象、具体内容（含约束分层）、影响面、验证命令、预期指标、风险回滚、评审状态；
- 问题分析摘要的借鉴对照表不得为空——凡产出提案必经联网借鉴步骤（第 1.5 步），无借鉴则提案不成立；
- inbox 条目状态流转：
new → processing → applied | rejected，全程可审计。
验证
本技能自身的验收标准：
- 用一条真实 inbox 条目走完全流程（问题分析九步→根因深挖→评审→提案→交接），产出问题分析摘要 + 提案文档；
- 问题分析摘要包含量化基线（pattern 频次/占比/时间分布）、根因分类、联网借鉴对照表（非空），不是"凭感觉选一条"；
- 提案中的验证命令全部可执行且不修改仓库（
--check/--strict只读）； - 全程未修改 L0 治理规则、未越权应用变更；
- 提案与摘要文件通过
git diff --check无空白错误。