grahama1970/battle

PARE. LEIA ESTE SKILL.MD COMPLETO ANTES DE CHAMAR QUALQUER ENDPOINT.

Skill Battle

Orquestrador de Competição de Segurança entre Equipe Vermelha e Equipe Azul

Coloca uma Equipe Vermelha (ataque) contra uma Equipe Azul (defesa) em um loop competitivo de longa duração. Cada equipe aproveita todas as skills .pi/skills para atacar ou defender uma base de código alvo.

Batalhas invariantes (o caso comum)

A pontuação padrão da Battle tem como alvo exploração (derrubada do sistema, injeção de comandos), mas o uso real mais frequente de um loop adversarial Vermelho/Azul é verificar um INVARIANTE ESPECÍFICO DO PROJETO: "nenhum valor de PII vaza", "o saldo do ledger está consistente", "o parser não descarta nenhum registro", "a verificação de autorização não pode ser contornada".

Forneça um Juiz de invariante plugável -- um pequeno módulo independente judge(target_dir, params) -> {passed, violations, evidence} (esquema battle.invariant_result.v1). O objetivo do Vermelho passa a ser "produzir uma entrada que faça o Juiz falhar"; o do Azul é "fazê-lo passar"; o marcador de pontos lê o resultado do Juiz, nunca um autorrelato do agente. Os Juízes são fechados em caso de falha: um juiz que erra é um invariante FALHO, nunca uma aprovação silenciosa.

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 é o invariante de confidencialidade do anonimizador como um Juiz: ele verifica independentemente a saída liberada (escalares JSON incluindo escapes decodificados, expansão numérica, células SQLite + DDL de esquema + inteiros de cabeçalho, texto/CSV, report.json e stdout/stderr capturados) em busca de qualquer valor de política em qualquer representação.

Pesquisa de variação contratual (composição genérica da Battle)

A Battle não é específica de projeto. Para qualquer projeto ou skill com um acceptance_contract.bundle.v1, a Battle deve expandir cada item de contrato através do Dogpile antes de reivindicar cobertura adversarial abrangente:

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

A saída é battle.contract_variation_plan.v1. É um contrato de Battle de três fases, não uma nota solta:

1. Fase 1: passar o piso congelado acceptance_contract.bundle.v1.
2. Fase 2: após essa aprovação, reunir $project-state, recibos atuais da Battle, pesquisa $dogpile filtrada por fonte e propostas de revisão $ask one-shot.
3. Fase 3: congelar descobertas úteis da Fase 2 em casos determinísticos, executá-los e reter prova de linhagem adaptativa para vitórias do Vermelho, correções do Azul e repetição.

O plano mapeia cada caso de aceitação para faixas de pesquisa Dogpile com fonte e famílias de variação reutilizáveis. Use filtros --dogpile-source repetíveis quando uma fase da Battle precisar apenas de provedores Dogpile selecionados, como brave-search, arxiv, github-search, youtube, brave-questions, feeds, wayback, ou context7 em vez da propagação completa da fonte. As famílias de variação reutilizáveis incluem equivalência de representação, codificação/normalização, diferenciais de parser, limites de superfície de liberação, conversão com perda, fatos divididos/compostos, escala, reintento/concorrência, autorização e limites de vazamento de falha. Dogpile e Ask são apenas entrada de pesquisa: eles descobrem famílias de variação significativas e evidências de fonte. A Battle então congela famílias selecionadas em geradores determinísticos, roda o alvo real em portas de evidência Docker/QEMU/gêmeo digital, emite battle.case_receipt.v1 por caso, agrega com battle.campaign_aggregate.v1 e retém as classes de fluxo de trabalho como casos $agentic-evals. Uma porta de liberação séria deve esperar centenas de casos determinísticos e aproximadamente 20-30 classes de eval retidas quando a superfície do contrato é ampla; portas de fumaça menores devem se rotular como fumaça.

Campanhas invariantes (testar o piso do contrato, depois atacar além dele)

Uma batalha invariante julga uma saída. Uma campanha invariante faz o Vermelho gerar toda a MATRIZ de "versões" de entrada que a especificação do alvo nomeia -- cada formato x cada representação x os casos extremos documentados -- MAIS fuzz aleatório, executa o alvo real em cada um, e o Juiz pontua cada saída. Cada caso emite um battle.case_receipt.v1 com pré-verificação de fixture, execução, rejeição, Juiz de segurança, Juiz funcional opcional e campos de veredito. Uma campanha PASSA apenas se todos os recibos de caso passarem, os casos MUST_ACCEPT exigidos forem realmente aceitos e julgados funcionalmente, os casos MUST_REJECT exigidos forem rejeitados com segurança, e o battle.campaign_aggregate.v1 calculado não tiver casos falhos ou incompletos. Uma versão falha é uma vitória concreta e reproduzível do Vermelho.

