fn_registry/.claude/rules/uses_functions.md

uses_functions

Cuando un .cpp llama a otra funcion del registry, el .md del CONSUMIDOR debe anadir la dependencia a uses_functions. El indexer NO lo deduce automaticamente para C++ (parser no trivial).

Como auditar (funciones huerfanas): sqlite3 registry.db "SELECT id FROM functions WHERE lang='cpp' AND uses_functions='[]';"

Como auditar (drift entre CMakeLists.txt y app.md):

• Cruzar los ${CMAKE_SOURCE_DIR}/functions/<dom>/<name>.cpp listados en el CMakeLists.txt con el uses_functions del app.md. Cada .cpp linkado debe aparecer como <name>_cpp_<dom> en el .md. Excepciones: ver mas abajo.

Convencion:

• Framework code (cpp/framework/app_base.cpp) — no esta indexado.
• Funciones bundled en fn_framework — son funciones del registry cuyo .cpp se compila dentro del static lib fn_framework (lista en cpp/CMakeLists.txt, target add_library(fn_framework STATIC ...)): tokens, icon_font, app_settings, app_about, fps_overlay, panel_menu, app_menubar, layouts_menu, logger, log_window, gl_loader, layout_storage, selectable_text. Las apps las usan transitivamente (incluyen core/logger.h, llaman fn_log::log_info), pero NO listan estos .cpp en su CMakeLists.txt (multiple-definition) ni los declaran en uses_functions del app.md. Excepcion: si una app toca una API que no este en fn_framework (raro), declara la dep.
• TU adicional de un parent function (ej. graph_labels_select.cpp que va con graph_labels.cpp) — desde 2026-05-04 se registra como entrada propia con su .md (ver ADR 0003). El parent declara la nueva entrada en su uses_functions. Las apps que enlazan ambos .cpp listan ambas IDs en uses_functions del app.md.
• Apps (apps/, cpp/apps/, projects/*/apps/) son leaves del grafo: declaran uses_functions en app.md pero ninguna funcion del registry las cita.
• DEMO_ONLY en primitives_gallery se etiqueta notes: scaffolding/demo.