evolution-proposal

进化提案（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 步，结构性优先） 每提出一个方案先问：这是临时方案还是结构性方案？

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