---
name: deviation-comment
description: Coverity の逸脱コメント（トリアージのコメント）の書き方と、Classification / Action / Severity の選び方。逸脱案を作るときに使う。ほかのスキルとサブエージェントが読む手順書で、人が直接頼むものではない。
---

# 逸脱コメントの書き方

逸脱コメントは、**この警告がどんな状況でも問題にならないこと**を述べる文章です。Coverity に登録され、あとから読む人が「直さなくてよい理由」として使います。

## 書き方

- **日本語**で、**見出しを付けない 1〜2 文**で書く。**200 字以内**（スクリプトが確かめます）。
- 次をこの順に入れる。
  1. **判定区分**（必須）：「誤検知。」「意図的。」など、文の先頭に置く。
  2. **問題にならない理由**（必須）：なぜ問題にならないのかを、条件を付けずに言い切る。
  3. **コードの根拠の場所**：理由を裏づける関数名とファイル・行（例 `read_all()（src/io/reader.c:120）`）。

## 例

> 誤検知。get_buf() の戻り値は NULL になりうるが、呼び出し元 read_all()（src/io/reader.c:120）で NULL を除いてから渡しているため、NULL を参照することはない。

> 意図的。case 2 から case 3 へのフォールスルーは、状態 2 の処理のあと状態 3 の処理を続けて行う設計（src/fsm.c:88 のコメントに記載）であり、break の書き忘れではない。

## 書かないこと

逸脱コメントには、問題にならない理由だけを書きます。次は書きません（必要なら結果ファイルの `verdict.rationale` か `confidence_reason` に書く）。

- 条件や但し書き：「ただし〜の場合に限る」「〜を確認した場合は」「〜に対して」
- 調べた過程や、調べきれなかったこと：解析リビジョンが分からない、警告の説明とコードが合わない、再解析が必要 など
- 推奨や、人への依頼：「修正を推奨」「確認してください」

## 言い切れないとき

条件を付けないと「問題にならない」と書けないなら、それは問題になりうるということです。その場合は**推奨を修正**にします（`recommendation` を `fix`）。逸脱案は形として作り、言える範囲の理由だけを短く書きます。

- 本物のバグ（`true_bug`）でも、今は動作に影響しない理由がコードで示せるなら、それを書く（例「本物の不具合。ただし、この機能は今の製品では無効（config.h:12）で、この処理は実行されない。」）。示せなければ、推奨は修正にする。

## 注意

- プロジェクトの知識（`knowledge.md`）に「逸脱コメントの書き方」があれば、それに従う。
- 根拠の場所は、調べて実際に読んだ場所だけを書く。確かめていない場所を推測で書かない。

## Classification / Action / Severity の選び方

逸脱案（`deviation`）の目安です。値は Coverity Connect に設定されている選択肢の名前で書きます。

| 判定 | Classification | Action | Severity |
|---|---|---|---|
| 誤検知 | False Positive | Ignore | Unspecified |
| 意図的 | Intentional | Ignore | Unspecified |
| 本物のバグだが直さない | Bug | Ignore | 影響に応じて Major / Moderate / Minor |

修正案（`fix`）の目安：Classification は `Bug`、Action は `Fix Required`、Severity は影響に応じて選ぶ。

社内で使っている選択肢が違うときは、この表を社内の値に書き換えてください。