Wargame Battle Plans

Skill: War-games — battle-plans ejecutables a ciegas

Usa Sonnet u Opus con el criterio del mejor modelo (Fable 5) sin pagar el modelo top.

Destilas el juicio del modelo más caro y capaz que tengas hoy en un documento estático — un battle-plan — y dejas que un modelo más barato lo ejecute con ese criterio ya pre-cocinado. Un plan normal asume el camino feliz. Un war-game lucha la misión sobre el papel, movimiento a movimiento, anticipando cada fallo probable, sus señales y su contramaniobra. Patrón probado en producción.

¿Cuándo usar este patrón?

• Antes de una misión técnica con riesgo real: un deploy a producción, una migración de datos, un envío masivo de emails a clientes, una operación destructiva (borrar, force-push, tocar DNS o una BD viva).
• Cuando el coste de un fallo silencioso es alto: un email que llega a quien no debía, un cron que vacía el crontab del servidor, un doble envío, una tabla pisada.
• Cuando quieres que el ejecutor sea otro agente (más barato, o en otra sesión, o dentro de un mes) y no tendrá tu contexto actual.
• Cuando la realidad puede cambiar entre que se planifica y se ejecuta (estados de ramas, servicios vivos, decisiones pendientes de un humano).

NO usar para:

• Tareas triviales o reversibles de un solo paso. Es sobre-ingeniería.
• Cosas que vas a ejecutar tú mismo, ahora, con todo el contexto en la cabeza. El war-game vale precisamente porque separa quien piensa de quien ejecuta.

Por qué este patrón existe

1. El modelo top es caro y a veces efímero. El mejor modelo disponible en cualquier momento (hoy puede ser Fable 5; mañana, otro) tiene un criterio que los modelos baratos no replican por sí solos: anticipa fallos, lee señales, sabe cuándo abortar. Ese criterio se puede embotellar una vez y reutilizar muchas.
2. Un plan del camino feliz miente. "Haz A, luego B, luego C" no dice qué haces cuando B devuelve un 403, o cuando C ya se ejecutó ayer sin que lo sepas. El war-game convierte cada paso en una bifurcación con salida.
3. El ejecutor no tiene tu contexto. El agente que corre la misión dentro de dos semanas no vio esta conversación. Si algo no está escrito en el battle-plan o enlazado por ruta, para él no existe.
4. Model-agnostic y future-proof. Cuando salga un modelo mejor, no reescribes tus runbooks: re-generas los war-games con él y el criterio embotellado sube de nivel solo.

El principio central: un war-game NO es un plan

Tres reglas que definen el método:

• No es un plan. Lucha la misión movimiento a movimiento: acción → observación esperada → fallo más probable (causa + señales) → contramaniobra → triggers de bifurcación → condiciones de aborto.
• No duplica documentación. El war-game enlaza a los PRDs, READMEs, fichas y notas que ya existen; solo aporta la capa dinámica que esos documentos no tienen.
• No se ejecuta al redactarse. Se escribe en papel. Lo ejecuta después otro modelo/agente, con un humano en el bucle allí donde el war-game lo exija.

El estándar de los 8 puntos

Un battle-plan solo está TERMINADO si cumple los 8. El red-team (ver más abajo) los verifica uno por uno, intentando romperlo.

1. Observaciones esperadas. Cada movimiento declara QUÉ VERÁS si funcionó y QUÉ VERÁS si no: comando + salida esperada, pantalla esperada, estado esperado. Sin observación esperada, un ejecutor barato no sabe si va bien.

2. Contramaniobras. Cada movimiento lleva su fallo MÁS PROBABLE con su causa, sus señales observables y la contramaniobra concreta — no "revisar el error", sino los pasos exactos.

3. Triggers de bifurcación. Cada fork del camino tiene un trigger explícito: "si observas X → ruta A; si observas Y → ruta B". El ejecutor nunca decide a ojo.

4. Flags de recon + VARIABLES marcadas. El war-game abre con una fase de RECONOCIMIENTO (qué re-verificar en runtime antes del primer movimiento). Todo supuesto que el redactor NO pudo resolver queda marcado como (VARIABLE: descripción) y volcado a un LEDGER. Nada inventado, nada asumido en silencio.

