grahama1970/battle

ALTO. LEA TODO ESTE SKILL.MD ANTES DE LLAMAR A CUALQUIER ENDPOINT.

Habilidad Battle

Orquestador de Competencia de Seguridad entre Equipos Rojo vs Azul

Pone a un equipo Rojo (ataque) contra un equipo Azul (defensa) en un bucle competitivo de larga duración. Cada equipo aprovecha todas las habilidades .pi/skills para atacar o defender una base de código objetivo.

Batallas invariantes (el caso común)

La puntuación predeterminada de Battle apunta a la explotación (caída del sistema, inyección de comandos), pero el uso real más frecuente de un bucle adversarial Rojo/Azul es verificar una INVARIANTE ESPECÍFICA DEL PROYECTO: "ningún valor de información de identificación personal (PII) se filtra", "el libro mayor está equilibrado", "el analizador no descarta ningún registro", "la comprobación de autorización no se puede eludir".

Proporcione un Juez de invariante conectable: un módulo independiente pequeño judge(target_dir, params) -> {passed, violations, evidence} (esquema battle.invariant_result.v1). El objetivo de Rojo se convierte en "producir una entrada que haga fallar al Juez"; el de Azul es "hacer que pase"; el marcador lee el resultado del Juez, nunca un auto-reporte de un agente. Los jueces fallan en modo cerrado: un juez que produce un error es una invariante FALLIDA, nunca un pase silencioso.

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 es la invariante de confidencialidad de anonimización como Juez: escanea de forma independiente la salida publicada (escalares JSON incluidos escapes decodificados, expansión numérica, celdas SQLite + DDL de esquema + enteros de cabecera, texto/CSV, report.json, y stdout/stderr capturado) en busca de cualquier valor de política en cualquier representación.

Investigación de familias de variación de contratos (composición Battle genérica)

Battle no es específico de un proyecto. Para cualquier proyecto o habilidad con un acceptance_contract.bundle.v1, Battle debe expandir cada elemento del contrato a través de Dogpile antes de reclamar una cobertura adversarial completa:

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

La salida es battle.contract_variation_plan.v1. Es un contrato Battle de tres fases, no una nota suelta:

1. Fase 1: pasar el mínimo del acceptance_contract.bundle.v1 congelado.
2. Fase 2: después de ese pase, recopilar $project-state, recibos Battle actuales, investigación $dogpile filtrada por fuente y propuestas de revisor $ask one-shot.
3. Fase 3: congelar los hallazgos útiles de la Fase 2 en casos deterministas, ejecutarlos y retener pruebas de linaje adaptable para victorias de Rojo, correcciones de Azul y reproducción.

El plan asigna cada caso de aceptación a carriles de investigación Dogpile con fuente y familias de variación reutilizables. Use filtros --dogpile-source repetibles cuando una fase de Battle necesite solo proveedores Dogpile seleccionados como brave-search, arxiv, github-search, youtube, brave-questions, feeds, wayback o context7 en lugar del abanico completo de fuentes. Las familias de variación reutilizables incluyen equivalencia de representación, codificación/normalización, diferenciales de analizador, límites de superficie de publicación, conversión con pérdida, hechos divididos/compuestos, escala, reintento/concurrencia, autorización y límites de fuga por fallo. Dogpile y Ask son solo entrada de investigación: descubren familias de variación significativas y evidencia de fuente. Battle luego congela las familias seleccionadas en generadores deterministas, ejecuta el objetivo real en compuertas de evidencia Docker/QEMU/gemelo digital, emite battle.case_receipt.v1 por caso, agrega con battle.campaign_aggregate.v1 y retiene las clases de flujo de trabajo como casos $agentic-evals. Una compuerta de publicación seria debería esperar cientos de casos deterministas y aproximadamente 20-30 clases de evaluación retenidas cuando la superficie del contrato es amplia; las compuertas más pequeñas para pruebas de humo deben etiquetarse como humo.

Campañas invariantes (probar el mínimo del contrato, luego atacar más allá)

Una batalla invariante juzga una salida. Una campaña invariante hace que Rojo genere la MATRIZ completa de "versiones" de entrada que el nombre de la especificación del objetivo menciona: cada formato x cada representación x los casos límite documentados, ADEMÁS de fuzzing aleatorio, ejecuta el objetivo real en cada una, y el Juez puntúa cada salida. Cada caso emite un battle.case_receipt.v1 con campos de pre-verificación del fixture, ejecución, rechazo, Juez de seguridad, Juez funcional opcional y veredicto. Una campaña PASA solo si todos los recibos de caso pasan, los casos MUST_ACCEPT requeridos son realmente aceptados y juzgados funcionalmente, los casos MUST_REJECT requeridos son rechazados de forma segura, y el battle.campaign_aggregate.v1 calculado no tiene casos fallidos o incompletos. Una versión fallida es una victoria de Rojo concreta y reproducible.

