running-bug-review-board

运行 Bug Review Board（BRB）QA 测试

此技能会对应用进行一次真实用户 QA 测试，并将结果汇总到 Bug Review Board 中：一个包含结构化 Bug 报告、每轮测试的运行报告、独立 HTML 仪表板，以及团队可据此采取行动的最终 YES/NO 签核结果的文件夹。工程团队使用的跟踪工具（Linear / GitHub / Jira / Notion）会双向同步，让 QA 和工程团队保持步调一致。

此技能将一套经过实战验证的工作流推广开来，该工作流已在 Mokuhoe 上完成阶段 QA——这些方法不依赖特定代码仓库。

为什么需要此技能

大多数工程师都会测试自己编写的代码。他们会确认自己写的功能可以正常运行。 但这会漏掉真实用户最先遇到的 Bug——流程之间的状态过时、移动端溢出、误导性文案、引导流程中途出现 404 的路径，以及身份验证与路由之间的竞态条件。

此技能会模拟真实用户。QA Agent 会扮演一位谨慎、略微挑剔且不会阅读源代码的客户。

两种工作流——Auto QA 和 Interactive BRB

此技能将工作拆分为两种截然不同的模式。它们共享产物，但有意在不同会话中运行：

• Auto QA 测试——Agent 操作应用、运行场景、提交 Bug、生成 HTML 报告并撰写结论。侧重全面性与速度。
• Interactive BRB——由另一个 Agent 与用户一起对待处理 / 进行中 / 已修复的 Bug 进行分类。先执行双向拉取，再应用基于模式的启发式方法来发现重复项和聚类；逐个检查 Bug、切换状态、同步到跟踪工具、重新生成 HTML 并撰写会议纪要。侧重共同判断。

请将两者分开。在 Auto QA 测试中运行 BRB 会让分类过程影响问题发现，并造成归因混乱。参见 references/brb-interactive.md。

三位一体——一轮测试，三种角色

每轮测试都要担任以下三种角色：

• 产品经理。 确认构建版本兑现了产品规格或阶段文档中记录的用户可见承诺。如果没有，那是产品缺口，而不是 Bug——请在运行报告中标出。
• QA。 从真实用户的角度，在主要支持的视口上执行每个场景。收集证据（快照、控制台信息，以及相关情况下的服务器数据）。通过 / 失败 / 受阻。
• 工程师。 留意失效的假设：阶段文档写着“X 使用函数 Y”，但 Y 已重命名；文档称某个流程由服务器驱动，但实际出现了新的客户端编排；界面中存在规格说明里没有的字段。发现缺口才是重点——不要对照有 Bug 的行为反向修改文档，使其看起来一致。

除非用户明确要求，否则不要修复产品代码。进行测试、记录问题、提交 Bug 并交接。

先了解应用（否则你会写出糟糕的测试）

在编写任何测试之前，先了解应用的意图——客户雇用它来完成什么任务。完整的调查指南请参阅 references/discovering-the-app.md。简要来说：

1. 按以下优先顺序阅读产品规格 / README / 落地页 / 推介演示文稿，了解应用承诺提供什么。

2. 阅读阶段文档（或当前迭代计划），了解刚刚构建了什么。

3. 阅读以往的 QA 门禁 / 检查清单，了解之前通过了哪些内容——回归问题是最有价值的发现。

4. 阅读 Bug 报告索引——未解决的 Bug 是必须优先重新测试的场景。

