6813da149a
保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。 保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。 验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。 包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。
2.5 KiB
2.5 KiB
C3c 正式测试账号互加好友执行边界
用户明确批准“是的，允许你互相加好友”，并补充必要时可使用103–110。本次先用已有101、102；扩展账号权限不自动修改客户端正式准入101/102规则，也不代表本次已创建103–110。
执行前核查与裁决
- 已有FriendService.AddFriend构造MySelf（PlayFabId、AvatarUrl、DisplayName、Level）、MyFriendCount和FriendPlayFabId；AcceptFriend使用Status=1、接受者PlayFabId、邀请者FriendPlayFabId。请求继续使用旧字段名，值为新UserID，遵循原UI邀请/接受顺序。
- 本轮批准的是具体正式账号测试操作和脱敏证据，不是C3c剩余生产源码编码许可。无新增抽象、无生产代码修改；不重新提交用户已经批准的好友操作。
- 分账号独立Cookie登录，不附带playerProfile；核state=0、newCreate=false。只读本人KV中的Lv、DisplayName、AvatarUrl、InfiniteBuildingData、LastLoginTimeUtc，为原AddFriend请求取得真实值。Lv无可用值时不编造等级提交。
- 先读取双方好友关系。若已互为好友，直接取样。否则101向102发送一次原AddFriend；成功后重读关系，若未直接互为好友，由102接受101邀请一次，再核双方列表。错误/超时不盲目重发写操作，先读回状态。
- 昵称/头像缺键沿已有KVUserService默认规则，已有值原样使用。MyFriendCount来自真实当前好友列表。保留其他既有好友。
- 日志记录HTTP、业务Code、双方关系和单项字段结构；不保存Cookie、凭证或玩家昵称/头像正文。可以记录测试UserID、数值等级和时间用于等价比较。
- 不删除本次关系，便于后续客户端验证。用户授权好友关系写入；不顺带发KV Set/Delete、UpdateProfile、领奖、付费、Play或打包，不读改服务器源码。
验证目标
双向好友关系实际存在；取得当前friend/GetFriendsList的非空单项结构，核PlayerID/昵称/头像/Level或LevelB/建筑等级/LastLogin。缺字段如实记录，不因好友成功就认定资料全部齐全或后端一定由KV实现。
预检补记：首次仅读Lv不能取得101真实等级，未发出好友修改请求。依据现行PlayerKVSaveSchema.DecodeCore，补读NewPlayerDataDic并优先取19槽newData的第0槽；若同时存在旧Lv，要求值一致。此为实测驱动读取现有存档格式的修正，不改生产解析器，不把现代档缺少独立Lv当坏档。初次失败JSON保留，后续证据另存final。