# ETAPA 2G — Cierre de Sprint 2: promoción de C.8 y documentación de AP.10 + AP.11

## 1. Objetivo
Documentar formalmente en el método los aprendizajes que el Sprint 2 produjo:
- **Promover C.8 a estable** en `method/PATTERNS.md` (validado en 3 etapas del proyecto).
- **Agregar AP.10 (propagación silenciosa de inconsistencia)** a `method/ANTI_PATTERNS.md`.
- **Agregar AP.11 (contrato desactualizado por código)** a `method/ANTI_PATTERNS.md`.

Etapa de documentación pura. **No toca código, no toca seed, no toca dashboard.**

---

## 2. Contexto previo
- Sprint 2 cerrado con Etapas 2A-2F entregadas.
- Etapa 2D produjo el caso real de AP.10 (subtítulos con códigos discrepantes del seed).
- Etapa 2E aplicó por primera vez C.8 y detectó el conflicto A1b-vs-A1 antes de ejecutar
  (caso real de AP.11 — SEED_SPEC.md desactualizado por Etapa 1D).
- Etapa 2F ejecutó con C.8 sin discrepancias (validación de patrón en uso limpio).
- Tres usos en proyecto Datos País → patrón estable según el método (`PATTERNS.md`,
  criterio "tras aplicarlo en un 2do proyecto distinto se promueve a estable" —
  aplica también a 2 usos limpios consecutivos en un proyecto vivo).

---

## 3. Tareas

### 3.1 Agregar C.8 a `method/PATTERNS.md`
Insertar en la **Categoría C — Validación de output**, después de C.7 (Control preventivo
de scope con `git diff`):

```markdown
### C.8 — Verificación de códigos contra fuente única · *deriva de P3, P4 · origen: 2do proyecto*
Cuando un prompt menciona códigos de un instrumento, esquema o contrato (preguntas, columnas,
campos), el agente verifica cada código contra la fuente única (`SEED_SPEC.md`, `schema.sql`,
ADRs) **antes** de ejecutar. Si detecta una discrepancia entre el código nombrado en el
prompt y su definición en la fuente única, **DETIENE la ejecución y reporta el conflicto**.
Ejecutar "literalmente" y delegar la verificación semántica al director es AP.10.
- ✅ **Correcto:** el reporte del agente incluye una sección "Verificación C.8" con cada
  código del prompt mapeado a su fila en la fuente única, antes de la ejecución. Si hay
  discrepancia, la ejecución no arranca hasta que el director resuelva.
- ❌ **Violación:** el agente ejecuta el prompt al pie de la letra y reporta "los textos son
  los solicitados literalmente; la validación semántica la hace el director" — exporta el
  trabajo de verificar al humano y propaga la inconsistencia.

**Cómo se incorpora a un prompt:** agregar un paso "Verificación C.8" como primera tarea
del DoD, listando los códigos a verificar y la ruta exacta de la fuente única.
**Casos reales en Datos País:** Etapa 2D (no se aplicó — daño AP.10), Etapa 2E (se aplicó —
detectó conflicto A1/A1b antes de ejecutar), Etapa 2F (se aplicó — sin discrepancias).
```

### 3.2 Agregar AP.10 a `method/ANTI_PATTERNS.md`
Insertar al final del listado, antes de "Cómo agregar un anti-patrón":

```markdown
## AP.10 — Propagación silenciosa de inconsistencia entre fuentes
**Comportamiento:** un prompt contiene una referencia (código, ruta, esquema) que el agente
podría verificar contra otra fuente del repo. En lugar de hacerlo, el agente ejecuta
literalmente y traslada la responsabilidad al director con frases como "la validación
semántica la hace el director" o "los textos son los solicitados literalmente".
**Daño:** las inconsistencias se propagan a producción con apariencia de precisión técnica.
*Caso real:* en Etapa 2D del proyecto Datos País, 11 de 12 subtítulos del dashboard
quedaron con códigos de pregunta discrepantes del seed real. El dashboard mostraba
métricas mal etiquetadas: el KPI "Ausencia promedio · 3.1 · días por mes" referenciaba
una pregunta que en el seed real era *gasto en cuidado*, no ausencias. Detectado en la
auditoría adversarial posterior, no antes. Si hubieran cargado datos reales, RRHH habría
visto guaraníes presentados como días.
**Detectar:** el reporte del agente declara "los textos son los solicitados literalmente";
hay códigos, rutas o nombres que el agente pudo verificar contra otra fuente y no lo hizo;
el agente delega la verificación semántica al humano sin haber verificado lo verificable.
**Evitar:** Patrón C.8 + cláusula explícita en el prompt: *"si detectás una discrepancia
entre el prompt y la fuente única, DETENÉ la ejecución y reportá antes de avanzar"*.
**Distinción:** ≠ AP.3 — AP.3 minimiza un problema observado; AP.10 evita verificar lo
verificable. ≠ AP.9 — AP.9 resuelve restricciones contradictorias del propio prompt;
AP.10 propaga inconsistencias entre el prompt y otra fuente.
```

