# Roadmap

Cosas por hacer, ordenadas por dónde aporta más un commit. No es una lista de
deseos: cada punto está acotado para que se pueda coger, hacer y medir. Si algo
te interesa, [CONTRIBUTING.md](CONTRIBUTING.md) dice cómo probarlo.

## Ventanas en más gestores

El motor de ventanas es X11 (`config/ventanas.sh`, con `xdotool`). En Wayland ya
hay un backend para **Sway e Hyprland** (`config/ventanas-wayland.sh`), pero está
a medias:

- **Terminar Sway/Hyprland.** `maximiza`, `restaura` y `minimiza` son fiables;
  las mitades (izquierda/derecha/centro) están escritas de la documentación y
  **necesitan probarse** en un equipo real —el flotante y las unidades (`ppt`,
  `%`) cambian por versión—. Es un primer commit ideal si usas uno de los dos.
- **KDE Plasma (Wayland).** Vía `kdotool` o scripting de KWin. Falta el backend.
- **GNOME Wayland.** No hay API general para mover ventanas ajenas (es su modelo
  de seguridad); requiere una extensión. Documentar la limitación o escribir el
  puente a una extensión.
- **Mover entre pantallas y a escritorios virtuales** en Wayland: el X11 lo hace,
  los backends de Wayland aún no.

## Más acciones

El catálogo son 150 órdenes (`nucleo/datos/acciones.json`). Cada una es JSON:
frases que la disparan, un comando de shell, y una plantilla de respuesta. Añadir
una es un commit pequeño y satisfactorio. Ideas que faltan:

- **Multimedia**: play/pausa, siguiente, volumen (`playerctl`, `wpctl`).
- **Brillo** de pantalla (`brightnessctl`).
- **Portapapeles**: leer/copiar (`wl-clipboard` / `xclip`).
- **Capturas** de pantalla (`grim`, `spectacle`, `gnome-screenshot`).
- **Energía**: bloquear, suspender, apagar (con confirmación).
- **Red**: a qué wifi conectar (`nmcli`).
- **Notificaciones** recientes, calendario, temporizadores.

Al añadir acciones que dependan de una herramienta, degradar con gracia si no
está (como hacen las de ventanas).

## Probar con otros modelos

JARVIS ya puede **elegir su modelo** en caliente (herramienta `elegir_modelo`, y
`JARVIS_MODELO` para fijarlo). Lo que falta es saber cuáles van bien:

- **Medir el tool-calling** de más modelos locales (llama, mistral, gemma,
  phi...) con el mismo criterio del RAG (`nucleo/saber/enriquece/eval_set.jsonl`
  da la idea). Cuáles emiten `tool_calls` fiables y cuáles no.
- **Auto-escalado**: que suba a un modelo potente solo cuando la pregunta lo
  pida, y vuelva al rápido. Hoy lo decide el propio modelo; se puede afinar.
- **Un modelo pensado para voz**: respuestas cortas, sin divagar.

## El RAG

- **Reranker**: un cross-encoder sobre los primeros k. Medido que un embedder
  transformer no compensa (ver [docs/rag.md](docs/rag.md)); un reranker es la
  otra palanca sin probar.
- **Corpus de demostración público** para poder ver el RAG funcionando sin los
  apuntes privados de nadie (man pages, docs de una herramienta libre).
- **Troceado que mantenga el bloque de comandos con su encabezado** (hoy separa
  algún comando de su contexto).

## Voz

- **Más idiomas.** Hoy es castellano de punta a punta (STT, prompt, TTS). Piper
  y whisper tienen modelos de otros idiomas; falta parametrizarlo.
- **Fine-tuning de la voz** (Piper/VITS) para clonar mejor con poco audio.

## Fine-tuning del modelo

`entrena/` tiene el pipeline QLoRA, bloqueado porque `qwen3.5` es multimodal y
`FastLanguageModel` lo mete por el camino de solo texto. El arreglo apunta a
`FastVisionModel` con `finetune_vision_layers=False`. Sin probar.

## Empaquetado

- **Perfiles de hardware** en `install.sh` (4 GB / 12 GB / solo-CPU) que ajusten
  el modelo y el contexto solos.
- **Detección de rutas** más fina en los scripts de `config/` y `voz/`, que aún
  asumen parte de la disposición del autor.