grahama1970/battle

STOP. LESEN SIE DIESE GESAMTE SKILL.MD, BEVOR SIE EINEN ENDPUNKT AUFRUFEN.

Battle Skill

Orchestrator für Sicherheitswettbewerbe zwischen Red und Blue Teams

Stellt ein Red Team (Angriff) gegen ein Blue Team (Verteidigung) in einer langlaufenden Wettbewerbsschleife. Jedes Team nutzt alle .pi/skills, um eine Zielcodebasis anzugreifen oder zu verteidigen.

Invariante Kämpfe (der häufigste Fall)

Battles Standardbewertung zielt auf Exploitation ab (Systemausfall, Befehlseinschleusung), aber die häufigste reale Verwendung einer adversarialen Red/Blue-Schleife ist die Überprüfung einer PROJEKTSPEZIFISCHEN INVARIANTE: "kein PII-Wert leckt", "das Hauptbuch stimmt", "der Parser verwirft keinen Datensatz", "die Authz-Prüfung kann nicht umgangen werden".

Stellen Sie einen steckbaren Invarianten-Judge bereit – ein kleines unabhängiges Modul judge(target_dir, params) -> {passed, violations, evidence} (Schema battle.invariant_result.v1). Reds Ziel wird es, "eine Eingabe zu produzieren, die den Judge zum Scheitern bringt"; Blues Ziel ist es, "ihn bestehen zu lassen"; der Punktestand-Leser liest das Judge-Ergebnis, niemals einen Selbstbericht eines Agenten. Judge sind fail-closed: Ein Judge, der einen Fehler produziert, ist eine FEHLGESCHLAGENE Invariante, niemals ein stilles Bestehen.

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 ist die Anonymisierungs- Vertraulichkeitsinvariante als Judge: Sie scannt unabhängig die veröffentlichte Ausgabe (JSON-Skalare inkl. dekodierter Escapes, numerische Expansion, SQLite-Zellen + Schema DDL + Header-Integer, Text/CSV, report.json und erfasste stdout/stderr) nach jedem Policy-Wert in jeder Darstellung.

Vertragsvariationsfamilien-Forschung (generische Battle-Komposition)

Battle ist nicht projektspezifisch. Für jedes Projekt oder jede Fertigkeit mit einem acceptance_contract.bundle.v1 sollte Battle jedes Vertragselement durch Dogpile erweitern, bevor eine umfassende adversary Abdeckung beansprucht wird:

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

Die Ausgabe ist battle.contract_variation_plan.v1. Es ist ein dreiphasiger Battle-Vertrag, keine lockere Notiz:

1. Phase 1: Bestehen des eingefrorenen acceptance_contract.bundle.v1-Bodens.
2. Phase 2: Nach diesem Bestehen sammle $project-state, aktuelle Battle-Quittungen, quellengefilterte $dogpile-Forschung und $ask one-shot-Reviewer-Vorschläge.
3. Phase 3: Friere nützliche Phase-2-Ergebnisse in deterministische Fälle ein, führe sie aus und behalte adaptive Abstammungsnachweise für Red-Siege, Blue-Fixes und Wiederholung.

Der Plan kartiert jeden Akzeptanzfall auf quellentragende Dogpile-Forschungsspuren und wiederverwendbare Variationsfamilien. Verwenden Sie wiederholbare --dogpile-source-Filter, wenn eine Battle-Phase nur ausgewählte Dogpile-Anbieter wie brave-search, arxiv, github-search, youtube, brave-questions, feeds, wayback oder context7 anstelle des vollständigen Quellen-Fanouts benötigt. Die wiederverwendbaren Variationsfamilien umfassen Darstellungsäquivalenz, Kodierung/Normalisierung, Parser-Differentiale, Freigabeoberflächengrenzen, verlustbehaftete Konvertierung, aufgeteilte/zusammengesetzte Fakten, Skalierung, Wiederholung/Nebenläufigkeit, Autorisierung und Ausfallleck-Grenzen. Dogpile und Ask sind nur Forschungseingaben: Sie entdecken sinnvolle Variationsfamilien und Quellennachweise. Battle friert dann ausgewählte Familien in deterministische Generatoren ein, führt das reale Ziel in Docker/QEMU/digital-twin-Nachweisgattern aus, gibt battle.case_receipt.v1 pro Fall aus, aggregiert mit battle.campaign_aggregate.v1 und behält die Workflow-Klassen als $agentic-evals-Fälle. Ein ernsthaftes Release-Gate sollte hunderte deterministische Fälle und etwa 20-30 beibehaltene Eval-Klassen erwarten, wenn die Vertragsoberfläche breit ist; kleinere Smoke-Gates müssen sich selbst als Smoke kennzeichnen.

