# Modulos C++ del registry

Bundles versionados de funciones del registry expuestos como static libs cmake. Apps opt-in via `app.md::uses_modules` + `target_link_libraries(... fn_module_<X>)`.

## Catalogo

| Modulo | Version | Static lib | Header | Entry | Linkage | Descripcion | Contrato |
|---|---|---|---|---|---|---|---|
| [framework_cpp](framework/module.md) | 1.1.0 | `fn_framework` | `framework/app_base.h` | `fn::run_app(cfg, render)` | transitivo via `add_imgui_app` | Shell ImGui (GLFW+OpenGL+ImGui+ImPlot+themas+layouts+logger) | [framework_cpp](../docs/MODULES_API.md#framework_cpp) |
| [data_table_cpp](data_table/module.md) | 2.1.0 | `fn_module_data_table` | `data_table/data_table.h` | `data_table::render(id, tables, state, events_out, show_chrome)` | explicito | Tabla completa TQL + 9 renderers declarativos + viz + drill + AI + button events | [data_table_cpp](../docs/MODULES_API.md#data_table_cpp) |

## Diferencia `members` vs `uses_functions` (post 0107d)

Cada `module.md` declara DOS listas:

- **`members`**: funciones del registry que el modulo POSEE. Viven en `cpp/functions/<dominio>/` y NO se usan fuera del modulo. Apps consumidoras del modulo NO listan estos miembros en su `uses_functions` (cobertura transitiva).
- **`uses_functions`**: funciones del registry que el modulo CONSUME pero NO posee. Utiles fuera del modulo. Si una app necesita estas STANDALONE, las declara en su propio `uses_functions` directamente (no es duplicacion — es uso independiente).

Ejemplo `data_table_cpp` v2.1.0:
- `members`: las 7 sub-funciones `data_table_*_cpp_viz` (renderizan dentro del modulo).
- `uses_functions`: `lua_engine`, `llm_anthropic`, `join_tables`, `auto_detect_type`, `tql_*`, `compute_*`, `viz_render` (consumidas por el modulo pero utiles solas).

## Como anadir un modulo

1. `mkdir modules/<name>/` con:
   - `module.md` (frontmatter: name, version, description, members, uses_functions, dir_path).
   - `CMakeLists.txt` definiendo `add_library(fn_module_<name> STATIC ...)`.
   - `<name>.cpp` + `<name>.h` (entry function).
   - `<name>_internal.h` si tiene >1 archivo + UiState compartido.

2. Anadir `add_subdirectory(${CMAKE_SOURCE_DIR}/../modules/<name> ${CMAKE_BINARY_DIR}/modules/<name>)` en `cpp/CMakeLists.txt`.

3. Anadir fila en este catalogo + seccion en `docs/MODULES_API.md` siguiendo el template.

4. `fn index` registra el modulo en `registry.db::modules`.

5. Cada bump de version: `/version modules/<name> <major|minor|patch> "<reason>"`. Edita `module.md::version` + `## Capability growth log`.

## Auditoria

- `fn doctor modules` (0107a): detecta drift `uses_modules` vs `uses_functions` en apps. Hoy: 0 drift en 8 apps consumidoras de `data_table_cpp` post-0107b.
- `audit_data_table_usage_go_infra` (capability del registry): audita patrones de uso del modulo `data_table` en apps. Detecta `inline_begintable`, `state_not_persistent`, `no_child_host`, `no_event_sink`, `cmake_missing_link`. Output en `dev/data_table_integration_audit.md`.

## Ciclo de vida + version policy

Ver `docs/MODULES_API.md::Ciclo de vida de un modulo` y `.claude/rules/cpp_apps.md`.

Semver estricto:
- **Major** = breaking ABI/API publica del modulo (entry function, State struct expuesto, eliminacion de members).
- **Minor** = additive backward-compatible (nuevo renderer, nuevo evento, refactor interno sin cambio de API).
- **Patch** = bugfix sin cambio de API.

Slash command para bumpear: `/version modules/<name> <bump-type> "<reason>"`.

## Modulos en roadmap (post 0107)

- `chat_ia_cpp` — sera el siguiente modulo. Bloqueado hasta cierre completo de 0107 (estandarizacion modulos). Issue 0109 cuando 0107 cierre.
- Otros candidatos detectados por uso repetido en apps: TBD (auditar con `audit_data_table_usage` pattern para otros bundles).