work-review

严格代码质量审查

使用此技能进行格外严格的审查，重点关注实现质量、可维护性、抽象质量和代码库健康状况。

最重要的是，此技能应促使审查者在代码结构方面勇于进取。不要只指出局部的清理机会，而要主动寻找“代码柔道”式的改进：在保留行为的同时，通过重构让实现变得大幅精简、直接、简单而优雅。

此技能仅可通过名称调用（disable-model-invocation: true）——不会自动触发；请直接调用 /work-review（例如，在编排器的 Review 流程中通过 work-check 到达此技能）。

这是质量系统中的一种审查模式。它以工作流模式执行——Agent 在编排子 Agent 时手动运行的一套确定性规范。编排模型（三种形态、执行机制、架构约定）位于 ../work/references/workflow-mode.md；它所防范的失败模式（L1–L8）位于 ../work/references/anti-error-lessons.md。此技能不会重复这些文档的内容，而是引用它们，并且仅保留审查者独立执行任务所需的内联内容。

工作流形态

PIPELINE → 一个 BARRIER 合并点。 工作的自然单元是 (file × lens)：每个已修改文件都会独立经过各个审查视角——文件 A 可以正在进行分层审查，而文件 B 仍在进行结构审查，各审查视角之间没有屏障（墙钟时间 = 单个文件审查链中最慢的一条所需的时间，而不是各审查视角耗时之和）。请将它们作为流水线运行。最后恰好有一个真正的跨项依赖：一个去重／合并屏障，用于合并由多个审查视角／文件报告的同一结构性问题，并对所有问题的并集进行全局完整性检查。设置此屏障有其必要性（跨项去重 + 单一的排序输出），并且它只是普通的集合逻辑，绝不能调用 Agent。这是 workflow-mode.md §2 中 Review harness 的可维护性专用版本：lenses (parallel) → dedup barrier → completeness sweep → ranked output。它不是 LOOP——差异范围已知且有限；没有需要重复执行、结果数量未知的“找出所有问题”轮次。

核心提示词

从以下基线开始：

对当前分支的更改进行深入的代码质量审计。 重新思考如何构建／实现这些更改，以在不影响行为的前提下实质性提升代码质量。 努力改进抽象和模块化，减少意大利面条式代码，并提升简洁性与可读性。 勇于进取：如果有明确的实现改进路径，哪怕需要重构部分代码库，也要着手改进。 务必全面、严谨。反复衡量，谨慎下刀。

步骤 0 — 测量（先看依据，再下判断）— L1

在形成任何判断之前，先运行成本低且结果确定的依据检查。“三思而后行”在这里不是一句口号，而是一道门槛。不要凭目测判断文件大小，也不要断言“这个文件太大了”；要用数字证明。将所有数据记录到一个 baseline 对象中，供后续阶段读取（严重性判断也必须引用这些数据）。

1. 界定差异范围 — 使用 git diff --numstat（以及 git diff --stat）获取确切的改动文件集和每个文件的新增／删除行数。这就是审查范围；其他所有检查都以此为限。
2. 验证 1k 行规则 — 对每个改动文件，运行 wc -l <file> 获取当前行数，并还原差异前的行数（current − added + removed，或 git show HEAD:<file> | wc -l）。§1 中“低于 1k → 高于 1k”的异味是两个数字所证实的事实，绝不是猜测。差异后的文件有 1,180 行、而差异前已有 1,140 行，与 PR 将文件从 920 行推过阈值增至 1,060 行，是两种不同（后者较弱）的发现。
3. 运行构建／类型检查／测试 — 运行项目的类型检查和测试命令。会破坏构建或测试的“更整洁”结构建议并不更整洁；所有声称不改变行为的结论（§Approval Bar，L8）都要以此基线为依据进行核验。
4. 记录基线 — 输出一次，供后续阶段和人工审查：

{
  "baseline": {
    "diffFiles": [{ "file": "src/upload-handler.ts", "added": 140, "removed": 12 }],
    "lineCounts": [{ "file": "src/upload-handler.ts", "before": 920, "after": 1048, "crosses1k": true }],
    "build": { "command": "<typecheck> && <test>", "status": "pass", "notes": "" },
    "oraclesRun": ["git diff --numstat", "wc -l", "<typecheck>", "<test>"]
  }
}

如果某项依据检查无法运行（没有测试命令、文件已脱离版本控制），请在 baseline.build.notes 中明确说明并继续——不作说明会被理解为“已运行且通过”（L7）。

