triaging-visual-review-runs

分流视觉审查运行

Visual Review 是 PostHog 的截图回归产品：CI 会捕获 Storybook + Playwright 截图， 将它们与已提交的基线哈希进行比较，并在每个已更改的快照都得到处理前阻止 PR 通过。 包含视觉变更的 PR 会带有 visual-review GitHub 状态检查，以及必需的“视觉回归测试通过”作业检查。 在每个有差异的快照都经过批准并最终确认、容忍或隔离，且作业重新运行前，这两项检查都会保持红色： 批准后由 finalize 完成此操作；容忍和隔离则由 recompute-create 完成。VR UI 提供相同的操作。 来自 fork 的 PR 是例外：它完全不会触发 Visual Review 运行。 请参阅 Fork PR 不会触发 Visual Review 运行。

本技能通过串联 VR MCP 工具，教会 Agent 如何回答人类审查者真正会问的问题，而不是使用 gh pr view 再在 VR 网页 UI 之间来回切换。读取工具涵盖状态／范围／历史／分流。Agent 可以自行处理不稳定测试，可以选择隔离，或较少见地选择容忍。 但它不能自行提交视觉变更：finalize-create 会提交基线，并且需要针对每次运行获得明确的人类确认。

先做判断

使用差异是真实的还是无关的？和不稳定检查：此 story 最近有变更吗？收集证据， 然后为每个已更改的快照选择第一个符合条件的行。

证据	操作	是否需要人工确认
PR 来自分支仓库（isCrossRepository: true）	仅报告。请参阅 分支仓库 PR	无法执行 VR 写入操作
差异来自你的更改，且符合预期	approve-create，然后请求 finalize	每次运行都需要，在 finalize 之前
差异来自你的更改，但不符合预期	修复代码并推送。不执行 VR 写入操作	否
你的更改使隔离的故事渲染为 changed 或 new，且符合预期	对该标识符执行 approve-create，然后请求 finalize。如果该更改也修复了不稳定问题，请在批准后添加 lift-on-merge-create。请参阅 隔离的故事	每次运行都需要，在 finalize 之前
你的更改修复了某个隔离故事的不稳定问题，且该故事渲染为 unchanged	对该标识符执行 lift-on-merge-create。请参阅 隔离的故事	否
更改范围之外的故事，不稳定记录为 unstable，hard_count ≥ 5，且 last_flaked_at 在最近 7 天内	执行 quarantine-create，然后执行 recompute-create。报告该情况	否
更改范围之外的故事，不稳定记录为 broken	不要隔离。默认分支上的基线有误。报告该情况并建议重新建立基线	是
更改范围之外的故事，历史记录平静，宽度和高度相同，change_kind: pixel，且你能指出噪声来源	执行 tolerate-create，然后执行 recompute-create	否
其他任何情况：unstable 但失败次数较少、看起来像真实变化但并非由你造成、无法确定	停止操作并报告你看到的情况	是
每个主题都是独立的标识符。
分别判断故事的 --light 和 --dark 快照，只隔离符合条件的快照。

容忍项应当很少。 差异比较已经过滤了阈值以下的大多数真实渲染噪声，而较小的差异百分比往往代表真实的结构变化。 容忍项会永久接受一个精确的哈希值，且无法通过 API 撤销，因此绝不能用它来绕过门禁。 如果某个故事每次运行的渲染结果都不同，并且符合上面的隔离条件，就应将其隔离，这也能保护其他所有开发者。证据不足时，请改为报告问题。

本次运行中被隔离的故事

隔离会让故事的差异不显示在门禁和 PR 评论中，因此绿色检查并不代表你的更改没有影响被隔离的故事。 每次运行选中该故事时，仍会渲染并比较其差异。PR 运行只会渲染其差异所影响的故事。 检查每次涉及 UI 的更改运行。 使用以下命令列出更改过的隔离快照： posthog:visual-review-runs-snapshots-list { id: <run_id>, include_quarantined: true, exclude_unchanged: true }。 使用 exclude_unchanged 时，quarantined_count 只统计已更改的快照。 列表采用分页，且不会优先显示被隔离的条目，因此请持续跟进 next，直到读完所有条目。

