[Proyecto I]

[leonardogq]

Nombre: Leonardo González Quintana
Grupo: C122
Repositorio: https://github.com/leonardogq/proyecto

Descripción

Planificador Inteligente de Eventos para un Estudio de Grabación.

Aplicación desarrollada en Python con Streamlit que permite gestionar la planificación de eventos considerando salas, recursos, personal y restricciones específicas del dominio. El sistema valida automáticamente la disponibilidad de recursos, aplica reglas configurables mediante archivos JSON y evita conflictos durante la programación de actividades como grabaciones de podcast, doblaje, canciones e instrumentales.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/leonardogq/proyecto

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

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

3. Proyecto Python

⚠️ Sin pyproject.toml.
✅ requirements.txt encontrado.
Dependencias declaradas: streamlit

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

• main.py
• planificador.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

2026-06-27 01:54:28.669 WARNING streamlit.runtime.scriptrunner_utils.script_run_context: Thread 'MainThread': missing ScriptRunContext! This warning can be ignored when running in bare mode.
2026-06-27 01:54:28.699 
  �[33m�[1mWarning:�[0m to view this Streamlit app on a browser, run it with the following
  command:

    streamlit run main.py [ARGUMENTS]
2026-06-27 01:54:28.699 Thread 'MainThread'

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/leonardogq/proyecto

Qué hace tu proyecto

Construiste un planificador de eventos para un estudio de grabación: gestiona salas, inventario de equipos/instrumentos/personal y programa grabaciones (podcast, doblaje, canción, instrumental) validando un montón de reglas del dominio antes de aceptar cada reserva. Lo más valioso es que separaste limpiamente la lógica de negocio (PlanificadorEventos en planificador.py) de la interfaz web en Streamlit (main.py), y sacaste todas las reglas a archivos JSON para poder cambiarlas sin tocar el código. Eso es diseño de nivel alto para primer año.

Ejecución

Como es una app Streamlit (web, no consola), no se puede alimentar por teclado; así que probé tu lógica de negocio directamente instanciando PlanificadorEventos con los datos reales del repo, y además arranqué la GUI en modo headless para confirmar que levanta (respondió HTTP 200 y health "ok"). Corrí 18 escenarios, válidos e inválidos. Todos se comportaron correctamente y ninguno provocó un crash del código. py_compile de ambos módulos: OK.

Lo que está bien

• Separación GUI/lógica: pude testear el núcleo sin la interfaz. Eso es exactamente lo que buscamos.
• Validaciones que funcionan de verdad: reproduje los 5 ejemplos de tu informe y salen idénticos — corequisitos (Si hay 3 'Micrófonos' debe haber 3 'Soportes de micrófono'...), fechas pasadas, personal obligatorio, exclusiones por sala, inventario insuficiente.
• Validación en etapas (agregar_evento): frenar en el primer error crítico para no soltar una avalancha de mensajes confusos es una decisión de diseño madura, y la explicaste muy bien en el informe.
• Reglas en JSON: cambiar mínimos de personal o exclusiones no toca el código.
• Detalles finos correctos: distingues int de bool para no confundir requiere_instrumentos: true con un mínimo numérico; la excepción "Batería no necesita cables" funciona; y hasta manejas el caso de que la fecha no sea datetime con un mensaje claro.

Qué mejorar

• Unifica la persistencia. Ya tienes guardar_eventos_json() en la clase, pero en main.py vuelves a escribir el JSON a mano en tres sitios (main.py:76, :110, :177). Peor: ahí guardas la fecha como ...isoformat() de solo el día, mientras el método de la clase la guarda con hora (...T00:00:00). El archivo termina con dos formatos según quién lo escriba. Reemplaza esos bloques por planificador.guardar_eventos_json() y listo: menos código y un solo formato.
• Nombres consistentes. Unos métodos llevan guion bajo (_validar_fechas) y otros no (validar_exclusiones_por_sala). Si el guion bajo significa "método interno", aplícalo a todos por igual; si no, quítalo.
• Protege las cargas de JSON. cargar_eventos_json maneja FileNotFoundError, pero cargar_recursos_json y cargar_restricciones_json no (planificador.py:555-567). Si faltara uno de esos archivos, la app revienta al arrancar. Un try/except con un mensaje claro lo hace más robusto.
• Docstrings de verdad. Tus descripciones de métodos son comentarios # dentro del cuerpo; si los pones como cadenas """...""" justo debajo del def, aparecen en help() y las herramientas los reconocen.

Sobre el informe

Muy bueno: extenso, coherente con el código y —lo que más valoro— honesto. Los ejemplos coinciden con lo que realmente produce el programa, y en "Problemas encontrados" reconoces con precisión que validar_exclusiones_por_evento existe pero hoy no tiene ninguna exclusión configurada, y explicas el porqué de la validación en etapas. Dos detalles menores: llamarlo "Inteligente" es generoso para un sugeridor que busca día a día de forma lineal (tú mismo lo describes como "relativamente sencillo", lo cual es honesto), y el Ejemplo 2 muestra una fecha de sugerencia (2026-06-26) que es anterior a hoy — es un valor de ilustración, el código real sugiere fechas futuras. Nada grave.

Buen trabajo, Leonardo. El dominio que elegiste es rico y lo modelaste con seriedad. Seguí así.