fn_registry/.claude/commands/modo_launcher.md

description

description
Modo launcher: das ordenes en lenguaje natural y Claude responde SOLO con la procedencia (registry/bash/heredoc) + el comando exacto, y lo ejecuta. Agiliza el lanzamiento de comandos y audita en vivo el Reg % (uso real de funciones del registry).

/modo_launcher — lanzamiento rápido registry-first

Activa un modo de comportamiento persistente. Mientras estás dentro, el usuario da órdenes en lenguaje natural y Claude responde con el mínimo absoluto: la procedencia del comando + el comando exacto + por qué, y lo ejecuta. Sin prosa, sin explicaciones largas, sin preámbulos.

El objetivo es doble:

1. Agilizar el lanzamiento de comandos (cero verborrea entre orden y ejecución).
2. Auditar en vivo que de verdad pasamos por funciones del registry antes que por bash inline — sube Reg % (objetivo 1 del Norte) y expone gaps reutilizables (objetivo 3).

Activación

Al invocar /modo_launcher entras en MODO LAUNCHER. El modo permanece activo en todos los turnos siguientes hasta que el usuario escriba salir o fin launcher. No hay hook: el modo se sostiene por estas instrucciones mientras estén en contexto. Si el comportamiento se diluye tras muchos turnos, el usuario puede re-invocar /modo_launcher para reanclarlo.

Al entrar, responde con una sola línea de confirmación y queda a la espera:

MODO LAUNCHER activo. Da ordenes. 'salir' para terminar.

Comportamiento por orden (regla dura)

Para CADA orden del usuario mientras el modo esté activo:

1. Registry-first. Mapea la orden a una capacidad y busca primero en el registry vía FTS (mcp__registry__fn_search) o reconoce un ID conocido. Las funciones del registry SIEMPRE tienen prioridad sobre bash inline.
2. Clasifica la procedencia según la taxonomía de abajo.
3. Ejecuta directo. Identificado el comando, ejecútalo sin pedir permiso — salvo que sea destructivo (ver guarda).
4. Responde en el formato fijo (abajo), con la salida cruda del comando. Nada más.

Formato de respuesta (OBLIGATORIO en cada orden)

FUENTE: <etiqueta>
CMD:    <comando exacto>
WHY:    <razón: match FTS, ID conocido, o "sin función → bash">
──────────
<salida cruda del comando>

• FUENTE es una de las etiquetas de la taxonomía.
• CMD es el comando literal lanzado (forma ./fn run <id> [args] para legibilidad aunque la ejecución real vaya por MCP).
• WHY es una línea: qué match de búsqueda o qué ID justifica esa elección. Si fue un gap, dilo.
• Tras la regla ──────────, la salida cruda. Cero comentario después salvo que el usuario pregunte.

Taxonomía de procedencia

Etiqueta	Qué es	Cómo se ejecuta
registry-run	Ejecutar UNA función o pipeline del registry	mcp__registry__fn_run <id> [args] (preferido); fallback ./fn run <id> [args]
registry-mcp	Inspeccionar el registro (buscar, ver, código, deps, dominios)	mcp__registry__fn_search / fn_show / fn_code / fn_uses / fn_list_domains
heredoc	Componer N funciones con lógica intermedia (loops, dispatch)	Heredoc python/.venv/bin/python3 - <<'PY' ... PY importando del registry
bash	Comando shell puro: no existe función que lo cubra	Bash directo
gap	No hay función Y el patrón parece reutilizable	Ejecuta el bash equivalente y marca el candidato (ver abajo)

Preferencia de ejecución para registry-run

• Usa mcp__registry__fn_run cuando esté disponible (queda registrado en call_monitor, alimenta el bucle reactivo).
• Si el MCP fn_run no está habilitado (requiere --enable-run), cae a ./fn run <id> por terminal. La línea CMD muestra siempre la forma ./fn run <id> por legibilidad.

Gaps: orden sin función en el registry

Cuando una orden no tenga función que la cubra:

1. Ejecuta el bash equivalente (FUENTE: bash).
2. Si el patrón parece reutilizable (firma genérica, se repetiría en otras tareas, ≥5 líneas de lógica), añade tras la salida UNA línea:

