coding-standards-enforcer

编码规范检查器

快速开始

只要涉及 Swift 源代码变更，且需要判断代码是否符合仓库的并发、观察和现代 API 规范，就使用此技能。

1. 首先对工作进行分类：
   • Swift 6.2 构建设置／语言模式问题
   • Swift MainActor／Actor 隔离／Sendable 问题
   • Observation @Observable／SwiftUI @State／@Bindable 所有权问题
   • 现代 API／风格／安全性清理
2. 仅加载与相应类别匹配的参考文件。
3. 按以下顺序检查变更代码：
   • 编译器诊断和隔离边界
   • 所有权和观察模型
   • API 现代化和安全性
4. 明确修复或指出偏离规范之处；不要让规范违规问题含糊不清。

何时加载参考资料

参考资料	使用时机
references/standards-review-map.md	需要了解检查顺序、分类路由和仓库级规范图谱时。
references/concurrency-guidelines.md	工作涉及 actors、@MainActor、Sendable、Task、async let、任务组或严格并发诊断时。
references/observation-modeling.md	工作涉及 Observation @Observable、@ObservationIgnored、SwiftUI @State、@Bindable、@Binding 或类型化环境数据流时。
references/modern-swift-apis.md	工作涉及 API 现代化、Foundation 替代方案、格式化、字符串匹配、强制解包或 Swift 原生风格时。

工作流

1. 检查变更的 Swift 文件，并记录主要问题类别。
2. 加载范围最小的相关参考文件。
3. 采用最小改动恢复规范合规性。
4. 如果条件允许，重新构建或重新运行受影响的测试范围。
5. 总结已修复的问题、有意保留的内容，以及任何尚待处理的迁移工作。

何时切换技能

• 如果核心问题是场景所有权、功能拆分或跨界面的状态布局，请切换到 spatial-app-architecture。
• 如果主要阻碍是构建失败，或修复规范问题后仍需复现的运行时问题，请切换到 build-run-debug。
• 如果工作主要是缩小失败测试的范围，而不是直接纠正规范违规，请切换到 test-triage。

防护原则

• 不要一概强制采用 @MainActor。隔离方式必须与所有权和运行时行为相匹配。
• 在新的 SwiftUI 或 visionOS 代码中，除非用户明确说明存在兼容性限制，或现有架构暂时无法脱离基于 Combine 的观察机制，否则不要引入 ObservableObject、@StateObject 或 @ObservedObject。
• 对于 Observation 所有权，请加载 observation-modeling.md，不要在此重复其 @Observable、@State 和 @Bindable 规则。
• 不要通过引入不必要的 Task.detached、DispatchQueue.main.async 或 @unchecked Sendable 来“修复”并发警告。
• 不要凭记忆假定 Swift 6.2 的默认 Actor 隔离行为；如果该选择会影响修复方案，请检查项目构建设置。
• 如果会改变语义，就不要机械地将 API 现代化。

输出要求

请提供：

• 已检查的文件或符号
• 应用的规范类别
• 已修复或仍存在的具体违规问题
• 使用的验证步骤
• 如果阻碍已不再属于规范问题，接下来应使用的技能