fn_registry/dev/flows/template.md

name, id, status, created, updated, priority, risk, related_issues, apps, projects, vaults, capability_groups, trigger, schedule, expected_runtime_s, tags

name	id	status	created	updated	priority	risk	related_issues	apps	projects	vaults	capability_groups	trigger	schedule	expected_runtime_s	tags
<slug>	NNNN	pending	YYYY-MM-DD	YYYY-MM-DD	medium	low						manual		60

Goal

Una frase: que prueba este flow del sistema multi-app.

Pre-requisitos

• Lista de cosas manuales/externas que deben estar listas antes (Chrome logueado, vault montado, service corriendo, token en pass, ...).

Funciones del registry recomendadas

Tabla rol -> funcion candidata (ver AGENT_GUIDE.md para discovery). Si falta una pieza: marca FALTA: crear <id> con prompt sugerido para fn-constructor.

Rol	Funcion candidata	Estado
Extractor	<id>	OK / FALTA
Validator	<id>	OK / FALTA
Transformer	<id>	OK / FALTA
Sink	<id>	OK / FALTA
Scheduler	DAG <path>.yaml / webhook / manual	OK / FALTA
Notify	<id>	OK / FALTA

Apps tocadas

• <app> (rol en el flow)

Projects relacionados

• <project> (razon)

Vaults / storage

• <vault o BD> (origin / sink)

Capability groups consultados

• <group> (ver docs/capabilities/<group>.md)

Flow

Pasos numerados. Cada paso puede ser:

• texto libre (manual)
• function: <id> (registry function)
• cmd: <bash>
• js: <expression> (en tab Chrome)
• dag: <name> (DAG en apps/dag_engine/dags_migrated/)

1. Paso 1.
2. Paso 2.

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

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.

Mecanica (pre-requisito, NO sustituye al resto)

Construir verde no es estar hecho. Es la base para empezar a probar.

• 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:	unit / e2e / manual	<cmd>	<output concreto, no "ok">
Edge case 1:	unit / e2e	<cmd>
Edge case 2:	unit / e2e	<cmd>
Error path 1:	e2e	<cmd que provoca fallo>	<fallo manejado, no crash>
Error path 2:	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)

• (custom) .

Telemetria esperada

• call_monitor.calls: que aparece.
• data_factory.runs: que aparece.
• <app>.operations.db: que aparece.
• Matrix / email / dashboard: que aparece visible.

Riesgos / gotchas

• Lista de cosas que pueden romperse y como detectarlas.

Notas

(rellenas tras correr o tras hallazgos)