[Proyecto I] Organizador de Eventos

[ianpuiglvlle]

Nombre: Ian Puig Levalle
Grupo: C-121
Repositorio: https://github.com/ianpuiglvlle/proyecto-ahora-si

Descripción

Organizador de Eventos sobre un estadio de futbol que cuenta con 2 campos (campo principal 1 y campo principal 2) donde se pueden reservar entrenamientos, partidos y torneos, usando streamlit y python.

[github-actions]

Verificación Automática — Proyecto I 🤖

❌ No se encontró una URL de repositorio de GitHub en el Issue.

Por favor asegúrate de incluir el enlace completo en el campo Repositorio, por ejemplo:
https://github.com/tu-usuario/tu-proyecto

[ianpuiglvlle]

/revisar

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/ianpuiglvlle/proyecto-ahora-si

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 (10, 1,236 líneas en total):

• interfaz_recursos.py
• interfaz.py
• main.py
• utils/helpers.py
• models/calendario.py
• models/restriccion.py
• models/recursos.py
• models/evento.py
• servicios/gestor_eventos.py
• servicios/gestor_recursos.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

Traceback (most recent call last):
  File "/tmp/tmp077rnql7/repo/main.py", line 1, in <module>
    import streamlit as st
ModuleNotFoundError: No module named 'streamlit'

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.

[apiad]

🔍 Revisión de Código — Claude Code

Repositorio: https://github.com/ianpuiglvlle/proyecto-ahora-si

Qué hace tu proyecto

Construiste un organizador de reservas para un estadio con dos campos principales, hecho como app web en Streamlit. Permite crear partidos, entrenamientos y torneos; elegir campo, hora y recursos (árbitro, marcador, equipo médico…); y detecta automáticamente conflictos de horario, capacidad de recursos, co-requisitos (Campo Principal exige árbitro y marcador) y exclusiones (Calentamiento no va con árbitro). Está muy bien organizado en capas: models/, servicios/, interfaz/ y utils/.

Ejecución

Lo corrí de verdad. Creé el entorno con uv venv --python 3.12, instalé Streamlit y pandas, y todos los módulos pasan py_compile. Ejercí la lógica de negocio con datos reales (instanciando Evento, Calendario, GestorRecursos, simulando st.session_state) y recorrí altas, conflictos, restricciones, persistencia y borrado. También arranqué la GUI en modo headless: el servidor levantó limpio, respondió HTTP 200 y el health-check dio ok. El error del bot automático (ModuleNotFoundError: streamlit) fue solo porque no tenía la librería instalada — no es un fallo de tu código.

Lo que está bien

• Arquitectura por capas real. La separación modelos / servicios / interfaz / utils es coherente y poco común en primer año. Muy buen trabajo.
• Orientación a objetos genuina: EventoConRecursos hereda de Evento con super(), y las restricciones usan polimorfismo (RestriccionCoRequisito y RestriccionExclusion comparten validar()).
• Verifiqué que las reglas funcionan: torneo en día laborable se rechaza; título vacío se rechaza; CAMPO_PRINCIPAL_1 sin árbitro/marcador da error de co-requisito; Calentamiento+Árbitro da error de exclusión; dos eventos en el mismo campo y bloque chocan, pero en campos distintos no; y cuando EQUIPO_MEDICO (capacidad 1) está ocupado, el segundo evento se rechaza con el mensaje de capacidad. Todo correcto.
• Persistencia sólida: el ciclo alta → guardar en eventos.json → contar → eliminar → reescribir JSON funciona de punta a punta.
• README excelente y honesto: describe archivo por archivo, el flujo de alta paso a paso y hasta una sección de "problemas conocidos". De los mejores informes a este nivel.

Qué mejorar

• Bug de desincronización (el más importante). En models/calendario.py:55-66, agregar_evento hace self.eventos.append(evento) antes de intentar guardar en JSON. Si el guardado se rechaza (por ejemplo, un evento duplicado exacto), la función devuelve error pero el evento ya quedó en memoria: lo reproduje y terminé con 2 eventos en la lista y solo 1 en el JSON. Solución: guarda primero y haz el append solo si el guardado salió bien.
• recursos.json está muerto. Ese archivo existe pero ningún módulo lo lee — los recursos están escritos a mano en gestor_recursos.py:16. Peor: ahí EQUIPO_MEDICO tiene capacidad 1, pero en recursos.json y en tu README dice 2. Tres fuentes que se contradicen. Decide una cosa: o lees recursos.json como fuente de verdad, o lo borras y dejas solo el código.
• El título del evento se usa como identificador de recurso (gestor_recursos.py:136, dentro de un set). Si dos eventos distintos tienen el mismo título en el mismo bloque, se contarían como uno solo. Considera un ID único por evento en vez del título.
• except: desnudos en evento.py:18,24 y helpers.py:22. Captura la excepción concreta (except (ValueError, IndexError):) para no esconder errores que no esperabas.
• Métodos y funciones sin usar: buscar_hueco_disponible, agregar_recursos_a_interfaz y validar_hora_torneo no se llaman desde ningún flujo activo. Bórralos o conéctalos.

Sobre el informe

No hay report.md (el requisito pide ese nombre y extensión); tienes un README.txt. El contenido es muy bueno y sincero — coincide con el código en lo esencial y no exagera con "demuestra"/"prueba". Dos discrepancias a corregir: dice que EQUIPO_MEDICO tiene 2 unidades (el código usa 1) y presenta recursos.json como si la app lo leyera (no lo hace). Renómbralo a report.md y ajusta esos dos puntos.

Es un proyecto ambicioso y bien construido. Con el arreglo del orden guardar/agregar y decidir qué haces con recursos.json queda redondo. ¡Buen trabajo!