grahama1970/battle

停止。エンドポイントを呼び出す前に、このSKILL.MD全体を読んでください。

Battle スキル

Red vs Blue チーム セキュリティ競技オーケストレーター

Red Team（攻撃）とBlue Team（防御）を、長時間実行される競争ループで対決させます。各チームは、対象のコードベースを攻撃または防御するために、すべての.pi/skillsを活用します。

不変条件バトル（一般的なケース）

Battleのデフォルトのスコアリングは悪用（システムダウン、コマンドインジェクション）を対象としていますが、敵対的なRed/Blueループの最も頻繁な実際の使用法は、プロジェクト固有の不変条件（「PII値の漏洩がない」、「台帳の残高が一致する」、「パーサーがレコードをドロップしない」、「認可チェックがバイパスできない」）を検証することです。

プラグイン可能な不変条件 Judge（独立した小さなモジュールjudge(target_dir, params) -> {passed, violations, evidence}（スキーマ battle.invariant_result.v1））を提供します。Redの目標は「Judgeを失敗させる入力を生成する」ことになり、Blueの目標は「それを成功させる」ことです。スコアキーパーはエージェントの自己報告ではなく、Judgeの結果を読み取ります。Judgeはフェイルクローズドです。エラーが発生したJudgeはFAILEDな不変条件であり、黙って合格することはありません。

python3 -m battle_skill.invariant_judge \
  --judge fixtures/reference-judges/no_data_leak_judge.py \
  --target <released-output-dir> \
  --params '{"policy": "policy.json", "output_subdir": "corpus"}'

fixtures/reference-judges/no_data_leak_judge.py は、匿名化機密性不変条件をJudgeとして実装したものです。リリースされた出力（デコードされたエスケープを含むJSONスカラー、数値展開、SQLiteセル+スキーマDDL+ヘッダー整数、テキスト/CSV、report.json、キャプチャされたstdout/stderr）を独立してスキャンし、任意の表現のポリシー値を検出します。

契約バリエーション研究（汎用Battle構成）

Battleはプロジェクト固有ではありません。acceptance_contract.bundle.v1 を持つプロジェクトまたはスキルについては、Battleは包括的な敵対的カバレッジを主張する前に、各契約項目をDogpileを通じて展開する必要があります。

./run.sh contract-variation-plan \
  --acceptance-bundle /path/to/acceptance_bundle.json \
  --dogpile-source brave-search \
  --dogpile-source arxiv \
  --out /tmp/battle-variation-plan.json

出力は battle.contract_variation_plan.v1 です。これは3フェーズのBattle契約であり、単なる大まかなメモではありません。

1. フェーズ 1: 凍結された acceptance_contract.bundle.v1 フロアを通過する。
2. フェーズ 2: その合格後、$project-state、現在のBattleレシート、ソースフィルタリングされた $dogpile リサーチ、$ask one-shot レビューアプロポーザルを収集する。
3. フェーズ 3: 有用なフェーズ2の調査結果を決定論的なケースに凍結し、実行し、Redの勝利、Blueの修正、リプレイのための適応的系統の証拠を保持する。

この計画は、すべての受入ケースをソースを持つDogpileリサーチレーンと再利用可能なバリエーションファミリーにマッピングします。Battleフェーズが完全なソースファンアウトの代わりに、brave-search、arxiv、github-search、youtube、brave-questions、feeds、wayback、context7 などの選択されたDogpileプロバイダのみを必要とする場合は、繰り返し可能な --dogpile-source フィルターを使用します。再利用可能なバリエーションファミリーには、表現等価性、エンコーディング/正規化、パーサーの差異、リリースサーフェス境界、非可逆変換、分割/合成された事実、スケール、リトライ/並行性、認可、障害漏洩境界が含まれます。DogpileとAskはリサーチ入力のみです。意味のあるバリエーションファミリーとソース証拠を発見します。その後、Battleは選択されたファミリーを決定論的ジェネレーターに凍結し、Docker/QEMU/デジタルツインの証拠ゲートで実際のターゲットを実行し、ケースごとに battle.case_receipt.v1 を発行し、battle.campaign_aggregate.v1 で集約し、ワークフロークラスを $agentic-evals ケースとして保持します。深刻なリリースゲートでは、契約サーフェスが広い場合、数百の決定論的ケースと約20〜30の保持された評価クラスが期待されるべきです。より小さなスモークゲートは、それ自体をスモークとしてラベル付けする必要があります。

