[Proyecto I]Planificador de eventos

[marlamora234564]

Nombre: Marla Cejas Mora
Grupo: C-122
Repositorio:https://github.com/marlamora234564/planificador-de-eventos

Descripción

Este proyecto implementa un planificador de eventos diseñado para la gestión de recursos y restricciones en producciones audiovisuales

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/marlamora234564/planificador-de-eventos

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 (5, 893 líneas en total):

• restricciones.py
• recursos.py
• main.py
• persistencia.py
• eventos.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

--- Planificador de Eventos ---
1. Agregar evento
2. Ver eventos
3. Eliminar evento
4. Gestionar recursos
5. Buscar hueco (horario disponible)
6. Salir
Seleccione una opción: Opción inválida. Por favor, intente de nuevo.

--- Planificador de Eventos ---
1. Agregar evento
2. Ver eventos
3. Eliminar evento
4. Gestionar recursos
5. Buscar hueco (horario disponible)
6. Salir
Seleccione una opción: Tr

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.

[marlamora234564]

Ya corregí el nombre del reporte a report.md y agregue el archivo requirements.txt

[apiad]

🔍 Revisión de Código — Claude Code

Repositorio: https://github.com/marlamora234564/planificador-de-eventos

Qué hace tu proyecto

Construiste un planificador de eventos para producción audiovisual que gestiona 20 recursos (humanos, técnicos y físicos) con un sistema real de restricciones: co-requisitos (una cámara requiere camarógrafo), exclusiones mutuas (luces vs. drones) y conflictos de calendario (un recurso no puede estar en dos eventos que se solapen). Lo más ambicioso es la opción "Buscar hueco": dado un conjunto de recursos y una duración, encuentra automáticamente el primer intervalo libre respetando todas esas reglas. Es un proyecto con verdadera chicha técnica.

Ejecución

Lo corrí de verdad en Python 3.12 recorriendo todo el menú con entradas simuladas, y además probé la lógica de negocio directamente con datos construidos a mano. Todos los módulos compilan sin errores y no hubo un solo Traceback en ninguna prueba — ni con entradas válidas ni con basura. requirements.txt está vacío, lo cual es correcto: usas solo biblioteca estándar.

Probé: alta válida (Director+Camarógrafo+Actor), violación de co-requisitos, exclusión mutua (Micrófonos+Grabadora), fechas mal formadas, fecha de fin anterior a la de inicio, eliminar con índice inválido, JSON corrupto, y el flujo completo de "buscar hueco" creando el evento. Todo se comportó como esperaba.

Lo que está bien

• Arquitectura modular excelente para primer año. Separaste el proyecto en cinco archivos con responsabilidades claras: menú, eventos, recursos, restricciones y persistencia. Eso es difícil de lograr y lo hiciste bien.
• Las validaciones son funciones puras (reciben datos, devuelven (es_valido, conflictos)). Pude invocarlas aisladas y funcionan perfecto — es un patrón limpio y comprobable.
• La lógica de solapamiento de fechas es correcta, incluso en el caso de frontera (un evento que empieza justo cuando otro termina se detecta como conflicto).
• "Buscar hueco" funciona de punta a punta. Con un recurso ocupado del 10 al 15 de enero, buscó 3 días y me devolvió correctamente el 16-18. Y luego creó el evento y lo guardó.
• La persistencia con backup funciona: verifiqué que antes de sobrescribir guarda el estado anterior en eventos_backup.json. Buen detalle de robustez.

Qué mejorar

• Código muerto en la clase Recurso. Tiene self.recursos = [] y métodos como agregar_recurso/ver_recursos, pero nunca se llenan: los recursos viven dentro de cada evento, no en la instancia. Por eso la opción "Ver recursos asignados" (menú 4 → 2) siempre dice "No hay recursos registrados". Sugerencia: o quitas esa opción del menú, o la reescribes para que recorra self.planificador.eventos y liste los recursos realmente en uso.
• Métodos huérfanos en persistencia.py: guardar_evento_unico y eliminar_evento nunca se llaman. Bórralos para que el archivo quede más claro.
• Mensaje de error de carga que se pierde. Si eventos.json está corrupto, el programa arranca sin crashear (bien), pero no te avisa: en eventos.py solo imprimes el mensaje cuando hay eventos. Cambia esa condición para mostrar también los errores, así el usuario sabe si su archivo se dañó.
• except: desnudo en el backup (persistencia.py): mejor except Exception:, para no capturar cosas como interrupciones del teclado.
• Detalle idiomático: en obtener_recurso_por_numero concatenas las tres listas con tres bucles; puedes hacerlo en una línea con RECURSOS_HUMANOS + RECURSOS_TECNICOS + RECURSOS_FISICOS.

Sobre el informe

Muy bueno: extenso, ordenado y fiel al código. Las 9 reglas de co-requisitos, las 3 exclusiones y el criterio de solapamiento que documentas coinciden exactamente con lo implementado, y el ejemplo de JSON coincide con lo que el programa realmente genera. No exagera ninguna funcionalidad. Dos detalles menores: la sección de estructura lista un README.md que ya no existe (lo renombraste a report.md), y no menciona el código muerto ni la opción de menú vacía. Nada grave — es un informe honesto.

¡Buen trabajo, Marla! Tienes una base de diseño muy fuerte; lo que queda por pulir es sobre todo limpiar lo que sobra.