• 如果你的更改让某个被隔离的故事渲染出了不同结果，就需要按标识符批准其新图片，然后再完成定稿。 “全部批准”和 approve_all 会跳过被隔离的快照。 如果不批准，默认分支会保留旧条目；隔离解除或到期当天，每次运行都会失败。
• 如果你的更改没有影响某个被隔离的故事，它仍可能显示为 changed，因为它存在不稳定问题。请保留现状，不要批准。 批准会将该故事重新设为本次运行所渲染的结果，这可能是不稳定的图片，也可能是修复前的图片；该故事待处理的解除隔离请求随后会在基线检查中失败。
• 修复不稳定问题后，单次运行中 VR 看不到任何变化，因此该故事会渲染为 unchanged，并被上面的列表排除。 对修复应解除隔离的每个标识符，使用 posthog:visual-review-runs-lift-on-merge-create { id: <run_id>, identifier: <identifier> } 记录修复，并在 PR 描述中注明这些标识符。 只有在 PR 合并，且默认分支上包含此次合并的运行针对匹配条目渲染出相同图片后，隔离才会解除。 在此之前，隔离会继续生效，除非先到期；posthog:visual-review-runs-quarantine-lifts-list { id: <run_id> } 会显示每个请求的 state 和 detail。
• 删除被隔离的故事会保留其基线条目。 只有完整运行才会将故事标记为 removed，也只有 finalize 才会清理该条目。 run-ci-frontend 标签会在下一次推送或标记为可供审核时生效，而不是添加标签时生效，因此添加标签后请推送，并确认新运行是完整运行。 请在合并前完成该运行的定稿，否则隔离结束后，每次完整运行都会报告该故事已 removed。
• 请求解除隔离绝不会批准图片。对于状态为 changed 或 new 的被隔离快照，请先按标识符批准，否则请求会返回 400。也请完成运行的定稿，以便合并时提交解除隔离所检查的基线条目。
• 一次干净的渲染无法证明罕见的不稳定问题已消失，variant_count: 0 也不能证明这一点，因为它只统计已被吸收的变体。

此技能的适用场景

遇到以下任一情况时，触发此技能：

• PR 编号、分支名称或提交 SHA 与 视觉审查、VR、快照、截图、 storybook 差异、playwright 快照、基线、批准、容忍、隔离 等词语一起出现。
• 询问 PR 为什么被阻止、视觉上有哪些变化，或差异是否真实。
• “我的运行完成了吗？”／“还剩什么需要审查？”／“这个故事最近有过不稳定的情况吗？”
• visual-review GitHub 检查失败，或 posthog-bot 发布了提及视觉审查的 PR 评论。
• 来自 fork 的 PR 上，Visual regression tests pass 检查失败；这是离线回退机制，不是 VR 运行。

当用户询问渲染后的差异图像本身时，VR 网页界面 更快——请引导他们前往该页面。此技能用于处理与差异相关的所有事项：状态、范围、历史记录和分类。

首先，检查 PR 是否来自 fork。 fork PR 没有 Visual Review 运行，因此下方所有针对运行的 VR 工具都不会返回结果。 只有针对仓库的波动性工具仍会返回结果。 查询工具前，先读取该标志：

gh pr view <n> --json isCrossRepository

如果 isCrossRepository 为 true，请在此处停止。 前往 Fork PR 没有 Visual Review 运行。

Fork PR 没有 Visual Review 运行

Visual Review 需要密钥，而 CI 不会向 fork 提供密钥。 因此会跳过 Visual Review 上传。 该 PR 不会有运行记录、快照行或 visual-review 检查。 这是预期行为，并非故障。

相反，每个 Storybook 分片都会在 Verify snapshots against the baseline offline 步骤中离线将自己的截图与已提交的基线文件 frontend/snapshots.yml 进行比较。 如果不匹配，Visual regression tests pass 检查就会失败。

