# Comparación de contexto: C0, V1, V2, V3 y V4

**V4 logra la mayor exactitud del catálogo: 305/376 (81.1%).** V3 obtiene 296, V2 294, V1 285 y Jev sin contexto añadido 258. V4 reduce el texto añadido aproximadamente 75% frente a V3, pero ambas versiones asignan prácticamente la misma masa de probabilidad a las acciones aceptables. Ninguna versión mejora el lote longitudinal respecto a C0.

Se completaron las **1,880 decisiones**, sin errores de preparación ni respuesta. Las cinco condiciones tienen los mismos 376 casos puntuables; no hay un subconjunto favorable que cambie los denominadores. Modelo `jev-1.13.0`, una respuesta por solicitud exacta, sin Luna, sin ajustar políticas después de observar resultados.

## Resultados

| Condición | Aciertos | Exactitud | Probabilidad media de acciones aceptables | Contexto añadido medio, bytes UTF-8 | Tokens de entrada medios de la decisión |
| --- | ---: | ---: | ---: | ---: | ---: |
| C0, sin contexto añadido | 258/376 | 68.6% | 56.56% | 0 | 3,536 |
| V1, legacy | 285/376 | 75.8% | 63.35% | 65,893 | 20,405 |
| V2, concise | 294/376 | 78.2% | 65.88% | 32,689 | 14,675 |
| V3, selective | 296/376 | 78.7% | 67.91% | 11,559 | 8,025 |
| **V4, V4B_FOCUS** | **305/376** | **81.1%** | **67.92%** | **2,870** | **4,225** |

La probabilidad mostrada es la suma de las probabilidades originales asignadas a todas las acciones admitidas por la clave; **no es probabilidad de ganar una partida**. El acierto se calcula sobre la elección explícita de Jev, no sobre un argmax reconstruido ni sobre la suma de varias opciones aceptables. No se normalizaron las respuestas redondeadas.

| Lote | C0 | V1 | V2 | V3 | V4 |
| --- | ---: | ---: | ---: | ---: | ---: |
| 32 microescenarios conocidos | 17 | 17 | 19 | 20 | 20 |
| 320 variantes de mecánicas | 224 | 255 | 261 | 263 | 272 |
| 24 escenarios longitudinales | **17** | 13 | 14 | 13 | 13 |
| **Total, 376** | **258** | **285** | **294** | **296** | **305** |

Frente a C0, V1 corrige 46 casos y empeora 19; V2 corrige 48 y empeora 12; V3 corrige 48 y empeora 10; V4 corrige 57 y empeora 10. **V4 frente a V3: 24 correcciones y 15 regresiones**, +9 aciertos netos, todos en el lote de mecánicas. La diferencia de masa media V4−V3 es apenas **+0.0053 puntos porcentuales**.

## Qué aporta esta comparación

1. **V4 es la mejor base medida en este catálogo.** Combina una cápsula de posición con un solo paquete de reglas elegido por Jev. En mecánicas sube de 263/320 a 272/320 frente a V3. Las plantillas con sus cuatro variantes correctas pasan de 49/80 a 54/80. También consume menos tokens en el proceso completo, incluyendo la selección de contexto.
2. **Reducir y seleccionar mejor parece útil, pero no aislamos el efecto de la longitud.** Cada versión modifica representación, reglas candidatas y selección, además del tamaño. Esta comparación no demuestra una ley de «menos texto = mejor». V4 pierde casos de clima y daño que V3 resolvía.
3. **El historial sigue sin estar resuelto.** C0 acierta 17/24 y V4 13/24; los pares con ambos casos correctos son 6/12 y 4/12, respectivamente. V4 elige la primera opción ofrecida en los 24 casos longitudinales, fallando los 11 donde esa primera opción no es aceptable. Eso describe las respuestas; no demuestra causalmente sesgo de posición sin permutar las opciones.
4. **El problema inicial de Quick Attack persiste en las cinco versiones.** En `prioridad-01`, la masa aceptable es C0 29%, V1 34%, V2 32%, V3 35% y V4 30%. Todas eligen `move 2 1, pass`, la opción incorrecta. En V4, Jev selecciona `damage-type-accuracy` (74%) y deja `order` (23%) fuera del contexto final. El texto añadido sí describe Quick Attack, pero omite su prioridad +1. Esto identifica una omisión concreta de selección; para atribuirle causalmente el fallo hay que probar el paquete de orden manteniendo todo lo demás fijo.
5. **Conviene separar pérdida de información de uso incorrecto de información presente.** En los dos casos `long-protect-history`, todas las versiones fallan; el diagnóstico previo verificó que V3 conserva la cadena y la regla de Protect. En `long-poison-or-burn`, C0 acierta ambos y las cuatro versiones con contexto fallan ambos. Hay que probar cambios pequeños y controlados sobre estas decisiones, además de corregir errores del estado reconstruido.

## Dónde cambia el desempeño

