107 lines
2.7 KiB
Markdown
107 lines
2.7 KiB
Markdown
# 文档现状分析与迁移规划
|
||
|
||
**日期：** 2026-08-07
|
||
**范围：** 工作区根目录、`lineup-app/`、现有 `agent_ops/设计/`
|
||
**目标：** 为 `agent_ops/` 建立由 agent 持续维护的文档目录结构和迁移顺序
|
||
|
||
## 1. 现状结论
|
||
|
||
当前文档资产主要来自三个来源：
|
||
|
||
1. 工作区根目录的项目级文档；
|
||
2. `lineup-app/` 的客户端文档体系；
|
||
3. `agent_ops/设计/` 中已有的设计历史材料。
|
||
|
||
它们的内容本身已经开始形成边界，但入口分散、时效性标注不统一、历史与当前有效资料仍有混放。
|
||
|
||
## 2. 当前文档的四种角色
|
||
|
||
### 2.1 权威入口
|
||
|
||
负责快速建立共识与导航，例如：
|
||
|
||
- 根 `README.md`
|
||
- `lineup-app/README.md`
|
||
- `lineup-app/设计/README.md`
|
||
- `lineup-app/迭代/README.md`
|
||
|
||
### 2.2 持续事实
|
||
|
||
反映当前已实现、已验证、已知限制与当前阶段判断，例如：
|
||
|
||
- `项目状态记录.md`
|
||
- 根 `程序文件清单与功能说明.md`
|
||
- `lineup-app/程序文件清单与功能说明.md`
|
||
- `lineup-app/迭代/plan.md`
|
||
|
||
### 2.3 当前有效设计
|
||
|
||
仍然对实现有约束力，例如：
|
||
|
||
- `lineup-app/设计/APP架构设计.md`
|
||
- `lineup-app/设计/02.正式方案/*.md`
|
||
- `lineup-app-server/DESIGN.md`
|
||
|
||
### 2.4 历史归档
|
||
|
||
保留背景和演进上下文，但不再直接指导当前实现，例如：
|
||
|
||
- `agent_ops/设计/00.records/*`
|
||
- `agent_ops/设计/01.前期分析与设计/*`
|
||
- 已完成阶段的旧评审记录
|
||
|
||
## 3. 为什么不能直接搬运
|
||
|
||
如果只是把原文档换个目录继续堆放，会保留以下问题：
|
||
|
||
- 多份内容重复但没有权威版本；
|
||
- 文档中的“最后核验时间”仍然散落，读者不容易判断哪些结论仍可信；
|
||
- 项目总览、运行状态、程序清单、设计和迭代会继续混放；
|
||
- 早期设计和当前生效设计无法快速区分。
|
||
|
||
因此迁移必须以“整合、改写、重定入口”为主，而不是简单复制。
|
||
|
||
## 4. 目标目录结构
|
||
|
||
```text
|
||
agent_ops/
|
||
├── 00.目录治理/
|
||
├── 01.项目总览/
|
||
├── 02.架构设计/
|
||
├── 03.迭代规划/
|
||
├── 04.程序清单/
|
||
├── 05.运行运维/
|
||
└── 90.历史归档/
|
||
```
|
||
|
||
## 5. 迁移顺序
|
||
|
||
### 第一阶段
|
||
|
||
先整合工作区根目录文档：
|
||
|
||
- 项目总览；
|
||
- 当前状态；
|
||
- 仓库职责边界；
|
||
- 跨仓程序清单。
|
||
|
||
### 第二阶段
|
||
|
||
整合 `lineup-app/设计/`：
|
||
|
||
- 提炼当前有效设计；
|
||
- 把历史背景和正式方案分开；
|
||
- 建立面向实现的设计入口。
|
||
|
||
### 第三阶段
|
||
|
||
整合 `lineup-app/迭代/`：
|
||
|
||
- 分离总体计划与具体迭代；
|
||
- 保留设计评审与验收评审链路；
|
||
- 建立可持续追踪的阶段索引。
|
||
|
||
## 6. 本轮输出
|
||
|
||
本轮已进入第一阶段，并已在新目录中落位第一批整合文档。
|