work-refute

/work-refute — 反証トーナメント

このスキルは、敵対的検証の品質パターンを実装します。 ../work-tournament/SKILL.md （並行した作成＋選定）の破壊的な兄弟スキルであり、 ../work/references/workflow-mode.mdにあるハーネスの検証段階です。 ../work/references/anti-error-lessons.mdの 教訓 L1、L2、L3、L5、L6、L7、L8 を実践します。

ワークフローの形 — このスキルは主張を処理するパイプラインです

一連の主張を検証するのは、バリアではなくパイプラインです。各主張の 反証者グループは独立して実行されます。主張間にバリアはありません。 主張 B の反証者がまだ調査中でも、主張 A はすでに投票され、報告されている場合があります。 経過時間は、各主張の反証者グループのうち最も遅いものによって決まり、主張全体の合計ではありません。

• 1つの主張の中では、N 人の反証者が並行して展開され、生存投票では小規模な主張ごとのバリアが設けられます（その主張の反証者だけを待ってから投票します）。バリアはこれだけで、局所的なものです。
• 結果を報告する前に、バッチ全体にバリアを設けて（「すべての主張の反証者を待つ」）、はいけません。これは誤ったバリアです（workflow-mode §1 を参照）。各主張の判定は、その主張のグループが解決した時点ですぐに出してください。
• 攻撃の観点の数が不明な場合は、オプションで外側にLOOP モードを適用できます（下記のループモードに関する注記を参照）。生き残った主張に対して、問題が見つからなくなるまでラウンドごとに再攻撃します。単一パスのデフォルトは純粋なパイプラインです。

なぜ PARALLEL/BARRIER ではないのか：バリアが正当化されるのは、項目間に実際の依存関係（重複排除／マージ、ゼロ件での早期終了、全候補の順位付け）がある場合だけです。主張 B の検証は主張 A の判定に依存しないため、バリアを設ける理由はありません。

基本理念（元の手法より）

単一のエージェント（または1回のレビュー）では、確証バイアスが生じます。「これはバグだ」「これが根本原因だ」「この設計は安全だ」という仮説を立てた後は、自然とそれを裏付ける証拠を探してしまいます。

敵対的検証では、立証責任を逆転させます。

• 明示的な役割を確認ではなく反証とする、独立した検証者を起動します。
• 「少しでも疑いがあり、その疑いを裏付けるために調査したのであれば、反証と判定する。」
• 主張が生き残るのは、以下の証拠を重視した生存ルールを通過した場合に限られます。 単純な3票中2票の多数決ではありません。引用されたソースを実際に再読した判定だけを数えます。中身のない、または手抜きの判定は棄権として扱い（除外して記録します。L8）、1つの確信度が高く十分な証拠のある反証が、手抜きの「疑いなし」という生存判定2つを覆すこともあります。
• セキュリティ／認証／マルチテナンシー／データ整合性／正確性に関する主張では、視点の多様性をデフォルトとします。反証者ごとに異なる観点を自動で選び、任意設定にはしません（L3）。同一の反証者を使うのは冗長化であり、多様化ではありません。

ルール #1 — まず直接的なオラクルを使う（必須、L1）： コマンド、テスト、型チェック、git の差分、完全一致検索、ビルド、または同様のオラクルを実行して決定的に検証できる主張であれば、まず直接検証を行います。これは、何人のエージェントに投票させるよりも、厳密に優れています（より低コストで、より速く、より信頼性が高い）。オラクルは結果をゲートし、フェイルクローズで動作します。反証者によって生き残った主張でも、利用可能なオラクルを実行していない場合は、まだ「完了」ではありません。報告する前にオラクルを実行してください。

敵対的検証は、次のような確率的／主観的／判断を要する主張にのみ使用します。

• 「これは実際のバグである」
• 「これが根本原因である」
• 「この変更は意図として安全／高性能／正確である」
• 「この設計は代替案より優れている」

使用方法

/work-refute [N] "the claim or finding to attack"

オプション（組み合わせて使用できます）：

• /work-refute 5 "the claim" — 検証者を5人使用します（デフォルトは3人です）
• /work-refute lenses=correção,segurança,reproduz "claim" — 明示的な観点を指定し、異なる視点から検証します
• /work-refute "claim" --direct-first（デフォルトの動作です）
• 既存の指摘に絞る場合：/work-refute the 4 findings from my last review

