starledger
StarLedger es un dashboard estático auto-almacenado para repositorios GitHub 'starread', con exportador determinista, notificador Telegram y clasificación AI opcional. Arquitectura sin backend ni custodia centralizada.
Ficha actualizada 23 sept 2026, 20:01 · upstream 23 sept 2026, 19:21 · release sin release detectada
Qué es starledger
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
StarLedger es una herramienta de código abierto diseñada para gestionar y visualizar los repositorios 'starread' de GitHub de forma auto-almacenada. El sistema está construido con Next.js, React y Node.js, sin backend ni custodia de claves centralizada. La arquitectura estática reduce la superficie de ataque y los costes de infraestructura.
El proyecto se desarrolla en fases: P0 (exportador determinista), P1 (dashboard estático), P2 (notificador Telegram), P3 (clasificación AI opcional), P4 (plantilla reutilizable) y P5 (Discovery Inbox manual). Cada fase tiene especificaciones técnicas documentadas y validaciones de puerta (gates) para asegurar calidad antes de publicar.
El exportador sincroniza la lista de repositorios a un archivo JSON canónico, con fallback REST/GraphQL que garantiza integridad de datos incluso bajo límites de API. El notificador envía actualizaciones a Telegram desde fuentes como YouTube o awesome-stars, con estado durable en rama dedicada y lógica de reintentos para entregas confiables.
- Visualizar repositorios 'starread' con filtros, ordenación y búsqueda en un dashboard estático
- Sincronizar la lista de repositorios a un archivo JSON canónico mediante exportador determinista
- Enviar notificaciones a Telegram sobre actualizaciones desde fuentes como YouTube o awesome-stars
- Categorizar, etiquetar y resumir repositorios con clasificación AI opcional y búsqueda semántica
- Crear despliegues personales sin custodia de claves centralizada usando la plantilla P4
- Introducir candidatos manualmente para revisión en el Discovery Inbox y deduplicarlos
- Arquitectura estática sin backend, reduciendo superficie de ataque y costes de infraestructura
- Exportador con fallback REST/GraphQL que garantiza integridad de datos incluso bajo límites de API
- Notificador con estado durable en rama dedicada y lógica de reintentos para entregas confiables
- Plantilla P4 generada determinísticamente, permitiendo replicación limpia sin compartir credenciales
- Validaciones de puerta (gates) para cada fase (P0-P5), asegurando calidad antes de publicar
- Diseño fail-closed que evita corrupción de datos al fallar en enumeración o autenticación
- Dependencia de credenciales PAT almacenadas por el usuario, sin custodia centralizada
- AI opcional (P3) requiere ejecutor externo, no incluido en el repositorio principal
- Discovery Inbox es manual, sin automatización completa de selección de candidatos
- No hay Dockerfile ni compose, requiriendo despliegue nativo o contenedores manuales
- Exportador puede fallar (exit 20) si la enumeración REST está incompleta por límites de API
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Frontend: Vercel/Netlify con build pnpm build, sirviendo dist/. Exporter/Notifier: Ejecución local o en servidor Node.js con NODE_ENV=production. Variables de entorno: STAR_SYNC_TOKEN (PAT read-only), TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID. Git: Usar rama starledger-state para commits del estado del notificador. Validación: Ejecutar pnpm release-gate antes de cada despliegue en producción.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
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.