review-implementation

审查实现（内部范围／分类引擎）

审查／审计技能组合使用的分类引擎：它接收综合发现表（适用的各维度审查轮次融合后的输出），验证所有适用维度均有体现，并返回分类后的决策表——随后停止。绝不重构或编辑代码。它负责范围／维度覆盖约定和分类准则（当前单元约定＋路由）；review-change、audit-pr 和 product-audit 会引用这些内容，而不是重复说明。

它不会扫描差异：每项发现都恰好由一个审查轮次负责（参见维度归属图）——各维度审查轮次（review-code、review-security、review-verify、review-perf、设计／a11y／品牌／SEO）负责发现问题，本引擎负责分类。此处不进行全面扫描。

使用时机

• 由 review-change（面向用户的审查入口）调用，作为其分类引擎处理融合后的发现表。
• 审计技能会引用其分类准则和覆盖约定。

范围

调用方的范围声明（相对于默认分支的分支差异，或传入的路径／glob）具有权威性；综合表已针对该范围收集。请在分类报告开头说明范围。

第 0 步 — 探索项目（始终首先执行）

根据 Agent 指南中的工作流约定和文档地图，阅读本技能所需的内容：架构／分层规则、测试理念，以及任何运行时／平台、安全、货币、i18n／SEO／a11y 和包体规则。若项目中有防护规则技能，请从中提取项目特有的风险维度。FIND.md 中的维度图是默认依据；项目文档会进一步明确哪些维度适用。

第 1 步 — 验证维度覆盖（综合表）

针对已声明的范围，确认综合发现表涵盖所有适用维度——根据 FIND.md 中的映射，每个维度由一个发现责任方负责：变更涉及但表中未提及的维度，属于缺失维度发现（维度 coverage），而不是默认通过。不同审查轮次对同一缺陷给出的重叠信号会在综合时合并为一行——表中既不能有重复项，也不能有遗漏。说明哪些维度适用，并确认每项都已体现。

第 2 步 — 分类（当前单元约定）

阅读分类与路由，不重新打开源文件，对综合表中的每一行进行分类：先判定 ignore（该主张），然后依据当前单元约定处理（范围内工作归为 fix-now / replan-in-unit / decision-required），最后对真正独立的未来能力归为 proposal。只进行一轮分类——不得按审查轮次或审查者分别分类。

上下文预算

输入是综合表，而非差异。最多完整阅读 10 个非差异文件以了解背景（调用方、约定、SPEC）；定向阅读（≤ 50 行的指定范围）以及 grep／glob 结果不计入。将每项分类立即记录为表格中的一行，并丢弃原始文件内容。

防护规则

• 仅处理发现和表格。此技能中绝不重构或编辑代码。
• 只有一个分类器。 分类只在此处针对融合后的表进行一次——不得由各审查者分别分类，也不得在各维度审查轮次中重新争论。
• 遵守死代码例外——已暂存／计划中的代码不属于死代码。
• 不要夸大严重性；区分“正确性／安全性”和“品味”。
• 同样也不要淡化：当前单元的工作绝不能归为 postpone／tradeoff／wontfix／disputed，也绝不能作为新问题——工作量大小应路由至 replan-in-unit，而不是降级处理（参见 CLASSIFY.md 中的当前单元约定）。
• 其他方面遵循项目的工作流约定（文档语言、证据）：引用 file:line，将不确定之处标记为 verify。

与其他技能的关系

• review-change 的分类引擎 —— 面向用户的评审技能会运行适用的各轴检查（查找器），合并其表格，然后调用此引擎进行分类。audit-pr 和 product-audit 也会复用此评估标准。
• 位于功能工作流的第 4 阶段（验证与评审）。
• fix-now 并入当前单元；replan-in-unit 会运行 node scripts/unit-route.mjs <unit>，其中的 route: replan 行会指出规划器，该规划器会在 execute-phase 前追加经用户确认的阶段；decision-required 会阻塞流程，等待用户决策；独立工作会成为提案，由用户转交给 triage-issue（D3）。

完成条件

• 已使用汇总表，已验证各轴覆盖情况（没有遗漏适用的轴，也没有重复行），每项发现都已说明理由并完成分流，且未更改任何代码。