@chongyan/autospec 1.0.1 → 1.0.2

package/plugins/skills/implementation-stage/SKILL.md

@@ -7,14 +7,45 @@ description: "When code implementation, feature coding, or translating a technic
 
 你正在执行编码实现阶段。此阶段将技术方案忠实落地为可运行代码。
 
+## ⚠️ 执行约束（强制）
+
+**【阻塞检查】** 在开始执行前，必须确认以下条件：
+
+```
+□ 上游方案设计阶段已完成（检查 state.json）
+□ design.md 文件存在且完整
+□ 已读取复杂度评估结果或重新评估
+□ 已确定参与角色列表
+□ 已识别涉及的子系统
+```
+
+**【跳过检测】** 以下行为将被检测并阻止：
+
+| 行为 | 检测方式 | 处理 |
+|------|----------|------|
+| 直接编码没有设计文档 | 检查 design.md 是否存在 | 阻止，返回执行方案设计 |
+| 跳过依赖包检查 | 检查 dependency-decision.md | 阻止，要求执行依赖检查 |
+| 跳过 Layer1 验证 | 检查编译/测试日志 | 阻止，要求执行验证 |
+| 跳过团队对抗审查 | 检查 Agent 调用记录 | 阻止，要求启动多 Agent 审查 |
+
+**【强制流程】** 必须按顺序完成以下步骤，不可跳过：
+
+```
+Step 1 → Step 2/3 → 阶段完成验证 → Layer1 → 团队对抗 → Layer2 → 阶段门禁
+         ↓
+    【强制】依赖包检查必须完成
+    【强制】Layer1 验证必须真实执行
+    【禁止】跳过验证直接提交代码
+```
+
 ## 前置检查
 
 1. 确认方案设计阶段已完成（检查 `.autospec/runtime/state.json`）
-2. 读取 `${KNOWLEDGE}/principles/constitution.md` → 确认红线
+2. 读取 `knowledge/01-principles/09-constitution.md` → 确认红线
 3. 读取上游精炼契约（技术方案）
 4. **检查是否为多系统项目**：读取 `.autospec/runtime/config.json` 的 `subsystems` 字段
-5. 如有角色配置，加载 `${KNOWLEDGE}/guides/stages/{角色}-profile.md` 中**编码阶段**关注点（如后端关注事务处理/并发安全/性能）
-6. 加载认知增强原则：读取 `${KNOWLEDGE}/principles/core-principles.md` → 本阶段重点应用 CP8(偏航检测)、CP9(刚好够用)、CP10(自我质检)
+5. 如有角色配置，加载 `.clause/agents/roles/{角色}.md` 中**编码阶段**关注点（如后端关注事务处理/并发安全/性能）
+6. 加载认知增强原则：读取 `${KNOWLEDGE}/principles/02-methodology-principles.md` → 本阶段重点应用 CP8(偏航检测)、CP9(刚好够用)、CP10(自我质检)
 
 ## 执行
 
@@ -26,17 +57,26 @@ description: "When code implementation, feature coding, or translating a technic
 
 ### Step 2: 单系统模式
 
