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

• 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".

• 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/.

User-facing (obligatorio)

• 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).

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)