@chongyan/autospec 1.0.2 → 1.0.4

package/knowledge/03-guides/18-log-practice.md

@@ -1,359 +0,0 @@
-# 进化实践记录器
-
-## 功能
-
-在流程完成或会话结束时，检查并提醒记录实践日志。合并了原 evolution-trigger 和 practice-log-reminder 的功能。
-
-**增强功能**：
-- 连接评测数据，自动识别进化触发信号
-- 基于质量分数自动决定是否需要记录
-- 集成错误模式检测
-
-## 触发条件
-
-1. **流程完成时**
-   - state.json 中 stage === 6 或 completedAt 存在
-   - 有活跃的 pipeline 状态
-
-2. **会话结束时**
-   - Stop hook 触发
-   - 有未完成的 pipeline
-
-3. **评测触发时**（新增）
-   - 质量分数 < 70
-   - 同类错误出现 >= 3 次
-   - 新模式识别
-
-## 输入
-
-```json
-{
-  "state": {
-    "currentStage": "06-deliver",
-    "completedAt": "2024-01-15T10:30:00Z",
-    "pipeline": "feature-xyz"
-  },
-  "practiceLogExists": false,
-  "evolutionLogExists": false,
-  "evaluationData": {
-    "qualityScore": 65,
-    "errorPatterns": [...],
-    "improvementAreas": [...]
-  }
-}
-```
-
-## 输出
-
-```json
-{
-  "needsReminder": true,
-  "reminderType": "practice-log | evolution-scan | both",
-  "message": "提醒消息",
-  "template": "practice-log 模板内容",
-  "evolutionTriggers": [
-    {
-      "type": "quality_low",
-      "evidence": "质量分数 65 < 70",
-      "suggestedAction": "触发 methodology 审查"
-    }
-  ]
-}
-```
-
-## 执行步骤
-
-1. **检查流程状态**
-   - 读取 state.json
-   - 判断是否已完成
-
-2. **检查日志文件**
-   - 检查 practice-log 是否存在
-   - 检查 evolution-log 是否存在
-
-3. **读取评测数据**（新增）
-   - 读取 metrics.json 中的 qualityScore
-   - 读取 errorPatterns
-   - 读取 improvementAreas
-
-4. **检测进化触发**（新增）
-   - 检查质量分数阈值
-   - 检查错误模式重复次数
-   - 检查新模式识别
-
-5. **生成提醒**
-   - 如果流程完成但没有 practice-log，提醒记录
-   - 如果有新的 practice-log，提醒执行进化扫描
-   - 如果有进化触发信号，自动创建 practice-log 草稿
-
-6. **提供模板**
-   - 生成 practice-log 模板
-   - 包含关键信息预填
-   - 包含评测数据摘要
-
-## 评测数据输入
-
-从 `.autospec/logs/evaluation/` 读取评测报告，提取：
-
-### 质量分数触发
-
-| 条件 | 触发动作 |
-|-----|---------|
-| 质量分数 < 70 | 触发 methodology 审查 |
-| 过程指标 < 60 | 触发流程优化 |
-| 结果指标 < 60 | 触发产出物模板优化 |
-| 路径指标 < 60 | 触发 SDD 引导优化 |
-
-### 错误模式触发
-
-| 条件 | 触发动作 |
-|-----|---------|
-| 同类错误 >= 3 次 | 自动创建 practice-log |
-| 新错误类型 | 标记需要分析 |
-| 恢复率 < 60% | 触发异常处理优化 |
-
-### 新模式识别
-
-| 条件 | 触发动作 |
-|-----|---------|
-| 新解决方案模式 | 触发 skill 提案 |
-| 新最佳实践 | 触发 knowledge 更新 |
-| 新反模式 | 触发 DP 更新 |
-
-## 触发规则
-
-### 规则 1: 同类错误 3 次
-
-```javascript
-// 检测同类错误重复
-if (errorPattern.count >= 3) {
-  autoCreatePracticeLog({
-    type: 'repeated_error',
-    errorType: errorPattern.type,
-    count: errorPattern.count,
-    suggestion: '建议创建专门的 skill 处理此类错误'
-  });
-}
-```
-
-### 规则 2: 质量分数 < 70
-
-```javascript
-// 检测质量分数
-if (qualityScore.overall < 70) {
-  triggerEvolution({
-    type: 'quality_review',
-    evidence: `质量分数 ${qualityScore.overall} < 70`,
-    action: '触发 methodology 审查'
-  });
-}
-```
-
-### 规则 3: 新模式识别
-
-```javascript
-// 检测新模式
-if (detectedNewPattern) {
-  suggestSkillCreation({
-    type: 'new_pattern',
-    pattern: detectedPattern,
-    evidence: patternEvidence
-  });
-}
-```
-
-## 提醒消息模板
-
-### 流程完成提醒
-
-```
-[AutoSpec 进化提醒] 📝
-
-流程已完成，请记录实践日志：
-
-1. 创建文件：.autospec/evolution/practice-log/{date}-{topic}.md
-
-2. 记录内容：
-   - 遇到的问题和解决方案
-   - 发现的新模式或最佳实践
-   - 可以改进的地方
-
-3. 执行进化扫描：
-   /evolve
-
-模板已为您准备好，是否需要自动创建？
-```
-
-### 评测触发提醒（新增）
-
-```
-[AutoSpec 进化触发] ⚡
-
-检测到以下进化信号：
-
-1. 质量分数: {score}/100 (低于阈值 70)
-   - 建议审查: methodology
-
-2. 重复错误: {errorType} 出现 {count} 次
-   - 建议: 创建专门的 skill
-
-3. 新模式识别: {patternName}
-   - 建议: 提取为可复用 skill
-
-详细评测报告: /evaluate
-是否自动创建 practice-log 草稿？
-```
-
-### 会话结束提醒
-
-```
-[AutoSpec 实践记录] 📋
-
-检测到有活跃的 pipeline，建议：
-
-1. 如果流程未完成，记录当前进度
-2. 如果遇到问题，记录到 practice-log
-3. 下次继续时可以快速恢复
-
-是否需要创建进度记录？
-```
-
-## practice-log 模板（增强版）
-
-```markdown
-# 实践日志
-
-日期：{date}
-主题：{topic}
-阶段：{stage}
-Trace ID: {traceId}
-
-## 问题描述
-
-<!-- 描述遇到的问题 -->
-
-## 解决方案
-
-<!-- 描述解决方案 -->
-
-## 经验总结
-
-<!-- 描述可以复用的经验 -->
-
-## 评测数据（自动填充）
-
-- 质量分数: {qualityScore}
-- 错误模式: {errorPatterns}
-- 改进领域: {improvementAreas}
-
-## 进化建议（自动生成）
-
-<!-- 基于评测数据自动生成的建议 -->
-
-## 相关文件
-
-<!-- 列出相关文件 -->
-
-## 标签
-
-<!-- 添加标签，如：bugfix, optimization, pattern -->
-```
-
-## 规则
-
-1. **不重复提醒**
-   - 如果已有 practice-log，不重复提醒
-   - 同一会话只提醒一次
-
-2. **渐进式提醒**
-   - 第一次：友好提示
-   - 第三次同类问题：强烈建议
-   - 第五次：必须记录
-
-3. **智能判断**
-   - 简单任务可能不需要记录
-   - 复杂问题自动标记需要记录
-
-4. **评测驱动**（新增）
-   - 质量分数低时自动触发
-   - 错误模式重复时自动触发
-   - 新模式识别时建议触发
-
-## 配置
-
-```yaml
-# .autospec/config.json
-{
-  "evolution": {
-    "reminderEnabled": true,
-    "reminderThreshold": 3,
-    "autoCreateTemplate": false,
-    "qualityThreshold": 70,
-    "errorPatternThreshold": 3
-  }
-}
-```
-
-## 与评测系统的集成
-
-### 数据流
-
-```
-评测报告 → evo-practice-logger → practice-log → 进化机制
-     │
-     ├── 质量分数 < 70 → 触发 methodology 审查
-     ├── 错误重复 >= 3 → 自动创建 practice-log
-     └── 新模式识别 → 建议 skill 创建
-```
-
-### 自动化触发
-
-当评测报告生成后，自动检查进化触发条件：
-
-1. 读取评测报告
-2. 检查触发条件
-3. 生成进化建议
-4. 自动创建 practice-log 草稿（如需要）
-
-## 示例
-
-### 输入
-
-```json
-{
-  "state": {
-    "currentStage": "06-deliver",
-    "completedAt": "2024-01-15T10:30:00Z"
-  },
-  "practiceLogExists": false,
-  "evaluationData": {
-    "qualityScore": 65,
-    "errorPatterns": [
-      { "type": "test_fail", "count": 3 }
-    ]
-  }
-}
-```
-
-### 输出
-
-```json
-{
-  "needsReminder": true,
-  "reminderType": "both",
-  "message": "检测到进化触发信号...",
-  "template": "# 实践日志\n\n日期：2024-01-15\n...",
-  "evolutionTriggers": [
-    {
-      "type": "quality_low",
-      "evidence": "质量分数 65 < 70",
-      "suggestedAction": "触发 methodology 审查"
-    },
-    {
-      "type": "repeated_error",
-      "evidence": "test_fail 出现 3 次",
-      "suggestedAction": "建议创建专门的 skill"
-    }
-  ]
-}
-```

