---
id: "57"
title: "Extraer paneles ImGui reutilizables de las apps C++ a cpp/functions/ — roadmap"
status: pendiente
type: epic
domain:
  - cpp-stack
  - registry-quality
scope: cross-stack
priority: media
depends: []
blocks: []
related: []
created: 2026-05-09
updated: 2026-05-17
tags: []
---

## Contexto

Las apps C++ del registry (`cpp/apps/*`, `projects/*/apps/*`) llevan acumulando paneles ImGui que comparten patron pero viven dentro de cada app. Hay duplicacion observable y mas que va a aparecer (navegator_dashboard quiere chat panel igual que graph_explorer; el dashboard de Tabs va a parecerse al panel "Browsers").

Hoy ya estan en el registro `cpp/functions/core/`: `dashboard_panel`, `fullscreen_window`, `log_window`, `modal_dialog`, `tree_view`, `selectable_text`. La capa visual (tokens, theming, iconos, settings/about/menubar) vive en `fn_framework`. Esto cubre primitivas. Falta una tier intermedia: **paneles compuestos** (mas grandes que un widget, mas pequeños que una app).

Este issue documenta el roadmap de que extraer, cuando, y por que.

## Principios

1. **Rule of three** — no extraer hasta que haya 2-3 consumidores reales. Pre-extraer crea abstracciones malas.
2. **Consumidor primero** — escribir el panel inline en la app. Si una segunda app lo necesita, copiar+adaptar. Si una tercera lo pide, extraer.
3. **Parametrizable, no monolitico** — los paneles extraidos reciben un struct de config (callbacks, paths, env vars) en vez de hardcodear nombres.
4. **No exponer estado global del modulo extraido** — usar contexto opaco que cada app crea/destruye.

## Catalogo: paneles candidatos detectados

Revisado todas las apps C++ vivas. Por cada panel: lineas, consumidores actuales, consumidores potenciales, decision.

### Tier 0 — ya extraidos ✓

| Panel | Ubicacion |
|---|---|
| dashboard cards grid | `cpp/functions/core/dashboard_panel.{h,cpp}` |
| fullscreen window wrapper | `cpp/functions/core/fullscreen_window.{h,cpp}` |
| log window con buffer | `cpp/functions/core/log_window.{h,cpp}` |
| modal dialog | `cpp/functions/core/modal_dialog.{h,cpp}` |
| tree view | `cpp/functions/core/tree_view.{h,cpp}` |
| selectable text | `cpp/functions/core/selectable_text.{h,cpp}` |

Estos definen el "lower-tier" — primitivas. Los nuevos extracts componen sobre estos.

### Tier 1 — extraer cuando aparezca el 3er consumidor

#### 1.1 `claude_chat_panel` (origen: graph_explorer/chat.cpp, 1241 LoC)

**Que es:** panel ImGui que arranca un subprocess `claude -p`, le envia mensajes del usuario, parsea stream-json, renderiza historial con tool-use detectado, expone callbacks para que la app recargue cuando el agente muta su BD.

**Consumidores hoy:** graph_explorer.

**Consumidores potenciales:**
- navegator_dashboard (issue navegator/0001) — chat para controlar Chrome.
- kanban (futuro) — agente para crear/mover cards.
- registry_dashboard — agente para crear functions/proposals.

**Por que tier 1 (no tier 0):**
- 59 referencias a `gx-cli`, `GX_OPS_DB`, `GX_APP_DB`, `agent_mutations`. Acoplamiento alto a graph_explorer.
- Refactor a config parametrizado es ~4-6h y modifica codigo que YA funciona — riesgo regresion.
- Con solo 2 consumidores no hay claridad de que parametrizar.

**Cuando extraer:** 3er consumidor pide chat. Hasta entonces: copiar+adaptar (graph_explorer mantiene el suyo, navegator copia el suyo).

**API propuesta cuando se extraiga:**