-1. **【强制】** 加载做类skill：读取 `${KNOWLEDGE}/guides/stages/code-implementer.md` → **按步骤执行**
-2. 加载检查清单：读取 `${KNOWLEDGE}/checklists/code.md` → 逐项核对
-3. 加载方法论原则：读取 `${KNOWLEDGE}/principles/core-principles.md` → 注入 P9(高内聚低耦合)、P11(架构决策记录) 等编码原则
-4. **先搜索现有代码库**，识别可复用组件（DP15 Brownfield适配）
-5. 如有角色特有检查项（如后端 profile.md 中的"事务处理"、"N+1查询"），额外关注
-6. **【强制】代码注释规范**：
+1. **【强制】** 加载做类skill：读取 `${KNOWLEDGE}/03-guides/04-implement-code.md` → **按步骤执行**
+2. 加载检查清单：读取 `knowledge/04-checklists/02-code.md` → 逐项核对
+3. 加载方法论原则：读取 `${KNOWLEDGE}/principles/02-methodology-principles.md` → 注入 P9(高内聚低耦合)、P11(架构决策记录) 等编码原则
+4. **【强制】编码前依赖包检查**（DP15 Brownfield 适配 + 依赖包复用）：
+   - 调用 `plugins/skills/project-evolve-scanner/scripts/dependency-reuse-checker.js`
+   - 扫描项目依赖（package.json / pom.xml / build.gradle / go.mod 等）
+   - 检查团队组件使用手册（`${KNOWLEDGE}/environment/` 或 `team-wiki/`）
+   - 搜索项目现有代码，识别可复用实现
+   - 如决定自己实现，必须记录理由到 `.autospec/dependency-decision.md`：
+     - 现有包不满足需求（具体说明）
+     - 升级风险过大（具体说明）
+     - 其他合理理由
+5. **先搜索现有代码库**，识别可复用组件（DP15 Brownfield 适配）
+6. 如有角色特有检查项（如后端 profile.md 中的"事务处理"、"N+1查询"），额外关注
+7. **【强制】代码注释规范**：
    - 每个公共函数/方法必须有文档注释（功能、参数、返回值、异常）
    - 复杂逻辑必须添加行内注释说明"为什么"
    - 关键算法必须注释说明实现思路
    - 使用项目统一的注释风格（根据 `.autospec/config.json` 或常见约定）
-7. 按方案模块划分编码，产出代码+自测
+8. 按方案模块划分编码，产出代码+自测
 
 ### Step 3: 多系统模式
 
@@ -45,7 +85,7 @@ description: "When code implementation, feature coding, or translating a technic
    - 跨系统接口契约
    - 开发顺序（通常：后端 → 前端 → 移动端；有ml时可能需要先验证效果）
 
-2. **按顺序处理每个子系统**：
+2. **按顺序处理每个子系统（带切换检查）**：
    ```
    for subsystem in config.subsystems（按依赖顺序）:
      a. 读取 design/{subsystem.name}.md
@@ -57,9 +97,20 @@ description: "When code implementation, feature coding, or translating a technic
         - {subsystem.test}（如有）
         - {subsystem.lint}（如有）
      f. 记录验证结果
+     g. **【强制】子系统切换检查**：
+        - 确认 Layer 1 验证通过（build/test/lint 全部 pass）
+        - 更新子系统状态为 completed
+        - 偏航自检：对照设计方案，确认无偏离
+        - 记录到 .autospec/monitoring-issues.json（如有问题）
    ```
 
-3. **集成验证**：
+3. **【强制】集成验证前检查**：
+   - 检查所有子系统状态是否为 completed
+   - 检查是否有未解决的 monitoring issues
+   - 确认依赖包复用检查通过
+   - 任一子系统未完成 → 阻塞集成验证
+
+4. **集成验证**（所有子系统完成后）：
    - 验证跨系统接口联调
    - 验证数据流正确性
    - 记录集成问题
@@ -81,6 +132,44 @@ description: "When code implementation, feature coding, or translating a technic
 - 评测脚本开发（如设计阶段定义）
 - 效果验证脚本
 