Invarianten-Kampagnen (teste den Vertragsboden, greife dann darüber hinaus an)

Eine Invarianten-Schlacht beurteilt eine Ausgabe. Eine Invarianten-Kampagne lässt Red die ganze MATRIX von Eingabe-"Versionen" generieren, die die Spezifikation des Ziels nennt – jedes Format x jede Darstellung x die dokumentierten Randfälle – PLUS zufälliges Fuzzing, führt das reale Ziel auf jedem aus, und der Judge bewertet jede Ausgabe. Jeder Fall gibt ein battle.case_receipt.v1 mit Fixture-Vorprüfung, Ausführung, Ablehnung, Sicherheits- Judge, optionalem funktionalen Judge und Urteilsfeldern aus. Eine Kampagne BESTEHT nur, wenn alle Fallquittungen bestanden werden, erforderliche MUST_ACCEPT-Fälle tatsächlich akzeptiert und funktional beurteilt werden, erforderliche MUST_REJECT-Fälle sicher abgelehnt werden und das berechnete battle.campaign_aggregate.v1 keine fehlgeschlagenen oder unvollständigen Fälle aufweist. Eine fehlschlagende Version ist ein konkreter, reproduzierbarer Red-Sieg.

Für Anonymisierungs-/Datenschutzziele ist der Akzeptanzvertrag nur der Boden. Wenn ein acceptance_contract.bundle.v1 existiert, kann der Arenenbau ihn als acceptance_floor an den Produktionsadapter übergeben. Battle schlägt dann fail-closed, es sei denn, jede acceptance_cases[]-ID wird auf mindestens einen Kampagnengeneratorfall im Profil required_case_ids abgebildet; dies sind die Mindest-Anforderung adversarischer Versionen, die BESTEHEN MÜSSEN, bevor irgendein zusätzliches Fuzzing oder über den Vertrag hinausgehende Fälle wichtig sind. Battle muss auch eine über den Vertrag hinausgehende Kampagne ausführen, die Oberflächen angreift, die ein Kundenbriefing häufig auslässt: JSON-Schlüssel und doppelte Schlüssel, CSV-Header/Dialekte/mehrzeilige Zellen, SQLite-Identifikatoren/Defaults/generierte Werte/partielle Indizes/Trigger, Dateinamen, report.json, stdout/stderr, alternative Kodierungen und Darstellungsfallen mit derselben Identität. Ein sauberes Briefing-Matrix-Replay allein ist ein Smoke-Nachweis, kein umfassender Battle-Nachweis.

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 liefert die Versionen des Anonymisierungs- Briefings: die vier Formate, JSON-String/int/float/scientific, SQLite TEXT/INTEGER/REAL, Unicode NFC/NFD, BOM, JSON \u-Escape, SQLite CHECK-Literal, plus Fuzzing. Es trägt auch die oai-trial-Roundtable-Randfälle: formatierte Policy- Telefonwerte, die als reine Ziffern in JSON/SQLite-Numeriken gespeichert sind, dieselbe Identität, die in jedes relevante Format eingesät wurde, und verlustbehaftete Fallen für führende Nullen / große Fließkommazahlen. fixtures/reference-generators/anon_beyond_brief_matrix.py ist die erforderliche nächste Stufe für Datenschutz-/Anonymisierungsnachweise: Es versucht nicht offensichtliche Schema-/Pfad-/Kodierungs-/Logs/ Freigabeoberflächen, die über den wörtlichen Akzeptanzvertrag hinausgehen. Ein Generator + target-run-cmd + Judge ist ein steckbares Trio: Richten Sie es auf die Spezifikationsmatrix und Invariante jedes Projekts aus.

