[Proyecto I]

[itadrias]

Nombre: Adrian Pacheco Rubio
Grupo: C122
Repositorio: https://github.com/itadrias/SuperHero_Manager

Descripción

Proyecto de gestión de eventos personalizados y predeterminados con temática de superhéroes.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/itadrias/SuperHero_Manager

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

✅ report.md — 2,500 palabras (mínimo: 2,000).

3. Proyecto Python

⚠️ Sin pyproject.toml.
✅ requirements.txt encontrado.
Dependencias declaradas: kivy, kivy-deps.angle, kivy-deps.glew, kivy-deps.sdl2, pillow

Archivos Python (14, 2,062 líneas en total):

• main.py
• widgets/__init__.py
• widgets/config.py
• widgets/chart.py
• widgets/sound_manager.py
• widgets/utils.py
• widgets/panel.py
• widgets/add.py
• widgets/checker.py
• widgets/events_view.py
• widgets/hero_selector.py
• widgets/buttons.py
• widgets/date_selector.py
• widgets/restrictions.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

Kivy Usage: main.py [KIVY OPTION...] [-- PROGRAM OPTIONS]::

            Options placed after a '-- ' separator, will not be touched by kivy,
            and instead passed to your program.

            Set KIVY_NO_ARGS=1 in your environment or before you import Kivy to
            disable Kivy's argument parser.

        -h, --help
            Prints this help message.
        -d, --debug

Resumen

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

6/6 verificaciones pasadas.

---

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

[apiad]

🔍 Revisión de Código — Claude Code

Repositorio: https://github.com/itadrias/SuperHero_Manager

Qué hace tu proyecto

Construiste un planificador de misiones para una agencia de superhéroes: eliges una misión (Patrullar, Luchar o una personalizada), armas un equipo de héroes e ítems viendo cómo sus atributos suman en un gráfico de radar en tiempo real, y el sistema valida las reglas del equipo y la agenda antes de guardar el evento. Lo más valioso es que no es "una GUI y ya": tienes una capa de lógica de negocio de verdad (restricciones, solapamiento de fechas, disponibilidad de recursos) separada de la interfaz, y datos externalizados en JSON. Para primer año, es un proyecto muy por encima de lo habitual.

Ejecución

Lo corrí de verdad, en tres capas. Primero probé tu lógica de negocio aislada (restrictions.py, checker.py) importándola directamente — justamente porque la separaste bien de Kivy, pude hacerlo. Luego arranqué la GUI: con un driver de video "dummy" falló por falta de OpenGL (eso es del entorno, no de tu código), así que la levanté bajo un framebuffer virtual (Xvfb) y ahí arrancó limpio, llegó al bucle principal y corrió sin ningún error. Hasta capturé un screenshot del menú principal renderizado. py_compile de los 14 módulos: todos compilan.

Lo que está bien

• Separación real lógica/interfaz. restrictions.py, checker.py y utils.py no dependen de Kivy. Eso me dejó probarlos aislados y confirmar que funcionan — es exactamente la buena práctica que se busca.
• Lógica correcta, verificada flujo a flujo. Probé: sin héroe → rechaza; misión que exige a Juggernaut sin él → rechaza con el mensaje correcto; un héroe que requiere su ítem → lo exige; equipo válido → acepta. En agenda: detecta el solapamiento de un héroe ocupado, devuelve None cuando no hay choque, y next_available calculó el hueco justo tras la liberación. También el conteo de ítems limitados (capacidad 1 choca, capacidad 10 no) y el borrado con re-indexado consistente. Todo pasó.
• Datos fuera del código. Héroes, ítems, misiones y reglas viven en JSON, no hardcodeados. Añadir una restricción es editar un archivo, no tocar Python.
• Cuidado en los detalles: docstrings en todo, animaciones, gráfico de radar dibujado con trigonometría propia, bloqueos de entrada durante animaciones. Se nota el esfuerzo.

Qué mejorar

• Estado global mutable. Las variables sum y used en hero_selector.py (y record en buttons.py) son globales a nivel de módulo que varios widgets comparten y mutan. Funciona, pero es frágil: tienes que acordarte de resetearlas a mano (clean=True). Lo idiomático sería guardar ese estado como atributos de un objeto de sesión y pasarlo, en vez de un global. Por qué importa: los globals mutables son la fuente número uno de bugs difíciles de rastrear cuando el programa crece.
• Endurece las funciones de borde. delete_event(id) revienta con KeyError si le pasas una key que no existe (checker.py), y SoundManager.play_sound haría AttributeError si un archivo de sonido faltara (sound_manager.py, porque SoundLoader.load puede devolver None). Hoy no se disparan porque los datos siempre vienen bien, pero un if id not in events: return y un if self.sound is None: return los blindan.
• Evita sum como nombre de variable. sum = [0,0,0,0,0,0] (hero_selector.py:16) tapa el sum() de Python. Renómbrala a algo como attr_totals — evitas confusión y un builtin oculto.
• Limpieza menor. Tienes un método remove definido dos veces en selection_matrix (la segunda tapa a la primera), un diccionario cant en checker.py que nunca se usa, y muchos from … import *. Importar explícito (from .utils import read_json, write_json) hace más fácil ver de dónde viene cada nombre.

Sobre el informe

El informe está muy bien: extenso, claro, y coincide con lo que el código hace de verdad — describe correctamente el solapamiento de agenda, next_available recursiva, el motor required/forbidden y el radar. Bien por entender tu propia arquitectura y explicarla. Un solo detalle: llamas "encriptados" / "Base de Datos Encriptada" a los JSON (secciones de Arquitectura). No están encriptados — son texto plano perfectamente legible. Es lenguaje que suena bien pero no describe lo real; con "externalizados en JSON" el mérito (que es genuino) queda igual de claro sin la imprecisión.

Muy buen trabajo, Adrian. La decisión de separar la lógica de la interfaz y sacar los datos a JSON es exactamente el tipo de pensamiento arquitectónico que vale la pena cultivar — te dio un código que se puede probar de verdad, y se nota. Sigue por ahí.