输出约定（结构化）— L6

每项发现都必须是经过架构校验的对象，不能是需要调用方自行搜索的散文。此技能作为子 Agent 运行时，须在回复末尾输出一个单独的 fenced ```json 代码块，且符合以下约定；调用方会校验结构，格式错误时最多重新请求一次，再将其视为失败（参见 workflow-mode.md §3–4）。

{
  "id": "cr-upload-host-branch",
  "file": "src/http/routes/upload-handler.ts",
  "lineRange": "168-211",
  "lens": "structural",
  "severity": "major",
  "reReadSources": ["src/http/routes/upload-handler.ts:168-211"],
  "workDone": true,
  "evidence": "upload-handler.ts:171 — new `if (req.query.hostname)` branch bolted onto the auth path; quote: `const tenant = req.query.hostname ?? session.tenant`",
  "suggestedRefactor": "Hoist tenant resolution into a single `resolveTenant(session)` policy; the host-override branch disappears from the request path.",
  "behaviorPreservingProof": "Same tenant for every existing caller (session.tenant), verified against Step-0 typecheck+tests baseline=pass; only the dead host-override path is removed.",
  "confidence": "high"
}

字段规则：

• lens — 枚举值 structural | duplication | abstraction | layering | orchestration | size | completeness。
• severity — 枚举值 blocker | major | minor | consider。必须基于已验证的影响（L6），而非主观印象：blocker = 按照 Approval Bar，可推定会阻止合并；major = 确实降低了可维护性；minor = 值得处理，但影响范围有限；consider = 可选的润色。切勿把推测性的清理夸大为 blocker，也不要把真正的意大利面式回归轻描淡写为 consider。
• evidence — 具体的 file:line，加上一段可供调用方重新查看的简短原文引述。没有证据 ⇒ 该发现属于弃权，不能标为 blocker（L8）。
• reReadSources — string[]；你为确认此发现而独立重新查看的当前源代码中的确切 file:line 范围（L2/L8）。为空 ⇒ 该发现是在未重新查看的情况下提出的。
• workDone — boolean；仅当你确实执行了支持此发现的重新查看／依据检查时，才设为 true，不能依赖首次浏览时的记忆。false ⇒ 未执行验证工作。
• 弃权规则（与 work-refute 一致）：blocker／major 若 reReadSources 为空或 workDone:false，即为弃权——说明尚未完成验证工作，因此会降级为 minor／consider 并记录（不能阻止合并），绝不能以 blocker 身份呈现。
• suggestedRefactor — 以结构性改动说明代码整理方案，而不是“重命名 X”。
• behaviorPreservingProof — 任何 blocker／major 结构性主张都必须提供：说明重构如何保持行为，并以步骤 0 的 baseline 为依据进行核验。
• confidence — 枚举值 high | medium | low；用于确定分流优先级（见下文）。

合并后的审查会返回一个封装对象，确保没有内容被悄然遗漏（L7）：

{
  "baseline": { "...": "see Step 0" },
  "findings": [ { "...": "objects above, ranked by severity then confidence" } ],
  "droppedTail": [ { "id": "cr-x", "file": "...", "oneLiner": "minor: var name shadows outer scope" } ],
  "caps": { "lensesRun": ["structural","duplication","..."], "lensesSkipped": [], "tier": "high", "reason": "" },
  "verdict": "request-changes"
}

verdict — 枚举值 approve | approve-with-nits | request-changes | block。

Review Lenses（多样化审查）— L3

使用相同提示词进行 N 次审查是重复劳动，而非扩大覆盖范围（L3）。对于非平凡的 diff， 应针对每个不同的审查视角进行一次重点审查——多样性才能发现单次通读会遗漏的问题。审查视角（每项对应一个枚举值）：

• structural — 代码柔术：能否删去整个分支／辅助函数／模式／层？是否可以重新构建问题框架，让这项改动显得顺理成章？（涵盖 §0，即雄心要求。）
• duplication — 复制粘贴的逻辑、近似重复的辅助函数，以及已有规范实现却另行编写的专用工具函数（§6，“需要标记的内容”）。
• abstraction — 薄封装、恒等／透传辅助函数、隐藏简单数据结构的通用“魔法”，以及令真实契约模糊不清的类型转换／any／unknown／可选性（§4、§5）。
• layering — 功能逻辑泄漏到共享路径；实现细节泄漏到 API；逻辑放在了错误的包／模块／层中（§6）。
• orchestration — 将互不相关的工作无谓地串行化；非原子的部分更新流程（§7）。
• size — 文件／组件的大小与拆分情况，应结合 Step-0 的数值进行评估（§1）。
• completeness — diff 之外的全面性检查（见下一节）。

流水线机制： 为每个 (file, lens) 启动一个重点审查子 Agent（或在较低层级按每个审查视角覆盖整个 diff），指定合适的子 Agent 角色，并在后台运行；这些审查只读，因此无需隔离 worktree。等待全部完成后，收集各自的结果。然后执行唯一一次 BARRIER 合并：对指向相同 file、lineRange 有重叠且根本问题相同的发现去重（保留严重性最高、证据最充分的实例），之后才能继续。去重是简单的集合逻辑，不是一次 Agent 调用。

并发与预算（不得静默设限——L7）： 分批启动，每批 min(16, cores−2) 个；超出的任务排队等待。如果预算不足，明确舍弃某些审查视角或文件，并将舍弃情况写入 caps.lensesSkipped / caps.reason（并通过所用 harness 的 todo／计划工具展示）——绝不能悄悄缩小覆盖范围。已终止／出错的审查视角子 Agent 会被过滤掉（.filter(Boolean)），不计为“通过”审查，其遗漏情况需记录在 caps 中（与 workflow-mode.md 的 null 处理方式一致）。对于较长时间的审计，将 { phasesDone, lensesRun, findings, droppedDueToCaps } 记录到 quality-journals/<task-id>.json（位于 Agent 的数据目录下），这样恢复任务时可以重新载入覆盖情况，而不必从头运行。

全面性检查（diff 之外）— L5

最有价值的全面性检查，不是重新检查已审阅的内容，而是找出 diff 从未触及但本应涉及的内容（L5）。完成各视角审查后，每个类别至少运行一个全仓库检查手段：

• 每个被提取／重命名／重构的符号 → 使用 grep/ripgrep 搜索整个仓库中的其他调用位置。若某项签名变更或提取只更新了 diff 中的调用位置，却遗漏仍在使用旧形式的同级代码，这是一个真实问题，diff 内的审查视角无法发现。
• 每个重复代码块 → 使用 grep 搜索同级模块中相同的模式：这是第 3 份副本（现在就应提取），还是已有可复用的规范辅助函数（§6）？
• 每项删除 → 使用 grep 搜索因此变成死代码的内容：对已删除导出的引用、如今无法到达的分支，或再也没有代码读取的配置键。

在 caps 中记录运行过的每项全局检查手段，以便区分“未发现全面性问题”和“跳过了全面性检查”（L7）。此检查与 ../work-gaps/SKILL.md 中的模式相同，是 diff 范围内的最后一道关卡。

不可妥协的附加标准

应用上述基准提示，并遵守以下明确的审查规则：

0. 积极寻求简化结构。

   • 不要满足于“这样可以稍微简洁一些”。
   • 寻找机会重新设计变更，让整个分支、辅助函数、模式、条件判断或层级彻底消失。
   • 优先选择那种事后看来理所当然的方案。
   • 假设通常存在一种“代码柔术”式的做法：通过更有效地利用现有架构来重组代码，让变更大幅简化、更加优雅。
   • 如果有办法删掉复杂性，而不是重新安排它，就要大力推动这种做法。

1. 没有非常充分的理由，不要让 PR 将不足 1k 行的文件扩充到超过 1k 行。

   • 默认将此视为强烈的代码质量问题。
   • 优先提取辅助函数、子组件、模块或局部抽象，而不是任由文件膨胀到 1000 行以上。
   • 如果 diff 会越过这一阈值，要明确询问是否应该先拆分代码。
   • 只有在存在令人信服的结构性理由，且最终文件仍然组织清晰时，才可豁免。

2. 不要让现有代码随机增长成一团乱麻。

   • 对新增的临时条件判断、散落的特殊情况，或插入不相关流程的一次性分支保持高度警惕。
   • 如果变更在“各处随意增加奇怪的 if 语句”，就应将其视为设计问题，而不是风格上的小问题。
   • 优先将逻辑放入专用抽象、辅助函数、状态机、策略对象或独立模块，而不是将其缠绕进现有流程。
   • 即使变更在功能上可行，只要它让周边代码更难理解，也要指出。

3. 优先改进设计，而不只是接受能运行的代码。

   • 如果能在保持行为不变的同时显著改善结构，就应推动采用更清晰的方案。
   • 不要对那些“能用”但会让代码库变得更乱的实现照单全收。
   • 强烈优先选择能够彻底删去各个活动部件的简化方案，而不是只把同样的复杂性分散到别处的重构。

4. 优先选择直接、朴实、易维护的代码，而不是取巧或魔法般的代码。

   • 将脆弱、临时拼凑或“魔法般”的行为视为代码质量问题。
   • 对那些掩盖简单数据形状假设的通用机制保持怀疑。
   • 指出那些没有带来清晰度、只增加间接层的薄抽象、身份包装器或透传辅助函数。

5. 在影响可维护性时，严格把关类型和边界的清晰度。

   • 当存在更清晰的类型边界时，要质疑不必要的可选类型、unknown、any 或大量类型断言。
   • 优先使用显式类型模型或共享契约，而不是形状松散的临时对象。
   • 如果某个分支依赖静默回退来掩盖不明确的不变量，就要追问是否应该明确边界。

6. 将逻辑保留在规范层，并复用现有辅助工具。

   • 指出泄漏到共享路径中的功能逻辑，或通过 API 暴露的实现细节。
   • 优先使用现有的规范化工具和辅助函数，而不是另起炉灶。
   • 推动代码归入正确的包、服务或模块，避免架构持续偏离。

7. 当更清晰的结构显而易见时，将不必要的顺序编排和非原子更新视为设计问题。

   • 如果彼此独立的工作无缘无故被串行执行，就要询问流程是否应该并行运行。
   • 如果相关更新可能导致状态只应用了一部分，就要推动采用原子性更好的结构。
   • 不要过度关注微优化，但要指出那些可以避免、却会让实现更脆弱的编排复杂性。

主要审查问题

对于每项有意义的变更，请询问：

• 是否有一种“借力打力”的做法，能让实现大幅简化？
• 能否重新构思这项变更，从而减少所需的概念、分支或辅助层？
• 这是否改善或削弱了局部架构？
• 这份差异是否在本应采用更好抽象的地方增加了分支复杂度？
• 某个原本内聚的模块是否变得耦合更多、状态更多或更难浏览？
• 这段逻辑是否位于正确的文件和层级？
• 这项变更是否让文件或组件超出合理的大小范围？
• 是否存在重复的条件判断，表明缺少合适的模型或辅助函数？
• 实现是否直接易读，还是依赖特殊情况和偶然的控制流？
• 这个抽象是否确实发挥了作用，还是只是一个包装层？
• 这份差异是否引入了类型转换、可选性或临时拼凑的对象结构，模糊了真正的不变量？
• 这段逻辑是否位于规范层，还是这份差异让细节越过了边界？
• 这段编排是否比必要情况更串行，或原子性更差？

需要重点标记的问题

遇到以下情况时，请升级问题严重程度：

• 实现复杂，而通过更清晰的重新构思本可整类删去复杂性。
• 重构只是移动代码，却没有减少读者需要记住的概念数量。
• 文件因 PR 变更而超过 1000 行，尤其是新代码本可拆分出去的情况。
• 在无关的代码路径中硬塞新的条件判断。
• 一次性布尔值、可空模式或标志让现有控制流变复杂。
• 特定功能的逻辑泄漏到通用模块中。
• 通用的“魔法”处理隐藏了简单结构，让代码更难推理。
• 轻量包装层或恒等抽象增加了间接层，却没有带来简化。
• 不必要的类型转换、any、unknown 或可选参数模糊了真正的契约。
• 复制粘贴逻辑，而不是提取辅助函数。
• 在已经很繁忙的函数中间处理范围狭窄的边缘情况。
• 重构虽然通过了测试，却降低了代码的模块化程度或可读性。
• “临时”分支很可能变成长期技术债。
• 代码库已有规范工具，却另行编写专用辅助函数。
• 逻辑添加到了错误的层级或软件包中，而它本应位于更中心的位置。
• 明显彼此独立的工作采用串行异步流程，而并行执行能让代码更简单、更清晰。
• 部分更新逻辑让状态的原子性低于必要程度。

优先考虑的改进方案

发现代码质量问题时，优先提出以下建议：

• 删除整层间接调用，而不是费心打磨它。
• 重新设计状态模型，让条件判断自然消失，而不是把它们集中起来。
• 调整所有权边界，让功能成为现有抽象的自然扩展。
• 将特殊情况逻辑转变为更简单、例外更少的默认流程。
• 提取辅助函数或纯函数。
• 将大型文件拆分为更小、更专注的模块。
• 将特定于功能的逻辑移至专用抽象之后。
• 用类型化模型或显式分发器替换条件链。
• 将编排与业务逻辑分离。
• 将重复分支合并为一个更清晰的流程。
• 删除无法实质性提升 API 清晰度的封装层。
• 复用现有的标准辅助函数，而不是引入近似重复的实现。
• 明确类型边界，让控制流更简单。
• 将逻辑移至已有该概念所有权的包、模块或层中。
• 如果并行处理独立工作也能简化编排，就采用并行处理。
• 将相关更新重构为更原子化的流程，避免出现难以推理的部分状态。

面对真正的结构性问题，不要满足于“或许可以改个名字”这类反馈。 如果有合理的途径可以让想法变得简单得多，就不要满足于仅仅把同一个混乱的想法打磨得更整洁。

评审语气

直截了当、严肃，并对质量提出严格要求。 不要无礼，但也不要把重大的可维护性问题说成轻微的建议。 如果代码让代码库变得更混乱，就明确指出。 如果实现错过了大幅简化的机会，也要明确指出。

推荐表达：

• 这会让文件超过 1k 行。我们能先把它拆解一下吗？
• 这会在已经很繁杂的流程中再增加一个特殊分支。我们能把它移到独立的抽象后面吗？
• 这能用，但会让周边代码更像一团乱麻。我们保留行为，并重构实现吧。
• 这看起来像是功能逻辑泄漏到了共享路径中。我们能把它隔离开吗？
• 这个抽象似乎没有必要。我们能直接保留原有流程吗？
• 为什么这里需要类型转换 / 可选项？我们能把边界定义得更明确吗？
• 这看起来像是为已有功能专门写的辅助函数。我们能复用标准实现吗？
• 我觉得有个巧妙的重构办法能让事情简单得多。我们能重新设计一下，让这些分支消失吗？
• 这次重构只是转移了复杂性，并没有真正消除复杂性。有没有办法让模型本身更简单？

输出期望

按以下顺序优先报告发现：

1. 结构性的代码质量退化
2. 错失大幅简化／代码重构机会
3. 意大利面式代码／分支复杂度增加
4. 使代码更难理解的边界／抽象／类型契约问题
5. 文件大小与拆分问题
6. 模块化与抽象问题
7. 可读性与可维护性问题

分级处理，不要截断（L7）。“不要用小问题淹没读者”的意思是排序并降级，而不是悄悄省略。按 severity（blocker > major > minor > consider）排序所有发现，再按置信度排序：

1. 完整呈现高置信度的问题（blocker／major，以及你有high置信度的任何 minor）——每项都要包含其 evidence、suggestedRefactor，并且结构性 blocker／major 还要包含 behaviorPreservingProof。
2. 降级处理其余问题——每一项你选择不展开的 minor／consider，都要以一句话列入 droppedTail，不能让它们凭空消失。读者必须能分辨“差异干净”和“我不再详细撰写”。悄悄截断会让人误以为“所有内容都已覆盖”。

因此，规则是：完整呈现少量高置信度评论，再加上完整且简洁的 droppedTail——既不要罗列冗长的表面问题，也不要悄悄缩短内容。

审批标准

不要仅仅因为行为看起来正确就批准。 审批标准如下：

• 没有明显的结构性回归
• 如果存在明显路径，可以大幅简化实现，却没有这样做
• 文件大小没有无正当理由地激增
• 没有因特殊情况分支而明显变得杂乱
• 没有明显取巧或神秘的抽象，导致代码更难推理
• 没有不必要的包装器／类型转换／可选性变更，掩盖真实设计
• 没有明显的架构边界泄漏或本可避免的规范辅助函数重复
• 没有错失明显的分解机会，导致可维护性未能得到实质改善

除非作者能够给出清晰的理由，否则应将以下情况视为推定阻断项：

• PR 保留了大量偶然复杂性，尽管存在合理的代码手法，可以将其删除
• PR 将一个不足 1000 行的文件扩展到超过 1000 行
• PR 添加了临时分支，使现有流程更加错综复杂
• PR 通过在共享代码中散布功能检查来解决局部问题
• PR 添加了不必要的抽象、包装器或充斥类型转换的契约，让设计更加迂回
• PR 重复已有辅助函数，或在有明确规范归属层的情况下将逻辑放在了错误的层

阻断门槛还有第二个维度（L6 + L8）。 只有同时满足以下两项，结构性／“代码手法”问题才可被推定为 blocker：

1. 已独立重新检查证据（L2/L8）。 你重新打开了当前源代码中确切的 file:line 并确认了问题——没有依赖引用的代码片段或第一遍审查时的记忆。发现项带有非空的 evidence；未经重新检查就提出的问题属于弃权，最多记为 minor／consider，绝不能是 blocker。
2. 已根据 Step-0 基线核验任何保持行为不变的主张（L1/L8）。 如果“这种重构没有代价”的论点无法与 §Step-0 的 baseline（类型检查／测试状态、行数）相符，那么该论点并未完成举证，该问题应降级。与绿色基线矛盾或实际未运行过的 behaviorPreservingProof，只是草率的判定，不能作为 blocker。

这是对 L6 的双向校准：既要防范误报（不要把非缺陷／表面问题／“我觉得这样更整洁”升级为阻止合并的问题），也要防范漏报（不要因为问题“技术上能运行”，就把确实会造成纠缠的回归轻描淡写地列为 consider）。只有在证据充分的情况下，达到可触发且损害可维护性程度的问题才是 blocker；推测性的缺口绝不是 blocker。

若不满足这些条件，请留下明确、可执行的反馈，并推动更清晰的分解。

工作量等级

根据需求调整流程机制（workflow-mode.md §5），并且在 caps 中记录等级以及跳过的审查维度，确保覆盖情况可审计（L7）：

等级	审查维度	完整性检查	并行度	适用情况
low	仅结构和规模，只报告高置信度发现	跳过（记录在案）	行内处理，不拆分任务	极小／机械性差异，文件很少
medium	结构、重复、抽象；优先处理高置信度问题	跳过（记录在案）	行内处理或分几轮检查	常规功能差异
high	所有审查维度	完整（§Completeness 中的每个全局判定器）	流水线式拆分，每批 min(16, cores−2)	实质性／高风险／多文件差异
ultra	所有审查维度，按文件并行拆分（file × lens）	完整	最大受控并发度	大型差异、深入审计、“找出所有问题”

low／medium 会有意牺牲召回率以提升信号质量——它们会跳过完整性 grep，只报告置信度最高的问题；这种取舍必须在 caps.reason 中注明，不得默默跳过。high 会增加完整的差异外检查。ultra 还会按文件拆分审查维度，使每个 (file, lens) 都成为独立的只读子 Agent，并在唯一的去重关口汇总。

补救措施——委派修复，不要偷偷修改

此技能负责发现并排序问题；不会悄悄重写差异内容。当用户希望应用质量清理措施（或编排器以 --fix 运行）时，将排名靠前的 findings 交给 /simplify——这个配套技能会在工作树中应用复用／简化／抽象／分层等补救措施。明确分工：/work-review 产出结构化结论；/simplify 执行其中指出的代码改进。若要在处理 blocker 前验证某项具体的行为保持声明，请通过 ../work-refute/SKILL.md 并采用视角多样的审视方式（L3）。

示例（简明起见）

一个包含 2 个文件的差异：upload-handler.ts（+140/−12，920 → 1,048 行）和 tenant.ts（+8/−0）。

1. 步骤 0——git diff --numstat + wc -l 证明 upload-handler.ts 已超过 1k 行（crosses1k:true）；类型检查 + 测试 → pass。记录在 baseline 中。
2. 审视视角（upload-handler，高级别）——structural 标记出一段新加到认证路径上的 if (req.query.hostname) 分支（即 Output Contract 中的示例问题）；size 确认超过 1k 行是由同一代码块导致；layering 指出，租户逻辑现在位于路由处理程序中，而非 tenant.ts。
3. 障碍合并——三个审视视角发现的是同一个根本问题（lineRange 重叠），因此去重后合并为一个 major／blocker 问题，而不是三个。
4. 完整性检查——在整个仓库中运行 rg 'resolveTenant\|\.tenant'，发现还有两个调用点已经通过会话解析租户 → 主机覆盖分支既冗余，又与现有逻辑不一致。这是差异之外的问题，差异内的审视视角无法发现。
5. 阻断项关卡（L6+L8）——从源文件重新阅读 upload-handler.ts:171（已确认依据），并根据步骤 0 的通过基线核对 behaviorPreservingProof → 将问题提升为 blocker。verdict: "request-changes"；一个 minor 问题（变量被遮蔽）移至 droppedTail。将补救措施交给 /simplify。