Back to Details

merge-risk

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Output format:
**Merge risk: <low-medium-high>**

**<category>:** <verdict>
<list gaps that increase risk. Use bullets, keep succinct. Include links to relevant files as needed>

<...list all categories>
These are the categories and verdicts that affect risk, with descriptions of what "low risk" means:
  • Alignment (poor ⚠️ / decent 👀 / good ✅): Code aligns with the description and source issue, when present. Behavior assumptions and drive-bys must be documented.
  • Impact (large ⚠️ / medium 👀 / small ✅): Scope is contained and away from sensitive code paths.
    • Consider blast radius: potential impact or scope of the changes introduced by this PR. Consider all possibilities. Examples are layout shift, breakages for consumers, mobile responsiveness, etc.
    • Sensitive areas carry outsized risk regardless of diff size: auth, permissions, payments, PII, secrets, data migrations, dependency bumps, and infra or config changes. Flag any that are touched, and call out anything that widens access, weakens validation, or logs sensitive data.
  • Verification (poor ⚠️ / decent 👀 / good ✅): Behavior is verified, where applicable.
    • Changes to the user experience need end-to-end proof as screenshots or recordings. Changes that could meaningfully affect performance need profiling. Prefer before-and-after evidence to standalone proof. When this coverage is lacking, it's a failure.
    • Edge cases must be tested, or documented when they aren't; review the code closely and link the user to relevant code when only documentation is present.
  • Rollback cost (high ⚠️ / medium 👀 / low ✅): The code is reversible once merged. Consider one-way vs. two-way doors. You can walk back through two-way doors, but not one-way doors. A PR that is cheap to roll back is lower risk. Changes that involve destructive actions or hard-to-reverse decisions are one-way doors.
  • Error detection (poor ⚠️ / decent 👀 / good ✅ / N/A ✅): If applicable, critical flows should be monitored; If this breaks in production, someone should find out before users report it. Look for swallowed errors or fallbacks that hide breakage.
Generate a risk score for merging this PR on a scale of low - medium - high.
Verdicts:
  • ⚠️ = 3
  • 👀 = 2
  • ✅ = 1
Weights:
  • Impact = 2x
  • Verification = 2x
  • Rollback cost = 1.5x
  • Error detection = 1x
  • Alignment = 1x
Score = Σ(score × weight) / Σ(weights).
  • low: < 1.5
  • medium: 1.5 – < 2.25
  • high: ≥ 2.25
输出格式：
**合并风险：<低-中-高>**

**<类别>：** <判定>
<列出会增加风险的缺口。使用项目符号，保持简洁。必要时附上相关文件的链接>

<...列出所有类别>
以下是影响风险的类别和判定标准，并说明各评分的含义：
  • 对齐性（差 ⚠️ / 尚可 👀 / 好 ✅）： 代码与描述及来源 issue（如果存在）保持一致。行为假设和顺带修改必须记录在案。
  • 影响（大 ⚠️ / 中 👀 / 小 ✅）： 变更范围受到控制，且不涉及敏感代码路径。
    • 评估 blast radius（影响半径）：PR 引入的变更可能造成的影响或波及范围。考虑所有可能性。例如布局偏移、破坏使用方功能、移动端响应性等。
    • 无论 diff 大小，敏感区域都具有更高的风险：auth、permissions、payments、PII、secrets、data migrations、dependency bumps，以及 infra 或 config changes。标出所有涉及项，并指出任何扩大访问权限、削弱验证或记录敏感数据的问题。
  • 验证（差 ⚠️ / 尚可 👀 / 好 ✅）： 在适用的情况下，行为已得到验证。
    • 对用户体验的变更需要 end-to-end 证明，例如截图或录屏。可能显著影响性能的变更需要 profiling。优先提供 before-and-after 证据，而不是单独的证明。缺少此类覆盖时，应判定为失败。
    • 必须测试 edge cases；如果无法测试，则应记录说明。仔细审查代码；只有在提供文档说明的情况下，才向用户提供相关代码链接。
  • 回滚成本（高 ⚠️ / 中 👀 / 低 ✅）： 合并后代码可以回滚。考虑 one-way door（单向决策）与 two-way door（双向决策）。双向决策可以撤销，但单向决策无法撤销。回滚成本较低的 PR 风险也较低。涉及 destructive actions（破坏性操作）或 hard-to-reverse decisions（难以撤销的决策）的变更属于单向决策。
  • 错误检测（差 ⚠️ / 尚可 👀 / 好 ✅ / N/A ✅）： 在适用的情况下，关键流程应受到监控；如果生产环境发生故障，应有人在用户报告之前发现。查找被吞掉的错误或掩盖故障的 fallback。
为合并此 PR 生成风险评分，评分范围为低至高级别。
判定结果：
  • ⚠️ = 3
  • 👀 = 2
  • ✅ = 1
权重：
  • 影响 = 2x
  • 验证 = 2x
  • 回滚成本 = 1.5x
  • 错误检测 = 1x
  • 对齐性 = 1x
评分 = Σ（评分 × 权重）/ Σ（权重）。
  • 低：< 1.5
  • 中：1.5 – < 2.25
  • 高：≥ 2.25