Ctrl K
ComunidadGuías…
GITHUB · ANALIZADO

millennium

Millennium es un tracker personal de colección Yu-Gi-Oh que trata las cartas como cartera de inversión: coste por lote, precios con scoring de confianza y valuación diaria. Arquitectura Django + Next.js auto-alojada.

Ficha actualizada 22 sept 2026, 17:32 · upstream 22 sept 2026, 16:24 · release v1.0.0

Ver códigoProblemas y ayudaRepositorio ↗Sitio oficial
00

Qué es millennium

Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.

Millennium es una herramienta para gestionar colecciones de cartas Yu-Gi-Oh con enfoque de análisis de inversión. Importa exportaciones CSV de Dragon Shield, estadiando cada fila antes de asociarla a una impresión específica (código de set, rareza, edición). Cada adquisición se registra como un lote con su propio coste base, permitiendo que cantidad y coste se sumen desde el libro mayor.

El sistema ingiere precios diarios desde TCGCSV (metadatos de YGOPRODeck) en un historial append-only con puntuación de confianza por punto. Valora cada cartera diariamente aplicando factores de condición y haircut de liquidación, registrando conteos de cobertura parcial para evitar que el total parezca completo cuando algunas cartas no están precificadas.

La arquitectura es un monolito modular Django (apps: core, cards, pricing, portfolio, collection, imports, valuation) que sirve una API JSON consumida por Next.js a través de proxy same-origin. PostgreSQL almacena jerarquía de tres niveles y snapshots append-only. En producción se despliega en VPS único detrás de Caddy con TLS, usando systemd timers para jobs programados.

CASOS DE USO
  • Rastrear adquisición de cartas con coste base por lote para análisis de rentabilidad
  • Obtener valuación diaria histórica de la colección con factores de condición aplicados
  • Importar colecciones desde exportaciones CSV de Dragon Shield con validación de impresión
  • Monitorear movimientos de precio y recibir alertas de porcentaje de cambio
  • Organizar cartas en grupos por deck para análisis de construcción competitiva
PUNTOS DESTACADOS
  • Arquitectura modular Django con API OpenAPI tipada y cliente TypeScript generado
  • Sistema de precios con scoring de confianza desde múltiples fuentes externas
  • Testing completo: pytest backend, Vitest frontend, Playwright end-to-end
  • CI/CD con GitHub Actions incluyendo CodeQL, gitleaks y pruebas E2E
  • Historial append-only de precios y valuaciones para auditoría temporal
  • Despliegue self-hosted en VPS único con Caddy como edge TLS
PRECAUCIONES
  • Precios no en tiempo real: actualización programada diaria desde fuentes externas
  • Redis solo en desarrollo; producción usa cache de base de datos de Django
  • Sin Dockerfile ni Compose para producción (usa systemd timers)
  • Requiere VPS propio con Caddy para terminación TLS y despliegue completo
01

Perfil de infraestructura

Estimación inicial derivada del repositorio y de los servicios detectados.

CPU2 vCPUrecomendación inicial
MEMORIA2 GBRAM estimada
DISCO30 GBalmacenamiento base
COMPLEJIDADmediumnivel de operación
02

Despliegue detectado

Qué señales reales de instalación hemos encontrado.

Despliegue manual

Despliegue en VPS único detrás de Caddy que termina TLS. Jobs programados vía systemd timers en producción (no Celery). Pull-based continuous deployment: merge a main dentro de minutos. Prerrequisitos: PostgreSQL 16, Node.js para frontend, uv para Python. Comandos Makefile: make dev, make migrate-up, make test, make e2e.

—Dockerfile
—Compose
—One-click
03

Stack y dependencias

Componentes inferidos a partir de manifests, configuración y documentación.

FRAMEWORKS
Next.jsReactNode.jsDjangoPython
SERVICIOS
PostgreSQLRedis
BASES DE DATOS
PostgreSQLRedis
PUERTOS
3000800054326379
05

Puede sustituir a

Relaciones detectadas por el análisis del repositorio y su categoría.

06

Experiencia real de la comunidad

Ayuda a contrastar la estimación automática con instalaciones reales.

Todavía no hay datos comunitarios para este proyecto.