台账第 030 条：文案三批上线，以及 exec 打到孤儿容器的发现

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

docs/复盘决定台账.md

@@ -243,3 +243,14 @@
 - 每天要评几个：近 31 个交易日累计出现过 208 个不同环节，"从没评过的"这个数从起步的每天 14 到 19 个，十天后降到 2 到 6 个，最后十个交易日中位 4 个。但指纹覆盖的是真正进模型的 32 条论断加 12 条事件，而每天新落库的事件是 900 到 1900 条，所以多数环节的事件榜单每天会被刷新、指纹跟着变。现实估算是每天评 20 个左右，约 59 万 token。用户确认这个量级可以接受。
 - 一处留待处置：触发密钥跟在网址后面，会明文写进接口的访问日志。不紧急（内网、日志只有本机能读），但与"凭据不入库"是同一性质的问题，做到治理那批时一起改成放在请求头里。
 - 复核日期：09-07（周一）看定时有没有自动跑，命令是 tail ~/akg_logs/review_segment.log。
+
+## 030 · 2026-09-04 · 文案三批上线；发现 exec 会打到一个跑了四周的孤儿容器
+
+- 改动：给人看的文字分三批改完。第一批是选股系统候选卡的四处（预期空间、传导那句、论断出处的 36 位编号、ST 门槛没文案掉进兜底）。第二批是 PMS 后端（规则闸六句、仓位约束六句、资金四句、计划取数两句），并抽了公共的显示层剥前缀函数。第三批是页面（操作日志印函数名、冻结原因漏网、提议卡印判决词、账本把整个字典打出来等九处），并新增一道静态守卫。
+- 一条必须守住的纪律：那些大写判据码是承重的，账本靠它取去重键、命令进度靠它做原因聚类。2026-07-29 账本被同一条指令按分钟灌满，病根就是去重键失效。所以码留在句首，只能在显示层剥。后端与前端各一份实现，注释互相指认，改一处必须两处同改。
+- 页面此前完全没有测试。新增的守卫检查四件事：枚举字段直出、判据码没剥前缀、把整个对象打给交易员看、翻译兜底裸奔。它实际比人工照清单改更可靠——多抓出四处清单里没有的。运维面板里有意显示原始数据的地方逐条登记放行，每条写明在哪个面板、为什么放行。
+- 顺带接上一个此前从没被渲染过的字段：候选卡的缺失项一路从选股系统带到 PMS 前端，页面上一次都没显示过。现在"关注"态终于说得出到底缺什么。
+- **发现一个环境问题，与本批改动无关但影响核验可信度**：`docker compose exec pms-web` 打到的不是服务容器，而是一个 2026-08-03 由 `docker compose run` 留下的孤儿容器（容器名 tradingsystem-pms-web-run-a4f4a87e7662），跑了四周、状态 unhealthy、用的是四周前的镜像。它跑的是 scripts/watch.py，不接端口、不影响生产，但会让 exec 做的核验落在旧代码上。
+- 识别办法：`docker compose ps -q pms-web` 报的容器 id 与 `docker compose exec -T pms-web hostname` 不一致就是撞上了。核验要紧的读数时用 `docker exec <真实容器 id>` 直接指名。
+- 处置：清掉那个孤儿容器要经用户同意，本次未动。
+- 复核日期：清理之后确认 exec 与 ps 报的是同一个容器。