grahama1970/battle

停止。在呼叫任何端點之前，請先完整閱讀此 SKILL.MD。

Battle 技能

紅藍隊安全競賽編排器

讓紅隊（攻擊方）與藍隊（防禦方）在一個長時間運行的競爭循環中對抗。每個團隊利用所有 .pi/skills 來攻擊或防禦目標程式碼庫。

不變量對戰（常見情況）

Battle 的預設計分目標是漏洞利用（系統崩潰、命令注入）， 但紅/藍對抗循環最常見的實際用途是驗證 特定專案的不變量：「無 PII 值洩漏」、「帳本平衡」、 「解析器不遺漏任何記錄」、「授權檢查無法被繞過」。

提供一個可插拔的不變量裁判──一個小型的獨立模組 judge(target_dir, params) -> {passed, violations, evidence}（schema battle.invariant_result.v1）。紅隊的目標變成「產出一個會讓裁判失敗的輸入」； 藍隊的目標是「讓它通過」；計分員讀取裁判的結果， 從不信任任何 agent 的自我報告。裁判是故障關閉的：一個出錯的 裁判視為一個 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 是一個匿名化 機密性不變量裁判：它獨立掃描釋出的輸出 （JSON 純量包含解碼後的跳脫字元、數字擴展、SQLite 儲存格 + schema DDL + 標頭整數、text/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。它是一個三階段的 Battle 合約， 而不是鬆散的筆記：

1. 階段 1：通過凍結的 acceptance_contract.bundle.v1 基礎門檻。
2. 階段 2：在該門檻通過後，收集 $project-state、目前的 Battle 收據、 基於來源過濾的 $dogpile 研究，以及 $ask 一次性 審查者提案。
3. 階段 3：將有用的階段 2 發現凍結為確定性案例，執行它們， 並為紅隊勝利、藍隊修復和重播保留自適應譜系證明。

該計劃將每個接受案例映射到帶有來源的 Dogpile 研究通道和 可重複使用的變異家族。當 Battle 階段只需要選定的 Dogpile 提供者時，使用可重複的 --dogpile-source 過濾器，例如 brave-search、 arxiv、github-search、youtube、brave-questions、feeds、wayback，或 context7，而不是完整的來源扇出。可重複使用的變異家族 包括表示等價性、編碼/正規化、解析器差異、 釋出表面邊界、有損轉換、分割/組合事實、規模、 重試/並發、授權，以及失敗洩漏邊界。Dogpile 和 Ask 僅作為研究輸入：它們發現有意義的變異家族和來源證據。 Battle 然後將選定的家族凍結為確定性生成器， 在 Docker/QEMU/數位孿生證據閘門中執行真實目標，發出 每個案例的 battle.case_receipt.v1，用 battle.campaign_aggregate.v1 彙總， 並將工作流程類別保留為 $agentic-evals 案例。一個嚴肅的 釋出閘門應期望數百個確定性案例和大約 20-30 個保留的 評估類別，當合約表面很廣時；較小的煙霧測試閘門必須 將自己標記為煙霧測試。

不變量戰役（測試合約基礎門檻，然後攻擊超越它）

一個不變量對戰評判一個輸出。一個不變量戰役讓紅隊生成 目標規格名稱所稱的整個輸入「版本」矩陣──每種格式 x 每一種表示法 x 已記錄的邊界案例──外加隨機模糊測試，在每個上執行真實目標， 裁判對每個輸出進行評分。每個案例發出一個 battle.case_receipt.v1，包含固定裝置前置檢查、執行、拒絕、安全性 裁判、可選的功能性裁判，以及判決欄位。一個戰役通過僅當 所有案例收據都通過，要求的 MUST_ACCEPT 案例實際被接受且功能性地 評判，要求的 MUST_REJECT 案例被安全拒絕，並且計算出的 battle.campaign_aggregate.v1 沒有失敗或不完整的案例。一個 失敗的版本是一個具體、可重現的紅隊勝利。

對於匿名化/隱私目標，接受合約只是基礎門檻。 當存在 acceptance_contract.bundle.v1 時，競技場建置可能會將其作為 acceptance_floor 傳遞給生產適配器。然後 Battle 故障關閉，除非 每個 acceptance_cases[] id 映射到設定檔中 required_case_ids 中的至少一個戰役生成器案例； 這些是在任何額外模糊測試或超越合約案例重要之前必須通過的 最低限度對抗版本。Battle 也必須 執行一個超越合約的戰役，攻擊客戶簡報經常遺漏的表面： JSON 鍵和重複鍵、CSV 標頭/方言/多行儲存格、 SQLite 識別碼/預設值/生成值/部分索引/觸發器、 檔案名稱、report.json、stdout/stderr、替代編碼，以及相同身分 表示陷阱。僅簡報矩陣重播是一個煙霧測試證明，而不是 全面的 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 產生匿名化簡報的 版本：四種格式、JSON 字串/整數/浮點數/科學記號、SQLite TEXT/INTEGER/REAL、Unicode NFC/NFD、BOM、JSON \u-跳脫、SQLite CHECK-字面值， 加上模糊測試。它也包含 oai-trial 圓桌會議的邊界案例：格式化 政策電話值儲存為僅數字 JSON/SQLite 數字、相同身分 播種於每個範圍內格式，以及有損的前導零/大浮點數陷阱。 fixtures/reference-generators/anon_beyond_brief_matrix.py 是隱私/匿名化證明的 要求下一步：它嘗試非顯而易見的 schema/路徑/編碼/日誌/釋出邊界表面，這些超越了字面上的接受合約。一個 生成器 + target-run-cmd + 裁判是一個可插拔的三元組：將它指向任何專案的 規格矩陣和不變量。