离线回退机制在以下方面弱于 Visual Review，这些差异会影响问题分类：

Visual Review	fork 上的离线回退机制
使用噪声阈值比较差异	仅进行精确像素哈希匹配
识别可容忍的备用哈希	不识别——即使是可容忍的变体也会失败
应用隔离	不应用——即使是已隔离的故事也会失败
在 VR 网页界面中显示渲染后的差异图像	没有图像；作业日志会列出有差异的快照
通过 MCP 工具进行分类和完成处理	不适用任何工具；由维护者更新基线文件

因此，即使没有可见变化，不稳定的故事也可能导致 fork PR 失败。

如何分类 fork PR 的失败：

1. 查看失败的 Visual regression tests pass 作业。 步骤摘要和 Baseline mismatch 错误会列出每个存在差异的快照。 使用 gh run view <run_id> --log-failed 获取日志。
2. 针对列出的标识符，按照差异是真实的，还是无关的？中的范围检查进行检查。 该检查只需要 git diff，因此无需运行记录也能执行。
3. 根据默认分支判断是否存在波动，而不是根据 fork PR 判断。 使用 posthog:visual-review-repos-flakiness-retrieve { id: <repo_id> }，仓库 ID 从 posthog:visual-review-repos-list 获取。 这是唯一仍然有用的 VR 工具，因为它会报告仓库级历史记录，且不需要运行记录。
4. 给出判断结果并停止。 由于没有可供操作的运行记录，你无法批准、容忍或完成处理。 如果必须更改快照，需要维护者在 PR 分支上更新 frontend/snapshots.yml，并在仓库内分支上运行 Visual Review。

切勿将 fork 的 head 推送到仓库内分支来为其创建 Visual Review 运行。 请参阅来自 fork 的拉取请求。

工具

读取工具（可随时安全调用）：

工具	用途
posthog:visual-review-runs-list	列出运行记录，可按 pr_number / commit_sha / branch / review_state 筛选。从这里开始。
posthog:visual-review-runs-retrieve	单次运行记录的完整详情（状态、汇总计数、替代情况）。包含仓库工具所需的 repo_id。
posthog:visual-review-runs-snapshots-list	运行记录中的各快照结果：标识符、result、差异百分比、分类、基线和当前产物 URL。默认排除已隔离的快照（参见 quarantined_count）；传入 include_quarantined=true 可查看这些快照。传入 exclude_unchanged=true 可跳过大型运行记录中数千条未变化的记录。
posthog:visual-review-repos-flakiness-retrieve	渲染结果不可信的仓库快照，每项都包含 flakiness_state 和波动率。波动检查从这里开始。
posthog:visual-review-runs-snapshot-history-list	默认分支上某个故事的基线时间线：每次基线变更占一行。参数为 { id: <run_id>, identifier: <identifier> }。
posthog:visual-review-runs-counts-retrieve	用于队列分类处理的汇总计数（例如处于 needs_review 状态的运行记录数量）。
posthog:visual-review-runs-tolerated-hashes-list	团队明确接受为“已知波动 / 可接受变化”的哈希值。参数与历史工具相同。
posthog:visual-review-repos-list	仓库（每个 GitHub 仓库一项）——通常只需关注一个；可用于筛选。
posthog:visual-review-repos-retrieve	仓库元数据：基线文件路径、PR 评论配置。
posthog:visual-review-repos-quarantine-list	活跃隔离项，包含原因、作者、到期时间和来源运行记录。传入 identifier 可查看其完整历史。
posthog:visual-review-repos-toleration-pileups-retrieve	反复被接受的故事：可考虑修复故事中的问题。
posthog:visual-review-runs-quarantine-lifts-list	当运行记录对应的 PR 合并后，解除隔离的请求，包含 state 和最新检查的 detail。参数为 { id: <run_id> }。
分流工具（它们不会改变基线；只有 recompute-create 之后门禁才会改变，但合并时解除隔离除外：默认分支运行会自行应用解除操作，无需重新计算）：

