Files
fn_registry/dev/issues/0120-orquestador-piloto-verde.md
T
egutierrez 93520c4319 docs(plan): issues 0120-0123 — mejora workflow subagentes
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>
2026-05-18 21:41:02 +02:00

3.3 KiB

id, title, status, type, domain, scope, priority, depends, blocks, related, created, updated, tags
id title status type domain scope priority depends blocks related created updated tags
0120 fn-orquestador: piloto verde end-to-end sobre chart_demo pendiente chore
meta
registry-quality
agent alta
0121
0122
0123
0069
0068
2026-05-18 2026-05-18
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

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)