05 · 架构 · 评审
能走通一次，不代表这张单可以进主干
技术负责人不改模块边界，卡的是这次提交有没有越界：列表直接写库存、集成模块改余额，不能因为能演示就进主干。
开发：待办列表上改数量保存，库存立刻对了，演示很快。
技术负责人：列表是读模型。谁允许它下命令？越界的提交，先别合并。
技术负责人守的是工程标准，不是进度口号
资深架构师写了边界，技术负责人保证代码没有越过边界，自己不另画一张模块图。岗位特点是把评审做成关卡：这条命令改了哪个模块拥有的数据，失败时回滚什么。写不出这两句，不能因为周五要演示而放行。演示可以在分支上给客户看，主干只收没有越界的版本。他把「能跑」和「能交付」分开，项目经理如果需要演示，用分支时间，不挪用主干质量。
评审清单里也有幂等、事务和权限，那是底线，不是本页的主实验。本地事务如何收口，由后端证明；外部只记一次，由集成证明。技术负责人看的是有没有人抄近路：查询接口写入、集成模块直接改余额、前端把库存余额当请求体回传。风格问题可以记债务，越界不能记债务。
评审怎样进行才不会变成形式
他要求作者自己先写三行：这条命令改哪些数据、这些数据的主人是哪个模块、失败时哪些会回滚。写不出三行的请求不进正式评审，避免会议室里现想。评审结论只有通过、改完再看、驳回重做，没有「先合并再补」。先合并再补的边界，生产上已经变成第二本账。
技术负责人也保护团队不被口头需求穿透。业务直接找开发加按钮时，他要求回到产品和变更，不在分支里私自加。私自加的按钮即使好用，也会让测试范围失真。他和测试负责人对齐：评审没通过的接口，不进提测。
列表页直接写库存的那次提交
一次合并请求让待办列表的行内保存直接 UPDATE 库存余额。作者证明点保存后面数马上对。技术负责人指出：库存模块才是主人，列表只应提交「改数量」的意图。同一周还有一条集成代码在回写成功后直接改本地余额，不走库存命令。两段代码读起来干净，都越界。请求被退回：列表只发命令；集成只投递已确认事件；余额仍由库存模块更新。
当天演示因此推迟到第二天下午。项目经理对客户解释的是「写入还在越界」，不是「开发慢」。这句话比带着第二本账上线便宜。主干在任何时刻都要能被测试环境拉起来，不依赖作者电脑上的手工改表。需要手工步骤的合并，写成脚本再看。回忆不是发布说明。整洁不是这个关卡的第一标准，有没有越界才是。幂等和事务仍是底线清单上的两行，由后端和数据库用自己的证据证明；本页的主实验是有没有人抄近路，让读模型下命令。作者若用「先让客户看见效果再拆」请求合并，技术负责人只允许该提交留在演示分支。主干上的列表保存必须仍是命令，不能带着 UPDATE 库存余额进去。评审记录里写明退回原因是越界，不是风格。