同一个事实只能有一个定义
路径、时间窗、开关条件在两端各写一份，就会悄悄分叉。防止写方和读方各自实现同一份约定
跨进程、跨端的约定只定义一次，做不到就加对齐测试
发生了什么
同一个月里出了三次同类问题。
第一次是信号文件。后台进程发现凭证失效时，把信号文件写到账号自己的目录下；桌面端在用户重新登录后，去清根目录下的同名文件。路径逻辑两边各写了一份，桌面端这一步其实是空操作，用户重新登录后一直卡在“登录已过期”。功能合并几小时后，我在自己机器上重新登录失败，才查出来。
第二次是共享开关。服务端新加了一道闸门，要求“已公开”和“已同意绑定”两个条件同时成立，前端的开关却只写了前一个，第二个字段从来没接上。界面上显示已公开，请求照样被拒。两天多之后，用户撞上才发现。
第三次是在线判断。系统里判断“机器是否在线”的时间窗有 60 秒和 150 秒两种值，一处按 150 秒判定在线，另一处查询按 60 秒找机器。修复时，独立评审又在监控指标里翻出第四处不一致。
为什么会这样
这些约定跨越了类型系统能看到的范围：一端是 Go，一端是 TypeScript；或者同一种语言，但值写在互不引用的几个地方。类型检查看不到，单边的测试也看不到，因为每一边单看都是对的，错在两边之间。
agent 会放大这个问题。它按任务写代码，写方和读方常常不在同一个任务里；看到需要一个路径，顺手再写一份，比找到已有的定义更省事。
怎么做
同一种语言：只留一个定义，其余的派生。时间窗那次，我把重复的常量改成从一个常量派生，查询函数的窗口改成必传参数，让编译器强制对齐。
跨语言共用不了：加对齐测试。两端用同一份测试数据，断言算出来的路径或字段完全一致。新增信号文件、health 字段这类跨进程协议时，PR 必须带上这个测试。
服务端加了用户可见的闸门或字段，PR 里列出前端消费点。没有消费点，就说明功能只做了一半。
改一个值之前，先搜它还出现在哪：
git grep -n '<那个值或字段名>'验证要走失败路径：凭证失效、再恢复，这种全流程要在真机上走一遍。只验证正常路径，上面的第一个问题根本看不到。