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

66 lines
3.3 KiB
Markdown

---
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."