Para objetivos de anonimización/privacidad, el contrato de aceptación es solo el mínimo. Cuando existe un acceptance_contract.bundle.v1, la construcción del escenario puede pasarlo como acceptance_floor al adaptador de producción. Battle entonces falla en modo cerrado a menos que cada id de acceptance_cases[] se asigne a al menos un caso de generador de campaña en los required_case_ids del perfil; esos son los versiones adversariales mínimas que DEBEN pasar antes de que importe cualquier fuzzing adicional o casos fuera del contrato. Battle también debe ejecutar una campaña fuera del contrato que ataque superficies que un informe de cliente a menudo omite: claves JSON y claves duplicadas, cabeceras/dialectos/celdas multilínea CSV, identificadores/predeterminados/valores generados/índices parciales/disparadores SQLite, nombres de archivo, report.json, stdout/stderr, codificaciones alternativas y trampas de representación de la misma identidad. Una reproducción limpia de la matriz del informe por sí sola es una prueba de humo, no una prueba Battle completa.

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 produce las versiones del informe de anonimización: los cuatro formatos, cadena JSON/entero/flotante/científico, SQLite TEXTO/ENTERO/REAL, Unicode NFC/NFD, BOM, JSON \u-escape, SQLite CHECK-literal, además de fuzzing. También lleva los casos límite de la mesa redonda de oai-trial: valores de teléfono de política formateados almacenados como valores numéricos JSON/SQLite solo dígitos, la misma identidad sembrada en todos los formatos dentro del alcance, y trampas de pérdida de cero a la izquierda / flotante grande. fixtures/reference-generators/anon_beyond_brief_matrix.py es el siguiente escalón requerido para la prueba de privacidad/anonimización: intenta superficies de esquema/ruta/codificación/registro/límite de publicación no obvias que van más allá del contrato de aceptación literal. Un generador + comando de ejecución objetivo + juez es un trío conectable: apúntelo a la matriz de especificaciones e invariante de cualquier proyecto.

El Juez de no-fuga-de-datos también soporta un perfil de interpretación explícito de suscripción opcional para semánticas de transformación. Estas garantías están DESACTIVADAS a menos que se declaren en --judge-params, por lo que Battle no expande silenciosamente el contrato después de ver una falla:

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

Con ese perfil, los valores completos escalares/token base64/base64url/hex se decodifican una vez y los campos escalares JSON/CSV/SQLite adyacentes a nivel de registro pueden reconstruir un valor de política completo. La decodificación recursiva arbitraria, las uniones de campos globales y el plegado de caracteres visualmente confusibles permanecen fuera de la compuerta de bloqueo predeterminada.

Después de que Rojo encuentre casos fallidos y Azul parchee el objetivo, emita el recibo de linaje reproducible en lugar de resumir en 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

Un PASE battle.invariant_adaptive_lineage.v1 prueba que Rojo encontró casos límite del contrato, Azul eliminó esas victorias de Rojo y la reproducción del Juez independiente pasó.

Luego Battle debe producir un informe validado por $create-report con contexto $project-state y una tabla de explotaciones explícita. El informe es el artefacto de decisión legible por humanos; los recibos siguen siendo la autoridad. Primero genere el estado del proyecto nuevo, luego renderice el informe:

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 revisión terminal por parte del agente del proyecto, use tarjetas cuando los casos tengan evidencia extensa:

./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 es un comando CLI de Typer. Escribe JSON de máquina en stdout y mantiene el informe Battle humano en stderr. Use --terminal-cards para la revisión normal del agente del proyecto de la evidencia de Battle: agrupa tarjetas bajo los encabezados Mínimo del contrato de aceptación, Explotaciones fuera del contrato, Linaje adaptable y Otros casos de campaña de respaldo, luego imprime un bloque ============== por caso con Alcance, Caso, Padre de aceptación, Esperado, Resultado, Ejemplo, Por qué Battle verifica esto, Investigación relacionada, Linaje adaptable y Evidencia del Juez. Si un recibo del adaptador de producción lleva acceptance_floor.case_map, las tarjetas del mínimo del contrato muestran los id(s) padre AC-*; de lo contrario, Padre de aceptación es no registrado en el recibo del caso. Si un recibo tiene example, why_chosen, research_refs o source_refs, las tarjetas muestran esos campos exactos; de lo contrario, los ejemplos/razones son deterministas a partir del id del caso y la investigación se informa como no registrada en el recibo del caso.