メインエージェントが候補をすでに抽出している場合は、構造化された入力（指摘のリスト）を渡すこともできます。

判断表（スキルに組み込み済み）

主張の種類	最初に使用する手法
コマンド／テスト／型／git で検証可能	直接検証（実行して結果を確認する）
コード／設計／原因に関する判断	敵対的検証（独立した検証者 N 人）
さまざまな形で失敗する可能性がある	多角的な視点からの検証（異なる観点）
サイズが不明な集合（X をすべて見つける）	work-exhaust（K 回連続で結果が空になるまで繰り返す）

このスキルは、コストの高い検証者を起動する前に、必ず直接検証の手順を試みます。

スキルの仕組み（オーケストレーション）

1. 主張を分類する

   • エージェントがすでに利用できるツール（シェルコマンドの実行、grep、ファイルの読み取り、git コマンド、ビルド／テストなど）で確認できる、明確な事実の主張ですか？
   • はいの場合 → まず直接確認を実施します。結果を確定した事実として記録します。

2. 判断を要する内容または主観的な内容の場合（またはユーザーが敵対的モードを明示的に要求した場合）

   • N を決定します（デフォルトは3で、ユーザーは2～7に変更できます）。同時実行数の上限と予算（実行の仕組みを参照）を守ります。N を減らす必要がある場合は、そのことを記録します（上限を黙って適用しない）。
   • モードを決定します：
     • セキュリティ／認証／マルチテナンシー／データ整合性／正確性に関する主張（L3）では、多角的な視点からの検証がデフォルトです。異なる観点を自動的に選択します。ユーザーが観点を指定する必要はありません。分離／認証に関する主張で標準的な観点は、次のとおりです： 偽造／なりすまし、設定またはレルムの混同（テナントの誤り／共有された発行者／環境の誤り）、別のコードパス（別の経路から同じシンクに到達する）、下流への影響（ここで確認されたバグが、後で何を破損させるか）。該当する場合は、リグレッションと仕様／AGENTS.md との整合性も追加します。
     • 冗長化（影響の小さい、単一の失敗モードを持つ主張に限る）：強力な「反証」プロンプトを使う検証者 N 人に、それぞれ完全に独立したコンテキストを与えます。
     • ユーザーが観点を明示した場合は、そのまま使用します（例：lenses="correção funcional, injection / secrets, reproduz no runtime?"）。

3. 真に独立した反証担当者を起動する — 反証担当者ごとにサブエージェントを起動します。真の並列処理のため、1 つのメッセージで複数を起動し、適切なサブエージェントの役割（general-purpose）を割り当て、バックグラウンドで実行します。反証担当者がファイルを変更する場合に限り、隔離された worktree で実行します（読み取り専用の反証担当者に worktree は不要です）。各担当者に渡すのは主張の生データ＋最小限のコンテキストのみです。メインエージェントや他の反証担当者の推論は決して渡しません。調査に必要なすべてのツール（コードの読み取り、コマンドの実行、Git 履歴の確認）を使用できます。

   • 各サブエージェントには、以下の3 つの必須条項を含む厳格な反証担当者のペルソナを設定します（これらは譲れない条件です。無視した反証担当者は、投票時に棄権として扱います）。

     あなたは敵対的な懐疑論者です。あなたの唯一の役割は、主張に反証することです。その主張があなたを欺こうとしていると想定してください。礼儀正しく振る舞わず、好意的に解釈しないでください。

     • （L2 — 自分でソースを読み直す。） 主張が引用するすべての file:line を再度開き、現在実際に確認できる行を引用してください。主張が引用した証拠を決して信用せず、最新のソースで確認してください。reReadSources に読み直した箇所を正確に列挙してください。
     • （L3 — 独自の視点。） [LENS] の視点だけから主張に反論してください（例：偽造／なりすまし、設定またはレルムの混同、別のコードパス、下流への影響）。他の視点に範囲を広げないでください。それらは別の反証担当者が担当します。
     • （L8 — 実際に調査した場合にのみ反証として数える。） refuted: true が有効なのは、コードを読み直し、指定された観点を実際に試し、具体的な file:line の証拠を示した場合に限ります。調査していない場合は workDone: false と refuted: false を設定してください。「問題なさそう／疑わしい点はない」といった安易な回答は、反証への生存票ではなく棄権です。「生存」とする場合も同じ基準が適用され、証拠のない空疎な生存票も棄権です。

     （スキーマを参照して）構造化 JSON の契約に従って返してください。severity （critical|high|medium|low）は、雰囲気ではなく実際に確認された現実世界での影響（L6）に基づいて設定してください。

