# 版本控制规则

## 版本号格式

```
主版本.次版本.补丁版本
  0       1       0
```

## 升级规则

| 变更类型 | 升级幅度 | 例子 |
|---------|---------|------|
| 修复错别字、格式调整 | +0.0.1 | 0.3.0 → 0.3.1 |
| 新增1-2个场景对话 | +0.0.1 | 0.3.1 → 0.3.2 |
| 新增1个AI prompt | +0.0.1 | 0.3.2 → 0.3.3 |
| 重组章节、新增小节 | +0.1.0 | 0.3.x → 0.4.0 |
| 哲学框架重构、多章节重写 | +1.0.0 | 0.x.0 → 1.0.0 |

## 当前阶段

**v0.x 阶段**：大量小步迭代，快速成熟期
- 目标：经历 **100+ 次 0.0.1 升级**
- 每个 0.0.1 升级必须包含：至少一个具体的增量（场景/prompt/表述）
- 不追求大版本，追求高频迭代

---

## 推送规则

### 核心规则

> **升级10次，推送1次。**

### 具体流程

```
1. 本地开发：
   - 每次升级 +0.0.1（本地 commit）
   - 不 push，只 commit

2. 每满10次升级：
   - git log 确认 10 次增量
   - 检查所有文件一致性
   - git push origin main

3. 使用 github-sync 推送：
   - 推荐用 git 命令直接 push
   - 仓库已有远程配置，无需额外工具
```

### 推送命令

```bash
# 本地开发（不推送）
git add .
git commit -m "v0.3.x: 具体升级内容"

# 满10次后推送
git push origin main
```

### 为什么10次一推送

- 减少 commit 噪音
- 保持 GitHub 历史整洁
- 批量迭代更有节奏

---

## 版本历史原则

1. **每次升级必须有实际增量**——不能为了升级而升级
2. **小步快跑**——0.0.1 也是进步
3. **记录每个 0.0.1**——累积量变到质变
4. **大版本慎重**——只有重大重构才 +1.0.0
5. **10次一推送**——保持节奏，不频繁打扰

---

## 目标

```
v0.1.0  →  初始版本
v0.2.0  →  第一次架构整理
v0.3.0  →  第二次哲学融合
   ↓
   [100+次 0.0.1 小步迭代]
   ↓
v1.0.0  →  技能成熟，可发布
```

---

**当前版本：v0.9.2**
**唯一真相源：VERSION 文件**
**下一个版本：v0.9.3**
**升级命令：python scripts/version_sync.py 0.8.9**
