用途：帮助在 Apple 平台（尤其 SwiftUI）功能中选择、评审与迁移应用架构，覆盖模式选择、模块边界、依赖方向、迁移策略与架构级测试接缝。原则是选择能显式表达状态归属、依赖、副作用与测试的最小架构，新 SwiftUI 功能默认用 MV，只在观察到真实复杂性时升级。
主要能力：提供决策工作流——记录状态归属、输入输出、依赖、副作用、导航交接与现有测试；识别具体压力（复杂状态机、共享派生状态、依赖控制、功能组合、团队归属、UIKit 导航）；选最小模式并写明其新增内容与不变内容；实现带注入依赖和可观察状态迁移的垂直切片；运行行为测试与状态迁移、依赖失败测试。还提供模式对照表（MV、MVVM、MVI、TCA、Clean Architecture、Coordinator、VIPER 的适用条件与主要成本）、升级信号、迁移步骤与常见错误清单及评审清单。
使用方式：按工作流逐切片迁移，一次只移动一个状态迁移或依赖，每切片后比较行为、导航、取消、错误与持久化结果；从 ObservableObject 迁到 Observation 时先保持相同拥有者与变更隔离；MVVM 转 MV 需等视图绑定到相同模型或服务后再删除转发成员；采用 TCA 时先包裹一个功能的状态、动作与副作用，再逐步迁移依赖。示例中给出 MV 默认写法：用 @MainActor 与 @Observable 定义 TripStore，通过初始化注入 TripClient，在视图里以 @State 持有并在 .task 中调用 load()。
适用场景：SwiftUI 功能的状态与编排简单时用 MV；展示逻辑需要独立可测适配层时用 MVVM；状态与意图、副作用需单一可审计路径时用 MVI；多可组合功能需确定性副作用、依赖与测试时用 TCA；大型产品需严格依赖方向时用 Clean Architecture；UIKit 或混合导航需独立流程拥有者时用 Coordinator；维护既有 VIPER 模块时保留 VIPER。
限制：不负责 SwiftUI 属性包装器接线与视图组合、导航 API 与路由模型、隔离诊断、测试语法与夹具，这些应交给同源的其他技能。VIPER 仪式感极高，不宜作为新 SwiftUI 功能的默认选择；不要仅因视图变长就升级架构，应先抽取子视图、服务与聚焦的可观察模型；避免仅转发的视图模型、上帝对象、单功能混用多模式与一次性大爆炸迁移。