diff --git a/docs/milestone-propose-requirements.md b/docs/milestone-propose-requirements.md
index d2f8896..06be85c 100644
--- a/docs/milestone-propose-requirements.md
+++ b/docs/milestone-propose-requirements.md
@@ -6,6 +6,73 @@
 
 ---
 
+## 0. 开发状态
+
+### 2026-03-16 23:49 UTC（第 1 轮：基线盘点 + 自动开发调度）
+
+当前进度：已启动按小时推进的开发节奏，先完成一轮代码基线盘点，方便后续按模块逐步落地。
+
+本轮已确认：
+- 后端 milestone 旧状态枚举仍在使用：`open / pending / deferred / progressing / closed`
+  - 位置：`HarborForge.Backend/app/models/milestone.py`
+- 后端 task 旧状态枚举仍在使用：`open / pending / progressing / closed`
+  - 位置：`HarborForge.Backend/app/models/task.py`、`HarborForge.Backend/app/models/models.py`、`HarborForge.Backend/app/schemas/schemas.py`
+- 后端与前端都还有多处写死 `progressing` / `pending` / `deferred`
+  - 典型位置：
+    - 后端：`app/api/routers/milestones.py`、`app/api/routers/tasks.py`、`cli.py`
+    - 前端：`src/types/index.ts`、`src/components/MilestoneFormModal.tsx`、`src/pages/MilestoneDetailPage.tsx`、`src/pages/TaskDetailPage.tsx`
+- `task_type = task` 仍真实存在，且当前主要表现为 `subtype = defect`
+  - 后端：`HarborForge.Backend/app/api/routers/tasks.py` 的 `TASK_SUBTYPE_MAP`
+  - 前端：`HarborForge.Frontend/src/components/CreateTaskModal.tsx`、`HarborForge.Frontend/src/pages/CreateTaskPage.tsx`
+
+当前判断：
+- 下一步最合适的是先做 **P0/P1 之间的“状态枚举与迁移骨架”**，否则后续 milestone / task / propose 的接口实现会反复返工。
+- 具体优先级建议：
+  1. 先统一后端 milestone/task 新旧状态枚举与 schema
+  2. 再补 migration / 兼容映射
+  3. 然后推进动作接口、权限、前端按钮与页面
+
+阻塞项：
+- 暂无硬阻塞；但 `closed` / `completed` 的终态与 task reopen 已写入需求，后续实现时要一次性考虑兼容，避免先做死状态流转。
+
+### 2026-03-17 00:00 UTC（第 2 轮：后端状态枚举全量替换）
+
+本轮做了什么：
+- 将 milestone 和 task 的后端状态枚举全部替换为新值
+- Milestone: `open/pending/deferred/progressing/closed` → `open/freeze/undergoing/completed/closed`
+- Task: `open/pending/progressing/closed` → `open/pending/undergoing/completed/closed`
+- 新增 `MilestoneStatusEnum` 到 schemas.py，milestone 的 create/update/response 现在使用类型化枚举而非裸字符串
+- 新增 `started_at` 字段到 Milestone model 和 MilestoneResponse
+- 更新所有 router（milestones.py, tasks.py, misc.py）中 `progressing` → `undergoing` 引用
+- 更新 task transition 逻辑支持 `completed` 状态自动记录 `finished_on`
+- 更新 CLI status icon 映射和 choices 参数
+
+改了哪些关键文件：
+- `HarborForge.Backend/app/models/milestone.py` — enum + started_at
+- `HarborForge.Backend/app/models/task.py` — enum
+- `HarborForge.Backend/app/models/models.py` — enum
+- `HarborForge.Backend/app/schemas/schemas.py` — MilestoneStatusEnum + TaskStatusEnum + started_at
+- `HarborForge.Backend/app/api/routers/milestones.py` — progressing→undergoing
+- `HarborForge.Backend/app/api/routers/tasks.py` — progressing→undergoing, completed handling
+- `HarborForge.Backend/app/api/routers/misc.py` — progressing→undergoing (3处)
+- `HarborForge.Backend/cli.py` — status icons + choices
+
+验证结果：
+- 全部 8 个文件 Python AST 语法检查通过
+- 后端无 sqlalchemy 环境无法做运行时验证，但枚举定义和引用已全部对齐
+- grep 确认后端代码中不再有 `progressing`/`deferred` 残留
+
+当前阻塞/风险：
+- 数据库迁移脚本尚未编写（MySQL enum 列需要 ALTER TABLE 才能接受新值）
+- 前端仍使用旧状态值，需要同步更新
+- 没有本地 DB/Docker 环境做集成验证
+
+下一轮最建议继续做什么：
+- P1.5 数据库迁移骨架：编写 Alembic 或手写 SQL 迁移脚本，处理 MySQL enum 列的 ALTER 和旧数据映射
+- 或者先做前端 TypeScript 类型定义更新（影响面小、独立性强）
+
+---
+
 ## 1. 背景
 
 当前希望把 milestone 的推进过程做成一个更严格的状态机，并把 feature story 的进入方式从“直接创建 task”改为“先提 propose，再 accept 进入 milestone”。