fn_registry/modules

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

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