5. 检测项目类型。 一个仓库可能包含多个应用——Web + iOS 单体仓库很常见——因此，只要发现信号，就要收集每个对应的界面，不要在发现第一个后就停止。以下两条消歧规则用于解决单个应用内部的信号重叠；它们不是跳过真正独立界面的理由：

   • 同一应用中，Electron / Tauri 优先于 Web 应用。 Electron / Tauri 项目（package.json 中包含 electron、@electron/、@tauri-apps/，或包含 electron-builder.yml / tauri.conf.json）也会包含 package.json 和 Web 框架依赖，但这些依赖属于桌面应用——只将其计为一个桌面应用，不要再将其另计为独立的 Web 应用。
   • 共享 *.xcodeproj / *.xcworkspace 时区分 macOS 与 iOS。 两者共用普通的 Xcode 项目，因此不能仅凭这一点分类——必须要求存在平台专属标记（如下所示）。

   各类界面及其启用的指南：

   • Electron / Tauri 桌面应用 → 使用 computer-use-playbook.md。（在无法使用 Computer Use 的非 macOS 主机上，指南中的优雅降级表会指引你通过 browser-playbook.md 访问应用的开发服务器 URL。）
   • Web 应用（存在 Web 框架依赖，且没有 Electron / Tauri 标记）→ 使用 browser-playbook.md。
   • iOS / iPadOS 应用（存在 iOS 专属标记——.iOS(...)、platform :ios、UIDeviceFamily 或 ios/ 目录）→ 使用 ios-simulator-playbook.md。
   • 原生 macOS 应用（存在 macOS 专属标记——.macOS(...)、.app 包或 LSMinimumSystemVersion——且没有 iOS 标记）→ 使用 computer-use-playbook.md。
   • 混合项目（单体仓库）——以上两种或更多不同界面都有信号（例如，存在 Web 框架依赖并且有 iOS 标记）→ 运行每个匹配的指南；测试计划需按平台划分场景块。Web 匹配绝不能中断同仓库中 iOS（或 macOS）的测试流程。
   • 其他（没有 UI 信号）→ 不启用 UI 指南。

   还要确认是否可以使用 Codex Computer Use（仅限 macOS）——它能对 Web 应用进行贴近真人操作的测试，也是访问原生 Mac 或 Electron/Tauri 应用的唯一方式。大多数虚拟机（Cursor 云端、CI）都无法使用它，因此测试流程绝不能依赖它。

6. 检测问题跟踪系统（Linear、GitHub、Jira、Notion 或无）。列出发现的所有信号，并在编写 qa-config.json 之前请用户确认。参阅 issue-trackers.md。

7. 列出公开路由 / 界面 / 入口点，并判断真实的新用户会访问哪些。

如果用户说“对这个应用做 QA”，但没有任何文档，请先询问——参阅 references/discovering-the-app.md § Asking the user。

工作流（任何阶段，任何仓库）

1. Scope        → which surface / phase / build
2. Discover     → product intent + recent change + open bugs
                + project type + issue tracker (confirmed)
3. Plan         → manual test plan (scenarios, IDs, expected, gates)
4. Prepare      → env, build, test accounts, viewport / device matrix
5. Mode         → parallel coordinator OR sequential wrap-up
6. Execute      → real-user scenarios with evidence
7. File bugs    → P0/P1/P2 with reproduction steps
8. Merge        → results + verdict (YES/NO + open P0/P1)
9. Generate HTML → apply html-report-style-guide.md
10. Hand off    → next QA agent (if NO) or engineering (if blockers)
11. Schedule BRB → separate session for interactive triage

详见 references/workflow.md。

模式选择器

情况	模式	参考
对某个阶段进行全新、完整的检查，允许使用多 Agent	并行协调器	references/parallel-coordinator.md
对某个阶段进行全新、完整的检查，且已安装 waves / waves-codex skill	并行协调器，以有界波次运行（覆盖率门槛、结构化交接、分层验证、低成本模型分片）	references/parallel-coordinator.md § Run the pass as a wave
先前的并行运行停滞或未完成	顺序收尾	references/sequential-wrapup.md
单个 Agent，范围较小	按从上到下的顺序执行	references/sequential-wrapup.md
工程团队交付后，重新测试 1–3 个已修复的 Bug	顺序执行，仅限 Bug 测试 ID	references/sequential-wrapup.md
需要与用户一起对未解决的 Bug 待办列表进行分类	交互式 BRB（独立会话）	references/brb-interactive.md
仓库是原生 macOS 应用，或你想对真实登录状态的应用进行贴近人工操作的检查	自动检查 + Computer Use 操作手册（macOS）	references/computer-use-playbook.md
仓库是 iOS / iPadOS 应用	自动检查 + iOS 操作手册（使用配套 skill 进行输入）	references/ios-simulator-playbook.md
尚无测试计划	先生成计划	references/test-plan.md
阶段文档列出的功能尚未在代码中实现	停止。告知用户——QA 需要可运行的构建版本	—

