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
..
__init__.py	第二批: 命令状态机/方案生成器/回放对账/管理页面/调度器骨架	2026-07-27 17:12:09 +08:00
advice_service.py	数量按建议档位重算：卡上写试探仓 1%，采纳后就真的只买 1%	2026-09-10 13:42:39 +08:00
candidate_pub.py	候选池发布给择时决策系统（台账 004）	2026-09-09 15:30:35 +08:00
command_service.py	PMS 页面显示：用户设的止损价与目标价单独成列，参考位列标明来源	2026-09-03 16:30:49 +08:00
dispatcher.py	代码全面修改	2026-08-28 13:07:27 +08:00
exec_advisor.py	处理命令冲突的问题	2026-08-20 11:09:33 +08:00
executor.py	PMS 两处安全修复：强制交人改为一票否决不再被卖出方向短路；目标价与止损价接通且必定交人	2026-09-03 16:06:27 +08:00
industry.py	代码全面修改	2026-08-28 13:07:27 +08:00
judge.py	解锁重问：判定、取数、接线、参数、单测（台账 055 第二件之 PMS 侧）	2026-09-09 15:13:09 +08:00
ledger_service.py	数量按建议档位重算：卡上写试探仓 1%，采纳后就真的只买 1%	2026-09-10 13:42:39 +08:00
logic_state_service.py	公司质地与建议方案接入：公司深度两键透传、整句送研判可关、建议方案矩阵与研判补档、持仓页一行、三个运行参数、单测（台账 053）	2026-09-09 12:15:03 +08:00
macro_service.py	代码全面修改	2026-08-28 13:07:27 +08:00
market.py	解锁重问的判定逻辑与取数：纯逻辑模块 + 当日成交量与五日均量	2026-09-09 15:05:20 +08:00
param_store.py	解锁重问：判定、取数、接线、参数、单测（台账 055 第二件之 PMS 侧）	2026-09-09 15:13:09 +08:00
plan_feed.py	公司质地与建议方案接入：公司深度两键透传、整句送研判可关、建议方案矩阵与研判补档、持仓页一行、三个运行参数、单测（台账 053）	2026-09-09 12:15:03 +08:00
portfolio.py	PMS 文案第二批：规则闸、仓位约束、资金、计划取数	2026-09-04 13:27:45 +08:00
proposal_service.py	数量按建议档位重算：卡上写试探仓 1%，采纳后就真的只买 1%	2026-09-10 13:42:39 +08:00
publish_export.py	修复公示导出：模板残留隐藏行把合计行与图表整段藏掉；红绿条件格式按最终行位重建；净值+仓位双系列带标记图表	2026-08-28 17:20:58 +08:00
reask_service.py	解锁重问：判定、取数、接线、参数、单测（台账 055 第二件之 PMS 侧）	2026-09-09 15:13:09 +08:00
signal_service.py	第零件甲组：PMS 目标价那条路的四个缺陷，加裁决理由服务端强制	2026-09-07 11:22:05 +08:00
strategy_advisor.py	模拟库和正式库分离	2026-08-28 14:34:00 +08:00
strategy_runner.py	代码全面修改	2026-08-28 13:07:27 +08:00
strategy_service.py	代码全面修改	2026-08-28 13:07:27 +08:00
upstream_signals.py	资金异动方向两套写法都认	2026-09-09 14:59:11 +08:00