Der No-Data-Leak-Judge unterstützt auch ein explizites Opt-in-Interpretationsprofil für Transformationssemantik. Diese Garantien sind AUS, es sei denn, sie werden in --judge-params deklariert, sodass Battle den Vertrag nicht stillschweigend erweitert, nachdem ein Fehler aufgetreten ist:

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

Mit diesem Profil werden ganze Skalar-/Token-Base64-/Base64url-/Hex-Werte einmal dekodiert und datensatzlokale benachbarte JSON-/CSV-/SQLite-Skalarfelder können einen vollständigen Policy-Wert rekonstruieren. Beliebiges rekursives Dekodieren, globale Feldverknüpfungen und visuell verwechselbare Zeichenfaltung bleiben außerhalb des standardmäßigen Blockierungsgatters.

Nachdem Red fehlschlagende Fälle gefunden und Blue das Ziel repariert hat, geben Sie den wiederholbaren Abstammungsbeleg aus, anstatt in Prosa zusammenzufassen:

./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

Ein battle.invariant_adaptive_lineage.v1 BESTEHEN beweist, dass Red Vertragsrandfälle gefunden hat, Blue diese Red-Siege entfernt hat und das unabhängige Judge-Replay bestanden wurde.

Dann muss Battle einen $create-report-validierten Bericht mit $project-state Kontext und einer expliziten Exploits-Tabelle erstellen. Der Bericht ist das menschenlesbare Entscheidungs- artefakt; Quittungen bleiben die Autorität. Generieren Sie zuerst den aktuellen Projektstatus, dann rendern Sie den Bericht:

PROJECT_STATE_ROOT=/pfad/zu/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

Für die Terminal-Überprüfung durch den Projektagenten verwenden Sie Karten, wenn Fälle lange Nachweise haben:

./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 ist ein Typer-CLI-Befehl. Es schreibt Maschinen-JSON auf stdout und behält den menschlichen Battle-Bericht auf stderr. Verwenden Sie --terminal-cards für die normale Projektagenten-Überprüfung von Battle-Nachweisen: Es gruppiert Karten unter den Überschriften Acceptance contract floor, Beyond-contract exploits, Adaptive lineage und Fallback Other campaign cases und gibt dann einen ==============-Block pro Fall aus mit Scope, Case, Acceptance parent, Expect, Result, Example, Why Battle checks this, Related research, Adaptive lineage und Judge evidence. Wenn ein Produktionsadapter-Beleg acceptance_floor.case_map trägt, zeigen Vertragsbodenkarten die übergeordnete(n) AC-*-ID(s); andernfalls ist Acceptance parent not recorded in case receipt. Wenn ein Beleg example, why_chosen, research_refs oder source_refs hat, zeigen Karten diese genauen Felder; andernfalls sind Beispiele/Begründungen deterministisch von der Fall-ID, und die Forschung wird als not recorded in case receipt gemeldet.

--terminal-table bleibt der kompakte Überblicks-Alias für --terminal-summary: beide drucken den Vertragsboden, den Red-Druck, den Scorekeeper-Aufruf und eine Falltabelle mit einer Zeile pro Angriff. In einem interaktiven Terminal verwendet Battle die terminalbewusste farbige Tabelle von Rich (RED_WIN rot, saubere Bestehen grün, fail-closed Stopps gelb) und ehrt NO_COLOR; unter Erfassung/CI fällt es auf deterministischen Klartext zurück, sodass Logs und Tests stabil bleiben.

invariant-report schreibt create_report.report.v1, validiert es durch skills/create-report/run.sh validate, rendert Markdown durch skills/create-report/run.sh render und hängt ## Exploits Table an. Die Tabelle muss klar und scannbar sein: eine Zeile pro Angriffsfall mit Spalten für Scope, Contractual?, Adaptive lineage?, Case, Exploit / attack, Why chosen, Expectation, Result und Judge evidence. Scope trennt contractual Fälle des Akzeptanzbodens von beyond-contract Sonden; Why chosen erklärt nicht-vertragliche Sonden; Adaptive lineage? markiert Red-Siege, die repariert und wiederholt wurden; RED_WIN blockiert die Veröffentlichung. Die Tabelle wird von battle.case_receipt.v1 abgeleitet, wenn vorhanden, und fällt auf case_log nur zurück, wenn ältere Kampagnenbelege vorliegen. Ein Battle-Abschluss ohne diesen Bericht vermisst die Entscheidungsoberfläche, selbst wenn die Kampagnenbelege bestanden haben.