界面类型 — 哪些操作手册会生效

在发现步骤中检测。将仓库信号与每种已存在界面类型对应的操作手册匹配——通常只有一种，但单体仓库可能匹配多种（见下文混合类型）。将选择结果记录在 docs/qa/qa-config.json 中，避免后续步骤重复讨论。

界面类型	信号	操作手册
Electron / Tauri 桌面应用 （优先检查——优先于 Web 应用）	package.json 中包含 electron、@electron/ 或 @tauri-apps/；electron-builder.yml；tauri.conf.json	computer-use-playbook.md
Web 应用	package.json 中包含 Web 框架依赖（没有 Electron / Tauri 标记）；app/ / pages/ / src/routes/；Vercel / Netlify / Cloudflare 部署配置	browser-playbook.md（在 Mac 上进行符合人工操作习惯的测试时，增加 Computer Use）
iOS / iPadOS 应用	Package.swift 中包含 .iOS(...)；Podfile 中包含 platform :ios；Info.plist 中包含 UIDeviceFamily；ios/ 目录（单独的 *.xcodeproj / *.xcworkspace 与 macOS 共用，至少需要一个 iOS 专属标记）	ios-simulator-playbook.md
原生 macOS 应用	Package.swift 中包含 .macOS(...)；.app 程序包；Info.plist 中包含 LSMinimumSystemVersion	computer-use-playbook.md
混合类型（单体仓库）	存在上述两种或更多不同界面类型的信号（例如 Web + iOS）——匹配到 Web 不得跳过 iOS / macOS 测试流程	运行所有匹配的操作手册——测试计划将为每个平台分别设置场景块
CLI / 库 / 后端	没有 UI 信号	不使用任何 UI 操作手册；QA 重点关注集成测试和错误路径

对于 iOS 应用 QA，我们的技能负责协调（发现、测试计划、提交 Bug、BRB），并将模拟器操作交由 iOS 社区专门打造的技能处理：AXe（Cameron Cooke）、XcodeBuildMCP（Cameron Cooke / Sentry）、ios-simulator-skill（Conor Luddy）、ios-build-verify（Josh Adams）、baguette（tddworks）、ios-idb-skill（Hao Wu）、serve-sim-skill（malopezr7）、swiftui-autotest-skill（Yusuf Karan）、xcode-build-skill（pzep1），以及用于 TestFlight 交接的 App Store Connect CLI + skills（Rudrank Riyam）。推荐技术栈表请参阅操作手册。

问题跟踪器集成

此技能会发现并确认，绝不自行假定。发现流程会探测信号（LINEAR_API_KEY、gh auth status、Atlassian URL、已注册的 MCP 服务等），并在写入 docs/qa/qa-config.json 之前向用户展示所有发现。确认后，Agent 会在本地提交 Bug，并根据配置同步到跟踪器（提交时或 BRB 时推送），同时拉取工程团队的状态变更（默认在 BRB 开始时启用）。参考文档详细说明了双向协调规则，以便将差异作为待用户决策的变更呈现，而不是静默覆盖。

跟踪器 ID 存储在 Bug 的 front-matter 中——Tracker / Linear、Tracker / GitHub、Tracker / Jira、Tracker / Notion、Tracker / lastSyncedAt。HTML 报告会将它们显示为每张 Bug 卡片上的标签。