4. 判定を収集して検証する

   • 各反証担当者は、以下の構造化 I/O 契約に適合する fenced json ブロックを出力します。形式を検証し、不正な形式の応答には1 回だけ再依頼します。それでも不正な形式の場合は、受け入れずに除外して記録します（文章だけの回答を黙って受け入れないでください）。

5. 証拠を重視した生存ルール（単純な 3 票中 2 票の多数決に代わるもの）

   1. まず棄権を除外します。 判定が数えられるのは、workDone === true かつ reReadSources が空でなく、具体的な evidence（file:line ＋引用）が含まれる場合に限ります。それ以外（応答なし／エラーの反証担当者（null）、安易な「問題なさそう」、証拠のない「疑わしい点はない」など）は棄権です。除外し、その内容を記録してください（どの反証担当者か、どの視点か、理由）（L8 ＋ null の処理）。
   2. 生存側の閾値を再計算します。 残った判定のうち、数えられるものが k 件（全 N 件中）の場合、生存の閾値は N ではなく、k の過半数です。再計算の内容を記録してください（N=3 → 1 dropped → vote over k=2, need ≥2 survive）。反証担当者が 1 人応答しなかった場合でも、それを反証票または生存票として扱ってはなりません（L7、上限到達を黙って扱わない）。
   3. 票数ではなく証拠を重視します。 confidence:"high"、workDone:true、再現可能な file:line に基づく反論を伴う refuted:true が1 票だけでも、証拠のない refuted:false が 2 票ある場合より重く扱い、主張は反証済みとします。逆に、安易な反証で十分に裏付けられた主張を退けないでください。
   4. 判定の対応付け： confirmed_bug / refuted / survives / needs_oracle（数えられる反証担当者が、決着には決定的なチェックだけが必要だと判断した場合 → 最終報告の前にルール #1 に従ってオラクルを実行します）。
   • 生存した場合の攻撃も含め、すべての反論を保持してください。ユーザーにとって貴重な情報です。

6. 投票後：オラクルゲート、網羅性、キャリブレーション（省略しないでください）

   • オラクルゲート（L1、フェイルクローズ）： オラクルが利用可能なのに未実行の生存項目があれば、 今すぐ実行します。オラクルが失敗した場合は判定を覆します。
   • 網羅性の引き継ぎ（L5）： 生存項目のセットを ../work-gaps/SKILL.md に渡し、 **「どのコードパス／モダリティに対して、反証者が攻撃を行わなかったのか？」**と文字どおり尋ねます。さらに、リストに一度も載らなかった主張やパスを見つけるため、グローバルオラクルを1つ実行します （リポジトリ全体でコアエンティティを grep する、スコープカバレッジの差分を取る、など）。
   • 重大度のキャリブレーション（L6）： 各 severity を検証済みの実世界での影響に照らして再評価し、 どちらの誤りも防ぎます。見た目だけ、または開発時のみの項目を critical/high に引き上げないでください（偽陽性）。悪用可能で到達可能な項目を low のままにしないでください（偽陰性）。high 以上には、具体的な到達可能性の論拠が必要です。

7. 結果を返す

   • survivors[]（オラクル実行後の、防御の根拠となった証拠を含めます）。
   • refuted[] ＋ 最も強力な攻撃と、その file:line。
   • abstentions[] ＋ 各項目を除外した理由（透明性、L7/L8）。
   • 観点を分けて実行した場合は、観点ごとの内訳を示します。
   • work-gaps の「未確認のパス」に関する注記と、明確な推奨事項。

構造化 I/O コントラクト

