forge-designlisted

# forge-design — 技术设计 ## Goal 把需求转化为可执行的技术设计，确保 brownfield 项目沿用既有架构，每个决策都有理由和代价。 ## Workflow ### 0.0 架构级变更预检（二次保险） 如果 CHANGE.md 末尾已有「架构层影响声明」或「走 A-architect 后回来」标记 → 跳过。 否则按 0-change §0.4 的 5 条标准重新判定： - 命中 + ARCHITECTURE.md 存在 → 检查 ADR 冲突，提示在 §1 显式声明 supersede 关系 - 命中 + ARCHITECTURE.md 不存在 → 反问用户：先跑 forge-architect / 继续但强制加 ADR 声明 / 重判 - 未命中 → 直接进步骤 0 ### 0. 技术栈预选（独立一条消息，等用户选定） **例外（可跳过）**： - CONTEXT.md 已有「已锁技术决策」→ 直接读用 - 用户描述含强偏好 → 锁定后跳过 - 纯库/SDK/CLI → 只选语言 **常规路径**： 加载 `references/tech-stacks-excerpt.md`，按「适用矩阵」过滤出 5~6 张最匹配卡片： - 5~6 张卡片（编号 + 名称 + 一句话栈描述） - **必给 1 首选 + 1 备选**，理由结合 REQUIREMENT.md 的 AC + 非功能需求 - **显式排除** 1~2 个 + 理由 - 末尾：`请回复数字（如 "1"）或描述偏好，选定后我才出具体 ADR 与架构图。` **选定后**：写入 DESIGN.md「## 0. 技术栈选定」段，后续所有设计基于这个栈展开。 ### 0.5 既有架构对齐（brownfield 必跑） **触发**：CONTEXT.md 存在且非空。**新创项目跳过**。 #### 0.5.1 列出本次 change 会触碰的既有模块 ``` MATCH (c:Community) WHERE c.keywords CONTAINS "<关键词>" RETURN c.heuristicLabel, c.symbolCount ``` **grep 回退**：基于 REQUIREMENT.md 和 CONTEXT.md，grep 出实际会涉及的模块： - 触碰模块（既有 · 来自 grep） - 新增模块 - 禁动清单（与本次无关，AI 不许"顺手"碰） #### 0.5.2 对齐既有抽象（防重复实现） 针对本次 change 需要的能力，先问已有的能不能用。禁止"顺便引入 X 库"——必须写出为什么不用既有的才能引新。 #### 0.5.3 沿用模式 vs 引入新模式 显式声明每个关键决策的选择。引入新模式必须有充分理由。 #### 0.5.4 写入 DESIGN.md 把上面三段写入 DESIGN.md「## 0.5 既有架构对齐」段。 ### 1. 技术决策（每条都要有理由） 格式：决策 → 备选 → 选择理由 → 取舍代价 ### 1.1 架构 Grill-me 审视（在锁定关键 ADR/架构图前必跑） 在确定重大架构决策（ADR）前，对备选方案进行多维压力追问： - **容量与可扩展性 Grill**："如果数据量或 QPS 增长 10 倍，该方案最先在哪里崩溃？" - **过早优化与复杂性 Grill**："方案是否引入了不必要的抽象层或中间件？（YAGNI 检查）" -