review-change

审查变更

质量门禁：运行所有适用的审查，跳过其余审查，然后综合并分类为一份报告。仅列出发现；绝不编辑或重构。

回合约定

在每回合结束前，加载并验证规范的 回合约定（11 个方框）。特定技能的补充要求（回执收尾、隔离规则、适用性）位于此处和 REVIEW_PROCESS.md 中。缺少参考文件 → 停止。

对于最终 PR 审查，只有通过以下附加方框，本回合才算完成：

✓ Decision: REVIEW-PASS + PR exists →
  `bun scripts/review-receipt.mjs emit --pr <N> --head "$(git rev-parse HEAD)" …`
  RUN and exited 0 — the script posts the SHA-bound comment, re-reads the PR
  comments, and exits non-zero unless the newest exact-HEAD
  `review-change:pass` marker is confirmed, so its exit code IS this box

回执生成器运行时，还会记录影响路径范围清单（fix/286），这样审查后出现的仅涉及外部路径的提交（共享检出中的会话日志或工具状态提交）就不会使回执在合并门禁处失效 — 传入 --scope-base main（该单元的基础引用），由运行时自行生成清单；绝不要手动拼装摘要。没有范围清单的回执仍绑定到提交本身（旧版语义）。

回执收尾是报告的前置条件，而不是后续步骤：退出码非零时，不要打印固定的报告区块。没有当前回执的干净报告不得建议 /audit-pr。

对于 REVIEW-FAIL 或 NEEDS-DECISION，在结尾建议中列出所有未解决发现项 ID，并用 + 连接；审查绝不能只交接第一个发现项。

审查结束时的回合边界

对于 REVIEW-FAIL 或 NEEDS-DECISION，此技能在报告处结束：绝不调用 /fold-findings、/execute-phase、/unit-lane 或 /triage-issue — 这些是由用户单独发起的调用，必须在新的回合中运行（外层程序化驱动器可依照 REVIEW_PROCESS.md 在同一回合中组合相同的顺序）。审查唯一允许的变更是账本提交（持久化步骤 11），以及在有 PR 的 REVIEW-PASS 时添加回执评论（持久化步骤 12）；绝不归并发现项、执行阶段或编辑代码。打印报告区块后（报告步骤 13），REVIEW-FAIL/NEEDS-DECISION 回合即告结束。

使用内部验证约定；在映射候选证据之前，审查者和执行者检查同一份冻结的验收文档（旧版（功能 61 之前）ACCEPTANCE.md 或功能 61 之后单元文档中的 ## Acceptance criteria）。

使用时机

• 每次合并前必须执行。 在未实施变更的上下文中进行审查；如果当前上下文实施了变更，则停止并交接给新的上下文。execute-phase 也可能建议在层级边界、累积或敏感度节点进行可选检查点（#77）。
• 在需要适用的审查而不需要无关检查时使用。

范围

默认目标是当前变更（相对于默认分支的分支差异）；可接受路径或 glob 以扩大或缩小范围。在报告顶部注明范围。

审查章程——推翻这一主张

此工作流旨在证明有效的事物确实有效——而且效果良好：在程序实现、工程实践、决策制定以及符合用户预期方面皆是如此。本次审查的目的就是尝试推翻这一主张；如果经受住了考验，这种经受本身就是审查结果。因此：

• 范围内的缺陷就是本次审查的工作——绝不能说“超出范围”。 当前功能范围内的 bug、安全问题或防护检查跳过，都是 review-change 发现项：只要存在其中任何一项，功能就尚未完成。回报不在于交付，而在于满足验收标准、进行适度的工程实践而不过度设计、满足其他功能的要求（需要身份验证的页面必须验证会话和权限；如果需求依赖于对另一张表的更改，那么即使它“看起来”超出范围，仍在审查范围内），最重要的是满足用户预期。
• 要询问，不要推断——涵盖所有预期。 如果计划、差异或需求未能明确用户的预期，就用非技术术语将其作为问题提出（技术用户会要求一个应用；非技术用户会要求“一个能测量我心率的应用”）——绝不能假定用户意图。这将“询问而非推断”从验收标准扩展到评判此次更改所依据的每一项预期。
• 全仓库范围内的排查不属于本次审查。 跨整个仓库开展开放式 bug 排查、安全研究和损坏版本调查，应由 product-audit 负责，并在其中界定范围和预算；本次审查只关注当前更改。

步骤 0——了解项目与更改（始终优先执行）

根据工作流约定和文档地图，按以下因素确定审查维度：

1. 项目性质： UI（docs/frontend/）、Web／移动端／CLI／库／后端，以及可选的已记录平台技能（仅作补充）。
2. 影响范围： 差异涉及的内容（UI、API、基础设施、领域逻辑）。只有项目和影响范围都适用时，才采用相应维度。
3. 先前发现（可选的检索辅助信息，绝非权威来源）： 如果索引入口存在，在各项检查开始前，agentic-workflow doc --query "<change topic>" --json-only 可能会找到涉及同一领域的先前发现、决策和会话日志条目。索引缺失、入口不存在或查询结果为空，都不会改变任何事情——grep 仍是全面检索的后备方式，索引绝不是决策依据。

