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