feat(infra): auto-commit con 86 cambios

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

dev/flows/template.md

@@ -68,28 +68,74 @@ Pasos numerados. Cada paso puede ser:
 
 ## Acceptance
 
+Checks task-level del flow — verifican que el flow CORRE una vez. Pueden quedar `[ ]` mientras iteras. NO sustituyen a la DoD.
+
 - [ ] Criterio 1.
 - [ ] Criterio 2.
 
 ## Definition of Done
 
-Contrato global de cierre. TODOS marcados antes de mover a `completed/`. Ver README.md seccion "Definition of Done".
+**Filosofia triada (ver `.claude/rules/dod_quality.md`):** DoD no es checkbox que se marca a mano. Cada item debe llevar **evidencia ejecutable** (comando, e2e_check, screenshot link, dashboard URL con datos frescos, log query). Si no puedes probarlo, no es DoD: es deseo. Las 3 capas son obligatorias.
 
-- [ ] **Repetibilidad**: corre 3 veces consecutivas sin intervencion manual.
-- [ ] **Observabilidad**: trazado en `call_monitor.calls` + `data_factory.runs` + dashboard relevante.
-- [ ] **Error-path**: >=1 modo de fallo probado y manejado.
-- [ ] **Idempotencia**: re-ejecucion no duplica ni corrompe sinks.
-- [ ] **Secrets**: cero credenciales fuera de `pass`/vaults; risk declarado coincide con datos reales.
-- [ ] **Docs**: `## Notas` con hallazgos + comandos reproducibles.
-- [ ] **Registry-first**: piezas reutilizables viven como funciones del registry.
-- [ ] **INDEX + status**: `status: done` + `INDEX.md` actualizado + movido a `completed/`.
+### Mecanica (pre-requisito, NO sustituye al resto)
 
-### User-facing (obligatorio)
+Construir verde no es estar hecho. Es la base para empezar a probar.
 
-- [ ] **User-facing**: <accion concreta del humano + lugar exacto donde ve/usa el output>.
-- [ ] **User-facing repeat**: humano vuelve manana al mismo lugar, ve datos frescos sin conocer el flow.
-- [ ] **User-facing onboarding**: parrafo en `## Notas` explica "para ver/usar esto: hacer X" sin leer el flow.
-- [ ] **User-facing latencia**: humano percibe el cambio en <Xs|Xmin> tras el evento (X declarado).
+- [ ] **Build verde** (`cmd: <comando build>`).
+- [ ] **Tests unitarios verdes** (`cmd: <comando test>`, listar IDs/paths).
+- [ ] **`fn index` limpio** (sin warnings nuevos).
+- [ ] **`fn doctor` verde** en artefactos tocados (`cmd: ./fn doctor --json | jq ...`).
+- [ ] **`uses_functions` auditado** (sin drift en `app.md` vs imports reales).
+
+### Cobertura de comportamiento
+
+Cada escenario debe tener una prueba ejecutable con assert real (no smoke "no peto"). Anadir tantas filas como casos relevantes — golden path + edge cases + error paths.
+
+| Escenario | Tipo de prueba | Comando / evidencia | Resultado esperado |
+|---|---|---|---|
+| Golden path: <descripcion> | unit / e2e / manual | `<cmd>` | <output concreto, no "ok"> |
+| Edge case 1: <input limite> | unit / e2e | `<cmd>` | <comportamiento concreto> |
+| Edge case 2: <estado raro> | unit / e2e | `<cmd>` | <comportamiento concreto> |
+| Error path 1: <fallo esperado> | e2e | `<cmd que provoca fallo>` | <fallo manejado, no crash> |
+| Error path 2: <recursos caidos> | e2e | `<cmd>` | <degradacion graceful + log> |
+
+**Regla**: al menos 1 golden + 2 edge + 1 error path. Tests inscritos en `e2e_runs` de la app correspondiente cuando aplique.
+
+### Vida util validada
+
+El flow no esta hecho hasta que sobrevive **uso real** durante >=7 dias sin romperse silenciosamente. Cada metrica tiene umbral medible y dashboard observable.
+
+| Metrica | Umbral | Donde se observa | Ventana |
+|---|---|---|---|
+| <metrica 1, ej. handshakes vivos> | `>=N` | `<dashboard URL / app panel>` | 7 dias |
+| <metrica 2, ej. error_rate> | `<X%` | `<dashboard URL>` | 7 dias |
+| <metrica 3, ej. duracion p95> | `<Xms` | `call_monitor.function_stats` | 30 dias |
+| crashes del proceso | `0` | `journalctl -u <unit>` | 7 dias |
+| huecos en audit chain | `0` | `cmd: <verify chain>` | continuo |
+
+**Regla**: las metricas NO se autoreportan en el flow; las lee el operador del dashboard real. Si el dashboard no existe, el item se invalida.
+
+### User-facing (reforzado)
+
+"DoD verde" sin uso humano real = plumbing limpio sin razon de existir.
+
+- [ ] **User-facing surface**: <accion concreta del humano + lugar exacto donde ve/usa el output (NO una BD, NO un log)>.
+- [ ] **User-facing usage real**: el humano (operador) usa la cosa en **su PC, en su contexto real**, **>=N veces en >=7 dias**, con inputs reales (no demo, no sandbox).
+- [ ] **User-facing variado**: cubre >=3 capabilities/casos distintos (no solo "abre dashboard y mira").
+- [ ] **User-facing onboarding**: parrafo en `## Notas` que explica "para ver/usar esto: hacer X" sin leer el flow.
+- [ ] **User-facing latencia**: percepcion del cambio <Xs|Xmin> tras el evento (X declarado, medido).
+
+### Anti-criterios (invalidan la DoD aunque los checkboxes esten verdes)
+
+Marca el flow como **NO done** si cualquiera de estas condiciones es cierta:
+
+- [ ] **Solo-en-mi-PC**: el flow funciona en `home-wsl` pero falla en `pc-aurgi` u otro PC del operador.
+- [ ] **Repetible-en-sandbox-vacio**: solo pasa con BD limpia / cuenta limpia / sin datos historicos.
+- [ ] **Camino feliz unico**: los error paths fueron declarados pero NUNCA se ejercitaron (sin entry en `e2e_runs` o logs reales).
+- [ ] **Dashboard fantasma**: el dashboard declarado en "Vida util" no se ha abierto en >30 dias.
+- [ ] **Self-test que no apesta**: el `e2e_check` retorna `pass` sin verificar nada material (no asserts).
+- [ ] **Silent-fail**: el proceso muere/degrada sin alerta visible al operador.
+- [ ] **Approval saltado**: alguna capability con `requires_approval=true` fue ejecutada sin el approval flow.
 
 ### Custom (opcional, dominio-especifico)