Files

T

kyugao ec02a791ee 迭代22+23: 策略tab静态化 + 计算字段（数字/判定型）+ 网格超市信号字段

- R-027 静态化：策略恒为内置两项（不可增删改名，保留显隐/排序）；设置页移除「策略分组」；
  字段配置入口迁到策略 tab 内「列设置」旁（FieldConfigDialog + schema-update 单策略写入）
- R-026 计算字段：自写公式引擎（中文变量、四则/括号/round·abs·min·max、缺值短路→—）+
  变量目录（行情/合约/持仓/自定义字段）+ strategy-positions 逐行现算（只读内存缓存，不落库、列只读）
- R-028 判定型：比较运算 + and/or + inferResultKind + 结果类型一致性校验 + 判定列 ✓/— 渲染；
  网格超市落地 可下空单=涨停价>基准值+网格大小、可下多单=跌停价<基准值-网格大小
- 变量选择改标签平铺（老师反馈）；公式手册 docs/99-其他材料/计算字段公式说明.md
- 约束同步：产品约束-002/003/004/009/013/014、技术约束-014/015/022/023/024、UI约束-002/003/005/008
- 回归：新增 test-r026/test-r027，更新 r011/r013/r017，17 个脚本全绿；typecheck/build 通过

2026-09-10 14:05:06 +08:00

5.3 KiB

Raw Permalink Blame History

迭代复盘：14-策略tab历史持仓展示

复盘日期：2026-09-07 ｜迭代状态：已实施，待老师人工验收 关联需求：R-016 ｜关联计划：PLAN-015

结果

迭代 14 达成：两个策略 tab（做T / 网格超市）title 旁新增「历史持仓」开关 + 清仓时间范围筛选（近一周默认 / 近 1 个月 / 近 3 个月 / 近半年 / 近 1 年）；已清仓持仓行灰显 + 「已清仓」徽标（含清仓日期）追加在当前持仓行后（closed_at DESC），展开复用 R-010 查看关联交易——补上「清仓即失联」的操作追溯缺口。当前持仓快照路径（R-014 语义）与所有写路径（closeHolding 置 shares=0，Q2 拍板）零改动。

过程事实

讨论驱动定稿（2026-09-07，Q1-Q7 老师逐项拍板）：Q2 为本轮唯一改判——AI 建议改 closeHolding 保留清仓时份额，老师否决：「显示 0 就好了，即使显示了清仓时的 shares 也没多少意义，主要目标是追溯这次持仓相关的历史操作」——需求核心从「数据完整性」校正为「操作追溯锚点」，方案随之收敛为零写路径变更；其余六问均按 AI 建议定稿；
实现（严格按 PLAN-015 步骤）：SqliteStore.getHoldingsHistory（strategy_id + closed_at IS NOT NULL + sinceMs 过滤 + DESC，只读新增）→ DataStore 门面透传 → strategy-holdings/history 端点（range 五档服务端换算自然日近似 + name 关联委托兜底 + 参数校验 bad-request）→ StrategyTab 开关/范围下拉/历史行渲染；
实现中发现并修复一个真实隐患：R-010 展开状态与交易缓存原以 code 为键——同码「当前行 + 历史行」并存（清仓后重新买入）时两行会同时展开、缓存串行；本轮把展开状态/缓存/行键统一收敛为唯一 rowKey（当前行 = code，历史行 = 'h-' + holdingId），toggleExpand 签名同步变更（当前调用方仅 tbody 一处）；
验证：test-r016-history.mjs 19/19（清仓转历史可查 / 5 档范围边界 / 排序 / 策略隔离 / 未清仓不出现 / 参数校验 / name 兜底 / 端点分发零破坏）；typecheck 通过；存量回归 test-position-sync 35/35、test-r013 21/21、test-quote-sync 27/27；build 通过（client bundle 164KB wrapped）；
文档链：R-016 定稿 + PLAN-015 + 迭代三件套 + 技术约束-019 + 需求池索引（R-016 登记；顺带补登遗漏的 R-015 行）；
部署态排查（老师首验无数据，2026-09-07）：实锤定位 = 运行中的 DSH 服务端进程仍是旧代码——同进程 /odl/api/summary 正常应答、新端点返回 unknown method（curl 实测）；客户端 bundle 因插件 symlink 直连源码 lib/ 而被刷新（按钮已出现），服务端模块注册表却停留在进程启动时；处置 = ① loadHistory 失败从静默吞空改为 Toast 可见化（静默兜底=排障盲区，本轮教训）并重新构建（test-r016 19/19 复跑通过）；② 服务端生效依赖 DSH web 进程重启（插件 symlink 方式安装，无需重装，重启即取新 lib）。

经验教训（复盘沉淀）

1. 需求的「核心目标」要听老师的定调，不要替老师拔高

AI 在 Q2 提议改 closeHolding 语义以「保留清仓时份额」，出发点是账本完整性；老师一句话把需求核心定调为「追溯历史操作」——份额数字本身没有追溯价值，holding_id 锚点 + 关联委托才有；
沉淀：讨论中 AI 的方案建议要标明「我认定的价值假设」，让老师有机会否定假设本身，而不只是选项。

2. 复用既有交互时，键的唯一性要先审后用

展开状态按 code 键控在「一码一行」时代是隐含正确的；历史行引入打破了「一码一行」不变量——同类隐含假设（缓存 Map、React key、loading 标记）都要在数据形态变化时重新过一遍；
沉淀：向既有列表引入第二类行时，先列出所有「按 X 键控」的状态，逐个判断是否需要升级为行唯一键。

3. 只读需求的实现应当「零写路径」可断言

本轮全程未触碰任何 INSERT/UPDATE 语句与语义（closeHolding 分毫未动），回归脚本专门加了「strategy-positions 分发不变」断言——历史查询与当前查询的隔离在端点层就已成立（独立 method），不需要靠约定；
沉淀：「只读功能」的范围声明落成验收断言（分发不变 + 写路径 diff 为空），比口头承诺可靠。

遗留/后续

归属候选不纳入清仓持仓（R-016 关联观察，2026-09-07 大连热电实际遇到）：清仓后当日委托无法再通过下拉关联到对应 holding——是否立独立需求（候选纳入近期清仓持仓）待老师定；
历史行成本价/收益推导：本期不做（边界定稿）；若后续要做，数据源 = 关联委托成交记录，属展示层推导，不动存储；
清仓方式标记（手动 vs 幽灵自动）：数据未区分，本期不做；若要做需 closeHolding 增加来源标记（涉及写路径，另立需求）；
R-015 / 迭代 13 人工验收仍待老师确认（与本迭代无依赖）。

验收状态更新（2026-09-08）

老师 2026-09-08 归档指令：确认验收并归档；R-016 已按归档清单移入 05-需求池/已完成/。

5.3 KiB Raw Permalink Blame History Unescape Escape