Feature: Herramienta de frescura de dependencias (s93)

Descripción general

Sesión 93: herramienta interna que da visibilidad única sobre el estado de frescura de las dependencias de terceros en dos repositorios (CreaRack-Pro + CreaRackSL-Workspace).

Muestra, de un vistazo, qué librerías se han quedado viejas sin necesidad de Dependabot ni Renovate:

Versión pineada (del manifiesto)
Versión instalada (del lockfile o CI)
Versión última (consultada en vivo en PyPI/npm)
Desfase semver (major/minor/patch) con alertas visuales por severity

Ordena por mayor desfase primero.

Motivación

No había detección automatizada de dependencias desactualizadas. Con ~112 deps (22 major desactualizadas al día de entrega), el riesgo de quedar peligrosamente atrás era alto.

Alcance en s93

CreaRack-Pro (este repo)

scripts/deps_freshness.py (353 LOC, stdlib puro)
- Parsea manifiestos sin hardcodeo: requirements.txt, frontend/package.json, terminal/agent/requirements-agent.lock
- Resuelve instaladas de pip-list.json, lockfiles, pnpm-list.json
- Consulta PyPI/npm JSON APIs (nunca caché de modelo LLM)
- Calcula desfase semver e publica en el Workspace
.github/workflows/deps-freshness.yml (121 LOC)
- Cron semanal lunes 06:30 UTC
- Triggers: push a manifiestos, workflow_dispatch manual
- Setup backend (pip) + workspace (pnpm) en CI
- Ejecuta colector y publica snapshot en POST /api/tools/deps

Workspace (repo separado, PR propio)

Tool /tools/deps (página web)
Endpoint GET/POST /api/tools/deps
Tabla D1 deps_freshness
2 guías wiki: feature coloquial + runbook técnica

Manifiestos cubiertos

Repo	Ruta	Ecosistema
CreaRack-Pro	`requirements.txt`	PyPI
CreaRack-Pro	`frontend/package.json`	npm
CreaRack-Pro	`terminal/agent/requirements-agent.lock`	PyPI (lockfile 100% ==)
CreaRack-Pro	`tests/requirements.txt`	PyPI (`is_dev=1`, desde 11-07-2026)
CreaRack-Pro	`tests/parity_validation/requirements.txt`	PyPI (`is_dev=1`, desde 11-07-2026)
Workspace	`package.json`	npm

Desde el 28-08-2026 las filas se deduplican por (repo, ecosistema, paquete): un paquete que aparece en varios de estos manifiestos sale una sola vez, con la horquilla más restrictiva, y la fila lista el resto en el campo manifests.

Flujo de datos

┌─ CreaRack-Pro/main
│  ├─ requirements.txt ─┐
│  ├─ frontend/package.json ├─> scripts/deps_freshness.py
│  ├─ terminal/agent/requirements-agent.lock ─┤ (+ deps_specs.py, deps_sources.py)
│  ├─ tests/**/requirements.txt ──────────────┤ • latest + versiones via PyPI/npm
│  └─ Workspace/package.json ─────────────────┘ • resuelve cada horquilla
│                                                • "instalada": PROD → CI → lock
│  Fuentes de "instalada", por orden:
│   1. PROD   GET crearack.com/api/installed-packages  (Bearer INTERNAL_TOOLS_TOKEN)
│   2. runner pip list / pnpm list del job de CI       (respaldo)
│   3. lock   package-lock.json · requirements-agent.lock
│
│  .github/workflows/deps-freshness.yml
│  └─> POST /api/tools/deps (Workspace) ──────────────────┐
│                                                            │
└──────────────────────────────────────────────────────────┤
                                                            │
                                          Workspace/D1 table
                                          deps_freshness
                                               │
                                               v
                                        /tools/deps (UI)
                                        ┌────────────────────────────┐
                                        │ PKG | PEDIDA | EN USO | LAG│
                                        │ django | ==6.0.8 | prod |  │
                                        │ ...                        │
                                        └────────────────────────────┘

Desde el 28-08-2026 (task #275) la columna «en uso» sale por defecto del contenedor de producción, no de lo que resuelve el runner: el colector consulta GET /api/installed-packages (endpoint interno de Django, Bearer INTERNAL_TOOLS_TOKEN, mismo patrón que /openapi-export) y guarda en installed_source de dónde vino cada valor (prod / runner / lockfile). Falla suave: si PROD no contesta, la pasada sigue con el respaldo del runner. El paso «Probe PROD installed packages» del workflow (continue-on-error) deja el código HTTP en el log.

Datos de entrada / verificación en local

Dry-run real (28-05-2026):

112 dependencias · major=22 · minor=25 · patch=17 · unknown=0 · uptodate=48

Cronograma

Semanal: lunes 06:30 UTC (cron)
Al toque: push a main + manifiesto
Manual: GitHub Actions UI

Reglas aplicadas

Regla 15 (HTTP 200 ≠ éxito): validación del body en respuesta de /api/tools/deps
Regla 17 (cloud, no PC): todo ejecutable en GitHub Actions, nunca requiere acción manual en PC

Fase 2

Eje CVE: cruce con OSV (Open Source Vulnerabilities) HECHO 11-07-2026 — ver [[feature—harness—osv-security-deps-freshness]].
Motor fiable: horquillas resueltas a la versión que de verdad se instala, «instalada» desde PROD, aviso de horquillas sin techo y si el arreglo cabe en el pin HECHO 28-08-2026 (task #275, scripts/deps_specs.py + scripts/deps_sources.py, 38 casos en tests/scripts/test_deps_freshness.py).
Botón Context7: “ver cambios” por fila → guía de migración IA-asistida (pendiente)
Integración Pulse/alertas: señal crítica si major ≥ 5 paquetes sin actualizar >6 meses (pendiente)

Complementaridad con otras herramientas

Dependabot: no instalado en este proyecto
Renovate: no instalado
agent-pip-audit.yml: eje ortogonal — CVEs vs frescura. Ambos necesarios.

Véase también

[[entity—ci—service—deps-freshness-collector]]
[[entity—ci—workflow—deps-freshness]]
[[concept—infra—dependency-management]]
[[concept—saas—observability]]
[[concept—ci—automation]]