[Proyecto I]

[archleonardoalbert-oss]

Nombre: Leonardo Albert Lopez
Grupo: C121
Repositorio: https://github.com/archleonardoalbert-oss/P_1

Descripción Administracion de los eventos de un Hotel (revisado por Miguel Leyva)

(Añadir una breve descripción de su proyecto).

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/archleonardoalbert-oss/P_1

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.
✅ requirements.txt encontrado.
Dependencias declaradas: altair, attrs, blinker, cachetools, certifi, charset-normalizer, click, gitdb, gitpython, idna

Archivos Python (9, 1,624 líneas en total):

• events.py
• dependencias.py
• main.py
• interface_back.py
• GUI/home.py
• GUI/info.py
• GUI/visualization.py
• GUI/manage_resources.py
• GUI/manage_events.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

2026-06-27 03:36:43.965 Thread 'MainThread': missing ScriptRunContext! This warning can be ignored when running in bare mode.
2026-06-27 03:36:43.965 Thread 'MainThread': missing ScriptRunContext! This warning can be ignored when running in bare mode.
2026-06-27 03:36:43.965 Thread 'MainThread': missing ScriptRunContext! This warning can be ignored when running in bare mode.
2026-06-27 03:36:43.96

Resumen

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

5/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/archleonardoalbert-oss/P_1

Qué hace tu proyecto

Construiste un planificador de eventos para un hotel ("LuxAlbert") con interfaz web en Streamlit: creas eventos de 8 tipos (más uno personalizado), cada uno consume recursos de un inventario finito, y el sistema valida automáticamente cinco cosas antes de aceptarlo — recursos mínimos, colisiones (exclusión mutua), dependencias (co-requisitos), disponibilidad en la fecha, y validez del intervalo. Si la fecha está saturada, sugiere la próxima libre ("buscar hueco"). Además hiciste tres extras opcionales: recursos con cantidad (pools), eventos recurrentes con periodicidad/ciclos, y restricciones editables por el usuario desde la propia app. Muy completo para primer año.

Ejecución

Como es una app Streamlit (no de consola), la corrí de dos formas. Primero ejercité la lógica de negocio directamente con los datos reales de tu Database.json, porque separaste muy bien el backend (interface_back.py, events.py) de la GUI — eso me permitió auditar todo sin tocar la interfaz. Después arranqué la app en modo headless (streamlit run main.py): levantó correctamente y respondió HTTP 200, sin ningún error del lado del servidor. Los 10 módulos pasan py_compile.

Un detalle de instalación me frenó al inicio: tu requirements.txt fija ulid==1.1, pero ese paquete de PyPI no tiene ulid.new(), que es justo lo que usas en interface_back.py:164. Esa función viene de otro paquete, ulid-py. Con un pip install -r requirements.txt limpio, crear cualquier evento revienta con AttributeError. Lo salté instalando ulid-py y a partir de ahí todo corrió.

Lo que está bien

• Separación backend/frontend real. Pude probar toda tu validación aislada de la GUI. Es lo mejor del diseño y no siempre se ve a este nivel.
• Las cinco validaciones funcionan. Verifiqué ejecutando: fecha invertida/basura/imposible (30/02) → rechazadas; mesas sin sillas → detecta la dependencia faltante; organizador+ingenieros → detecta la colisión; y con tus 10 espectáculos que agotan los 10 Enanos el 22/02, un evento nuevo en esa fecha se rechaza correctamente por falta de recursos.
• "Buscar hueco" funciona. Pedí un evento el 22/02 (saturado) y me devolvió el 23/02. Correcto.
• Persistencia verificada. Guardar genera un ID ULID y suma el evento; borrar por ID y "limpiar todos" dejan la base como debe. Probado contra una copia de tu JSON.
• Tres extras opcionales implementados y funcionando (pools, recurrencia, restricciones editables). Eso es ambición bien ejecutada.

Qué mejorar

• Arregla el requirements.txt: cambia ulid==1.1 por ulid-py==1.1.0. Tal como está, nadie que clone tu repo puede crear eventos sin descubrir el truco por su cuenta. Es el cambio más importante.
• Corrige las instrucciones de arranque: tu README.txt dice streamlit run interface_front.py, pero ese archivo no existe — el punto de entrada real es main.py. Quien siga el README literalmente no logra abrir la app.
• El manejo de error en main.py:41-46 no hace lo que parece: llamas st.rerun() antes de reintentar y de mostrar el st.toast, y como rerun() corta la ejecución, esas líneas siguientes nunca se ejecutan. Si querías avisar del error, muestra primero el toast y luego decide si relanzas.
• Evita depender del orden de la lista de validaciones. En manage_events.py:130 accedes a validation_main[0][0], [1][0], [4]… Si algún día reordenas Details(), todo se rompe silenciosamente. Un diccionario con claves ({'min_recursos':..., 'colisiones':...}) o un namedtuple lo haría mucho más legible y a prueba de errores.
• Detalles pequeños: el import streamlit as st "para debug" en interface_back.py:6 no se usa y acopla tu backend a la GUI; from dependencias import * es mejor como import explícito; y applymap (visualization.py:62) está deprecado en pandas — usa .map. Ojo también con los KeyError si algún recurso pedido no está en la base: hoy la GUI te protege (solo ofrece recursos existentes), pero la lógica aislada no es robusta a eso.

Sobre el informe

Tu informe.txt me gustó por lo honesto: reconoces que la POO "no aporta demasiado", que los mensajes de error se pueden mejorar, listas una sección de "aspectos a mejorar" con la ineficiencia de recargar la base muchas veces, y declaras abiertamente que la sección Info la generaste con IA. Esa transparencia suma. El único desajuste con el código es el que mencioné: el README/estructura hablan de un interface_front.py que no existe. Corrígelo y el entregable quedará redondo. Buen trabajo — la base está muy bien pensada.