dataforge/fn_registry
1
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

docs(plan): issues 0120-0123 — mejora workflow subagentes

Browse Source 
Plan en 4 olas para cerrar gaps detectados en revision critica:
- 0120 piloto fn-orquestador (chart_demo e2e_checks)
- 0121 cobertura e2e_checks masiva (fn-recopilador batch)
- 0122 fn-revisor + auto-apply ampliado (desbloquea fase 5)
- 0123 /flow run + fn-meta-orquestador + fn-priorizador

Dep-chain: 0120 -> 0121 -> 0122 -> 0123. Cada uno con
Acceptance verificable programaticamente para que /autonomous-task
pueda converger.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Egutierrez
2026-05-18 21:41:02 +02:00
parent a192ee0695
commit 93520c4319
4 changed files with 265 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
dev/issues/0120-orquestador-piloto-verde.md
+78
View File
@@ -0,0 +1,78 @@
---
id: "0120"
title: "fn-orquestador: piloto verde end-to-end sobre chart_demo"
status: pendiente
type: chore
domain:
- meta
- registry-quality
scope: agent
priority: alta
depends: []
blocks:
- "0121"
- "0122"
- "0123"
related:
- "0069"
- "0068"
created: 2026-05-18
updated: 2026-05-18
tags: [orquestador, autonomous, e2e_checks, piloto]
---
# 0120 — Piloto verde de fn-orquestador
## Problema
`fn-orquestador` (issue 0069) tiene spec completa con 11 reglas duras, worktree aislado, paths protegidos y watchdog. Pero `task_runs` esta vacio: ningun piloto verde documentado. Memoria del "piloto 1" registra contaminacion del main repo (origen de las reglas 9/10/11). Sin un task_run con `status=done` y PR mergeado, el comando `/autonomous-task` es promesa, no herramienta. Las olas 0121-0123 dependen de que esto funcione.
## Decision
Ejecutar `/autonomous-task` sobre un target acotado y verificable: anadir bloque `e2e_checks` minimo al `app.md` de `chart_demo` y validar que `fn-analizador` corre la suite verde. Documentar el `task_run` entero (iteraciones, proposals, eventos) para auditar comportamiento real del orquestador.
### Target
`apps/chart_demo/` — app C++ ImGui pequeña, sin `e2e_checks` declarado, con `--self-test` ya implementado por el framework `fn::run_app`.
### Bloque `e2e_checks` esperado
```yaml
e2e_checks:
- id: build
cmd: "cmake --build cpp/build/windows --target chart_demo -j"
timeout_s: 300
- id: self_test
cmd: "./cpp/build/windows/apps/chart_demo/chart_demo --self-test"
timeout_s: 30
```
## Tareas
1. Confirmar pre-condiciones del orquestador (migration 006, autonomous_protected_paths.json, gh auth, master limpio).
2. Lanzar `/autonomous-task 0120 --dry-run` para audit.
3. Lanzar `/autonomous-task 0120 --max-iterations 5 --max-minutes 30`.
4. Recoger output: `task_run_id`, branch `auto/0120-*`, log de iteraciones, proposals aplicadas/skipped, URL del PR draft.
5. Verificar `git -C /home/lucas/fn_registry status --short` igual a baseline (regla 11 sandbox breach).
6. Post-mortem: si fallo en alguna iteracion, anotar en seccion `## Hallazgos` y refinar `fn-orquestador/SKILL.md` o `autonomous_loop.md` si corresponde.
## Acceptance
- [ ] `sqlite3 apps/agent_runner_api/operations.db "SELECT id, status FROM task_runs WHERE issue_id='0120'"` devuelve >=1 fila con `status=done`.
- [ ] `apps/chart_demo/app.md` contiene bloque `e2e_checks:` con al menos `build` + `self_test`.
- [ ] `fn-analizador` corrida sobre `chart_demo` reporta `checks_pass=checks_total` (todo verde).
- [ ] PR draft existe en Gitea con branch `auto/0120-*` apuntando a `master`.
- [ ] `git -C /home/lucas/fn_registry status --short` antes/despues del piloto identico (excluyendo solo este `.md` cerrado).
- [ ] Documento de post-mortem en `## Hallazgos` con: iteraciones totales, tiempo total, proposals creadas, decisiones del orquestador.
## DoD
User-facing surface:
- **Donde**: PR draft visible en Gitea `dataforge/fn_registry/pulls`.
- **Latencia**: <30 min total.
- **Como vuelve**: lectura del `task_run` via `mcp__registry__fn_doctor` o tab Monitor del registry_dashboard.
- **Onboarding (1 parrafo)**: "Para lanzar orquestador autonomo sobre un issue trivial, ejecuta `/autonomous-task <NNNN>`. Tras converger, abre PR draft. Si falla, lee `task_runs.events_json` para reconstruir las decisiones."
## Hallazgos
(Rellenar tras ejecucion)
dev/issues/0121-e2e-checks-coverage-masa.md
+57
View File
@@ -0,0 +1,57 @@
---
id: "0121"
title: "Cobertura e2e_checks: design-e2e batch sobre apps sin contrato"
status: pendiente
type: chore
domain:
- registry-quality
- meta
scope: registry
priority: alta
depends:
- "0120"
blocks:
- "0122"
related:
- "0068"
created: 2026-05-18
updated: 2026-05-18
tags: [e2e_checks, recopilador, batch, coverage]
---
# 0121 — Cobertura e2e_checks masiva via fn-recopilador batch
## Problema
Regla `e2e_validation.md` define el contrato `e2e_checks` en `app.md` para que `fn-analizador` (fase 4) pueda validar. Hoy solo ~12 apps lo declaran. >20 apps sin contrato hacen que el bucle reactivo opere amputado: fase 4 colapsa, fase 5 no recibe input. `/autonomous-task` no puede converger sobre la mayoria de apps por falta de gate.
## Decision
Lanzar `fn-recopilador` en modo `design-e2e <app>` en paralelo sobre TODAS las apps sin `e2e_checks` declarado. Cada output es propuesta de bloque YAML para anadir al `app.md` correspondiente. Humano (o `/autonomous-task` por app) aplica via PR.
Anadir subcomando `fn doctor e2e-coverage` que lista apps sin contrato y devuelve % de coverage.
## Tareas
1. Listar apps sin `e2e_checks:` con `grep -L`.
2. Spawn `fn-recopilador design-e2e <app>` en paralelo (1 mensaje, N tool_use blocks) para cada app sin contrato.
3. Recoger propuestas, una por app, en `dev/proposals_e2e_checks_0121/<app>.yaml` (carpeta efimera).
4. Implementar `fn doctor e2e-coverage` en `cmd/fn/doctor.go` + funcion auxiliar `audit_e2e_coverage_go_infra` via `fn-constructor`.
5. Aplicar propuestas: editar `app.md` de cada app (manual o autonomous-task por lote).
6. Re-ejecutar `fn doctor e2e-coverage` y validar coverage >=80%.
## Acceptance
- [ ] `fn doctor e2e-coverage --json` existe y reporta coverage actual.
- [ ] Coverage >=80% (>=80% de apps en `apps/`, `cpp/apps/`, `projects/*/apps/` con `e2e_checks` declarado).
- [ ] Para cada app con `e2e_checks` nuevo: `fn-analizador` corrida produce `e2e_runs` con `checks_total>0`.
- [ ] Funcion `audit_e2e_coverage_go_infra` indexada en registry.db con `uses_functions` declarado.
- [ ] PR mergeado a master con cambios en N `app.md` + nuevo doctor subcomando.
## DoD
User-facing surface:
- **Donde**: `fn doctor e2e-coverage` en terminal + tab Monitor del registry_dashboard (KPI coverage %).
- **Latencia**: report en <5s.
- **Como vuelve**: `fn doctor` rutinario tras cada deploy.
- **Onboarding**: "Antes de cerrar issue que toca app, comprobar `fn doctor e2e-coverage` para que la coverage no baje."
dev/issues/0122-fn-revisor-auto-apply.md
+65
View File
@@ -0,0 +1,65 @@
---
id: "0122"
title: "fn-revisor + auto-apply ampliado: desbloquear fase 5"
status: pendiente
type: feature
domain:
- meta
- registry-quality
scope: agent
priority: alta
depends:
- "0121"
blocks:
- "0123"
related:
- "0069"
- "0086"
created: 2026-05-18
updated: 2026-05-18
tags: [revisor, mejorador, proposals, auto-apply, autonomous]
---
# 0122 — fn-revisor + ampliar filtro auto-aplicable del orquestador
## Problema
`fn-mejorador` (fase 5) abre proposals con evidencia, pero el filtro auto-aplicable del orquestador solo cubre `bug_fix`, `e2e_check_add`, `doc_update`, `capability_tag_add`. La mayoria de proposals reales son `new_function` / `refactor` / `improve_function` → quedan `pending` para humano → cola se acumula sin cerrar (3+ proposals pendientes hoy). El bucle reactivo aprende pero no actua.
Ampliar el filtro sin un revisor automatico = kamikaze. Necesitamos un agente `fn-revisor` que actue como gate pre-PR sobre `auto/*`: code review caveman, severity-tagged, sin scope creep.
## Decision
1. **Crear `fn-revisor`** como subagente nuevo (`.claude/agents/fn-revisor/SKILL.md`). Modelo sonnet. Tools: Read, Grep, Bash (read-only). Output formato: `path:line: <emoji> <severity>: <problema>. <fix>.`. Adaptar prompt de `caveman:cavecrew-reviewer` al contexto fn (registry-first, reglas duras, etc.).
2. **Ampliar filtro auto-aplicable** del orquestador para incluir `new_function` con condiciones:
- fn-constructor crea la funcion en el worktree.
- Tests de la funcion pasan en el worktree.
- NO toca apps existentes (solo crea bajo `functions/<domain>/`).
- `fn-revisor` da veredicto `pass`.
3. **Cron `purge_pending_proposals`**: dagu daily que lee proposals `pending` > 14 dias, las marca `stale`, notifica via matrix (flow 0007).
## Tareas
1. Escribir `.claude/agents/fn-revisor/SKILL.md` con plantilla caveman + reglas fn.
2. Editar `.claude/agents/fn-orquestador/SKILL.md`: anadir `new_function` al filtro con condiciones explicitas.
3. Editar `.claude/rules/autonomous_loop.md`: documentar ampliacion + rol de revisor.
4. Crear `bash/functions/pipelines/purge_pending_proposals.sh` + `.md` via `fn-constructor`.
5. Crear DAG dagu `purge_pending_proposals.yaml` en `~/dagu/` (skill `dagu-auto`).
6. Test: crear proposal `new_function` ficticia, lanzar `/autonomous-task` sobre issue dummy que la dispare, verificar que orquestador aplica + revisor revisa + PR draft sale.
## Acceptance
- [ ] `.claude/agents/fn-revisor/SKILL.md` existe + comparte estilo con `caveman-reviewer`.
- [ ] Orquestador aplica proposal `new_function` cuando condiciones cumplen.
- [ ] `fn-revisor` invocado por orquestador antes de `git commit` en `auto/*`.
- [ ] Pipeline `purge_pending_proposals_bash_pipelines` indexado.
- [ ] DAG dagu activo: `dagu status purge_pending_proposals` muestra ultima ejecucion <24h.
- [ ] `pending_proposals` (telemetria UserPromptSubmit) <=1 tras 1 semana.
## DoD
User-facing surface:
- **Donde**: PR drafts en Gitea + tab Monitor "Proposals" del dashboard + matrix bot notifica purgas.
- **Latencia**: revisor responde <2 min por PR.
- **Como vuelve**: `mcp__registry__fn_proposal action="list"`.
- **Onboarding**: "Si abriste proposal y no fue auto-aplicada, fn-revisor explica por que en su output. Lee y decide: aprobar manual o tunear condicion."
dev/issues/0123-flow-runner-meta-paralelo.md
+65
View File
@@ -0,0 +1,65 @@
---
id: "0123"
title: "/flow run + fn-meta-orquestador: ejecutar flows + paralelo issues autonomos"
status: pendiente
type: feature
domain:
- meta
- dev-ux
scope: agent
priority: media
depends:
- "0122"
blocks: []
related:
- "0069"
- "0102"
created: 2026-05-18
updated: 2026-05-18
tags: [flows, runner, meta-orquestador, paralelo, priorizador]
---
# 0123 — Flows ejecutables + meta-orquestador paralelo
## Problema
1. 12 flows declarados en `dev/flows/`, 0 cerrados. Fase 2 (`/flow run`) NUNCA implementada. Flows son docs estaticos sin musculo ejecutivo. Ningun subagente los consume.
2. `parallel-fix-issues` lanza N agentes Claude vanilla en worktrees. `fn-orquestador` lanza 1 issue autonomo en worktree. NO existe combinacion: N issues autonomos coordinados respetando dep-graph.
3. `/work today` prioriza con regla fija (prio+deps+DoD%). NO usa errores e2e, blast radius ni huerfanas para reordenar.
## Decision
Tres piezas:
1. **`/flow run <NNNN>`**: ejecuta Acceptance checkboxes como steps. Cada step = `./fn run <id>` o subagent call. Logea en `data_factory.runs` + `e2e_runs`.
2. **`/fix-flow <NNNN>`**: simetrico a `/fix-issue`. Cierra DoD del flow ejecutando Acceptance + abriendo issues si falla algun step.
3. **`fn-meta-orquestador`** (subagente nuevo): lee `dev/issues/` con `status=pendiente` + dep-graph + telemetria. Spawn N `fn-orquestador` en worktrees paralelos respetando deps. Reusa `parallel-fix-issues/scripts/setup-worktrees.sh`.
4. **`fn-priorizador`** (subagente nuevo): lee issues + telemetria call_monitor (error_rate, blast radius, huerfanas, violations). Output: top-N reordenado para `/work today`.
5. **`fn doctor issues` + `fn doctor flows`**: valida TAXONOMY allowlist + DoD presente + user-facing surface declarada.
## Tareas
1. Implementar `/flow run` en `.claude/commands/flow.md` + parser de Acceptance + dispatcher de steps.
2. Implementar `/fix-flow` espejando `/fix-issue` adaptado al frontmatter de flows.
3. Escribir `.claude/agents/fn-meta-orquestador/SKILL.md` con dep-graph resolver + spawner paralelo.
4. Escribir `.claude/agents/fn-priorizador/SKILL.md` que consulta `call_monitor.operations.db` + `task_runs`.
5. Anadir subcomandos `fn doctor issues` + `fn doctor flows` con funciones auxiliares via `fn-constructor`.
6. Test: lanzar `/fix-flow 0001` (hn-top-stories) end-to-end + verificar acceptance.
## Acceptance
- [ ] `/flow run 0001` ejecuta cada step y reporta pass/fail por step.
- [ ] `/fix-flow 0001` cierra DoD verde y mueve a `dev/flows/completed/`.
- [ ] `fn-meta-orquestador` lanza N orquestadores paralelos sobre issues sin dep entre si.
- [ ] `fn-priorizador` output incluye senal de telemetria (no solo prio+deps).
- [ ] `fn doctor issues --json` detecta drift TAXONOMY.
- [ ] `fn doctor flows --json` detecta flows sin DoD ni user-facing surface.
- [ ] 1 flow real cerrado (`status=done` + en `completed/`).
## DoD
User-facing surface:
- **Donde**: `/flow run` + `/work today` en terminal + tab Work del dashboard.
- **Latencia**: `/flow run` reporta progreso live por step.
- **Como vuelve**: `/work today` cada manana muestra top reordenado.
- **Onboarding**: "Para arrancar el dia, `/work today`. Para cerrar un flow, `/fix-flow <NNNN>`. Para lanzar varios issues a la vez, `fn-meta-orquestador` via skill o spawn manual."