76 lines
8.4 KiB
Markdown
76 lines
8.4 KiB
Markdown
# 3C补验收与4A方案独立审查
|
||
|
||
日期：2026-09-23。审查者：用户指定的独立审查AI（ZCode会话）。性质：只读审查，仅新增本文件；未修改代码、共享入口文档，未访问正式服，未使用子Agent。
|
||
|
||
## 审查对象SHA256
|
||
|
||
| 文件 | SHA256 |
|
||
|---|---|
|
||
| `阶段3C复核更正与补验收-2026-09-23.md` | `20CEA4BA6B274BBD108E7B931DAE5FCEDF457D0A803A0343622A33D274DFBFD5` |
|
||
| `阶段4存档接线分期与4A方案-2026-09-23.md` | `4A04700D9CA97992C6E0D25B2614DFA7AF6EECD99EFC4C3756FC134704C28D06` |
|
||
| `阶段4A实施任务书-待评审-2026-09-23.md` | `AF2E5217FE1DA1DFFCBC89CF707BE37EFCCEA89358C61768C824976673686F8E` |
|
||
| `KVStage3CTests/Program.cs` | `3C89DA087AA3841ADBA79A11BB2BAC724FD8F5F429D2124F826185EBBDDA64DA`（与更正文档记录一致，即上一轮终验所验收版本） |
|
||
|
||
## 双裁决摘要
|
||
|
||
- **裁决A（3C复核更正与修复设计）：通过。** R1–R5五项发现全部有源码依据，严重度评定恰当；修复任务书方向足够，附3项P3补充（A-S1～A-S3）。补验收完成前3C不得恢复"通过"。
|
||
- **裁决B（4A方案可实施性）：通过。** 接口租约、桥接所有权、Close屏障、旧句柄失效、取消语义均正确且在现有生产接口内可实现；A1–A12覆盖充分，附3项P3补充（B-S1～B-S3）。**4A编码批准仍被3C补验收前置门阻塞**（任务书前置门已正确列出）。
|
||
|
||
无新发现的P1/P2（R1–R5系对既有代码的确认，非本审查新增缺陷）。
|
||
|
||
## A：3C复核与补验收——R1–R5逐条确认
|
||
|
||
**R1/P1：确认成立。** 源码：`Program.cs:533` `action().WaitAsync(TimeSpan.FromSeconds(20))`仅取消等待不终止任务；`Live()`的L1/L2经`Run`包装（行283/287）；`LiveAccount`内`CreateAsync(..., default, ...)`（行310）无生命周期token，无外部取消通路；超时后孤儿任务继续在途变更，而`finally`的`CleanupCore`（行296–301）与其并发；`HadUnknownWrite`由孤儿路径置位（行319–320）可能晚于`WriteArtifacts`。触发：正式网络慢于20s的组合步骤。影响：清理与迟到写重叠、结果文件失真。P1恰当。
|
||
|
||
**R2/P1：确认成立。** 源码：`ValidateManifest`（行516–523）——`!k.StartsWith(m.Prefix)`在Prefix为空串时恒真；Prefix无格式约束（任意前缀＋以其开头的任意≤128键均可过）；keys无唯一性与精确后缀校验；`RunDirectory/CacheRoot`仅要求`InsideRuns`未绑定与manifest同一run；`InsideRuns`（行525–529）不拒绝重解析点/链接；`JsonConvert.DeserializeObject`不拒绝重复JSON属性与未知字段。触发：被篡改/损坏的manifest＋操作者运行`--cleanup`。影响：可授权删除非fixture key（含业务key）。P1恰当。
|
||
|
||
**R3/P2：确认成立。** 源码：`CleanupCore`行363 `Completed = !HadUnknownWrite && CleanedAccounts==2`，不依据断言失败；`Cleanup`（行332–341）独立进程以`failed=0`起点重跑并`WriteArtifacts`（行340→554–556）**覆盖原result.json与log**。影响：失败运行可被表现为成功且原始失败证据被销毁。P2成立；鉴于证据覆写后果，建议主会话将其修复按P1优先级排序（不改变分级）。
|
||
|
||
**R4/P2：确认成立。** 源码：`LiveAccount`行328–329只断言`Count==2`与键存在，不核对值；L2后不重读101；verify用`DirectGet`（裸Client）而非新登录＋新Owner重开同缓存（矩阵L4缺失）；删除目标`Keys[2]`从未先确认存在（碰撞预检全缺失⇒live删除的是从未写入的键，删除路径未被真实行使）。P2恰当。
|
||
|
||
**R5/P2：确认成立。** 源码：`OfflineChild`c分支（行145–150）仅Open＋Inspect，无Get/Ready断言（重开未Get状态必为NotLoaded）；`ConservativeUnknown`重开Owner使用新RecordingHandler（行230–231）无计数，行233`mutationCount==1`只覆盖首只handler，重开后不重发未证实；`CorruptionPolicy`缺"主档缺失＋bak/tmp遗留→RecoveryRequired"；live编排Unknown退出替身（矩阵L7）不存在；行102诊断`SnapshotDto("101", d, PlayerKVSyncStatus.Ready)`硬编码Ready，live诊断缺state/ticket/epoch真实字段。P2恰当。
|
||
|
||
### 修复设计的三点补充（P3，建议随裁决采纳）
|
||
|
||
- **A-S1（R1）**：修复应把owner生命周期token接到编排级linked CTS，使孤儿传输被确定性Cancel并经Close drain收尾，而非仅等待其自行结束；替身用例须用闸门同步证明"超时→停止→传输收尾完成→才允许清理"的顺序（不使用Sleep）。
|
||
- **A-S2（R3）**：原运行的断言状态须持久进manifest（当前manifest无该字段，补清理无法据原运行判定Completed）；补清理只生成独立补救产物，原result/log保持只读。
|
||
- **A-S3（R2）**："未知字段/重复属性拒绝"需显式严格解析（JObject白名单字段映射；JsonConvert默认行为不满足）；建议`--cleanup`在登录前完成全部校验，并输出将删除key的SHA256清单（不回显明文）供操作者核对。
|
||
|
||
## B：4A方案可实施性
|
||
|
||
| 审查点 | 结论 |
|
||
|---|---|
|
||
| Owner只读接口租约 | 正确。复用Owner准入门（含closing/closed/归属校验）；`State.ReadLocal`自带原子状态检查并返回独立拷贝（3A实现已核）；读后复查归属；不新建第二State、不改3A状态机 |
|
||
| 桥接重复拥有session | 无。明确"持有引用不拥有、不Dispose、登录控制器在Close完成后销毁"；单一所有权成立 |
|
||
| Close挡住新Open | 成立。桥接串行屏障＋3A文件租约（Busy）双保险；A4覆盖"忽略取消传输"等待场景 |
|
||
| 旧句柄写新账号 | 被阻止。固定句柄＋逐操作验证OwnerInstanceId/epoch（A6）；"仅全局epoch不足"判断正确——延后回调必须持固定句柄 |
|
||
| 取消等待误取消收尾 | 无。Open排队取消仅取消该等待者；Close异常保留失败状态并拒绝后续Open，锁未释放不被误作可重用 |
|
||
| 文件白名单 | 足够。`internal CreateAsync(handlerFactory)`注入点已存在（3B验证过同程序集编译），无需新增公共传输入口；修改`PlayerKVSessionOwner.cs`属已验收文件最小增量，A12要求3B回归保持通过且未允许文件hash不变 |
|
||
| 生产现状断言抽查 | 全部属实：`UserService.cs:306`HexNumber、`SurveyService.cs:56`、`FriendService.cs:375`、`FishingBehaviorB.cs:770`（async void）、`FishingTurntablePanel.cs:517/585`无条件`isDataSynced=true`、`DataCenter.PlayerData.cs`LoadPlayerData/NewPlayerDataDic、Coordinator tickets只增不清退 |
|
||
| 4B/4C约束反噬4A接口 | 未发现。固定句柄、空KV阻塞策略、票据语义均可由现有＋4A新增接口承载 |
|
||
|
||
### 三点补充（P3）
|
||
|
||
- **B-S1**：建议A2/A3扩展——`CreateAsync`失败（如初始Get失败）后桥接活动位必须清空，后续Open不被卡死。
|
||
- **B-S2**：建议增加"句柄ReadLocalSnapshot与在途Flush并发"用例：读应得到baseline→pending→localOnly合并视图且不干扰在途批次。
|
||
- **B-S3**：`ReadLocalSnapshot`错误分类中`StaleOrClosing`与`NotReady`并存时的优先级建议明确（建议StaleOrClosing优先，避免旧句柄被误报为数据未就绪）。
|
||
|
||
## 证据类型区分
|
||
|
||
- **历史运行证据**（保留为执行事实）：offline 7/7、live 3/3、42/86/29、Unity编译——不证明矩阵逐项满足；更正文档对此的定性正确。
|
||
- **静态推导**：R1–R5全部为源码级推导（本审查逐行确认）；均为"源码可达风险与覆盖缺口"，不是已发生的数据事故；未观察到正式服数据损坏。
|
||
- **尚未实测**：R1迟到写与清理重叠（合成复现方法：受闸门控制的延迟handler使L1超过20s，断言清理开始前传输已收尾——按更正文档§3.2在修复后执行）；L7替身；修复后的全部矩阵与新的正式正常路径run。
|
||
|
||
## 需主会话确认的事项
|
||
|
||
1. 采纳A-S1～A-S3、B-S1～B-S3为实施说明。
|
||
2. R3修复优先级建议按P1对待（证据覆写后果）。
|
||
3. 重申：3C补验收（含修复、逐行矩阵、外部复核）完成前，不得以4A设计通过为由批准编码；4A任务书前置门已正确列出该条件。
|
||
4. 更正文档§4关于"八文件历史基线"的自我更正（S101AccountSession仅本阶段hash）属实，无需再动。
|
||
|
||
## 结论
|
||
|
||
- **A：通过**（R1–R5确认，修复设计足够＋3项P3补充；3C恢复"通过"须待补验收闭环）。
|
||
- **B：通过**（4A方案可实施＋3项P3补充；编码批准以3C补验收闭环为前置）。
|
||
- 本审查无新增P1/P2。
|