进化提案（Evolution Proposal）

核心规则

本机 Agent 体系已具备进化的全部要素（可变异对象、适应度函数、选择机制、固化管线），缺的是把审计发现转化为受控变异的提案环节。本技能就是那个转化器：

1. 只产提案，不直接改：输出是可评审的变更提案（diff + 证据 + 验证命令 + 预期指标），固化必须过人工或既有门禁。
2. 证据驱动：每条提案必须锚定 inbox 条目中的量化证据（retries=10 / pollCount=8 / inputTokens=2.5M），无证据不立项。
3. 先分析后提案：进入提案前必须先做系统化问题分析（量化基线 → 全量聚合 → 根因分类 → 优先级排序），禁止"看到一条异常就提一条提案"的碎片化处理。
4. 根因分类决定对策：沿用 systematic-optimization 的三类根因——缺约束（补约束）、有约束不执行（加执行点检查/门禁）、无法强制（升级到系统层机制）。约定层不执行是经验事实，不是假设：同一反模式反复出现必须升级方案。
5. 元规则隔离：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 步）

1. 读取 inbox 全部条目：Get-Content ~/.agent-broker/topics/skills/evolution-inbox/workspace/inbox.jsonl，按行解析 JSON。
2. 统计全量基线：总条目数、按 pattern 聚合的频次与占比（如 poll 26/390 = 6.7%）、按 severity 分布、按 status 分布。
3. 对每个高频 pattern，统计时间分布（策略生效前/后，参考 ~/.dsh/AGENTS.md 各模块生效时刻），判断是历史存量还是近期增量。
4. 记录基线数字（阶段 4 提案、固化后度量对比同口径使用）。

步骤 1.2 全量列问题（第 1 步）

1. 按 pattern 分组，每组标注：会话数、量化证据（次数/占比/极端值）、最严重代表条目（sessionId + 具体证据）。
2. 区分表象与真问题：表象是症状（如"这个会话轮询 305 次"），真问题是"缺什么机制导致这种症状反复出现"（如"监督等待阶段没有长轮询的硬约束"）。

步骤 1.3 根因分类（第 2 步） 对每个 pattern 判定根因类型（沿用 systematic-optimization 三类）：

判定方法：问三个问题——约束存在吗？存在但没执行吗？为什么没执行（不知道/忘了/没法强制）？第三类"无法强制"是复发问题的常见真根因：规则写在哪不重要，规则拦不拦得住才重要。

步骤 1.4 寻找解决方案（第 3 步，结构性优先） 每提出一个方案先问：这是临时方案还是结构性方案？

• 临时方案：手动清理、这次注意、下次记得（会复发）；
• 结构性方案：自动检测、硬校验、参数门禁、系统拦截（无法绕过）；
• 临时方案只用于止血，必须伴随结构性方案，否则问题必然复发。

步骤 1.5 联网借鉴同类已知解法（第 4 步，必做）

1. 先定义问题域，关键词取自根因（如 "agent polling anti-pattern" / "event-driven agent wait" / "long-running task supervision"）。
2. 用异步队列（queue_cli_request/queue_codex_request）+ 单次 request_result(wait=60~120) 发起联网检索（本机 web_search 余额不足时走 CLI 通道），2~3 个极窄探针（≤100 字、结构化输出）。
3. 只回收结构化结果：机制名 | 出处 | 实现方式 | 来源，不堆砌原文。
4. 产出借鉴对照表（机制 | 出处 | 实现 | 来源），写入问题分析摘要。

步骤 1.6 归纳取舍（第 5 步）

1. 借鉴方案对照本机场景约束：哪些能移植、哪些不能、怎么改造。
2. 最终方案必须标注约束分层（系统层/流程层/约定层，见 systematic-optimization 第 5 步）；约定层条目标注"未强制，待观察"，不得自称已解决；问题反复出现则升级到系统层。
3. 按成本/收益取舍，不做过度设计。