Zweckgrenze

Battles Zweck ist das Red/Blue-Sicherheitswettbewerbs-Backend: autorisiertes Ziel-Setup, isolierte Ausführung, Red-Angriffsgenerierung, Blue-Verteidigungsgenerierung, unabhängiges Judge-Replay, Scorekeeper-Belege, adaptive Abstammung und dauerhaftes Lernen. Adaptive Abstammung ist eine Backend-Lernschleife, die Child-Red/Blue-Nachweise von Judge-gestützten Belegen erzeugt, bewertet, auswählt und fördert oder ablehnt.

PixiJS ist nur ein Zuschauer-/Replay-Oberfläche für Battle-Belege. Ein PixiJS-Bestehen beweist, dass aufgezeichnete Belege in einem unterhaltsamen Replay inspiziert werden können; es beweist nicht, dass der Battle-Orchestrator, anbietergetriebene Subagenten, Docker/QEMU-Isolation, der nächtliche Scheduler, der Scorekeeper oder das Speicherlernen funktioniert. Schließen Sie nicht die Kern-Battle-Bereitschaft allein aus PixiJS-Nachweisen und blockieren Sie nicht das adaptive Backend-Lernen durch Replay-Politur, die über die wahrheitsgemäße Überprüfbarkeit von Belegen hinausgeht.

Architektur

Produktions-Battle ist eine Orchestrierungsfertigkeit, keine große maßgeschneiderte Sicherheits- Engine. Der Host-seitige Prozess sollte Runden planen, Personas auswählen, Subagenten entsenden, Docker-Laufzeiten bereitstellen, Belege sammeln, harte Laufzeitsignale bewerten, Berichte schreiben und Lernen persistieren. Zielcode und teamgenerierter Code darf nur innerhalb von Docker ausgeführt werden.

Erforderliche Produktionsinvarianten:

• Red und Blue sind Subagententeams. Jeder entsandte Subagent muss eine explizite Persona enthalten, die vom Orchestrator für diese Runde ausgewählt wurde. Mehrere Personas pro Team können gleichzeitig laufen, wenn die Runde von Breite profitiert.
• Battle-Ausführung erfordert ein security.target_authorization.v1-Manifest, bevor Docker, QEMU, Ziel-Laufzeitsetup, Hack-Delegation, Nachweis-Replay oder Patch-Replay startet. Das Manifest bindet den Projekt-/Betreiberbereich und die Zielidentität; es ist keine Rechtsmeinung und beweist keinen Exploit-Erfolg oder Patcheffektivität.
• $hack-Ausführung des Red-Teams ist eine Subagentenverantwortung, kein Battle-Python- Import. Battle führt Scans/Research/Speicher-Recall durch oder plant sie ein, baut die Kandidaten-Exploit-Liste auf, wählt die Red-Persona aus, entsendet einen agent-skills/agents/Tau-Subagenten mit diesem Vertrag und zeichnet den zurückgegebenen Exploit-Beleg auf.
• Subagenten-Übergaben und Belege sollten der kompakten Tau-artigen JSON- Vertragsform von tau.agent_handoff.v1 und tau.subagent_receipt.v1 folgen, mit Battle-spezifischen Feldern, die darauf aufgesetzt werden, anstatt einem separaten Ad-hoc- Protokoll.
• Battle ruft modulare Tau-Subagentenverträge auf. Tau und die Schleife/der agentische Rahmen besitzen die Subagentenausführung und verwenden scillm als LLM/Modell-Aufrufer. Battle besitzt Teamauswahl, Personenzuweisung, Docker-Laufzeiten, Punkteverwaltung, Artefakte und Gedächtnis-Pruning.

…

[abgeschnitten zur Übersetzung]