处理pms系统对接

docs/选股计划入池_对接说明.md

@@ -98,3 +98,28 @@ docker compose exec -T akg-factor-bridge python run.py push-pool
 出现 SELL/AVOID 的闲置票进回收站，且决策系统随后把它们标 DROPPED。
 
 判收纪律照旧：代码就绪 ≠ 接通 ≠ 判收。判收 = 上面这四条在实机各看到一次。
+
+
+## 7. 池深与 PMS 下单候选的关系（2026-08-27 查明并定稿）
+
+这一节回答一个真问题：一只票能被 PMS 下单、却不在本分析池里，是不是出错了。答案是不出错，但两边的深度本来该对齐，这次把它对齐了。
+
+先分清两个深度，它们同源，但不是一回事。
+
+一个是本分析池的深度，参数是 POOL_TOP。它决定决策系统每晚深度分析多少只票，一只约两三分钟。
+
+另一个是 PMS 的下单候选深度，参数是 PMS_PLAN_TOP_N，在 tradingSystem 的 config/settings.py 里。PMS 建仓不读本 Mongo 池，而是直接调选股计划接口 plan_api，取主榜按分数前 PMS_PLAN_TOP_N 名，作为真正的下单候选。
+
+问题出在两个深度不一致。改之前 POOL_TOP 是 20，PMS_PLAN_TOP_N 是 30。于是主榜第 21 到 30 名的强传导票，PMS 能下单，却不在本分析池里，买它们的时候没有当晚的支撑压力位和定性结论托底。有个缓冲：买入即成持仓，而持仓永远进池，所以当晚池子重建后会补上分析。但买入当天到当晚那一段，是没有夜间结论的。2026-08-27 的 688599（天合光能，主榜第 25 名，强传导）正是这情形。那天它还叠了一层：自动闸先判拒，理由是资金净流出、无盘中买入信号、证据不足，随后被页面人工裁决改成通过并成交，所以那一笔是人工强下的，不是自动越界。
+
+用户拍板：本分析池要做成 PMS 下单候选的超集。这样能买的票一定先在夜间被分析过，用户也能观察到更宽的一批。
+
+要长期守的不变式：POOL_TOP 必须不低于 PMS_PLAN_TOP_N。日后在 PMS 侧调大 PMS_PLAN_TOP_N，必须同步把这里的 POOL_TOP 调到不低于它，否则「能买、没分析」的缺口又会回来。
+
+本次取值：POOL_TOP 由 20 提到 50，盖住 30 名的候选，另留 20 只强传导做观察；POOL_MAX 由 60 提到 100，容纳更深的计划加持仓加留池观察。
+
+成本要心里有数：夜间每只全量分析约两三分钟，POOL_MAX 决定夜扫总时长。100 只大约四小时，22:30 起约次日 02:40 完，仍在早上 08:40 盘前拉计划之前。嫌久就把 POOL_MAX 调小。
+
+自动维护：入池、留池、出池由 pool.push() 每天在盘前链里维护，持仓永不出池，掉榜但形态没恶化的票留在池里继续观察，形态恶化的进回收站。名单不需要手工维护。
+
+参数在哪：POOL_TOP 和 POOL_MAX 在 akg-factor-bridge 的 .env 里；PMS_PLAN_TOP_N 在 tradingSystem 的 config/settings.py 里，也可被 PMS 的 param_store 覆盖。改完 .env 要重建容器让新值生效，见第 5 节部署，注意 restart 不重读 env。