各反証者は、指定の形式に一致するフェンス付き json ブロックで返信を終えます。呼び出し元はこれを解析して検証します（形式が不正な場合は1回だけ再リクエストし、その後は破棄して記録します）。これは ../work/references/workflow-mode.md §4 に記載された規約の、スキルごとの適用例です。

{
  "claimId": "host-param-storage",
  "lens": "config-or-realm confusion",
  "verdict": "confirmed_bug",
  "refuted": true,
  "severity": "high",
  "confidence": "high",
  "workDone": true,
  "reReadSources": [
    "src/http/routes/upload-handler.ts:171",
    "src/auth/middleware.ts:88",
    "docs/adr/tenant-isolation.md"
  ],
  "evidence": [
    "upload-handler.ts:171 — storage tenant taken from ?hostname, post-auth, no session binding",
    "middleware.ts:88 — issuer check shared across realms, does not pin tenant"
  ],
  "attack": "An authenticated tenant A can pass ?hostname=tenantB and read tenant B storage; the issuer check does not close it because the realm is shared.",
  "scenario": "Repro: login as A, GET /upload?hostname=tenantB → B's objects listed."
}

フィールド	型／列挙値	必須	教訓
claimId	string	はい	—
lens	string	観点を分ける場合は必須	L3
verdict	confirmed_bug | refuted | survives | needs_oracle	はい	L1、L6
refuted	boolean	はい	—
severity	critical | high | medium | low	はい	L6
confidence	high | medium | low	はい	—
workDone	boolean	はい	L8
reReadSources	string[]（実際に再度開いた file:line）	はい（空でない場合にカウント）	L2／L8
evidence	string[]（file:line ＋短い引用）	カウントするには必須	L2
attack	string（最も強力な反証）	refuted の場合は必須	—
scenario	string（具体的な再現手順／悪用できない理由）	推奨	L6

workDone:false または reReadSources が空 または evidence が空の場合、その判定は棄権として扱われ、投票には加わりません（ステップ5.1で除外して記録します）。

実行の仕組み

これらはパイプラインの信頼性を高めます。workflow-mode §3 と同じ内容です。再導出しないでください。

• null の処理（反証担当の無効化）： null／エラー／タイムアウト／棄権した反証担当は除外されます（.filter(Boolean) と 5.1 の棄権フィルター）。反証にも、生き残りにも決して数えません。フィルタリング後、残ったものを対象に生存しきい値を再計算し、除外をログに記録します（名前付きの行で記録します）。 （refuter#2 (lens=alternative-code-path) dropped: workDone=false → vote over k=2）。
• 同時実行数の上限： 反証担当は ~min(16, cores−2) の制御されたウェーブで起動します。複数のクレームを含むパイプライン全体で上限を共有します。上限を超えるクレームの反証グループはキューに入れ、すべてを一度に実行しないでください。
• 予算の把握： 予算が少なくなったら、N を明示的に減らすか、起動を停止します。パネルを暗黙に縮小してはいけません。
• 暗黙の上限設定禁止（L7）： 反証担当が要求数より少ない場合、レンズを実行しなかった場合、予算の都合でクレームを保留した場合、オラクルなしで生き残りを報告した場合など、あらゆる縮小について、判断記録に名前付きの行を記載し、さらにハーネスの todo／plan ツールを通じて表面化させてください。読み手が「問題なく完了」と「打ち切り」を区別できる必要があります。
• ワークツリーの分離： ファイルを変更する反証担当のみ、分離されたワークツリーで実行します。読み取り専用の反証担当には必要ありません。
• ジャーナリング（長時間実行／ループ実行）： quality-journals/<task-id>.json（エージェントのデータディレクトリ配下）に { phasesDone[], seen[], anglesUsed[], survivors[], droppedDueToCaps[] } を書き込みます。再開時は seen[] を読み込み、決してリセットしないでください。そうすることで、反証されたクレームが再び入り込まず、使い切ったレンズも再実行されません。

例：証拠に基づく生存判定の実践

クレーム：「認証ミドルウェアの発行者チェックで防げるため、?hostname によるストレージの上書きは安全です。」 観点の多様性を確保し、N=3、自動選定されたレンズを使用します。