無資料洩漏裁判也支援一個明確的選擇加入解釋設定檔 用於轉換語義。這些保證除非在 --judge-params 中宣告，否則為關閉， 因此 Battle 不會在看到失敗後靜默擴展合約：

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

使用該設定檔，整個純量/令牌 base64/base64url/hex 值被解碼 一次，並且記錄本地的相鄰 JSON/CSV/SQLite 純量欄位可以重構一個 完整的政策值。任意的遞迴解碼、全域欄位連接，以及 視覺混淆字元折疊仍然在預設阻擋閘門之外。

在紅隊找到失敗案例且藍隊修補目標後，發出可重播的 譜系收據，而不是用散文總結：

./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 證明紅隊找到了合約 邊界案例，藍隊移除了那些紅隊勝利，並且獨立裁判重播通過了。

然後 Battle 必須產生一個經 $create-report 驗證的報告，包含 $project-state 上下文和一個明確的漏洞利用表格。報告是人類可讀的決策 產物；收據仍然是權威。先產生最新的專案狀態， 然後渲染報告：

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

對於專案 agent 終端機審查，當案例有長篇證據時使用卡片：

./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 進行 正常的專案 agent 審查 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。如果一個生產適配器收據帶有 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 的緊湊概覽別名： 兩者都列印合約基礎、紅隊壓力、計分員呼叫，以及每個攻擊一個案例表格行。 在互動式終端機中，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。表格 必須是直白且易於掃描的：每個攻擊案例一行，包含 Scope、Contractual?、Adaptive lineage?、Case、Exploit / attack、 Why chosen、Expectation、Result，以及 Judge evidence 欄位。Scope 分離 contractual 接受基礎案例與 beyond-contract 探測； Why chosen 解釋非合約探測；Adaptive lineage? 標記已被修復並重播的紅隊勝利； RED_WIN 封鎖釋出。表格從 battle.case_receipt.v1 衍生，當存在時， 僅對較舊的戰役收據回退到傳統的 case_log。一個沒有該報告的 Battle 關閉 即使戰役收據通過，也缺少決策表面。

目的邊界

Battle 的目的是紅/藍安全競賽後端：授權目標 設定、隔離執行、紅隊攻擊生成、藍隊防禦生成、 獨立裁判重播、計分員收據、自適應譜系，以及持久學習。 自適應譜系是一個後端學習循環，它生成、評估、 選擇，並從裁判支援的收據中推廣或拒絕子代紅/藍證據。

PixiJS 僅是 Battle 收據的觀察者/重播表面。一個 PixiJS 通過 證明記錄的收據可以在一個有趣的重播中被檢視；它不 證明 Battle 編排器、提供者驅動的子 agent、Docker/QEMU 隔離、 夜間排程器、計分員或記憶學習有效。不要僅從 PixiJS 證據 關閉核心 Battle 準備就緒，並且不要將後端自適應譜系阻塞在 重播打磨上，超出真實的收據可檢視性。

架構

生產 Battle 是一個編排技能，而不是一個大型特製安全 引擎。主機端程序應排程回合、選擇角色、分派 子 agent、佈建 Docker 執行環境、收集收據、對硬執行時間訊號評分、 寫入報告，以及持久化學習。目標程式碼和團隊生成的程式碼必須僅在 Docker 內部執行。

要求的生產不變量：

• 紅隊和藍隊是子 agent 團隊。每個被分派的子 agent 必須包含一個 由該回合的編排器選擇的明確角色。當回合從廣度中受益時， 每個團隊可以並行執行多個角色。
• Battle 執行需要一個 security.target_authorization.v1 清單，在 Docker、QEMU、目標執行環境設定、Hack 委派、證明重播或修補 重播開始之前。該清單綁定專案/操作者範圍和目標身分； 它不是法律意見，也不證明漏洞利用成功或修補 有效性。
• 紅隊 $hack 執行是子 agent 的責任，而不是一個 Battle Python 匯入。Battle 執行或排程掃描/研究/記憶召回，建立 候選漏洞利用清單，選擇紅隊角色，分派一個 agent-skills/agents/Tau 子 agent 使用該合約，並記錄 返回的漏洞利用收據。
• 子 agent 交接和收據應遵循 Tau 風格的緊湊 JSON 合約形狀，由 tau.agent_handoff.v1 和 tau.subagent_receipt.v1 使用， 並在其上疊加 Battle 特定欄位，而不是一個單獨的臨時 協定。
• Battle 呼叫模組化 Tau 子 agent 合約。Tau 和循環/agentic 框架 擁有子 agent 執行，並使用 scillm 作為 LLM/模型呼叫器。Battle 擁有 團隊選擇、角色分配、Docker 執行環境、計分、產出和記憶優化。