不変条件キャンペーン（契約フロアをテストし、その先を攻撃する）

不変条件 バトル は1つの出力を判断します。不変条件 キャンペーン では、Redがターゲットの仕様が命名する入力「バージョン」のMATRIX全体（すべての形式×すべての表現×文書化されたエッジケース）に加えてランダムファズを生成し、それぞれで実際のターゲットを実行し、Judgeがすべての出力をスコアリングします。すべてのケースは、フィクスチャ事前チェック、実行、リジェクション、セキュリティJudge、オプションの機能Judge、および評決フィールドを含む battle.case_receipt.v1 を発行します。キャンペーンは、すべてのケースレシートが合格し、必要な MUST_ACCEPT ケースが実際に受け入れられ機能的に判断され、必要な MUST_REJECT ケースが安全に拒否され、計算された battle.campaign_aggregate.v1 に失敗または不完全なケースがない場合にのみPASSします。1つの失敗バージョンは、具体的で再現可能なRedの勝利です。

匿名化/プライバシーターゲットの場合、受入契約は単なるフロアです。acceptance_contract.bundle.v1 が存在する場合、アリーナビルドはそれを acceptance_floor としてプロダクションアダプターに渡すことができます。その後、Battleは、すべての acceptance_cases[] IDがプロファイルの required_case_ids 内の少なくとも1つのキャンペーンジェネレーターケースにマッピングされない限り、フェイルクローズします。これらは、追加のファズや契約外のケースが重要になる前に合格しなければならない最小限の敵対的バージョンです。Battleはまた、クライアントのブリーフでしばしば省略されるサーフェス（JSONキーと重複キー、CSVヘッダー/方言/複数行セル、SQLite識別子/デフォルト/生成値/部分インデックス/トリガー、ファイル名、report.json、stdout/stderr、代替エンコーディング、同一ID表現のトラップ）を攻撃する契約外のキャンペーンも実行する必要があります。クリーンなブリーフマトリックスのリプレイだけでは、スモークプルーフであり、包括的なBattleプルーフではありません。

python3 -m battle_skill.invariant_campaign \
  --generator fixtures/reference-generators/anon_brief_matrix.py \
  --target-run-cmd 'docker run --rm -v {input}/corpus:/trial/input/corpus:ro -v {input}/policy.json:/trial/input/policy.json:ro -v {output}:/trial/output anonymization-trial run' \
  --judge fixtures/reference-judges/no_data_leak_judge.py \
  --gen-params '{"fuzz": 20}' --judge-params '{"output_subdir": "corpus"}'

fixtures/reference-generators/anon_brief_matrix.py は、匿名化ブリーフのバージョン（4つの形式、JSON string/int/float/scientific、SQLite TEXT/INTEGER/REAL、Unicode NFC/NFD、BOM、JSON \u-escape、SQLite CHECK-literal、およびファズ）を生成します。また、oai-trialラウンドテーブルのエッジケース（桁のみのJSON/SQLite数値として保存されたフォーマット済みポリシー電話値、範囲内のすべての形式にわたってシードされた同じID、および非可逆的な先頭ゼロ/大きな浮動小数点のトラップ）も含みます。fixtures/reference-generators/anon_beyond_brief_matrix.py は、プライバシー/匿名化プルーフに必要な次の段階です。文字通りの受入契約を超える、明白でないスキーマ/パス/エンコーディング/ログ/リリースサーフェスを試みます。ジェネレーター + target-run-cmd + judge はプラグ可能なトリオです。任意のプロジェクトの仕様マトリックスと不変条件に向けてポイントします。

データ漏洩防止Judgeは、変換セマンティクスのための明示的なオプトイン解釈プロファイルもサポートしています。これらの保証は、--judge-params で宣言されない限りOFFです。そのため、Battleは失敗を見た後で暗黙的に契約を拡張することはありません。