CANDIDATO → <nombre_propuesto>_<lang>_<domain>: <1 frase de qué haría>

No lances fn-constructor automáticamente dentro del modo (rompería el ritmo de lanzamiento). Solo marca. El usuario decide al salir si promueve los candidatos.

Guarda de comandos destructivos

Ejecuta directo SALVO que el comando sea irreversible o de alto impacto. En esos casos, NO ejecutes: muestra el bloque con FUENTE/CMD/WHY y añade ⚠ DESTRUCTIVO — confirma con 'ok' en vez de la salida. Espera el ok explícito del usuario antes de lanzar.

Patrones que exigen confirmación:

• rm -rf, borrado de archivos versionados, > archivo sobre archivos trackeados.
• git push --force, git reset --hard, git clean, borrado de ramas.
• SQL DROP, DELETE sin WHERE, TRUNCATE, borrar cualquier .db.
• deploy, systemctl stop/restart/disable de services, fn sync (escribe en el servidor).
• kill -9 masivo, format, mkfs, dd, cambios en fstab.

Para todo lo demás (lecturas, búsquedas, fn run de funciones puras o idempotentes, git status/add/commit, listados), ejecuta directo.

Salida del modo

Cuando el usuario escriba salir o fin launcher, cierra el modo con un resumen caveman de una tabla:

=== fin MODO LAUNCHER ===
ordenes:    N
registry:   X  (run A / mcp B)
bash:       Y
gaps:       Z  → [lista de candidatos marcados]
Reg %:      X/(X+Y) de las ordenes ejecutables golpearon el registry

Si hubo candidatos a función (gap), recuérdalos y pregunta si promover alguno vía fn-constructor.

Reglas duras del modo

• Registry-first siempre. Nunca escribas bash inline para lógica que ya es función del registry. Busca antes de teclear.
• Cero prosa fuera del bloque. Nada de "Claro, voy a…". Solo el bloque FUENTE/CMD/WHY/salida.
• Una orden = un bloque. Si la orden necesita varios pasos, encadénalos en un solo CMD o numera los bloques, pero mantén el formato.
• No inventes IDs. Si no encuentras función por búsqueda, es gap, no un registry-run falso.
• El modo no exime de las reglas del repo (registry_calls.md, purity.md, etc.). Solo cambia el estilo de respuesta.

Ejemplo de sesión

tú: /modo_launcher
yo: MODO LAUNCHER activo. Da ordenes. 'salir' para terminar.

tú: busca funciones de slice
yo: FUENTE: registry-mcp
    CMD:    mcp__registry__fn_search query="slice"
    WHY:    inspección directa del registro
    ──────────
    filter_slice_go_core — Filtra slice por predicado
    chunk_slice_go_core   — Parte slice en lotes de N
    ...

tú: mata lo que escuche en el puerto 8484
yo: FUENTE: registry-run
    CMD:    ./fn run port_kill_bash_infra 8484
    WHY:    match FTS 'port kill' → port_kill_bash_infra
    ──────────
    killed pid 33120 on :8484

tú: enséñame el uso de disco de home
yo: FUENTE: bash
    CMD:    du -sh /home/enmanuel/* | sort -rh | head
    WHY:    sin función → utilidad de sistema puntual
    ──────────
    12G   /home/enmanuel/fn_registry
    ...
    CANDIDATO → disk_usage_top_bash_shell: top-N directorios por tamaño en una ruta

tú: salir
yo: === fin MODO LAUNCHER ===
    ordenes:    3
    registry:   2  (run 1 / mcp 1)
    bash:       1
    gaps:       1  → disk_usage_top_bash_shell
    Reg %:      2/3 (67%)
    1 candidato marcado. ¿Promuevo disk_usage_top_bash_shell vía fn-constructor?

Relación con otras reglas

• registry_calls.md — el modo es una capa de estilo sobre los tres patrones canónicos (inspect / run / compose).
• registry_first.md — el modo materializa "buscar antes de escribir" en cada orden.
• function_growth_and_self_docs.md — los candidatos marcados alimentan la promoción de patrones inline a funciones.
• kiss.md — sin hook, sin estado en disco: el modo vive solo en estas instrucciones.