[Proyecto I]

[RMolanod7]

Nombre: Ricardo Miguel Molano Dominguez
Grupo: C121
Repositorio: https://github.com/RMolanod7/OlymPlaner

Descripción

OlymPlaner es una aplicación diseñada para simplificar la planificación de una Olimpiada de Centroamérica y el Caribe mediante una interfaz intuitiva y un conjunto robusto de validaciones automáticas. El sistema permite gestionar recursos, programar actividades, evitar conflictos y generar un calendario final coherente.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/RMolanod7/OlymPlaner

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

⚠️ Report.md encontrado pero con solo 1,699 palabras (mínimo: 2,000).

3. Proyecto Python

⚠️ Sin pyproject.toml.
⚠️ Sin requirements.txt.

Archivos Python (6, 1,084 líneas en total):

• Events.py
• Units.py
• Persistence.py
• Main.py
• Inventory.py
• Paises.py

4. Punto de Entrada

✅ Punto de entrada detectado: Events.py

5. Ejecución

✅ El proyecto se ejecuta.

(sin salida)

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/RMolanod7/OlymPlaner

Qué hace tu proyecto

OlymPlaner es una aplicación web hecha con Streamlit para planificar una Olimpiada de Centroamérica y el Caribe. Permite elegir el país sede, fijar la fecha y la duración (5–30 días), ajustar un inventario de recursos por categorías (personal, salones, materiales, alimentación y otros) y, a partir de ahí, construir el calendario: agregar eventos —incluso de forma recurrente—, listarlos, eliminarlos, ver detalles por evento o por recurso, buscar el siguiente hueco de horario libre y, finalmente, mostrar un calendario final agrupado por días con estilo visual. Todo el flujo está gobernado por un sistema amplio de restricciones (colisiones de horario, eventos únicos, tope de exámenes, recursos obligatorios y absurdos, co-requisitos y exclusiones de seguridad). Cumple bien lo que describe tu issue.

Ejecución

Monté un entorno aislado con uv, instalé Streamlit y recorrí la app con su framework de pruebas. En un clon limpio la app no arranca: lanza un error porque el fichero de datos del repositorio se llama data_olymplanner.json pero el código busca Data_Olymplanner.json; al no encontrarlo, no se inicializa el país y peta. Corrigiendo ese nombre, toda la aplicación funciona: seleccioné país, validé la duración, confirmé recursos, avancé, agregué un evento con éxito y probé listar, detalles, buscar hueco y calendario final, todo sin errores.

Lo que está bien

• Modularización real y POO bien usada. Dividiste el proyecto en seis archivos con responsabilidades claras (eventos, recursos, inventario, países, persistencia, interfaz) y clases donde el dominio lo pide. Es una organización superior a la media de primer año.
• Motor de restricciones ambicioso y coherente. Colisiones de horario, unicidad de inauguración/despedida, límite de exámenes, exclusiones de seguridad y co-requisitos entre recursos: mucha lógica, y bien conectada con lo que documentas.
• Persistencia en JSON y recursión aplicada a los eventos recurrentes, con deepcopy para no mutar el evento base. Detalles que muestran cuidado.
• Informe excelente y honesto, que describe lo que el código realmente hace sin inventar funcionalidades.

Qué mejorar

• El bug de arranque es lo más urgente. Renombra data_olymplanner.json a Data_Olymplanner.json (o cambia la cadena en el módulo de persistencia). Mejor aún: define el nombre del fichero en una sola constante para no repetirlo. Este fallo debió salir probando desde cero: acostúmbrate a clonar tu propio repo en una carpeta limpia y correrlo antes de entregar.
• Reduce la duplicación. Los bloques de Desayuno/Almuerzo/Cena son idénticos; únelos con if nombre in ("Desayuno","Almuerzo","Cena"). La cadena de comparaciones de técnicos también se puede resolver con un bucle.
• Divide la interfaz. Main.py es muy largo; extraer cada opción del menú a su propia función lo haría mucho más legible.
• Detalle visual: las imágenes de Panamá y República Dominicana están intercambiadas; revísalas.

Sobre el informe

El informe coincide con el código y no sobreestima nada; de hecho, describe con precisión el diseño, el uso y las dificultades. Lo único que no refleja es el fallo de arranque, que quedó sin detectar.

Valoración general

Es un trabajo sólido y por encima del nivel esperado en primer año: buena arquitectura, un dominio bien modelado y un informe cuidado. Su principal fortaleza es la organización del código; su principal área de mejora es la robustez, porque un descuido de una sola línea impide que la aplicación arranque en un clon limpio. Corrígelo y tendrás un proyecto muy completo.

---

Revisión automática de código con Claude Code — orientativa. La nota final la pone el profesor.

📄 Reporte detallado (código, archivo y línea): ver análisis completo