适用性矩阵（默认；项目文档可进一步细化）

每个维度都对应工作流自身内部审查包中的一项技能（skills/review-*——随工作流一同安装，因此不会缺失）：

维度 — 内部审查包技能	Web	移动端	控制台／CLI	库／SDK	后端／基础设施
review-code（正确性、简化、死代码、重复代码、架构）	✓	✓	✓	✓	✓
review-security	✓	✓	✓	✓	✓
review-verify（运行、确认实际行为、测试）	✓	✓	✓	✓	✓
review-design（UI／UX）	✓	✓	仅限 TUI	✗	✗
review-a11y	✓	✓	少见	✗	✗
review-brand（语气／文案）	✓	✓	输出文本	✗	✗
review-perf	✓	✓	✓	✓	✓
review-seo	✓	✗	✗	✗	✗
API 易用性／使用文档（内联检查）	如果有 API	如果有 API	标志／帮助信息	✓✓	✓

review-implementation（对综合表格执行一次分类的步骤——流程步骤 8）和 review-debt（对已分类表格执行债务转换的步骤——流程步骤 9）不是维度发现器： 它们在每次审查中各运行一次，而非按维度运行。

隔离规则（默认——每次审查都适用，不仅限对抗性审查）

每个适用的审查阶段、验证阶段（步骤 6）、分类器（步骤 8）和债务转换（步骤 9）都必须在 隔离且上下文干净的环境中运行，并且只返回固定的发现表以及 PASS | FAIL——绝不返回差异或散文。每个阶段启动一个全新的子 Agent／无头运行；若无法做到，则使用全新对话。仅传入审查范围、检查清单和步骤 0 文档；完整读取非差异内容的次数上限为 10 次（不计有针对性的 ≤50 行读取／grep）。协调器只保留表格，不保留源内容，并在步骤 7 将表格汇总。内联回退按顺序归并表格。阶段只能在其指定层级或更高层级运行，不得降低层级。

渐进式加载——选择一条审查路径

确认适用性和隔离要求后：

参考资料允许列表严格限定为以下七个链接路径。绝不虚构或读取其他 references/ 路径。

调用路径	按此顺序加载	跳过
默认审查	审查流程 → 对抗性建议 → 持久化并决策 → 输出与防护措施	汇总、可移植性、对抗性设置
--adversarial N	审查流程 → 在审查者运行前加载对抗性设置 → 在汇总前加载对抗性综合 → 持久化／决策 → 输出／防护措施	可移植性
--synthesize	审查流程 → 对抗性综合及提供的审查者表格 → 持久化／决策 → 输出／防护措施	对抗性设置、可移植性
legacy --merge	打印下方固定的迁移拒绝消息并停止——不执行任何 git／forge 修改	全部内容

已移除 legacy --merge——它不是别名。 调用 /review-change --merge 时，必须打印以下固定的迁移拒绝消息，并在运行任何 git 或 forge 修改命令之前停止：

migration: --merge is removed. Table fusion is --synthesize: pass the fixed
reviewer tables the same way and the synthesis contract fuses them. No
repository merge is performed by this skill.

当前审查路径只使用 --synthesize／汇总相关表述。只有在上下文、并行处理、斜杠命令或层级控制不可用时，才添加 可移植性。docs/workflow/REPOSITORY_STATE.md 是输出／防护措施的证据，不是技能参考资料；该路径负责 NRS 和架构不变量规则。

资源与此文件仅隔一层。固定的审查者／综合／输出约定均为字面定义。缺少必需资源 → 停止；绝不近似模拟审查约定。

可移植性

保持审查者上下文隔离。顺序／无头回退请使用可移植性；绝不合并独立的对抗性审查阶段。

与其他技能的关系

编排内部查找器（review-code、review-security、review-verify、 review-design、review-a11y、review-brand、review-perf、review-seo），随后运行一个 review-implementation 分类器和一个 review-debt 转换，默认彼此隔离；已安装的平台包为可选项。triage-issue 由用户调用，绝不自动运行（D3），适用于独立提案、审计发现和 --prioritize-now 运行。它属于第 4 阶段：检查点审查可选，结束审查必须执行且必须是全新的。fix-now 会路由至单元的折叠周期——通过单独的 /fold-findings 调用执行，绝不由本审查运行；replan-in-unit 会添加经用户确认的阶段，独立工作则成为提案。audit-pr 只使用已验证的 PR 评论回执，绝不使用聊天报告；product-audit 是定期扫描。出现 REVIEW-FAIL 时，手动修正路径为 /fold-findings，然后在变更后的 HEAD 上重新运行 /review-change（最多两个周期——根据 REVIEW_PROCESS.md，未经用户明确指示不得开始第三个周期）；程序化外层驱动程序也可以运行同样的审查→折叠序列。

完成条件

• 一张综合分类表涵盖所有适用维度，列出跳过的维度及原因，并包含人工检查。每项发现都有明确去向：合并、已确认的重新规划阶段、已提出的决策或已转交用户的提案；没有任何发现被悄然遗漏，且审查不会产生待办项（D3）。打印结尾的 → Next: 区块（无问题 → /audit-pr；反复出现偏差 → /product-audit），并且不更改任何代码。