fn_registry/.claude/commands/fn_claude.md

description

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?

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" <<SQL
SELECT 'calls_session', COUNT(*) FROM calls WHERE session_id = '${CLAUDE_SESSION_ID:-unknown}'
UNION ALL SELECT 'calls_24h', COUNT(*) FROM calls WHERE ts >= 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

-- 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:

# Verifica si ya existe algo similar en el registry
mcp__registry__fn_search "<keyword del candidato>"

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) |
|---|---|---|---|---|
| <name>    | inline_repeated/wrapper_skip/new | go/py/bash | core/infra/... | <heredoc fragment> |

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:

./fn index 2>&1 | tail -2
# Verifica que las nuevas funciones existen
for fn in <lista>; do
    mcp__registry__fn_show "$fn" >/dev/null && echo "OK: $fn" || echo "FAIL: $fn"
done

Tambien actualiza call_monitor.copied_code + function_stats corriendo:

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 <fn_id> 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:

sqlite3 "$MON" "SELECT COUNT(*) FROM calls WHERE session_id = '${CLAUDE_SESSION_ID:-unknown}' AND ts >= <inicio_comando>"

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:        <id>
calls_session:     N
calls_24h:         M (mcp_ratio: 0.XX)
violations_24h:    K
pending_proposals: P (existentes en registry.db)

GAPS DETECTADOS:
  1. <name>_<lang>_<domain> — razon — evidencia
  2. ...

LANZADOS (en paralelo):
  fn-constructor #1: <name1>  → en progreso
  fn-constructor #2: <name2>  → en progreso
  ...

VALIDADAS tras ./fn index:
  ✓ <name1>_<lang>_<domain>  
  ✓ <name2>_<lang>_<domain>

PROPOSALS NUEVAS: <count>

PROXIMO TURNO: menciona `<name1>` 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.