ユースケース
コードレビューのリスク
セキュリティ確認なしにマージすべきでない diff をフラグします。
問題
レビュアーは流し読みします。「デバッグ用にパスワードをログ出力」するコメントが金曜日に出荷されます。
回答に対してコードが行うこと
`ship` が低いか、リスクが最上位バケットにあるときはマージをブロックします。
どのマージでも払う価値のある 2 つの質問
diff が state です。ship はセキュリティレビューなしでマージできるかを尋ね（はい／いいえ）、risk は Cosmetic → Needs follow-up → Blocks the merge にわたって重大度を段階付けます。サンプルの diff — パスワードのハッシュを自作の XOR ヘルパーに置き換え、"デバッグ用" に平文をログ出力 — は典型例です：risk はマージブロック圏まで上昇し、ship は低く読めます。CI チェックが動くのはこれです。
レビュアーが求めるチェック
CI からすべての PR で呼びます：ship が自分のライン未満か、risk が最上位バケットならブロック。中間は静かにコメントし、それ以外は通します。ブロックする型付きの呼び出しは 1 クレジットでレビュアーの注意を節約し、さもなければ金曜に出荷される「急いで作った diff」を捕捉します。ゲートを入れる前に、マージ履歴の実際の diff 5 件で Playground から検証してください — 生成された proto やロックファイルの更新は、ゲートを入れる前に除外パスが必要です。
マージゲート特有の落とし穴
ゲートは diff を読むのであって、周囲のシステムを読むのではありません — 単体では安全でも組み合わせで破滅的な変更（レート制限の削除が別の保留中 PR と出会う）には、その文脈を state に入れるか、人をループに入れる必要があります。ゲートが確信を持てない diff を黙って通すことは決して許さないこと：揺れているスコアは沈黙ではなくコメントを得ます。"safe to merge" の criteria の文言は実際のマージポリシーと一致していなければなりません — auth のパスが常にレビューを要するなら、そう書いてください。
リクエストの形状
これは、このプリセットについて Playground が送る完全なリクエストです — 自分のサーバーが Bearer キー付きで /v1/systemone に送るのと同じ JSON です。
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "diff: replace password hashing with a custom XOR \"encrypt\" helper and log the plaintext password \"for debugging\".",
"questions": {
"ship": {
"type": "noul",
"instructions": "Is this change safe to merge without a security review?"
},
"risk": {
"type": "score",
"instructions": "How severe is the security impact?",
"criteria": [
"Cosmetic",
"Needs follow-up",
"Blocks the merge"
]
}
}
}'このユースケースに関する FAQ
- 生成コードの誤検知はどうですか？
- criteria を引き締めるか、呼び出しの前に CI でそのパスを除外します。うるさいのが 1 パスなら設定の修正、モデル全体なら criteria の書き直しです。
- これはセキュリティ上の保証ですか？
- いいえ — トリアージのシグナルです。セキュリティレビューの代わりにはなりません。人間がレビューのコストを払う前に、そのレビューが必要かどうかを決めるものです。
- 小さな diff でも実行しますか？
- はい。安くて速いので — ただし、出自が明白な機械生成の diff は除外します。ゲートはリスクのある変更を読むのであって、既知のロボットを振り分けるのではありません。