[Proyecto I]

[Gabriel84848]

**Nombre:**Gabriel Alvarez Amaro
**Grupo:**c-122
**Repositorio:**https://github.com/Gabriel84848/Remake-del-1er-Proyecto-Pyton-Matcom

Descripción

Sistema de reservas para el hotel "Blue Gate" con interfaz de consola que permite gestionar habitaciones y servicios, validando automáticamente la disponibilidad y aplicando restricciones como la obligatoriedad de desayuno para suites y la incompatibilidad entre masaje y yoga.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/Gabriel84848/Remake-del-1er-Proyecto-Pyton-Matcom

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

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

3. Proyecto Python

⚠️ Sin pyproject.toml.
⚠️ Sin requirements.txt.

Archivos Python (5, 1,265 líneas en total):

• Clases.py
• Main.py
• logica_reservas.py
• interfaz_usuario.py
• guardar_y_cargar.py

4. Punto de Entrada

✅ Punto de entrada detectado: Clases.py

5. Ejecución

✅ El proyecto se ejecuta.

(sin salida)

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.

[Gabriel84848]

Actualice el repositorio pq me marco 1917 palabras de 2000 y que no tengo el requirements.txt (el cual anadi pero vacio pq no uso librerias externas)

[apiad]

🔍 Revisión de Código — Claude Code

Repositorio: https://github.com/Gabriel84848/Remake-del-1er-Proyecto-Pyton-Matcom

Qué hace tu proyecto

Construiste un sistema de reservas para el hotel "Blue Gate" con un menú de consola de 7 opciones: ver catálogos de habitaciones y servicios, crear reservas (paso a paso), buscar hueco automático, cancelar y ver reservas. Lo más valioso es tu arquitectura: separaste la lógica pura (logica_reservas.py, que solo recibe datos y devuelve resultados) de la interfaz (interfaz_usuario.py). Esa decisión hace tu código robusto y verificable, y es más madura de lo habitual en primer año.

Ejecución

Lo corrí de dos formas. Por consola alimenté el menú real (printf ... | python Main.py): crear una reserva de la suite H204 la escribió correctamente en Yeison.json, y cancelarla dejó el JSON vacío. Y como tu lógica está bien separada, la ejercité aislada con datos reales del repo: 14 verificaciones, todas correctas. py_compile de los 5 módulos: OK. No encontré ningún bug funcional.

(Nota: el punto de entrada real es Main.py, no Clases.py como dijo el bot automático; por eso a él no le salió salida — la app pide input() de inmediato.)

Lo que está bien

• Todas tus restricciones funcionan, verificado ejecutando: mismo piso obligatorio, máximo 2 habitaciones, sin duplicados, suite H204 oculta cuando no hay desayuno, exclusión masaje/yoga, y capacidad de servicios (tras 5 desayunos → 0 disponibles).
• El solapamiento de fechas está bien resuelto: dos reservas adyacentes (el check-out de una = check-in de otra) NO colisionan — ese caso borde suele fallarle a la gente y a ti no.
• Validas entradas basura sin reventar: nombre "Al" (muy corto), fecha 01-01-2020 (pasado), 32-13-2026 y 31-02-2026 (imposibles), opción de menú 99 — todo se maneja con mensaje claro, ningún Traceback.
• Persistencia correcta: serializas date a ISO string y lo recuperas bien; y tienes un fallback que ante un JSON corrupto carga los datos por defecto (lo probé con un JSON roto y funcionó).
• El patrón de devolver (booleano, mensaje) en tus validaciones es consistente y limpio.

Qué mejorar

• Evita los except genéricos. En guardar_y_cargar.py:45 usas except Exception y en logica_reservas.py:74 un except: desnudo. El problema: si algún día hay un bug real de carga, quedará disfrazado de "usar datos por defecto" y no te enterarás. Sé específico: except (ValueError, KeyError). Así atrapas lo que esperas y dejas que lo inesperado te avise.
• Modela los servicios sin strings. Guardas los servicios como "desayuno:1" y luego los partes con .split(":") en muchos sitios. Eso es frágil (un typo en el formato rompe todo). Una tupla ("desayuno", 1) o un dict evitaría ese parseo repetido y sería más difícil de romper.
• Deriva ids_validos de los datos. En interfaz_usuario.py:22 la lista de IDs está escrita a mano; si cambias las habitaciones en el JSON, ese literal queda desactualizado. Mejor calcularla desde las habitaciones que ya cargaste.

Sobre el informe

Tu Report.md (2108 palabras, por encima del mínimo) es honesto y coincide bien con el código — los ejemplos de flujo que pusiste reproducen fielmente lo que vi al ejecutar, y no exageras la validación (dejas claro que la exclusión masaje/yoga es imposible desde la interfaz y que la verificación extra es "por si acaso"). Un solo detalle: en la sección 1.4.2 escribiste "verificar que no estén en el mismo piso" — se te invirtió la frase, tu código correctamente exige que sí estén en el mismo piso. También hay un encabezado duplicado al inicio. Nada de fondo, solo redacción.

Muy buen trabajo, Gabriel. La reescritura consciente para eliminar el código espagueti valió la pena y se nota. ¡Sigue así!