fn_registry/.claude/commands/autonomous-task.md

/autonomous-task — Lanza fn-orquestador (Fase 6 del ciclo reactivo)

Lanza el meta-orquestador autonomo que recorre el bucle CONSTRUIR → EJECUTAR → RECOPILAR → ANALIZAR → MEJORAR sobre un issue, sin intervencion humana, hasta convergencia / estancamiento / timeout / limite de iteraciones.

Issue 0069. Pre-condiciones obligatorias (chequear ANTES de despachar):

1. Migration fn_operations/migrations/006_task_runs.sql aplicada.
2. Subagentes fn-constructor, fn-executor, fn-recopilador, fn-analizador, fn-mejorador, fn-orquestador presentes en .claude/agents/.
3. dev/autonomous_protected_paths.json existe.
4. master local up-to-date con origin/master.
5. Branch auto/<issue_id> NO existe ya.
6. gh auth status OK (necesario para PR draft al converger).
7. Tipo de tarea soportado: feature_app_simple, bugfix_with_repro, refactor_safe, add_e2e_check.

Si alguna pre-condicion falla → ABORT con razon. NO improvisar.

---

Argumento

$ARGUMENTS — <issue_id> o <task_spec_path> + flags opcionales.

/autonomous-task 0070
/autonomous-task 0070 --max-iterations 15 --max-minutes 90
/autonomous-task 0070 --auto-apply-proposals safe
/autonomous-task 0070 --dry-run
/autonomous-task path/to/spec.yaml --branch auto/custom-name

Flags:

• --max-iterations N tope de iteraciones (default 10)
• --max-minutes M timeout total (default 60)
• --auto-apply-proposals none|safe|aggressive (default safe)
• --branch NAME rama TBD (default auto/<issue_id>)
• --dry-run simula, NO aplica

---

Comportamiento

1. Verificar pre-condiciones con script bash (ver arriba). Si alguna falla, reportar y salir.
2. Despachar a fn-orquestador via Agent tool con subagent_type=fn-orquestador. Pasar:
   • issue_id o task_spec
   • flags resueltos
   • paths protegidos (leidos de dev/autonomous_protected_paths.json)
3. El subagente:
   • Crea worktree aislado /tmp/fn_orq_<issue>_<ts>/ desde master.
   • Persiste estado en task_runs (operations.db del app target o repo root).
   • Despacha por fases a los 5 subagentes especializados.
   • Aplica proposals filtradas por --auto-apply-proposals.
   • Termina con: converged (PR draft creado) | stalled | timeout | iterations_exhausted | needs_human | aborted.
4. Reportar resultado al humano con:
   • status, iterations / max, duration / max
   • branch, worktree, PR draft url si converged
   • proposals creadas / aplicadas
   • last run_id y status
   • Resumen iter-por-iter del progress_json

---

Reglas duras (no negociables)

• Sandbox de rama EN WORKTREE — nunca toca master ni el working tree del humano.
• No merge automatico — PR draft siempre.
• No --no-verify, no --force, no skip hooks.
• Paths protegidos via dev/autonomous_protected_paths.json.
• Watchdog: 2 iteraciones con mismo set de fails → status=stalled.
• Auditoria total en task_runs.progress_json.
• No self-modification: NO toca .claude/agents/ ni .claude/commands/.

---

Integracion con call_monitor (issue 0085)

El orquestador puede leer projects/fn_monitoring/apps/call_monitor/operations.db para:

• Consultar function_stats antes de decidir que funciones usar/reusar.
• Filtrar proposals existentes via mcp__registry__fn_proposal --status pending para evitar duplicados.
• Loggear sus invocaciones via el hook PostToolUse (automatico).

Tras converger, el call_monitor propose ejecutado por el humano (o futuro cron) absorbera las nuevas violations / copied_code / fails para alimentar la siguiente ronda.

---

Tipos NO soportados

• Diseño arquitectura nuevo (humano decide).
• Decisiones UX subjetivas.
• Cambios BD productiva.
• Cualquier cosa que toque secrets/credenciales.
• Self-modification del propio orquestador.

Si el issue contiene criterios no-verificables programaticamente, ABORT con status=needs_human.

---

Output canonico

=== /autonomous-task: 0070 ===
status:        converged
iterations:    7 / 10
duration:      23 min / 60
branch:        auto/0070
worktree:      /tmp/fn_orq_0070_1731612345
PR draft:      https://github.com/.../pull/123
proposals:     3 creadas, 2 auto-aplicadas
last run_id:   e2e_run_abc123 (status: pass)

Iter:
  1. construir → ok (2 funciones nuevas)
  2. ejecutar  → ok
  3. analizar  → fail (2/8 checks)
  4. mejorar   → 3 proposals (2 auto-applicadas)
  5. construir → ok (re-build tras patches)
  6. analizar  → pass
  7. recopilador → ok (operations.db integra)

Siguiente: revisar PR draft + fn proposal list -s pending --target-id 0070