@chongyan/autospec 1.0.2 → 1.0.4

package/knowledge/01-principles/10-evolution-mechanism.md

@@ -1,699 +0,0 @@
-# 自进化机制
-
-> 核心思想：**让框架从每次执行中学习，但进化本身必须受约束、可回滚、可审计。**
->
-> **版本**: v2.1
-> **最后更新**: 2026-03-27
-> **基于**: FinSDD 自进化体系、Claude Marketplace 插件进化机制
-
-## 三层自进化体系
-
-AutoSpec 的自进化在三个层面分层发生，形成从项目实践到框架升级的完整闭环：
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│  L1: Self-Evolve (框架级)                                        │
-│  /self-evolve                                                    │
-│  目标: AutoSpec 框架自身的迭代升级                                  │
-│  位置: .claude/commands/self-evolve.md                          │
-│  产出: 框架技能、方法论、设计原则                                  │
-└─────────────────────────────────────────────────────────────────┘
-                              ↓ 提炼
-┌─────────────────────────────────────────────────────────────────┐
-│  L2: Field-Evolve (领域级)                                        │
-│  /autospec:field-evolve                                          │
-│  目标: 框架从实战项目中学习和提炼能力                               │
-│  位置: plugins/commands/field-evolve.md                            │
-│  产出: 领域技能、最佳实践、benchmarks                              │
-└─────────────────────────────────────────────────────────────────┘
-                              ↓ 应用
-┌─────────────────────────────────────────────────────────────────┐
-│  L3: Project-Evolve (项目级)                                      │
-│  /autospec:project-evolve                                        │
-│  目标: 实战项目自身的代码、配置、文档优化                          │
-│  位置: plugins/commands/project-evolve.md                        │
-│  产出: 代码质量提升、测试补全、文档完善                            │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-### L1: Self-Evolve（框架自我进化）
-
-迭代 AutoSpec **自身**时，框架用自己的流程来完善自己（dogfooding）：
-
-```
-AutoSpec 自身改进需求 → 走 AutoSpec 流程 → practice-log → 框架进化
-                                              ↓
-                          同一次迭代既是产出，又是进化信号
-```
-
-- AutoSpec 的开发本身遵循启动门禁和双层验证
-- 对框架文件的修改要用框架自身的审查流程验证
-- 通过 benchmark 评估进化效果，退化自动回滚
-- 框架越用越好，形成飞轮效应
-
-### L2: Field-Evolve（领域进化）
-
-用 AutoSpec 驱动**其他项目**研发时，实践经验自动回流到框架：
-
-```
-项目A研发 → practice-log → distiller提炼新skill → 框架变强
-项目B研发 → practice-log → extractor提炼methodology → 框架变强
-项目C研发 → 新领域技能沉淀 → skills/domain/ 扩充
-        ↓
-每个项目的经验都让下一个项目更顺畅
-```
-
-- 分析实战项目中的 benchmarks 评测数据，提炼有效模式
-- 从 practice-log 中蒸馏通用技能和最佳实践
-- 每个项目的经验通过 field-evolve 提炼后应用于所有项目
-- 领域特有的技能留在企业叠加层（不上游）
-- 通用的改进（pipeline优化、skill改进）贡献回核心框架
-
-### L3: Project-Evolve（项目自我进化）
-
-实战项目**自身**的代码、配置、文档优化：
-
-```
-代码扫描 → 问题检测 → 自动修复/A/B验证 → 质量提升
-    ↑                                    ↓
-    └──────────── 持续巡航 ←─────────────┘
-```
-
-- **智能感知**：自动发现代码质量问题、测试缺口、文档缺失
-- **自动修复**：格式化、重构、补全测试、完善文档
-- **评测驱动**：基于 benchmarks 评测指导优化方向
-- **记忆沉淀**：项目级经验沉淀为团队共享知识
-
-### 三层进化的关系
-
-```
-L3 Project-Evolve（项目级优化，量大，持续）
-    ↓ 实践信号汇聚
-L2 Field-Evolve（领域级提炼，周期性）
-    ↓ 提炼通用能力
-L1 Self-Evolve（框架级升级，战略性）
-    ↓ 框架升级
-L3 Project-Evolve（升级后的框架用于新项目）
-```
-
-**数据流向**：
-- 向下流动：L1 → L2 → L3 是能力下发（框架升级 → 领域技能 → 项目应用）
-- 向上流动：L3 → L2 → L1 是经验回流（项目实践 → 领域提炼 → 框架升级）
-
-## 第一原则
-
-进化系统最危险的失败模式是**修改自己的评判标准**。因此：
-
-1. **评判器不可变** — 宪法、验证harness、进化规则本身，不可被自动修改
-2. **约束进化空间** — 明确哪些可以自动进化，哪些需要人工批准
-3. **可量化适应度** — 进化必须有可测量的改进信号，不凭感觉
-4. **可回滚** — 每次进化变更可追溯、可撤销
-5. **简洁压力** — 等效结果下，优先选择更简单的方案
-
-## 进化分区与三层体系的对应
-
-将框架内容分为四个区域，对应三层自进化体系的不同层级：
-
-| 进化分区 | 对应层级 | 进化命令 | 主要内容 |
-|---------|---------|---------|---------|
-| 🔴 冻结区 | L1 Self-Evolve 核心 | `/self-evolve` | 宪法、进化规则、核心原则 |
-| 🟡 受控区 | L1/L2 交界 | `/self-evolve` + 人工审批 | pipeline、通用skills、角色画像 |
-| 🟢 自由区 | L2 Field-Evolve | `/autospec:field-evolve` | domain skills、benchmarks、决策树 |
-| 🔵 环境知识区 | L3 Project-Evolve | `/autospec:project-evolve` | 环境配置、组件库、最佳实践 |
-
-### 🔴 冻结区（Frozen Zone）
-
-**绝不可自动修改。变更必须由人工发起并审批。**
-
-| 内容                                                 | 原因            |
-| -------------------------------------------------- | ------------- |
-| `constitution.md`                                  | 安全红线，是整个系统的底座 |
-| `evolution.md`（本文件）                                | 进化规则本身，防止自我篡改 |
-| `knowledge/02-process/00-overview.md` 的启动门禁和双层验证定义 | 流程骨架，牵一发动全身   |
-| `methodology/design-philosophy.md` 的第一性原则（DP1-DP3） | 根基原则          |
-| 评判标准的判定逻辑（审类skill的"必须满足"条款）                        | 防止降低标准来通过验证   |
-
-**冻结区变更协议**：
-
-1. 人工提出变更提案（说明理由、影响范围、回滚方案）
-2. 至少经过一个完整项目周期的试运行
-3. 变更作为独立commit，message标记 `[FROZEN-ZONE]`
-
-### 🟡 受控区（Controlled Zone）
-
-**可以自动提议变更，但必须人工批准后才能生效。**
-
-| 内容                                                    | 进化方式                   |
-| ----------------------------------------------------- | ---------------------- |
-| `knowledge/02-process/01-requirement.md` \~ `06-delivery.md` 阶段定义 | 基于practice-log分析提出优化建议 |
-| `skills/` 通用技能（requirement-stage, design-stage等）       | 基于执行效果提出改进             |
-| `roles/{role-name}.md` 角色画像                           | 基于实际项目反馈调整关注点          |
-| `methodology/principles.md`                           | 基于实践验证新增/修订原则          |
-| `methodology/checklists/`                             | 基于审查结果补充检查项            |
-
-**受控区变更协议**：
-
-1. 自动生成变更提案（含：当前问题 + 建议修改 + 支撑证据 + 预期效果）
-2. 提案存放于 `.autospec/evolution/proposals/` 待审批
-3. 人工审批通过后合入
-4. 合入后跑一次基准案例对比（如有）
-5. 对比退化 → 自动回滚
-
-### 🟢 自由区（Free Zone）
-
-**可以自动进化，但必须通过skill-validator验证。**
-
-| 内容                            | 进化方式              |
-| ----------------------------- | ----------------- |
-| `skills/domain/` 业务技能         | 从practice-log自动蒸馏 |
-| `roles/*/skills/` 角色特有技能      | 从角色实践中自动提炼        |
-| `evaluation/benchmarks/` 基准案例 | 从成功/失败案例自动归档      |
-| `methodology/decision-trees/` | 从重复决策模式中自动生成      |
-
-**自由区变更约束**：
-
-1. 必须通过 skill-validator 验证
-2. 不可与冻结区内容冲突
-3. 每次变更记录到进化日志
-4. 同一skill在一个进化周期内最多修改一次（防止震荡）
-
-### 🔵 环境知识区（Environment Knowledge Zone）
-
-**环境衔接层知识，按类型分属不同进化分区。**
-
-详见 `knowledge/06-environment/README.md`。
-
-| 内容 | 进化分区 | 进化方式 |
-|------|---------|---------|
-| `environment/env-knowledge/middleware/` 中间件知识 | 🟡 受控区 | 人工定义 + 自动验证，自动提议需人工批准 |
-| `environment/env-knowledge/infrastructure/` 基础设施知识 | 🟡 受控区 | 人工定义 + 自动验证 |
-| `environment/component-lib/components/` 组织组件库 | 🟢 自由区 | 自动进化 + validator验证 |
-| `environment/component-lib/best-practices/` 最佳实践 | 🟢 自由区 | 从practice-log自动蒸馏 |
-| `environment/integration/ci-cd/` CI/CD配置 | 🟡 受控区 | 人工定义 + 自动执行 |
-| `environment/integration/testing/` 测试知识 | 🟡 受控区 | 从测试执行自动学习，人工审批后生效 |
-| `environment/integration/deployment/` 部署配置 | 🟡 受控区 | 人工定义 + 自动执行 |
-
-**环境知识进化协议**：
-
-1. **中间件知识进化**：
-   - 从代码中检测到新的中间件使用模式 → 自动生成配置模板提案
-   - 提案存放于 `.autospec/evolution/proposals/` 待审批
-   - 人工审批后写入 `environment/env-knowledge/middleware/`
-
-2. **组件知识进化**：
-   - 同类使用模式出现3次 → 自动生成组件知识提案
-   - 通过 environment-manager hook 验证后自动合入
-   - 更新注册表 `environment/registry.json`
-
-3. **集成知识进化**：
-   - 新增CI/CD、测试、部署配置需人工定义
-   - 配置变更需经过验证流程
-
-4. **测试知识进化**：
-   - 触发时机：每次交付完成后，field-evolve-distiller 扫描测试执行记录
-   - 学习信号：
-     - 新的测试框架或工具使用模式（出现3次以上）
-     - 更高效的 Mock 策略或测试数据准备方法
-     - 测试失败模式重复出现（同类失败3次以上）
-     - 测试代码风格趋于稳定（可提炼为模板）
-   - 进化流程：
-     - field-evolve-distiller 识别测试模式 → 自动生成测试知识提案
-     - 提案存放于 `.autospec/evolution/proposals/` 待审批
-     - 人工审批后写入 `environment/integration/testing/`
-   - 知识格式：推荐使用自由的 Markdown 格式，而非结构化 YAML
-   - 验证：用实际测试案例验证效果
-
-**环境知识验证**：
-
-- Schema验证：YAML格式正确
-- 环境变量验证：必需变量存在
-- 安全检查：无危险命令、无硬编码敏感信息
-- 语义验证：与项目技术栈兼容
-
-## 进化循环
-
-```
-执行流水线 → 收集信号 → 分析模式 → 生成提案 → 验证提案 → 接受/拒绝 → 下一轮
-    │              │            │            │            │           │
-    │              │            │            │            │           └─ 拒绝 = 回滚
-    │              │            │            │            └─ skill-validator + 基准对比
-    │              │            │            └─ 区分冻结/受控/自由区
-    │              │            └─ field-evolve-distiller + methodology-extractor
-    │              └─ practice-log + 执行指标
-    └─ pipeline-runner 驱动
-```
-
-## 三层自进化隔离演进
-
-### 隔离原则
-
-| 原则 | 说明 |
-|------|------|
-| **数据隔离** | 每个进化的practice-log独立存储 |
-| **执行隔离** | 每个进化在独立环境执行 |
-| **回滚隔离** | 每个进化独立回滚，不影响其他 |
-| **评测隔离** | 每个进化独立评测，不共享指标 |
-
-### 隔离实现架构
-
-```
-L1 Self-Evolve（框架级）→ /self-evolve
-├── 独立环境：.claude/self-evolve/
-├── 独立评测：.claude/benchmarks/self-evolve/
-├── 独立回滚：git branch self-evolve-{timestamp}
-├── 独立日志：.autospec/logs/self-evolve/
-└── 触发条件：人工触发 + 完整评测通过
-
-L2 Field-Evolve（领域级）→ /autospec:field-evolve
-├── 独立环境：.autospec/evolution/field/
-├── 独立评测：.autospec/benchmarks/field/
-├── 独立回滚：.autospec/evolution/rollback/field/
-├── 独立日志：.autospec/logs/field-evolve/
-└── 触发条件：5条practice-log累积 + 评测通过
-
-L3 Project-Evolve（项目级）→ /autospec:project-evolve
-├── 独立环境：项目目录/.autospec/
-├── 独立评测：项目目录/.autospec/benchmarks/
-├── 独立回滚：项目目录/.autospec/evolution/rollback/
-├── 独立日志：项目目录/.autospec/logs/
-└── 触发条件：每次交付后自动触发
-```
-
-### 进化前评测（强制）
-
-| 评测类型 | 内容 | 作用 |
-|---------|------|------|
-| **语法评测** | 验证修改内容语法正确 | 防止格式错误 |
-| **语义评测** | 验证修改内容语义合理 | 防止逻辑错误 |
-| **一致性评测** | 验证与冻结区/受控区无冲突 | 防止区域冲突 |
-| **安全评测** | 验证无危险操作 | 防止安全风险 |
-
-### 进化后评测（强制）
-
-| 评测类型 | 内容 | 作用 |
-|---------|------|------|
-| **回归评测** | 验证现有功能未被破坏 | 防止退化 |
-| **效果评测** | 验证改进目标达成 | 确认有效 |
-| **稳定性评测** | 验证多次执行稳定 | 防止震荡 |
-
-### 基于评测驱动的自进化
-
-AutoSpec 通过 **Benchmarks 评测** 驱动进化，形成"评测 → 分析 → 改进 → 验证"的闭环：
-
-```
-实战流程执行
-    ↓
-自动生成 Benchmarks（基于项目特点）
-    ↓
-执行 Benchmarks 评测（Layer 1 + Layer 2 + Layer 3）
-    ↓
-生成评测报告（评分、改进建议）
-    ↓
-Field-Evolve 分析（哪些 benchmarks 有效）
-    ↓
-提炼通用 Benchmarks 模板
-    ↓
-更新框架 Benchmarks 能力
-    ↓
-应用于所有项目
-```
-
-**评测驱动的价值**：
-1. **客观量化**：用数据而非主观判断评估进化效果
-2. **及时反馈**：每次执行后立即获得改进信号
-3. **可追溯**：评测历史记录进化轨迹
-4. **可对比**：基准案例对比验证进化有效性
-
-### 信号收集
-
-每次流水线执行后，自动收集：
-
-| 信号            | 来源         | 含义        |
-| ------------- | ---------- | --------- |
-| Layer 1 通过率   | 验证日志       | 代码质量基线    |
-| Layer 2 首次通过率 | 审查结果       | skill产出质量 |
-| **Layer 3 评测分数** | **benchmarks结果** | **综合质量评分** |
-| **Benchmarks 通过率** | **评测报告** | **阶段准出指标** |
-| 回退次数          | state.json | 流程顺畅度     |
-| 人工介入次数        | 执行日志       | 自主能力指标    |
-| 阶段耗时          | 执行日志       | 效率指标      |
-| 假设漂移次数        | 假设追踪表      | 阶段间一致性    |
-
-### 适应度函数
-
-```
-进化有效 = 以下至少一项改善，且无一项退化：
-  1. Layer 1+2 首次通过率 ↑
-  2. Layer 3 Benchmarks 综合评分 ↑
-  3. Benchmarks 通过率 ↑
-  4. 回退次数 ↓
-  5. 人工介入次数 ↓（在同等执行模式下）
-  6. 交付成功率 ↑
-
-进化无效 = 任何安全指标退化（即使其他指标改善）
-```
-
-**Benchmarks 驱动的进化指标**：
-- 各阶段 benchmarks 平均分数趋势
-- P0 benchmarks 首次通过率
-- 评测建议的采纳率和效果
-
-### 进化周期
-
-| 频率                  | 动作                          | 对应层级    |
-| ------------------- | --------------------------- | --------- |
-| **每次执行后**           | 记录practice-log，收集信号         | L3 Project  |
-| **阶段完成后**           | 执行 Benchmarks 评测                | L3 Project  |
-| **每5条practice-log** | 触发 distiller + extractor 扫描 | L2 Field    |
-| **每周/每迭代**          | 审查受控区变更提案 + Benchmarks分析    | L2 Field    |
-| **每季度**             | 冻结区变更评估 + 自主边界扩展            | L1 Self     |
-| **每年/大版本**          | 框架架构升级 + 进化体系迭代            | L1 Self     |
-
-## 企业适配
-
-AutoSpec 通过**领域叠加层**适配不同企业环境，而非分叉框架。
-
-### 适配架构
-
-```
-┌─────────────────────────────────┐
-│         企业叠加层               │  ← 企业特有（不上游合并）
-│  org-constitution.md            │     企业级红线追加
-│  org-skills/                    │     企业特有技能
-│  org-checklists/                │     企业特有检查项
-│  domain-knowledge/              │     领域知识注入
-├─────────────────────────────────┤
-│         AutoSpec 核心框架        │  ← npm install 获得（可升级）
-│  constitution.md                │
-│  pipeline/ skills/ roles/ ...   │
-└─────────────────────────────────┘
-```
-
-### 领域注入
-
-```bash
-autospec init --domain <domain>
-```
-
-通过 `--domain` 指定业务领域，自动加载领域特有的：
-
-| 领域           | 注入内容示例                     |
-| ------------ | -------------------------- |
-| `finance`    | 合规检查项、金额必须用Money类、审计日志要求 |
-| `healthcare` | 数据隐私红线、医疗合规检查、医疗数据校验    |
-| `ecommerce`  | 高并发检查、支付安全、库存一致性           |
-| `generic`    | 仅核心框架，无领域叠加（默认）            |
-
-领域配置存放于 `.autospec/domain/`，格式：
-
-```json
-// .autospec/domain/config.json
-{
-  "domain": "finance",
-  "version": "1.0",
-
-  // 追加到宪法（不替换核心宪法）
-  "constitution_addons": [
-    "敏感数据处理必须有审计日志",
-    "金额计算禁止使用浮点数"
-  ],
-
-  // 追加到检查清单
-  "checklist_addons": {
-    "code": [
-      "所有金额字段使用 BigDecimal/Money 类型",
-      "交易操作必须有幂等性保证"
-    ],
-    "design": [
-      "支付链路必须有对账机制"
-    ]
-  },
-
-  // 领域特有技能（指向文件）
-  "skills": [
-    "domain/finance-compliance-checker.md",
-    "domain/finance-audit-reviewer.md"
-  ]
-}
-```
-
-### 流水线扩展钩子
-
-企业可在每个流水线阶段注入自定义逻辑，无需修改核心框架：
-
-```
-before_require  → [需求分析] → after_require
-before_design   → [方案设计] → after_design
-before_implement → [编码实现] → after_implement
-before_review   → [代码审查] → after_review
-before_test     → [QA测试]   → after_test
-before_deliver  → [交付部署] → after_deliver
-```
-
-**扩展钩子配置**（`.autospec/domain/hooks.json`）：
-
-```json
-{
-  "hooks": {
-    "before_implement": [
-      {
-        "name": "compliance-scan",
-        "command": "node .autospec/domain/scripts/compliance-check.js",
-        "required": true
-      }
-    ],
-    "after_review": [
-      {
-        "name": "jira-sync",
-        "command": "node .autospec/domain/scripts/sync-to-jira.js",
-        "required": false
-      }
-    ]
-  }
-}
-```
-
-**设计原则**：
-
-- 钩子缺失或失败时，核心流程不受影响（`required: false` 时优雅降级）
-- `required: true` 的钩子失败 → 等同 Layer 1 失败，阻止进入下一阶段
-- 钩子是确定性脚本，不是AI判断
-
-### 企业私有进化
-
-企业环境中的进化产出分为两类：
-
-1. **可上游贡献**：改进通用pipeline/skills → 提PR回AutoSpec主仓
-2. **企业私有**：企业特有技能/检查项/知识 → 留在企业叠加层，不上游
-
-分离标准：**是否依赖企业内部上下文**。依赖 → 私有。不依赖 → 可贡献。
-
-## Claude Code 集成
-
-AutoSpec 通过 Claude Code 原生机制实现流程控制，不额外发明抽象：
-
-### 集成架构
-
-```
-Claude Code 原生机制          AutoSpec 用途
-─────────────────────────    ──────────────────────────────
-.claude/commands/            斜杠命令 → 显式触发流程/阶段
-.claude/skills/              技能 → 自动感知开发任务，注入流程意识
-.claude/agents/              子Agent → 做审分离（独立审查实例）
-.claude/settings.json        Hooks → 确定性安全检查（冻结区守卫、Layer 1 信号）
-```
-
-### Hooks（确定性守卫 + 质量监控）
-
-通过 Claude Code hooks 实现安全检查和质量监控，不依赖 AI 判断：
-
-| Hook                       | 事件                      | 作用                                  |
-| -------------------------- | ----------------------- | ----------------------------------- |
-| `frozen-zone-guard`        | PreToolUse (Write/Edit) | 阻止对冻结区文件的自动修改                       |
-| `scope-sentinel`           | PreToolUse (Write/Edit) | 编码阶段偏航检测（三级递增提醒）                    |
-| `layer1-validator`         | PreToolUse/PostToolUse  | Layer 1 强制检查 + 结果捕获 + 质量追踪 + **自主修复循环** |
-| `execution-tracker`        | PostToolUse (全部)        | 追踪执行日志（skill 加载、agent 调用、产物生成）       |
-| `environment-manager`      | Stop                    | 环境知识验证 + 未注册中间件检测                   |
-| `auto-fix-loop`            | PostToolUse (Layer 1 失败) | 自主修复循环（依赖/配置/代码/资源错误自动修复）            |
-
-Hooks 是**确定性的**（shell脚本，非AI判断），对应 DP1 第一层验证理念。
-企业可在此基础上追加自定义 hooks（合规检查、审计日志等）。
-
-### Skills（流程意识注入）
-
-| Skill                | 触发条件                              | 作用                                                       |
-| -------------------- | --------------------------------- | -------------------------------------------------------- |
-| `startup-guard`      | Claude 检测到开发类任务但未使用 / 命令 | 自动注入启动门禁意识，推荐合适的工作流命令                                    |
-| `layer1-validation`  | 代码变更后                             | 提醒运行 Layer 1 验证                                          |
-| `requirement-stage`   | 需求分析场景                            | 加载需求分析流程（含CEO探索对齐）+ skill + 方法论原则                        |
-| `design-stage`    | 方案设计场景                            | 加载设计流程 + skill + 方法论原则 + 检查清单                            |
-| `implementation-stage` | 编码实现场景                            | 加载实现流程 + skill + Brownfield适配 + 角色关注点                    |
-| `testing-stage`      | 测试场景                              | 加载测试流程 + skill + 角色特有测试关注点                               |
-| `delivery-stage`   | 交付部署场景                            | 加载交付流程 + 安全检查 + 自动触发practice-log和进化信号                    |
-| `field-evolve-*`       | 框架进化/流程完成后                        | 加载进化流程（scanner → executor → analyzer → fixer → verifier → learner → distiller） |
-| `pending-dashboard`   | 新会话启动时                            | 扫描待处理提案/practice-log/中断流程，主动提醒用户                         |
-
-Skills 是**被动激活的**——Claude 根据 description 自动判断是否加载。
-与 commands（主动调用）互补：skill 保底防跳过，command 显式驱动。
-
-### Agents（做审分离 + CEO探索 + 自主决策）
-
-| Agent                         | 用途                  | 隔离方式                     |
-| ----------------------------- | ------------------- | ------------------------ |
-| `independent-reviewer`           | 需求/设计/代码 Layer 2 审查 | 独立上下文 + 只读权限 + 仅获得产出物和标准 |
-| `test-coverage-reviewer`      | 测试充分性审查             | 独立上下文 + 只读权限 + 建立覆盖映射表   |
-| `consistency-checker`        | 跨产物一致性检查（DP18）      | 独立上下文 + 只读权限 + 六维检测      |
-| `ceo`       | CEO/战略视角需求探索        | 独立上下文 + 只读权限 + 聚焦商业价值    |
-| `product-owner` | 产品落地挑战（与CEO博弈）      | 独立上下文 + 只读权限 + 聚焦可行性     |
-| `stage-gate-evaluator`         | 自主阶段产出审批（无人值守）      | 独立上下文 + 只读权限 + 客观评估质量    |
-| `safety-auditor`     | 不可逆操作安全审计           | 独立上下文 + 只读权限 + 安全风险评估    |
-| `failure-diagnostician`           | 自主故障诊断（回退Level 3替代） | 独立上下文 + 只读权限 + 根因分析      |
-
-通过 Claude Code 的 Agent 机制实现 DP2 做审分离和多Agent博弈，审查/探索 Agent 天然信息隔离。
-自主决策类 Agent（stage-gate/safety-auditor/diagnose）实现无人值守流水线。
-
-### 扩展点
-
-企业可通过以下方式扩展 Claude Code 集成：
-
-```
-.claude/
-├── commands/autospec/       # 追加企业自定义命令
-├── skills/                  # 追加企业特有 skills
-├── agents/                  # 追加企业特有 agents（如安全审计Agent）
-└── settings.json            # 追加企业 hooks（如合规检查）
-```
-
-所有扩展遵循 Claude Code 原生格式，无额外学习成本。
-
-## 安全护栏
-
-### 进化不可触碰的底线
-
-1. **不可降低验证标准** — 进化可以改进skill产出，不可放宽审查标准
-2. **不可跳过Layer 1** — 即使skill进化了，确定性验证仍然必须真实执行
-3. **不可自动修改冻结区** — 包括本文件
-4. **不可在无实践支撑时进化** — 每条进化变更必须引用至少1条practice-log
-5. **不可无限自进化** — 同一组件在一个周期内最多进化一次
-
-### 进化回滚
-
-当进化变更导致以下任一情况时，**自动回滚**：
-
-- 基准案例通过率下降
-- Layer 1 通过率下降 ≥ 10%
-- 出现新的宪法违规
-- 人工标记"进化退化"
-
-回滚粒度：单个变更（不是整个进化周期）。通过git commit history实现。
-
-### 进化审计
-
-所有进化变更记录到 `.autospec/evolution/evolution-log.json`：
-
-```json
-{
-  "zone": "free",
-  "target": "skills/domain/api-design.md",
-  "action": "create",
-  "trigger": "practice-log/003",
-  "evidence": ["practice-log/003", "practice-log/005"],
-  "metrics_before": { "layer2_pass_rate": 0.75 },
-  "metrics_after": { "layer2_pass_rate": 0.85 },
-  "status": "accepted",
-  "rollback_commit": "abc1234"
-}
-```
-
-## 自主修复机制
-
-AutoSpec 框架具备**自主修复能力**，在遇到错误时先尝试自动修复，而不是立即标记为 BLOCKED。
-
-### 修复循环流程
-
-```
-检测障碍 → 分析根因 → 决策策略 → 执行修复 → 验证结果
-    ↑                                      │
-    └──────────── 最多 3 次循环 ─────────────┘
-```
-
-### 错误分类与修复策略
-
-| 错误类型 | 自主修复策略 | 示例 |
-|---------|------------|------|
-| **依赖类** | 自动添加/安装依赖 | 缺少 npm/Maven 包、工具缺失 |
-| **配置类** | 自动修正配置 | 配置文件错误、环境变量缺失 |
-| **代码类** | 自动修正代码 | 语法错误、类型错误、导入缺失 |
-| **资源类** | 自动创建/下载 | 文件缺失、目录不存在 |
-| **验证类** | 自动重试/修正 | 测试失败、编译错误 |
-| **逻辑类** | 需人工确认 | 业务逻辑错误、需求歧义 |
-
-### 修复边界
-
-| 区域 | 内容 | 修复方式 |
-|------|------|---------|
-| **冻结区** | 宪法文件、核心原则 | 不可自主修改，直接 BLOCKED |
-| **受控区** | 框架核心机制、接口契约 | 需人工批准，生成修复提案 |
-| **自由区** | 依赖添加、配置修正、语法错误 | 可自主修复，修复后验证 |
-
-### 实现位置
-
-- **核心逻辑**: `plugins/hooks/lib/auto-fix-loop.js`
-- **集成点**: `plugins/hooks/layer1-validator.js`（Layer 1 失败时触发）
-- **实践日志**: `.autospec/practice-log/`（记录每次修复详情）
-
-### 集成方式
-
-自主修复能力已集成到 `layer1-validator` hook 中：
-
-```
-Layer 1 验证失败
-    ↓
-analyzeErrorType() 分析错误类型
-    ↓
-getRepairZone() 判断修复区域
-    ↓
-自由区？→ autoFixLoop() 执行修复循环
-    ↓
-验证修复结果
-    ↓
-成功 → 继续执行 | 失败 → 重试（最多 3 次）→ 升级人工
-```
-
-### 实践日志记录
-
-每次自主修复都会记录到 practice-log：
-
-```markdown
-## [日期] 自主修复记录
-
-**问题**: [问题描述]
-**根因**: [错误类型]
-**修复方案**: [具体修复步骤]
-**验证结果**: [pass/fail]
-**分类**: [依赖/配置/代码/资源/验证]
-**区域**: [frozen/controlled/free]
-**重试次数**: [0-3]
-```
-
-### 安全护栏
-
-1. **最大重试 3 次** - 同一问题修复 3 次后必须升级人工
-2. **冻结区不可碰** - 宪法文件、核心原则不可自主修改
-3. **必须验证** - 修复后必须重新验证，不可跳过
-4. **完整记录** - 所有修复必须记录到 practice-log，用于进化分析
-
-### 与自进化的关系
-
-自主修复机制是 L3 Project-Evolve（项目级）的核心能力：
-
-```
-项目执行 → 遇到错误 → 自主修复 → 成功 → practice-log
-                                    ↓
-              同类问题 3 次重复 → field-evolve 提炼 → 通用技能
-                                    ↓
-                                    框架能力增强
-```
-
-自主修复的成功案例会通过 `field-evolve` 提炼为通用技能，增强框架的整体修复能力。
-