---
id: "0166"
title: "Rastrear dependencias entre apps (app→app) para clonado/build reproducible"
status: pendiente
type: enhancement
domain:
  - registry-quality
  - build
scope: registry-only
priority: media
depends: []
blocks: []
related: []
created: 2026-05-31
updated: 2026-05-31
tags: [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).