group_xinghuo_jinrong

147 Commits 9 Branches 1 Tag

3 Commits

Include renames

Author	SHA1	Message	Date
GaoYiYuan_0626	cde0c226fe	基金转换 T+1 模型：T-15/T-16/T-17 收官（842 绿 / 真库 9/9 / 转换线第 5 步完成） T-15 D28 部分成交专项： - sqlite +1 终态单幂等 skipped 口径裁定（ConfirmConflict 仅限读后状态才变窗口） - 真库 confirm +3 组 19 项（E2 占用释放双向 / G2 actual_qty=0 → rejected / H2 撤单后确认）→ 102/102 - CONVERT_STRESS Barrier(2) 窄窗争批：恰 1 confirmed + 1 rejected - 突变实证防御纵深：④可用量复核 / ⑤plan_lots / 事务内哨兵三道防线拆任一道仍收敛 rejected T-16 D29 资金流中转： - _insert_cash_flows 全仓唯一写入点（out/redeem 费前 + in/subscribe 净转入，remark=convert:{gid} 同事务） - test_confirm_writes_no_cash_flow 反转为恰 2 条 + 金额对账（T-7 登记闭环） - 真库 apply A2 组 + B 组 0 残留 → 30/30；confirm 反转断言 → 103/103 - FK 坑（core_cash_flow.fk_cf_customer 挡客户删除）：5 处清理段补删 T-17 D30 share_class + A/C 互转： - _validate_products 纯新增拦截分支：两端 share_class 非空且不同才查 allow_ac_convert（任一端=1 两向放行） - 口径裁定 2 条（R-12 字面偏差，待用户追认）：NULL 不参与 A/C 判定 / 同类走一般转换规则 - 联网核实（用户铁律）：A/C 互转需管理人开通（摩根 2025-11 公告）= 开关真实载体；持有期重新起算与本仓一致 - 种子 ⑥ 段（双开对/双关对照/同类对照）；sqlite +4 → 842 passed / 8 skipped；真库 accept H 组 → 43/43 - 突变：分支失效 → closed 红，还原绿文档：开发计划 T-15~T-17 DoD 全勾 + 执行记录 · 基线 842 · TODO/MEMORY/AGENTS/交接文档 v4.5 终态（第 5 步收官 → 下一步第 6 步集成测试）	2026-09-12 13:42:49 +08:00
GaoYiYuan_0626	0e27fec5cb	文档：T-7 确认段落地回写（开发计划 DoD 全勾 + 执行记录 / 交接文档 §B.11 / TODO / 两处 MEMORY） - 开发计划 T-7：DoD 9 项勾选 + 新增「执行记录」小节，逐条留痕 6 处与计划的差异裁定： ① 确认段不做最低持有重判（计划缺口，强制全转属受理段决策，受理单 remark 传承）； ② 新增 format/audit/engine_call 三共用模块（后者顺带完成 T-8 的「引擎时机改」）； ③ nav.py 未改（确认段直调 core_ro.get_nav_on，取 T−1 路径随 v1.0 convert_fund 一并删）； ④ test_convert_integration 改写推迟到 T-9（需端到端真接口）； ⑤ 受理单置 confirmed 并入 apply_convert 同事务（防「批次已扣、状态未置」中间态）； ⑥ MySQL rowcount=changed rows 陷阱（nav_pending 重试不得复用冲突判定）。 - 交接文档 §B.11：T-6→T-7 完成、基线 797→827、真库 36/36→37/37 与 83/83、新增 T-7 实施期发现段、下一步 T-8/T-9（并注明 T-8 范围已缩小）。 - docs/memory/TODO.md：进度行 + T-6 真库数 + T-7 条目勾选与详述。 - .workbuddy/memory/MEMORY.md 与 docs/memory/MEMORY.md：进度与关键裁定同步；当日工作日志补「续 3：T-7 确认段落地」。	2026-09-11 19:37:30 +08:00
GaoYiYuan_0626	048f1a9e1e	基金转换 T+1 模型：T-7 确认段落地（confirm_service 三段编排 + T+1 批处理）【新增】 - app/service/convert/confirm_service.py：confirm_one（8 步确认）+ confirm_batch （按业务日捞单 / 整批锁 / 串行 / 单笔容错）。关键裁定： · T 日净值用 get_nav_on 精确匹配，缺则 nav_pending（绝不回退旧净值）； · 扣批次 + 2 条流水 + 转入批次 + 两端持仓 + 明细 + 受理单置 confirmed 同处一个 Core 单库事务，状态被抢（rowcount!=1）→ 整事务回滚； · 引擎在事务 commit 后跑，异常不阻断已成立的交易（FR-C28）； · 部分成交 actual=min(申请,可用)，被抢部分占用自然释放（R-10）。 - app/service/convert/format.py / audit.py / engine_call.py：展示规格、审计、引擎调用三处共用出口抽出（受理/确认两段不再各写一份，避免口径漂移）。 - scripts/dev/verify_convert_confirm.py：真库验证 81 项断言，含 PRD §5.3.2 示例在真库上逐字节重放（68020.00/612.18/67407.82/333.36/67074.46/34945.54/-0.0049）。【修复 · 受理-确认接口契约缺口】强制全转是受理段决策（受理时 qty 已收敛为实际全转量），确认段拿不到原始申请量、无法复现该判定。修法： - 受理段把 forced_full_transfer 落受理单 remark（新增 REMARK_FULL_TRANSFER）； - 确认段改为继承受理决策、不再重判最低持有（plan_lots 不传 min_hold_qty） —— 重判会因 T→T+1 可用份额变化得出与受理承诺不一致的结论（擅自扩大客户指令）； - remark 支持多标记 `;` 连接（full_transfer;partial）。 - MySQL rowcount=changed rows 陷阱：nav_pending 重试不得复用 transition_status 的冲突判定，改为 status 未变时不迁移、返回 transitioned=False。【其他】 - convert_service：新增 cancel_convert（T 日撤单，两道闸门）、_t1_t2_dates （日历边界 None 容错）；受理响应改为 PRD §5.3.1 字段；convert_fund 标 Deprecated。 - convert_core_repository：ConvertApplyInput 加 convert_request_id/diff_fee/ request_remark；_apply_convert_once 末步 _confirm_request 事务内置状态守卫。 - convert_request_repository：_end_of_day 统一闭区间语义；新增 reject()。 - 测试：新增 tests/test_convert_confirm.py（24 例）；全量 827 passed / 10 skipped。	2026-09-11 19:35:37 +08:00

