[Proyecto I] #318

Activity

1. github-actions commented on Jun 26, 2026

   

   github-actionsBot

   on Jun 26, 2026 – with GitHub Actions

   More actions

   Verificación Automática — Proyecto I 🤖

   Repositorio analizado: https://github.com/cala49/Ciutat-Esportiva-Joan-Gamper

   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.
   ⚠️ Sin requirements.txt.

   Archivos Python (7, 964 líneas en total):

   • models.py
   • event.py
   • calendary.py
   • main.py
   • persistence.py
   • contranins.py
   • cli.py

   4. Punto de Entrada

   ✅ Punto de entrada detectado: main.py

   5. Ejecución

   ✅ El proyecto se ejecuta.

   ============================================================
   🎯 PLANIFICADOR INTELIGENTE DEL FÚTBOL CLUB BARCELONA
   ============================================================
   Sistema de gestión de recursos y eventos con restricciones
   Desarrollado por: Carlos Cala
   ============================================================
   🔃 Cargando datos del sistema...
   ✅ Datos cargados: 7 recursos, 1 eventos
   
   ==
   

   Resumen

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

   4/6 verificaciones pasadas.

   ---

   Verificación automática — los resultados son orientativos. El profesor revisará en detalle.
2. apiad commented on Jul 15, 2026

   

   apiad

   on Jul 15, 2026

   Member

   More actions

   🔍 Revisión de Código — Claude Code

   Repositorio: https://github.com/cala49/Ciutat-Esportiva-Joan-Gamper

   Qué hace tu proyecto

   Construiste un gestor de eventos para la Ciutat Esportiva Joan Gamper: un menú de consola que administra partidos y entrenamientos con su equipamiento (balones, kits, tarjetas, suplementos), detecta conflictos cuando dos eventos se solapan y comparten un recurso, busca huecos libres en el calendario y aplica restricciones entre recursos. Lo más valioso es la arquitectura: tienes una jerarquía de clases con herencia (Resource → Ball, Kit, Cards, Supplements), separaste la lógica de la interfaz, y la persistencia guarda solo los IDs de los recursos y los reconstruye al cargar. Eso es diseño maduro para primer año.

   Ejecución

   Lo corrí de verdad. Sin dependencias externas (solo biblioteca estándar), arranca directo. Probé: listar recursos y eventos (bien), agregar un evento válido en el futuro (bien), entradas basura como fecha-basura / 25:99 / abc (responde "Formato inválido" sin reventar), fecha en el pasado (la rechaza), buscar hueco (bien), restricción de inclusión (funciona: al usar Amarillas sin Rojas la bloquea), y guardar→reiniciar→cargar (los eventos persisten). Los 7 módulos compilan.

   Pero encontré un crash importante: en cuanto un evento nuevo choca de verdad con otro (se solapan en tiempo y comparten un recurso), la app muere con ❌ Error inesperado: 'Event' object has no attribute 'nombre' y se cierra. Lo reproduje tanto llamando a la lógica directamente como por el menú.

   Lo que está bien

   • Modularización clara: models, event, calendary, contranins, persistence, cli, cada uno con su responsabilidad.
   • POO bien aplicada: herencia con super(), to_dict/from_dict, @classmethod, polimorfismo en las restricciones.
   • Persistencia por referencia: guardas IDs y reconstruyes las subclases correctas por el campo subtype. Muy buen patrón, y el roundtrip guardar/cargar funciona.
   • Validación de entradas robusta: formatos malos, fechas pasadas y opciones inválidas no rompen el programa.

   Qué mejorar

   • El bug del conflicto (arréglalo primero). En calendary.py:57 escribiste current_event.nombre, pero el atributo se llama name (mira event.py:6). Cámbialo a current_event.name y la detección de conflictos —que es el corazón de tu proyecto— dejará de crashear. Este mismo error también puede tumbar la opción "Buscar hueco" cuando un intervalo candidato choca con un evento existente, porque esa función usa veri_conflict por dentro.
   • RestriccionExclusion hace lo contrario de lo que dice tu README. Tu README promete "no se pueden usar 2 Balones al mismo tiempo", pero el código (contranins.py:42-61) en realidad exige que ambos recursos estén juntos y falla si usas solo uno. Lo verifiqué: con los dos balones da "cumplida", con uno solo da error. Para una exclusión real, la condición debería fallar cuando ambos están presentes: if usa_recurso1 and usa_recurso2: return False, "…no pueden usarse juntos". Aprovecha y corrige el mensaje de éxito, que dice "Restricción de inclusión cumplida" también en la clase de exclusión.
   • Las restricciones no se guardan. GestorRestricciones vive solo en memoria; al cerrar la app se pierden. Si quieres que persistan, añádelas al JSON como haces con recursos y eventos.
   • Detalle de robustez: el except Exception de main() te ocultó el bug del nombre bajo un "Error inesperado" genérico. Mientras desarrollas, deja que el Traceback se vea; te habría señalado la línea exacta al instante.

   Sobre el informe

   Tu README describe bien el dominio y las restricciones de inclusión (que sí funcionan), y el tono es honesto. Dos matices: (1) lo de la exclusión de balones no coincide con lo que hace el código —revisa esa restricción—; y (2) llamar "interfaz visual" al menú de texto lo sobreestima un poco, aunque en la práctica el menú se ve limpio y se usa cómodo.

   Buen trabajo de diseño, Carlos. Tienes una base excelente; con esos dos arreglos (una palabra el primero, invertir una condición el segundo) el proyecto queda redondo. Consejo que te va a servir siempre: prueba también los caminos que deberían fallar —un conflicto real, una exclusión con ambos recursos—, porque ahí es donde estaban escondidos estos dos bugs.