feat(infra): auto-commit con 86 cambios

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

dev/flows/README.md

@@ -12,49 +12,116 @@ Un flow describe una secuencia de pasos que atraviesa varias apps (`navegator_da
 - **Definition of Done OBLIGATORIA** — ver seccion abajo. Sin DoD el flow NO puede crearse.
 - Cerrados se mueven a `completed/`.
 
-## Definition of Done (OBLIGATORIA)
+## Definition of Done (OBLIGATORIA — triada)
 
 Cada flow al crearse DEBE declarar un bloque `## Definition of Done` distinto de `## Acceptance`. Sin el, `/flow create` rechaza el scaffold y `/flow done` rechaza el cierre.
 
-**Diferencia:**
+**Regla absoluta**: DoD no es checkbox que se marca a mano. Cada item lleva **evidencia ejecutable** (comando, e2e_check, dashboard URL con datos frescos, log query, screenshot link). Si no puedes probarlo, no es DoD: es deseo. Ver `.claude/rules/dod_quality.md` para la regla completa.
+
+**Diferencia con `## Acceptance`:**
 
 | `## Acceptance` | `## Definition of Done` |
 |---|---|
-| Checks task-level del flow (ejecucion concreta) | Contrato global de calidad para considerar el flow CERRADO |
-| Pueden quedar `[ ]` mientras iteras | TODOS deben estar `[x]` antes de mover a `completed/` |
-| Verifica que el flow CORRE | Verifica que el flow es REPETIBLE, OBSERVABLE y MANTENIBLE |
+| Checks task-level del flow (el flow corre una vez) | Contrato global de calidad: el flow sobrevive uso real |
+| Pueden quedar `[ ]` mientras iteras | TODAS las capas verdes con evidencia antes de mover a `completed/` |
+| Verifica que el flow CORRE | Verifica que el flow es REPETIBLE, OBSERVABLE, MANTENIBLE y USADO |
 
-**Plantilla minima de DoD** (anadir/ajustar segun flow):
+### Las 3 capas obligatorias
+
+**1. Mecanica** (pre-requisito, NO es DoD por si misma):
+Build verde, tests verdes, `fn index` limpio, `fn doctor` verde, `uses_functions` sin drift. Hacer compilar la cosa NO es haberla terminado.
+
+**2. Cobertura de comportamiento**:
+Tabla `escenario | tipo | comando | resultado esperado`. Minimo 1 golden + 2 edge + 1 error path con assert real, no smoke "no peto". Cuando aplique, las pruebas dejan entry en `e2e_runs` de la app afectada.
+
+**3. Vida util validada**:
+Tabla `metrica | umbral | dashboard | ventana`. El flow sobrevive **>=7 dias de uso real** sin romperse silenciosamente. Crashes = 0, huecos en audit chains = 0, error_rate < umbral declarado, dashboard observable abierto periodicamente. **El humano usa la cosa en su PC, en su contexto real, >=N veces variadas, no en sandbox aislado**.
+
+### Plantilla obligatoria
+
+Ver `template.md` para el esqueleto completo. Bloques:
 
 ```markdown
 ## Definition of Done
 
-- [ ] **Repetibilidad**: el flow corre N veces consecutivas (N declarado en el flow, default 3) sin intervencion manual.
-- [ ] **Observabilidad**: queda trazado en `call_monitor.calls` + `data_factory.runs` + dashboard correspondiente.
-- [ ] **Error-path**: al menos 1 modo de fallo probado y manejado (no crash silencioso).
-- [ ] **Idempotencia**: re-ejecutar no duplica datos ni rompe estado (clave en sinks).
-- [ ] **Secrets**: cero credenciales en disco fuera de `pass`/vaults; cero datos sensibles fuera de `risk` declarado.
-- [ ] **Docs**: `## Notas` rellenado con hallazgos reales + comandos para reproducir.
-- [ ] **Registry-first**: todas las piezas reutilizables existen como funciones del registry (no inline en apps).
-- [ ] **INDEX + status**: `status: done` en frontmatter + fila actualizada en `INDEX.md` + archivo movido a `completed/`.
+### Mecanica
+- [ ] Build verde (`cmd: ...`)
+- [ ] Tests verdes (`cmd: ...`)
+- [ ] fn index limpio
+- [ ] fn doctor verde
+- [ ] uses_functions auditado
+
+### Cobertura de comportamiento
+| Escenario | Tipo | Comando | Resultado esperado |
+|---|---|---|---|
+| Golden: ... | unit/e2e | `cmd` | output concreto |
+| Edge 1: ... | unit/e2e | `cmd` | comportamiento concreto |
+| Error 1: ... | e2e | `cmd que rompe` | fallo manejado, no crash |
+| Error 2: ... | e2e | `cmd` | degradacion graceful + log |
+
+### Vida util validada
+| Metrica | Umbral | Donde se observa | Ventana |
+|---|---|---|---|
+| <metrica> | `>=N` | `<dashboard URL>` | 7 dias |
+| crashes | `0` | `journalctl ...` | 7 dias |
+
+### User-facing (reforzado)
+- [ ] User-facing surface (lugar concreto, NO BD ni log).
+- [ ] User-facing usage real: >=N veces en >=7 dias, en PC real, con inputs reales.
+- [ ] User-facing variado: >=3 capabilities/casos distintos.
+- [ ] User-facing onboarding (parrafo en `## Notas`).
+- [ ] User-facing latencia <X medida.
+
+### Anti-criterios (invalidan DoD aunque checkboxes verdes)
+- [ ] solo-en-mi-PC
+- [ ] solo-en-sandbox-vacio
+- [ ] camino feliz unico (error paths declarados pero nunca ejercitados)
+- [ ] dashboard fantasma (no abierto en >30 dias)
+- [ ] self-test sin asserts
+- [ ] silent-fail
+- [ ] approval saltado
 ```
 
-Cada flow puede anadir DoD especificos al dominio (ej. `bbva-movimientos`: "datos NUNCA cruzan a registry.organic-machine"). El bloque DoD se **versiona con el flow** — un cambio de DoD requiere bump de `updated:` en frontmatter.
+### Reglas duras para marcar `status: done`
 
-### User-facing surface (sub-bloque OBLIGATORIO dentro de DoD)
+`/flow done` rechaza el cierre si:
 
-"DoD verde" sin valor visible al humano = plumbing limpio sin razon de existir. Cada DoD DEBE incluir, al menos, estos cuatro checks tipo `User-facing`:
+1. Falta alguna de las 3 capas (mecanica + cobertura + vida).
+2. En Cobertura: <1 golden, <2 edge, <1 error path con evidencia.
+3. En Vida util: tabla vacia o sin dashboard observable real.
+4. User-facing usage real <7 dias o <N usos declarados.
+5. Cualquier anti-criterio marcado como cierto.
+6. `## Notas` sin parrafo onboarding.
+7. Algun item sin comando/URL/log query — solo texto.
 
-```markdown
-- [ ] **User-facing**: <accion concreta del humano + lugar exacto donde ve/usa el output>.
-- [ ] **User-facing repeat**: el humano vuelve manana al mismo lugar y ve datos frescos sin conocer el flow.
-- [ ] **User-facing onboarding**: parrafo en `## Notas` que explica "para ver/usar esto: hacer X" — sin leer el flow.
-- [ ] **User-facing latencia**: el humano percibe el cambio en <X segundos|minutos> tras el evento (X declarado por flow).
-```
+Cada flow puede anadir DoD especificos al dominio. El bloque DoD se **versiona con el flow** — un cambio de DoD requiere bump de `updated:` en frontmatter.
 
-Regla: si la respuesta a "donde lo ves" es "en una BD" o "en un log" -> NO vale. Tiene que ser una superficie usada por el humano (UI de una app, sala Matrix, dashboard, Metabase card, repo Gitea, archivo en vault abierto a mano). Si el output solo lo consume otra app/flow, esa app/flow es quien debe declarar su propia user-facing surface.
+### User-facing surface (regla complementaria)
 
-`/flow done` rechaza el cierre si falta alguno de los 4 user-facing checks o si `## Notas` no contiene parrafo onboarding.
+Si la respuesta a "donde lo ves" es "en una BD" o "en un log" -> NO vale. Tiene que ser una superficie usada por el humano (UI de app, sala Matrix, dashboard, Metabase card, repo Gitea, archivo en vault abierto a mano). Si el output solo lo consume otra app/flow, esa app/flow declara su propia user-facing surface.
+
+### Antipatrones documentados
+
+| Antipatron | Por que es malo |
+|---|---|
+| Marcar `done` porque pasa una vez | Tarea "hecha" se rompe al primer uso real |
+| Checkbox sin evidencia ejecutable | DoD se convierte en placebo, no en gate |
+| Test que solo verifica camino feliz | El error path es donde se pierden datos en produccion |
+| Observabilidad declarada pero dashboard no abierto en 30 dias | Telemetria muerta = ceguera |
+| "Repetible 3 veces consecutivas" con BD efimera | No prueba comportamiento sobre datos reales acumulados |
+| Aprobacion saltada en algun camino | Security gate roto pero invisible |
+| Error path manejado solo "en teoria" | Cuando ocurra en produccion el manejo no existe |
+
+### Validacion programatica de DoD (TBD)
+
+`/flow done` ejecuta checks programaticos:
+- Parsea bloques `### Mecanica`, `### Cobertura`, `### Vida util`, `### User-facing`, `### Anti-criterios`.
+- Verifica que cada item tiene `cmd:` / URL / log query / e2e_check_id asociado.
+- Cuenta filas en Cobertura: >=1 golden + >=2 edge + >=1 error.
+- Cruza con `e2e_runs` y `call_monitor.calls` para confirmar evidencias en BDs reales.
+- Aborta cierre si falta cobertura o algun anti-criterio esta marcado.
+
+Hoy parte de esto es manual (revision humana). Ver `audit_dod_schema_go_infra` (issue 0114) + `fn doctor dod`.
 
 ### DoD evidence schema (issue 0114, opcional)