### 3.3 Agregar AP.11 a `method/ANTI_PATTERNS.md`
Insertar inmediatamente después de AP.10:

```markdown
## AP.11 — Contrato desactualizado por código
**Comportamiento:** una etapa modifica el comportamiento real del sistema (seed, esquema,
RLS, RPCs) pero no actualiza el documento que sirve como contrato o fuente única
(`SEED_SPEC.md`, `ARCHITECTURE.md`, ADRs). El documento queda mintiendo por silencio.
**Daño:** el próximo agente o autor de prompts que lo lea va a tomar decisiones basadas
en información falsa. *Caso real:* en Etapa 1D del proyecto Datos País se modificó
`seed.sql` para que A1/A2/A3 fueran widgets geo (Departamento/Ciudad/Barrio en lugar de
texto libre País/Ciudad/Sucursal), pero no se actualizó `SEED_SPEC.md`. Dos sprints
después, Etapa 2E se escribió tomando SEED_SPEC como verdad y proponiendo agregar una
pregunta A1b que duplicaba la A1 ya existente. El conflicto se detectó antes de ejecutar
porque el agente aplicó el Patrón C.8; sin C.8, se habría creado una pregunta duplicada
en producción.
**Detectar:** cuando una etapa cambia comportamiento del sistema, preguntar explícitamente
"¿qué documento de contrato describe esto, y lo actualicé?". Si la respuesta es "no sé"
o "después lo veo", AP.11 latente. También: cuando una etapa posterior asume contenido
del contrato que ya no coincide con la realidad.
**Evitar:** todo prompt que modifique un sistema documentado en un contrato debe incluir,
como parte del DoD, "actualizar el documento de contrato correspondiente con los cambios".
Es Principio 4 aplicado al mantenimiento, no solo a la creación.
**Distinción:** ≠ AP.4 — AP.4 es decisión no registrada; AP.11 es decisión registrada en
código pero NO actualizada en el contrato escrito.
```

### 3.4 (Opcional) Agregar referencia cruzada en C.1 del método
En `method/PATTERNS.md`, dentro de C.1 (Validación visual mandatoria del artefacto final),
si existe la oportunidad, agregar como nota: *"Cuando el output incluye textos que
referencian otras fuentes del repo (códigos, IDs, rutas), aplicar también C.8."*

Esta tarea es opcional — solo si encaja naturalmente. No forzarla.

---

## 4. Entregables (DoD)
- [ ] `method/PATTERNS.md` actualizado con C.8 como patrón estable.
- [ ] `method/ANTI_PATTERNS.md` actualizado con AP.10 y AP.11.
- [ ] Tres bloques markdown insertados exactamente como están en este prompt (no
      reescribir, no resumir, no parafrasear el contenido — copiar literal).
- [ ] `git diff --name-only HEAD` retorna **solo** los 2 archivos del método.
- [ ] Build no aplica (no hay cambios de código).

## 5. Qué reportar
```
Verificado:
- archivos en diff: method/PATTERNS.md, method/ANTI_PATTERNS.md
- C.8 insertado en Categoría C después de C.7: confirmado
- AP.10 y AP.11 insertados al final del listado: confirmado
- Texto copiado literal del prompt: confirmado (sin reescritura)
- Tarea opcional 3.4: [aplicada / no aplicada — justificación corta]

Asumido:
- [solo si el método tiene una estructura distinta a la esperada]

Decisiones proactivas (Nivel 2):
- [si las hubo]
```

## 6. Qué NO hacer
- ❌ No reescribir, resumir ni parafrasear los textos de C.8, AP.10 o AP.11 — copiar literal.
- ❌ No agregar otros patrones o anti-patrones por iniciativa.
- ❌ No modificar PRINCIPLES.md ni AUTOMATION_STRATEGY.md.
- ❌ No tocar nada del proyecto Datos País (esto es del método, no del producto).
- ❌ No crear archivos nuevos — solo editar los dos existentes.