package/knowledge/03-guides/19-distill-skill.md

@@ -1,91 +0,0 @@
----
-name: field-evolve-distiller
-description: 当全流程完成或practice-log积累到一定量、需要从执行轨迹或业务知识中提炼新的可执行skill时触发
-type: produce
----
-
-## 定位
-从实践中识别和提炼可执行的新skill，是框架持续扩展能力的引擎。分三个场景：流程蒸馏（向内看）、业务蒸馏（向外看）、测试知识蒸馏（从测试执行中学习）。
-
-## 输入
-- 必须输入：practice-log中状态为"待处理"的条目
-- 场景A可选：流程执行轨迹、人工介入记录
-- 场景B可选：业务项目中的知识素材（成熟提示词、业务规则、领域术语）
-- 场景C可选：测试执行记录、测试代码、测试失败模式
-
-## 输出
-- 新的skill文件（符合 skills/_template.md 格式，含CSO description + 反模式清单）
-- 测试知识文件（Markdown 格式，存放于 `environment/integration/testing/`）
-- 蒸馏报告（从什么素材提炼、归入哪个目录、与现有skills/知识的关系）
-- **证据清单**（支撑蒸馏决策的practice-log引用）
-
-## 执行步骤
-
-### 场景A：流程蒸馏（向内看）
-
-1. **监控**：扫描流程执行中的操作轨迹和人工介入点
-2. **识别**：寻找以下信号
-   - 某个操作模式反复出现（3次以上）
-   - 某处频繁需要人工介入（自动化缺口）
-   - 两个现有skills有重复逻辑（可提取更基础的skill）
-   - 质量关卡的某类判断逻辑逐渐成熟（可独立为专项skill）
-3. **抽象**：将具体操作抽象为通用skill定义
-   - 明确输入/输出（含关键假设和证据）
-   - 确定属于哪个阶段
-   - 厘清与现有skills的关系（替代/补充/组合）
-   - **编写CSO格式的description**
-   - **编写反模式清单**
-4. **验证**：调用skill-validator检查
-5. **归档**：归入 skills/ 或 plugins/skills/
-
-### 场景B：业务蒸馏（向外看）
-
-1. **收集**：从项目中归集业务知识素材
-2. **分层**：判断知识的复用层级（场景级/行业级/通用级）
-3. **封装**：将业务知识封装为可执行skill
-   - 内嵌领域知识（不依赖外部记忆）
-   - **编写CSO格式的description**
-   - **编写反模式清单**
-4. **验证**：用真实业务案例验证效果，调用skill-validator检查
-5. **归档**：归入 skills/domain/
-
-### 场景C：测试知识蒸馏（从测试执行中学习）
-
-1. **监控**：扫描测试执行记录和测试代码
-2. **识别**：寻找以下信号
-   - 新的测试框架或工具使用模式（出现3次以上）
-   - 更高效的 Mock 策略或测试数据准备方法
-   - 测试失败模式重复出现（同类失败3次以上）
-   - 测试代码风格趋于稳定（可提炼为模板）
-3. **抽象**：将测试模式抽象为测试知识
-   - 明确适用场景和技术栈
-   - 提炼测试策略（testcontainer、mock 等）
-   - 记录注意事项和反模式
-4. **验证**：用实际测试案例验证效果
-5. **归档**：归入 `environment/integration/testing/` 目录
-
-**测试知识蒸馏示例**：
-- 发现项目中多次使用 Testcontainer 启动 MySQL → 提炼为测试知识 `mysql-testing.md`
-- 发现某类 Mock 策略导致测试不稳定 → 补充到反模式清单
-- 发现测试数据准备有通用模式 → 提炼为测试工具函数
-
-### 蒸馏后处理
-- 更新practice-log对应条目状态为"已处理"
-- 如果某角色skill在3+角色中出现 → 提议升级为通用skill
-
-## 反模式清单（DP7）
-1. **过早蒸馏**：模式出现不到3次就急于提炼。检测：必须有3+实例支撑
-2. **过度泛化**：把项目特有的模式强行泛化。检测：判断复用层级，不可泛化的留在practice-log
-3. **不验证就归档**：跳过skill-validator直接归档。检测：验证是必选步骤
-4. **忽略现有skills**：不检查是否已有类似skill。检测：蒸馏前搜索现有skills
-5. **遗漏反模式**：新skill没有反模式清单。检测：反模式是模板必选section
-
-## 适用场景与边界
-- 适用：全流程完成后的自动扫描、practice-log积累到一定量时、测试执行积累到一定量时
-- 不适用：skill已存在只需升级（用skill-evolver）、提取的是方法论而非可执行skill（用methodology-extractor）
-- 测试知识蒸馏：测试模式出现3次以上、测试失败模式重复出现
-
-## 示例
-**场景A示例**：跑了5次需求分析后发现"需求冲突检测"是独立能力 → 蒸馏为 `skills/req-conflict-detector/SKILL.md`
-**场景B示例**：商机项目拓客提示词经5轮调优趋于稳定 → 蒸馏为 `skills/domain/b2b-lead-discovery.md`
-**场景C示例**：项目中多次使用 Testcontainer 启动 MySQL 测试 → 提炼为 `environment/integration/testing/mysql-testing.md`

