Domain 4: Prompt Engineering & Structured Output

以下のコードレビューコメントについて、type を "bug" / "style" / "question" のいずれかに分類してください。

例:
入力: "この関数は null チェックが抜けています。クラッシュします。"
出力: { "type": "bug", "reason": "明示的なクラッシュ条件" }

入力: "この変数名は説明的でないと思います"
出力: { "type": "style", "reason": "命名は実行に影響しない" }

入力: "ここで使われている `O(n^2)` は意図的ですか？"
出力: { "type": "question", "reason": "確認を求めている。バグ確定ではない" }

判断に迷う場合は { "type": "question" } を選んでください。

以下のコード変更について、PR description の "Why" セクションを書いてください。

例:
diff: 「キャッシュ TTL を 60s → 300s に変更」
出力:
{
  "why": "本番のキャッシュヒット率が 40% で、上流 API が rate limit に達する頻度が高い。
          TTL を 5 倍にすることで rate limit エラーを抑える狙い。
          stale データの許容度は事前に PdM と確認済み（本機能は近似値で十分）。"
}

→ 出力例の「現状の数値 / 変更の狙い / 副作用への配慮」の 3 段構成に揃えてください。

以下の SQL クエリ生成コードについて、SQL injection の可能性を判定してください。

✅ 許容例:
const stmt = db.prepare("SELECT * FROM users WHERE id = ?");
stmt.get(userId);
→ { "vulnerable": false, "reason": "prepared statement + bound parameter" }

❌ 問題例:
const query = `SELECT * FROM users WHERE id = ${userId}`;
db.query(query);
→ { "vulnerable": true, "reason": "テンプレートリテラルでユーザー入力を直接埋込" }

❌ 問題例（紛らわしいパターン）:
const query = sql`SELECT * FROM users WHERE id = ${userId}`;
db.execute(query);
→ { "vulnerable": false, "reason": "sql タグ付きテンプレートは parameterized query を生成（要：使用ライブラリの確認）" }

以下の論文から引用文献を抽出してください。

例 A (inline citation):
"...as shown by Smith et al. (2023), the effect is significant..."
→ { "type": "inline", "authors": "Smith et al.", "year": 2023 }

例 B (numbered bibliography):
"...the effect is significant [12]..."
（末尾の References:）"[12] Smith, J. (2023). Title. Journal, 4(2), 100-120."
→ { "type": "numbered", "ref_number": 12, "authors": "Smith, J.", "year": 2023, "title": "Title" }

例 C (footnote):
"...the effect is significant¹..."
（脚注:）"¹ Smith 2023, "Title", Journal 4(2)."
→ { "type": "footnote", "marker": "¹", "authors": "Smith", "year": 2023 }

文書全体を読んでから、上記 3 種類のいずれに該当するかを判定して抽出してください。

以下の障害報告から、影響範囲とダウンタイムを構造化してください。

例:
入力: "ストレージがほぼ満タンの状態で、約 1 時間ほど書き込みが失敗していた。
       影響を受けたユーザーはおおよそ 5,000 人前後"
出力:
{
  "storage_state": { "raw": "ほぼ満タン", "normalized": "near_capacity", "approximate": true },
  "downtime": { "raw": "約 1 時間", "minutes_estimate": 60, "approximate": true },
  "affected_users": { "raw": "おおよそ 5,000 人前後", "count_estimate": 5000, "approximate": true }
}

→ raw（原文ママ）+ normalized（カテゴリ）/ estimate（数値概算）+ approximate フラグの形式に揃えてください。
正確な数値が原文にない場合は approximate: true を必ず付け、estimate は中央値で記録します。

// retry-with-error-feedback パターン
const result = await extractWithSchema(document);
const errors = validateSchema(result);
 
if (errors.length > 0) {
  // ✅ 元のドキュメント + 失敗した抽出結果 + 具体的なエラーを追加して再送
  const retry = await extractWithFeedback({
    document,
    failedExtraction: result,
    validationErrors: errors  // 具体的なエラーが重要
  });
}
// ❌ リトライが効果ない場合：情報がそもそもドキュメントに存在しない
// → 情報不在はフォーマットエラーと違い、リトライで解決しない