@@ -1,4 +1,7 @@
# b2f
+> 文档版本:v1.0
+> 最后更新:2026-04-02
+
说明:
@@ -160,3 +163,4 @@
- 确认正式流程只认 launch 返回的 `manifestUrl`
- 预埋“放弃恢复”调用位
- 是否已解决:否
# Backend
这套后端现在已经能支撑一条完整主链:
@@ -42,3 +45,4 @@ go run .\cmd\api
- 局生命周期:`start / finish / detail`
- 局后结果:`/sessions/{id}/result`、`/me/results`
- 开发工作台:`/dev/workbench`
# Backend Docs
这套文档服务两个目的:
@@ -54,3 +57,4 @@
- 应用装配:[app.go](D:/dev/cmr-mini/backend/internal/app/app.go)
- 路由注册:[router.go](D:/dev/cmr-mini/backend/internal/httpapi/router.go)
- migration:[migrations](D:/dev/cmr-mini/backend/migrations)
# Backend TodoList
## 1. 目标
@@ -330,3 +333,4 @@ backend 现在最值得先做的,不是扩接口,而是先确认下面 3 条
当前 backend 最重要的任务不是“再加更多接口”,而是:
> 先把 session 运行态语义、放弃恢复语义和 ongoing session 口径定稳,再继续扩后台配置系统。
# 前后端联调清单
## 1. 目的
@@ -367,3 +370,4 @@ backend 文档里也规划了:
当前最真实的进度判断是:
> backend 业务后端主链已经进入可联调阶段;小程序地图运行内核也已经具备承接能力;下一步最值钱的是补小程序业务 API 层和 launch/finish 两个适配器。
# 开发说明
## 1. 环境变量
@@ -192,3 +195,4 @@ Redis 后面只在需要性能优化、限流或短期票据缓存时再接。
4. 再考虑实时网关票据
不要跳回去把玩法规则塞进 backend。
# API 清单
本文档只记录当前 backend 已实现接口,不写未来规划接口。
@@ -423,3 +426,4 @@
- `release.releaseId`
- `release.manifestUrl`
- `release.configLabel`
# 数据模型
当前 migration 共 5 版。
@@ -169,3 +172,4 @@
- 实时票据 / 网关票据
这些后面要按真正业务需要补 migration,不要先拍脑袋建大而全表。
# 核心流程
## 1. 总流程
@@ -226,3 +229,4 @@ APP 当前主链是手机号验证码:
`app event -> app launch -> app game`
业务接口必须保持统一,终端差异只进入上下文,不进入对象模型分叉。
# 系统架构
@@ -231,3 +234,4 @@
- 网关只认 backend 签发的运行态票据
不要把微信身份或业务 token 直接暴露给实时网关。
# 资源对象与目录方案
本文档用于把“地图复用、KML 复用、内容资源复用、配置发布”统一收成一套后端可执行方案。
@@ -587,3 +590,4 @@ gotomars/event-releases/{eventPublicID}/{releasePublicID}/asset-index.json
只有这样,地图复用、KML 复用、资源包复用、多活动发布才能长期稳定。
并且这套模型必须从一开始就兼顾未来 APP,而不是做成“小程序跑通后再重构”的临时结构。
# 配置管理方案
@@ -410,3 +413,4 @@
> 源配置管理 + 构建产物管理 + release 发布管理 + session 绑定 release
这样以后无论你配置项怎么继续长,主架构都还能撑住。
@@ -1,3 +1,6 @@
结果页会根据客户的要求不停的变换,用什么方案能实现这个需求,其实其他的弹出内容也都存在这个问题,样式,内容都时根据客户需求变化的,怎样一种方案设计比较好呢?
@@ -330,4 +333,4 @@ CTA 就是卡片上引导用户下一步操作的按钮。
再深一点,自定GPS点能不能做成动画的,停止一个动画,跑起来又是一个动画,甚至可以做些额外的动作。
-开个小差,我想临时加个功能,在咱的GPS模拟器加个日志输出功能,把调试期间不方便打在调试面板里的信息输出到模拟器上,你觉得如何?这样更方便后期调试?如果可以先给个方案
+开个小差,我想临时加个功能,在咱的GPS模拟器加个日志输出功能,把调试期间不方便打在调试面板里的信息输出到模拟器上,你觉得如何?这样更方便后期调试?如果可以先给个方案
-# 动画字典 v1
+# 动画字典 v1
@@ -356,3 +359,4 @@
**按动画字典逐项补齐高频体验链。**
-# 动画接入工作流
+# 动画接入工作流
@@ -362,3 +365,4 @@ lite 表现:
已经归档到 [archive/animation](/D:/dev/cmr-mini/doc/archive/animation),当前以本文件为统一入口。
-# 动画体系阶段性小结
+# 动画体系阶段性小结
## 1. 当前定位
@@ -191,3 +194,4 @@
**把现有能力收成动画字典,并优先打磨目标切换与跳点这两条高频体验链。**
-# 动画接入规格模板
+# 动画接入规格模板
## 1. 用途
@@ -162,3 +165,4 @@ lite 表现:透明度降低 50%,时长缩短到 220ms
只有规格明确,程序才能稳定接入。
-# 动画接入评审清单
+# 动画接入评审清单
@@ -161,3 +164,4 @@
先补规格,再接程序。
-# 动效系统设计方案
+# 动效系统设计方案
本文档用于整理当前项目后续的动画 / 动效建设方案,目标不是单纯“让界面更花”,而是把动画正式纳入现有架构,成为:
@@ -449,3 +452,4 @@
**后续动画建设应以“打点成功”和“目标状态”两条高频体验为起点,把动画正式纳入现有架构,而不是继续做零散样式补丁。**
-# 配置驱动应用的后台管理方案建议
+# 配置驱动应用的后台管理方案建议
本文用于整理当前这类“配置驱动型地图游戏应用”的后台管理建议,面向:
@@ -415,3 +418,4 @@ Go 中间层实现“装配成最终 JSON”。
- 可回滚
- 可稳定运行
-# 积分赛配置文档(基础版)
+# 积分赛配置文档(基础版)
本文档用于给服务端和后台配置设计提供一份可直接落地的积分赛基础模板。
目标是先把积分赛入口结构定稳,后续程序功能再逐步细化。
@@ -354,3 +357,4 @@
- 用 `game.scoring / game.punch / game.guidance / game.finish` 承载玩法规则
- 先把静态积分赛入口结构定稳,后续再扩动态积分与更复杂玩法
-# 游戏配置文件设计方案(阶段讨论稿)
+# 游戏配置文件设计方案(阶段讨论稿)
本文档用于整理当前阶段推荐的配置文件设计方案,供后端、客户端和后台管理设计参考。
目标是让配置真正成为游戏的驱动入口,同时兼顾后续多玩法、多资源、多活动复用。
@@ -586,3 +589,4 @@ KML 适合描述:
**KML 描述空间事实,配置描述玩法解释;主配置按 `map / playfield / game / resources / debug` 分层,后续再升级成 manifest 组合。**
-# 顺序赛配置文档(基础版)
+# 顺序赛配置文档(基础版)
本文档用于给服务端和后台配置设计提供一份可直接落地的顺序赛基础模板。
目标是先把入口配置结构定稳,后续程序功能再逐步细化。
@@ -312,3 +315,4 @@
- 用 `game.session / game.punch / game.sequence / game.guidance` 承载玩法规则
- 先把基础入口结构定稳,后续再细化跳点、惩罚、特殊引导等高级规则
-# 默认配置模板文档(当前实现版)
+# 默认配置模板文档(当前实现版)
本文档提供一份 **当前客户端可直接使用的默认配置模板**。
目标是:
@@ -414,3 +417,4 @@
始终保持一致。
-# H5 体验接入方案
+# H5 体验接入方案
本文档用于定义当前项目中 **原生小程序 + H5 定制内容** 的混合接入方案。
@@ -412,3 +415,4 @@ H5 接入时必须注意:
- [platform-capability-notes.md](D:/dev/cmr-mini/doc/debug/平台能力说明.md)
-# Experience Shell 方案
+# Experience Shell 方案
本文档用于定义小程序中 H5 定制内容的承载方式。目标不是把 H5 做成真正的同页弹窗,而是做成:
@@ -231,3 +234,4 @@ H5 可以通过 bridge 发:
**独立页面承载,但由原生壳子把它做成 `sheet / dialog / fullscreen` 三种体验形态。**
-# 游戏中文创体验层方案
+# 游戏中文创体验层方案
@@ -327,3 +330,4 @@ interface ExperienceRuntimeState {
第一阶段先用“控制点完成触发内容卡”跑通最小闭环,后面再逐步扩成完整体验系统。
-# 游戏结算层方案
+# 游戏结算层方案
@@ -292,3 +295,4 @@ interface ResultSceneState {
第一阶段先做基础 summary,后续再逐步接入文创奖励、奖章、排名和过场动画。
-# CMR-Mini 项目深度分析报告 (GeminiAnalysis.md)
+# CMR-Mini 项目深度分析报告 (GeminiAnalysis.md)
## 1. 项目定位与核心愿景
**CMR-Mini** 是一个运行在微信小程序环境中的高性能**定向越野 (Orienteering)** 实时竞赛/练习引擎。其核心竞争力在于通过自研的 **WebGL 地图渲染管线** 提供流畅的地图交互,并结合高精度多传感器融合技术(GPS、罗盘、心率、加速度计等)实现精准的运动反馈。
@@ -49,3 +52,4 @@ CMR-Mini 已经建立了一个非常坚实的专业定向越野引擎基础。
---
*Generated by Gemini CLI Analysis Tool*
-# 临时玩法讨论记录
+# 临时玩法讨论记录
本文档用于临时记录以下讨论内容:
@@ -208,3 +211,4 @@
当前这套架构不仅适合传统定向和积分赛,也适合继续承载更游戏化的运动玩法。
像贪吃蛇式玩法和区域拾金币玩法,都更像是“新增玩法插件”,而不是“推翻现有底座”。
-# 传感器接入待开发方案
+# 传感器接入待开发方案
本文档用于整理当前项目后续可利用的传感器能力,分为:
@@ -569,3 +572,4 @@
**原始传感器进 `engine/sensor`,高级状态进 `telemetry`,上层只消费统一状态。**
-# 多人模拟器改造待开发文档
+# 多人模拟器改造待开发文档
本文档用于记录“公网模拟器支持多人开发/多人联调”的待开发方案。
当前仅作为设计与排期参考,不代表已经进入实现阶段。
@@ -329,3 +332,4 @@ type ClientSession = {
这项改造建议先保留为待开发事项。
当前阶段不急着实现,但应作为后续多人开发与多人玩法联调的重要底座能力。
@@ -1,5 +1,9 @@
-
-# 文档归档索引
+# 文档归档索引
这里存放的是已经完成历史使命的阶段性方案稿、重复模板和临时记录。
@@ -24,3 +27,4 @@
- 动画工作流:[animation-integration-workflow.md](/D:/dev/cmr-mini/doc/animation/动画接入工作流.md)
- 混合体验架构:[hybrid-experience-architecture.md](/D:/dev/cmr-mini/doc/experience/混合体验架构方案.md)
# 业务后端数据库初版方案
@@ -694,3 +697,4 @@ H5 / 白标页面配置。
正确方向是:
> PostgreSQL 存业务状态 + 版本化配置对象,Go API 负责查询与发布编排,客户端继续消费发布后的运行态配置。
# 全局规则与配置维度清单
本文档用于定义当前系统中**跨玩法共用**的全局规则块和配置维度,作为后续所有玩法设计文档、配置文件设计、后台录入和联调的统一骨架。
@@ -404,3 +407,4 @@
- 后台配置管理有明确输入目标
- 后续扩展不会只长代码、不长文档
-# 配置频繁变更场景下的后台管理方案
+# 配置频繁变更场景下的后台管理方案
本文用于整理一套更适合“配置项变化很频繁”的后台方案。
@@ -405,3 +408,4 @@ Go 中间层先做最小装配功能。
**PostgreSQL 存“版本化对象 + jsonb 内容”,Go 中间层做“装配 + 校验 + 发布”,客户端只读静态发布结果。**
-# 游戏配置全量模板(当前开发实现版)
+# 游戏配置全量模板(当前开发实现版)
本文档提供一份 **截至当前开发状态,客户端已实现或已正式消费的较完整配置模板**。
@@ -759,3 +762,4 @@
- [D:\dev\cmr-mini\doc\config-template-minimal-game.md](D:/dev/cmr-mini/doc/config/最小游戏配置模板.md)
- [D:\dev\cmr-mini\doc\config-option-dictionary.md](D:/dev/cmr-mini/doc/config/配置选项字典.md)
- [D:\dev\cmr-mini\doc\config-docs-index.md](D:/dev/cmr-mini/doc/config/配置文档索引.md)
-# 游戏最小可跑配置模板
+# 游戏最小可跑配置模板
本文档提供一份 **去掉大部分选配项之后,当前客户端可以直接跑起来的最小配置模板**。
@@ -200,3 +203,4 @@
- [D:\dev\cmr-mini\doc\config-template-full-current.md](D:/dev/cmr-mini/doc/config/当前最全配置模板.md)
# 线上业务接入边界方案
@@ -336,3 +339,4 @@ miniprogram/
## 12. 一句话总结
线上系统负责“把用户送进正确的一局游戏”,配置系统负责“定义这局游戏是什么”。
# 配置分级总表
本文档用于把当前配置体系按“核心必需项 / 常用活动项 / 高级实验项”三层整理,作为后续后台配置设计、活动装配和字段治理的统一依据。
@@ -224,3 +227,4 @@
- 第 3 类:高级实验项
如果无法明确归类,默认先归入高级实验项,不急着开放到后台常规表单。
# 配置发布说明
本文档说明当前项目如何把 `event/*.json` 样例配置同步到服务器。
@@ -113,3 +116,4 @@ npm run publish:config:dry-run
2. 后台生成发布版本
3. 后台上传 OSS/CDN
4. 客户端仍只读取静态 JSON
# 配置文档索引
本文档用于汇总当前项目所有与配置设计、配置样例、配置管理相关的文档,并按“公共配置”和“按游戏分类”两层组织。
@@ -67,3 +70,4 @@
6. 对应玩法目录下的全局配置项
7. 对应玩法目录下的游戏配置项
8. 对应玩法的 `event/*.json` 样例
-# 配置选项字典(当前实现版)
+# 配置选项字典(当前实现版)
本文档用于整理 **当前客户端已经消费或已经预留承载的配置项**,作为事件配置、后台配置和联调时的统一参考。
@@ -1291,3 +1294,4 @@
- 服务端可对照
- 后台可录入
- 客户端联调时有统一参考
-# 传感器现状总结
+# 传感器现状总结
本文档用于说明当前小程序版本已经接入并实际使用的传感器/输入源、它们在系统中的作用,以及当前阶段的稳定边界。
@@ -233,3 +236,4 @@
-# 平台能力与主体限制说明
+# 平台能力与主体限制说明
本文档用于记录当前项目在 **微信小程序平台能力** 上已经确认的边界,避免后续把环境或主体限制误判成代码问题。
@@ -143,3 +146,4 @@
- H5 和高级传感器按“预留 + 待验证”处理
- 待企业主体生效后,再统一回归验证
# 模拟器多通道联调最小方案
## 目标
@@ -141,3 +144,4 @@
- 多控制台协作
如果后面真的需要这些,再升级到房间模型。
# 模拟器控制面板重构方案
@@ -94,3 +97,4 @@
- 新版页面可完整使用现有 GPS、心率、日志、路径、网关能力
- 模拟器只保留一个工作台入口
- websocket 协议和调试逻辑继续复用
-# 模拟器调试日志方案
+# 模拟器调试日志方案
@@ -128,3 +131,4 @@
## 当前结论
先把 `gps-logo` 调试链打通,再回头用模拟器日志查 logo 为什么不显示,比继续把临时字段堆在调试面板里更稳。
-# 罗盘问题排查记录
+# 罗盘问题排查记录
## 背景
@@ -211,3 +214,4 @@
**在微信小程序里,Android 罗盘监听的稳定性比 iOS 更脆;某些看似冗余的 `start()` 调用,实际是平台兼容补丁,不应该在没有真机回归的情况下清理。**
-# 调试文档索引
+# 调试文档索引
这一组文档用于记录:
@@ -38,3 +41,4 @@
- 看“以后日志怎么打”,优先看模拟器日志方案。
- 看“多人联调怎么隔离”,优先看模拟器多通道联调最小方案。
- 看“为什么罗盘以前坏过”,再去看罗盘问题记录。
-# 原生与 H5 Bridge 协议草案
+# 原生与 H5 Bridge 协议草案
本文档定义当前项目中 **原生小程序** 与 **H5 定制内容页** 之间的基础通信协议。
@@ -380,3 +383,4 @@ Bridge 的第一阶段目标,不是做成万能总线,而是:
这 5 条做稳,就足够支撑第一波客户定制需求。
-# 混合体验架构方案
+# 混合体验架构方案
本文档用于说明当前项目在 **结果页、文创内容页、客户定制体验页** 上的长期承载方案。
@@ -510,3 +513,4 @@ H5 详情页或任务页
- [experience-shell-proposal.md](/D:/dev/cmr-mini/doc/archive/experience/体验壳子方案.md)
- [h5-experience-integration-proposal.md](/D:/dev/cmr-mini/doc/archive/experience/H5体验接入方案.md)
# 多线程联调协作方式
@@ -316,3 +319,4 @@
- 再决定是否引入更重的流程工具
而不是先把协作体系做复杂。
# 故障恢复机制
本文档用于说明当前客户端在“游戏进行中非正常退出”场景下的恢复机制。
@@ -237,3 +240,4 @@
当前故障恢复机制的定位是:
**保证玩家在异常退出后可以继续当前对局,但不承担恢复所有临时界面状态。**
# 游戏规则架构
本文档用于说明当前项目中“游戏规则”在文档、配置文件、样例 JSON、解析代码和运行时规则引擎之间的实际组织方式。
@@ -378,3 +381,4 @@
当前这套实际架构可以概括为:
**`doc/config` 管公共规则全集,`doc/games/<游戏名称>` 管玩法规则与配置子集,`event/*.json` 管可运行样例,客户端解析配置后交给规则引擎执行,并由轻量恢复层处理异常退出后的续局。**
-# 新玩法建议方案
+# 新玩法建议方案
本文档用于整理当前阶段值得考虑的新游戏玩法方向,重点回答以下问题:
@@ -440,3 +443,4 @@
当前这套架构已经不只是适合传统顺序赛和积分赛,也适合继续承载更游戏化、更有传播性的运动玩法。
如果只优先选一个最值得推进的新玩法,建议先做:`幽灵追逐赛`。
# 玩法设计文档模板
本文档用于定义后续所有玩法设计文档的**统一写法**,保证玩法规则、全局规则块、配置落点和最小样例能够一起沉淀,为后续 JSON 配置管理和后台装配提供稳定输入。
@@ -409,3 +412,4 @@
不要让后台方案反过来决定玩法规则结构。
# 程序默认规则基线
本文档用于定义当前客户端在**不依赖活动配置细项**时,程序层应该内建的默认规则。
@@ -437,3 +440,4 @@ HUD 属于公共程序能力,不属于某个玩法专属实现。
## 12. 一句话结论
当前阶段应以这份文档作为**程序默认能力基线**:先把最小流程、弹层职责、HUD 结构和距离反馈定死,再决定哪些内容值得进入配置层。
# 运行时编译层总表
本文档用于定义当前项目推荐的“运行时编译层”结构,也就是把系统默认值、玩法默认值、活动配置、玩家设置编译成统一运行时 profile 的中间层。
@@ -243,3 +246,4 @@
`系统默认值 -> 玩法默认值 -> 活动配置 -> 玩家设置 -> 运行时编译层 -> 引擎 / 页面 / 规则`
这样配置越多,系统越不容易乱;后续后台做复杂了,也还是有一层中间结构兜住。
# 积分赛全局配置项
本文档只列积分赛对公共配置块的默认落点。完整字段定义仍以 [全局规则与配置维度清单](D:/dev/cmr-mini/doc/config/全局规则与配置维度清单.md) 和 [配置选项字典](D:/dev/cmr-mini/doc/config/配置选项字典.md) 为准。
@@ -19,3 +22,4 @@
- 普通点默认自动进入 10 秒题卡
- 答题时比赛继续计时
- 未选择目标点时,HUD 只提示“请选择目标点”
# 积分赛最大配置模板
本文档作为积分赛的完整模板入口。当前项目仍维护一份共享全量模板:
@@ -51,3 +54,4 @@
- [规则说明文档](D:/dev/cmr-mini/doc/games/积分赛/规则说明文档.md)
- [游戏配置项](D:/dev/cmr-mini/doc/games/积分赛/游戏配置项.md)
- [score-o.json](D:/dev/cmr-mini/event/score-o.json)
# 积分赛最小配置模板
本文档提供一份 **积分赛(`score-o`)最小可跑配置模板**。
@@ -244,3 +247,4 @@
如果要查看公共完整字段,请继续参考:
- [当前最全配置模板](D:/dev/cmr-mini/doc/config/当前最全配置模板.md)
# 积分赛游戏说明文档
本文档作为 `score-o` 的目录入口,用来统一说明本玩法文档放在哪里、分别看什么。
@@ -31,3 +34,4 @@
- [配置选项字典](D:/dev/cmr-mini/doc/config/配置选项字典.md)
- [全局规则与配置维度清单](D:/dev/cmr-mini/doc/config/全局规则与配置维度清单.md)
# 积分赛游戏配置项
本文档用于汇总当前系统对 `score-o` 的已支持可配置项,重点只看和积分赛玩法直接相关的字段。
@@ -52,3 +55,4 @@
详细规则请看:
# 积分赛规则说明文档
本文档用于定义 `score-o` 在**最小模板**下的系统默认规则,作为后续实现、联调和配置扩展的共同基线。
- 后续配置化扩展前的默认产品行为
- 积分赛样例配置和实现验收时的基准口径
# 顺序打点全局配置项
本文档只列顺序打点对公共配置块的默认落点。完整字段定义仍以 [全局规则与配置维度清单](D:/dev/cmr-mini/doc/config/全局规则与配置维度清单.md) 和 [配置选项字典](D:/dev/cmr-mini/doc/config/配置选项字典.md) 为准。
@@ -18,3 +21,4 @@
- 开始点和结束点不弹题
# 顺序打点最大配置模板
本文档作为顺序打点的完整模板入口。当前项目仍维护一份共享全量模板:
@@ -55,3 +58,4 @@
- [规则说明文档](D:/dev/cmr-mini/doc/games/顺序打点/规则说明文档.md)
- [游戏配置项](D:/dev/cmr-mini/doc/games/顺序打点/游戏配置项.md)
- [classic-sequential.json](D:/dev/cmr-mini/event/classic-sequential.json)
# 顺序打点最小配置模板
本文档提供一份 **顺序赛(`classic-sequential`)最小可跑配置模板**。
@@ -230,3 +233,4 @@
# 顺序打点游戏说明文档
本文档作为 `classic-sequential` 的目录入口,用来统一说明本玩法文档放在哪里、分别看什么。
# 顺序打点游戏配置项
本文档用于汇总当前系统对 `classic-sequential` 的**已支持可配置项**,便于产品、客户端、服务端、后台录入和联调统一对照。
4. [当前最全配置模板](D:/dev/cmr-mini/doc/config/当前最全配置模板.md)
5. [顺序赛样例配置](D:/dev/cmr-mini/event/classic-sequential.json)
# 顺序打点规则说明文档
本文档用于定义 `classic-sequential` 在**最小模板**下的系统默认规则,作为后续实现、联调和配置扩展的共同基线。
@@ -300,3 +303,4 @@
- 顺序赛样例配置和实现验收时的基准口径
-# Realtime Gateway + Cloudflare Tunnel 本机联调说明
+# Realtime Gateway + Cloudflare Tunnel 本机联调说明
本文档说明如何在**不正式部署到线上服务器**的前提下,把本机的 `realtime-gateway` 暴露给外部设备或远程联调方。
@@ -286,3 +289,4 @@ npm run mock-gps-sim
这条路径最轻、最稳,也最符合你现在“先不正式上线”的目标。
-# Realtime Gateway 运行手册
+# Realtime Gateway 运行手册
本文档用于整理当前 `realtime-gateway` 的构建、运行、联调和排障方式,覆盖今天已经落地的能力。
@@ -442,3 +445,4 @@ go run .\cmd\mock-consumer -channel-id ch-xxxx -token <consumer-token> -topics t
这也是当前最省风险的组合。
-# 实时设备数据网关最终方案
+# 实时设备数据网关最终方案
本文档用于收敛当前关于 GPS 模拟、中转、监控、规则判定、回放、通知分发等讨论,给出一版可直接进入实现设计的最终方案。
@@ -876,3 +879,4 @@ Business Server
同时又能把实时性能放在系统设计的首位。
-# 实时网关 MVP 拆分
+# 实时网关 MVP 拆分
本文档用于把 `realtime-gateway` 第一阶段工作拆成可执行任务。
@@ -122,3 +125,4 @@ MVP 跑通后优先做:
4. 简单规则插件
5. Dispatcher 插件
-# 实时网关协议草案
+# 实时网关协议草案
本文档描述 `realtime-gateway` 第一版协议草案,范围只覆盖 MVP。
@@ -343,3 +346,4 @@
- `replay_control`
- `auth_refresh`
-# 网关文档索引
+# 网关文档索引
这一组文档用于承接:
@@ -29,3 +32,4 @@
3. [realtime-gateway-runbook.md](/D:/dev/cmr-mini/doc/gateway/实时网关运行手册.md)
4. [gateway-mvp-task-breakdown.md](/D:/dev/cmr-mini/doc/gateway/网关MVP任务拆分.md)
-# 沟通协作建议
+# 沟通协作建议
这份文档用于约定后续在 UI 微调、交互细改、规则补充时,怎样沟通最有效,减少来回修改。
@@ -95,3 +98,4 @@
**需求把边界说死,修改一次只动一层。**
-# GPS 点动画系统方案
+# GPS 点动画系统方案
@@ -209,3 +212,4 @@ GPS 点动画不应该做成单一固定动画,而应该做成:
这 4 种状态的程序化动画跑通,再决定后续是否继续开放更细粒度配置。
-# GPS 点样式系统方案
+# GPS 点样式系统方案
@@ -112,3 +115,4 @@ GPS 点应被视为独立样式系统,而不是固定蓝点。
做稳定,再逐步承接商业品牌化定制。
-# 轨迹可视化方案
+# 轨迹可视化方案
本文档定义用户轨迹的显示模式、默认策略与配置结构。
@@ -84,3 +87,4 @@
- 轨迹颜色按速度变化
- `standard / lite` 下自动降级 glow
@@ -1,4 +1,11 @@
# 文档索引
+维护约定:
+- 所有 Markdown 文档统一在标题下方标注 `文档版本` 和 `最后更新`。
+- 后续新建或更新文档时,必须同步维护这两项元信息。
## 按游戏分类
@@ -68,3 +75,4 @@
- 长期保留的少量工作便签见 [notes](/D:/dev/cmr-mini/doc/notes)。
- 历史方案稿和阶段性讨论稿已移到 [archive](/D:/dev/cmr-mini/doc/archive/归档索引.md)。
# F2B 协作清单
@@ -193,3 +196,4 @@
- 需要对方确认什么:
- 后续是否提供用户身体数据接口
- 状态:后续事项
# CMR Mini 开发架构阶段总结
+文档维护约定:
+- 仓库内 Markdown 文档统一在标题下方标注 `文档版本` 和 `最后更新`。
+- 后续新建文档或更新文档内容时,必须同步更新这两项元信息。
本文档用于记录当前阶段小程序的整体架构、分层原则、事件驱动链路、模拟器体系,以及后续继续扩展时应遵守的边界。
@@ -1563,3 +1570,4 @@ GPS:
- 定制结果页
都会沿这条边界继续推进,而不是重新混在一个弹层里。
# CMR Mini Program(彩图奔跑小程序)
## 📌 项目简介
@@ -204,4 +207,4 @@ NPC / 问答扩展
🧠 一句话总结
-这是一个“自研地图引擎 + 定向运动系统”的小程序项目,而不是普通地图应用。
+这是一个“自研地图引擎 + 定向运动系统”的小程序项目,而不是普通地图应用。
# Realtime Gateway
`realtime-gateway` 是一个独立于现有模拟器的 Go 实时设备数据网关工程。
@@ -147,3 +150,4 @@ go run .\cmd\mock-consumer -channel-id ch-xxxx -token <consumer-token> -topics t
更多运行和排障细节,直接看:
- [实时网关运行手册.md](D:/dev/cmr-mini/doc/gateway/实时网关运行手册.md)
# Client API 前端联调文档
文档版本:v1.0.0
最后更新:2026-03-31
@@ -692,3 +695,4 @@ Path 参数:
- 已存在测试赛事卡片、地图、Event、manifest 绑定关系
- 已存在一个已批准报名的测试用户,可直接验证赛事入口 `launch`
# CMR 联调协作清单
本文档用于后端、前端和你之间的联调协作。
@@ -290,3 +293,4 @@
- 已支持 quick flows
- 已支持场景保存
- 已支持配置发布链调试
# Mock GPS Simulator
## 启动
@@ -277,3 +280,4 @@ http://192.168.1.23:17865/
```text
ws://192.168.1.23:17865/debug-log
```