步骤 1.7 优先级排序（收敛）

1. 按「影响面 × 频率 × 可改进空间」给 pattern 排序；同根因的多个 pattern 合并为一个问题集。
2. 本轮只选 1~2 个问题集进入提案（避免一次提案过多导致评审失焦）。
3. 将选中问题集涉及的全部 inbox 条目标记 status: "processing"（写回 inbox 对应行，记录 proposedBy）。
4. 产出问题分析摘要（见输出契约），与提案文档一并落盘。

阶段 2：根因深挖与补丁起草（变异算子，用便宜模型）

1. 对选中问题集，结合本机已有规则（~/.dsh/AGENTS.md 8 模块 + 既有 skills）复核阶段 1 的根因分类，确认是新反模式、已知规则的回归还是执行不达标。
2. 复用现有工具辅助定位（不重复造轮子）：
   • 重试簇 → dsh-retry-analysis.js（provider × failure code × 消息簇）；
   • token 热点 → dsh-token-summary.js（模型/项目/任务类型画像）；
   • 轮询 → 直接查会话日志中 request_status/job_list 的调用序列。
3. 起草补丁内容（变异算子）：针对根因，产出最小化的规则/技能/插件/路由改动，遵循 minimal-implementation；明确标注补丁落在哪一层（系统层/流程层/约定层，见 systematic-optimization 第 5 步约束分层），若根因是"有约束不执行"且问题反复出现，方案必须升级到流程层以上。

阶段 3：评审（选择算子，前沿模型）

1. 本地静态预检：如果提案涉及技能包，先跑 quality_report.py --strict 和 validate_repo.py --strict；涉及 DSH 配置先跑 dsh-config-sync --check。
2. 前沿模型评审（可选用 switchboard）：把提案 + 证据 + 影响面发给前沿模型（如 queue_cli_request + request_result），要求给出 PASS / REJECT / 修改建议。
3. 成本与风险自检：估算改动引入的额外 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：交接（不越权固化）

1. 把问题分析摘要 + 提案路径 + 提案摘要交给用户/决策层，等人工批准。
2. 禁止自行应用 L0/L1 变更；用户批准后由用户或按既有流程执行固化（git 门禁 + 版本号 bump + 跨设备同步）。
3. 固化完成后，将 inbox 对应条目标记 status: "applied"（或 "rejected" 并附原因），保持 inbox 可审计。

输出契约

• 每次处理产出问题分析摘要 + 提案文档两份产物：
  • 问题分析摘要（proposals/<date>-<n>-analysis.md）：基线数字、pattern 聚合表、根因分类表、借鉴对照表（机制|出处|实现|来源，来自联网检索）、方案取舍（含约束分层）、优先级排序、本轮选择的问题集；
  • 提案文档（proposals/<date>-<n>.md）：来源证据、根因、变更对象、具体内容、影响面、验证命令、预期指标、风险回滚、评审状态；
• 提案必须包含：来源证据、根因（含根因类型）、变更对象、具体内容（含约束分层）、影响面、验证命令、预期指标、风险回滚、评审状态；
• 问题分析摘要的借鉴对照表不得为空——凡产出提案必经联网借鉴步骤（第 1.5 步），无借鉴则提案不成立；
• inbox 条目状态流转：new → processing → applied | rejected，全程可审计。

验证

本技能自身的验收标准：

1. 用一条真实 inbox 条目走完全流程（问题分析九步→根因深挖→评审→提案→交接），产出问题分析摘要 + 提案文档；
2. 问题分析摘要包含量化基线（pattern 频次/占比/时间分布）、根因分类、联网借鉴对照表（非空），不是"凭感觉选一条"；
3. 提案中的验证命令全部可执行且不修改仓库（--check/--strict 只读）；
4. 全程未修改 L0 治理规则、未越权应用变更；
5. 提案与摘要文件通过 git diff --check 无空白错误。