165 lines (117 loc) · 4.89 KB

TGO Network 实施路线图

1. 目的

本文档把已经确定的架构与范围，转化为接下来的执行顺序。

重点关注：

当前所处阶段
接下来优先做什么
哪些事项会阻塞多个模块

2. 执行原则

按纵向业务切片推进，而不是孤立堆技术层
优先冻结边界，再进行界面与逻辑实现
不在旧 topic/city 原型上继续扩张需求
优先完成公开站点与后台的最小运营闭环

3. 当前里程碑概览

里程碑	状态	目标	主要输出
M0	已完成	架构与文档基线	技术栈、边界、规划文档
M1	已完成	工程骨架与基础设施	monorepo、认证、数据库、CI
M2	当前进行中	范围收敛与契约冻结	新版范围、路由、数据模型、API 设计
M3	下一步	前台 7 模块落地	首页、分会、成员、活动、文章、加入、关于
M4	下一步	后台 8 模块落地	仪表盘、文章、活动、申请、成员、工作人员、角色、审计
M5	后续	生产加固	审计完善、监控、备份恢复、部署稳定性
M6	后续	增长能力	手机号登录、签到、通知、分析

4. 当前阶段的关键任务

M2：范围收敛与契约冻结

当前必须先完成：

冻结前台 7 个模块的页面边界
冻结后台 8 个模块的职责边界
冻结 branches / members / join_applications 的数据模型
冻结非成员、成员、工作人员三类身份边界
冻结成员体系与工作人员体系的分离建模原则
冻结新的公开 API 与后台 API
将旧 topics / cities 降为历史探索

完成标准：

产品范围不再继续扩张
路由图、数据模型、API 设计相互一致
后续实现可以直接按文档分工

5. 下一阶段交付顺序

M3：前台能力对齐

推荐先后顺序：

首页
加入说明与申请表
分会董事会
成员列表与详情
活动列表与详情/报名
文章列表与详情
关于我们

这样排序的原因：

首页与加入路径最影响整体产品表达
分会/成员结构会反向验证数据模型是否正确
活动和文章依赖较成熟的内容模型，可稍后接入

M4：后台能力对齐

推荐先后顺序：

仪表盘
文章管理
活动管理与报名审核
加入申请审核
成员管理
分会与董事会维护
工作人员管理
角色与权限配置
审计日志

说明：

分会与董事会虽然不一定是一级菜单，但在实现顺序上必须跟成员模块同时完成
审计日志应伴随敏感模块一起接入，而不是最后再补

6. 仓库内推荐施工顺序

packages/shared
packages/db
apps/api
apps/admin
apps/site

原因：

共享 DTO 和 schema 决定上下游契约
API 是前后台共同依赖的业务边界
后台先稳定内容录入，前台再对接真实数据

7. 当前最关键的阻塞项

以下事项如果不先定，会导致多处返工：

branches 是否完全取代旧 cities
成员体系与工作人员体系是否完全分离
“成员身份”与“工作人员角色”如何彻底分离
加入申请是否先采用单表审核模型
后台“成员”模块是否承接分会与董事会维护
首页是否采用结构化区块而不是普通文章

当前文档已经默认给出答案，后续实现应按此推进。

8. 可并行推进的工作

在数据模型和 API 契约冻结后，可以并行：

后台信息架构与表单原型
前台页面布局与组件拆分
API 路由与 DTO 落地
图片上传与资源引用流程
测试用例改写与收敛

并行的前提是：

DTO 已稳定
权限码已稳定
路由命名已稳定

9. 每个功能切片的完成定义

每个切片至少要包含：

必要的 schema 调整
API 查询或写接口
后台录入或审核能力
前台展示或提交能力
对应权限校验
最小测试覆盖
文档同步

10. 当前最大的实施风险

继续沿旧 topic/city 路线增加实现，导致主线再次发散
先做页面再补数据模型，导致字段反复返工
前台直接拼装业务逻辑，绕开 API
后台模块名称与实际职责不一致
测试仍覆盖旧原型，而未覆盖新范围

11. 文档收敛后的直接下一步

当前这一步已经进入“从文档冻结走向实现迁移”的阶段。

现在最合适的下一步不是继续扩需求，而是按执行清单开始收敛实现：

以 schema-adjustment-checklist.md 冻结数据库增量改造顺序
以 api-dto-adjustment-checklist.md 冻结共享契约与 API 切换顺序
以 implementation-transition-backlog.md 按 shared -> db -> api -> admin -> site 的顺序实施
新主线跑通后，再安排旧 topic / city 原型退场

只有这样，前后台实现才不会再大范围返工。