6ad82167bb
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
112 lines
3.5 KiB
Markdown
112 lines
3.5 KiB
Markdown
---
|
|
name: <slug>
|
|
id: NNNN
|
|
status: pending
|
|
created: YYYY-MM-DD
|
|
updated: YYYY-MM-DD
|
|
priority: medium # low | medium | high
|
|
risk: low # low | medium | high (sensibilidad datos)
|
|
related_issues: []
|
|
apps: [] # apps tocadas — usadas por /flow list --app
|
|
projects: [] # projects relacionados
|
|
vaults: [] # vaults sink/source
|
|
capability_groups: [] # extractor, transformer, sink, navegator, ...
|
|
trigger: manual # manual | cron | webhook
|
|
schedule: "" # cron expr si trigger=cron
|
|
expected_runtime_s: 60
|
|
tags: []
|
|
---
|
|
|
|
## 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)_ <DoD especifica al dominio si aplica>.
|
|
|
|
## 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)
|