grahama1970/battle

중지. 어떤 엔드포인트를 호출하기 전에 이 전체 SKILL.MD를 읽으십시오.

Battle Skill

레드 팀 대 블루 팀 보안 경쟁 오케스트레이터

레드 팀(공격)과 블루 팀(방어)을 장기적인 경쟁 루프에서 맞붙입니다. 각 팀은 모든 .pi/skills를 활용하여 대상 코드베이스를 공격하거나 방어합니다.

불변 속성 배틀 (일반적인 경우)

Battle의 기본 점수는 착취(시스템 다운, 명령어 주입)를 대상으로 하지만, 적대적 레드/블루 루프의 가장 빈번한 실제 사용은 프로젝트별 고유 불변 속성(Invariant)을 검증하는 것입니다: "PII 값 누출 없음", "원장 균형 유지", "파서가 레코드 누락 없음", "인증/권한 검사 우회 불가".

플러그 가능한 불변 속성 심사관(Judge)을 제공하십시오 - 독립적인 작은 모듈 judge(target_dir, params) -> {passed, violations, evidence} (스키마 battle.invariant_result.v1). 레드의 목표는 "심사관이 실패하게 만드는 입력 생성"이 되고, 블루의 목표는 "통과시키는 것"입니다. 점수 기록부는 심사관 결과를 읽으며, 에이전트의 자체 보고는 절대 읽지 않습니다. 심사관은 fail-closed 방식입니다: 오류가 발생한 심사관은 실패한 불변 속성으로 처리되며, 조용히 통과되지 않습니다.

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 셀 + 스키마 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입니다. 이는 느슨한 메모가 아닌 3단계 Battle 계약입니다:

1. 단계 1: 고정된 acceptance_contract.bundle.v1 기준을 통과합니다.
2. 단계 2: 해당 통과 후, $project-state, 현재 Battle 영수증, 소스 필터링된 $dogpile 연구, $ask one-shot 리뷰어 제안을 수집합니다.
3. 단계 3: 유용한 단계 2의 발견 사항을 결정론적 사례로 고정하고 실행하며, 레드 승리, 블루 수정, 재실행에 대한 적응형 계보 증명을 유지합니다.

이 계획은 모든 승인 사례를 소스가 있는 Dogpile 연구 경로 및 재사용 가능한 변형 계열에 매핑합니다. Battle 단계가 전체 소스 확장 대신 선택된 Dogpile 공급자(예: brave-search, arxiv, github-search, youtube, brave-questions, feeds, wayback, context7)만 필요한 경우 반복 가능한 --dogpile-source 필터를 사용하십시오. 재사용 가능한 변형 계열에는 표현 동등성, 인코딩/정규화, 파서 차이, 릴리스 표면 경계, 손실 변환, 분할/구성된 사실, 규모, 재시도/동시성, 인증, 실패 누출 경계가 포함됩니다. Dogpile과 Ask는 연구 입력 전용입니다: 의미 있는 변형 계열과 소스 증거를 발견합니다. 그런 다음 Battle은 선택된 계열을 결정론적 생성기로 고정하고, Docker/QEMU/디지털 트윈 증거 게이트에서 실제 대상을 실행하고, 사례당 battle.case_receipt.v1을 내보내고, battle.campaign_aggregate.v1로 집계하며, 워크플로우 클래스를 $agentic-evals 사례로 유지합니다. 심각한 릴리스 게이트는 계약 표면이 넓을 때 수백 개의 결정론적 사례와 약 20-30개의 유지된 평가 클래스를 예상해야 합니다. 더 작은 스모크 게이트는 자신을 스모크라고 명시해야 합니다.

불변 속성 캠페인 (계약 기준 테스트 후 그 너머 공격)

불변 속성 배틀은 하나의 출력을 판단합니다. 불변 속성 캠페인은 레드가 대상 사양이 명명하는 입력 "버전"의 전체 MATRIX(모든 형식 x 모든 표현 x 문서화된 에지 케이스)와 무작위 퍼즈를 생성하고, 각각에 대해 실제 대상을 실행하며, 심사관이 모든 출력을 점수화합니다. 모든 사례는 fixture 사전 점검, 실행, 거부, 보안 심사관, 선택적 기능 심사관 및 평결 필드를 포함한 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에 있는 적어도 하나의 캠페인 생성기 사례에 매핑되지 않으면 fail-closed됩니다. 이는 추가 퍼즈 또는 계약 외 사례가 중요해지기 전에 반드시 통과해야 하는 최소한의 적대적 버전입니다. 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는 익명화 브리핑의 버전을 생성합니다: 네 가지 형식, JSON 문자열/정수/실수/과학적 표기법, SQLite TEXT/INTEGER/REAL, Unicode NFC/NFD, BOM, JSON \u-이스케이프, SQLite CHECK-리터럴, 그리고 퍼즈. 또한 oai-trial 원탁 회의 에지 케이스를 포함합니다: 포맷된 정책 전화 값이 숫자만 있는 JSON/SQLite 숫자로 저장됨, 모든 범위 내 형식에 걸쳐 동일한 ID 시드, 손실 선행 0 / 큰 실수 함정. fixtures/reference-generators/anon_beyond_brief_matrix.py는 개인정보보호/익명화 증명을 위한 필수 다음 단계입니다: 문자 그대로의 승인 계약을 넘어서는 명확하지 않은 스키마/경로/인코딩/로그/릴리스 표면을 시도합니다. 생성기 + 대상 실행 명령 + 심사관은 플러그 가능한 삼중항입니다: 모든 프로젝트의 사양 매트릭스와 불변 속성에 지정할 수 있습니다.