Para alvos de anonimização/privacidade, o contrato de aceitação é apenas o piso. Quando um acceptance_contract.bundle.v1 existe, a construção da arena pode passá-lo como acceptance_floor para o adaptador de produção. A Battle então falha fechada a menos que cada id acceptance_cases[] mapeie para pelo menos um caso gerador de campanha no perfil do required_case_ids; esses são as versões adversariais mínimas que DEVEM passar antes que qualquer fuzz extra ou casos além do contrato importem. A Battle também deve executar uma campanha além do contrato que ataque superfícies que um briefing de cliente frequentemente omite: chaves JSON e chaves duplicadas, cabeçalhos/dialetos/células multilinha CSV, identificadores/padrões/valores gerados/índices parciais/gatilhos SQLite, nomes de arquivo, report.json, stdout/stderr, codificações alternativas e armadilhas de representação de mesma identidade. Uma repetição limpa da matriz do briefing sozinha é uma prova de fumaça, não uma prova abrangente da 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 produz as versões do briefing de anonimização: os quatro formatos, JSON string/int/float/cientific, SQLite TEXT/INTEGER/REAL, Unicode NFC/NFD, BOM, JSON \u-escape, SQLite CHECK-literal, além de fuzz. Também carrega os casos extremos da mesa redonda oai-trial: valores de telefone de política formatados armazenados como numéricos JSON/SQLite apenas dígitos, a mesma identidade propagada em todos os formatos no escopo e armadilhas de perda de zero à esquerda / grande float. fixtures/reference-generators/anon_beyond_brief_matrix.py é o degrau exigido para prova de privacidade/anonimização: tenta superfícies de esquema/caminho/codificação/ log/liberação não óbvias que vão além do contrato de aceitação literal. Um gerador + target-run-cmd + juiz é um trio plugável: aponte para a matriz de especificação e invariante de qualquer projeto.

O Juiz sem vazamento de dados também suporta um perfil de interpretação explícito opcional para semântica de transformação. Essas garantias estão DESLIGADAS a menos que declaradas em --judge-params, então a Battle não expande silenciosamente o contrato após ver uma falha:

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

Com esse perfil, valores escalares/token base64/base64url/hex inteiros são decodificados uma vez e campos escalares adjacentes no registro local JSON/CSV/SQLite podem reconstruir um valor de política completo. Decodificação recursiva arbitrária, junções globais de campos e dobra de caracteres visualmente confusos permanecem fora da porta de bloqueio padrão.

Após o Vermelho encontrar casos falhos e o Azul corrigir o alvo, emita o recibo de linhagem reproduzível em vez de resumir em prosa:

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

Um PASS battle.invariant_adaptive_lineage.v1 prova que o Vermelho encontrou casos extremos do contrato, o Azul removeu essas vitórias do Vermelho e a repetição independente do Juiz passou.

Em seguida, a Battle deve produzir um relatório validado por $create-report com contexto $project-state e uma tabela de explorações explícita. O relatório é o artefato de decisão legível por humanos; os recibos permanecem a autoridade. Gere primeiro o estado atual do projeto e, em seguida, renderize o relatório:

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

Para revisão terminal do agente de projeto, use cards quando os casos tiverem evidências longas:

./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 é um comando CLI Typer. Ele escreve JSON de máquina no stdout e mantém o relatório humano da Battle no stderr. Use --terminal-cards para revisão normal do agente de projeto da evidência da Battle: agrupa cards sob os cabeçalhos Piso do contrato de aceitação, Explorações além do contrato, Linhagem adaptativa e Outros casos de campanha, e então imprime um bloco ============== por caso com Escopo, Caso, Pai de aceitação, Expectativa, Resultado, Exemplo, Por que a Battle verifica isso, Pesquisa relacionada, Linhagem adaptativa e Evidência do Juiz. Se um recibo do adaptador de produção carregar acceptance_floor.case_map, cards do piso do contrato mostram o(s) id(s) pai AC-*; caso contrário, Pai de aceitação é não registrado no recibo do caso. Se um recibo tiver example, why_chosen, research_refs ou source_refs, os cards mostram esses campos exatos; caso contrário, exemplos/racionais são determinísticos a partir do id do caso e a pesquisa é relatada como não registrada no recibo do caso.