工具	用途
posthog:visual-review-runs-approve-create	在数据库中将 changed / new 快照标记为已审核（已批准）。不会提交，也不会让门禁转绿——通过 finalize 发布。
posthog:visual-review-runs-tolerate-create	将一个已更改快照的当前哈希作为所有后续运行的备用哈希接受。仅适用于渲染噪声，参见先做判断。无法通过 API 撤销。
posthog:visual-review-repos-quarantine-create	在其过期前（若省略 expires_at，则为 30 天），从每个 PR 的通过或失败结果中移除一种运行类型的一个标识符。使用 quarantine-expire-create 撤销。
posthog:visual-review-repos-quarantine-expire-create	解除隔离，让该故事再次对运行进行门禁检查。
posthog:visual-review-runs-lift-on-merge-create	在该运行对应的 PR 合并后，且默认分支运行使用匹配条目渲染快照图片时，解除隔离。绝不会批准图片。参数为 { id: <run_id>, identifier }。
posthog:visual-review-runs-quarantine-lifts-cancel-create	撤回待处理的合并后解除隔离操作。隔离状态保持不变。参数为 { id: <run_id>, request_id }。
posthog:visual-review-runs-recompute-create	重新统计已完成但尚未 finalize 的运行，发布 visual-review 状态，并重新运行该运行记录的 CI 任务，使必需检查读取新的判定结果。

分支保护要求通过 Visual regression tests pass 和 Playwright tests pass 任务检查，而不是 visual-review 状态。 因此，只有 recompute-create 重新运行该运行记录的 CI 任务后，隔离或容忍操作才会解除 PR 的阻塞。 已批准的更改会让门禁保持红色，直到 finalize 提交这些更改；因此 recompute 绝不会发布已批准的更改。

发布工具（不可逆、面向外部——需要针对每次运行取得明确的人类确认；参见门禁）：

工具	用途
posthog:visual-review-runs-finalize-create	将已批准的基线提交到 PR 分支，并让 GitHub 的 visual-review 检查转绿。此操作会发布更改。

标记为已审核的调用格式（approve-create）：

• id（必填）— 运行 UUID。它是路由参数，因此缺少它时调用会失败。
• snapshots: [{identifier, new_hash}] — new_hash 是每个快照 current_artifact 的 content_hash。这只会在数据库中记录审核状态；不会提交任何内容，门禁也会保持红色，直到你 finalize。

隔离调用格式（quarantine-create）：

• id — 仓库 UUID（本次运行的 repo_id），run_type — 失败运行的 run_type。两者都是路由参数。
• identifier，以及包含证据的 reason，例如“在 master 上不稳定：7 天内默认分支运行失败 7 次，图表动画时序问题；与 PR 1234 无关”。
• source_run_id — 失败的运行。expires_at — 留空表示 30 天，或设置更早的日期，绝不能设置更晚的日期。
• notify_owners: true — 将隔离通知发布到所属团队的 Slack 频道，让负责修复该故事的人知晓。
• 然后对该 PR 中最新的、非过期且 run_type 相同的运行调用 recompute-create { id: <run_id> }，并检查 ci_rerun_triggered。

容忍调用格式 — 两个字段都必填：

• id（必填）— 运行 UUID。这是路由参数，缺少它时调用会失败。
• snapshot_id（必填）— 要容忍的单个快照 UUID（来自 visual-review-runs-snapshots-list）。它用于标识运行中的_哪个_快照；不能替代运行 id。

Finalize 调用格式（finalize-create）— 全有或全无的发布操作：

