diff --git a/dev/issues/0120-orquestador-piloto-verde.md b/dev/issues/0120-orquestador-piloto-verde.md new file mode 100644 index 00000000..2a625c4d --- /dev/null +++ b/dev/issues/0120-orquestador-piloto-verde.md @@ -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 `. Tras converger, abre PR draft. Si falla, lee `task_runs.events_json` para reconstruir las decisiones." + +## Hallazgos + +(Rellenar tras ejecucion) diff --git a/dev/issues/0121-e2e-checks-coverage-masa.md b/dev/issues/0121-e2e-checks-coverage-masa.md new file mode 100644 index 00000000..c26b24e7 --- /dev/null +++ b/dev/issues/0121-e2e-checks-coverage-masa.md @@ -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 ` 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 ` 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/.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." diff --git a/dev/issues/0122-fn-revisor-auto-apply.md b/dev/issues/0122-fn-revisor-auto-apply.md new file mode 100644 index 00000000..b99470c1 --- /dev/null +++ b/dev/issues/0122-fn-revisor-auto-apply.md @@ -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: : . .`. 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//`). + - `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." diff --git a/dev/issues/0123-flow-runner-meta-paralelo.md b/dev/issues/0123-flow-runner-meta-paralelo.md new file mode 100644 index 00000000..c39ae0bc --- /dev/null +++ b/dev/issues/0123-flow-runner-meta-paralelo.md @@ -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 `**: ejecuta Acceptance checkboxes como steps. Cada step = `./fn run ` o subagent call. Logea en `data_factory.runs` + `e2e_runs`. +2. **`/fix-flow `**: 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 `. Para lanzar varios issues a la vez, `fn-meta-orquestador` via skill o spawn manual."