init

docs/05-需求池/R-003.md

@@ -0,0 +1,111 @@
+# R-003 分仓管理工具完善与优化 · 已归档（讨论记录）
+
+> 需求状态：**已完成（已归档）** ｜ 登记日期：2026-08-28 ｜ 更新日期：2026-08-28 ｜ 定稿日期：2026-08-28 ｜ 归档日期：2026-08-28
+> 归档摘要见：已完成/R-003.md（本文件保留完整讨论记录）
+> 来源：迭代 01 复盘（2026-08-28）+ R-002 实现现状审视
+> 关联：R-002（已实现，docs/05-需求池/已完成/R-002.md）、迭代 01 复盘（docs/04-迭代记录/01-分仓管理工具/迭代复盘.md）
+
+## 需求概述
+
+对 R-002（分仓管理工具）的**完善与优化**：修复已知缺陷、补齐产品约束未覆盖的部分、优化使用体验。本期**不新增全新功能域**（如网格参数管理、做T 记录、行情监控等另行评估），聚焦「把 R-002 做扎实」。
+
+## 候选优化方向（讨论中，未收敛）
+
+> 以下候选方向来自迭代 01 复盘与代码现状审视，待与老师逐项讨论确定本期范围。
+
+| 方向 | 现状问题 | 优化内容 | 优先级候选 |
+|---|---|---|---|
+| O1 持仓信息完整性 | 全部持仓 tab 只显示份额相关字段，QMT 返回的现价/市值/盈亏/可用等**未展示**（与产品约束-001「完整展示持仓信息」不符） | 全部持仓 tab 补充现价/市值/盈亏/可用等字段展示 | 高 |
+| O2 策略 tab 动态化 | 客户端 tab 写死 3 个（全部持仓+2策略），设置中增删/隐藏策略后 tab **不同步** | tab 由服务端策略配置驱动，增删改/显示开关实时反映到 tab 栏 | 高 |
+| O3 设置界面完善 | 设置 section 只有显示/隐藏开关，**无增/删/改策略 UI**（API 已支持 strategies/update） | 补全策略 CRUD UI（新增/重命名/删除/排序） | 高 |
+| O4 数据刷新机制 | tab 数据只在进入/操作后加载一次，交易时段价格/市值**不会自动更新** | 定时轮询 or WebSocket 实时推送（后者关联草稿 T-005，需评估是否纳入本期） | 中 |
+| O5 数据加载失败兜底 | 页面数据加载失败时仅显示「加载失败」文字，无重试入口 | 加载失败的常规提示信息（失败原因）+ 重试按钮；不是数据源状态监控，而是页面加载的兜底体验 | 中 |
+| O6 份额编辑体验 | 添加/移出需逐票输入股数，无快捷操作 | 快捷操作（全部移入/全部移出/一键清零）、步进优化、操作反馈 | 低 |
+| O7 其他 | 老师补充 | 待讨论 | - |
+
+## 讨论进程
+
+### 2026-08-28 · 第 2 轮：范围圈定（老师确认）
+
+**老师拍板**：本期范围 = **O2 + O3 + O5 + O6**。
+
+- ✅ **O2 策略 tab 动态化**：tab 由服务端策略配置驱动，增删改/显示开关实时同步
+- ✅ **O3 设置界面完善**：补全策略 CRUD UI（新增/重命名/删除/排序）
+- ✅ **O5 数据加载失败兜底**：加载失败提示 + 重试（非数据源状态监控）
+- ✅ **O6 份额编辑体验**：快捷操作优化
+- ❌ **O1 持仓信息补全**：本期不做（后续评估）
+- ❌ **O4 数据实时刷新**：本期不做；WebSocket 实时推送（草稿 T-005）**不转正**，继续留草稿区待后续评估
+
+### 2026-08-28 · 第 3 轮：核心逻辑收敛（进行中）
+
+针对 O2/O3/O5/O6 的关键决策点逐项讨论，收敛后进入定稿。
+
+**已确认决策（老师拍板，2026-08-28）**：
+
+| 决策点 | 结论 |
+|---|---|
+| O2-1 tab 数据来源 | 每次进入/设置变更后重新拉取策略配置，tab 栏同步刷新 |
+| O2-2 隐藏策略的 tab | 隐藏即不显示（与 R-002 定稿一致） |
+| O2-3 tab 栏刷新触发 | 设置保存后客户端全局刷新 |
+| O3-1 新增策略 | 自动生成英文 id（slug），如「长线持有」→ long-term-hold |
+| O3-2 删除策略的份额处理 | **份额回到未分配**（老师确认，数据不丢） |
+| O3-3 重命名 | 分配数据挂 id 不挂名称，改名不影响 |
+| O3-4 排序 | 支持上移/下移按钮（不做拖拽） |
+| O3-5 预置策略 | **可删除，彻底自由**（老师确认，与其他策略一视同仁） |
+| O5-1 失败提示位置 | 数据加载区域显示失败提示信息（原因）+ 重试按钮 |
+| O5-2 失败重试 | 加载失败显示提示 + 手动重试按钮；自动重试 2 次（间隔 2s） |
+| O5-3 超时 | 保持 15s 可配置，超时显示「数据源超时」 |
+| O6-1 快捷操作 | 全部移入（未分配→当前策略）、一键清零（策略内全部移出） |
+| O6-2 份额步进 | 保留 step=100，手动输入任意值仍可用 |
+| O6-3 操作反馈 | 顶部轻提示：成功绿、失败红，3s 自动消失 |
+
+### 2026-08-28 · 第 4 轮：剩余不确定点收敛（老师确认）
+
+针对定稿前剩余不确定点，老师逐项拍板：
+
+| # | 不确定点 | 结论 |
+|---|---|---|
+| 1 | O2/O3 联动机制 | **提示用户手动刷新**（策略变更后，设置页/主界面提示「策略已变更，请手动刷新」；不做自动广播/轮询，简单可靠） |
+| 2 | O3 删除策略确认 | **删除弹窗提示确认**（破坏性操作需二次确认） |
+| 3 | O5 数据源状态条 | **当前无任何数据源状态显示**——O5 需要从零新增「数据源状态」能力（确认当前缺失，需新增而非增强） |
+| 4 | O6 全部移入边界 | **单票级**（表格行内操作，把该票未分配份额全部移入当前策略） |
+| 5 | O6 一键清零确认 | **清零前弹窗提示**，用户确认后执行 |
+
+### 2026-08-28 · 第 5 轮：O5 本质澄清（老师明确）
+
+**老师澄清**：我们要的不是「数据源状态监控」，而是**页面加载数据失败时，无法正常显示的常规提示信息 + 让用户重试**。
+
+- ❌ 不做：全局数据源状态监控（可用/不可用状态栏、状态点等）
+- ✅ 要做：页面/表格数据加载失败 → 显示**常规失败提示（含原因）** + **重试按钮**；超时等异常同样给出提示
+- 修正：O5 从「数据源健壮性（状态展示）」修正为「**数据加载失败兜底提示 + 重试**」
+
+### 2026-08-28 · O8 拆分独立
+
+老师提出：将「数据池（数据集）中间层 + 策略表格动态字段配置」从 R003 拆分，独立成新需求草稿（T-006，草稿/数据池中间层与策略表格动态字段配置.md），另行讨论定稿。R003 本期范围保持 O2/O3/O5/O6。
+
+---
+
+### 2026-08-28 · 设置 tab 化扩展（老师新增，迭代 02 实现中追加）
+
+老师新增需求（迭代 02 实现期间追加）：
+- **设置页 tab 化**：「神之一手」设置改为两个子 tab：**通用设置** / **策略分组**；
+- **通用设置**：三个 switch 配置项 —— 全部持仓 / 交易记录 / 关注列表（对应会话窗的 tab）；
+  - 本期实现三个 tab（交易记录/关注列表为空占位），开关默认全开；
+  - 开关控制对应 tab 的显示/隐藏，切换后提示「刷新生效」；
+- **策略分组**：现有策略 CRUD（移到该子 tab 下）。
+
+此扩展纳入迭代 02 实现范围（R003 的补充优化）。
+
+---
+
+## 定稿结论（2026-08-28 老师确认）
+
+**R-003 已定稿**，本期范围 = **O2 + O3 + O5 + O6**，共 20 项决策收敛（详见上文讨论进程）。
+
+### 定稿摘要（三要素核对）
+
+1. **边界清楚**：✅ 本期做 O2（tab 动态化）/ O3（策略 CRUD）/ O5（加载失败兜底提示+重试）/ O6（份额快捷操作）；不做 O1（持仓信息补全）/ O4（实时刷新）/ T-005（WS）；O8 数据池已拆分至 T-006 草稿
+2. **核心逻辑明确**：✅ 20 项决策全部收敛（O2×3 / O3×5 / O5×3 / O6×4 / 范围排除×5）
+3. **老师确认**：✅ 2026-08-28 老师明确「确定」
+
+**范围排除明确**：O1 持仓信息补全、O4 数据实时刷新、T-005 WebSocket 均不纳入本期；O8 数据池（T-006）独立草稿另行讨论。表格列保持代码写死（T-006 落地前不改）。

