review-as-json

以 JSON 格式审查

对这项更改运行 /review，并严格遵循其要求。

将结果输出为单个 JSON 对象，而不是文字报告：

{
  "verdict": "approve | changes_needed | hold",
  "summary": "One or two sentences on the change overall.",
  "findings": [
    {
      "severity": "critical | warning | info",
      "type": "issue | suggestion | question",
      "category": "mission | architecture | implementation | craft | security | performance",
      "title": "Short imperative, e.g. 'Sanitize user input before query'",
      "description": "What it is, why it matters, and the consequence.",
      "file": "path/to/file.ts",
      "line": 42,
      "suggestedFix": "Optional concrete fix."
    }
  ],
  "passes": {
    "mission": "met | missing | different | unclear",
    "architecture": "ok | concern | blocking",
    "implementation": "ok | concern | blocking",
    "craft": "ok | concern | blocking",
    "security": "ok | concern | blocking",
    "performance": "ok | concern | blocking"
  },
  "sectionSummaries": {
    "mustFix": "1-2 sentences on the critical findings, if any.",
    "shouldFix": "1-2 sentences on the warnings, if any.",
    "questions": "1-2 sentences on the questions, if any.",
    "suggestions": "1-2 sentences on the suggestions, if any."
  }
}

输出规则：

• 只输出 JSON 对象。不要添加前言、评论或 Markdown 代码围栏。
• 严重程度。 critical 会阻止合并（漏洞、安全漏洞、数据丢失）。warning 应予以处理，但不会阻止合并。info 是备注。
• 摘要。 不要重述结论（“此 PR 已获批准”“请求更改”）——呈现层会显示这些内容。摘要应说明原因。
• sectionSummaries。 说明主题本身（“新增端点均缺少输入验证”），不要只统计发现项的数量。
• 类型。 question 表示需要得到答复，而不是缺陷。suggestion 表示可选的改进。其他所有情况都是 issue。
• 类别。 每条发现的 category 都是发现它的审查阶段——CI 输出会按此显示各阶段的结果。
• 标记前先验证仍然适用。每条发现都必须提供具体的文件、行号和后果。如果无法验证，请将其设为 question。
• 如果没有发现，请输出空的 findings 数组，并将结论设为 approve。