soloforge 1.1.36 → 1.1.37

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "soloforge",
-  "version": "1.1.36",
+  "version": "1.1.37",
   "description": "AI-driven development workflow system - one person does the work of a five-person team",
   "type": "module",
   "main": "dist/index.js",
@@ -72,8 +72,8 @@
   },
   "devDependencies": {
     "@types/node": "^22.0.0",
-    "@vitest/coverage-v8": "^3.2.4",
+    "@vitest/coverage-v8": "^4.1.8",
     "typescript": "^5.7.0",
-    "vitest": "^3.1.0"
+    "vitest": "^4.1.8"
   }
 }

package/templates/procedures//350/256/276/350/256/241/345/256/241/350/256/241/346/265/201/347/250/213.md

@@ -0,0 +1,186 @@
+---
+name: audit-design-procedure
+type: procedure
+when: '设计审计, 详细设计审计, 架构审计, 设计审核, 审核设计, audit design, design audit, 接口审计'
+scope:
+  - backend
+  - frontend
+  - infrastructure
+products:
+  - '*'
+id: ka-procedure-设计审计流程
+asset_kind: procedure
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-intent-expander
+routes:
+  - analysis
+  - review
+primary_triggers:
+  - 设计审计
+  - 详细设计审计
+secondary_triggers:
+  - 设计审核
+  - 审核设计
+  - 架构审计
+negative_triggers: []
+priority: P2
+specificity: 5
+consumes:
+  - mc-intent-router
+  - mc-knowledge-injection-boundary
+  - mc-intent-expander
+emits:
+  - audit_report
+pipeline_scope:
+  - new-system
+  - existing-system
+applicable_tech_stack:
+  - '*'
+---
+
+# 设计审计流程
+
+> **wf-audit-design** 工作流的执行流程契约。
+> 适用场景: 用户对已有设计文档（架构/详细/API/数据库设计）做 6 维度审计，**不修改源文档**。
+> 关联工具: `sf_review` (input_artifacts 模式) / `sf_expand` (audit_design_prompt)。
+
+---
+
+## 1. 触发条件
+
+### 1.1 用户意图识别
+满足以下任一条件进入审计工作流:
+- 意图包含关键词: `审计` / `审核设计` / `设计审计` / `设计审核` / `架构审计` / `详细设计审计` / `audit design`
+- 调用 `sf_review` 时显式传入 `input_artifacts` 参数
+
+### 1.2 前置条件
+- 用户必须指定至少一个 `input_artifacts` 条目（kind + path）
+- 引用的设计文档必须存在于磁盘
+- 路由层推断 `mutation_allowed = false`（审计严格只读）
+
+---
+
+## 2. 6 维度审计清单
+
+每维度必须给出至少 1 条 finding，或显式标记 `no_issue_observed`。**未覆盖即失败**。
+
+### 维度 1: 跨文档一致性
+- 架构文档 / 详细设计 / API 设计 / 数据库设计 命名、边界、调用链是否一致
+- 同一概念是否在不同文档中使用不同名称
+- 接口契约（参数 / 返回 / 异常）在 API 文档与详细设计中是否完全一致
+
+### 维度 2: OOD/SOLID 合规
+- 单一职责: 模块 / 类 / 函数边界是否清晰
+- 开闭原则: 扩展点是否通过抽象隔离
+- 依赖倒置: 高层模块是否依赖抽象而非具体实现
+- 命名 / 分层是否反映职责
+
+### 维度 3: 防孤岛设计
+- 新模块与现有系统的集成点是否明确
+- 是否定义了与上游（消费者）和下游（依赖）的契约
+- 跨团队 / 跨服务协作边界是否清晰
+
+### 维度 4: 契约破坏性
+- 新设计是否破坏已有 API / 事件 / 数据契约
+- 版本兼容性: 是否有 deprecation 路径
+- 客户端 / 调用方升级成本是否评估
+
+### 维度 5: SQL/数据迁移回滚性
+- DDL 是否可回滚（DROP / ALTER 必须有 rollback 脚本）
+- 数据迁移是否可在中断后恢复
+- 是否定义了数据回滚检查点
+- 是否区分可逆 / 不可逆变更（DELETE 无回滚需特别标注）
+
+### 维度 6: 索引/性能覆盖
+- 主链路查询是否有索引支撑
+- 是否评估了 N+1、全表扫描、热点行更新风险
+- 分页 / 排序字段是否有联合索引
+
+---
+
+## 3. 严重度分级
+
+| 级别 | 含义 | 是否阻塞实施 |
+|------|------|--------------|
+| `hard_fail` | 设计错误 / 破坏性变更 / 数据丢失风险 | 是 |
+| `warning` | 建议修改，存在风险但不致命 | 否（建议修复） |
+| `advisory` | 供参考的改进建议 | 否（仅供参考） |
+
+---
+
+## 4. 输出契约 (audit_report)
+
+```typescript
+interface AuditReport {
+  dimensions: Array<{
+    name: string;                       // "跨文档一致性" | "OOD/SOLID" | ...
+    findings: Array<{
+      severity: "hard_fail" | "warning" | "advisory";
+      location: string;                 // 文档路径 + 章节/行号
+      issue_zh: string;                 // 中文问题描述
+      recommendation_zh: string;        // 中文修复建议
+    }> | Array<{ no_issue_observed: true; note_zh: string }>;
+  }>;
+  overall_status: "blocked" | "advisory";
+  blocking_findings_count: number;      // severity=hard_fail 的总数
+  input_artifacts: Array<{ kind: string; path: string }>;
+  audited_at: string;                   // ISO 8601
+}
+```
+
+### 4.1 整体状态判定
+- `blocking_findings_count > 0` → `overall_status = "blocked"`
+- `blocking_findings_count = 0` → `overall_status = "advisory"`
+
+---
+
+## 5. 流程步骤
+
+```
+[用户] sf_classify (intent: "开始详细设计审计", input_artifacts: [...])
+   ↓
+[路由] 识别 audit action → workflow_intent = "audit_design"
+   ↓
+[路由] EXTENSION_WORKFLOW_MAP.audit_design → route=analysis, mutation=false
+   ↓
+[扩展] 加载 audit_design_prompt 模板 + 关联知识（review_rule / pattern）
+   ↓
+[执行] 6 维度审计，每维度遍历 input_artifacts 中相关章节
+   ↓
+[输出] audit_report + blocking_findings_count
+   ↓
+[结束] overall_status="blocked" 时建议用户先修复 hard_fail，再进入实施
+```
+
+---
+
+## 6. 关键约束
+
+1. **不修改源文档**: 审计产物独立输出，源设计文档保持只读
+2. **finding 必须可追溯**: 每条 finding 必须有 location 字段引用具体文档路径 + 章节 / 行号
+3. **不臆断**: 文档中未声明的约束不得作为 finding 依据
+4. **不漏维度**: 6 维度全部覆盖，无 finding 时必须显式标记 `no_issue_observed`
+5. **中文输出**: issue_zh / recommendation_zh / note_zh 字段必须为中文
+
+---
+
+## 7. 关联资产
+
+- **Prompt 模板**: `audit_design_prompt` (`src/engine/pipeline/intent_expander/templates.ts`)
+- **工作流契约**: `wf-audit-design` (`src/engine/workflow/workflow_contract_registry.ts`)
+- **ARTIFACT_ALIASES**: `design_doc` / `detailed_design` / `api_spec` / `database_design`
+- **Pipeline hint**: `code-review`（复用代码审查流程的规则与模式资产）
+
+---
+
+## 8. 与代码审查流程的区别
+
+| 维度 | 代码审查 (code_review) | 设计审计 (audit_design) |
+|------|------------------------|-------------------------|
+| 对象 | 源代码 / diff | 设计文档（Markdown） |
+| 输入 | changed_files + file_contents | input_artifacts (kind + path) |
+| 触发 | "审查代码" / sf_review 无 input_artifacts | "审计设计" / sf_review 带 input_artifacts |
+| 维度 | 编码规范 / BUG / 安全 / 性能 | 跨文档一致性 / OOD / 防孤岛 / 契约 / SQL / 索引 |
+| 输出 | review_report | audit_report |
+| 修改建议 | 直接改代码 | 修改设计文档后重新审计 |