improve-architecture

改进架构

发现具体的架构摩擦，并只明确仍需做出的决策。

使用 architecture-language.md、engineering-discipline.md，以及仓库中的 Glossary/ADR（如有）。

边界

• 使用此技能来发现改进机会，或明确尚未解决的模块／接口／接缝选择。
• 使用 review-work 来评估具体变更、PR 或阶段中的架构。
• 对已选定且保持行为不变的简化，交给 simplify-work；其他已确定的实现工作交给 implement-work。不要强行要求用户选择候选项、参与访谈、制定计划或进行交接。
• 评审可以建议使用此技能，但不应自动启动它。

发现

1. 从调用方可见的用法入手。绘制所需的最小调用、组件、数据或控制流示意，以明确模块、所有权、接口和接缝。
2. 找出有证据支持的摩擦：知识分散、浅层透传层、细节泄漏、可避免的分支或可变状态、难以测试的行为、变更影响扩大、所有权不明确，或允许无效状态的数据模型。
3. 仅当用户尚未选定领域时，才提供一组精简且按优先级排序的候选项。
4. 对于选定的候选项，只明确关键约束、迁移、验证和对调用方的影响。
5. 给出最精简且有用的下一步产物：建议、接口选择、范围明确的 simplify-work 或 implement-work 工作项、计划请求或交接。默认不创建计划或进行交接。

候选项摘要应说明领域、观察到的摩擦、改进机会、收益、风险和证据。

接口或接缝选择

当放置位置确实尚未确定时，根据对调用方的影响、隐藏复杂性、迁移成本、可测试性、易变性和所有权，对比两三个实质不同的选项，并给出建议。如果放置位置显而易见或没有变化，则跳过此步骤。

将架构术语视为启发式工具。若单个适配器能够隔离易变性、所有权或测试需求，就足以构成一个接缝；应询问它保护的是哪个边界。优先使用公开或有意保持稳定的接口作为行为测试面，避免仅为测试而暴露内部细节。

不要提议大规模重写，不要在没有新摩擦证据时重新争论 ADR，也不要不必要地要求普通功能开发使用架构术语。