迭代14: 策略tab历史持仓展示（R-016）+ 今日已清仓默认层

- R-016 Q1-Q7: 两个策略 tab title 旁「历史持仓」开关 + 清仓范围筛选（近一周默认/1月/3月/半年/1年）
  - SqliteStore.getHoldingsHistory（strategy_id + closed_at 非空 + sinceMs，closed_at DESC，只读）
  - DataStore 门面透传 + strategy-holdings/history 端点（name 兜底 + 参数校验）
  - 前端: 开关/范围下拉/历史行灰显+「已清仓」徽标/展开复用 R-010（rowKey 唯一化）
- R-016 二轮补充（Q8-Q9 老师拍板）: 今日已清仓默认层
  - range=today = 本地自然日 00:00 起（特判零点，不落回溯毫秒档）
  - 当天已清仓的持仓默认恒显示、不受「历史持仓」开关控制（开关只控今天之前）
  - rowsToRender 分层合成 + holdingId 去重；标题计数不含已清仓行；零写路径变更
- 回归: test-r016-history 24/24 + 存量回归全绿

docs/04-迭代记录/14-策略tab历史持仓展示/迭代复盘.md

@@ -0,0 +1,38 @@
+# 迭代复盘：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 拍板）零改动。
+
+## 过程事实
+
+1. **讨论驱动定稿**（2026-09-07，Q1-Q7 老师逐项拍板）：Q2 为本轮唯一改判——AI 建议改 closeHolding 保留清仓时份额，老师否决：「显示 0 就好了，即使显示了清仓时的 shares 也没多少意义，主要目标是追溯这次持仓相关的历史操作」——需求核心从「数据完整性」校正为「操作追溯锚点」，方案随之收敛为零写路径变更；其余六问均按 AI 建议定稿；
+2. **实现**（严格按 PLAN-015 步骤）：SqliteStore.getHoldingsHistory（strategy_id + closed_at IS NOT NULL + sinceMs 过滤 + DESC，只读新增）→ DataStore 门面透传 → strategy-holdings/history 端点（range 五档服务端换算自然日近似 + name 关联委托兜底 + 参数校验 bad-request）→ StrategyTab 开关/范围下拉/历史行渲染；
+3. **实现中发现并修复一个真实隐患**：R-010 展开状态与交易缓存原以 code 为键——同码「当前行 + 历史行」并存（清仓后重新买入）时两行会同时展开、缓存串行；本轮把展开状态/缓存/行键统一收敛为唯一 rowKey（当前行 = code，历史行 = 'h-' + holdingId），toggleExpand 签名同步变更（当前调用方仅 tbody 一处）；
+4. **验证**：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）；
+5. **文档链**：R-016 定稿 + PLAN-015 + 迭代三件套 + 技术约束-019 + 需求池索引（R-016 登记；顺带补登遗漏的 R-015 行）；
+6. **部署态排查（老师首验无数据，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 为空），比口头承诺可靠。
+
+## 遗留/后续
+
+1. **归属候选不纳入清仓持仓**（R-016 关联观察，2026-09-07 大连热电实际遇到）：清仓后当日委托无法再通过下拉关联到对应 holding——是否立独立需求（候选纳入近期清仓持仓）待老师定；
+2. **历史行成本价/收益推导**：本期不做（边界定稿）；若后续要做，数据源 = 关联委托成交记录，属展示层推导，不动存储；
+3. **清仓方式标记**（手动 vs 幽灵自动）：数据未区分，本期不做；若要做需 closeHolding 增加来源标记（涉及写路径，另立需求）；
+4. **R-015 / 迭代 13 人工验收**仍待老师确认（与本迭代无依赖）。