init

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 失效+新增的判定）
+- [ ] 约束与计划的校验关系（计划如何证明符合约束）