辅助脚本： scripts/bugs-needing-sync.sh 会列出缺少跟踪器 ID 的 Bug（待推送项）。 scripts/bugs-needing-pull.sh 会列出 Tracker / lastSyncedAt 已过期的 Bug（待拉取项）。

HTML 报告（Zite + Dieter Rams）

每次测试轮次和每次 BRB 会话结束时，都要按照 html-report-style-guide.md 重新生成 docs/qa/report/index.html，以及每个 Bug 和每次运行的详情页面。

报告读起来应像杂志，而不是看板。排版承担主要表达功能——优先级用小型大写字母显示为 P0，状态用 Open 一词表示，结论用一个展示型字体的词表示（YES 或 NO）。正文只用一种墨色，链接和 CTA 使用一种低调的陶土色作为强调色，用细线分隔。不要使用彩色标签、胶囊标签或阴影。所有屏幕尺寸下，阅读栏宽度均为 640px；在桌面端，Bug 详情页在右侧增加一列低调的元数据。移动端提供一个固定在拇指操作区域的栏，重复显示主要操作，让读者不必滚回顶部。

信息层级专为工程师审查者快速浏览而设计：标题 → 导语 → 影响 → 实际情况 / 预期情况 → 修复风险 → 步骤 → 证据。Bug 模板在 v0.3 中新增了 Impact 和 Risk to fix 两个部分（仅作增补——旧 Bug 即使没有这些部分，也能正常呈现）。

Markdown 始终是唯一事实来源。 HTML 只读，并且会重新生成。切勿通过编辑 HTML 更改 Bug 状态——应编辑 Markdown 并重新生成。利益相关方会在 BRB 和发布评审期间查看仪表板。

基于模式的分诊建议

交互式 BRB 会显示一个建议卡片，其中的建议来自 triage-heuristics.md 中列出的命名启发式规则——相同的疑似文件、步骤前缀重叠、相同的控制台错误、相同的角色 + 界面区域 + 结果、阶段级联、外观问题聚集、回归标记、相同的负责人。每条建议都会注明启发式规则名称及匹配文本，让用户始终能看到标记问题的原因。不使用嵌入向量、LLM API，也不会自动合并。Agent 提出建议；用户做决定。

在自动测试轮次的文件创建阶段，也可以选择启用相同的启发式规则（triage.runHeuristicsOnFile，默认值为 false），这样测试轮次就能询问“新建文件，还是更新 BUG-007？”，而不是重复登记。

缺少脚手架文件夹时创建

如果目标仓库尚无 QA 文件夹结构，请运行随附的脚手架生成器来创建：

bash <skill>/scripts/scaffold-qa.sh "$REPO_ROOT" PHASE_NUM [SLUG]

它会创建以下内容（可幂等执行——不会覆盖现有文件）：

<repo>/docs/qa/
├── README.md                         # how QA works in this repo
├── qa-config.json                    # stub; discovery rewrites once user confirms
├── phase-NN-<slug>-manual-test-plan.md  # filled-in skeleton (if PHASE_NUM given)
├── report/                           # HTML report destination (agent generates)
├── bug-reports/
│   ├── README.md                     # index + status workflow
│   ├── _template.md                  # bug template
│   └── assets/                       # screenshots (incl. ios/ for iOS QA)
└── runs/                             # per-shard + coordinator merges + BRB minutes

如果仓库中已经有其他布局（例如 tests/manual/、 qa/ 或问题跟踪系统），则采用该布局——不要重复创建。

始终遵守