反証担当	レンズ	workDone	reReadSources	判定
#1	偽造／なりすまし	true	auth.ts:40	survives（発行者チェックによりトークン偽造を防げる）
#2	設定とレルムの混同	true	upload-handler.ts:171、middleware.ts:88、tenant-isolation ADR	confirmed_bug、severity:high、confidence:high
#3	代替コードパス	false	[]	「問題なさそうです。疑問点はありません」

単純に 2 対 1 の多数決を取ると、クレームは生き残り、実在するマルチテナントのバグ（anti-error-lessons §「the case」での根拠となる事例）を見逃します。

証拠に基づくルール：

1. フィルタリング： #3 は棄権（workDone:false、reReadSources が空）なので、除外してログに記録します。判定数は k=2 です。
2. 再計算とログ記録： N=3 → 1 dropped → vote over k=2。
3. 重み付け： #2 は、確信度が高く、ソースを再読し、file:line の証拠を伴う反証です。#1 の単独の生存判定よりも重みがあります → 判定 = confirmed_bug、重大度 high。
4. オラクルゲート／完全性： work-gaps に渡します。「どの経路を、どの反証担当も攻撃しなかったか？」と問いかけることで、ストレージ一覧表示経路が明らかになります。重大度は（到達可能＋被害あり＋未カバー）という根拠に基づき、high に再設定されます。

プロンプトテンプレート（内部で使用）

まず直接検証する（該当する場合は常に試みる）： 「エージェントによる投票の前に、これを決定的に判断できるか確認してください。明らかなコマンドの実行、テスト、git のチェック、型チェック、検索を行ってください。環境から明確な yes/no を得られる場合は、それを実行し、正確なコマンドと出力を添えて結果を報告してください。」

反証プロンプト（この手法の核心 — 3つの必須条項を含む）： 「この主張を容赦なく反証してください。：「[CLAIM]」

厳格なルール：

• あなたは敵対的な懐疑論者です。あなたの使命は主張を検証することではなく、破壊することです。礼儀正しく振る舞わず、好意的に解釈しないでください。
• （L2 — 自分でソースを読み直す。） 引用されたすべての ファイル:行を再度開き、今確認できる実際の最新の行を引用してください。主張によって提示された証拠は決して信用しないでください。読み直したものを reReadSources に列挙してください。
• （L3 — 独自の視点を持つ。） [LENS] の視点だけから攻撃してください。他の反証担当者が残りの視点をカバーします。
• （L8 — 作業をした場合に限り、反証は有効。） refuted: true が有効なのは、コードを読み直し、指定された視点から検討し、ファイル:行 形式の証拠を示した場合だけです。作業をしていない場合は workDone: false と refuted: false にしてください。「問題なさそう／疑いなし」という中身のない回答は、生存への投票ではなく、棄権です。
• 実際に検証された影響（L6）に基づいて severity（critical|high|medium|low）を定義してください。
• 回答の最後に、契約のフィールド（claimId、lens、verdict、refuted、severity、confidence、workDone、reReadSources、evidence、attack、scenario）を含む json ブロックを付けてください。」

[LENS] の欄には、各反証担当者ごとに、自動選択された異なる視点（ステップ 2）が入ります。

ループモードの注記（生存者の集合に対して、枯渇するまで実行）

攻撃の切り口の数が不明な場合は、単一パスのパイプラインを ../work-exhaust/SKILL.md のループで囲み、各ラウンドで生存者を新しい視点から再攻撃してください。

• ジャーナル内で、すでに試した主張 × 視点の組み合わせを永続的な seen/attacked セットとして維持してください。各ラウンドでは、現在の生存者ではなく seen と照合して重複を除外してください（L4）。生存者との照合で重複を除外すると、すでに却下された攻撃の切り口が再び現れ、ループが収束しません。
• 新たな反証も新たに攻撃した切り口もゼロとなる静穏ラウンドが K 回連続したら停止してください（K≥2）。これは枯渇による終了です。seen が唯一の正とする情報源であり、再開時にも決してリセットしません。
• 誤った枯渇判定を防いでください：視点が尽きても、主張が尽きたわけではありません。試した視点で静穏ラウンドになっても、主張が安全だとは証明されません。証明するのは、静穏ラウンドと網羅性ゲート（L5）の両方だけです。

既存スキルとの連携

