init

docs/03-设计约束/UI交互约束.md

@@ -0,0 +1,16 @@
+# UI交互约束（UI & Interaction Constraints）
+
+> UI 与交互层面的约束：视觉风格、组件、交互行为。后续迭代进行界面与交互实现时以此为依据。
+>
+> 记录格式：每条约束包含「编号 / 约束说明 / 添加日期 / 生效状态 / 失效日期 / 最后一次变更描述」。新增追加、变更更新、失效标记状态（不删除记录）。引用用编号，如 `UI约束-001`。
+> **最后一次变更描述**：概括该约束最近一次变更（新增 / 变更 / 失效）讨论的最后一层结论；新增时写新增结论，变更/失效时更新为当次结论。
+
+## 约束列表
+
+| 编号 | 约束说明 | 添加日期 | 生效状态 | 失效日期 | 最后一次变更描述 |
+|---|---|---|---|---|---|
+| （待添加） | | | | | |
+
+<!-- 示例条目（确认格式后删除）：
+| UI约束-001 | 示例：求签页面必须保持单屏完整，不出现滚动 | 2026-08-26 | 生效 | - | 讨论确认：移动端优先，避免滚动打断仪式感 |
+-->

docs/03-设计约束/产品功能约束.md

@@ -0,0 +1,19 @@
+# 产品功能约束（Product Constraints）
+
+> 产品功能层面的约束：功能边界、行为定义、不可违背的产品规则。后续迭代实现产品功能时以此为依据。
+>
+> 记录格式：每条约束包含「编号 / 约束说明 / 添加日期 / 生效状态 / 失效日期 / 最后一次变更描述」。新增追加、变更更新、失效标记状态（不删除记录）。引用用编号，如 `产品约束-001`。
+> **最后一次变更描述**：概括该约束最近一次变更（新增 / 变更 / 失效）讨论的最后一层结论；新增时写新增结论，变更/失效时更新为当次结论。
+
+## 约束列表
+
+| 编号 | 约束说明 | 添加日期 | 生效状态 | 失效日期 | 最后一次变更描述 |
+|---|---|---|---|---|---|
+| 产品约束-001 | 分仓管理以「全量持仓」为数据基础：系统必须完整展示账户全部持仓信息（代码/名称/数量/可用/均价/现价/市值/盈亏），不遗漏、不裁剪 | 2026-08-27 | 生效 | - | 讨论确认（R-002）：老师要求「首先肯定支持全部持仓信息」 |
+| 产品约束-002 | 分仓通过「持仓标签」体系实现：在全量持仓之上，用不同标签对持仓进行逻辑分组，每个标签展示其下的仓位汇总（数量/市值/盈亏/占比） | 2026-08-27 | 生效 | - | 讨论确认（R-002）：老师要求「分不同的持仓标签，各自有多少仓位」 |
+| 产品约束-004 | 删除持仓策略时，该策略下已分配的份额自动回到「未分配」，数据不丢失（删除前需弹窗确认） | 2026-08-28 | 生效 | - | R-003 O3 定稿（2026-08-28）：删除策略 = 份额回未分配 + 弹窗确认 |
+| 产品约束-003 | 持仓标签可自定义、可增删改；标签维度候选包括策略/用途/风险等级等（具体维度待讨论确认） | 2026-08-27 | 生效 | - | 讨论确认（R-002）：标签体系需支持自定义，维度待细化 |
+
+<!-- 示例条目（确认格式后删除）：
+| 产品约束-001 | 示例：求签功能必须保证抽取结果的不可预测性 | 2026-08-26 | 生效 | - | 讨论确认：为保证公平性，抽取必须不可预测 |
+-->

docs/03-设计约束/技术方案约束.md

