| id | suppression-feedback |
| name | Suppression Feedback Workflow |
| description | Riverbed Memory の suppression entry を活用するときの判断基準と CLI 操作を案内する。 |
| version | 0.1.0 |
| category | midstream |
| phase | midstream |
| applyTo | ["src/**/*.{ts,tsx,js,jsx,mjs,cjs}","app/**/*.{ts,tsx,js,jsx,mjs}","lib/**/*.{ts,tsx,js,jsx,mjs,cjs}","packages/**/*.{ts,tsx,js,jsx,mjs,cjs}"] |
| inputContext | ["diff","commitMessage"] |
| outputKind | ["findings","actions"] |
| modelHint | balanced |
| tags | ["suppression","process","midstream","riverbed-memory"] |
| severity | minor |
| dependencies | ["code_search"] |
Pattern declaration
Primary pattern: Reviewer
Secondary patterns: Tool Wrapper
Why: 検出された major / critical 指摘について、suppression 登録か追加修正かの判断を促し、CLI 操作を案内する educator スキル。
Goal / 目的
- 検出された指摘が (a) 真の修正対象 / (b) accepted_risk として記録すべき / (c) false positive として記録すべき / (d) 別 fingerprint との duplicate のいずれかをレビュアー(人間または AI)が判断できるようにする。
- 重大度別の suppression ポリシー (
major / critical は accepted_risk でないと auto-suppress されない HIGH_SEVERITY guard) を浸透させる。
river suppression add CLI の正しい使い方と、Riverbed Memory への登録フローを案内する。
Guidance
feedbackType の使い分け
| feedbackType | 想定状況 | major / critical の挙動 |
|---|
accepted_risk | リスクを認識した上で残すと決めた指摘 | HIGH_SEVERITY guard を通過する唯一の値。auto-suppress 可。 |
false_positive | 実装意図に対する誤検知 | guard でブロック。manual handle のみ。 |
wont_fix | 修正しないと決めた既知問題 | guard でブロック。 |
not_relevant | この PR / ファイルの文脈外 | guard でブロック。 |
duplicate | 別 fingerprint への参照 | guard でブロック。duplicateOfFingerprint で参照先を示す。 |
CLI 操作
river suppression add \
--fingerprint <fp> \
--feedback <accepted_risk | false_positive | wont_fix | not_relevant | duplicate> \
--rationale "なぜ suppress するかを 1〜2 文で" \
[--scope <pattern>] [--severity <level>] [--files <glob>] \
[--expires <ISO date>] [--pr <num>]
--rationale は必須かつ未来の自分への説明であるべき。"why this is OK" を残す。
--expires を付けると一時的 suppression を作れる。ライブラリ移行待ちなど時限のあるケースで活用。
--pr を付けると suppression と PR の対応が Riverbed Memory に残り、後続レビューで duplicate 判定が容易になる。
レビュー時の判断フロー
- fingerprint で既存 suppression を検索 → 既知なら
duplicate で参照
- 指摘内容を実装意図と照らす → 誤検知なら
false_positive を提案
- 修正コストを見積もる → "リスク認識して残す" 妥当性があれば