package handlers import "net/http" type OpsWorkbenchHandler struct{} func NewOpsWorkbenchHandler() *OpsWorkbenchHandler { return &OpsWorkbenchHandler{} } func (h *OpsWorkbenchHandler) Get(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Type", "text/html; charset=utf-8") _, _ = w.Write([]byte(opsWorkbenchHTML)) } const opsWorkbenchHTML = ` CMR 运维后台

先录资源，再绑活动，最后发布

运维平台第一版的目标很单一：把正式资源稳定录入系统，沉淀成资源对象，再通过统一发布链形成可追溯的 release。这里不混调试按钮，也不直接暴露玩家链路。

资源录入文件上传和外链登记统一收口，不再依赖手工改代码或散脚本。
活动绑定活动侧只绑定默认 runtime、presentation、content bundle 三元组。
发布中心继续走统一 build / publish / rollback，不开第二套发布逻辑。
资源总览

先看关键统计，再看当前运行时信息

资源总览先回答两个问题：系统里现在有多少正式对象；你当前选中的活动此刻绑定了哪套 release / runtime / 展示定义 / 内容包。

资源与路线统计
0地点
0地图
0瓦片版本
0受管资源
0路线组
0路线变体
0运行绑定
0配置源
活动与发布统计
0活动数
0默认体验活动
0已发布活动
0发布版本
0展示定义
0内容包
0运维账号
当前运行时信息
-
-
-
-
-
操作提示
1. 先看资源总览
确认地点、地图、路线组、活动、已发布数量是否符合预期。
2. 再选主流程
地图 / 地点管理 -> 路线资源管理 -> 活动管理 / 活动编排 -> 发布中心。
3. 关联活动只看摘要
地图页只看数量和跳转，活动详情统一放到“活动管理”。
开发环境默认免登录放行，生产环境请使用手机号验证码注册/登录的独立运维账号。运维账号和前端玩家账号完全分离。
地图 / 地点管理

先进入地图列表，再做新增、编辑和预览

地点是地图的归属容器，不是主入口。一个地点可挂多张地图，一张地图只属于一个地点。关联活动在这里先只看数量和摘要，详情统一去“活动管理”。

地图列表
默认只看地图列表。点一张地图，再进入地图详情；新增地图和新增地点都走独立弹出层。
暂无地图
打开页面后会自动拉取地图列表，也可以手动点“刷新地图区”。
资源录入

统一纳管资源

运维只需要关心“录一个资源”，不需要关心它最终是 OSS 上传还是已有外链。录完之后都落成统一资源对象。

上传文件

适合 KML、schema、manifest、本地静态包。backend 负责上传 OSS 并纳管。

登记外链

适合正式 OSS / CDN 上已经存在的资源。登记后，活动侧和发布链统一只认受管资源对象。

建议优先纳管：地图瓦片目录、KML、presentation schema、content bundle manifest。
KML / 赛道管理

围绕当前地图管理 KML、赛道集和默认路线

KML 不是独立漂在外面的资源。运维上应该先选地图，再导入一批 KML，形成赛道集，然后查看默认路线和预览数据。

导入瓦片版本
批量导入 KML
当前地图下赛道集
暂无赛道集
读取地图详情或完成一轮 KML 导入后，这里会显示当前地图的赛道集。
KML / 变体预览
-
-
0
-
活动管理

先看活动列表和基础信息

活动管理先处理业务壳：名称、状态、是否默认体验、是否出现在活动列表，以及当前发布概况。资源绑定与发布准备统一去“活动编排”。

活动列表
暂无活动
先点“读取活动列表”。
当前活动概况
-
-
-
-
活动编排

绑定运行对象、展示定义和内容包

这里才进入发布前准备：给当前活动绑定 runtime、presentation、content bundle，确认默认 active 三元组，然后交给发布中心 build / publish。

发布中心

统一 build / publish / rollback

运维后台不造第二条发布链，仍然复用现在这套 source、build、release 流程。

`