# 空应用脚手架策略说明

## 背景

截至 `M1` 结束，仓库已经完成：

- `pnpm workspace + turbo` 根骨架
- `apps/*` 与 `packages/*` 的目标目录占位
- `packages/config` 的共享配置占位

但我们仍然**没有**创建真实的 `Next.js` 或 `NestJS` 应用。

这不是遗漏，而是刻意的教程设计。

## 为什么 M1 不直接创建真实应用

### 1. 先固定结构，再引入工具链

如果一开始就运行 `create-next-app`、`nest new`，读者会直接看到大量脚手架文件，很难分清：

- 哪些是框架默认生成
- 哪些是我们项目真正需要的约束
- 为什么目录要这样拆

先做骨架和占位，可以先把“结构意图”讲清楚。

### 2. 避免一次性引入过多噪音

真实脚手架会立刻带来：

- 框架默认配置
- 测试工具差异
- lint / format 规则差异
- 包管理与构建细节

这些内容本身并不属于 M1 的核心目标，会冲淡“为什么先做 monorepo 骨架”的主线。

### 3. 给后续里程碑保留自然展开空间

教程型项目需要“问题出现 → 再引入工具”的节奏。

例如：

- 需要鉴权与 API 时，再正式创建 `apps/server`
- 需要后台登录与表单时，再正式创建 `apps/admin`
- 需要公开 SSR 展示时，再正式创建 `apps/web`

这样每一步都更容易解释“为什么现在创建，而不是之前就创建”。

## 什么时候开始创建真实应用

推荐不要在 `M1` 创建真实应用，而是在进入后续能力时再逐步生成。

### 推荐顺序

1. `apps/server`
2. `apps/admin`
3. `apps/web`

### 为什么先 `server`

`M2` 的主题是鉴权与角色。

这一步最先需要的是：

- 用户身份定义
- 登录接口
- `admin / viewer` 权限模型
- 后续可复用的业务后端入口

所以最合理的第一个真实应用应是 `apps/server`。

### 为什么 `admin` 早于 `web`

`admin` 会最先承接：

- 登录
- 后台编辑
- 发布动作
- AI 触发入口

而 `web` 的公开展示更偏向 `M3` 的内容发布闭环，因此可以晚于 `admin` 创建。

## 进入脚手架阶段前的检查清单

在真正生成 `Next.js` / `NestJS` 空应用之前，建议先确认：

- `development` 分支已稳定
- 当前里程碑的骨架说明文档已齐全
- 目录职责已经通过 README 讲清楚
- 共享配置占位已经存在
- 当前旧 Vue 项目仍可作为可运行基线
- 已明确“本次只生成空应用，不接入业务”

只有这些前提明确，脚手架生成才不会变成一次性失控扩张。

## 后续落地建议

### 第一步：生成 `apps/server`

- 只创建最小 `NestJS` 应用
- 不接数据库
- 不接 Redis
- 先为 M2 鉴权做准备

### 第二步：生成 `apps/admin`

- 只创建最小 `Next.js` 应用
- 不急着接完整 UI 系统
- 先承接登录壳与后台页骨架

### 第三步：生成 `apps/web`

- 在需要公开展示与 SSR 时再创建
- 避免 `web` 过早出现而缺少真实内容来源

## 本文结论

`M1` 的目标不是“把所有应用生成出来”，而是：

- 先建立清晰的 monorepo 结构
- 先固定目录职责与边界
- 先让仓库进入可渐进演化的状态

真实应用脚手架应作为后续里程碑的起点，而不是 M1 的终点。