```cpp
struct ClaudeChatConfig {
    const char* claude_bin;             // "claude" o WSL path
    const char* cli_tool_name;          // "gx-cli", "cdp-cli", "kanban-cli", ...
    const char* cli_tool_dir;
    std::map<std::string, std::string> env_vars;  // GX_*, NAVD_*, ...
    const char* mcp_config_path;        // o func que lo genera on-demand
    const char* system_prompt;          // opcional
    std::function<int()> mutations_counter;  // app-side reload trigger
    const char* log_file_path;
};

namespace fn_ui {
    struct ChatHandle;  // opaco
    ChatHandle* chat_create(const ClaudeChatConfig& cfg);
    void chat_send(ChatHandle*, const char* user_text);
    void chat_render(ChatHandle*, bool* p_open);
    void chat_destroy(ChatHandle*);
}
```

#### 1.2 `jobs_queue_panel` (origen: graph_explorer/jobs.cpp + odr_console/jobs)

**Que es:** panel + sistema de jobs asincronos. Lista jobs en cola/running/done con barra de progreso, stdout/stderr capture, cancelable, persistente entre sesiones.

**Consumidores hoy:** graph_explorer (jobs.cpp + views_jobs.cpp), odr_console (panel Jobs).

**Consumidores potenciales:**
- navegator_dashboard — scraping jobs (un crawl es un job).
- registry_dashboard — fn index, fn run jobs.

**Por que tier 1:** ya hay 2 consumidores, parece duplicacion clara. **Inspeccionar diff entre ambos antes de extraer** — pueden estar implementados distinto y no reusarse del todo.

**Cuando extraer:** despues de auditar que graph_explorer/jobs.cpp y odr_console/jobs comparten >70% del codigo. Si si: 3er consumidor (navegator scraping) detona la extraccion.

**API propuesta:**

```cpp
namespace fn_ui {
    struct Job {
        std::string id;
        std::string title;
        std::function<int(JobContext&)> run;  // retorna exit code
        // ...
    };
    void jobs_panel_init(const char* persistence_db_path);
    void jobs_panel_submit(const Job&);
    void jobs_panel_render(bool* p_open);
}
```

### Tier 2 — extraer cuando aparezca el 2do consumidor (todavia no detectado)

#### 2.1 `project_switcher_panel` (origen: graph_explorer/project_manager.cpp)

**Que es:** sidebar/menu para cambiar entre subcarpetas de proyectos (cada proyecto tiene su DB y settings). Persiste el ultimo proyecto abierto.

**Hoy en:** graph_explorer.

**Potencial:** navegator_dashboard (perfiles browser como proyectos), registry_dashboard (apps como proyectos), kanban (boards).

**Cuando extraer:** cuando navegator_dashboard quiera multi-perfil persistente con settings por perfil. v3 del dashboard probablemente.

#### 2.2 `key_value_inspector_panel` (origen: graph_explorer/views.cpp `Inspector`)

**Que es:** panel "Inspector" generico que muestra propiedades de un objeto seleccionado en formato key:value, con edicion inline opcional. Hoy es ad-hoc para entities.

**Potencial:** navegator_dashboard (Tab Detail mostrar propiedades de pestaña), registry_dashboard (function detail), kanban (card details).

**Cuando extraer:** cuando dos paneles de "ver propiedades de cosa seleccionada" tengan codigo casi identico.

#### 2.3 `paste_and_extract_panel` (origen: graph_explorer/extract_panel.cpp)

**Que es:** panel que recibe texto pegado, invoca enricher Python, muestra entities extraidas + boton para insertarlas.

**Potencial:** navegator_dashboard (extraer texto seleccionado de pestaña), registry_dashboard (extraer descripcion para auto-fill function metadata).

**Cuando extraer:** 2do consumidor con flujo similar.

#### 2.4 `http_request_inspector_panel` (origen: registry_dashboard/http_client.cpp + futuro navegator_dashboard/network)

**Que es:** panel para ver una peticion HTTP (request line, headers, body) renderizado bonito. Read-only.