+## 阶段检查点（本阶段必须完成）
+
+执行过程中请持续对照以下检查点，确保不遗漏：
+
+**说明**：
+- **检查点表**：快速验证产出是否存在/完成
+- **检查清单（checklists/）**：详细验证产出质量是否达标
+- 通过"检查清单核对完成"一项覆盖所有质量检查，避免重复
+
+| 类别 | 检查项 | 必须完成 | 验证方式 |
+|-----|-------|---------|---------|
+| 流程 | 复杂度评估/继承完成 | ✅ | 检查是否已有复杂度分数和角色列表 |
+| 流程 | 动态团队组建完成 | ✅ | 检查是否已根据复杂度确定参与角色 |
+| 做类 | 编码执行Agent加载完成 | ✅ | 已加载 implement-code skill |
+| 做类 | 编码执行Agent正确执行 | ✅ | 已执行编码任务（模块/接口/数据模型）并产出代码 |
+| 做类 | 代码汇总完成 | ✅ | 各Agent产出已合并到正确文件 |
+| 流程 | 团队对抗审查执行（审类） | ✅ | 检查是否已调用 team-orchestrator 并汇总审查报告 |
+| 流程 | consistency-checker Agent 调用 | ✅ | 代码-设计一致性检查 |
+| 流程 | independent-reviewer Agent 调用 | ✅ | Layer 2 审查必须调用 |
+| 产出 | 检查清单核对完成 | ✅ | 已按 02-code.md 逐项核对并记录（质量检查） |
+| 流程 | Layer 1 验证通过 | ✅ | 编译/测试/Lint 全部通过 |
+| 流程 | Benchmark 评测通过 | ✅ | IMP-001~003 全部通过 |
+
+**阶段完成前自检**：
+- [ ] 已完成复杂度评估或继承
+- [ ] 已组建动态团队（根据复杂度确定角色）
+- [ ] 已加载编码执行Agent（implement-code skill）
+- [ ] 已执行编码任务（模块/接口/数据模型）
+- [ ] 代码已汇总到正确文件
+- [ ] 已执行团队对抗审查（调用 team-orchestrator）
+- [ ] 已按检查清单（02-code.md）逐项核对（质量检查）
+- [ ] 已调用 consistency-checker（代码-设计一致性）
+- [ ] 已调用 independent-reviewer（Layer 2）
+- [ ] Layer 1 验证已通过（编译/测试/Lint）
+- [ ] Benchmark 评测已通过（Layer 3）
+- [ ] Layer 1 验证已通过（编译/测试/Lint）
+- [ ] Benchmark 评测已通过（Layer 3）
+
 ## 认知纪律（本阶段：严格执行 + 偏航检测）
 
 - **CP8 偏航检测**：编码过程中持续对照技术方案。发现偏离时：
@@ -92,6 +181,30 @@ description: "When code implementation, feature coding, or translating a technic
 
 ## 验证
 
+### 阶段完成验证（阻塞检查）
+
+**【强制】【不可跳过】** 在执行 Layer1 验证之前，必须验证以下条件：
+
+```
+验证清单：
+□ 上游设计文档存在（design.md）
+□ 代码已按方案实现
+□ 依赖包复用检查已完成
+□ 代码注释规范已满足
+□ 多系统模式下各子系统已完成
+```
+
+**验证失败处理**：
+
+| 缺失项 | 处理方式 |
+|--------|----------|
+| 设计文档不存在 | 返回方案设计阶段 |
+| 依赖包检查未完成 | 执行依赖包检查 |
+| 代码注释不满足 | 补充注释 |
+| 子系统未完成 | 继续完成子系统 |
+
+**【禁止】** 验证未通过时，禁止进入 Layer1 验证。
+
 ### Layer 1: 确定性验证（必须真实执行）
 
 **单系统模式**：
@@ -112,12 +225,40 @@ description: "When code implementation, feature coding, or translating a technic
 - **数据系统**：数据质量检查通过、ETL流程可执行
 - **AI/模型系统**：模型可加载、推理可执行、评测脚本可运行
 
+### 团队对抗审查（按复杂度）
+
+**【强制】** 根据复杂度评估结果，启动团队智能体并行审查：
+
+#### 简单任务（score <= 5）
+- 技术负责人：架构合理性、代码质量
+
+#### 中等任务（score 6-8）
+- 技术负责人 + 相关工程师（根据子系统类型）
+
+#### 复杂任务（score >= 9）
+- 技术负责人 + 后端工程师 + 前端工程师 + 相关工程师
+- 如触发强制规则，额外引入安全工程师/运维工程师
+
+**执行方式**：
+```
+**【强制】** 读取 `${KNOWLEDGE}/03-guides/01-team-orchestrator.md`
+并行启动团队智能体审查代码：
+  - 技术负责人 Agent：架构合理性、技术选型
+  - 后端工程师 Agent：API设计、数据库设计、性能
+  - 前端工程师 Agent：组件设计、状态管理
+  - 数据工程师 Agent：数据模型、ETL流程（如涉及数据系统）
+  - AI工程师 Agent：模型代码、评测代码（如涉及AI系统）
+  - 安全工程师 Agent：安全漏洞检查（如触发）
+  - 运维工程师 Agent：部署可行性（如触发）
+汇总审查意见，生成团队审查报告
+```
+
 ### Layer 2: AI审查（做审分离）
 使用 **independent-reviewer** Agent 执行独立审查：
 ```
 **【强制】** 调用 Agent 工具：
   prompt: 请审查以下代码实现。
-    1. 先读取审查标准: ${KNOWLEDGE}/guides/stages/code-reviewer.md
+    1. 先读取审查标准: ${KNOWLEDGE}/03-guides/11-review-code.md
     2. 被审查的代码（提供变更文件列表和路径）
     3. 上游技术方案: .autospec/specs/{feature}/design.md（或 design/ 目录）
     4. 上游需求文档: .autospec/specs/{feature}/requirement.md
@@ -142,7 +283,7 @@ description: "When code implementation, feature coding, or translating a technic
    - 生成改进建议
    - 返回 Step 2 修正代码
    - 最多重试 3 次
-5. 如评测通过：
+8. 如评测通过：
    - 记录评测结果
    - 允许进入 testing stage
 ```
