zlt
|
c9b468e7a2
|
数量按建议档位重算：卡上写试探仓 1%，采纳后就真的只买 1%
一、问题。155 实测 8 张待确认提议，7 张卡上写「建议方案：试探仓（目标 1.0%，
分批 100%）」，而每一张采纳后实际会买 3.00%（标准仓 6% 的第一批），正好三倍。
只有 300118.SZ 那张标准仓的是自洽的。
根因是次序。候选产出时 advise() 的档位是进过数量的（params_for 把 target_pct
塞进 stock_target_default，action_engine 据此拆批）。但研判回来之后 apply_judge
还会再降一档 —— 把握度低或结论不可用就降成试探仓 —— 那一步只改档位文字，数量
已经算完了。apply_judge 的说明原文写着「不改数量, 数量交人」，而页面上采纳按钮
根本没有填数量的地方，这个「交人」无处兑现；采纳时后端直接抄提议里的股数原样
落单（web/main.py 只有卖出侧会按可卖量重算）。
二、改法。新增 advice_service.resize_to_advice，在 apply_judge 降档之后重算这一批
的股数，并把 target_pct / target_amount / base_amount / batch_scheme 一起改掉 ——
否则卡上那三个数字仍然是旧口径。总规模不另外读参数表，直接从硬数字里的
target_amount ÷ target_pct 反推，保证与当初算数量用的是同一个规模。
买不足一手时抬到一手：300604.SZ 现价 264.81，1% 只有 75 股，抬到 100 股实际
占 1.32%，仍远小于机械档 6%。但一手金额不许超过机械档 —— 超过说明这只票对当前
规模本来就太贵，那就不改数量、把原因留在卡上，不默默按旧数量下单。
三、一并补上持仓的目标仓位。pms_position.target_pct 这一列全库从来没有任何一处
写过，而动作引擎算补仓与加仓金额时先读它、读不到退全局 6%。不补的话会得到一个
更难看的组合：第一笔只买 1%，随后系统自己按 6% 一路补，试探仓的意思当场作废。
现在在建仓成交入账时记一次，且只记第一次（目标仓位是建这只仓时定的意思，
后续加仓不该改）。记不上绝不拦成交入账。
四、补一个洞：上游标了硬风险的候选一律交人，哪怕档位是 full。
这一条原先只写在 _verdict_auto_exec_why 那条更窄的旁路里（第四条「上游风险列表
为空」），而一票否决那条链完全不看 risk。后果是反的：档位是 propose_only 时旁路
会拦住带风险的票，一旦档位改成 full，那条旁路根本不走，带硬风险的候选反而畅通
无阻直接落指令 —— 越放开越不设防。交人原因也把硬风险排到最前，不再笼统说
「档位 propose_only」。
硬风险是选股系统在候选卡上标的三类：昨夜给出卖出/回避/已剔除信号、用的传导快照日
与计划日不符、吸筹为高位派发。
五、方向。这一批改动只会让发出去的钱变少或不变，不会变多：同一张卡从 1200 股
58,260 元降到 400 股 19,420 元；硬风险那条是把自动执行改成必须人点头。
新增 test_batch26_units.py 十七例，D 组专门钉「重算之后的金额一定不超过原来那一笔」。
前端跟上两种结果：重算成功了说一声「数量已按试探仓重算：1200 股 → 400 股」，
重算不成的把原因摆在卡上。两道页面守卫通过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-10 13:42:39 +08:00 |
|
zlt
|
7e06e43334
|
代码全面修改
|
2026-08-28 13:07:27 +08:00 |
|
zlt
|
680210ebcc
|
处理现有问题
|
2026-08-03 09:24:29 +08:00 |
|
zlt
|
d1e0cb9298
|
处理现有问题
|
2026-08-03 09:10:56 +08:00 |
|
zlt
|
889e2ef5b8
|
资金快照不可信时整轮跳过刹车结算
|
2026-07-31 16:43:43 +08:00 |
|
zlt
|
2ae59df497
|
处理对应bug
|
2026-07-31 16:10:58 +08:00 |
|
zlt
|
72d35e7fc9
|
处理没成本价的问题
|
2026-07-31 14:19:36 +08:00 |
|
zlt
|
ea542103bb
|
PMS 内部那一截——候选池 → 建仓/升仓命令 → 方案生成 → 指令 → 规则闸终检 → 择时分日配额
|
2026-07-31 14:03:33 +08:00 |
|
zlt
|
bab6d0ec27
|
账本重建
|
2026-07-31 13:46:15 +08:00 |
|
zlt
|
0ab611b9e3
|
买入前资金校验+规模偏差可见; 给QMT侧补1100股来历与持仓情形要求
|
2026-07-30 13:02:51 +08:00 |
|
zlt
|
4f2a545505
|
修事实源判据: 应答空集≠没应答, force 生路; SRC_NONE 下 force 不放行
|
2026-07-30 12:05:22 +08:00 |
|
zlt
|
e32b6df05b
|
补协议§6.2快照对账: query轮询+ws为主表兜底的事实源仲裁
|
2026-07-30 11:59:12 +08:00 |
|
zlt
|
204914cc12
|
ws入账三分流: 孤儿成交挂起不入账; 协议升V1.0.1; 交接文档同步
|
2026-07-30 10:34:34 +08:00 |
|
zlt
|
691c8ad84a
|
处理s3收尾工作
|
2026-07-30 08:42:06 +08:00 |
|
zlt
|
580e03fc76
|
处理s3收尾工作
|
2026-07-29 16:55:45 +08:00 |
|
zlt
|
795a8b4e4e
|
s3
|
2026-07-29 14:50:04 +08:00 |
|
zlt
|
4b49d39ccd
|
处理入账、消费等问题
|
2026-07-29 10:49:56 +08:00 |
|
zlt
|
48f9e653da
|
处理页面渲染不完全的问题
|
2026-07-29 10:12:12 +08:00 |
|
zlt
|
e217f2c817
|
处理页面渲染不完全的问题
|
2026-07-29 10:01:00 +08:00 |
|
zlt
|
9c2470df21
|
修复: 建表脚本/redis RESP3/参数缓存穿透/回放认领时间守卫
|
2026-07-27 17:31:34 +08:00 |
|
zlt
|
b3fdb4a4e6
|
第二批: 命令状态机/方案生成器/回放对账/管理页面/调度器骨架
|
2026-07-27 17:12:09 +08:00 |