Author

SHA1

Message

Date

GaoYiYuan_0626

cde0c226fe

基金转换 T+1 模型：T-15/T-16/T-17 收官（842 绿 / 真库 9/9 / 转换线第 5 步完成）

T-15 D28 部分成交专项：
- sqlite +1 终态单幂等 skipped 口径裁定（ConfirmConflict 仅限读后状态才变窗口）
- 真库 confirm +3 组 19 项（E2 占用释放双向 / G2 actual_qty=0 → rejected / H2 撤单后确认）→ 102/102
- CONVERT_STRESS Barrier(2) 窄窗争批：恰 1 confirmed + 1 rejected
- 突变实证防御纵深：④可用量复核 / ⑤plan_lots / 事务内哨兵三道防线拆任一道仍收敛 rejected

T-16 D29 资金流中转：
- _insert_cash_flows 全仓唯一写入点（out/redeem 费前 + in/subscribe 净转入，remark=convert:{gid} 同事务）
- test_confirm_writes_no_cash_flow 反转为恰 2 条 + 金额对账（T-7 登记闭环）
- 真库 apply A2 组 + B 组 0 残留 → 30/30；confirm 反转断言 → 103/103
- FK 坑（core_cash_flow.fk_cf_customer 挡客户删除）：5 处清理段补删

T-17 D30 share_class + A/C 互转：
- _validate_products 纯新增拦截分支：两端 share_class 非空且不同才查 allow_ac_convert（任一端=1 两向放行）
- 口径裁定 2 条（R-12 字面偏差，待用户追认）：NULL 不参与 A/C 判定 / 同类走一般转换规则
- 联网核实（用户铁律）：A/C 互转需管理人开通（摩根 2025-11 公告）= 开关真实载体；持有期重新起算与本仓一致
- 种子 ⑥ 段（双开对/双关对照/同类对照）；sqlite +4 → 842 passed / 8 skipped；真库 accept H 组 → 43/43
- 突变：分支失效 → closed 红，还原绿

文档：开发计划 T-15~T-17 DoD 全勾 + 执行记录 · 基线 842 · TODO/MEMORY/AGENTS/交接文档 v4.5 终态（第 5 步收官 → 下一步第 6 步集成测试）