**Potencial:** navegator_dashboard (Network panel renderiza HAR entries), registry_dashboard (mostrar requests outgoing del fn_registry_api).

**Cuando extraer:** cuando 0070b (HAR record) sea consumido por algo que quiera renderizarlo bien.

### Tier 3 — NO extraer (especificos de su app)

| Panel | Por que NO |
|---|---|
| graph_explorer/types_registry | Acoplado a `types.yaml` schema especifico. |
| graph_explorer/node_groups | DuckDB + grafo + tipo "Table" del schema graph_explorer. |
| graph_explorer/layout_store | Posiciones de nodos del grafo, schema especifico. |
| graph_explorer/views.cpp::Legend | Mapa de tipos→colores especifico del grafo. |
| graph_explorer/views.cpp::Stats | Conteos por tipo de entity, schema especifico. |
| navegator_dashboard/browsers panel | Detector chrome.exe Win32, hereda WMI/CIM, especifico Windows. |
| odr_console/datasets panel | Listado especifico del flujo ODR. |

Estos viven en su app. Si emerge un patron despues, se reconsidera.

### Tier 4 — primitivas que sirven a TODOS los paneles (extraccion oportunista, sin app-driver)

Util tener antes de los Tier 1-2 para hacer la extraccion mas limpia:

| Primitiva | Para que |
|---|---|
| `subprocess_streamer.{h,cpp}` | Encapsula spawn + pipes + read-thread + queue. Lo usaria chat_panel + jobs_panel. |
| `mcp_config_writer.{h,cpp}` | Genera `.mcp.json` para Claude. Lo usaria chat_panel. |
| `app_db_init.{h,cpp}` | Patron generico de "abrir SQLite junto al exe + aplicar migrations embed.FS". Hoy cada app reimplementa. |
| `key_input_history.{h,cpp}` | Input + flecha arriba/abajo recupera entradas previas. Util en chat + REPL evaluate. |
| `json_log_renderer.{h,cpp}` | Render de stream JSON estilo claude-code (rol, tool_use, contenido). Util tanto en chat de graph_explorer como en futuros chats. |

Estas primitivas se extraen cuando empieza la extraccion de un Tier 1 que las necesita (no antes — caen en el "rule of three" tambien).

## Estrategia de adopcion

Por **demanda**:

1. **Hoy (tras este issue):** copiar+adaptar `chat.cpp` a `navegator_dashboard`. Documentar la duplicacion. NO extraer.
2. **Cuando aparezca 3er consumidor de chat** (o `jobs`, o `project_switcher`): pausar feature work, refactorizar el extract con vista 3D.
3. **Auditoria periodica trimestral**: cada 3 meses revisar este issue, contar consumidores actuales, decidir si activar extracts.

## Sub-issues iniciales (no abrir hasta tener 3er consumidor identificado)

- `0071a` — extract `claude_chat_panel` (cuando 3 apps lo pidan).
- `0071b` — extract `jobs_queue_panel` (auditar duplicacion graph_explorer/odr_console primero).
- `0071c` — extract `project_switcher_panel`.
- `0071d` — extract `key_value_inspector_panel`.
- `0071e` — extract `http_request_inspector_panel`.

## Definicion de hecho (issue 0071 cerrado)

- Catalogo arriba esta vivo, refleja apps actuales.
- Auditoria trimestral mantiene la lista actualizada.
- Sub-issues 0071a-e: cada uno abre cuando se cumple su criterio.
- Cuando todos los Tier 1 + 2 esten extraidos, este issue se marca completed.

## Anti-patron a evitar

- **Big-bang refactor**: extraer 5 paneles a la vez, con interfaces no validadas, rompiendo todas las apps. NO.
- **Pre-extraer "por si acaso"**: el panel mas dificil es el que solo tiene 1 consumidor — no sabes que parametrizar. NO.
- **Library wrapper sin control**: meter `claude_chat_panel` con 30 hooks/callbacks "para flexibilidad". KISS — solo expone lo que el 3er consumidor demuestra que necesita.