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