docs/05-需求池/已完成/R-002.md

@@ -0,0 +1,246 @@
+# R-002 分仓管理工具（持仓策略标签管理）· 已完成
+
+> 归档日期：2026-08-28 ｜ 需求状态：**已完成**
+> 原索引：docs/05-需求池/需求池索引.md（主索引保留 R-002 条目，指向本归档）
+> 讨论记录：docs/05-需求池/已完成/R-002-讨论记录.md（随需求一并归档）
+
+## 需求摘要
+
+在 DSH 中实现「分仓管理」：插件设置中管理持仓策略（策略=标签，增删改 + 显示/隐藏开关）；主窗口上方 tab 栏（对话/轨迹/上下文后）显示策略标签，每个标签下加载对应持仓数据；QMT 读全量真实持仓（插件直连 QMT Bridge RESTful 接口，非 MCP），策略分仓数据本地保存管理。
+
+## 核心逻辑（定稿版）
+
+1. **插件设置管理**：DSH 设置中添加「神之一手」菜单，管理持仓策略（策略=标签，可增删改 + 显示/隐藏开关）；
+2. **tab 栏展示**：主窗口上方「对话 | 轨迹 | 上下文」后显示策略标签（全部持仓/网格策略持仓/做T持仓），每个标签下加载对应持仓数据；
+3. **数据与存储**：QMT 读全量真实持仓（插件直连 REST http://192.168.3.43:8610），策略分仓数据本地保存（~/.dsh/one-divine-lot/allocations.json）。
+
+## 实现记录
+
+| 项 | 内容 |
+|---|---|
+| 实现迭代 | 01-分仓管理工具 |
+| 实现方式 | 独立插件（one-divine-lot），外部挂载到 DSH web profile |
+| 服务端 | S1-S6：数据源适配（REST）、设置管理、本地存储、分仓逻辑、HTTP API（/odl/api/* 8 端点） |
+| 客户端 | S7：三个 conversation.view tab + settings.section 设置菜单 |
+| 宿主挂载 | S8：dsh plugin add + bundle patch |
+
+## 验收结果（2026-08-28 老师确认完成）
+
+- ✅ 全部持仓显示（12 只真实持仓）
+- ✅ 三个策略 tab
+- ✅ 设置菜单「神之一手」
+- ✅ 份额编辑（添加/移出/步进100/手动输入）
+- ✅ 响应式布局
+- ✅ 本地存储持久化
+- ✅ 服务端 API 全部工作
+
+## 经验沉淀
+
+- 迭代复盘：docs/04-迭代记录/01-分仓管理工具/迭代复盘.md
+- 设计约束：技术约束-003~007（DSH 插件开发规范，2026-08-28 补充）
+
+---
+
+## 需求讨论记录（2026-08-27 整合）
+
+> 本需求从提出到定稿的完整讨论过程（原独立文件 R-002-讨论记录.md 整合于此）。
+> 整合日期：2026-08-28（老师要求：归档后讨论记录并入需求文件）
+
+# R-002 分仓管理工具 · 需求讨论记录
+
+> 需求状态：**讨论中** ｜ 本文件记录需求明确过程的讨论结论，供定稿时汇总。
+> 关联：docs/05-需求池/需求池索引.md（R-002）
+
+## 讨论进程
+
+### 2026-08-27 · 第 1 轮：分仓对应策略，账户核心策略为「网格超市 + 手动做T」
+
+**老师给出的需求信息**：
+1. **分仓对应不同的策略** —— 分仓的维度是策略，不是持仓周期/风险等级等；
+2. **当前账户核心策略：网格超市** —— 十几个标的都在做网格交易；
+3. **配合手动做T** —— 在网格基础上，手动做 T（高抛低吸/日内差价）。
+
+**讨论推论（待确认）**：
+- 分仓标签 ≈ 策略标签：每个策略对应一个分仓；
+- 「网格超市」可能是一个策略族（多个网格标的同属此策略），或每个网格标的独立成策略 —— 需明确粒度；
+- 「手动做T」是独立策略仓，还是叠加在网格仓上的操作动作 —— 需明确与网格仓的关系。
+
+**待确认问题**：
+1. 网格超市的粒度：所有网格标的是否同属一个「网格超市」策略仓？还是每个标的一个策略？
+2. 手动做T：是独立的策略仓，还是对网格标的的增强操作（同一标的同时在网格+做T）？
+3. 同一标的是否可能同时归属多个策略仓（如 网格 + 做T）？
+4. 除了网格超市 + 做T，是否还有其他策略仓（如长线持有）？
+
+### 2026-08-27 · 第 2 轮：分仓标签初步定为两个策略标签
+
+**老师确认**：
+1. 分仓标签初步就是两个策略标签：**「网格超市」** 和 **「手动做T」**；
+2. 账户核心策略 = 网格超市（十几个标的做网格）+ 手动做T；
+3. 分仓 = 按这两个策略标签划分。
+
+**推论（待确认）**：
+- 「网格超市」标签下：所有做网格的标的（十几个）归入此仓；
+- 「手动做T」标签下：做T 的标的归入此仓；
+- 一个标的可能同时属于两个标签（既是网格标的，又手动做T）？—— 需确认是否允许多标签。
+
+**待确认问题（第 3 轮）**：
+1. 同一标的是否允许同时打「网格超市」+「手动做T」两个标签？
+2. 每个策略仓下要看什么？只有汇总（市值/盈亏），还是包含网格参数（区间/格距/档位）？
+3. 未来是否可能增加第三个策略标签（预留扩展）？
+
+### 2026-08-27 · 第 3 轮：本期范围收敛 —— 标签可维护，其他功能先不管
+
+**老师确认**：
+1. **标签可以维护** —— 本期核心能力是标签的维护（创建/删除/重命名/查看）；
+2. **其他功能先不管** —— 网格参数管理、做T 记录、策略仓汇总等复杂功能本期不做。
+
+**本期范围（初步收敛）**：
+- ✅ 全量持仓展示（数据基础）
+- ✅ 标签维护（增/删/改/查）
+- ✅ 持仓打标签 / 移除标签（标签与持仓关联）
+- ❌ 网格参数管理（后续）
+- ❌ 做T 交易记录（后续）
+- ❌ 策略仓的复杂汇总/风控（后续）
+
+**待确认（第 4 轮，定稿前）**：
+1. 上述范围是否准确反映了老师意图？
+2. 若确认，R-002 状态可推进为「已定稿」，正式进入计划/迭代。
+
+### 2026-08-27 · 第 4 轮：允许「持仓份额拆分」—— 同一标的可分配到多个策略仓
+
+**老师确认（关键设计决策）**：
+1. **允许多标签**：一个票可以同时属于多个策略仓；
+2. **但持仓数据会分开**：不是整个持仓打标签，而是**按数量拆分份额分配到不同策略仓**；
+3. **示例**：一个票持仓 1000 股，可能网格有 600 股，余下 400 股是准备做 T 的前期买入仓。
+
+**模型含义（持仓份额分配模型）**：
+- 数据基础：全量真实持仓（每只票的总数量）；
+- 分仓 = 将每只票的持仓**数量份额**分配到各策略仓（如 600719.SH 1800 股 → 网格仓 1000 股 + 做T仓 800 股）；
+- **约束：各策略仓份额之和 = 该票总持仓量**；
+- 不再是「持仓↔标签」的整票多对多，而是「持仓份额 → 策略仓」的精确分配。
+
+**待确认（第 5 轮）**：
+1. 份额由谁维护？人工指定（老师输入每仓数量）？还是本期不做份额分配、只预留模型？
+2. 各仓份额的展示：是否要展示「每仓数量/市值/占比」？
+3. 未被分配的数量（份额之和 < 总持仓）怎么处理？归入「未分配」？
+
+### 2026-08-27 · 第 5 轮：完整产品形态明确（三条核心逻辑）
+
+**老师给出的完整需求（分仓/持仓管理逻辑）**：
+
+1. **插件设置管理能力**：在设置里，添加「神之一手插件设置管理能力」——
+   - 可以添加不同的持仓策略；
+   - 一个策略对应一个标签；
+   - 配置该策略/标签**是否显示 / 隐藏**。
+
+2. **会话标签展示**：在当前 DSH 的会话标签旁边，根据上面的设置，显示对应的标签；
+   - 每个标签下，加载对应的持仓数据。
+
+3. **数据处理与存储**：插件需要能够处理数据、存储——
+   - 通过 QMT 能读取到**全部持仓数据**（真实持仓）；
+   - 但**策略的分仓数据只能本地保存并更新管理**（QMT 没有分仓概念，分仓是本地维护的元数据）。
+
+**产品形态转变**：从「纯命令行工具」→「带 UI 设置的完整插件」：
+- 设置管理（策略 CRUD + 显示开关）→ DSH 设置/配置扩展点
+- 会话标签旁展示 → DSH 客户端 UI 扩展点
+- 本地存储 → 插件持久化存储
+
+**技术探索需求**：
+1. DSH 插件设置管理能力如何提供（settings 扩展点）？
+2. DSH 会话标签旁的 UI 扩展机制（client modules / client UI）？
+3. 本地存储机制（文件/数据库）？
+
+**待确认（第 6 轮）**：
+- 策略 = 标签 = 分仓，三者现在等同（一个策略对应一个标签，标签即分仓）；
+- 「显示/隐藏」开关：隐藏的策略标签不显示在会话标签旁；
+- 分仓数据本地存储：格式与位置待定（JSON 文件？DSH 数据目录？）。
+
+### 2026-08-27 · 技术探索结论（DSH 扩展点验证）
+
+对 DSH 宿主环境的技术探索确认以下扩展点可用：
+
+1. **设置管理**：DSH 提供 `ctx.settings` 服务（@deepseek-ai/dsh-settings）—— 插件可 `settings.register(ns, schema)` 注册自己的设置 namespace，用户文档持久化，天然适配「策略/标签配置 + 显示开关」；
+2. **会话标签旁 UI**：DSH 客户端 UI 通过 `dsh.client` 平台扩展（React 组件，参考 dsh-client-ui-conversation 等），插件可作为 client plugin 注入；「会话标签旁显示策略标签」属于客户端 UI 扩展点，需修改宿主 composition 加载 client 插件；
+3. **本地存储**：策略分仓数据（本地维护的元数据）可存为 JSON 文件（DSH 数据目录）或复用 settings 持久化；QMT 只提供全量真实持仓，分仓分配为本地状态。
+
+**技术可行性结论**：老师描述的三条逻辑（设置管理 / 会话标签旁展示 / 本地存储）在 DSH 均有对应扩展机制，可实现。实现涉及修改宿主 composition（加载 client 插件），需加载 editing-cordis-compositions 技能按规范操作。
+
+### 2026-08-27 · 第 6 轮：需求定稿（老师确认）
+
+**老师确认**：
+1. **需求基本确定** —— R-002 可定稿；
+2. **标签展示位置**：展示在 DSH 主窗口上方，放在「对话 ｜ 轨迹 ｜ 上下文 ｜」**后面添加**（即顶部 tab 导航栏扩展，策略标签作为新增 tab）；
+3. **独立插件，作为外部插件挂载** —— one_divine_lot 保持独立插件仓库，通过外部插件机制挂载到 DSH 宿主。
+
+**定稿结论**：R-002 状态 → 已定稿，可进入计划与迭代。
+
+### 2026-08-27 · 第 7 轮：数据源架构修正 —— 插件直连 QMT Bridge RESTful 接口
+
+**老师指出的架构问题**：
+- QMT Bridge MCP 是**给智能体（Agent）用**的桥接层（封装成 MCP 工具，供 AI 调用）；
+- 我们的插件**不应通过 MCP**，而应**直接调用 QMT Bridge 同一服务端口下的 RESTful 接口**；
+- REST 接口相关信息可通过 MCP 的 OpenAPI 规范获取（qmt_list_apis detail）。
+
+**技术探索确认（2026-08-27）**：
+- QMT Bridge 服务：**http://192.168.3.43:8610**（局域网 IP，配置于 ~/.dsh/profiles/web/cordis.patch.yml）
+- REST 端点（OpenAPI v3）：/health、/trade/asset、/trade/positions、/trade/orders、/trade/trades、/data/kline、/data/quote、/data/instrument、/data/calendar/trading_dates、/data/subscribe、/data/tick、/data/unsubscribe
+- MCP 端点：http://192.168.3.43:8610/mcp（同端口，MCP 封装给 Agent）
+- **REST 直连验证通过**：/health、/trade/asset、/trade/positions 均正常返回，数据与 MCP 一致
+
+**架构结论**：
+- 插件数据源适配器：直接 HTTP 调用 QMT Bridge RESTful 接口（不经过 MCP）；
+- MCP 仅作为 Agent 侧访问同一服务的封装层；
+- 设计约束技术约束-001 仍成立（统一数据源抽象），但实现层从「MCP 调用」改为「REST 调用」。
+
+### 2026-08-27 · S5 分仓逻辑设计讨论（Q1-Q4 结论）
+
+**老师确认**：
+1. **Q1 按股数分配**：份额分配以股数为单位（不按比例）；
+2. **Q2 允许未分配余额**：可能有未对应策略的持股余额（临时手动操作，无对应策略）—— 即份额之和 ≤ 总持仓，允许「未分配」余量存在；
+3. **Q3 策略仅为人为分组**：当前阶段策略只是人为的分组管理，**不实现策略的管理逻辑**（份额不随策略自动调整）；
+4. **Q4 不做统计信息**：分仓聚合**不加市值/盈亏/占比等统计**，只展示份额分配本身。
+
+**对 S5 设计的影响**：
+- getSummary() 去掉市值/盈亏/占比聚合，只返回「各策略的持仓份额 + 未分配份额」；
+- 份额分配：按股数，允许 sum ≤ 总持仓，剩余为「未分配」；
+- 份额是人为静态指定，不涉及策略逻辑。
+
+**待讨论（Q5）**：UI 上如何实现份额编辑操作。
+
+### 2026-08-27 · Q5 UI 编辑交互设计讨论（老师明确）
+
+**老师确认的 UI 形态**：
+
+1. **在策略 tab 内编辑**（不是单独的编辑界面）；
+2. **tab 结构**：理论上会有三类 tab：
+   - **全部持仓**：初始有数据（全量真实持仓，来自 QMT）；
+   - **网格策略持仓**：初始为空；
+   - **做T持仓**：初始为空；
+3. **添加**：在策略持仓页（网格/做T）提供「添加持仓」操作 —— 从全部持仓中找到标的，指定份额，添加到该策略分组；
+4. **移出**：提供「移出」操作 —— 该部分持仓不再按策略管理（回到全部持仓/未分配）。
+
+**设计要点**：
+- 全部持仓是**数据源**（从 QMT 读的真实持仓），也是「未分配」的展示处；
+- 策略持仓（网格/做T）是**从全部持仓挑份额**组成的分组；
+- 份额编辑 = 添加（全量→策略，指定股数）+ 移出（策略→全量）。
+
+**待确认细节**：
+1. 全部持仓 tab 是否也显示已分配到策略的份额（灰色/标注）？
+2. 添加时份额输入：一次添加一股数？还是可拆多策略？
+3. 「移出」是移出全部份额还是可指定数量？
+4. 全部持仓 tab 与「未分配」概念的关系：全部持仓 = 未分配 + 已分配？
+
+### 2026-08-27 · Q5 细节确认（老师确认）
+
+**细节确认结论**：
+
+1. **细节1（全部持仓 tab）**：A —— 显示完整持仓（1800 股），已分配部分标注（网格 1000 / 做T 800 / 未分配 400）；
+2. **细节2（添加粒度）+ 细节4（多策略）**：
+   - 每个策略 tab 是独立编辑上下文；
+   - 添加时份额**默认 0**，用户编辑填入要分配到**当前策略**的份额；
+   - 每次操作只确定「分配到当前策略」的份额，并更新总持仓的已分配数量；
+   - **同一标的可在多个策略**（分别在各自策略 tab 下添加，如网格 600 + 做T 800）；
+   - 例：网格 tab 添加 600719.SH 输入 600 → 网格 600；做T tab 再添加输入 800 → 做T 800；已分配 = 1400，未分配 = 400；
+3. **细节3（移出）**：B —— 指定数量移出（如做T 800 移出 200 → 做T 600，未分配 +200）。
+
+**核心模型**：份额按策略独立维护；添加默认 0 起填；已分配 = 各策略份额之和；未分配 = 总持仓 - 已分配。

docs/05-需求池/已完成/R-003.md

@@ -0,0 +1,58 @@
+# R-003 分仓管理工具完善与优化 · 已完成
+
+> 归档日期：2026-08-28 ｜ 需求状态：**已完成**
+> 原索引：docs/05-需求池/需求池索引.md（主索引保留 R-003 条目，指向本归档）
+> 讨论记录：docs/05-需求池/R-003.md（完整讨论过程保留于此）
+
+## 需求摘要
+
+对 R-002（分仓管理工具）进行完善与优化，本期范围 = **O2 + O3 + O5 + O6**：
+
+- **O2 策略 tab 动态化**：tab 由服务端策略配置驱动，增删改/显示开关实时同步（隐藏策略的 tab 不显示；策略变更提示手动刷新）
+- **O3 设置界面完善（策略 CRUD）**：新增（自动英文 id）/ 重命名（不影响分配）/ 删除（弹窗确认 + 份额回未分配）/ 排序（上移下移）/ 显隐；预置策略可删（彻底自由）
+- **O5 数据加载失败兜底**：加载失败提示（含原因）+ 重试按钮；自动重试 2 次；超时提示（**非数据源状态监控**）
+- **O6 份额编辑体验**：单票「全部移入」（未分配全部进当前策略）+ 策略「一键清零」（弹窗确认）+ 操作 Toast 反馈
+
+**实现期间追加（2026-08-28）**：设置页 tab 化（通用设置 / 策略分组两个子 tab）；通用设置三个 switch（全部持仓 / 交易记录 / 关注列表，控制会话 tab 显隐）；策略显示开关改用 switch 控件。
+
+## 核心逻辑（定稿版）
+
+1. **策略 tab 动态化**：客户端启动时拉取策略配置，按 visible 策略动态注册 conversation.view tabs（slots.register 返回 disposer，可注销重注册）；全部持仓固定保留；
+2. **策略 CRUD**：设置页「策略分组」子 tab 提供新增/重命名/删除/排序/显隐；删除弹窗确认 + 份额回未分配（产品约束-004）；预置策略可删；
+3. **加载失败兜底**：LoadState 三态组件（loading/error+重试/success），自动重试 2 次（间隔 2s），超时（15s 可配置）提示；
+4. **份额快捷操作**：单票全部移入（move-all-shares 端点）、策略一键清零（remove-all-shares 端点，弹窗确认）；
+5. **设置 tab 化**：通用设置（三个 switch 控制通用 tab 显隐）+ 策略分组；切换后提示「刷新页面后生效」。
+
+## 实现记录
+
+| 项 | 内容 |
+|---|---|
+| 实现迭代 | 02-分仓管理工具完善与优化 |
+| 实现方式 | 沿用独立插件 one-divine-lot（服务端 + 客户端改造） |
+| 服务端 | S1-S4：settings.js（策略 CRUD + tabs 配置）、storage.js（清份额）、manager.js（全部移入/清零）、api.js（strategies/add/remove/move + move-all-shares/remove-all-shares + tabs/tabs-update 端点） |
+| 客户端 | S5-S8：LoadState/Toast 基础组件、SettingsSection 设置 tab 化 + CRUD、client/index.js 动态 tab 注册、StrategyTab 快捷操作 |
+| 构建安装 | S9：pnpm build + 宿主动态加载（无需重启即更新客户端 bundle） |
+
+## 验收结果（2026-08-28 老师确认）
+
+- ✅ 策略隐藏/显示（switch 控件）验证 OK
+- ✅ 新增策略正常，tab 增加正常
+- ✅ 删除策略正常，tab 消失正常
+- ✅ 策略排序调整正常（getStrategies 按 order 排序修复后）
+- ✅ 全部持仓/策略 tab 表格正常显示（React 空值崩溃修复后）
+- ✅ 三个通用 tab（全部持仓/交易记录/关注列表）+ 策略 tabs 按配置注册
+- ✅ 设置页两个子 tab（通用设置/策略分组）
+- ✅ 服务端 API 全链路验证通过（tabs、strategies CRUD、快捷操作）
+
+## 经验沉淀
+
+- **React JSX 空值崩溃**：LoadState 的 children 立即求值，positions 为 null 时崩溃被 slot 边界静默吞掉 → 必须空值保护（(positions ?? []).map）
+- **useRpc 引用稳定性**：每次渲染返回新函数导致 effect 无限循环 → useCallback 稳定化
+- **getStrategies 排序一致性**：设置页/tab 栏/move 逻辑必须共用同一 order 排序，否则顺序不一致
+- **服务端 API 需重启生效**：客户端 bundle 宿主动态读取，但服务端模块（api.js 等）需重启 DSH 才加载新代码
+
+## 关联文档
+
+- 讨论记录（完整）：docs/05-需求池/R-003.md
+- 迭代记录：docs/04-迭代记录/02-分仓管理工具完善与优化/
+- 设计约束：产品约束-004（删除策略份额回未分配）

docs/05-需求池/草稿/数据池中间层与策略表格动态字段配置.md

@@ -0,0 +1,27 @@
+# 草稿：数据池（数据集）中间层 + 策略表格动态字段配置
+
+> 状态：起草（未成形，不进入计划/迭代范围）｜ 登记日期：2026-08-28
+> 来源：R003 讨论（2026-08-28，老师提出）—— 从 R003 中拆分独立
+> 关联：R-003（docs/05-需求池/R-003.md）、T-005 草稿（ws 实时数据）、R-002（已实现）
+
+## 想法概述
+
+在插件服务端构建一层**数据池（数据集）中间层**：
+
+1. **数据集定义**：按股票代码聚合的宽表（内存 Map），合并多数据源字段（持仓 / 合约信息 / 行情快照 / 本地份额元数据），字段带源前缀、可溯源；
+2. **数据源映射**：每个字段声明「来源 + 提取逻辑」；数据源适配器 → 填充器（filler）写入数据池；新增数据源（如未来 WS 5400 全量实盘订阅）只需新增填充器，池结构零改动；
+3. **策略持仓表格**：策略 tab 下表格的数据，从「列配置 × 数据池行」渲染，不再写死字段；
+4. **动态字段配置**：每个策略 tab 独立配置列（自定义列名 → 数据池字段名 → 顺序 → 显隐），存本地 JSON，设置页管理。
+
+## 待讨论点
+
+- [ ] 数据池字段命名规范（源前缀？直接名？）
+- [ ] 数据池范围（仅持仓+自选 vs 全市场 5400）
+- [ ] 刷新时机（启动构建/操作后刷新/手动刷新/定时）
+- [ ] 惰性 vs 全量拉取
+- [ ] 存储介质（服务端内存起步，SQLite 升级边界）
+- [ ] 列配置数据结构与存储位置
+- [ ] 与未来 WS 全量订阅（T-005）的衔接
+- [ ] 优先级与排期（定稿后确定）
+
+> 成熟后按「三要素」（边界清楚 / 核心逻辑明确 / 老师确认）讨论定稿，再转正到根目录形成正式需求。

docs/05-需求池/草稿/通过ws长连接做市场数据的实时反映.md

@@ -0,0 +1,19 @@
+# 草稿：通过 ws 长连接做市场数据的实时反映
+
+> 状态：起草（未成形想法，不进入计划/迭代范围）｜ 登记日期：2026-08-28
+> 来源：迭代 01 复盘（2026-08-28，老师提出「WebSocket 数据监控」）
+
+## 想法描述
+
+通过 **WebSocket 长连接** 实现市场数据的**实时反映**：插件开启 WebSocket（webServer.registerUpgrade + ws 库），实现持仓 / 行情等市场数据的实时推送与展示。
+
+## 待讨论点
+
+- [ ] 推送范围：持仓数据？行情数据？两者都要？
+- [ ] 订阅机制：客户端如何订阅感兴趣的标的 / 数据？
+- [ ] 实时反映的 UI 形态：数据更新如何反映到现有策略 tab？
+- [ ] 与现有 REST 拉取（QMT Bridge REST）的关系：实时推送与按需拉取如何分工？
+- [ ] 数据来源：QMT Bridge 是否提供行情订阅端点（/data/subscribe、/data/tick）？如何桥接？
+- [ ] 优先级与排期（机制定稿后确定）
+
+> 成熟后按「三要素」（边界清楚 / 核心逻辑明确 / 老师确认）讨论定稿，再转正到根目录形成正式需求。

docs/05-需求池/说明.md

@@ -0,0 +1,58 @@
+# 05-需求池（Backlog）
+
+> 所有待办需求的统一入口：想法先进池，讨论后排优先级，再进计划。
+
+## 角色
+
+项目的"收件箱"。任何新想法、新需求、待解决的问题，第一步都是登记入池，而不是直接动手。保证"想清楚再动"。
+
+## 强约束（初始定义）
+
+1. **统一格式登记**：每条需求按约定格式登记，信息完整方可入池。
+2. **有优先级**：需求必须标注优先级（或待讨论确定优先级）。
+3. **状态流转明确**：需求有清晰的状态流转：**起草 → 讨论中 → 已定稿**（单向推进，回退需讨论说明）；已定稿后可进入计划/迭代，实现后联动「实现迭代 / 实现状态」。
+4. **实现追溯联动**：需求被某次迭代实现时，需求索引记录需补充「实现该需求的迭代」（如 `01-建立神之一手框架`）与「需求实现状态」（实现中 / 已实现 / 部分实现），与迭代记录双向可追溯。
+5. **讨论中的想法先入池**：任何讨论中冒出的新想法，先记入池，不直接进代码或计划。
+6. **入范围门槛**：**只有确定的需求才可进入计划范围或迭代工作范围**；讨论中、未确定的需求停留在需求池，不得进入计划与迭代。
+7. **池子可清理**：定期复盘，拒绝/搁置的需求要明确标记，不让池子无限膨胀。
+
+## 待讨论细节
+
+- [x] 登记格式（字段：标题 / 描述 / 来源 / 优先级 / 状态（起草/讨论中/已定稿）/ 更新日期 / 实现迭代 / 实现状态）—— 2026-08-27 已按 skill v2 对齐
+- [ ] 优先级规则（P0-P2？MoSCoW？如何定）
+- [x] 状态流转的具体定义（AI 提议 + 老师确认，2026-08-28 定；详见下方「状态流转与定稿」）
+- [x] 需求定稿判定标准（三要素：边界清楚 / 核心逻辑明确 / 老师确认，2026-08-28 定）
+
+## 状态流转与定稿（2026-08-28 老师确认）
+
+### 状态流转责任
+
+- 状态流转由 **AI 提议 + 老师确认** 驱动：AI 负责整理需求、提出状态变更建议（起草 → 讨论中 → 已定稿），老师拍板确认后 AI 更新状态；
+- 回退（如 已定稿 → 讨论中）同样需老师确认，并记录回退理由。
+
+### 需求定稿标准（三要素）
+
+需求进入「已定稿」需同时满足以下三条，全部满足才可进入计划 / 迭代范围：
+
+1. **边界清楚**：做什么 / 不做什么（本期范围）明确收敛；
+2. **核心逻辑明确**：关键决策点（数据模型 / 交互 / 技术方案）都有讨论结论；
+3. **老师确认**：老师明确表示需求可定稿。
+
+> 实践样本：R-002 从提出到定稿经历 7+ 轮讨论，完整走完三要素后进入迭代 01。
+
+## 目录结构（2026-08-28 老师确认）
+
+```
+docs/05-需求池/
+├── 说明.md            # 本文件（目录说明与约定）
+├── 需求池索引.md       # 当前工作需求总览（状态流转记录）
+├── 草稿/              # 需求收集：临时的想法、未成形的需求（先进草稿，成熟后转正到根目录）
+├── 已完成/            # 已完成需求的归档（每个需求一个文件，含需求摘要+讨论记录）
+└── 丢弃/              # 被拒绝/搁置需求的归档（记录需求+丢弃原因）
+```
+
+> **约定（2026-08-28 老师明确）**：
+> - **根目录 = 当前需求工作目录**：正在讨论、已定稿、待实现的需求以文件形式放在根目录（如 R-002）；
+> - **草稿/ = 需求收集**：临时的想法、未成形的需求先放这里，成熟后转正到根目录形成正式需求；
+> - **已完成/ = 归档**：需求实现后移入（每个需求一个文件）；
+> - **丢弃/ = 归档**：拒绝/搁置的需求移入（记录原因）。

docs/05-需求池/需求池索引.md

@@ -0,0 +1,30 @@
+# 需求池索引（Backlog Index）
+
+> 所有待办需求的统一登记处。想法先进池，讨论后排优先级，再进计划。
+>
+> **登记格式**（按 divine-lot-dev skill v2 规范）：
+> 每条需求含：编号 / 标题 / 描述 / 来源 / 优先级 / **状态（起草 / 讨论中 / 已定稿）** / **更新日期** / 实现迭代 / 实现状态。
+>
+> **入范围门槛**：只有状态为「已定稿」的需求才可进入计划范围或迭代工作范围；起草 / 讨论中的需求停留在需求池。
+>
+> **需求池边界**（2026-08-27 老师确认）：需求池只登记「待办需求」；已演进为终极目标的内容（如原 R-001 智能交易辅助系统）不属于需求，不占需求池条目，以终极目标文档为准（见 01-终极目标）。
+
+## 需求列表
+
+| 编号 | 标题 | 描述 | 来源 | 优先级 | 状态 | 更新日期 | 实现迭代 | 实现状态 |
+|---|---|---|---|---|---|---|---|---|
+| R-002 | 分仓管理工具（持仓策略标签管理） | 验证 QMT Bridge MCP 连通（资金/持仓）。**核心逻辑（已定稿）**：① 插件设置中管理持仓策略（策略=标签，增删改 + 显示/隐藏开关）；② 按设置在主窗口上方 tab 栏（对话/轨迹/上下文后）显示策略标签，每个标签下加载对应持仓数据；③ 插件处理与存储：QMT 读全量真实持仓（**插件直连 QMT Bridge RESTful 接口**，非 MCP），策略分仓数据本地保存管理。**实现方式**：独立插件，作为外部插件挂载到 DSH。第一个落地工具，源自 T-001。**2026-08-27 定稿，2026-08-28 完成，已归档至 已完成/R-002.md** | 老师指令（2026-08-27） | P0 | 已定稿 | 2026-08-28 | 01-分仓管理工具 | **已实现（已归档）** |
+| R-003 | 分仓管理工具完善与优化 | 对 R-002 的完善与优化：O2 策略 tab 动态化、O3 策略 CRUD（删除弹窗确认）、O5 加载失败兜底、O6 份额快捷操作 + 设置页 tab 化（通用设置/策略分组）。**2026-08-28 定稿，2026-08-28 完成，已归档至 已完成/R-003.md** | 迭代 01 复盘 + 老师补充 | P0 | 已定稿 | 2026-08-28 | 02-分仓管理工具完善与优化 | **已实现（已归档）** |
+
+## 渐进明细规划素材
+
+> 2026-08-27 老师确立「渐进明细」：前期目标笼统，先实现周边工具，做中学逐步明确计划。以下周边工具候选为规划素材，**状态为「起草」级**（未定稿，不进入计划/迭代范围），待讨论与实践中逐步明确并转入正式需求。
+
+| 编号 | 周边工具候选 | 描述 | 状态 |
+|---|---|---|---|
+| T-001 | 分仓管理工具（数据连通验证 + 持仓/资金管理） | 验证 QMT Bridge MCP 可用性，封装持仓/资金查询；以「分仓」视角管理持仓。**已定稿为 R-002 并进入迭代 01** | 已转需求 R-002 |
+| T-002 | 交易与复盘记录工具 | 将交易、复盘沉淀为 DSH 可管理的结构化文档，支撑市场复盘/交易复盘目标 | 起草 |
+| T-003 | 策略配置文件骨架 | 定义策略的数据结构（YAML/JSON），支撑策略定义目标 | 起草 |
+| T-004 | 消息/通知工具 | DSH 内消息路由与通知能力，支撑按策略模式管理消息目标 | 起草 |
+| T-005 | 通过 ws 长连接做市场数据的实时反映 | WebSocket 长连接实现市场数据（持仓/行情）实时推送与展示；源自迭代 01 复盘。**2026-08-28 老师确认放草稿，不入正式需求池**，草稿文件：`草稿/通过ws长连接做市场数据的实时反映.md` | 起草 |
+| T-006 | 数据池中间层 + 策略表格动态字段配置 | 服务端数据池（数据集中间层：按 code 聚合宽表、多源字段映射、填充器架构）+ 策略持仓表格动态字段配置（列配置×池行渲染）。源自 R003 讨论（2026-08-28）拆分独立，草稿文件：`草稿/数据池中间层与策略表格动态字段配置.md` | 起草 |