---
name: evolution-proposal
description: 把 evolution-inbox 中的审计异常条目转化为可评审的进化提案（规则/技能/插件/路由补丁）。先做系统化问题分析（量化基线→全量聚合→根因分类→优先级排序），再用便宜模型起草、前沿模型评审、人工批准后走既有门禁固化。用于处理 evolution_scan.js 产出的异常条目、复盘高频反模式、把会话经验固化为规则或技能改进。不用于单轮小修改和 L0 治理规则的直接修改（只产提案不越权固化）。
version: 0.3.0
triggers:
  - "evolution-inbox 中有新异常条目待处理"
  - "会话收到审计反模式信号（轮询/重试簇/token 热点/压缩风暴）需要根治"
  - "用户要求把近期会话经验固化为规则/技能/插件改进"
not_for:
  - "单轮小修改（走 minimal-implementation）"
  - "不涉及进化对象的日常任务"
  - "直接修改 AGENTS.md 治理规则（L0 层只能人工发起，本技能只产提案）"
depends_on:
  - task-mode-router
  - minimal-implementation
  - execution-discipline
  - systematic-optimization
---

# 进化提案（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 三类）：

| 根因类型 | 特征 | 对策 |
|---|---|---|
| 缺约束 | 根本没有对应的规则/流程/检查 | 补约束（新增规则/技能/门禁） |
| 有约束不执行 | 规则存在但执行者没遵守 | 加执行点检查（skill 硬约束、检测脚本、门禁） |
| 无法强制 | 规则无法被强制执行 | 升级到系统层机制（插件/参数/自动检测） |

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

**步骤 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`）：

```markdown
# 进化提案 #<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` 无空白错误。