• 从真实用户的角度出发。 操作应用，而不是查看源代码。通过 URL 和点击（或模拟器轻点）进行测试，而不是只检查 convex/users.ts 或 API 层。
• 测试手机、平板和桌面端。 真实用户会使用这三种设备，跳过某个断点可能就会漏掉布局、溢出或点击目标问题。Web 应用要覆盖这三种模式——参考尺寸为 手机 375 × 812、平板 768 × 1024、桌面 1280 × 800（根据规格中的断点调整）。优先测试应用的主要目标：以产品规格为准；如果规格不明确，询问用户最看重哪种模式；如果用户无法联系，则根据你在仓库中发现的内容（响应式 CSS／断点、框架默认值、营销文案）推断最可能的主要目标，并注明这一假设。在 qa-config.json#platforms.web 中记录各模式和选定的主要目标，避免后续测试时重新讨论。对于 iOS 应用，设备矩阵取自 qa-config.json#platforms.ios.devices。
• 每个 Agent 使用一个浏览器标签页。 多个 Agent 共用一个标签页会导致身份验证提供商触发速率限制，并造成会话过期。
• 留存证据。 在故障发生时截取快照或屏幕截图，逐字记录控制台错误，并在相关时记录服务器数据行。
• FAIL 时立即提交缺陷——参见 references/bug-filing.md。不要等到测试结束才提交。
• 遵循测试账号操作指南。 参见 references/test-accounts.md。如果没有相关文档，先询问用户，不要猜测。
• 不同场景之间做好会话清理。 参见 references/session-hygiene.md。过期的存储／Cookie／重复使用 +test 邮箱会悄无声息地污染新用户流程。
• 每个仓库只运行一次问题跟踪器发现流程，参见 issue-trackers.md，然后再提交缺陷。
• 每轮测试和每次 BRB 会话结束时，都重新生成 HTML 报告，遵循 html-report-style-guide.md。
• 对于 iOS 应用 QA，将实际的模拟器操作交给 ios-simulator-playbook.md 中的配套技能；不要自行重新实现启动／轻点／截图流程。

绝不允许

• 仅凭代码检查就将场景标记为 PASS。用户体验的不是源代码，而是应用。
• 没有证据（快照、服务器数据行、干净的控制台）就将阶段门标记为 ☑。
• 未经提示就修复产品代码。记录问题、提交缺陷并交接。
• 跳过阶段文档中的已知问题／延期事项部分——这些内容决定测试范围，并防止误报缺陷。
• 为了符合有缺陷的行为而重命名阶段文档或规格。这会掩盖回归问题。
• 在同一个 cursor-ide-browser 标签页中运行多个 QA 浏览器子 Agent。
• 不更改运行标记后缀就重复使用之前测试失败的邮箱。
• 未经询问就假定使用某个问题跟踪器——即使迹象非常明显。
• 不要在自动 QA 测试的同一会话中运行 Interactive BRB——两者刻意分开，以免分诊偏差影响问题发现。
• 未经询问，不要将仅存在于跟踪器中的缺陷自动导入本地 Markdown（默认值为 pull.createLocalForUntracked: "ask"）。
• 不要自动合并启发式规则判定为重复的缺陷——每次合并／去重都需要用户确认。
• 不要编辑 HTML 来更改缺陷状态。 编辑 Markdown，然后重新生成。
• 不要将 iOS 模拟器操作指南用于 Web 应用 QA。 它只适用于 iOS 应用项目。移动 Web QA 应遵循浏览器操作指南。

缺陷优先级（BRB 分类）

级别	定义	操作
P0	阻断核心流程；数据丢失；绕过身份验证；安全问题	阶段无法发布；暂停 QA 测试，直到完成分诊
P1	功能损坏或行为不正确；存在变通方案	阻止当前阶段通过签核
P2	外观问题、边缘情况、无障碍问题、开发者控制台噪声	推迟到润色阶段或发布加固阶段

如果无法确定是 P0 还是 P1，且用户可能进入无法恢复的状态或丢失数据，则选择 P0。

通过标准（任意阶段）

• 阶段手动测试计划中的所有场景均通过（或在阶段文档中明确标记为延期并说明原因）。
• 阶段门禁／检查清单全部通过。
• 没有针对本阶段尚未解决的 P0 或 P1 Bug。
• 对于涉及身份验证／邀请／通知的阶段：回归矩阵全部通过。

