添加回测脚本

DEVLOG.md

@@ -30,6 +30,30 @@
 
 ---
 
+## 2026-08-27（续二）· 查清「池外的票被下单」：不是 bug，是分析池比下单候选浅，决定把分析池调成超集
+
+**背景**
+盘中发现 688599（天合光能）被下单，但它不在我们的 AKG_PLAN 股票池里，怀疑系统越界买了池外的票。
+
+**查明的结论**
+不是 bug，是两件事叠在一起。
+
+第一件，两个「池」的深度本来就不一样，而且允许不一样。分析池 AKG_PLAN 是决策系统每晚做深度分析的范围，深度由 akg-factor-bridge 的 POOL_TOP 决定，原值 20。PMS 真正下单的候选不读这个 Mongo 池，而是直接调选股计划接口 plan_api，取主榜按分数前 PMS_PLAN_TOP_N 名，原值 30。688599 当天主榜第 25 名、强传导。25 比 30 浅，所以进了下单候选；又比 20 深，所以不在分析池，正好卡在中间。这个差在两处配置注释里都写明是有意的，PMS 的建仓引擎里甚至拿「候选池第 25 名」当例子。
+
+第二件，那一笔是人工强下的。账本三条显示，9 点 43 自动闸判 REJECT，理由是主力净流出、主散背离、无盘中买入信号、证据不足；9 点 46 被「页面人工裁决」改成 PASS；9 点 47 成交 1600 股。查上游买入计划表 trading_buy_plan 与决策账本 decision_ledger，对 688599 当天都是 0 行，证明它没走上游建仓仲裁那条路，全程在 PMS 侧。
+
+**用户拍板的改动（待在服务器执行）**
+把分析池做成下单候选的超集，让能买的票一定先被夜间分析，也便于观察。要长期守的不变式：POOL_TOP 不低于 PMS_PLAN_TOP_N。本次 POOL_TOP 由 20 提到 50，POOL_MAX 由 60 提到 100，两个都在 akg-factor-bridge 的 .env。执行方式：改 .env 两行，然后 docker compose up -d --force-recreate akg-factor-bridge（restart 不重读 env），再 docker exec akg_factor_bridge python run.py push-pool，先 --dry-run 后真写。成本：夜扫每只约两三分钟，POOL_MAX 决定总时长，100 只约四小时，嫌久就调小 POOL_MAX。设计细节写进了 akg-factor-bridge/docs/选股计划入池_对接说明.md 第 7 节。
+
+**动了哪些文件**
+akg-factor-bridge/docs/选股计划入池_对接说明.md 加了第 7 节，讲池深与 PMS 下单候选的关系。POOL_TOP 与 POOL_MAX 的实际改动在服务器 .env，待用户执行。
+
+**还欠着**
+一，上面两个 env 改动要在桥机 factorevaluation 执行并判收，push-pool 之后 688599 应当进池。
+二，TECH_POOL 怎么喂进下单候选还没查，用户说后面再做。
+三，早前做的两个只读回测脚本 scripts/backtest_churn.py 与 scripts/backtest_entry.py 已在库里。结论是：决策系统的快卖多为正确止损，卖出端不加最小持有期护栏；但入场时点系统性偏晚，全体买入五个交易日后平均还在亏；账本目前只有一个月、一段行情，入场过滤先不上，等数据攒够再验。
+四，bionic 云端通路三处改动（config/settings.py、app/services/llm_client.py、workers/tasks_intraday.py）仍待用户在自己终端提交并上 192.168.16.188 部署。
+
 ## 2026-08-27 · PMS 加登录与两个角色（系统管理员 / 交易员），认证接第三方 bshop
 
 **背景**