self-evolve-framework 1.0.5 → 1.0.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -13,6 +13,7 @@ alwaysApply: true
|
|
|
13
13
|
self-evolve.mdc（编排层 — 当前文件）
|
|
14
14
|
├── ponytail.mdc → 代码最小化检查（每个操作前）
|
|
15
15
|
├── CodeGraph MCP → 依赖图分析（重构/调 bug 时）
|
|
16
|
+
├── 核心边界审计 → 删/改功能前确认承重墙（本文件内联）
|
|
16
17
|
└── skillopt-sleep → 离线进化分析（按需调）
|
|
17
18
|
↓
|
|
18
19
|
post-edit 验证闭环 ← ⭐ 核心
|
|
@@ -24,13 +25,16 @@ self-evolve.mdc（编排层 — 当前文件）
|
|
|
24
25
|
|
|
25
26
|
### 步骤 1：前置检查（修改前）
|
|
26
27
|
```
|
|
27
|
-
┌─ 修改范围 > 3
|
|
28
|
-
|
|
28
|
+
┌─ 修改范围 > 3 个文件？──────→ 调 Ponytail 约束 → 询问用户是否可缩小
|
|
29
|
+
├─ 重构/修复 bug？─────────→ 调 CodeGraph MCP → 评估影响范围
|
|
30
|
+
└─ ★ 删/重构功能代码？──────→ 核心边界审计 → 问"这段代码影响哪条用户路径？删了谁兜底？"
|
|
29
31
|
```
|
|
30
32
|
|
|
31
33
|
### 步骤 2：执行修改
|
|
32
34
|
按 Ponytail 原则写最少代码。
|
|
33
35
|
|
|
36
|
+
**核心边界约束**：如果涉及功能删减，确保受影响的核心路径有替代方案兜底，并在注释或 commit 信息中注明承重墙依据。
|
|
37
|
+
|
|
34
38
|
### 步骤 3：自动验证（修改后）
|
|
35
39
|
```
|
|
36
40
|
1. 前端：运行 npm run build
|
|
@@ -55,6 +59,11 @@ self-evolve.mdc（编排层 — 当前文件）
|
|
|
55
59
|
|
|
56
60
|
同类型错误出现 ≥2 次 → 自动创建规则：
|
|
57
61
|
create .codebuddy/rules/{pattern-name}.mdc
|
|
62
|
+
|
|
63
|
+
涉及核心功能路径的修改，额外记录：
|
|
64
|
+
- 受影响路径
|
|
65
|
+
- 兜底方案
|
|
66
|
+
- 当前依赖方（谁在调用/依赖这段代码）
|
|
58
67
|
```
|
|
59
68
|
|
|
60
69
|
### 步骤 5：会话结束检查
|
|
@@ -63,6 +72,25 @@ self-evolve.mdc（编排层 — 当前文件）
|
|
|
63
72
|
→ 超过 7 天 → 提示："项目已 {N} 天未审计，需要跑 skillopt-sleep 吗？"
|
|
64
73
|
```
|
|
65
74
|
|
|
75
|
+
## 🔧 核心边界审计规则
|
|
76
|
+
|
|
77
|
+
> 删改功能代码前必经的一道门——不是阻止删，而是确保删之前知道不能丢什么。
|
|
78
|
+
|
|
79
|
+
### 审计步骤
|
|
80
|
+
|
|
81
|
+
```
|
|
82
|
+
1. 定位：这段代码影响哪些用户可见的功能路径？
|
|
83
|
+
2. 溯源：谁在调用/依赖这段代码？→ 调 codegraph_callers
|
|
84
|
+
3. 兜底：如果没有这段代码，受影响的功能还有没有其他实现路径？
|
|
85
|
+
4. 结论：
|
|
86
|
+
✅ 有兜底 → 可以删，commit 信息注明兜底方案
|
|
87
|
+
⚠️ 无兜底 → 不能直接删，先补兜底或向用户说明风险
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
### 关键词触发
|
|
91
|
+
|
|
92
|
+
`删除`、`弃用`、`移除`、`deprecated`、`不再需要`、`改接口`、`重构`
|
|
93
|
+
|
|
66
94
|
## 🔧 CodeGraph MCP 使用规则
|
|
67
95
|
|
|
68
96
|
| 场景 | 必须调用的工具 |
|
|
@@ -22,6 +22,7 @@ AI 从以下来源收集项目数据：
|
|
|
22
22
|
- **代码异嗅**：循环依赖、过度耦合、重复代码
|
|
23
23
|
- **缺失约束**：重复发生但无规则防范的问题
|
|
24
24
|
- **优化机会**：可简化的逻辑、可合并的文件
|
|
25
|
+
- **★ 核心边界**：识别模块间的契约接口、关键用户路径和其依赖方，标记"改/删前必须审慎"的承重区域
|
|
25
26
|
|
|
26
27
|
### 阶段 3：Replay — 回放验证
|
|
27
28
|
对每个发现的问题：
|
|
@@ -35,6 +36,7 @@ AI 从以下来源收集项目数据：
|
|
|
35
36
|
- **更新规则**：现有规则描述模糊或过时
|
|
36
37
|
- **删除规则**：不再相关或从未被触发的规则
|
|
37
38
|
- **优化 memory**：合并重复的错误模式记录
|
|
39
|
+
- **★ 边界标记**：涉及核心功能路径的删除/修改建议，加 ⚠️ 标签要求人工确认，不可自动采纳
|
|
38
40
|
|
|
39
41
|
### 阶段 5：Stage — 暂存
|
|
40
42
|
所有建议先写入 `.codebuddy/memory/skillopt-staging/` 目录，**不修改任何活文件**。
|