데이터 누출 방지 심사관은 변환 의미론을 위한 명시적 옵트인 해석 프로필도 지원합니다. 이러한 보증은 --judge-params에 선언되지 않는 한 OFF 상태이므로, 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 PASS는 레드가 계약 에지 케이스를 찾았고, 블루가 해당 레드 승리를 제거했으며, 독립적인 심사관 재생이 통과했음을 증명합니다.

그런 다음 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을 작성하고 사람용 Battle 보고서는 stderr에 유지합니다. 정상적인 프로젝트 에이전트 리뷰를 위해 --terminal-cards를 사용하십시오: 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 빨간색, 깨끗한 통과 녹색, fail-closed 중단 노란색)을 사용하고 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 오케스트레이터, 공급자 기반 하위 에이전트, Docker/QEMU 격리, 야간 스케줄러, 점수 기록부 또는 메모리 학습이 작동한다는 것을 증명하지 않습니다. PixiJS 증거만으로 핵심 Battle 준비 상태를 종결하지 말고, 진실된 영수증 검사 가능성을 넘어 재생 폴리시를 위해 백엔드 적응형 계보를 차단하지 마십시오.

아키텍처

프로덕션 Battle은 오케스트레이션 스킬이며, 대규모 맞춤형 보안 엔진이 아닙니다. 호스트 측 프로세스는 라운드를 예약하고, 페르소나를 선택하고, 하위 에이전트를 파견하고, Docker 런타임을 프로비저닝하고, 영수증을 수집하고, 하드 런타임 신호를 점수화하고, 보고서를 작성하고, 학습을 지속해야 합니다. 대상 코드와 팀 생성 코드는 Docker 내에서만 실행되어야 합니다.

필수 프로덕션 불변 속성:

• 레드와 블루는 하위 에이전트 팀입니다. 파견된 각 하위 에이전트는 해당 턴을 위해 오케스트레이터가 선택한 명시적 페르소나를 포함해야 합니다. 턴이 폭의 이점을 얻을 때 여러 페르소나가 동시에 실행될 수 있습니다.
• Battle 실행은 Docker, QEMU, 대상 런타임 설정, Hack 위임, 증명 재생 또는 패치 재생이 시작되기 전에 security.target_authorization.v1 매니페스트가 필요합니다. 매니페스트는 프로젝트/운영자 범위와 대상 ID를 바인딩합니다. 법적 의견이 아니며 착취 성공 또는 패치 효과를 증명하지 않습니다.
• 레드 팀 $hack 실행은 하위 에이전트 책임이며, Battle Python 임포트가 아닙니다. Battle은 스캔/연구/메모리 리콜을 수행하거나 예약하고, 후보 착취 목록을 작성하고, 레드 페르소나를 선택하고, 해당 계약으로 agent-skills/agents/Tau 하위 에이전트를 파견하고, 반환된 착취 영수증을 기록합니다.
• 하위 에이전트 핸드오프 및 영수증은 tau.agent_handoff.v1 및 tau.subagent_receipt.v1에서 사용되는 간결한 Tau 스타일 JSON 계약 형태를 따라야 하며, 별도의 임시 프로토콜보다는 Battle 특정 필드가 계층화됩니다.
• Battle은 모듈식 Tau 하위 에이전트 계약을 호출합니다. Tau와 루프/에이전틱 하네스는 하위 에이전트 실행을 소유하고 LLM/모델 호출자로 scillm을 사용합니다. Battle은 팀 선택, 페르소나 할당, Docker 런타임, 점수 기록, 아티팩트 및 메모리 정리를 소유합니다.

…

[번역을 위해 잘림]

라이선스 및 기여

이 스킬은 오픈 소스입니다. 자세한 내용은 저장소의 LICENSE 파일을 참조하십시오.