{
  "interpretation_profile": {
    "decoders": ["base64", "base64url", "hex"],
    "record_local_reconstruction": true,
    "max_decoded_bytes": 4096
  }
}

このプロファイルにより、スカラー/トークンの base64/base64url/hex 値は1回だけデコードされ、レコードローカルの隣接するJSON/CSV/SQLiteスカラーフィールドは完全なポリシー値を再構築できます。任意の再帰的デコード、グローバルフィールド結合、および視覚的に紛らわしい文字の折りたたみは、デフォルトのブロッキングゲートの対象外のままです。

Redが失敗ケースを発見し、Blueがターゲットにパッチを適用した後、散文で要約する代わりに、再生可能な系統レシートを発行します。

./run.sh invariant-lineage-receipt \
  --red-campaign /tmp/red-result.json \
  --replay-campaign /tmp/replay-result.json \
  --target oai-trial \
  --out /tmp/battle-lineage.json

battle.invariant_adaptive_lineage.v1 PASSは、Redが契約のエッジケースを発見し、BlueがそれらのRedの勝利を削除し、独立したJudgeのリプレイが合格したことを証明します。

次に、Battleは $project-state コンテキストと明示的なエクスプロイトテーブルを含む $create-report 検証済みレポートを生成する必要があります。このレポートは人間が読める意思決定アーティファクトです。レシートは引き続き権威となります。最初に新しいプロジェクト状態を生成し、次にレポートをレンダリングします。

PROJECT_STATE_ROOT=/path/to/target ../project-state/run.sh report --json --output /tmp/project-state.json
./run.sh invariant-report \
  --campaign /tmp/battle-brief-fuzz.json \
  --campaign /tmp/battle-beyond-brief.json \
  --adaptive-lineage /tmp/battle-lineage.json \
  --project-state /tmp/project-state.json \
  --target oai-trial \
  --out-json /tmp/battle-report.json \
  --out-md /tmp/battle-report.md

プロジェクトエージェントのターミナルレビューの場合は、ケースに長い証拠があるときにカードを使用します。

./run.sh invariant-report \
  --campaign /tmp/battle-brief-fuzz.json \
  --campaign /tmp/battle-beyond-brief.json \
  --project-state /tmp/project-state.json \
  --target oai-trial \
  --out-json /tmp/battle-report.json \
  --out-md /tmp/battle-report.md \
  --terminal-cards

invariant-report はTyper CLIコマンドです。マシンJSONをstdoutに書き込み、人間向けのBattleレポートをstderrに保持します。--terminal-cards は、Battle証拠の通常のプロジェクトエージェントレビューに使用します。Acceptance contract floor、Beyond-contract exploits、Adaptive lineage、およびフォールバックの Other campaign cases の見出しの下にカードをグループ化し、ケースごとに Scope、Case、Acceptance parent、Expect、Result、Example、Why Battle checks this、Related research、Adaptive lineage、Judge evidence を含む ============== ブロックを1つ出力します。プロダクションアダプターレシートが acceptance_floor.case_map を保持している場合、契約フロアカードは親の AC-* IDを表示します。そうでない場合、Acceptance parent は not recorded in case receipt となります。レシートに example、why_chosen、research_refs、source_refs がある場合、カードはこれらの正確なフィールドを表示します。そうでない場合、例/根拠はケースIDから決定論的に決定され、リサーチは not recorded in case receipt として報告されます。

--terminal-table は、--terminal-summary のコンパクトな概要エイリアスのままです。どちらも、契約フロア、Redの圧力、Scorekeeperの呼び出し、および攻撃ごとに1つのケーステーブル行を出力します。インタラクティブなターミナルでは、BattleはRichのターミナル対応カラーテーブル（RED_WIN は赤、クリーンパスは緑、フェイルクローズドストップは黄色）を使用し、NO_COLOR を尊重します。キャプチャ/CI下では、ログとテストが安定するように、決定論的なプレーンテキストにフォールバックします。