Cada familia contiene 20 variantes de mecánicas. Los grupos no son muestras independientes de partidas.

| Familia | C0 | V1 | V2 | V3 | V4 |
| --- | ---: | ---: | ---: | ---: | ---: |
| Prioridad | 11 | 11 | 13 | 12 | 14 |
| Velocidad | 20 | 20 | 20 | 20 | 20 |
| Terreno | 12 | 12 | 13 | 12 | 12 |
| Protección | 16 | 16 | 17 | 16 | 16 |
| Inmunidades | 9 | 14 | 13 | 16 | 18 |
| Redirección | 15 | 15 | 16 | 16 | 18 |
| Ataques de área | 11 | 18 | 20 | 20 | 20 |
| Clima | 14 | 18 | 18 | 18 | 15 |
| Mega | 10 | 13 | 17 | 16 | 16 |
| Residuales | 20 | 20 | 20 | 20 | 20 |
| Estados | 12 | 16 | 16 | 16 | 16 |
| Daño | 13 | 13 | 14 | 15 | 13 |
| Objetos | 17 | 20 | 18 | 18 | 20 |
| Restricciones | 20 | 19 | 19 | 20 | 20 |
| Reemplazos | 12 | 13 | 10 | 10 | 16 |
| Historial simplificado | 12 | 17 | 17 | 18 | 18 |

El historial simplificado de este lote y los 24 casos longitudinales prueban situaciones diferentes.

Ejemplos revisados directamente en contextos y respuestas:

- En `bulk-05-immunity-fire-d`, la masa aceptable pasa de 24% en V3 a 74% en V4, que elige Dragon Pulse. **Ambos contextos contienen Flash Fire**; V4 concentra la información en el paquete de daño/tipos, seleccionado con 81%. La mejora no puede explicarse simplemente como añadir una regla que faltaba.
- En `bulk-04-protect-spiky-b`, la masa baja de 55% a 23%. El paquete V4 **sí explica que Feint rompe Spiky Shield**, pero Jev elige Aura Sphere. La protección activa queda en el log original y no en la cápsula. Es necesario distinguir selección de reglas, representación del estado e interpretación al decidir.
- En el par `bulk-15-switch-ghost-entry-a/b`, V4 elige Indeedee en ambos: empeora A (69%→44%) y mejora B (38%→59%). La cápsula distingue Trick Room; el paquete de cambios nombra Surge Surfer sin explicar su efecto. El diagnóstico identifica qué información queda disponible, sin atribuir causalidad a esa omisión.

## Protocolo y versiones

- **C0:** log visible de Showdown, solicitud del jugador y menú de comandos nativo, sin contexto añadido. No significa una solicitud sin instrucciones ni opciones.
- **V1:** constructor original `chooseDecision`, modo `legacy`, recuperación Noul y estado original capturado antes de la consulta de acciones.
- **V2:** constructor original `chooseDecision`, modo `concise`. Se mantiene `observed-only`, sin fingir información completa para reducir el contexto.
- **V3:** `buildSelectiveContext`, selección Noul, umbral 0.5 y presupuesto original de 12,000 bytes, con cierre de dependencias.
- **V4:** `buildFocusPackContexts`, exclusivamente **V4B_FOCUS**: cápsula de posición y un paquete elegido por el `Choice` explícito de Jev. No se mezclan las variantes CAPSULE, RULES, FOCUS2 o ALL en el marcador V4.

Se reutilizaron los constructores sin modificar sus reglas. Los contextos V1/V2 se capturan antes de ejecutar su decisión nativa y se colocan como `state.extraContext` en la misma pregunta final que usan C0, V3 y V4. Por tanto, es una comparación de **contextos generados**, no de todos los componentes de cinco clientes de batalla diferentes. El log, el menú, sus identificadores, el orden, las instrucciones finales y la posición del contexto son iguales entre condiciones.

Se congelaron los contextos de todos los casos antes de interpretar las claves de evaluación. Los constructores reciben sólo la observación reconstruida y el wiki público; no reciben claves, razonamientos de la solución ni resultados. Las claves opacas se verifican por hash al cargar el snapshot, pero sólo se interpretan después de congelar las solicitudes. Las respuestas de acciones guardadas tampoco se pasan a la construcción de contexto.

El orden de evaluación de las condiciones rota entre casos. Se conserva una respuesta por solicitud serializada exacta y modelo. Se desactivaron reintentos automáticos. Los errores de una condición no suprimen las otras; en esta ejecución no hubo errores.

## Reutilización y consumo

Los resultados C0/V3 se fijaron a la prueba anterior de 376 casos y se verificaron exactamente. Se reutilizaron además las solicitudes V4 ya idénticas y las V1/V2 elegibles. **No son 1,880 llamadas nuevas de decisión.**

