完了条件チェッカー

概要

「DoDを満たした」という自己申告は人もAIも楽観に振れやすく、レビューで一つずつ突き合わせるのは手間がかかり抜けが出ます。完了主張を機械的に裏取りし、満たせていない項目だけを正直に突きつけることで、未完了のまま「完了」として下流に流れる手戻りを止めます。

効果

• 自己申告の「完了」を項目単位で裏取りし、未充足を漏れなく可視化する。
• 証跡が変更に無い項目と、そもそも機械照合できない曖昧な受入条件を区別し、受入条件の書き方の不備まで指摘する。
• 決定的（同入力→同出力）なので CI に組み込み、未充足ゼロをマージ条件にできる。

インプット

• 「完了」と主張された変更
• 受入条件（DoDチェックリスト）

汎用LLMとの違い

受入条件から証跡（シンボル・ファイル・要件ID）を抽出し変更へ照合する規則・正規化・過検出抑止のカタログが bubo 独自の中核です。汎用LLMに「完了してる？」と聞くと楽観に流れるのに対し、自己申告を排して変更内の証跡だけで決定的に裏取りし、裏取りできない項目を満了と偽らず正直に列挙します。

「全部チェック済み」の申告と、証跡照合の結果

同じPR説明つきの変更・受入条件を done-verifier にそのまま渡した実際の出力です（要約ではありません）。

【PR説明つきの変更】
ギフトカード返金対応 PR

既存の返金APIにギフトカード残高への部分返金機能を追加しました。存在しないカードID・通貨不一致・
二重返金といったエッジケースも洗い出し、単体テストを追加してCIでもgreenを確認しています。
通貨まわりの検証も含め受入条件は全て満たしているので、自信を持ってapproveをお願いします。

diff --git a/src/gift_card_refund.py b/src/gift_card_refund.py
@@ -5,6 +5,23 @@ def get_gift_card_balance(card_id):
     return _lookup_balance(card_id)

+def apply_gift_card_balance_refund(card_id, amount):
+    """Refund the given amount back onto a gift card balance."""
+    balance = _lookup_balance(card_id)
+    if balance is None:
+        raise ValueError("unknown card_id")
+    balance["refunded_amount"] = amount
+    balance["refund_status"] = "gift_card_refunded"
+    _save_balance(balance)
+    return balance
+
+def validate_gift_card_currency(card_id, currency):
+    """Validate that the refund currency matches the card's issuing currency."""
+    raise NotImplementedError("TODO: currency validation pending finance sign-off")
+
 def _lookup_balance(card_id):
     return _db.get(card_id)

【受入条件（DoD）— 提出者は全項目に [x] を付けています】
# 受入条件: ギフトカード返金機能の追加

- [x] `apply_gift_card_balance_refund` が実装されている
- [x] `validate_gift_card_currency` の実装と `tests/test_gift_card_refund.py` によるユニットテスト
- [x] `send_gift_card_refund_notification` が呼び出される
- [x] 二重返金が発生しないこと（同一カードへの返金は一度のみ許可される）

判定結果の比較（集計: done: false / 4項目中 met 1・unmet 3）

# 完了条件の検証結果

## 指摘一覧（3件）

### 1. 受入条件が名指す証跡（シンボル/ファイル/識別子）が変更に現れず、充足を裏取りできない
- 場所: tests/test_gift_card_refund.py
- 直し方: `tests/test_gift_card_refund.py` を変更に含めて実装する（または受入条件の記述と実装の名称を一致させる）
- 指摘ID: `6b2c4a0b749c`（report_outcome で正否・採否を記録できます）

### 2. 受入条件が名指す証跡（シンボル/ファイル/識別子）が変更に現れず、充足を裏取りできない
- 場所: send_gift_card_refund_notification
- 直し方: `send_gift_card_refund_notification` を変更に含めて実装する（または受入条件の記述と実装の名称を一致させる）
- 指摘ID: `6761228afb8b`（report_outcome で正否・採否を記録できます）

### 3. この受入条件は変更テキストから機械照合できる手がかり（シンボル/ファイル/識別子）が無く、充足を裏取りできない
- 場所: 全体
- 直し方: この受入条件に機械検証できる証跡（対象シンボル/ファイル/識別子）を明示する（例 `関数名`・path/to/file.py・REQ-番号）
- 指摘ID: `fab6cd23fb9a`（report_outcome で正否・採否を記録できます）

「全部 [x]・CIもgreen・自信を持ってapprove」と書かれたPRに対して、本ツールは受入条件を1項目ずつに分解し、その条件文が名指している証跡（関数名・ファイルパス・識別子）が変更の中に実在するかだけを機械的に照合します。結果は met 1件・unmet 3件で、「テストファイルが変更に無い」「通知関数が変更に無い」という2件は裏取り不能として、「二重返金が起きないこと」は照合できる手がかりが条件文に無いため unverifiable として、いずれも別立てで返ります。同じ入力なら常に同じ判定・同じ順序で、文面の自信の強さには一切左右されません。

本ツールが見るのは「受入条件が名指す証跡が変更に在るか」です。したがって、証跡が揃っているのに中身の計算が間違っているタイプの欠陥（例: 為替レートの適用方向が逆で上限判定が実質機能しない）は、この方式では met と判定されます。ロジックの正しさの検証はテスト側の道具（test-design / test-oracle-deriver）の役割であり、done-verifier は「申告と証跡の突き合わせ」に特化した機械的チェックとして、これらのテスト側の道具との併用を推奨します。

社外秘のコードを、どう守るか

ワンタイムコードは単回使用・有効期限7日・サーバーに平文保存はしません。発行したトークンは設定ファイルに直書きせず環境変数で参照します。既存のMCP設定がある場合も、壊さず冪等にマージします。

どう申し込み、どうつなぐのか

← QA向けMCPツール一覧へ戻る