docs: 分支策略（简化版 GitFlow）文档

docs/decisions/0005-branching-strategy.md

@@ -0,0 +1,30 @@
+# ADR 0005：分支策略（简化版 GitFlow）
+
+- **状态**：已接受
+- **日期**：2026-09-04
+
+## 背景
+
+项目进入多模块骨架建设阶段，单人/小团队开发。需要明确一套分支流，既保证 `main` 始终可发布，又不引入超过当前规模的开销。当前 `dev` 与 `main` 处于同一 commit（尚未分叉），正是定策略的时机。
+
+## 决策
+
+采用**简化版 GitFlow**：
+
+- `feature/<name>` 从 `dev` 拉取，完成后 **merge 回 `dev`**（不直接进 `main`）。
+- `dev` 作为集成点，保持可构建；所有 feature 先合入这里。
+- `dev` 稳定后，**经人工确认**再 merge 回 `main`。
+- 当前阶段**不引入 `release/*`**；`hotfix/<name>`（从 `main` 拉，合回 `main` + `dev`）按需使用。
+
+日常操作细节见 [docs/gitflow.md](../gitflow.md)。
+
+## 理由
+
+- 严格 GitFlow 中，`main` 只经 `release/*` / `hotfix/*` 进入，feature 永不直接碰 `main`。在基础建设阶段，`release/*` 分支是纯负担。
+- 简化版保留了两个关键性质：**`dev` 是集成点**（隔离未稳定代码）、**`main` 只放可发布状态**，同时免去 release 分支的管理开销。
+- 与 `feature/<name>/` 模块目录名对齐的命名，让分支与代码结构一一对应。
+
+## 后果
+
+- `main` 始终为可发布状态；进入 `main` 的合并必须人工确认。
+- 未来团队扩大或进入正式发布周期，可平滑升级为完整 GitFlow（引入 `release/*`、正式版本 tag），无需推翻现有模型。