easysdd-architecture-check

design 写得越久，矛盾越容易藏在细节里——第 0 节定义的术语在第 3 节被悄悄换成了同义词；第 2 节的契约示例和第 1 节的关键决策对不上；声明"不做"的事情在推进步骤里悄悄出现了。代码一旦落地，"我以为方案是这样写的"和"代码实际是这样的"也会慢慢分叉。

本技能就是给这种时候做一次定向体检——只看不改，把不和谐点说清楚，让用户决定要不要改、怎么改。

适用场景

• 一份 design 要进入实现前，先确认它内部自洽
• feature 接近验收，确认代码和 design 对得上
• 改了一轮 design 后，确认新内容没和旧约定打架

不适用：

• 用户希望直接修复 → 转 easysdd-feature-implement 或 easysdd-issue-fix
• 用户希望做拍板决策 → 转 easysdd-decisions
• 用户还没有 design → 先转 easysdd-feature-design