5. Condiciones de aborto. Lista explícita de situaciones en las que el ejecutor DEBE parar y escalar al humano-en-el-bucle (pérdida de acceso, datos en riesgo, coste inesperado, supuesto crítico roto) — con el estado en que debe dejar las cosas al abortar (rollback / como estaba).

6. Pasadas de verificación. Al final, la batería de comprobaciones del resultado completo: smoke tests, comandos, URLs, criterios de aceptación medibles. No "debería funcionar".

7. Red-team pass. Un agente DISTINTO del redactor ha intentado romper el war-game contra estos 8 puntos y sus hallazgos están incorporados. La autoevaluación no cuenta.

8. Ejecutabilidad a ciegas. Un modelo SIN acceso a la conversación original ni contexto previo puede ejecutar el war-game: rutas completas, comandos completos, referencias a documentos por ruta, credenciales señaladas por su UBICACIÓN (gestor de secretos / .env — jamás el valor), y el ejecutor objetivo declarado en la cabecera.

El workflow generador: redactor → red-team → reparador

El battle-plan de calidad no sale de una sola pasada. Es un pipeline de 3 etapas, idealmente lanzado como workflow multi-agente:

   ┌─────────────┐      ┌──────────────────┐      ┌──────────────┐
   │  REDACTOR   │  →   │    RED-TEAM      │  →   │  REPARADOR   │
   │ mejor modelo│      │ agente DISTINTO  │      │ aplica los   │
   │ disponible  │      │ intenta romperlo │      │ hallazgos    │
   │ (p.ej. Fable│      │ contra los 8     │      │ al plan      │
   │  5)         │      │ puntos           │      │              │
   └─────────────┘      └──────────────────┘      └──────────────┘

• REDACTOR — el mejor modelo que tengas. Lee el brief y los documentos de referencia, y produce el battle-plan luchando la misión sobre el papel. Marca como (VARIABLE: …) todo lo que no puede resolver.
• RED-TEAM — un agente distinto (no el redactor: la autoevaluación no cuenta). Su única misión es romper el plan: buscar movimientos sin observación esperada, contramaniobras vagas, bifurcaciones implícitas, supuestos no verificados, comandos que asumen contexto. Devuelve una lista de hallazgos.
• REPARADOR — aplica los hallazgos del red-team al battle-plan. El resultado es el documento final, firmado con quién redactó, quién hizo red-team y qué hallazgos se incorporaron.

El LEDGER de variables. Todas las (VARIABLE: …) sin resolver se consolidan en una tabla, para que el humano las resuelva ANTES de que el ejecutor llegue a los movimientos que las necesitan:

• [recon] = se resuelve en runtime, durante la fase de RECON (no necesita a nadie).
• [humano] = decisión de negocio o de riesgo que solo un humano puede tomar.

La plantilla del battle-plan (las 8 secciones)

Todo battle-plan sigue esta estructura. Escríbelo en un fichero por misión (wargames/<Mxx>-<slug>.md).

1. Cabecera — tabla con: fecha de redacción (es una foto fechada), misión (1 párrafo denso), ejecutor objetivo, tiempo estimado, regla de oro de la misión, y documentos de referencia por ruta (leer ANTES de ejecutar). Si el recon del redactor descubre algo que contradice el brief, un bloque "hallazgo del reconocimiento".

2. Fase RECON — qué re-verificar en runtime ANTES del primer movimiento. Cada check R1, R2, … con: comando concreto → qué esperar → trigger si no cuadra. Ningún check de recon modifica nada (solo lectura). La realidad de hoy puede no ser la del día de ejecución.

3. Movimientos numerados — el cuerpo. Cada Mov. N con:

   • Acción (comandos/pasos literales)
   • Observación esperada (si funcionó / si no)
   • Fallo más probable (causa + señales observables)
   • Contramaniobra (pasos concretos)
   • 🔀 Triggers de bifurcación donde el camino se abre.

4. Triggers de bifurcación — integrados en los movimientos (marcados 🔀). Nunca "usa tu criterio": siempre "si X → A; si Y → B".

