统一后端与提交游戏（讨论稿）
讨论稿，2026-10-27。起因是 Dronnax 在群里提的几件事：接口规格放公网加 Swagger UI、规范进 GitHub 仓库改动走 PR、所有游戏统一到一个后端、用飞书审批提交游戏。前两件已经做了（就是这个仓库和文档站），这里讨论后两件。
一、现在是什么样
| 部分 | 在哪 | 做什么 |
|---|---|---|
| 荷官（游戏厅） | 主人的 NAS，单独的容器 | 报名、发牌、判定、积分、在群里播报；按游戏厅协议调用群友的机器人 |
| 膛币柜台 | 腾讯云，只在内网 | 唯一的一本账：签到、牌局、生日发币，点酒、打赏花币 |
| 规范 | 这个仓库 | 游戏厅协议、各游戏规格、开店接口草案 |
游戏厅本来就是多游戏的：每个游戏是荷官里的一个模块，报名、积分、钱包、机器人协议都共用，加游戏不加接口路径（协议第九节）。
二、“统一后端”指什么
建议理解成两句话：
- 账只有一本：所有游戏、所有店都记在膛币柜台，谁也不另起一套币。
- 游戏都进同一个游戏厅：新游戏作为游戏厅里的一个模块上线，共用报名、积分榜、钱包和机器人协议，而不是每个游戏单独起一个服务、单独一套机器人接口。
对群友只开两个口：机器人协议（荷官调你的机器人）和开店接口（你的店调柜台）。其余都是内部实现，可以随时换，不影响大家。
性能不用担心：现在是一个群、同时几桌，一个进程绰绰有余；真到瓶颈时再按游戏拆进程，对外接口不变。
三、群友写的游戏怎么上
| 方案 | 群友交什么 | 谁实现 | 优点 | 缺点 |
|---|---|---|---|---|
| A. 交规格 | 规则 + 规格文档 + OpenAPI 里的 schema | 维护者实现进游戏厅 | 最快、最安全，现在就能做 | 上线快慢看维护者 |
| B. 交代码 | A 的全部 + 按游戏厅接口写好的游戏模块和测试 | 群友写，维护者审核后合并 | 群友能自己掌握玩法细节 | 要先把游戏模块接口整理成文档，还要做代码审核（代码跑在主人机器上） |
| C. 外部游戏 | 自己跑游戏服务器 | 群友 | 完全自主 | 要另定一套“游戏服务器 ↔ 游戏厅”的协议（报名、积分、钱包），工作量最大，账也更难管 |
建议：先用 A；等第一个群友真想自己写代码时，再把游戏模块接口整理出来做 B。C 暂时不做。
四、提交游戏走什么流程
飞书审批不太合适：审批是企业内部的功能，群里大家都是外部账号，一般没法在主人的企业里发起审批（具体要再确认）。而且审批单里放不下规格文档和 schema，审完还得有人手动搬。
建议直接用这个仓库的 PR 当审批：
- 群友开一个分支，按 参与修改 里的清单加规格文档和 schema，开 PR。
- 自动检查：OpenAPI 合法、示例符合 schema、站内链接都能打开。PR 页面上还有这一版文档站的预览网址。
- 主人审核：PR 里讨论、改到满意后合并，合并就是审批通过，谁批的、改了什么都有记录。
- 合并后维护者在游戏厅里实现，上线后在群里通知。
可以再加一步：有新 PR 或合并时，荷官在群里发一张卡片（GitHub 通知荷官），不看 GitHub 的人也知道有新游戏在审。
五、要主人定的
- 同意“账只有一本、游戏都进同一个游戏厅”这个方向吗？
- 群友的游戏先按方案 A（交规格、维护者实现）吗？
- 提交游戏用 PR 代替飞书审批吗？要不要群里的通知卡片？
- 仓库加哪些协作者（Dronnax 之外）？