• id（必填）— 运行 UUID。
• approve_all: true — 在 finalize 前批准所有仍处于待处理状态的 changed/new 快照（已容忍的快照不受影响）。确认所有剩余差异都是预期结果时使用。
• 省略 approve_all（默认值为 false），即可 finalize 已逐个检查快照的运行。Finalize 是全有或全无的操作：除非每个 changed/new 快照都已获批准、已容忍或已隔离，否则操作会失败并返回 409 not_fully_resolved（并列出尚未处理的内容）。
• 它只会提交数据库中已批准的快照 — 已容忍的快照会保留其基线，绝不会被覆盖。推送基线提交时，其 SHA 会返回在运行的 metadata.baseline_commit_sha 中。如果无需提交（所有内容都通过容忍/隔离解决 — finalize 会发布绿色状态，且必需检查会在其任务重新运行时变绿），或者跳过了提交：没有 PR，或因 PR 有更新的提交而返回 409 sha_mismatch（这种情况会让门禁继续显示红色 — 在最新提交上重新运行 CI，然后再次 finalize），则该字段不会出现。

如果 finalize 失败并返回 409 stale_run，说明该运行已被更新的运行取代 — 调用 visual-review-runs-list { pr_number } 并 finalize 最新的运行。成功的 finalize 通常会触发一次新的 CI 运行，这是正常情况。

Finalize 门禁

Finalize 是此技能中唯一不可逆且会影响外部的操作：它会改写提交到 PR 的基线，并让合并门禁变绿。请将其视同向他人的分支推送 — 绝不能自动执行。

在调用任何 finalize-create 之前，必须满足以下所有条件：

1. 你已验证差异。 你已获取当前 PNG（对于 changed，还包括基线 PNG）并检查过；对任何可疑项运行了 flake 检查，并逐个快照给出了判定。仅凭元数据永远不够。
2. 你已展示判定并等待。 按快照向用户说明发生了哪些变化以及你的建议，然后停下。
3. 用户已明确批准_本次_运行。 宽泛的“让门禁变绿”或“修复 PR”只是允许你调查并给出建议 — 并不代表允许 finalize。如果任务意味着要 finalize，但用户没有针对这次具体运行明确表示同意，就应询问。

当 先做判断 允许时，approve-create、tolerate-create、quarantine-create 和 recompute-create 不需要经过此门禁。 如果你即将调用 finalize-create，却无法指出用户针对本次运行明确说过的“同意”，就停下并询问。

词汇速查表

这些内容会出现在工具输出中，理解时很重要：

• 运行的 review_state：needs_review（已开启，等待人工审核）、clean（没有差异）、processing（CI 仍在上传）、 stale（同一 PR 上有更新的运行取代了此运行——请检查 superseded_by_id）。
• 运行的 run_type：storybook（组件快照）或 playwright（全页面 E2E 快照）。
• 快照的 result：unchanged、changed（真实差异）、new（尚无基线）、removed。
• 快照的 classification_reason：tolerated_hash（与已知可容忍的哈希匹配，无需操作）、 below_threshold（低于噪声阈值）、exact（字节完全一致）、""（需要审核的真实差异）。
• 快照的 review_state：pending 或 approved。
• 运行的 summary：total / changed / new / removed / unchanged / unresolved / tolerated_matched — unresolved 是实际阻碍审核的项目数。

工作流

“这个 PR 的 VR 状态是什么？”

最常见的任务。通过两次调用，将 PR 编号对应到其运行状态。 首先确认该 PR 并非来自 fork。 Fork PR 没有运行记录，visual-review-runs-list 对其会返回空列表。

1. posthog:visual-review-runs-list { pr_number: <n>, limit: 5 } — 按 created_at 降序排序，取最新的非过期运行。
2. 如果运行的 summary.changed > 0 或 summary.unresolved > 0，则进一步查看： posthog:visual-review-runs-snapshots-list { id: <run_id>, exclude_unchanged: true }，并报告 changed 快照。

请反馈：PR 编号、运行 UUID、review_state、摘要计数，以及 _posthogUrl 深层链接，方便用户直接点击打开差异查看器。

“差异是真实的，还是无关的？”

这是了解代码的 Agent 能做出的最有用判断。结合三项信号：范围匹配情况、波动历史和实际渲染的图像。Agent 应查看截图，而不只是描述元数据。