@@ -0,0 +1,22 @@
+# 技术方案约束（Technical Constraints）
+
+> 技术方案层面的约束：技术栈、架构、实现规范、依赖原则。后续迭代进行技术实现时以此为依据。
+>
+> 记录格式：每条约束包含「编号 / 约束说明 / 添加日期 / 生效状态 / 失效日期 / 最后一次变更描述」。新增追加、变更更新、失效标记状态（不删除记录）。引用用编号，如 `技术约束-001`。
+> **最后一次变更描述**：概括该约束最近一次变更（新增 / 变更 / 失效）讨论的最后一层结论；新增时写新增结论，变更/失效时更新为当次结论。
+
+## 约束列表
+
+| 编号 | 约束说明 | 添加日期 | 生效状态 | 失效日期 | 最后一次变更描述 |
+|---|---|---|---|---|---|
+| 技术约束-002 | 分仓管理采用「全量持仓 + 标签」模型：持仓数据为账户真实持仓（来自数据源适配器），标签为逻辑分组元数据（独立于持仓存储，可增删改），聚合视图按标签汇总仓位 | 2026-08-27 | 生效 | - | 讨论确认（R-002）：全量持仓为基础，标签体系做逻辑分仓 |
+| 技术约束-001 | 行情/交易数据源必须通过统一接口抽象（定义统一的数据模型与操作接口），实现层为具体数据源适配器；当前限定实现 QMT Bridge 适配器，未来可新增其他行情/交易接口适配器，业务层不感知具体数据源 | 2026-08-27 | 生效 | 2026-08-27 | 变更（2026-08-27 R-002 讨论）：原为「QMT Bridge MCP 适配器」，修正为**直接调用 QMT Bridge RESTful 接口**（http://192.168.3.43:8610），MCP 仅作为 Agent 侧封装层，插件侧直连 REST |
+| 技术约束-003 | QMT Bridge 数据源通过其 RESTful HTTP 接口接入（基础地址 http://192.168.3.43:8610，OpenAPI v3 规范），不经过 MCP 层；MCP 是给 Agent 用的封装，插件内部直连 REST | 2026-08-27 | 生效 | - | 讨论确认（R-002 第 7 轮）：老师指出 MCP 是给智能体用的，插件应直连同一服务端口的 RESTful 接口 |
+| 技术约束-004 | 插件服务端 API 用 webServer 自开路由（如 /odl/api/*），**不直接使用 connection.rpc.intercept('/api')** —— DSH 的 /api 通道只能一个 interceptor（api-gateway 已占用），重复 intercept 会抛错导致插件 apply 失败 | 2026-08-28 | 生效 | - | 迭代 01 复盘沉淀：RPC 冲突导致服务端插件 apply 失败、RPC 404 |
+| 技术约束-005 | 客户端插件 bundle 必须是 CJS + window.__ModuleLoader__.load({id, factory}) 包装（tsdown 构建 + wrap 脚本），裸 ESM 无法被 DSH 客户端模块系统加载 | 2026-08-28 | 生效 | - | 迭代 01 复盘沉淀：客户端 bundle 未包装导致 loaded without registering via __ModuleLoader__.load |
+| 技术约束-006 | 客户端 slots.register 的 component 必须是第二参数（register({...}, Component)）；settings schema 必须用 schemastery z.object() 函数式定义 | 2026-08-28 | 生效 | - | 迭代 01 复盘沉淀：component 位置错误致 React #130；普通对象 schema 报 schema is not a function |
+| 技术约束-007 | 插件安装用 dsh plugin add（自动 reconcile bundles），不直接用 pnpm add；bundle patch 顶层必须是 insert 操作 | 2026-08-28 | 生效 | - | 迭代 01 复盘沉淀：pnpm add 不会更新 dsh.profile.bundles |
+
+<!-- 示例条目（确认格式后删除）：
+| 技术约束-001 | 示例：技术栈以 Node.js / TypeScript 为准，不引入未讨论的新框架 | 2026-08-26 | 生效 | - | 讨论确认：优先复用 DSH 既有能力，新框架需论证 |
+-->

docs/03-设计约束/说明.md

@@ -0,0 +1,40 @@
+# 03-设计约束（Design Constraints）
+
+> 项目设计与技术的强制规范：下分产品功能、技术方案、UI交互三个文档模块。后续一切迭代以此为依据。
+
+## 角色
+
+项目的"宪法性规范"层。定义本项目必须遵守的设计约束，后续的每一次迭代（计划、执行、实现）都必须以此为依据，不得违背。
+
+## 文档模块（三个）
+
+`03-设计约束/` 下三个文档模块，各自以**列表**形式记录约束条目，每条包含：**编号 / 约束说明 / 添加日期 / 生效状态 / 失效日期 / 最后一次变更描述**。
+
+| 文档模块 | 内容范围 |
+|---|---|
+| `产品功能约束.md` | 产品功能层面的约束：功能边界、行为定义、不可违背的产品规则 |
+| `技术方案约束.md` | 技术方案层面的约束：技术栈、架构、实现规范、依赖原则 |
+| `UI交互约束.md` | UI 与交互层面的约束：视觉风格、组件、交互行为 |
+
+后续讨论确定的设计/技术/产品约束与变更，直接更新对应模块列表：
+
+- **新增约束** → 追加一条新记录（分配新编号，填约束说明、添加日期，生效状态=生效，最后一次变更描述=新增讨论结论）
+- **变更约束** → 更新该条目的约束说明与日期，并将最后一次变更描述更新为当次讨论结论（或标失效后新增条目，视变更幅度）
+- **失效约束** → 标记生效状态=失效，填写失效日期，并将最后一次变更描述更新为失效讨论结论（不删除记录）
+
+引用约束时用编号，如 `产品约束-001`。
+
+> **最后一次变更描述**：概括该约束最近一次变更（新增 / 变更 / 失效）讨论的最后一层结论，写入该列以便追溯。
+
+## 强约束（初始定义）
+
+1. **迭代依据**：后续迭代（计划制定、代码实现、UI/产品呈现）必须以本目录规范为依据；无规范依据的实现不允许发生。
+2. **记录完备**：每条约束必须包含 编号 / 约束说明 / 添加日期 / 生效状态 / 失效日期 / 最后一次变更描述 六要素，缺失则视为无效记录。
+3. **变更需讨论**：修改或新增规范必须经过讨论，并记录变更理由；变更后已完成的迭代不受追溯约束，但新迭代立即生效。
+4. **与终极目标一致**：任何规范不得与 `01-终极目标/` 冲突；冲突时以终极目标为准，并引发讨论修订规范。
+
+## 待讨论细节
+
+- [ ] 编号规则的具体格式（如 `产品约束-001`、`技术约束-001`、`UI约束-001`）
+- [ ] 约束的变更流程（谁发起、如何评审、如何记录，变更 vs 失效+新增的判定）
+- [ ] 约束与计划的校验关系（计划如何证明符合约束）