fn_registry/dev/issues/completed/0107d-module-tiers-policy.md

id, title, status, type, domain, scope, priority, depends, blocks, related, created, updated, tags

id	title	status	type	domain	scope	priority	depends	blocks	related	created	updated	tags
0107d	Sacar lua_engine/llm_anthropic/join_tables/auto_detect_type del modulo data_table — politica de tiers	pendiente	refactor	cpp-stack meta	module	alta	0107c		0107	2026-05-17	2026-05-17	modules data-table policy tiers lua llm

0107d — Politica members generales + tiers

Parte del issue principal 0107.

Problema

data_table module hoy lleva como miembros lua_engine, llm_anthropic, join_tables, auto_detect_type. Esos 4 son utiles fuera de tablas:

• lua_engine: scripting general.
• llm_anthropic: LLM wrapper, util en chat_ia (proximo modulo) y otros.
• join_tables: util en cualquier app que combine tablas (no solo data_table::render).
• auto_detect_type: util en data import generico.

Forzar membership infla el modulo y obliga a las apps a tragarse 4 deps pesadas (lua + curl + libllm + http) aunque solo quieran render basico.

Decision

Politica de tiers:

# module.md (post-0107d)
members:
  # core_members: esenciales, sin ellos no hay funcionalidad
  - data_table_chips_cpp_viz
  - data_table_grid_cpp_viz
  - data_table_drill_cpp_viz
  - data_table_color_rules_cpp_viz
  - data_table_viz_panels_cpp_viz
  - compute_stage_cpp_core
  - compute_pipeline_cpp_core
  - compute_column_stats_cpp_core
  - tql_emit_cpp_core
  - tql_helpers_cpp_core
  - tql_apply_cpp_core
  - tql_to_sql_cpp_core
  - viz_render_cpp_viz

uses_functions:
  # Deps externas usadas por el modulo (no son miembros del modulo)
  - lua_engine_cpp_core         # TQL scripting (opt-in via feature flag interno)
  - llm_anthropic_cpp_core      # Ask AI panel (opt-in via FN_LLM_ANTHROPIC)
  - join_tables_cpp_core        # Joins
  - auto_detect_type_cpp_core   # Detect tipos al cargar nueva tabla

Distincion:

• members: funciones que el modulo POSEE — viven en cpp/functions/viz/ y nadie mas las usa directamente (renderizan dentro del modulo).
• uses_functions: funciones que el modulo CONSUME — viven en cpp/functions/core/, son utiles fuera del modulo, otras apps pueden importarlas directamente.

Apps consumidoras de data_table:

• Si solo llaman data_table::render(...) → solo uses_modules: [data_table_cpp], nada mas.
• Si ademas usan lua_engine directamente para sus propios scripts → anaden lua_engine_cpp_core a uses_functions (no es duplicado, es uso directo independiente).

Tareas

• 4.1 Editar modules/data_table/module.md: separar members core de uses_functions. Bump version 2.1.0.
• 4.2 Editar modules/data_table/CMakeLists.txt: lua_engine.cpp, llm_anthropic.cpp, join_tables.cpp, auto_detect_type.cpp quedan dentro de la static lib (el modulo los usa internamente), pero el linkage transitivo se controla via PUBLIC vs PRIVATE. Si una app NO usa directamente lua/llm fuera del modulo, igual los recibe pero solo como impl detail del modulo. Decidir: SI mantenemos lua/llm/join dentro de la static lib del modulo (PUBLIC link) o sacamos al app para que cada una decida (PRIVATE en modulo, app linkea por su lado).
• 4.3 Documentar tier en docs/MODULES_API.md (0107f).
• 4.4 fn doctor modules (0107a) entiende la distincion members vs uses_functions y NO marca drift cuando una app lista en uses_functions algo que el modulo declara en su uses_functions (no es miembro).
• 4.5 Actualizar 7 app.md: si un app necesita lua/llm/join standalone, declararlo. Si no, no.

Decisiones de diseno

Decision 4.2 detallada: mantener lua/llm/join dentro de fn_module_data_table static lib (PUBLIC), porque:

• 100% de las apps que linkean fn_module_data_table hoy lo usan para tablas, que usan internamente lua/llm/join.
• Cero apps quieren un "data_table ligero sin lua". Si llegara ese caso → split modulo en data_table_core + data_table_full. Mientras tanto, KISS.
• La distincion members vs uses_functions queda solo en module.md (metadata) — el CMakeLists agrupa todo bajo la static lib.

Riesgos

• Ambiguedad "¿el modulo posee X o lo usa?": resolver via 1 regla simple — si X aparece como funcion suelta consumida por otras apps fuera del modulo, va a uses_functions. Si nadie mas la usa, es member.