• ../work-tournament/SKILL.md の兄弟スキル／発展形（並列で独立した試行を行い、選択するもの）です。調整に使う用語（サブエージェントを起動する、隔離された worktree を用意する、バックグラウンドで実行する、すべての完了を待つ、結果を収集する）は共通ですが、作成ではなく破壊を目的とします。
• ../work-check/SKILL.md（トレースのレビュー＋状態の直接検証＋厳格な PASS/FAIL）です。強化された work-check 検証ツールは、適切な場合に優れた反証担当者になります。実装後の純粋なコード変更検証には、まず /work-check を優先してください。変更の意味や影響が問題となる場合に、work-refute を使用してください。
• 投票後の引き継ぎ先は ../work-gaps/SKILL.md（L5 の「NO を投じた反証担当者が攻撃しなかった点は何か？」ゲート）です。また、切り口の数が不明な場合は ../work-exhaust/SKILL.md に引き継いでください。
• このスキルに主張の集合を提供する上流の検出スキル： ../work-sweep/SKILL.md。
• これらを組み合わせる完全なハーネスは ../work/references/workflow-mode.md §2 にあります。

呼び出し例

1. レビューで見つかった、影響の大きい単一の指摘：

   /work-refute "The new AI drawer can cause the form state to get out of sync when the user collapses it during an adjustment"
   

2. セキュリティ上重要な主張を、異なる視点から検証する場合：

   /work-refute lenses="functional correctness, injection / secrets, authentication bypass, data exposure" "The new endpoint is safe for unauthenticated access because we check the tenant in middleware"
   

3. 複数の指摘を一度に扱う場合（メインエージェントが先に抽出します）：

   /work-refute the 6 review findings I just listed about the upload stage machine
   

4. エージェントとの長時間のセッション後、勝利を宣言する前：

   /work-refute "We have correctly implemented the SLA calculation and the UI now shows the right amber/red states"
   

このスキルが拒否または格下げすべき場合

• 主張が、1つのコマンドまたはオラクルで確認できる純粋な事実である場合 → オラクルを実行し、 結果を報告します（L1。決定的な質問にパネルを使わないでください）。
• N=1 の場合 → 意味のある投票には、少なくとも2つの（棄権ではない）判定が必要であると警告します。また、棄権によって k が2未満になる場合は、その旨を伝えて再度エージェントを起動し、k<2 で判定しないでください。
• ユーザーが何かを「確認」するよう求めた場合 → 反証モードに言い換えるか、拒否します。

このパターンは、手軽な確信を、コストは高いものの誠実な確信と引き換えにします。重要な場面で使い、 些細なタスクに大掛かりな仕組みを実行することは拒否し、その理由を伝えてください（workflow-mode §5）。

---

このスキルを実行するエージェント向けの実装上の注意

このスキルを呼び出す場合は、次のことを必ず行ってください。

• まず通常のツールを使って直接検証を試み、残った項目に対してオラクルゲートをフェイルクローズにします （L1、ルール #1）。
• 主張の一連の処理はパイプラインとして実行します。リフューターグループの判定がまとまるたびに、各主張の判定を個別に出力します。 バッチ全体の完了を待つバリアは設けないでください。
• 敵対的検証では、各リフューターにつきサブエージェントを1つずつ起動します（真の並列処理のため、 1つのメッセージ内で複数を起動）。バックグラウンドで、新しく分離されたコンテキストを使い、 ファイルを変更する場合に限り、分離されたワークツリー内で起動します。すべての結果を待って回収してください。
• サブエージェントには、互いの推論を見ないよう指示し、必須の3つの条項（L2 再読、L3 異なる観点、L8 作業完了）を含めてください。
• 結果が返った後は、棄権を除外し、生き残った項目を対象にしきい値を再計算して記録し、 単純な人数ではなく、証拠の重み付けに基づく生存ルールを適用します（ステップ5）。
• 勝利を宣言する前に、完全性の引き継ぎ（L5）と重大度の調整（L6）を実施してください。
• 生き残った項目についても反論を明示し、棄権と除外した理由を列挙し、どのリフューターが何を退けたのか、 また各項目が生き残った理由を明確にしてください（無言の上限なし）。

これは、利用可能な品質向上パターンの中でも、特に効果の高いものの1つです。活用してください。