agent_ops/00.目录治理/01.文档现状分析与迁移规划.md

文档现状分析与迁移规划

日期： 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. 目标目录结构

agent_ops/
├── 00.目录治理/
├── 01.项目总览/
├── 02.架构设计/
├── 03.迭代规划/
├── 04.程序清单/
├── 05.运行运维/
└── 90.历史归档/

5. 迁移顺序

第一阶段

先整合工作区根目录文档：

• 项目总览；
• 当前状态；
• 仓库职责边界；
• 跨仓程序清单。

第二阶段

整合 lineup-app/设计/：

• 提炼当前有效设计；
• 把历史背景和正式方案分开；
• 建立面向实现的设计入口。

第三阶段

整合 lineup-app/迭代/：

• 分离总体计划与具体迭代；
• 保留设计评审与验收评审链路；
• 建立可持续追踪的阶段索引。

6. 本轮输出

本轮已进入第一阶段，并已在新目录中落位第一批整合文档。