协议与契约
这一区收的是跨两端的内容——描述"谁和谁之间约定了什么"，而不是某一端内部怎么实现。
原先这些内容在客户端与服务端文档里各写一份，两边视角不同、措辞不同，改动时又常常只改 一边，于是慢慢漂移。合并文档站时把它们收敛到这里，每条契约只有一份权威描述。
三份契约
| 文档 | 约定了谁和谁 | 违反的后果 |
|---|---|---|
| 客户端 ↔ 服务端握手协议 | 我们的客户端 ↔ 我们的服务端 | 已发布的 APK 解析失败，真机崩溃或行为异常 |
| 引擎数据契约 | 我们的补丁 ↔ 游戏引擎（native / WebView） | 补丁注入失效、汉化不生效、状态重放错乱 |
| 上游游戏后端 API 清单 | 客户端 ↔ 不由我们掌控的 Totentanz / 官方后端 | ——（只读整理，供将来自建后端参考） |
三者的性质完全不同
第一份是硬契约：只增不改
客户端是已签名、已分发的 APK，字段名与解析逻辑钉死在包里，无法随服务端热改。 所以 /client/* 的 JSON 字段只可新增，不可删除 / 改名 / 改类型 / 改语义， 新增字段必须可选。变更流程是「先加新字段 → 客户端适配发版 → 双跑过渡 → 再废旧」。
这是整个项目里唯一一条"改错了就没法回滚"的规则——服务端可以随时改代码，但已经装在 玩家手机上的 APK 不能。
第二份是互操作边界
补丁与游戏引擎之间靠 hook 点、符号名、资源路径、JS bridge 约定协作。这些不是我们定的， 是逆向出来的——底包一换就可能变。所以这份文档同时也是"换底包时要逐条重新核对的清单"。
第三份是历史存档，不是活契约
上游服务端已不可达。这份清单来自社区留存的历史流量抓包（2024-06-05 至 07-30， 293,217 条请求），是一次性、不可再生的资料，只作将来若要自建游戏后端时的规格基线。 它描述的不是我们的任何一个接口。
从哪读起
- 要改服务端响应 → 握手协议 + 协议保真原则
- 要换底包 / 改 native hook → 引擎数据契约 + Native Hook 层
- 想了解自建游戏后端的工作量 → 上游 API 清单