--terminal-table permanece o alias de visão geral compacta para --terminal-summary: ambos imprimem o piso do contrato, pressão do Vermelho, chamada do Scorekeeper e uma linha de tabela de caso por ataque. Em um terminal interativo, a Battle usa a tabela colorida consciente de terminal do Rich (RED_WIN vermelho, passes limpos verde, paradas falhadas amarelo) e honra NO_COLOR; sob captura/CI, ela recai para texto simples determinístico para que logs e testes permaneçam estáveis.

invariant-report escreve create_report.report.v1, valida através de skills/create-report/run.sh validate, renderiza Markdown através de skills/create-report/run.sh render e anexa ## Tabela de Explorações. A tabela deve ser direta e escaneável: uma linha por caso de ataque, com colunas para Escopo, Contratual?, Linhagem adaptativa?, Caso, Exploração / ataque, Por que escolhido, Expectativa, Resultado e Evidência do Juiz. Escopo separa casos contratuais do piso de aceitação de sondas além do contrato; Por que escolhido explica sondas não contratuais; Linhagem adaptativa? marca vitórias do Vermelho que foram corrigidas e repetidas; RED_WIN bloqueia a liberação. A tabela é derivada de battle.case_receipt.v1 quando presente, recorrendo a case_log legado apenas para recibos de campanha mais antigos. Um fechamento da Battle sem esse relatório está faltando a superfície de decisão, mesmo que os recibos da campanha passem.

Limite de Propósito

O propósito da Battle é o backend da competição de segurança Vermelho/Azul: configuração de alvo autorizada, execução isolada, geração de ataque do Vermelho, geração de defesa do Azul, repetição independente do Juiz, recibos do Scorekeeper, linhagem adaptativa e aprendizado durável. Linhagem adaptativa é um loop de aprendizado do backend que gera, avalia, seleciona e promove ou rejeita evidências Vermelho/Azul filhas de recibos apoiados pelo Juiz.

PixiJS é apenas uma superfície de espectador/repetição para recibos da Battle. Uma aprovação no PixiJS prova que recibos registrados podem ser inspecionados em uma repetição divertida; não prova que o orquestrador da Battle, subagentes orientados por provedores, isolamento Docker/QEMU, agendador noturno, Scorekeeper ou aprendizado de memória funcionam. Não conclua a prontidão central da Battle a partir de evidências do PixiJS sozinhas e não bloqueie a linhagem adaptativa do backend em polimento de repetição além da inspecionabilidade verdadeira do recibo.

Arquitetura

A Battle de produção é uma skill de orquestração, não um grande mecanismo de segurança personalizado. O processo do lado do host deve agendar rodadas, escolher personas, despachar subagentes, provisionar runtimes Docker, coletar recibos, pontuar sinais de runtime difíceis, escrever relatórios e persistir aprendizado. O código alvo e o código gerado pela equipe devem ser executados apenas dentro do Docker.

Invariantes de produção exigidos:

• Vermelho e Azul são equipes de subagentes. Cada subagente despachado deve incluir uma persona explícita selecionada pelo orquestrador para aquela rodada. Múltiplas personas por equipe podem ser executadas simultaneamente quando a rodada se beneficia de amplitude.
• A execução da Battle requer um manifesto security.target_authorization.v1 antes de Docker, QEMU, configuração de runtime alvo, delegação de Hack, repetição de prova ou repetição de patch começar. O manifesto vincula o escopo do projeto/operador e a identidade do alvo; não é uma opinião legal e não prova sucesso de exploração ou eficácia de patch.
• A execução de $hack da equipe Vermelha é uma responsabilidade do subagente, não uma importação Python da Battle. A Battle realiza ou agenda varredura/pesquisa/recuperação de memória, constrói a lista de explorações candidatas, escolhe a persona do Vermelho, despacha um subagente agent-skills/agents/Tau com esse contrato e registra o recibo de exploração retornado.
• Repasses e recibos de subagentes devem seguir a forma de contrato JSON compacta do estilo Tau usada por tau.agent_handoff.v1 e tau.subagent_receipt.v1, com campos específicos da Battle sobrepostos em vez de um protocolo ad hoc separado.
• A Battle chama contratos de subagente Tau modulares. Tau e o harness de loop/agente são donos da execução do subagente e usam scillm como o chamador LLM/modelo. A Battle é dona da seleção de equipe, atribuição de persona, runtimes Docker, pontuação, artefatos e memória.

…

[truncado para tradução]