@@ -160,7 +301,7 @@ description: "When code implementation, feature coding, or translating a technic
   prompt: 请评估编码实现阶段的产出物是否达到准出标准。
     当前阶段：Stage 03 编码实现
     产出物：代码变更文件列表
-    准出标准：${KNOWLEDGE}/checklists/code.md
+    准出标准：knowledge/04-checklists/02-code.md
     上游契约：.autospec/specs/{feature}/design.md（或 design/ 目录）
     自主级别：{自主/交互}
 ```

package/plugins/skills/layer1-validation/SKILL.md

@@ -76,4 +76,4 @@ for subsystem in config.subsystems:
 | frontend | 前端 | ✅/❌/⚠️ | ✅/❌ | ✅/❌ | ✅/❌ |
 | ai | AI/模型 | - | ✅/❌ | ✅/❌ | - |
 
-可使用 `/autospec:validate` 命令执行完整验证。
+可使用 `/autospec:test` 命令执行完整验证。

package/plugins/skills/pending-dashboard/SKILL.md

@@ -39,23 +39,24 @@ description: "When a new Claude Code session starts in a project with .autospec/
 - 自主模式成功完成 ≥ 5 次 → 积累足够信任
 
 ### 6. 记忆系统状态
-扫描记忆系统状态：
+扫描记忆系统状态（使用 memory-manager.js API）：
 
 **全局记忆检查**：
-- 检查 `~/.autospec-global/autospec:memory/` 是否存在
-- 如果不存在 → 提示首次使用需要初始化全局记忆
-- 如果存在但 `team-preferences.json` 为空 → 提示配置团队偏好
+- 调用 `hasGlobalMemory()` 检查是否存在
+- 如果返回 false → 提示首次使用需要初始化全局记忆
+- 如果存在，调用 `getMemory(MEMORY_SCOPE.GLOBAL, 'team-preferences.json')`：
+  - 如果为空 → 提示配置团队偏好
 
 **项目记忆检查**：
-- 检查 `.autospec/autospec:memory/` 是否存在
-- 如果不存在 → 提示初始化项目记忆
-- 如果存在，读取 `core/north-star.json`：
+- 调用 `hasProjectMemory(projectRoot)` 检查是否存在
+- 如果返回 false → 提示初始化项目记忆
+- 如果存在，调用 `getNorthStar(projectRoot)`：
   - 如果 `mission` 为空 → 提示填写北极星指标
   - 如果 `northStarMetric.current` 与 `target` 差距 > 10% → 提示指标进度落后
   - 如果 `lastUpdated` 超过 30 天 → 提示核心记忆可能过期
 
 **待确认记忆**：
-- 检查 `.autospec/autospec:memory/memory-meta.json` 中是否有 `pendingExtractions`
+- 调用 `getMemory(MEMORY_SCOPE.PROJECT, 'memory-meta.json', projectRoot)` 检查是否有 `pendingExtractions`
 - 如果有待确认的记忆提取 → 提示用户确认
 
 ## 输出格式

package/plugins/skills/project-evolve-analyzer/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: project-evolve-analyzer
+description: "问题分析：分析项目代码质量，识别问题，提供改进建议"
+type: analyzer
+---
+
+# Project-Evolve Analyzer
+
+## 定位
+
+问题分析技能，分析项目代码质量，识别问题，提供改进建议。
+
+## 输入
+
+- 扫描结果（来自 scanner）
+- 修复历史（来自 fixer）
+
+## 输出
+
+- 问题清单：问题描述、严重程度、影响范围
+- 改进建议：优先级排序、具体方案
+- 分析报告：质量评分、趋势分析
+
+## 执行步骤
+
+### Step 1: 问题识别
+
+```
+分析扫描结果：
+1. 代码复杂度分析
+2. 重复代码检测
+3. 死代码识别
+4. 测试缺口分析
+```
+
+### Step 2: 根因分析
+
+```
+对每个问题：
+1. 定位问题位置
+2. 分析问题原因
+3. 评估影响范围
+4. 确定严重程度
+```
+
+### Step 3: 建议生成
+
+```
+生成改进建议：
+1. 按优先级排序
+2. 提供具体方案
+3. 预测修复效果
+4. 标记自动/手动
+```
+
+### Step 4: 报告生成
+
+```
+生成分析报告：
+1. 质量评分
+2. 问题统计
+3. 改进建议
+4. 趋势分析
+```
+
+## 使用示例
+
+```
+# 执行问题分析
+读取 plugins/skills/project-evolve-analyzer/SKILL.md 并执行
+
+# 输出
+- 问题数: 25
+- 严重问题: 5
+- 改进建议: 12
+- 质量评分: 78/100
+```
+
+## 分析维度
+
+| 维度 | 分析内容 | 权重 |
+|------|----------|------|
+| 代码质量 | 复杂度、重复、死代码 | 25% |
+| 测试体系 | 覆盖率、边界、异常 | 25% |
+| 文档完整性 | README、API、CHANGELOG | 20% |
+| 配置工程 | 构建、依赖、CI/CD | 15% |
+| 架构设计 | 模块边界、依赖关系 | 15% |
+
+## 与 self-evolve-analyzer 的区别
+
+| 特性 | self-evolve-analyzer | project-evolve-analyzer |
+|------|---------------------|------------------------|
+| 目标 | 分析框架问题 | 分析项目问题 |
+| 分析对象 | 框架代码 | 用户项目代码 |
+| 评分标准 | 框架质量标准 | 项目质量标准 |

package/plugins/skills/project-evolve-fixer/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: project-evolve-fixer
+description: "自动修复：对项目代码进行自动化修复，包括代码规范、格式化、未使用导入等"
+type: fixer
+---
+
+# Project-Evolve Fixer
+
+## 定位
+
+自动修复技能，对项目代码进行自动化修复，包括代码规范、格式化、未使用导入等。
+
+## 输入
+
+- 扫描结果（来自 scanner）
+- 修复类型：automatic（自动）/suggested（建议）
+
+## 输出
+
+- 修复记录：修复的文件、变更内容
+- 修复报告：修复数量、成功率
+- 退化检测：如有问题自动回滚
+
+## 执行步骤
+
+### Step 1: 修复类型判断
+
+```
+L1 自动修复（无需确认）：
+- 代码格式化
+- 未使用导入清理
+- 简单命名规范化
+- 依赖安全升级
+
+L2 建议修复（需确认）：
+- 复杂重构
+- 架构调整
+- 性能优化
+```
+
+### Step 2: 执行自动修复
+
+```
+对每个 L1 修复项：
+1. 备份原文件
+2. 执行修复
+3. 验证修复
+4. 记录变更
+```
+
+### Step 3: 生成建议
+
+```
+对每个 L2 修复项：
+1. 分析问题
+2. 生成修复方案
+3. 等待确认
+4. 执行或跳过
+```
+
+### Step 4: 验证与回滚
+
+```
+1. 运行测试验证
+2. 检查是否有退化
+3. 如有问题自动回滚
+4. 记录修复结果
+```
+
+## 使用示例
+
+```
+# 执行自动修复
+读取 plugins/skills/project-evolve-fixer/SKILL.md 并执行
+
+# 输出
+- 自动修复: 15项
+- 建议修复: 8项
+- 成功率: 100%
+```
+
+## 修复能力
+
+| 修复类型 | 自动/建议 | 说明 |
+|----------|----------|------|
+| 代码格式化 | 自动 | Prettier/ESLint |
+| 未使用导入 | 自动 | import 清理 |
+| 命名规范化 | 自动 | 驼峰/蛇形 |
+| 依赖升级 | 自动 | 安全补丁 |
+| 复杂重构 | 建议 | 需人工确认 |
+| 性能优化 | 建议 | 需人工确认 |
+
+## 与 self-evolve-iterator 的区别
+
+| 特性 | self-evolve-iterator | project-evolve-fixer |
+|------|----------------------|---------------------|
+| 目标 | 框架自我修复 | 项目代码修复 |
+| 修复范围 | 框架代码 | 用户项目代码 |
+| 修复类型 | 配置/模板 | 实际代码 |

package/plugins/skills/project-evolve-generator/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: project-evolve-generator
+description: "基于项目特征自动生成 benchmark，用于项目自我评测"
+type: generator
+---
+
+# Project-Evolve Generator
+
+## 定位
+
+基于项目特征自动生成 benchmark，用于项目自我评测。
+
+## 输入
+
+- 项目路径（必需）
+- benchmark 名称（可选）
+
+## 输出
+
+- benchmark 配置文件：`.autospec/benchmarks/project-{name}.yaml`
+
+## 执行步骤
+
+### Step 1: 项目类型检测
+
+```
+检测项目类型：
+1. nodejs: package.json
+2. java: pom.xml, build.gradle, build.gradle.kts
+3. go: go.mod
+4. python: requirements.txt, pyproject.toml, setup.py
+5. rust: Cargo.toml
+6. ruby: Gemfile
+```
+
+### Step 2: 项目框架检测
+
+```
+检测框架类型：
+- nodejs: react, vue, next, nuxt, express, nest
+- java: spring-boot, spring, dubbo
+- python: django, fastapi, flask
+```
+
+### Step 3: 项目结构扫描
+
+```
+扫描目录结构：
+1. 检测根目录下的子目录
+2. 识别测试目录（tests/test）
+3. 识别文档目录（docs/documentation）
+4. 识别源码目录（src/lib）
+```
+
+### Step 4: Benchmark 生成
+
+```
+生成 benchmark 配置：
+1. 基于项目类型生成基础配置
+2. 设置 pipeline 为 waterfall
+3. 定义各阶段验收标准
+4. 设置质量指标阈值
+```
+
+### Step 5: 保存 Benchmark
+
+```
+保存配置：
+1. 输出到 .autospec/benchmarks/
+2. 文件命名：project-{name}.yaml
+3. 使用 YAML 格式
+```
+
+## 使用示例
+
+```
+# 生成 benchmark
+读取 plugins/skills/project-evolve-generator/SKILL.md 并执行
+
+# 输入
+- 项目路径: ./my-project
+
+# 输出
+- Benchmark: .autospec/benchmarks/project-my-project.yaml
+```
+
+## Benchmark 结构
+
+```yaml
+pipeline: waterfall
+description: 基于项目自动生成的 benchmark
+
+scenario:
+  name: {项目名} 开发能力测试
+  input: 评估 {项目类型} 项目的开发能力
+  complexity: medium
+  expectedStages:
+    - requirement
+    - design
+    - implement
+    - test
+    - deliver
+
+stageCriteria:
+  requirement:
+    expectedArtifacts:
+      - specs/{项目名}/requirement.md
+    successCriteria:
+      - 需求描述清晰
+      - 验收标准完整
+
+  design:
+    expectedArtifacts:
+      - specs/{项目名}/design.md
+    successCriteria:
+      - 架构设计合理
+      - API 定义完整
+
+  implement:
+    expectedArtifacts:
+      - src/ 源代码
+      - tests/ 测试代码
+    successCriteria:
+      - 代码编译通过
+      - 单元测试通过
+
+  test:
+    expectedArtifacts:
+      - tests/ 测试报告
+    successCriteria:
+      - 测试用例完整
+      - 测试通过
+
+  deliver:
+    expectedArtifacts:
+      - release-notes.md
+    successCriteria:
+      - 发布说明完整
+```
+
+## 与其他技能的区别
+
+| 技能 | 侧重点 |
+|------|--------|
+| scanner | 扫描项目问题 |
+| fixer | 自动修复问题 |
+| analyzer | 分析问题根因 |
+| verifier | 验证修复效果 |
+| **generator** | 生成 benchmark |