package/knowledge/03-guides/20-update-skill.md

@@ -1,45 +0,0 @@
----
-name: skill-evolver
-description: 当skill执行效果持续不达标或同类问题出现3次以上、需要迭代升级已有skill时触发
-type: produce
----
-
-## 定位
-让skills持续进化而非一次性产出。基于执行效果和反馈，系统化地升级已有skill。
-
-## 输入
-- 必须输入：待升级的skill文件、反馈数据（审类skill打回记录 / practice-log条目 / 人工反馈 / methodology更新）
-- 可选输入：evaluation/benchmarks中的相关案例
-
-## 输出
-- 升级后的skill文件
-- 变更说明（改了什么、为什么、预期效果）
-- **证据清单**（支撑升级决策的反馈数据引用）
-
-## 执行步骤
-1. 收集该skill相关的所有反馈数据
-   - 预期产出：反馈汇总表
-   - 失败处理：反馈不足则标记，不盲目修改
-2. 分析问题模式：是skill的步骤不够具体？评判标准不够准确？适用场景描述有误？反模式不够全面？
-3. 生成修改建议（明确改哪个section、怎么改、预期效果）
-4. 执行修改
-5. 用skill-validator验证修改后的skill
-6. 如有evaluation/benchmarks中的相关案例，用案例对比修改前后效果
-7. **整理证据清单**（哪些反馈支撑了哪些修改）
-
-## 反模式清单（DP7）
-1. **盲目修改**：没有充分反馈就修改skill。检测：必须有至少3条反馈数据支撑
-2. **过度泛化**：把特定项目的问题泛化为通用修改。检测：修改必须回溯到问题是否普遍
-3. **破坏已有能力**：修改后导致原本能处理的场景失效。检测：用基准案例验证前后效果
-4. **跳过验证**：修改后不用skill-validator检查。检测：验证是必选步骤
-
-## 适用场景与边界
-- 适用：skill执行效果不达标、practice-log中同类问题出现3次以上、methodology更新导致skill需同步
-- 不适用：skill本身没问题但使用者没按skill执行；需要全新skill而非升级（用field-evolve-distiller）
-
-## 示例
-**触发**：code-reviewer skill连续3次在"安全审查"维度漏判SQL注入问题
-**分析**：评判标准中安全检查项不够具体，只写了"无安全漏洞"，没有列举具体检查类型
-**修改**：在评判标准中展开为具体项（SQL注入、XSS、CSRF、越权访问...），在评审步骤中增加安全审查子步骤
-**验证**：用已知含SQL注入的代码案例重新审查，确认能正确识别
-**证据**：practice-log #12, #15, #18 均记录了SQL注入漏判