invariant-report は create_report.report.v1 を書き込み、skills/create-report/run.sh validate を通じて検証し、skills/create-report/run.sh render を通じてMarkdownをレンダリングし、## Exploits Table を追加します。このテーブルは平易でスキャン可能である必要があります。攻撃ケースごとに1行で、Scope、Contractual?、Adaptive lineage?、Case、Exploit / attack、Why chosen、Expectation、Result、Judge evidence の列があります。Scope は、contractual な受入フロアケースと beyond-contract プローブを区別します。Why chosen は非契約プローブを説明します。Adaptive lineage? は、修正されてリプレイされたRedの勝利を示します。RED_WIN はリリースをブロックします。このテーブルは、存在する場合は battle.case_receipt.v1 から派生し、古いキャンペーンレシートの場合のみレガシーな case_log にフォールバックします。そのレポートなしでのBattleのクロージャは、キャンペーンレシートが合格しても、意思決定サーフェスが欠落しています。

目的の境界

Battleの目的は、Red/Blueセキュリティ競技のバックエンドです。承認されたターゲットのセットアップ、分離された実行、Red攻撃生成、Blue防御生成、独立したJudgeリプレイ、スコアキーパーレシート、適応的系統、および耐久性のある学習です。適応的系統は、Judgeバックアップされたレシートから子のRed/Blue証拠を生成、評価、選択、および昇格または拒否するバックエンド学習ループです。

PixiJSは、Battleレシートのための単なる観戦/リプレイサーフェスです。PixiJSパスは、記録されたレシートが楽しいリプレイで検査できることを証明します。Battleオーケストレーター、プロバイダ駆動サブエージェント、Docker/QEMU分離、夜間スケジューラー、スコアキーパー、またはメモリ学習が機能することを証明するものではありません。PixiJS証拠のみからコアのBattle準備状況を結論付けたり、真実のレシート検査可能性を超えるリプレイの洗練のためにバックエンドの適応的系統をブロックしたりしないでください。

アーキテクチャ

プロダクションBattleはオーケストレーションスキルであり、大規模な特注のセキュリティエンジンではありません。ホスト側プロセスは、ラウンドをスケジュールし、ペルソナを選択し、サブエージェントをディスパッチし、Dockerランタイムをプロビジョニングし、レシートを収集し、ハードランタイムシグナルをスコアリングし、レポートを作成し、学習を永続化する必要があります。ターゲットコードとチーム生成コードは、Docker内でのみ実行される必要があります。

必要なプロダクション不変条件：

• RedとBlueはサブエージェントチームです。ディスパッチされる各サブエージェントには、そのターンに対してオーケストレーターによって選択された明示的なペルソナが含まれている必要があります。チームごとの複数のペルソナは、ターンが幅から恩恵を受ける場合に同時に実行できます。
• Battleの実行には、Docker、QEMU、ターゲットランタイムセットアップ、Hack委任、プルーフリプレイ、またはパッチリプレイが開始される前に、security.target_authorization.v1 マニフェストが必要です。マニフェストは、プロジェクト/オペレーターのスコープとターゲットIDをバインドします。これは法的意見ではなく、エクスプロイトの成功やパッチの有効性を証明するものではありません。
• Redチームの $hack 実行は、BattleのPythonインポートではなく、サブエージェントの責任です。Battleは、スキャン/リサーチ/メモリリコールを実行またはスケジュールし、候補エクスプロイトリストを構築し、Redペルソナを選択し、その契約で agent-skills/agents/Tau サブエージェントをディスパッチし、返されたエクスプロイトレシートを記録します。
• サブエージェントのハンドオフとレシートは、tau.agent_handoff.v1 および tau.subagent_receipt.v1 で使用されるコンパクトなTauスタイルのJSON契約形状に従う必要があります。Battle固有のフィールドは、別個のアドホックプロトコルではなく、その上に階層化されます。
• BattleはモジュラーなTauサブエージェント契約を呼び出します。Tauとループ/エージェンティックハーネスはサブエージェントの実行を所有し、scillm をLLM/モデル呼び出し元として使用します。Battleは、チーム選択、ペルソナ割り当て、Dockerランタイム、スコアキーピング、アーティファクト、およびメモリを所有します。

... [翻訳のために切り詰めました]