5. VARIABLES — supuestos irresolubles marcados (VARIABLE V#: …) en el texto Y volcados al LEDGER.

6. Condiciones de aborto — tabla: situación → señales → estado en que dejar las cosas. Con una regla transversal de qué hacer siempre al abortar (dejar en modo seguro, log intacto, nota fechada).

7. Pasadas de verificación — batería numerada y medible que se corre al final (y de nuevo tras el primer ciclo real).

8. Firma — quién redactó (y con qué modelo), quién hizo el red-team, qué hallazgos se incorporaron.

Reglas de seguridad del método (no negociables)

• Idioma consistente. El battle-plan en el idioma del equipo; comandos y rutas literales.
• Jamás valores de secretos. Solo su UBICACIÓN (gestor de secretos, ruta de un fichero 600, variable de entorno). Nunca el valor en claro.
• Operaciones destructivas (BD, DNS, borrados, force-push): SIEMPRE detrás de tres cosas — (a) una condición de "ventana con el responsable" (un humano presente y avisado), (b) backup previo verificado, (c) plan de rollback como primer movimiento de la rama destructiva.
• Cabecera con fecha + ejecutor objetivo + tiempo estimado. Un war-game caduca; la fecha y el RECON lo protegen.

Ejemplo completo (anonimizado): informe mensual automático a clientes por email

Misión genérica reutilizable: cada día 1 del mes, un cron en <servidor> genera un informe HTML de marca con las métricas del mes de cada cliente (analítica web + rendimiento en buscadores) y lo envía por email. Con censo de clientes, idempotencia (jamás doble envío), reintentos, un mes de preview obligatorio (todo al equipo, cero a clientes) y verificación con clientes control.

Este ejemplo muestra la anatomía real de un battle-plan. Adáptalo a tu stack.

Cabecera

Documentos de referencia (por ruta): el molde de un notifier/allowlist ya probado, el script piloto mono-cliente si existe, la config de secretos, la doc del CRM de clientes.

Fase RECON (solo lectura — cada check con su trigger)

• R1 — ¿Existe ya un piloto? git log --oneline -5 -- scripts/informe-mensual/. Esperado: aparece el script base. Trigger: si no existe, buscar antes de asumir (git log --all | grep -i informe); si sigue sin aparecer → construir desde el molde notifier, pero parar y preguntar (aborto A6): un piloto validado no desaparece solo.
• R2 — Estado en el servidor. ssh <servidor> 'ls -la <ruta>/informe-mensual/ ; crontab -l | grep informe'. Trigger A: carpeta + cron → adoptar y extender. Trigger B: carpeta sin cron → el cron se instala en Mov. 9. Trigger C: no existe → el deploy de Mov. 8 la crea (sin backup previo, no hay nada que pisar).
• R3 — Secretos presentes (solo existencia y permisos, JAMÁS el contenido). ssh <servidor> 'ls -l <ruta-secretos>/'. Esperado: los ficheros existen, permisos 600, owner correcto. Si falta el secreto SMTP → buscarlo en el gestor de secretos; su instalación la hace un humano por el protocolo de rotación (scp directo, sin pasar por el chat). NO continuar a movimientos de envío sin él.
• R4 — La lectura de datos sigue viva (smoke de solo lectura, sin envío). Ejecutar el script en modo --dry sobre un cliente conocido. Esperado: HTML generado + cifras > 0. Fallo probable: 403 PERMISSION_DENIED → la service account perdió acceso; contramaniobra: re-grant. Si invalid_grant → key rotada: escalar (aborto A2). ⚠️ Ojo con las variables de entorno obligatorias: sin la variable que apunta a la key, el default del script puede ser una ruta de otro sistema operativo y dar FileNotFoundError — eso NO es problema de permisos.
• R5 — CRM de clientes accesible (para el censo). GET de solo lectura. Anota qué columnas hay: interesa si existe un campo de email de contacto. Trigger: si no hay columna de email → la fuente de emails es la allowlist + fichas + el humano (VARIABLE V1). NUNCA inventar un email.
• R6 — Dependencias en el servidor (runtime + CLI que usen las verificaciones). Comprobar imports y binarios. Contramaniobra si falta: usar el venv correcto y ajustar el wrapper.
• R7 — Entregabilidad DNS vigente (SPF/DKIM del dominio remitente). nslookup -type=TXT <dominio>. Trigger: si el SPF no incluye el servidor de correo → NO activar ningún envío (ni preview): llegarían como sospechosos. Escalar (es cambio DNS, fuera del alcance). El build puede continuar.

Movimientos (extracto — cada uno con la estructura completa)

Mov. 1 — Base operativa desde el molde. Copiar el molde notifier (allowlist + preview por defecto + doble flag para envío real). Observación esperada: carpeta con los ficheros; git status los muestra nuevos. Fallo probable: duda de "¿dónde vive el código?". Contramaniobra (decisión cerrada aquí): el operativo vive en el repo operativo; cualquier copia en otro repo queda como molde genérico. No dos fuentes de verdad.

Mov. 2 — Censo de clientes elegibles (propuesta, NO decisión). Cruzar 4 fuentes de solo lectura (CRM, propiedades accesibles por la service account, mapping de analítica, allowlist de emails). Regla de elegibilidad cerrada: con datos accesibles = elegible; sin ninguna fuente = NO elegible (se lista aparte). Email sin fuente verificable = fila marcada ⚠️ SIN EMAIL VERIFICADO. Entregar el censo al responsable y PARAR el alta de clientes hasta su OK. (VARIABLE V1: censo definitivo + emails por cliente — decisión del humano). Fallo probable: tentación de rellenar emails "obvios" (info@dominio) sin verificar. Contramaniobra: prohibido. Sin entrada verificada en la allowlist → no se envía. 🔀 Trigger: mientras V1 no esté resuelta, los Mov. 3-9 (build, deploy, simulacro con clientes control) pueden ejecutarse igual; el Mov. 10 exige V1.

Mov. 3 — Config externa (separar datos de código). Un clientes.json sustituye al dict hardcodeado. destinatarios SOLO con emails aprobados en V1. Bcc fijo no configurable al buzón del equipo (archivo central + visibilidad). Fallo probable: emails de cliente commiteados a un repo público. Contramaniobra: el clientes.json SOLO en el repo privado operativo y en el servidor. Jamás en un repo público.

Mov. 4 — Extender el generador (modos de envío + idempotencia). Modos que sustituyen al --test ambiguo: --dry (genera, no envía) · --preview (envía TODO a la allowlist del equipo — cero clientes) · --send-real (destinatarios reales). Sin flag → --dry (default seguro). Assert duro: en --preview, si algún destinatario no está en la allowlist → raise antes de tocar SMTP. Registro idempotente en sqlite con PRIMARY KEY(slug, mes, modo): antes de cada envío real, SELECT — si ya existe → skip con log (jamás doble envío). El INSERT solo tras el envío sin excepción. Fallo probable: refactor rompe el import. Contramaniobra: python -m py_compile antes de cada prueba.

Mov. 8 — Deploy al servidor (con backup, sin tocar el cron todavía). Backup de la versión anterior antes de pisar; mkdir -p del subdirectorio de la BD (un scp de varios ficheros NO crea el destino). Dejar el interruptor de modo en preview. Rollback de este movimiento (primer ciudadano de la rama): mv <ruta>.bak-<fecha> <ruta>. Fallo probable: pisar una versión del servidor más nueva que la de git. Contramaniobra: antes del scp, scp inverso + diff; si hay cambios no recogidos, incorporarlos primero. El .bak es el rollback en cualquier caso.

Mov. 9 — Cron con reintentos (idempotencia probada ANTES de instalarlo). Primero, en el servidor y en modo preview, ejecutar el generador DOS veces sobre el mismo cliente/mes → la 2ª debe hacer skip. Después instalar el cron con protección del crontab: un crontab -l fallido encadenado a | crontab - VACÍA el crontab entero. Por eso: backup primero, comprobar que el backup tiene >0 líneas, y solo entonces recomponer. Día 1 = envío; días 2-3 = reintentos (el sqlite hace que los ya enviados hagan skip). Fallo probable: el grep -v borra de más otra línea del crontab. Contramaniobra: diff entre backup y crontab nuevo — la única diferencia admisible es la línea añadida; si no, restaurar del backup.

Mov. 10 — Ventana de preview + revisión del responsable. Simulacro inmediato en modo preview: todos los informes del mes cerrado llegan al equipo. Verificar la entrega REAL en el buzón destino (INBOX + Spam): el log del emisor NO basta — "aceptado por el relay" ≠ "entregado". "Mostrar original" → SPF: PASS, DKIM: PASS. 🔀 Trigger: si el responsable pide cambios → iterar Mov. 4 + redeploy + nuevo preview; si da OK → Mov. 11.

Mov. 11 — Activación del envío real (SOLO tras OK explícito). Es el único movimiento que abre la puerta a buzones de cliente — ventana con el responsable. Cambiar el interruptor de modo a real. Vigilancia activa ese día: log, resumen, y consulta al registro sqlite. Fallo probable: un cliente con email erróneo (rebote). Contramaniobra: marcar ese slug activo: false, corregir SOLO con dato verificado, reactivar; el reintento NO reenvía a los demás (sqlite).

Condiciones de aborto (parar + escalar + estado a dejar)

Regla transversal al abortar: dejar el interruptor en modo seguro (preview o cron desinstalado con backup), log intacto, git push de lo commiteado, y una nota fechada con el punto exacto de parada.

Pasadas de verificación (batería medible)

1. Crontab íntegro: 1 línea nueva Y todas las previas intactas (crontab -l | wc -l ≥ backup).
2. Idempotencia (el test estrella): ejecutar el wrapper DOS veces el mismo día → 2ª corrida: log skip en todos, CERO emails nuevos, sqlite sin duplicados (GROUP BY … HAVING COUNT(*)>1 → vacío).
3. Allowlist preview: con modo preview, grep del log → ningún destinatario fuera de la allowlist del equipo. Cero coincidencias de dominios de cliente.
4. Entrega real verificada en destino: informes en INBOX (no Spam); SPF: PASS, DKIM: PASS.
5. Cifras cuadran (3 clientes control): informe vs UI de analítica/buscadores (±5% por consolidación) y vs una lectura API independiente (código distinto, misma fuente → detecta bugs de rangos).
6. Cliente sin una fuente: informe parcial se genera sin tarjetas vacías/None.
7. Sin secretos en el diff: git log -p | grep -iE "BEGIN PRIVATE|smtp_pass *=" → vacío.

Firma

Battle-plan redactado por el redactor (mejor modelo disponible) · red-team pass (punto 7 del estándar) ejecutado por un agente DISTINTO: N hallazgos incorporados (variables de entorno en el smoke de RECON, semántica de modos unificada, mkdir en deploy, LEDGER poblado, backup de crontab fiable, allowlist cerrada).

Anti-patrones

• ❌ NO escribir "si algo va mal, revisa el error". Eso no es una contramaniobra: escribe la causa, las señales y los pasos.
• ❌ NO dejar bifurcaciones al criterio del ejecutor barato. Si no hay trigger explícito ("si X → A"), el ejecutor decide a ojo y falla.
• ❌ NO que el redactor se autoevalúe. El red-team lo hace un agente distinto o no cuenta.
• ❌ NO asumir supuestos en silencio. Todo lo que el redactor no pueda verificar → (VARIABLE: …) en el texto y en el LEDGER.
• ❌ NO poner el valor de un secreto en el battle-plan. Solo su ubicación.
• ❌ NO ejecutar operaciones destructivas sin ventana con un humano, backup verificado y rollback como primer movimiento de esa rama.
• ❌ NO ejecutar un war-game viejo a ciegas. Es una foto fechada: la fase RECON re-verifica la realidad antes del primer movimiento. Si el recon contradice un supuesto crítico, sigue el trigger o aborta.
• ❌ NO parchear a ciegas un war-game cuando la misión cambia de forma sustancial. Re-genéralo.

Tradeoffs del diseño

Ejemplos de aplicación

Skills relacionadas

• Cualquier skill de deploy / VPS: el war-game es la capa de "qué puede salir mal" sobre el runbook de deploy.
• Cualquier skill de git destructivo: el war-game exige backup + rollback como primer movimiento de la rama destructiva.
• Cualquier skill de manejo de secretos: el war-game solo señala la ubicación, nunca el valor.

Patrón aportado por MultiAtlas a la comunidad SaaS Factory. Probado en producción; ejemplo completamente anonimizado.