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

03-设计约束（Design Constraints）

项目设计与技术的强制规范：下分产品功能、技术方案、UI交互三个文档模块。后续一切迭代以此为依据。

角色

项目的"宪法性规范"层。定义本项目必须遵守的设计约束，后续的每一次迭代（计划、执行、实现）都必须以此为依据，不得违背。

文档模块（三个）

03-设计约束/ 下三个文档模块，各自以列表形式记录约束条目，每条包含：编号 / 约束说明 / 添加日期 / 生效状态 / 失效日期 / 最后一次变更描述。

文档模块	内容范围
产品功能约束.md	产品功能层面的约束：功能边界、行为定义、不可违背的产品规则
技术方案约束.md	技术方案层面的约束：技术栈、架构、实现规范、依赖原则
UI交互约束.md	UI 与交互层面的约束：视觉风格、组件、交互行为

后续讨论确定的设计/技术/产品约束与变更，直接更新对应模块列表：

• 新增约束 → 追加一条新记录（分配新编号，填约束说明、添加日期，生效状态=生效，最后一次变更描述=新增讨论结论）
• 变更约束 → 更新该条目的约束说明与日期，并将最后一次变更描述更新为当次讨论结论（或标失效后新增条目，视变更幅度）
• 失效约束 → 标记生效状态=失效，填写失效日期，并将最后一次变更描述更新为失效讨论结论（不删除记录）

引用约束时用编号，如 产品约束-001。

最后一次变更描述：概括该约束最近一次变更（新增 / 变更 / 失效）讨论的最后一层结论，写入该列以便追溯。

强约束（初始定义）

1. 迭代依据：后续迭代（计划制定、代码实现、UI/产品呈现）必须以本目录规范为依据；无规范依据的实现不允许发生。
2. 记录完备：每条约束必须包含 编号 / 约束说明 / 添加日期 / 生效状态 / 失效日期 / 最后一次变更描述 六要素，缺失则视为无效记录。
3. 变更需讨论：修改或新增规范必须经过讨论，并记录变更理由；变更后已完成的迭代不受追溯约束，但新迭代立即生效。
4. 与终极目标一致：任何规范不得与 01-终极目标/ 冲突；冲突时以终极目标为准，并引发讨论修订规范。

待讨论细节

• 编号规则的具体格式（如 产品约束-001、技术约束-001、UI约束-001）
• 约束的变更流程（谁发起、如何评审、如何记录，变更 vs 失效+新增的判定）
• 约束与计划的校验关系（计划如何证明符合约束）