Files
fn_registry/dev/issues/0122-fn-revisor-auto-apply.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
0122 fn-revisor + auto-apply ampliado: desbloquear fase 5 pendiente feature
meta
registry-quality
agent alta
0121
0123
0069
0086
2026-05-18 2026-05-18
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."