adr_omission_report — ADR-0180 月次レポート | BizLinkPartners 社内ドキュメント

.github/workflows/adr-omission-detect.yml の月次 cron / workflow_dispatch が生成する「Triage 到達前の ADR 起案漏れ検知」レポートを YYYY-MM 単位で永続化する dir。

生成物

YYYY-MM.md — 月次レポート本体。workflow が cron / workflow_dispatch 実行時に自動 commit する。
README.md (本 file) — 手順とレポート様式の SSoT。

レポート様式 (workflow が生成する `YYYY-MM.md` の構造)

---
type: ops-report
adr: ADR-0180
run_id: <GH Actions run id>
generated_at: <ISO8601>
month: YYYY-MM
model_hint: <gemini-flash | 他>
---

# ADR 起案漏れ検知 YYYY-MM

## サマリ

| 項目 | 値 |
|---|---|
| scan_target_total (git log 全行数) | N |
| processed_prs (実処理数) | N |
| excluded.adr_change | N |
| excluded.draft_adr | N |
| excluded.auto_sync | N |
| excluded.deps_bump | N |
| judged_prs (LLM 判定数) | N |
| needs_adr_count (ADR-worthy 候補) | **N** |
| llm_errors | N |

## 実質捕捉数 (ADR-0180 §9 KPI 1 · 盲点 4 対応)

**実質捕捉数 = needs_adr_count × precision**

precision = 月末の目視レビューで「実際 ADR 化すべきだった」と認めた候補 / needs_adr_count

- 目視で判定した precision: `_(手動入力: 0.0-1.0)_`
- 実質捕捉数: `_(自動計算: needs_adr_count × precision)_`
- 半年累計目標: 3 件以上 (§9 KPI 4)

## 候補 PR (needs_adr = true)

<workflow が JSON から candidates を抜粋して表を貼る>

## 目視レビューの記録

- レビュー日: `_(手動入力)_`
- レビュー実施者: `_(手動入力)_`
- 起案候補として `/intake` に投入した PR: `_(手動入力: PR 番号列挙)_`
- false positive として却下した PR: `_(手動入力: PR 番号 + 却下理由)_`

目視レビューの運用

月初 (毎月 1 日 09:00 JST) に cron が YYYY-MM.md を自動生成 · commit
レビュー担当は該当月中に本 file の「目視レビューの記録」節を手動記入 · commit
起案候補は /intake に生テキストを投入して通常 ADR Pipeline に流す
false positive が多い場合は §8 撤退条件 1 (LLM 判定安定性) を評価

mini app UI 経由の GT 記入 (recommended · ADR-0180 refined_by)

markdown を直接手編集する運用に代えて、drp Workers 上の mini app UI で候補評価を行える (drp/src/adr_eval/ · PR #4153 skeleton / #4170 Phase 2 本実装)。

URL

本番: https://drp.bizlp.dev/adr-eval/{YYYY-MM} (= 月次判定 UI · 代表取締役 email · Cloudflare Access 経由)
例: https://drp.bizlp.dev/adr-eval/2026-07

手順

代表取締役 email で browser access
§3 (needs_adr=true 候補) · §4 (needs_adr=false 候補) の table で各行に mode dropdown / needs_adr checkbox / 却下理由 (needs_adr=false 時) を入力
行ごとに「保存」button で KV バッファへ書き込み (行単位の progressive save · KV loss しても markdown SSoT は無傷)
上部の metrics card で precision / Light 検出数 / TP·FP·FN·TN を即時確認
全件記入後、下部の「export → PR 起票」button で KV → labeling md 反映 + GitHub 上に export PR を起票 (drp session が review + merge)
export PR merge 後、frontmatter gt_status: pending → completed に更新 (代表取締役)

有効化 (初回のみ)

wrangler secret put ADR_EVAL_ENABLED true (drp/ で実行)
wrangler secret put GITHUB_PAT_ADR_EVAL <PAT> (scope: repo)
PAT rotation: 月次 (draft §6.2 リスク)

撤退条件 (draft §8 継承)

記入時間 > 25 分 (50 件基準) が 2 ヶ月連続
KV loss が 3 ヶ月に 1 回以上
GitHub API rate limit 超過
drp workers CPU time 制限超過が 2 週間継続
撤退時: /adr-eval endpoint 削除 · KV namespace purge · markdown 版に運用戻す

撤退条件監視

以下は本 dir の履歴で監視する:

§8-1: false positive 率 > 50% が 1 ヶ月以上継続 → 直近 3 月分のレポートで確認
§8-2: LLM コスト > $50/月 → run artifact のトークン数集計で確認
§8-3: 検知件数ゼロが 3 ヶ月継続 → 直近 3 月分の needs_adr_count で確認 (cron 無音失敗と区別するため adr-omission-detect-failure label の Issue 履歴も参照)

生成物

レポート様式 (workflow が生成する YYYY-MM.md の構造)