推进活动系统最小成品闭环与游客体验

backend/docs/后台管理最小方案.md

@@ -1,6 +1,6 @@
 # 后台管理最小方案
-> 文档版本：v1.1
-> 最后更新：2026-04-03 11:02:42
+> 文档版本：v1.8
+> 最后更新：2026-04-07 17:23:15
 
 ## 1. 目标
 
@@ -176,16 +176,16 @@
 
 ## 4. 后台第一版页面建议
 
-按最小闭环，建议先做 6 个页面：
+按当前运维工作流，建议先按“地图主流程”组织，而不是把底层对象散着摆：
 
 1. 地图列表页
-2. 赛场 / KML 列表页
-3. 资源包列表页
-4. Event 列表与编辑页
-5. Build / Release 列表页
-6. 发布详情页
+2. 地图详情页
+3. KML / 赛道管理页
+4. 活动管理页
+5. 发布中心
+6. 资源总览页
 
-这 6 页够把“资源录入 -> Event 组装 -> 发布 -> launch”跑通。
+这 6 页的目标是把“资源录入 -> 地图管理 -> 赛道管理 -> 活动绑定 -> 发布”跑通。
 
 补充：
 
@@ -216,8 +216,112 @@
 - `event` 只做引用和少量覆盖
 - `release` 固化具体版本引用
 
+### 5.1 当前活动模型收口原则
+
+为了让前台卡片、详情页、发布语义和运维操作都保持简单，当前活动模型先明确收成最小可玩单元：
+
+- `单地图`
+- `单路线组`
+- `单玩法`
+
+也就是第一阶段一个活动只表达一件事：
+
+> 在这张地图上，使用这组路线，按这一个玩法运行。
+
+当前不建议第一阶段直接支持：
+
+- 一个活动绑定多张地图
+- 一个活动绑定多组路线
+- 一个活动同时支持多玩法
+
+复杂需求先通过“活动实例化”解决，而不是在一个活动里做多对多编排。例如：
+
+- 地图 A + 路线组 1 + 顺序赛 = 活动 A1
+- 地图 A + 路线组 2 + 顺序赛 = 活动 A2
+- 地图 A + 路线组 2 + 积分赛 = 活动 A3
+
+这样做的目的：
+
+- 前台卡片逻辑简单
+- 发布语义明确
+- 结果追溯简单
+- 运维后台第一期不需要一开始就做复杂配置器
+
+后续如果确实需要复杂组合，优先考虑：
+
+- 基于模板批量实例化多个活动
+
+而不是直接把单个活动扩成多地图、多路线组、多玩法容器。
+
+### 5.2 组合入口层原则
+
+多地图、多路线组、多玩法这类需求后面仍然会存在，但当前建议放在“组合入口层”解决，不直接进入单个活动的运行模型。
+
+也就是分成两层：
+
+1. 运行实例层
+- 一个活动实例始终保持：
+  - `单地图`
+  - `单路线组`
+  - `单玩法`
+
+2. 组合入口层
+- 通过组合卡片或组合入口，把多个活动实例编排成一个前台入口
+- 例如：
+  - 多地图合集
+  - 多玩法合集
+  - 不同难度合集
+  - 同主题活动合集
+
+这样做的目的：
+
+- 前台入口可以灵活组合
+- backend 的发布、回溯、结果沉淀仍然保持简单
+- 运维后台第一期不需要一开始就做复杂多对多编排器
+- 后面若要扩能力，也是在“组合层”扩，而不是把底层活动模型搞乱
+
 ## 6. 一条完整后台工作流
 
+## 7. 运维入口第一期
+
+当前已经开始落地一条“先运维录入、再活动绑定发布”的最小入口，不再只靠手工脚本或改代码上传资源。
+
+第一期先开放两条：
+
+1. `POST /admin/ops/tile-releases/import`
+   - 作用：一次录入 `place + map asset + tile release`
+   - 适合把地图瓦片版本登记进 backend
+
+2. `POST /admin/ops/course-sets/import-kml-batch`
+   - 作用：一次录入一组 KML，生成 `course set + variants`
+   - 适合多赛道活动的批量路线导入
+
+第一期边界：
+
+- 只做录入
+- 只做对象登记和最小 current 绑定
+- 已开始落地独立运维后台 `/admin/ops-workbench`
+- 不替代后续完整运维后台
+
+当前第一版页面结构已经按主流程拆成：
+
+1. `资源总览`
+2. `地图管理`
+3. `资源录入`
+4. `KML / 赛道管理`
+5. `活动管理`
+6. `发布中心`
+
+当前设计原则：
+
+- 运维首先看到“地图列表”
+- KML / 赛道围绕地图管理，不作为孤立对象平铺
+- 活动管理围绕地图关联活动、默认体验活动和发布状态展开
+- 活动编排当前先按“单地图 + 单路线组 + 单玩法”收口
+- 多地图 / 多玩法需求当前先通过“组合卡片 / 组合入口”承接
+- 地图、KML、活动尽量统一成“列表 / 新增 / 修改 / 详情 / 预览 / 发布关联”的相似使用习惯
+- 底层对象如 `Place / MapAsset / TileRelease / CourseSource / CourseSet` 继续保留，但收进主流程内部，不作为首页认知入口
+
 ```mermaid
 flowchart LR
   A["录入地图版本"] --> D["Event 选择地图版本"]
@@ -327,7 +431,21 @@ flowchart LR
 2. `Event` 组装接口 `/admin/events`、`/admin/events/{id}/source` 已完成
 3. `pipeline/build/publish` 后台聚合接口已完成
 4. `rollback` 已完成
-5. 下一步是把这批接口接进 workbench 或正式后台页面
+5. 运维入口第一期已完成：
+   - `POST /admin/ops/tile-releases/import`
+   - `POST /admin/ops/course-sets/import-kml-batch`
+6. 运维入口第二期已开始：
+   - `POST /admin/assets/upload`
+   - `POST /admin/assets/register-link`
+   - `GET /admin/assets`
+   - `GET /admin/assets/{assetPublicID}`
+7. 运维后台第一版结构已开始落地到 `/admin/ops-workbench`：
+   - `资源总览`
+   - `资源录入`
+   - `赛道集管理`
+   - `活动绑定`
+   - `发布中心`
+8. 下一步是继续把更多资源对象与发布细节收进这套运维台，而不是再塞回调试工作台
 
 ## 10. 一句话结论