[Proyecto I] #312

Activity

1. github-actions commented on Jun 26, 2026

   

   github-actionsBot

   on Jun 26, 2026 – with GitHub Actions

   More actions

   Verificación Automática — Proyecto I 🤖

   Repositorio analizado: https://github.com/lacuentadeadrian57-netizen/Reservation-Manager

   1. Repositorio

   ✅ El repositorio es accesible y fue clonado correctamente.

   2. Informe (report.md)

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

   3. Proyecto Python

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

   Archivos Python (3, 547 líneas en total):

   • manager.py
   • loader.py
   • main.py

   4. Punto de Entrada

   ✅ Punto de entrada detectado: main.py

   5. Ejecución

   ✅ El proyecto se ejecuta.

   2026-06-26 14:23:20.181 WARNING streamlit.runtime.scriptrunner_utils.script_run_context: Thread 'MainThread': missing ScriptRunContext! This warning can be ignored when running in bare mode.
   2026-06-26 14:23:20.181 WARNING streamlit.runtime.state.session_state_proxy: Session state does not function when running a script without `streamlit run`
   2026-06-26 14:23:20.181 WARNING streamlit.runtime.scri
   

   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.
2. apiad commented on Jul 15, 2026

   

   apiad

   on Jul 15, 2026

   Member

   More actions

   🔍 Revisión de Código — Claude Code

   Repositorio: https://github.com/lacuentadeadrian57-netizen/Reservation-Manager

   Qué hace tu proyecto

   Construiste un gestor de reservas web con Streamlit que administra locales, recursos y reservas a lo largo del tiempo, con precios, exclusiones entre recursos y requisitos por local. Lo más valioso es tu motor de resolución de colisiones: cuando dos reservas se solapan (por el mismo local o por agotar un recurso compartido), tu sistema desplaza automáticamente la segunda al siguiente hueco libre preservando su duración. Eso es un algoritmo de verdad, no trivial, y funciona.

   Ejecución

   Como es una app Streamlit (no de consola), la probé de dos formas: ejercité tu lógica de negocio (manager.py) directamente con los datos reales de save.json, y además levanté la GUI en modo headless. La GUI arrancó sin problemas (HTTP 200, sin errores) y la lógica pasó todas las pruebas de flujo. Corrí, entre otras: cálculo de precio (Conference Room 1 día + Whiteboard + Coffee → 420, correcto), altas válidas, y todos los rechazos esperados (fecha inicio > fin, fecha en el pasado, opcional inválido, exclusión Mirrors+Lighting). También forcé cascadas de 3 reservas solapadas y contención de un recurso escaso entre dos locales: en todos los casos el desplazamiento fue correcto y sin solapamientos.

   Lo que está bien

   • Separación GUI / lógica ejemplar. manager.py no depende de Streamlit para nada; pude probar toda tu lógica sin tocar la interfaz. Ese diseño es maduro y poco común en primer año.
   • El motor de colisiones funciona de verdad, incluyendo el caso difícil de recursos compartidos entre locales distintos (verificado bajando la cantidad de Screen a 1).
   • Escritura atómica del JSON (archivo temporal + os.replace en loader.py): evita corromper el guardado si algo falla a mitad. Muy buen detalle.
   • Anotaciones de tipo consistentes y un id_map para acceso O(1) por ID.
   • Las validaciones dan mensajes claros y accionables.

   Qué mejorar

   • Tu código exige Python 3.12+, pero el informe dice "3.8+". En manager.py:108 y main.py:116 usas f-strings con comillas anidadas iguales (f"...{_reserve["start"]}..."), sintaxis válida solo desde 3.12. Lo compilé en Python 3.11 y da SyntaxError: en cualquier versión anterior tu app no arranca. Corrige el informe a "3.12+", o cambia las comillas internas por simples para que corra en más versiones.
   • delete_resource deja referencias colgantes. Al borrar Mirrors, la lista de exclusiones de Lighting controls sigue mencionando a Mirrors. No rompió nada en mis pruebas, pero deja estado inconsistente. Al borrar un recurso, recórrelo también en las exclusiones de los demás.
   • update_quantity tiene una rama que nunca se ejecuta (manager.py:192-196): asignas el valor antes de comparar value < self.quantity[name], así que la comparación siempre es falsa y refresh() no se dispara al reducir stock. Guarda el valor viejo en una variable antes de asignar.
   • add_location con un requisito inexistente lanza KeyError. Desde la GUI no ocurre (el multiselect limita las opciones), pero si algún día llamas esa lógica de otro modo, crasheará. Vale un chequeo defensivo.
   • Detalle menor: except: desnudo en loader.py y la lectura de JSON sin protección contra archivos corruptos (la escritura sí la tiene, la lectura no).

   Sobre el informe

   El informe describe bien la arquitectura y las restricciones — y esas restricciones sí están implementadas, lo comprobé. Pero tiene tres cosas que corregir: (1) el texto está duplicado literalmente dos veces; el contenido único real son ~1014 palabras, así que el conteo que supera el mínimo es artificial — con desduplicar quedas por debajo. (2) La versión de Python es incorrecta (3.8+ → 3.12+). (3) Hablas de reservas con horas ("10:00-12:00") y "horarios de apertura", pero tu sistema trabaja solo con fechas (día completo); ese ejemplo no corresponde a lo que hace el código. Ajusta el informe a lo que el programa realmente hace: será más corto pero honesto, y eso vale más.

   Buen trabajo, Adrian. El núcleo algorítmico es lo difícil y lo resolviste bien; lo que queda es pulir el mantenimiento de estado y alinear el informe con el código real.