review-architecture

技能：架构审查

目的

根据 architecture-quality 评估提供的代码范围。此技能负责执行和收集证据；Rule 负责所有架构标准。输出发现列表，绝不输出评分或重写内容。

核心目标

针对每一项适用但未通过的 Rule 条目，提出位置精确、可执行的架构发现，同时报告哪些条目不适用，或因缺少项目参数而无法评估。

成功标准：

1. 指明当前生效的 Rule 版本及每个适用条目的 ID。
2. 在作出判断前，明确项目拓扑、受保护的契约、配置文件和有效豁免。
3. 当 Rule 指定自动化证据时，优先使用自动化证据，但不得夸大工具的覆盖范围。
4. 每条发现都引用一项未通过的 Rule ID，且类别为 cognitive-architecture。
5. 只有在所有适用条目均已通过、获得有效豁免或明确注明证据限制后，才能报告零条发现。

范围边界

此技能仅审查架构。不负责选择差异还是代码库审查范围、不审查语言规范、安全性、性能、可靠性、可观测性或测试质量、不修改代码，也不批准豁免。对于这些事项，请使用相应的原子技能或 orchestrate-code-review。

使用场景

• 针对变更、模块或代码仓库开展架构审查
• orchestrate-code-review 中的架构认知步骤
• 核实已声明的模块拓扑或受保护契约变更
• 实现后审查组合、连线和变更范围风险

行为

1. 完整加载 architecture-quality，并记录其版本。
2. 如存在，阅读最近的项目 AGENTS.md、架构文档和 .ai-cortex/config.yaml。根据 rule-modeling 确定生效的配置文件、参数和豁免。
3. 仅收集适用条目所需的证据：
   • 优先使用仓库原生的依赖或契约检查。
   • 否则使用构建元数据、导入图、导出签名、生产环境调用点和提供的差异。
   • 对于判断类条目，应比较具体的职责和依赖证据；不要使用无法解释的质量评分。
4. 独立评估每一项适用条目。缺少项目参数时，仅将对应的 project:* 条目标记为无法评估；不得因此忽略基线条目。
5. 每项未履行的义务输出一条发现。在描述中包含当前生效的 Rule 版本，例如 architecture-quality@<active-version>/ARC-003。
6. 仅当豁免的每个字段都有效，且其 Rule ID 和范围涵盖确切的发现时，才应用该豁免。单独报告豁免条目；不得将其从记录中抹去。
7. 使用 findings-list Spec 中的确切字段 passed、waived、not_applicable 和 evidence_limited 返回 Rule 覆盖情况。

输入和输出

输入是已选定的代码范围：文件、目录或差异。可选项目背景可能包括变更规模和上游技术设计。

输出为零条或多条符合 findings-list 格式的发现。每条发现的类别均为 cognitive-architecture；描述中引用未通过的 Rule ID。覆盖情况页脚属于元数据，不是发现。

限制

• 不要重述或在本地扩展架构检查清单；缺少某项标准时，应提出规则变更。
• 不要假定某种具名架构风格，也不要臆造模块拓扑。
• 不要把缺少依赖工具当作依赖项均已通过的证明。
• 审查期间不要批准、扩大或创建豁免。
• 不要执行修复；如请求修复，应将阻塞性发现交给 orchestrate-repair-loop。
• 不要将缺少测试报告为架构发现。此 Skill 负责判断生产代码中的组合方式和契约是否正确；review-testing 负责判断是否有任何测试能发现问题。

自检

• 已加载规范架构规则，并记录其版本。
• 已根据项目证据解析有效配置文件、参数和豁免。
• 每个适用的规则 ID 均已标记为通过、发现、有效豁免或明确的证据限制。
• 每项发现均有精确位置、类别 cognitive-architecture、有效严重级别和引用的规则 ID。
• 未在此 Skill 中臆造或重复任何架构标准。
• 覆盖范围页脚区分了通过、豁免、不适用和证据限制。

示例

示例 1：声明的依赖违规

输入：项目声明 domain 没有向外的模块依赖，但 domain/order.ts 导入了数据库适配器。

预期：在该导入处报告一项严重级别为 major、类别为 cognitive-architecture 的发现，并引用 ARC-002。同时评估 ARC-003 和其他适用的基线项目；不要假定它们也不通过。

示例 2：有效的遗留循环豁免

输入：某个循环符合 ARC-003，且未过期的豁免涵盖了确切的遗留目录，并包含经批准的冻结控制措施。

预期：在豁免 ID 下列出 ARC-003，验证没有新节点或边加入冻结循环；若补偿控制措施遭到违反，则报告一项发现。

示例 3：没有项目拓扑

输入：一个小型库没有 .ai-cortex/config.yaml。

预期：根据参数要求，将 ARC-002 和 ARC-009 标记为无法评估或不适用，然后照常评估基线内聚性、循环、边界泄漏、耦合和推测性扩展。

示例 4：分析器无法解析的符号

输入：未使用符号分析器报告 jobs.QuarterlyCloseTask 未被引用。该类通过配置中保存的名称实例化，而正在审查的变更会将其删除。

预期：报告一项轻微级别为 minor、引用 ARC-010 的发现。删除操作依据的是无法识别配置命名构造或反射式构造的工具，因此不能据此证明没有任何代码会调用该类——此项目要求提供覆盖一个完整业务周期的运行时信号，并包含季度结账所涉及的低频路径。如果变更保留此类符号，且无论如何都没有运行时信号，则将 ARC-010 报告为 evidence_limited；干净的分析器运行结果不能证明分析器无法解析的内容通过了检查。

示例 5：弃用标记没有负责人或移除时间点

输入：api.v1.SearchRequest 上的 @deprecated 注解注明了替代项，但既未记录负责人，也未注明移除期限或日期。

预期：报告一项轻微级别为 minor、引用 ARC-011 的发现，并明确指出缺少的两个字段，而不是笼统指出标记本身。项目不拥有的依赖项上的标记不适用；若已记录的移除时间点已过，但仍未移除且未记录延期，则应报告发现。