QA Loop vs GStack QA vs Incident Investigate

浏览器 QA 需要闭环时它最合适——找出 bug、提修复方案、验证修复、留下证据。qa-loop 偏向给干系人交证据，gstack-qa 偏向在同一个会话里把修复 ship 出去。在前端重构和视觉回归这两类场景上最强。截图数据风险和 qa-loop 一样——别对着有登录态的生产会话跑，截图本身就会变成泄漏面。

Best when browser QA needs to close the loop — find the bug, propose the fix, verify the fix, leave evidence. Where qa-loop emphasizes evidence trails for stakeholder reporting, gstack-qa emphasizes shipping the fix in the same session. Strongest on frontend refactors and visual regressions. Same screenshot data-risk caveat as qa-loop: don't point it at authenticated production sessions where the screenshot itself becomes a leak.

在那种「第一反应反而是错的」事故里它最有用。强制走「证据—假设—验证—再动手」的顺序：先收集日志，列出候选假设，逐个验证，最后才提修复方案。只要救下一次本该用「重启就好」掩盖掉的真实数据完整性问题，回报就够了。但纯样式回归就别用它了，等回滚比慢思考更划算。

Best for incidents where the fastest reflex would be the wrong fix. Forces an evidence-before-action loop: collect logs, list candidate hypotheses, verify each, only then propose a change. Pays for itself the moment it catches the kind of incident where "just restart it" would have masked a real data-integrity problem. Skip it for obviously cosmetic regressions — the cost of slowing down outweighs the cost of a re-deploy there.