package/knowledge/03-guides/21-validate-skill.md

@@ -1,72 +0,0 @@
----
-name: skill-validator
-description: 当新建或修改了skill文件、需要验证其是否符合框架标准和质量要求时触发
-type: review
----
-
-## 定位
-验证新建或修改的skill是否符合框架标准，确保skill质量。是skill生命周期的质量关卡。
-
-## 输入
-- 必须输入：待验证的skill文件
-- 可选输入：skills/_template.md（做/审模板标准）、现有skills列表、methodology/
-
-## 评判标准
-必须满足：
-- [ ] 符合对应模板结构（做类或审类）
-- [ ] frontmatter完整（name, description, type）
-- [ ] description符合CSO原则（只写触发条件，不写工作流摘要）
-- [ ] 输入/输出定义清晰，区分必须/可选
-- [ ] 输出包含关键假设清单和证据清单
-- [ ] 执行步骤/评审步骤可操作（人或AI能直接执行）
-- [ ] 包含反模式清单（至少5条通用 + skill特有）
-- [ ] 至少包含一个完整示例
-- [ ] 与现有skills无功能重叠或逻辑矛盾
-- [ ] 与methodology/principles.md和constitution.md无矛盾
-
-建议满足：
-- [ ] 适用场景与边界描述充分，标注前置/后续skill
-- [ ] 审类skill的评判标准具体可量化
-- [ ] 审类skill的输出格式包含证据表格
-- [ ] 示例覆盖典型场景和边界情况
-
-## 评审步骤
-1. 检查文件格式是否符合模板
-   - 证据获取：逐section对照模板
-2. 检查description是否符合CSO原则
-   - 证据获取：description是否包含触发条件而非工作流摘要
-3. 逐section检查内容完整性
-4. 评估可执行性：假设自己是执行者，能否只凭这个skill文件完成任务
-5. 检查反模式清单的完整性和实用性
-6. 检查与现有skills的关系（有无重叠、冲突、可组合）
-7. 检查与methodology和constitution的一致性
-8. 逐项输出判定结果，**每项附具体证据**
-
-## 输出格式
-
-```
-## 验证结论：通过 / 不通过
-
-### 逐项判定
-| 检查项 | 结论 | 证据 | 备注 |
-|--------|------|------|------|
-| 模板符合 | ✅/❌ | {缺失section列表} | {修复建议} |
-| CSO description | ✅/❌ | {当前description} | {建议修改} |
-| ... | ... | ... | ... |
-
-### 必须修复
-- ...
-
-### 建议改进
-- ...
-```
-
-## 反模式清单（DP7）
-1. **橡皮图章**：不逐项检查就通过。检测：每项必须附证据
-2. **形式主义**：只查格式不查内容质量。检测：必须评估"可执行性"
-3. **标准漂移**：验证标准随意放松。检测：对照模板和宪法逐项检查
-4. **遗漏CSO检查**：不验证description格式。检测：CSO是独立检查项
-
-## 适用场景与边界
-- 适用：新建skill、修改skill后的验证、定期skill质量巡检
-- 不适用：验证非skill类型的文件