完成定义

每轮测试通过后，协调员都要提交一份合并文档，首行内容为：

Phase N ready? YES — 所有门禁均已通过 ☑，没有尚未解决的 P0/P1。 Phase N ready? NO — 列出尚未解决的 P0/P1 和仍未运行的场景， 并附上一段交接提示，供下一位 QA Agent 使用。

如果结果为 NO，合并文档必须可以直接粘贴到新对话中。 下一位 Agent 无需重新梳理状态。参见 references/gate-merge.md。

同时重新生成并提交 HTML 报告（docs/qa/report/index.html）。

浏览器工具（优先使用 Cursor，按备用梯队降级）

在 Cursor 中运行时，默认使用 cursor-ide-browser MCP。如果会话使用其他工具，或缺少浏览器 MCP，则按 references/browser-playbook.md 中的梯队降级：

1. cursor-ide-browser MCP（Cursor / Claude Code）
2. Chrome DevTools for agents（chrome-devtools-mcp）——自动等待结果，并提供 DevTools 级别的网络／控制台／Lighthouse／a11y 检查；还可连接到你已登录的 Chrome，避免身份验证流程触发机器人检测
3. browser-use MCP（与提供方无关）
4. Playwright（CLI 或 MCP）
5. Codex Computer Use（macOS）——在真实的已登录应用中进行贴近人工操作的测试；参见 computer-use-playbook.md
6. 手动操作，并请用户粘贴控制台错误／截图

无论使用哪种工具，操作手册都相同：导航 → 快照 → 使用最新的引用执行操作 → 收集证据 → 完成后解除锁定。参考文档涵盖每种工具的具体用法，包括如何模拟人工操作，以免应用触发机器人检测或遭遇时序竞争。无论环境中提供什么工具，测试都必须能够完成——不要依赖大多数虚拟机都不具备的 Computer Use。

每轮测试的交付物

路径	内容
docs/qa/qa-config.json	跟踪器 + 分类 + 报告 + 平台配置（发现阶段会重写此存根文件）
docs/qa/phase-NN-<slug>-manual-test-plan.md	（如果是新生成的）
docs/qa/runs/QA-<shard>-run-YYYY-MM-DD.md	每个分片的测试结果
docs/qa/runs/COORDINATOR-MERGE-YYYY-MM-DD.md	合并结果 + 判定
docs/qa/runs/BRB-YYYY-MM-DD.md	（仅限交互式 BRB）会议纪要
docs/qa/bug-reports/BUG-NNN-*.md + assets/BUG-NNN/	每个缺陷
docs/qa/report/index.html + bugs/ + runs/ + assets.css	Apple 风格语言的 HTML 仪表盘
docs/QA_GATES.md（或仓库中的对应文件）	更新门禁复选框
阶段文档 § QA 状态	签署说明 + 合并文档链接
跟踪器工单（Linear / GitHub / …）	如果启用了 syncOnFile，或在 BRB 之后

根据目标仓库现有的路径调整。

参考文档（按需加载）