2026-09-12 13:42:49 +08:00

GaoYiYuan_0626

0e27fec5cb

文档：T-7 确认段落地回写（开发计划 DoD 全勾 + 执行记录 / 交接文档 §B.11 / TODO / 两处 MEMORY）

- 开发计划 T-7：DoD 9 项勾选 + 新增「执行记录」小节，逐条留痕 6 处与计划的差异裁定：
  ① 确认段不做最低持有重判（计划缺口，强制全转属受理段决策，受理单 remark 传承）；
  ② 新增 format/audit/engine_call 三共用模块（后者顺带完成 T-8 的「引擎时机改」）；
  ③ nav.py 未改（确认段直调 core_ro.get_nav_on，取 T−1 路径随 v1.0 convert_fund 一并删）；
  ④ test_convert_integration 改写推迟到 T-9（需端到端真接口）；
  ⑤ 受理单置 confirmed 并入 apply_convert 同事务（防「批次已扣、状态未置」中间态）；
  ⑥ MySQL rowcount=changed rows 陷阱（nav_pending 重试不得复用冲突判定）。
- 交接文档 §B.11：T-6→T-7 完成、基线 797→827、真库 36/36→37/37 与 83/83、
  新增 T-7 实施期发现段、下一步 T-8/T-9（并注明 T-8 范围已缩小）。
- docs/memory/TODO.md：进度行 + T-6 真库数 + T-7 条目勾选与详述。
- .workbuddy/memory/MEMORY.md 与 docs/memory/MEMORY.md：进度与关键裁定同步；
  当日工作日志补「续 3：T-7 确认段落地」。

2026-09-11 19:37:30 +08:00

GaoYiYuan_0626

048f1a9e1e

基金转换 T+1 模型：T-7 确认段落地（confirm_service 三段编排 + T+1 批处理）

【新增】
- app/service/convert/confirm_service.py：confirm_one（8 步确认）+ confirm_batch
  （按业务日捞单 / 整批锁 / 串行 / 单笔容错）。关键裁定：
  · T 日净值用 get_nav_on 精确匹配，缺则 nav_pending（绝不回退旧净值）；
  · 扣批次 + 2 条流水 + 转入批次 + 两端持仓 + 明细 + 受理单置 confirmed
    同处一个 Core 单库事务，状态被抢（rowcount!=1）→ 整事务回滚；
  · 引擎在事务 commit 后跑，异常不阻断已成立的交易（FR-C28）；
  · 部分成交 actual=min(申请,可用)，被抢部分占用自然释放（R-10）。
- app/service/convert/format.py / audit.py / engine_call.py：展示规格、审计、
  引擎调用三处共用出口抽出（受理/确认两段不再各写一份，避免口径漂移）。
- scripts/dev/verify_convert_confirm.py：真库验证 81 项断言，含 PRD §5.3.2
  示例在真库上逐字节重放（68020.00/612.18/67407.82/333.36/67074.46/34945.54/-0.0049）。

【修复 · 受理-确认接口契约缺口】
强制全转是**受理段决策**（受理时 qty 已收敛为实际全转量），确认段拿不到原始
申请量、无法复现该判定。修法：
- 受理段把 forced_full_transfer 落受理单 remark（新增 REMARK_FULL_TRANSFER）；
- 确认段改为**继承受理决策、不再重判最低持有**（plan_lots 不传 min_hold_qty）
  —— 重判会因 T→T+1 可用份额变化得出与受理承诺不一致的结论（擅自扩大客户指令）；
- remark 支持多标记 `;` 连接（full_transfer;partial）。
- MySQL rowcount=changed rows 陷阱：nav_pending 重试不得复用 transition_status
  的冲突判定，改为 status 未变时不迁移、返回 transitioned=False。

【其他】
- convert_service：新增 cancel_convert（T 日撤单，两道闸门）、_t1_t2_dates
  （日历边界 None 容错）；受理响应改为 PRD §5.3.1 字段；convert_fund 标 Deprecated。
- convert_core_repository：ConvertApplyInput 加 convert_request_id/diff_fee/
  request_remark；_apply_convert_once 末步 _confirm_request 事务内置状态守卫。
- convert_request_repository：_end_of_day 统一闭区间语义；新增 reject()。
- 测试：新增 tests/test_convert_confirm.py（24 例）；全量 827 passed / 10 skipped。

2026-09-11 19:35:37 +08:00