name trust-audit description security / correctness tool(linter, scanner, verifier)の出力が信頼を獲得・維持できる設計かを
監査する方法論。false-positive economics、Indeterminate verdict、audit-first rollout、
suppression の使い勝手、FP feedback loop を採点する。trust-calibrator agent が使用。
Trigger: 信頼設計 監査, false positive 監査, FP economics, verdict 設計, audit-first, suppression, linter 疲労.
user-invocable false
監査の前提
正しさを売るツールでは、信頼が通貨。false positive は false negative より採用に致命的 : 1 件の誤検知が「狼少年」を生み、以降の全 finding が無視される(linter 疲労)。TTFV を超えて到達したユーザーが「価値を信用し続ける確率」を、出力設計が決める。
多くのツールは binary pass/fail を強制し、証拠不足の場面で嘘をつく 。信頼設計とは、この嘘をつかない仕組みを持つこと。
監査ステップ
1. verdict モデルを見る(嘘をつかない設計)
出力が binary(pass/fail)か、それとも証拠不足を表現できる中間状態を持つか。証拠が無いのに「合格」と言うのは嘘であり、信頼を毀損する。
libverify を監査
verdict 分類: `Satisfied / Violated / Indeterminate / Not Applicable`(README, crates の registry/assessment)。
`Indeterminate` = 証拠不足を正直に表明する状態。`Not Applicable` = 対象外を明示。
binary を強制せず4値を持つ → 嘘をつかない設計 → 強い。
profile が verdict を pass/review/fail に写像(gate 判断は別レイヤ)→ 判定と gate の分離も良い。
2. rollout の勾配を見る(信頼を稼いでから gate へ)
初回からいきなり enforce(CI を落とす)だと、最初の FP で見捨てられる。報告のみ → 信頼獲得 → gate、の勾配があるか。
gh-verify
`--audit` モード = 報告するが CI を落とさない(main.rs の after_help, README Adoption Path)。
Adoption Path: Evaluate(--audit)→ Tune(--policy/--exclude)→ Enforce(--audit 外す)→ Scale。
信頼を稼いでから gate に移る勾配が明示 → 強い。
3. 誤検知の出口を見る(suppression の使い勝手)
FP が出たとき、ユーザーがそれを安全に・局所的に黙らせられるか。出口が無いと1件の FP がツール全体の放棄に直結する。
gh-verify
`--exclude ` で個別 control を抑制、`--policy oss` で OSS 向けに緩和(main.rs の CommonOpts, conflicts_with で exclude/only 排他)。
誤検知を全体放棄でなく局所抑制に変換 → 強い。
4. FP feedback loop を見る
FP rate を観測・分類して potency を継続的に上げる機構があるか(real-world 検証、TP/FP 分類、policy/adapter/control 層での修正ループ)。
スコアリング・ルーブリック (0-10)
スコア 状態 0-2 binary pass/fail のみ。証拠不足でも断定。suppression 無し。FP で即全放棄を招く 3-5 binary だが exclude はある。audit モード無し。FP 計測なし 6-7 Indeterminate 相当の中間状態 or audit-first、どちらか + suppression 8-9 中間 verdict + audit-first rollout + 局所 suppression を満たす 10 上記全て + FP feedback loop で potency を継続改善。判定と gate を分離
出力 finding を持たない純ライブラリ等は Not Applicable(スコアを捏造しない)。
出力フォーマット
_workspace/02_trust_calibrator.md に:
# Trust Audit: <repo >
## スコア: N/10 — <一言根拠>
## verdict モデル
<binary か中間状態を持つか > ## rollout 勾配
<audit-first の有無 、adoption path > ## suppression
<誤検知の局所的出口>
## FP feedback loop
<計測・分類・修正の機構>
## 信頼リスクと提案
| Severity | リスク | 位置 | 提案 |
|----------|--------|------|------|
アンチパターン(減点対象)
パターン なぜ減点 証拠不足でも binary 断定 嘘 = 信頼毀損 いきなり enforce(audit モード無し) 最初の FP で見捨てられる suppression が無い/全体 off のみ 1件の FP がツール全放棄に直結 FP rate を計測しない potency が改善しない、信頼が下がり続ける 判定と gate が密結合 ユーザーが厳しさを調整できない