package/knowledge/03-guides/22-extract-methodology.md

@@ -1,55 +0,0 @@
----
-name: methodology-extractor
-description: 当全流程完成或practice-log积累到5条以上、需要从实践中识别和提取可复用的方法论时触发
-type: produce
----
-
-## 定位
-让方法论从实践中自然生长，而非空想。识别实践中的有效模式和认知，沉淀为可复用的原则和方法论。
-
-> 与field-evolve-distiller的区别：distiller提取**可执行的skill**，extractor提取**认知性的方法论**（原则、检查项、决策树）。
-
-## 输入
-- 必须输入：practice-log中状态为"待处理"的条目
-- 可选输入：流程执行记录、人工复盘的讨论内容
-
-## 输出
-- 更新后的methodology文件（principles.md / checklists/ / decision-trees/ / design-philosophy.md）
-- 提取报告（从什么实践提取、更新了哪个文档、新增还是修改）
-- **证据清单**（支撑提取决策的practice-log引用）
-
-## 执行步骤
-1. 扫描practice-log中"待处理"的条目
-2. 分析本次实践：哪些做法有效、哪些踩坑
-   - 预期产出：有效做法列表 + 踩坑列表
-3. 与已有methodology对比：是新发现还是已有原则的验证
-   - 如果是已有原则的验证 → 增加验证案例引用
-   - 如果与已有原则冲突 → 标记待讨论，**不自动覆盖**
-4. 判断是否可泛化：
-   - 只对当前项目有效 → 留在practice-log，标记"仅作案例保留"
-   - 普遍适用 → 提取为方法论
-5. 确定更新目标：
-   - 新原则 → 更新 methodology/principles.md
-   - 新检查项 → 更新对应 methodology/checklists/
-   - 新决策模式 → 创建或更新 methodology/decision-trees/
-   - 设计哲学层面的发现 → 更新 methodology/design-philosophy.md
-6. 执行更新（追加或修改，不删除已有内容除非明确过时）
-7. 更新practice-log对应条目状态为"已处理"
-8. **整理证据清单**
-
-## 反模式清单（DP7）
-1. **空想方法论**：没有实践支撑的方法论。检测：每条方法论必须引用至少1条practice-log
-2. **过度泛化**：把项目特有的经验强行泛化。检测：判断是否在2+项目中有效
-3. **自动覆盖冲突**：新发现与已有原则冲突时自动覆盖。检测：冲突必须标记待讨论
-4. **区分不清**：把可执行的skill混入方法论。检测：方法论是"认知性的"，skill是"可执行的"
-5. **忽略失败案例**：只提取成功经验。检测：踩坑教训同样有提取价值
-
-## 适用场景与边界
-- 适用：全流程完成后的自动扫描、practice-log积累到5条以上时、老板要求复盘时
-- 不适用：提取的是可执行skill（用field-evolve-distiller）、与已有methodology冲突需人工裁决的
-
-## 示例
-**实践**：连续3个项目在设计阶段都因为"没考虑缓存策略"被打回
-**分析**：这是一个普遍适用的设计检查项，不是项目特有的
-**提取**：在 methodology/checklists/design.md 中新增检查项："缓存策略是否已考虑（适用于有数据读取的场景）"
-**证据**：practice-log #5, #8, #11