--- description: "Auto-auditoria: verifica que la sesion registra uso de funciones, detecta gaps (patrones inline repetidos, wrappers saltados, heredocs sin function_id), lanza fn-constructor en paralelo para crear las funciones que faltan, y valida que Claude usara las nuevas en el siguiente turno" --- # /fn_claude — auto-auditoria + auto-construccion del registry Comando meta: Claude se audita a si mismo. Verifica que su comportamiento en esta sesion (y las recientes) deja rastro en `call_monitor.operations.db`, detecta gaps reales del registry para el trabajo actual, lanza sub-agentes `fn-constructor` en paralelo para cerrar esos gaps, y verifica que la proxima vez usara las funciones nuevas. Issue 0085 fase autocompleta. Reemplaza el flujo manual de "veo un patron, decido si extraer, escribo proposal, espero humano, fn-mejorador genera, fn-orquestador opera". Con `/fn_claude` Claude hace todo eso solo, **autonomamente para si mismo**. --- ## Comportamiento (ejecutalo en este orden) ### 1. AUDIT — ¿estoy siendo registrado? ```bash ROOT="/home/lucas/fn_registry" MON="$ROOT/projects/fn_monitoring/apps/call_monitor/operations.db" # Pre-condiciones [ -f "$MON" ] || { echo "call_monitor.operations.db NO existe — issue 0085a no aplicado"; exit 1; } [ "$FN_TELEMETRY" = "1" ] || echo "WARNING: FN_TELEMETRY != 1 — wrappers Python/Bash inactivos" # Metricas de la sesion actual + ultimas 24h sqlite3 "$MON" <= CAST(strftime('%s','now','-1 day') AS INTEGER) UNION ALL SELECT 'violations_24h', COUNT(*) FROM violations WHERE ts >= CAST(strftime('%s','now','-1 day') AS INTEGER) UNION ALL SELECT 'tool_used_distribution_24h', NULL; SELECT tool_used, COUNT(*) FROM calls WHERE ts >= CAST(strftime('%s','now','-1 day') AS INTEGER) GROUP BY tool_used ORDER BY 2 DESC; SQL ``` Si `calls_session = 0` → algo esta mal (hook PostToolUse no fire o BD no escribible). Reporta y para. Si `mcp_*` / total < 0.4 → estas usando demasiado heredoc/sqlite directo. Reporta como warning. ### 2. GAP — ¿que funciones faltan? Dos fuentes: #### 2a. Patrones repetidos en heredocs/Edit ```sql -- En call_monitor.operations.db SELECT tool_used, COUNT(*) AS hits FROM calls WHERE function_id = '' AND ts >= CAST(strftime('%s','now','-7 days') AS INTEGER) AND tool_used IN ('heredoc_py', 'heredoc_bash', 'sqlite_direct') GROUP BY tool_used; ``` Si `heredoc_py > 5` sin function_id → Claude esta componiendo logica que probablemente debe ser pipeline. Investigar el ultimo heredoc del transcript: si reescribe algo que ya es funcion del registry → violation candidate. Si no, es candidato a pipeline nuevo. #### 2b. Trabajo actual de la sesion — gap inferido del contexto Lee el ultimo prompt del usuario y los ultimos 10 turnos. Lista funciones que: - Has llamado inline (sed/awk/jq custom, transformaciones de datos, parsing). - Has reinventado (HTTP client raw, SQLite open con flags, FS walks). - Has compuesto >2 veces con el mismo shape. Para cada candidato: ```bash # Verifica si ya existe algo similar en el registry mcp__registry__fn_search "" ``` Si NO existe match relevante → candidato a `fn-constructor`. Si existe pero firma incompleta → candidato a `improve_function` (proposal, NO auto-construccion). ### 3. PROPOSE — lista candidatos Genera tabla: ``` | Candidato | Razon | Lenguaje | Dominio | Evidencia (snippet) | |---|---|---|---|---| | | inline_repeated/wrapper_skip/new | go/py/bash | core/infra/... | | ``` Si lista vacia → "no gaps detected, sesion saludable" + reporta metricas. Para. ### 4. CONSTRUCT — lanza fn-constructor en paralelo Para cada candidato, dispara un sub-agente `fn-constructor` con prompt autocontenido: ``` Agent(subagent_type="fn-constructor", prompt=...) ``` Prompts en PARALELO en un mismo mensaje (varios Agent calls). Pasar: - nombre propuesto, lang, domain - firma esperada (params + return) - pureza - descripcion + ejemplo de uso (heredoc real detectado) - nota: "esta funcion la necesita Claude para auto-uso futuro" ### 5. VALIDATE — ¿la proxima sesion la usara? Despues de que fn-constructor termine: ```bash ./fn index 2>&1 | tail -2 # Verifica que las nuevas funciones existen for fn in ; do mcp__registry__fn_show "$fn" >/dev/null && echo "OK: $fn" || echo "FAIL: $fn" done ``` Tambien actualiza `call_monitor.copied_code` + `function_stats` corriendo: ```bash cd "$ROOT/projects/fn_monitoring/apps/call_monitor" && ./call_monitor copied-code && ./call_monitor propose ``` Reporta: - N funciones nuevas creadas (con IDs) - N proposals nuevas en `registry.db.proposals` - Recomendacion al usuario: "proximo turno mencionar/usar `` para validar que el wrapper se invoca correctamente" ### 6. SELF-TEST — telemetria del propio /fn_claude `/fn_claude` mismo debe quedar registrado. Tras ejecutar, query final: ```bash sqlite3 "$MON" "SELECT COUNT(*) FROM calls WHERE session_id = '${CLAUDE_SESSION_ID:-unknown}' AND ts >= " ``` Si la cuenta no aumento → el comando esta operando fuera de la telemetria (bug). Reportar. --- ## Reglas duras 1. **NO ejecutar fn-constructor para algo que ya existe.** Buscar primero via `mcp__registry__fn_search`. Si match relevante → NO crear duplicado. 2. **NO crear funciones especulativas.** Cada candidato debe tener evidencia real (snippet de heredoc o llamada inline detectada en esta sesion o en `call_monitor.calls` reciente). 3. **PARALELO**: si hay >1 candidato, lanza todos los `fn-constructor` en un solo mensaje con multiples `Agent` calls. NO secuencial. 4. **No autonomous merge**: las funciones nuevas viven en el branch local. NO push automatico. Humano revisa y push manual. 5. **Limites duros**: max 5 funciones nuevas por invocacion. Si detectas mas, prioriza por evidence weight (`occurrences * recency`) y reporta el resto como pending. 6. **Si la sesion no esta siendo registrada (`calls_session = 0`)**: ABORT antes de fase 2. No tiene sentido auto-construir sin telemetria. --- ## Output canonico ``` === /fn_claude — auto-auditoria === session_id: calls_session: N calls_24h: M (mcp_ratio: 0.XX) violations_24h: K pending_proposals: P (existentes en registry.db) GAPS DETECTADOS: 1. __ — razon — evidencia 2. ... LANZADOS (en paralelo): fn-constructor #1: → en progreso fn-constructor #2: → en progreso ... VALIDADAS tras ./fn index: ✓ ____ PROPOSALS NUEVAS: PROXIMO TURNO: menciona `` para validar wrapper. ``` --- ## Cuando usar - Al inicio de una sesion larga, para verificar telemetria activa. - A media sesion, cuando notes que estas reescribiendo el mismo bloque. - Antes de cerrar sesion, para capitalizar lo aprendido como funciones reutilizables. - Tras `/autonomous-task` para validar que el orquestador no genero ruido (proposals/funciones huerfanas). --- ## Cuando NO usar - En sesiones cortas (<5 turnos) — no hay datos suficientes. - Si `call_monitor.operations.db` no esta inicializado (`call_monitor init` primero). - Si el usuario quiere control manual del proceso de extraccion. Este comando es agresivo.