• references/workflow.md — 完整的 PM/QA/Eng 决策树
• references/discovering-the-app.md — 调查意图；缺少文档时询问用户
• references/test-plan.md — 根据规范、阶段文档和门禁制定阶段手动测试计划
• references/test-accounts.md — Clerk / Auth0 / Supabase / 自定义方案，以及“询问用户”模式
• references/session-hygiene.md — 过期存储、速率限制、角色后缀
• references/browser-playbook.md — cursor-ide-browser、Chrome DevTools MCP、browser-use、Playwright 配方，以及如何像真人一样操作（Web 应用）
• references/computer-use-playbook.md — 使用 Codex Computer Use 操作 Web 和原生 macOS 应用（macOS；其他平台优雅回退到浏览器驱动）
• references/ios-simulator-playbook.md — iOS / iPadOS 应用 QA，精选配套技能梯队（AXe、baguette、XcodeBuildMCP、ios-simulator-skill、ios-build-verify，……）
• references/parallel-coordinator.md — 分片映射、优先处理写入路径的规则、可复制粘贴的分片提示词，以及在安装了 waves / waves-codex 时，如何将测试作为有界波次运行
• references/sequential-wrapup.md — 单 Agent 收尾；可复制粘贴的提示词
• references/bug-filing.md — 缺陷模板、严重程度、证据规则、状态转换
• references/gate-merge.md — 合并分片报告 → 门禁与判定
• references/issue-trackers.md — 发现并确认流程、Linear / GitHub / Jira / Notion 适配器、双向同步
• references/brb-interactive.md — 交互式缺陷评审看板工作流（独立会话）
• references/triage-heuristics.md — 用于检测重复项 / 聚类的命名启发式目录
• references/html-report-style-guide.md — Apple 风格用语、组件、渲染规则
• references/extending-the-skill.md — 添加跟踪器、启发式、界面或模式，无需重写
• references/templates/ — bug-report、test-plan、run-report、coordinator-merge、brb-interactive-prompt、brb-minutes、qa-config.example.json、html-report/ 骨架

脚本

• scripts/scaffold-qa.sh REPO_ROOT PHASE_NUM [SLUG] — 在任意代码库中创建 QA 文件夹布局、qa-config 存根和报告文件夹。
• scripts/bugs-needing-sync.sh REPO_ROOT [--tracker …] — 列出缺少跟踪器 ID 的缺陷；Agent 读取列表，并根据 issue-trackers.md 推送。
• scripts/bugs-needing-pull.sh REPO_ROOT [--threshold 24h] [--tracker …] — 列出 Tracker / lastSyncedAt 已过期的缺陷；Agent 读取列表，并根据 issue-trackers.md 拉取。

扩展此技能

添加新的问题跟踪器、分诊启发式、界面操作手册或模式都只需增补内容 — 复制一个章节并填写，Agent 会在下一次会话中加载。向前兼容的 qa-config.json 架构（version: 1，忽略未知字段）、可增补的缺陷 front-matter、带版本号的 HTML 报告标记。参见 references/extending-the-skill.md。

应避免的反模式

不要	原因
仅凭代码检查就将场景标记为 PASS	用户体验不到源代码
将 P0 错误推迟到“下一阶段”	基础问题会在各处引发连锁反应
不在全新构建上重新运行，就相信之前的 PASS 标记	无关工作也可能引入回归
在同一个浏览器标签页中运行多个 QA Agent	身份验证提供商会限流；会话会相互干扰
修改阶段文档以匹配有问题的行为	这会掩盖回归——应改为提交错误报告
提交错误报告时不写明复现步骤	工程团队无法据此采取行动
只测试理想路径	工程师已经测试过理想路径
在同一会话中运行 BRB 和自动检查	分类偏差会污染问题发现
未填写 qa-config.json 就将错误同步到跟踪器	可能产生重复项并丢失编辑内容
使用 iOS 操作手册在 Mobile Safari 中测试 Web 应用	超出范围；iOS 操作手册仅适用于 iOS 应用项目
自动合并启发式建议	每项去重都需要用户确认
将跟踪器中独有的错误自动导入为本地 Markdown	工程团队可能是在 QA 不应认领的上下文中提交这些错误
编辑 HTML 以更改错误状态	Markdown 才是事实来源；HTML 应重新生成

QA 检查发现超出 QA 范围的工作时

如果在检查过程中发现：

• 阶段声称存在但实际缺失的功能（完全没有对应的代码路径）
• 多个场景中的架构都偏离了规范
• 某个 P0 问题阻塞了所有剩余场景

停止测试。说明发现的问题。由用户决定是升级给工程团队处理，还是拆分出一个更小的阶段。继续测试会浪费时间，因为需要替换的是底层基础。