| Condición | Registros lógicos, selección + decisión | Llamadas nuevas | Tokens de entrada nuevos | Tokens de salida nuevos | Tokens de entrada del proceso completo por caso, según respuestas originales |
| --- | ---: | ---: | ---: | ---: | ---: |
| C0 | 376 | 0 | 0 | 0 | 3,536 |
| V1 | 752 | 752 | 17,096,758 | 414,158 | 45,470 |
| V2 | 752 | 750 | 10,049,202 | 91,682 | 26,794 |
| V3 | 752 | 0 | 0 | 0 | 20,883 |
| V4 | 752 | 666 | 2,539,304 | 78,279 | 7,560 |
| **Total** | **3,384** | **2,168** | **29,685,264** | **584,119** | — |

Los 1,216 usos de caché se dividen en 1,194 referencias históricas y 22 coincidencias dentro de esta ejecución. El consumo nuevo no debe usarse para afirmar que C0 o V3 cuestan cero: su coste de inferencia original está separado del consumo incremental de esta prueba. Las cifras de tokens proceden de la API, no de un tokenizador aproximado. No se convierte el consumo a dinero sin una tarifa verificada.

La carga inicial detectó dos respuestas históricas diferentes para una solicitud C0 idéntica de Quick Attack. Se detuvo **antes de llamar a la API**. Para conservar el control ya acordado, se excluyó del caché C0 de la prueba antigua de Quick Attack y se mantuvo el C0 de la prueba de 376; no se eligió según acierto ni se repitió la solicitud. La elección explícita coincide, pero las probabilidades difieren. Esta evidencia impide asumir determinismo absoluto; queda guardada en `historical-response-variation.json`.

## Límites y siguiente experimento

El conjunto son 32 controles conocidos, 80 plantillas de mecánicas con cuatro variantes y 12 pares longitudinales. Hay sesgos relevantes: 300/320 variantes de mecánicas contienen Perish Song y elegir siempre la primera opción daría **239/320 (74.7%)**. V4 consigue 272/320 y resuelve 41/81 casos donde esa primera opción es incorrecta, frente a 26/81 de V3; existe señal útil más allá de ese baseline, pero no corresponde extrapolar el 81.1% a victorias de partidas ni a mecánicas representativas de VGC.

No se corrigieron defectos del observador durante esta comparación: el sufijo de color en HP puede borrar `tox` en dos escenarios, y algunos efectos actuales de protección sólo quedan en el log/historial. Tampoco se cambió la cobertura de reglas candidatas. Estas limitaciones están documentadas en la [prueba anterior](../native-corpus-v3/README.md).

El siguiente paso propuesto es mantener V4 como referencia y medir por separado: fidelidad del estado, cobertura de reglas candidatas, pérdida de reglas al elegir un solo paquete, efecto del orden de opciones y uso de la regla cuando ya está presente. Conviene priorizar historial, clima, daño y Quick Attack, con pares de solicitudes que cambien una sola cosa. **Esta entrega no ejecuta una nueva arquitectura ni esas ablaciones.**

## Reproducción y evidencia

Desde `decision-lab`, con el snapshot local y la credencial en `.env`:

```powershell
node --env-file-if-exists=.env --import tsx scripts/benchmark-context-versions.ts --live --out runs/context-versions-new --snapshot runs/v3-native-corpus-snapshot --concurrency 3
node --import tsx scripts/report-context-versions.ts --run runs/context-versions-new --out experiments/context-versions-new
```

Sin `--live`, el primer comando es una prueba offline con respuestas simuladas y sin puntuación de desempeño. Los destinos deben ser nuevos: el runner no sobrescribe una corrida anterior. La repetición real puede consumir API cuando no hay respuesta exacta elegible en caché. El corpus congelado original se conserva en `../native-corpus-v3/source-snapshot.json.gz`; su hash se verifica en esta entrega.

Validación: **468 pruebas aprobadas, una omitida y cero fallos**; TypeScript aprobado; recorrido offline completo de 376 × 5 condiciones; auditoría de 1,880 respuestas contra el broker y coincidencia de las 26 fuentes con sus hashes congelados. Se verificaron C0/V3 contra el experimento previo, el aislamiento del contexto, los menús, las claves, la puntuación y el consumo. Los gzip se descomprimieron y sus hashes se comprobaron de nuevo desde disco.

- [Comparación por escenario, CSV](case-results.csv) y [resultados con probabilidades completas](results.json).
- [Resumen y consumo](summary.json), [protocolo](protocols.json) y [diagnóstico independiente](independent-diagnostic.md).
- [Contextos exactos](contexts.json.gz), [trazas deduplicadas](traces.json.gz) y [manifiesto para restaurarlas](archive-manifest.json).
- [Variación histórica de una respuesta idéntica](historical-response-variation.json) y [verificación de entrega](delivery-verification.json).

La deduplicación de archivo no cambia el contenido UTF-8 de solicitudes o respuestas. Las claves y los datos originales están en el snapshot referenciado y en las trazas. Se conserva el experimento previo y la implementación de las cuatro versiones.