[Proyecto I]

[KyleFullbuster]

Nombre: Alejandro Miguel González Velez
Grupo: C-122
Repositorio: https://github.com/KyleFullbuster/Honor-of-Kings-Esports-Scheduler

Descripción

Sistema de gestión integral para equipos competitivos de Honor of Kings (王者荣耀). Gestiona scrims, prácticas, análisis de draft y asignación de recursos profesionales.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/KyleFullbuster/Honor-of-Kings-Esports-Scheduler

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

❌ No se encontró report.md en el repositorio.

3. Proyecto Python

⚠️ Sin pyproject.toml.
✅ requirements.txt encontrado.
Dependencias declaradas: altair, attrs, blinker, cachetools, certifi, charset-normalizer, click, gitdb, GitPython, idna

Archivos Python (12, 3,121 líneas en total):

• Proyecto/styles.py
• Proyecto/main.py
• Proyecto/scheduler.py
• Proyecto/utils/helpers.py
• Proyecto/utils/__init__ .py
• Proyecto/tabs/__init__.py
• Proyecto/tabs/tab3_search.py
• Proyecto/tabs/tab5_details.py
• Proyecto/tabs/tab2_add.py
• Proyecto/tabs/tab1_events.py
• Proyecto/tabs/tab4_delete.py
• Proyecto/tabs/tab6_system.py

4. Punto de Entrada

⚠️ No se encontró un punto de entrada claro (main.py, app.py, etc.).

5. Ejecución

⚠️ Sin punto de entrada identificado — no se intentó ejecutar.

Resumen

• ✅ Repositorio accesible
• ❌ report.md con ≥2000 palabras
• ✅ Archivos Python
• ✅ Configuración de dependencias
• ❌ Punto de entrada
• ❌ Ejecución

3/6 verificaciones pasadas.

---

Verificación automática — los resultados son orientativos. El profesor revisará en detalle.

[KyleFullbuster]

Elegí Honor of Kings porque es el MOBA móvil más jugado del mundo, con una escena eSports vibrante (torneos con premios millonarios). Me permite modelar restricciones reales como compatibilidad de héroes con jugadores y exclusiones por roles, inspirado en drafts competitivos. Es un dominio dinámico que combina estrategia, tiempo y recursos, ideal para el proyecto.

[apiad]

🔍 Revisión de Código — Claude Code

Repositorio: https://github.com/KyleFullbuster/Honor-of-Kings-Esports-Scheduler

Qué hace tu proyecto

Armaste un planificador de eventos para un equipo profesional de Honor of Kings: creas scrims, prácticas, análisis y torneos, cada uno con jugadores, héroes e instalaciones, y el sistema valida un conjunto de restricciones reales (co-requisitos como "Lam requiere Jugador2", exclusiones como "Lam ≠ Li Bai", una sola sala por evento, reglas de posición en eventos importantes), detecta conflictos de horario y busca huecos libres. Todo esto vive en una interfaz Streamlit de seis pestañas, bien separada del motor de lógica. Es un proyecto ambicioso y, lo más importante, funciona.

Ejecución

No es una app de consola, así que la ejecuté como lo que es. Primero corrí el motor (scheduler.py) directamente con datos concretos, y luego arranqué la GUI real en modo headless: Streamlit sirvió correctamente (HTTP 200) sin ningún error. Los 12 módulos compilan (py_compile limpio).

Probé el camino feliz y ~15 flujos inválidos. El alta de un evento válido funcionó y persistió en data.json (la lista pasó de 4 a 5 eventos). Y cada entrada mala fue rechazada con un mensaje claro: fecha basura, fecha en el pasado, sin jugador, co-requisito incumplido, exclusión mutua, dos salas, recurso inexistente, duración muy corta, nombre duplicado y conflicto de horario. En ninguno reventó con un Traceback — eso es exactamente lo que uno quiere ver.

Lo que está bien

• Separaste bien la lógica de la interfaz. scheduler.py es el motor, main.py + tabs/*.py son la GUI, styles.py el CSS, los datos en JSON. Gracias a eso pude probar el motor sin tocar la interfaz. Muy buen diseño para primer año.
• El sistema de restricciones es real y lo verifiqué funcionando: co-requisitos, exclusiones mutuas, una sola sala por evento y la regla de posición para scrims/torneos (un Jugador Mid sin héroe de Mid es rechazado; con Daji, un mid, pasa).
• Manejo de errores sólido: todo sale como ValueError con mensaje legible, usas logging en vez de print sueltos, y tienes type hints y docstrings. Detalle fino: si heroes.json falta, hay datos por defecto de respaldo.

Qué mejorar

• Renombra utils/__init__ .py a __init__.py (tiene un espacio antes de .py). Funciona solo por casualidad — import utils deja utils.__file__ en None — y en otra máquina podría romperse. Es un cambio de un segundo.
• Tienes dos validadores en paralelo y pueden contradecirse. El de verdad es scheduler.check_constraints, pero en utils/helpers.py hay otro (validate_event_resources) con reglas distintas: por ejemplo, ahí un scrim pide mínimo 5 jugadores, pero el motor solo pide 1. Si algún día cambias una regla en un lado y no en el otro, la GUI y el motor dirán cosas diferentes. Deja una sola fuente de verdad (el motor) y que la GUI la llame.
• Evita deducir el rol/posición partiendo el texto del nombre (heroe.split("(")[1]...). Si algún día cambias cómo se escribe un héroe, se rompen las reglas de posición. Guardar cada recurso como un pequeño diccionario ({"nombre": ..., "rol": ..., "posicion": ...}) sería mucho más robusto.

Sobre el informe

No incluiste el report.md que pide el proyecto (el README.md de 594 palabras lo suple en parte, con capturas). Lo bueno: el README es honesto — las restricciones que describe coinciden con las del código y todo lo que afirma sobre validación de conflictos lo comprobé corriéndolo. Un detalle a alinear: dices "~30 héroes" pero heroes.json trae 111 (más de lo que anuncias). Para la próxima, entrega el report.md formal explicando decisiones de diseño; tu proyecto da de sobra para llenarlo. ¡Buen trabajo!