--terminal-table sigue siendo el alias de vista general compacta para --terminal-summary: ambos imprimen el mínimo del contrato, presión de Rojo, llamada del marcador y una fila de tabla por ataque. En un terminal interactivo, Battle usa la tabla coloreada consciente del terminal de Rich (RED_WIN rojo, pases limpios verde, paradas por fallo cerrado amarillo) y respeta NO_COLOR; bajo captura/CI, vuelve a texto plano determinista para que los registros y pruebas se mantengan estables.

invariant-report escribe create_report.report.v1, lo valida a través de skills/create-report/run.sh validate, renderiza Markdown a través de skills/create-report/run.sh render y añade ## Tabla de Explotaciones. La tabla debe ser directa y escaneable: una fila por caso de ataque, con columnas para Alcance, ¿Contractual?, ¿Linaje adaptable?, Caso, Explotación / ataque, Por qué se eligió, Expectativa, Resultado y Evidencia del Juez. Alcance separa los casos contractuales del mínimo de aceptación de las sondas fuera del contrato; Por qué se eligió explica las sondas no contractuales; ¿Linaje adaptable? marca las victorias de Rojo que fueron corregidas y reproducidas; RED_WIN bloquea la publicación. La tabla se deriva de battle.case_receipt.v1 cuando está presente, recurriendo a case_log heredado solo para recibos de campaña más antiguos. Un cierre de Battle sin ese informe carece de la superficie de decisión incluso si los recibos de campaña pasan.

Límite de Propósito

El propósito de Battle es el backend de competencia de seguridad Rojo/Azul: configuración autorizada del objetivo, ejecución aislada, generación de ataques de Rojo, generación de defensas de Azul, reproducción independiente del Juez, recibos del marcador, linaje adaptable y aprendizaje duradero. El linaje adaptable es un bucle de aprendizaje de backend que genera, evalúa, selecciona y promueve o rechaza evidencia hija de Rojo/Azul a partir de recibos respaldados por el Juez.

PixiJS es solo una superficie de espectador/reproducción para los recibos de Battle. Un pase de PixiJS prueba que los recibos registrados se pueden inspeccionar en una reproducción divertida; no prueba que el orquestador de Battle, los subagentes impulsados por proveedores, el aislamiento Docker/QEMU, el planificador nocturno, el marcador o el aprendizaje en memoria funcionen. No cierre la preparación central de Battle basándose solo en la evidencia de PixiJS, y no bloquee el linaje adaptable del backend en pulido de reproducción más allá de la inspeccionabilidad veraz del recibo.

Arquitectura

La Battle de producción es una habilidad de orquestación, no un gran motor de seguridad personalizado. El proceso del lado del anfitrión debe programar rondas, elegir personajes, despachar subagentes, aprovisionar entornos de ejecución Docker, recopilar recibos, puntuar señales de ejecución en tiempo real, escribir informes y persistir el aprendizaje. El código objetivo y el código generado por el equipo deben ejecutarse solo dentro de Docker.

Invariantes de producción requeridas:

• Rojo y Azul son equipos de subagentes. Cada subagente despachado debe incluir un personaje explícito seleccionado por el orquestador para ese turno. Múltiples personajes por equipo pueden ejecutarse simultáneamente cuando el turno se beneficia de la amplitud.
• La ejecución de Battle requiere un manifiesto security.target_authorization.v1 antes de que comiencen Docker, QEMU, la configuración del entorno de ejecución objetivo, la delegación de Hack, la reproducción de pruebas o la reproducción de parches. El manifiesto vincula el alcance del proyecto/operador y la identidad del objetivo; no es una opinión legal y no prueba el éxito de la explotación o la efectividad del parche.
• La ejecución de $hack del equipo Rojo es una responsabilidad del subagente, no una importación de Python de Battle. Battle realiza o programa escaneo/investigación/recuperación de memoria, construye la lista de explotaciones candidatas, elige el personaje de Rojo, despacha un subagente agent-skills/agents/Tau con ese contrato y registra el recibo de explotación devuelto.
• Las transferencias y recibos de subagentes deben seguir la forma compacta del contrato JSON estilo Tau utilizada por tau.agent_handoff.v1 y tau.subagent_receipt.v1, con campos específicos de Battle superpuestos en lugar de un protocolo ad hoc separado.
• Battle llama a contratos modulares de subagentes Tau. Tau y el arnés de bucle/agente son dueños de la ejecución del subagente y usan scillm como el llamador de LLM/modelo. Battle es dueño de la selección del equipo, la asignación de personajes, los entornos de ejecución Docker, el marcador, los artefactos y la memoria pr...