--- 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: CMD: WHY: ────────── ``` - `FUENTE` es una de las etiquetas de la taxonomía. - `CMD` es el comando literal lanzado (forma `./fn run [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 [args]` (preferido); fallback `./fn run [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 ` por terminal. La línea `CMD` muestra siempre la forma `./fn run ` 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 → __: <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.