mvp-scope.md

TGO Network 当前阶段范围

1. 交付原则

这个项目不应该在两种极端之间摇摆：

• 做一个会被推倒重来的临时 Demo
• 一开始就试图把最终完整产品一次做完

正确方式是：

在最终目标架构上，按阶段交付可上线的产品切片。

这意味着：

• 架构选择现在就按最终形态来
• 功能范围按阶段刻意收敛
• 后续版本是在现有系统上扩展，而不是推翻重做

2. 已稳定的基础决策

下列决策在当前阶段视为稳定：

• 前台使用 Astro
• 后台使用 Vue + Vite
• 后端使用 Hono
• 主数据库使用 PostgreSQL
• 认证方向使用 Better Auth
• 文件二进制使用 S3-compatible object storage
• 前台、后台、API 必须保持拆分
• 业务权限必须留在我们自己的应用层

3. 当前阶段如何理解 MVP

这里的 MVP 不是“功能很少”的意思，而是“最小可上线闭环”：

• 前台能完整讲清楚组织是谁、成员是谁、活动是什么、如何加入
• 后台能完成内容发布、活动运营、申请审核、权限管理
• 数据模型与 API 采用真实生产架构
• 后续扩展手机号登录、更多社区能力时不需要重做底层

MVP 不等于：

• 只做静态页面
• 只有展示没有后台
• 用临时数据结构先糊出来
• 把所有未来功能一次塞进首版

3.1 当前必须明确的人群边界

当前版本至少要区分 3 类人：

• 非成员
  • 可以浏览公开品牌与介绍内容
  • 可以提交加入申请
• 成员
  • 在前台查看成员侧信息
  • 在前台报名参加活动
• 工作人员
  • 登录后台执行运营与审核操作

这里要特别强调：

• “成员”是业务身份
• “工作人员”是后台准入身份
• “角色”是工作人员后台权限包

所以：

• 成员不是后台 role
• 非成员申请人也不是后台 role
• 后台的“角色”菜单只管理工作人员 RBAC 权限

4. 当前版本必须包含的前台范围

4.1 首页

必须能够承载：

• TGO 介绍
• 组织形式
• 覆盖人群
• 精彩活动/精选内容
• 申请加入 CTA

4.2 分会董事会

必须能够展示：

• 各个分会
• 各分会董事会成员
• 成员头像、名字、公司、职称等基本信息

4.3 成员列表与详情

列表至少展示：

• 头像
• 名字
• 公司
• 职称

详情至少展示：

• 头像
• 名字
• 公司
• 职称
• 个人简介
• 加入时间
• 所属分会（如适用）

说明：

• 当前前台中的成员能力应按“成员身份”理解，而不是后台工作人员权限
• 当前阶段成员不做认证，先以公开展示为主

4.4 活动

必须能够支持：

• 后台发布活动
• 按城市或分会筛选活动
• 查看活动详情
• 在活动详情页点击报名

补充约束：

• 活动报名当前采用开放报名
• 当前不要求成员登录
• 是否符合成员活动要求，由工作人员在后台审核确认
• 非成员的核心转化动作仍然是提交加入申请

4.5 文章

必须能够支持：

• 后台发布文章
• 前台展示文章列表
• 查看文章详情

4.6 加入申请

必须同时包含两部分：

• 申请条件与加入方式说明
• 申请表

申请表字段至少包含：

• 姓名
• 电话
• 微信号
• 邮箱
• 个人介绍
• 加入申请信息

4.7 关于我们

必须能够说明：

• 组织的活动形式
• 加入方式
• 组织背景与定位

5. 当前版本必须包含的后台范围

5.1 仪表盘

至少展示：

• 当前文章总数
• 当前活动总数
• 当前申请数量
• 当前系统状态

5.2 文章

必须包含：

• 文章列表
• 新建文章
• 编辑文章
• 发布/归档能力

5.3 活动

必须包含：

• 活动列表
• 新建活动
• 编辑活动
• 活动报名审核

5.4 申请

必须包含：

• 申请列表
• 申请详情
• 审核与备注

5.5 成员

必须包含：

• 成员列表
• 成员信息编辑
• 分会与董事会信息维护能力

说明：分会和董事会信息属于成员域的一部分，可以作为二级页面，不强制要求一级导航独立拆出。

5.6 工作人员

必须包含：

• 工作人员列表
• 增加工作人员
• 编辑工作人员信息
• 编辑工作人员权限或角色绑定

5.7 角色

必须包含：

• 角色列表
• 角色权限配置
• 权限矩阵维护

这里的“角色”只指工作人员后台角色，不指成员身份分类。

5.8 审计日志

必须包含：

• 敏感后台操作记录
• 操作人、目标对象、时间、结果等信息

6. 当前范围内的支撑能力

虽然不一定作为一级菜单出现，但以下能力属于当前范围内必须具备的支撑项：

• Better Auth 驱动的后台登录
• 面向成员侧的会话扩展能力预留
• 工作人员权限校验
• 首页内容配置
• 加入页和关于页的后台内容维护
• 图片上传与对象存储接入
• 审计日志落库
• 基础健康检查、环境校验、CI

7. 当前明确不做的内容

当前阶段不应继续扩张到以下方向：

• topics 专题中心
• cities 独立内容落地页
• 完整的成员个人中心
• 课程体系 / 培训老师 / 企业图谱
• 支付、账单、发票自动化
• 复杂推荐、个性化、社交关系链
• 多级审批工作流引擎

这些内容如果以后需要，应该在当前主线稳定后再扩展。

8. 阶段划分建议

Phase 0：架构与文档

目标：

• 冻结技术栈
• 冻结系统边界
• 冻结当前版本功能范围

Phase 1：运行骨架

目标：

• 三个应用能启动
• 认证、数据库、基础 API 跑通
• 最小测试链路存在

Phase 2：公开站点闭环

目标：

• 上线 7 个前台模块
• 对接真实 API 和真实后台数据
• 完成 SEO 与基础内容呈现

Phase 3：后台运营闭环

目标：

• 上线 8 个后台模块
• 能通过后台驱动前台内容、活动、申请与权限

Phase 4：生产加固

目标：

• 审计、限流、监控、部署、备份恢复完善

Phase 5：增长扩展

候选项：

• 手机号登录
• 更丰富的成员能力
• 活动签到
• 通知系统
• 数据分析看板

9. 当前版本的验收标准

当前阶段可以视为完成的标准是：

• 前台 7 个模块全部具备真实数据驱动能力
• 后台 8 个模块全部具备最小可用能力
• 非成员、成员、工作人员三类人群边界清晰
• 工作人员权限能阻止未授权操作
• 成员侧能力与工作人员后台角色没有混用
• 文章、活动、成员、分会、申请都能通过后台进入前台闭环
• 加入申请和活动报名都能形成可审核数据

10. 当前文档之后的下一步

文档收敛完成后，下一步不是继续加功能，而是做三件事：

1. 冻结数据模型差异
2. 冻结 API 契约与路由
3. 按收敛范围重排现有实现与测试优先级