第一百一十一章 已删除
项磊给陈朗打了招呼，回来说：「他不太愿意。」
「说什么？」
「说这是技术内部的事，外部审计不需要了解到这里。」
「告诉他，」他发过去，「`recovery_handler.c`，git log 上的删除记录我们已经看到了。来或者不来，这个情况我们都会写进报告，区别是报告里有没有他的说明。」
沉默了大约十五分钟。
项磊发来：「他说可以，让你加他。」
陈朗通过得很快，但一开始什么都没发。
他先发过去：「陆衍，云帆。项磊应该说过了，你不需要对外说自己联系过我，我需要了解的是：你在 `recovery_handler.c` 里写的那段注释，是什么内容，然后是谁让你删的。」
等了将近五分钟。
「你真的看过 git log 了？」
「看了，删除提交的时间是 4 月 3 日，提交信息是 `style: remove verbose comments`。」
又停了几分钟。
陈朗回：「行，我说一下，但你不要让我在泉华内部出现。」
「只写技术发现，不写人名。」
「3 月 15 日，」陈朗开始发消息，「我在做 G2 的季度性维护，对照 `set_system_fault` 的调用链做了一次逐路径检查。在这个过程里，我注意到 G1 旁路和 G2 recovery 失败都在调同一个函数，但两条路进去的时候状态不一样。G1 那边调的时候内存锁是持有的，G2 这边在 recovery 彻底失败之后锁已经释放了。」
「当时查了一遍 G1 那边的文档，发现没有关于这条路径的说明，就在 `recovery_handler.c` 里写了一段注释，把这个情况记下来。」
「写了什么内容？」
「内容是：G1 旁路触发和 G2 recovery 失败同时发生时，`set_system_fault` 会被并发调用，G1 持有内存锁，G2 不持有。在测试环境下验证了这个场景，状态写入顺序会出错，退出码不可预期。最后一行写的是：`MUST REVIEW before production deployment`。」
「然后发生了什么？」
「方总在 4 月 2 日召集了 G1 和 G2 技术负责人开了一次联合会议，我没参加，但谭工后来跟我说，会议上讨论了 G1 合同收尾和 G2 后续维护的对接安排。」
「次日，谭工找我说，`recovery_handler.c` 里的注释太啰嗦，要我清理一下，保持代码干净。他当时说的是风格问题，我以为就是普通的代码整洁要求。」
「你删了？」
「删了，当天晚上推上去的。」
「谭工，就是你的 G2 技术负责人？」
「是，谭伟。」陈朗发过来，「他说清理注释的时候，我没有想太多，觉得他可能就是喜欢代码简洁。直到后来魏磊问我 G1 那边有没有注意到这条路径，我才想起来我删掉的那段注释。」
「谭工知不知道你写的是什么内容？」
「应该知道，他做 code review 的时候看到过那段注释。」
「他让你删的时候，有没有提到具体原因，除了代码风格以外？」
停了一会儿。
「他说，G1 和 G2 是分开的合同，G2 的维护代码里涉及 G1 的问题，会让界面变得不清楚，万一被审计方看到，会产生不必要的误会。」
那句话看了一遍。
「这就是我需要知道的，」他回，「谢谢。」
「报告里怎么写？」
「会写'G2 维护记录中曾有对该场景的技术描述，后因代码整理操作被删除'，不会点名。」
「行。」
把对话截图发给麦景行，加了一条：「4 月 3 日的那个提交，你能从 git 里把原来的注释恢复出来看一下吗？」
麦景行几分钟后发来：「找到了，这是删除前的版本——」
然后发来一段文本，是那段注释的原文：
```c / WARNING (2026-03-15): G1 bypass + G2 recovery_fail concurrent invocation of set_system_fault. G1 holds memory lock; G2 does not. Race condition confirmed in integration env — exit code non-deterministic (0x02/0x07/0x0E observed). MUST REVIEW isolation contract before production deployment. Ref: common/err_handle.h L.47 / ```
把这段文字读了两遍，又读了一遍。
这不是草率的标注。经过测试环境验证、有具体退出码记录、明确标注了引用路径，每一条都写得清清楚楚。简单说：系统上线前，有人已经验证过这里会并发出错，而且明确警告必须复核。`Race condition confirmed`，`Exit code non-deterministic`，`MUST REVIEW before production deployment`。
这段注释在 `recovery_handler.c` 里待了十九天，从 3 月 15 日到 4 月 3 日。4 月 2 日有个 G1/G2 联合会议，4 月 3 日晚上这段文字从代码里消失了。
「这个删除提交，」他问麦景行，「谁做 reviewer？」
「没有 reviewer，」麦景行回，「直接推到主干，没有任何 review。」
「其他时候陈朗的提交都有 review 吗？」
「查了一下，有，一般都有 1 到 2 个 reviewer。这个提交是他在 G2 这个库里唯一一次没有 review 的提交。」
两个信息放在一起。
唯一一次没有 review 的提交，恰好是这个删除操作。
有人主动掐断了那条记录链。
「联合会议那天有没有任何内部记录？」他问麦景行。
「不知道，代码库里没有，会议记录不在我们的权限范围里。」
「收到。」
他给乔木发了消息，把整个情况说了一遍：陈朗的证词，原始注释的内容，删除的时间节点，谭工的说法。
乔木看完，比前几次回复都快，直接发来：「现在的情况我来说一下，你看对不对。」
「3 月 15 日，陈朗在测试环境里验证了竞争条件，写了明确警告。4 月 2 日，G1/G2 联合会议，有方总参加。4 月 3 日，警告被删了，删除提交没有 review。」
「对。」
「现在的问题是，这件事的定性。」乔木说，「是'技术风险在内部没有被正式记录'，还是'已有明确警告记录，后被主动移除'。这两件事，报告里的表述不一样，法律属性不一样，对泉华的影响也完全不一样。」
他没有立刻回。
「合同里，我们的工作边界是什么？」乔木继续问。
「代码注释和安全关键代码的可追溯性文档。」
「git 历史，在不在这个范围里？」
「在，git 是代码的一部分。」
「有没有义务写这个？」
他想了一会儿。「有。」
「选择就一个，」乔木说，「如实写。但在交给方总之前，我建议先把这个部分单独拉出来给她看，给她一个心理准备的机会。」
他靠在椅背上，看着桌面。
如实写，就意味着报告会记录：泉华内部曾有一份明确的技术风险警告，在特定时间节点之后，这份警告从代码库中消失了，且删除操作没有经过常规 review 流程。
这份报告会进十一月的监管合规检查支撑材料。
监管方看到这份报告，就会看到这行字。
他给麦景行发了一条：「把 4 月 3 日删除提交的完整 diff 存一份，加上 3 月 15 日原始注释的内容，一起整理成一个单独的附件，先不放进报告正文，单独存着。」
「好，」麦景行回，然后停了一下，「陆哥，这报告出来，方总那边……」
「我知道，」他回，「等我见了她再说。」
手机放下来，窗外的天光已经是早上了。
刚准备关屏，手机又亮了一下。
是方晓晨。
「陆总，方便今天下午通话吗？关于报告进度，有几点想事先沟通一下。」
凌晨五点，方晓晨主动发来消息。
他看着这条消息，没有立刻回复。