1. 检查范围 — 运行 git diff master...HEAD --stat（或与 PR 的目标分支比较）→ 列出修改过的路径。 将其与 posthog:visual-review-runs-snapshots-list { id, exclude_unchanged: true } 交叉核对，并筛选 result: changed → 获取 story 标识符。 Story 的命名格式为 <area>-<scene>--<story>--<theme>；例如，scenes-app-settings-user--settings-user-profile--dark 对应 frontend/src/scenes/settings/user/...。用它将 story id 对应到可能的源代码路径。

2. 视觉检查 — 对于每张 changed 快照，工具结果都包含 current_artifact.download_url 和 baseline_artifact.download_url。这些是指向 PNG 文件的预签名 S3 URL；下载并查看：

   curl -s -o /tmp/vr-baseline.png "<baseline_artifact.download_url>"
   curl -s -o /tmp/vr-current.png "<current_artifact.download_url>"
   

   然后用 Read 读取两个文件（Read 工具会以视觉方式渲染图像）并进行比较。需要指出：

   • 实际可见的差异（文本变化、按钮移动、布局偏移、颜色偏差、元素缺失）。
   • 差异是否与元数据中的 diff_pixel_count 和 diff_percentage 一致 （例如，差异达到 54%，但图像看起来几乎相同 → 变化的是截图取景，而不是 UI）。
   • 基线与当前图像的尺寸（width / height 字段）是否不同。尺寸不匹配通常意味着 story 在不同的视口中渲染，或截图时尚未完成渲染——这是波动信号，而非回归，也绝不是可以容忍的渲染噪声。
   • change_kind：pixel 表示零散的像素噪声，structural 表示感知上的变化。较小的差异百分比往往也可能代表真实的结构性变化。

3. 波动历史 — 对任何看起来可疑的 story，运行下面的波动检查。

4. 结论 — 综合以上三项：

   • 范围合理，且可见回归与代码变更相符 → 差异是真实的，建议批准。
   • 范围不匹配，且该 story 在默认分支上存在波动 → 按照 先做判断 将其隔离。
   • 范围合理，但可见回归看起来并非预期 → 推送修复；不要批准。

务必用一句话描述你在图像中看到的内容——用户会据此判断是否信任你的结论，而不必亲自打开 VR UI。

Flake 检查：“这个故事一直在变化吗？”

从 visual-review-runs-snapshots-list 获取可疑的快照行后，分别问两个问题。

这个故事是否不稳定？ 只有易波动性概览能回答这个问题。通过 posthog:visual-review-runs-retrieve { id: <run_id> } 读取 repo id。然后调用 posthog:visual-review-repos-flakiness-retrieve { id: <repo_id> }，并找到 identifier 和 run_type 与快照匹配的条目。该条目包含易波动性信号：

• flakiness_state：broken、unstable、at_risk 或 clean。
• hard_rate 和 hard_count：近期默认分支运行中未通过门禁的比例和次数。 last_flaked_at：最近一次此类运行的时间。
• soft_rate：被容忍机制吸收的比例。
• window_runs：用于计算这些比率的仓库默认分支运行次数。它对同一 run_type 的所有条目都相同，与故事本身无关。

只有当响应中的 truncated: false 时，没有条目的故事才表示情况正常。 如果 truncated: true，缺失的故事可能处于任何状态，因此不能据此得出结论。 不要仅凭缺少条目就进行容忍或隔离：请检查 visual-review-runs-tolerated-hashes-list 和快照历史，或报告此情况。

基线是否发生了变化？ 调用 posthog:visual-review-runs-snapshot-history-list { id: <run_id>, identifier: <identifier> }。它会为默认分支上的 每次基线转换返回一行，而不是逐次运行结果列表。它会排除功能分支，并且会合并使用相同基线的连续运行。 因此，你不能用它来统计运行结果。

两个参数都是必需的。请从快照行中复制：将其中的 run_id 放入 id，将 identifier 放入 identifier。快照自身的 id 不是运行 id，传入后调用会失败。 visual-review-runs-tolerated-hashes-list 也需要相同的两个参数。

