fn_registry/dev/issues/0166-app-to-app-dependencies-tracking.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
0166	Rastrear dependencias entre apps (app→app) para clonado/build reproducible	pendiente	enhancement	registry-quality build	registry-only	media				2026-05-31	2026-05-31	build apps dependencies clone migration

0166 — Rastrear dependencias entre apps (app→app)

APP Metadata

Campo	Valor
ID	0166
Estado	pendiente
Prioridad	media
Tipo	enhancement — metadata de apps + fn app clone / fn doctor

Contexto

Durante la migración a Linux nativo (PC lucas-linux, 2026-05-31) al levantar los servicios systemd hubo que clonar+compilar los apps de servicio. El build de sqlite_api (projects/fn_monitoring/apps/sqlite_api) falló con:

handlers.go:13:2: package fn-registry/apps/data_factory/datafactory is not in std

sqlite_api importa un paquete de otro app (apps/data_factory/datafactory). Como data_factory no estaba clonado, no compilaba. Hubo que clonarlo a mano para desbloquear el build. No hay forma declarada de saber, antes de clonar/compilar un app, qué otros apps necesita.

Problema

• fn app clone <id> clona solo el repo pedido; no arrastra los apps de los que depende.
• fn sync locations lista paths por PC pero no relaciones app→app.
• El grafo de dependencias entre apps es implícito (vive solo en los import de Go), así que clonar el subset correcto en una máquina nueva es ensayo-error.

Objetivo

Hacer explícitas y consultables las dependencias app→app, para que:

1. Se pueda saber qué apps dependen de qué apps (consulta / reporte).
2. fn app clone <id> pueda arrastrar los apps-dependencia (o al menos avisarlos).
3. fn doctor detecte clones incompletos (app presente pero su dep ausente).

Propuesta (a concretar)

1. Metadata declarada en app.md: añadir campo depends_on_apps: [<id>...] en el frontmatter (análogo a uses_functions/uses_types de las funciones).
2. Detección automática (validación): un audit que parsee los import de cada app, detecte imports de la forma fn-registry/apps/<X>/... o .../projects/.../apps/<X>/... y compare con depends_on_apps (igual que audit_uses_functions para funciones).
   • Caso semilla confirmado: sqlite_api → data_factory.
3. fn app clone --with-deps <id>: resuelve el cierre transitivo de depends_on_apps y clona todo lo necesario a las rutas de pc_locations.
4. fn doctor: marcar [incomplete-clone] si un app está clonado pero falta un depends_on_apps.

Notas

• Relacionado (mismo arrastre de migración, issues aparte si procede):
  • Los repo_url de varios apps de servicio (registry_api, services_api) apuntan al alias gitea.organic-machine.com que no resuelve; el host real es gitea-dgg044oo04woo4ggcsws4gk0.organic-machine.com. fn app clone falla por eso.
  • Los go.mod de los apps de servicio requieren go mod tidy antes de compilar (deps faltantes con go 1.26).

Criterio de hecho

• Campo depends_on_apps documentado y poblado al menos en sqlite_api.
• Audit que detecta imports app→app y reporta drift vs depends_on_apps.
• fn app clone resuelve dependencias (o las avisa).