台账 057：接口改读快照、新鲜度守卫、以及那处让计划不可复现的缺陷

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/复盘决定台账.md

@@ -527,3 +527,21 @@
 - **预期。** 交易日内计划接口不再出现超时；每天只在盘前预热那一次花三十多秒。
 
 - **复核日期。** 连续三个交易日观察 PMS 页面有没有再报超时。
+
+## 057 · 2026-09-10 · 计划接口改读当日全量快照；并修掉一处让计划不可复现的缺陷
+
+这一条起于你的一句质疑：靠缓存掩盖三十三秒的装配，这个设计是对的么。答案是不对，缓存只是把「每次都三十三秒」变成「每天第一次三十三秒」。查下去还牵出一个更要紧的问题。
+
+- **改动一：接口优先读当日全量快照，按请求参数截取。** 出计划时本来就落了一份全量快照（不裁剪、不设主题限额），注释里写明它是「复盘与对账的唯一底本」，只是接口一直没读它，每次请求都现场装配整池。现在接口先读那份底本，读不到或太旧就自动回落到实时装配。实测读快照零点四一秒、现场装配三十二点三秒，快七十八倍。
+
+- **改动二：新鲜度守卫。** 快照是出计划那一刻的定格，太旧就不能当今天的计划下发。两条判据，任一不满足就退回实时装配：代码版本要与当前一致（版本变了说明判决逻辑可能变了）；生成时刻距今不超过十六小时。**时间判据用的是「距今多久」而不是「晚于今天几点」**——选股系统容器跑在世界协调时上，早上七点十分出的计划，快照里记的是前一天二十三点十分，拿本地日期算界会差八小时，把新鲜的快照判成过期。显式指定日期时守卫不生效，复盘要拿的就是历史那一份。
+
+- **改动三，也是今天最值钱的一条：取因果论断的查询补上确定排序。** 那条查询原来没有 ORDER BY，而它的文档串写着「每票取最近披露日的最多三条」，代码却按数据库返回的天然顺序截前几条。没有排序时那个顺序不保证，于是同一个数据日、同一份代码，**相隔三十二秒的两次装配结果就不一样**：候选卡差五处、逻辑线差五处、候选卡名次差二十处，顶层的候选单与关注名单也不同。计划因此不可复现，下游也不知道自己拿的是哪一份，复盘更无从谈起。补上「按票、披露日倒序、论断编号」三级排序后，两次现算完全一致。
+
+- **这条缺陷是怎么被发现的。** 本来只是想验证「快照读出来的与现算的一不一样」，发现有实质差异；排除了代码改动的可能（这两天只动了接口与新增函数，没碰候选卡逻辑）之后，改用「连着现算两次」做对照，才发现现算自己跟自己都对不上。**如果不做这一步对照，会误判成「快照过时」，然后去修一个不存在的问题。**
+
+- **验证读数。** 两次现算逐行逐字段完全一致；快照截取与真实快照里当时下发的那份逐行比对，代码序列一致、除名次外逐字段一致、名次重编后完全一样；选股系统十个测试文件全部通过。
+
+- **预期。** 下次出计划（次日早七点十分）之后，接口走快照路径、毫秒级返回；计划成为可复现的，同一数据日同一代码算多少次都一样。
+
+- **复核日期。** 明日出计划后，看接口日志里的 source 字段是不是 snapshot，以及连续两次现算是否仍然一致。