判断：

• flakiness_state 为 clean，或故事在未截断的列表中没有条目 → 很可能是此 PR 导致的真实回归。
• flakiness_state 为 unstable，且 hard_count ≥ 5、last_flaked_at 时间较近 → 故事存在易波动性；应将其隔离。 一次失败就足以判定为 unstable，而单次失败往往是已合并的真实变更，因此应以次数为准。
• flakiness_state 为 broken → 基线有误，而不是故事有问题。不要隔离；建议重新设定基线。
• at_risk 永远不会导致运行失败，因此 PR 无需采取行动。
• 最近出现 removed、维度发生大幅跳变，或基线很久以前才最后变动 → 基线可能已过时；建议在 master 上重新设定基线。

队列分流

当用户是在做日常维护，而不是询问某个具体 PR 时：

1. posthog:visual-review-runs-counts-retrieve → 队列总数。
2. posthog:visual-review-runs-list { review_state: needs_review, limit: 50 }（如有需要，翻页）。
3. 按 branch 作者或 run_type 分组，找出集中的问题（例如，“12 个 PR 都被同一个共享组件变更阻塞”通常意味着需要解决一个共同的根本原因）。
4. 优先展示 summary.changed > 0 的运行，而不是只有 new 的运行——new 表示尚无基线，通常很容易批准；changed 才是真正需要审查的工作。
5. 解除过期隔离：visual-review-repos-flakiness-retrieve 中 needs_decision: true 的条目已不再失败或即将过期。只有当它在观察时段内没有硬性失败，或合并的修复已消除原因时，才使用 posthog:visual-review-repos-quarantine-expire-create { id, run_type, identifier } 解除隔离。 解除隔离前，请确认默认分支当前渲染的故事与该条目一致。 使用包含该修复的提交中、与该隔离项 run_type 相同的最新已完成默认分支运行，并通过 include_quarantined: true, exclude_unchanged: true 列出变更的快照，然后按 next 继续。 只有当该故事在多次此类运行中都不在列表里时，才解除隔离。罕见的波动问题大多数时候都能正常渲染，因此一次正常运行还不够；待处理的运行或其他 run_type 的运行也不能证明任何事情。 单凭 broken 状态不能作出判断。该状态覆盖 7 天，因此修复合入后的数天内仍会保持 broken。 如果该故事仍在列表中，请先确认近期的默认分支运行渲染出了相同的变更图像，再重新建立基线。 同一个有波动问题的故事只出现一次变更渲染，说明这是一次波动；重新建立基线只会改变失败的变体。此时应保留隔离。 如果连续多次运行都出现相同图像，请先重新建立基线（README 的隔离章节介绍了操作步骤），再解除隔离。 如果隔离项处于这种情况，请在过期日期之前报告，因为过期操作会导致运行以同样的方式失败。

输出要求

对于 PR 状态问题，先用一行给出结论，再列出 2-4 条支持信息。始终包含指向该运行的 _posthogUrl 深层链接——人需要查看渲染图像才能作出判断，而 Agent 只能描述元数据。

对于分流或汇总问题，简短的表格比文字说明更合适。请按用户接下来要采取的行动分组。

注意事项

• 不要为了通过门禁而容忍问题，也不要隔离由你自己的变更造成的差异或 broken 条目。
• 不要把绿色门禁视为你的变更没有影响已隔离故事的证明。请参阅已隔离的故事。
• 不要假设 PR 上失败的 GitHub 检查与 VR 无关——如果你正在处理的 PR 上 visual-review 检查显示红色，就应该运行此技能。
• 不要将 fork PR 上空的运行列表视为运行损坏或待处理。 请先检查 isCrossRepository，然后对离线检查进行分流。
• 当 result: changed 时，不要仅凭元数据作出结论。请获取基线和当前 PNG 并检查；元数据只能说明“有内容发生了变化”，不能说明这种变化是否符合预期。