[Proyecto I] Hotel Event Manager

[Stark040301]

Nombre: Abel Rodríguez Puig
Grupo: C-122
Repositorio: https://github.com/Stark040301/Hotel_Planner_Project

Descripción

Aplicación Python/CustomTkinter para gestionar inventario hotelero y planificar eventos con validación de recursos y persistencia en JSON. Arquitectura MVC.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/Stark040301/Hotel_Planner_Project

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

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

3. Proyecto Python

⚠️ Sin pyproject.toml.
✅ requirements.txt encontrado.
Dependencias declaradas: customtkinter, tkcalendar, darkdetect, iniconfig, markdown-it-py, mdurl, packaging, pillow, pluggy, Pygments

Archivos Python (28, 5,442 líneas en total):

• main.py
• hotel_planner/core/scheduler.py
• hotel_planner/models/inventory.py
• hotel_planner/models/store.py
• hotel_planner/models/inventory_store.py
• hotel_planner/models/event.py
• hotel_planner/models/resource.py
• hotel_planner/models/event_store.py
• hotel_planner/ui/vertical_segmented.py
• hotel_planner/ui/__init__.py
• hotel_planner/ui/app.py
• hotel_planner/ui/io_worker.py
• hotel_planner/ui/advanced_ui.py
• hotel_planner/ui/styles.py
• hotel_planner/ui/controller.py
• (y 13 más)

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

Traceback (most recent call last):
  File "/tmp/tmppij57at4/repo/main.py", line 11, in <module>
    app = App()
          ^^^^^
  File "/tmp/tmppij57at4/repo/hotel_planner/ui/app.py", line 29, in __init__
    super().__init__()
  File "/tmp/tmppij57at4/venv/lib/python3.12/site-packages/customtkinter/windows/ctk_tk.py", line 40, in __init__
    CTK_PARENT_CLASS.__init__(self, **pop_from_dict_by_set

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/Stark040301/Hotel_Planner_Project

Qué hace tu proyecto

Construiste una aplicación de escritorio (CustomTkinter, MVC de verdad) para gestionar un inventario hotelero de salas, empleados y objetos, y planificar eventos que consumen esos recursos. El corazón es un Scheduler que valida disponibilidad por solapamiento de intervalos, respeta restricciones de co-requisito y exclusión entre recursos, y hasta busca el siguiente hueco libre. Para ser primer año, el alcance y la calidad del diseño son sobresalientes.

Ejecución

La GUI (python main.py) no arrancó en mi entorno, pero no es culpa tuya: falla al no haber servidor gráfico (X11) — el mismo aborto de xcb/Tkinter que vio la verificación automática. Como separaste bien la lógica de la vista, probé el backend directamente con tus datos reales (default_data.json, 81 recursos y 9 eventos) y corrí tus tests. Resultados:

• py_compile de los 28 módulos: OK.
• Tus tests (tests/test_constraints.py): 5 passed en 0.07s.
• Programar un evento válido → (True, None); sobre-reservar una sala ocupada → rechazado con libres: 0; pedir 15 camareros de 12 → rechazado; pedir 12 → aceptado.
• find_next_available con dos eventos en 10-12 y 14-16 devolvió justo el hueco 12:00-13:00.
• JSON corrupto, archivo inexistente y fin <= inicio → todos manejados con mensajes claros, sin ningún Traceback.

Todo el motor de planificación funciona correctamente.

Lo que está bien

• Motor de scheduling correcto y bien diseñado: índices ordenados con bisect, conteo de reservas por solapamiento de intervalos, y un barrido sweep line (resource_usage_intervals) para saber cuántas unidades están en uso en cada tramo. Nivel alto.
• Arquitectura MVC genuina: modelo, Scheduler, Controller y vistas de verdad separados. Tanto que pude probar el backend sin la GUI — eso es señal de buen diseño.
• Polimorfismo real: Room/Employee/Item sobre Resource, cada uno extendiendo to_dict().
• Escritura atómica (archivo .tmp + os.replace) para no corromper datos si falla el guardado. Patrón maduro, poco común en un principiante.
• Escribiste tus propios tests unitarios y pasan. Excelente hábito.

Qué mejorar

• Bug real en "Añadir Recurso". Inventory.add_resource (inventory.py:22) no tiene return, así que devuelve None. Pero el controlador espera el recurso de vuelta: added = ...add_resource(room); return (True, added.to_dict()) (controller.py:93-94). Lo verifiqué: al añadir una sala, el controlador responde (False, "'NoneType' object has no attribute 'to_dict'") aunque el recurso sí se añade. O sea, la UI mostraría un error engañoso al añadir cualquier recurso. Arréglalo haciendo que add_resource devuelva el recurso añadido (return resource).
• Duplicación al fusionar recursos. En inventory.py, cuando ya existe un recurso con ese nombre, sumas la cantidad a la entrada existente… pero luego igualmente haces self.resources.append(resource) (inventory.py:38), dejando dos filas con el mismo nombre. Probé Item('Silla', 10) + Item('Silla', 5) y quedan dos entradas (15 y 5). No se nota con los datos de ejemplo (nombres únicos), pero el append debería ir dentro de un else.
• Limpieza menor: quedan varios print("DEBUG ...") en app.py (mejor logging), algún except Exception: pass que se traga errores, y código de carga casi idéntico entre load_events y load_events_from_list que podrías unificar.

Sobre el informe

Muy completo (2.797 palabras) y en general honesto: MVC, escritura atómica, ruta de persistencia ~/.hotel_planner/data.json, tests… todo coincide con el código. Un matiz: presentas la recurrencia (diaria/semanal/mensual…) como funcionalidad, pero en el código es solo un campo que se guarda — el scheduler no expande eventos recurrentes (tú mismo lo dejaste como TODO en scheduler.py:92 y una nota en scheduler.py:45). Un evento "diario" solo ocupa su intervalo único. Vale la pena aclarar en el informe que la recurrencia se almacena pero aún no se aplica.

En resumen: un proyecto ambicioso y bien construido, con un motor correcto y tests propios. Corrige el contrato de add_resource y quedará también sólido en el flujo de añadir recursos. ¡Muy buen trabajo!