图 03 · 架构决策
我正在解决哪种不确定性？
六层架构决策堆，从领域语言（底层）到验证行为（顶层）。架构是决策的序列，而不是一次性画出来的图纸。每一层都可以用对应的技能推进。
为什么分层？
每一层都依赖于下面的层。如果领域语言不清晰，行为规范会使用不同的词描述相同的事情。如果模块边界未定义，行为规范无法确定是哪个模块负责什么。
出现分歧时，往往是两人在谈论不同的层。
不必从底层开始
对于小修改，可以从层 4（行为规范）直接开始，跳过前三层。当发现术语不一致时，再回到层 1。
架构不是一次性图纸，而是一系列按顺序解决的问题。
实例：TypeScript 实体库生命周期钩子
层 1 → 层 4 的决策序列
层 1：/grill-with-docs 确认「钩子」=「在实体状态变化时同步调用的回调」
层 2：{codebase-design} 决定钩子注册在 EntityRegistry 内部，不暴露给消费者
层 3：/research 调查 Node.js EventEmitter vs 直接回调的性能差异
层 4：/to-spec 描述 onMount(entity) 在 entity.activate() 之后同步调用
发现层级混乱的信号
- 讨论停滞在「实现细节」但领域词汇未对齐 → 先回到层 1
- spec 描述的行为横跨多个模块 → 先解决层 2 边界
- 测试通过但行为不符合预期 → 层 4 规范不完整
线性阅读顺序：从金字塔底部开始：层 1 确立领域语言（/grill-with-docs → CONTEXT.md）→ 层 2 划定模块边界（{codebase-design} → ADR）→ 层 3 分析数据流（/research · {prototype}）→ 层 4 规定行为（/to-spec）→ 层 5 做出实现决策（/to-tickets · /implement）→ 层 6 验证行为（{tdd} · {code-review}）。