创建相关issues

AGENTS.md

@@ -90,6 +90,18 @@ handlers := &bootstrap.Handlers{
 4. 当前需求触碰复杂只读逻辑时，只迁移该查询到 `internal/query/<context>`；Query 可直接使用 GORM 做联表、聚合、权限过滤和 DTO 投影。
 5. 不为追求 DDD 形式创建无业务价值的接口、工厂和目录；架构选择不明确时先阅读 DDD 规范并写明判断依据。
 
+### 规划与任务拆分约束
+
+创建或修改 PRD、OpenSpec proposal/design/tasks、实施计划或本地 Issue/Ticket 前，必须完整阅读 `docs/7月迭代/独立方案/基础规范/DDD规范.md`，并遵守以下规则：
+
+1. 每个可实施单元必须标明适用的架构通道：复杂写、简单写、Query、Infrastructure 或 Application + Port/Adapter；同一纵向切片涉及多条通道时，标明主通道和辅助通道。
+2. 每个任务必须说明其收口的完整业务边界及明确不迁移的旧代码范围，禁止借任务拆分扩大为模块级或全仓重构。
+3. Ticket 必须按可独立验证的纵向切片拆分，不得按“先建表、再 Service、再 Handler”生成水平分层任务；宽范围机械迁移按 expand–migrate–contract 拆分并保持各阶段可验证。
+4. 复杂写的不变量、状态机、金额、并发和可靠事件必须完整进入 Domain/Application 边界；简单写不得强行创建聚合；读取不得经过聚合根或修改状态。
+5. 已评审 PRD 或 OpenSpec 已确定的架构选择是实施契约，拆票和实现阶段不得自行改变；确需调整时必须先说明影响并获得用户确认。
+6. 跨 PRD 或跨 Change 的依赖必须引用具体任务或 Ticket，禁止只写“依赖公共基础设施”等无法判定完成状态的模糊阻塞项。
+7. 任务正文只记录本切片适用的架构约束，不机械复制整份 DDD 规范；实现和评审仍以本文件及完整 DDD 规范为准。
+
 ## 核心原则
 
 ### 错误处理