[Proyecto I] Gimnasio

[hectorsebastian2025]

Nombre: Héctor Sebastián Rodríguez Chacón
Grupo: C121
**Repositorio:**https://github.com/hectorsebastian2025/Planificador-de-Gimnasio.git

Descripción

Planificador de eventos en un gimnasio donde puedes reservar los locales disponibles en la institución

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/hectorsebastian2025/Planificador-de-Gimnasio.git

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: ��a�l�t�a�i�r�, �, �a�t�t�r�s�, �, �b�l�i�n�k�e�r�, �, �c�a�c�h�e�t�o�o�l�s�, �, �c�e�r�t�i�f�i�, �

Archivos Python (12, 944 líneas en total):

• src/__init__.py
• src/models.py
• src/tempCodeRunnerFile.py
• src/app_streamlit.py
• src/storage_clientes.py
• src/storage.py
• src/storage_eventos.py
• src/pages/__init__.py
• src/pages/gestion_eventos.py
• src/pages/clientes_registro.py
• src/pages/gestion_clientes.py
• src/pages/eventos.py

4. Punto de Entrada

⚠️ No se encontró un punto de entrada claro (main.py, app.py, etc.).

5. Ejecución

⚠️ Sin punto de entrada identificado — no se intentó ejecutar.

Resumen

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

3/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/hectorsebastian2025/Planificador-de-Gimnasio

Qué hace tu proyecto

Construiste un planificador de gimnasio como app web con Streamlit: registro y baja de clientes, reserva de recursos por fecha y turno, cancelación de reservas y una portada con barras de ocupación. Lo más valioso es la riqueza de las reglas de negocio: acceso por plan (con el caso "con/sin entrenador"), ventana de 7 días, capacidad por turno, no-duplicados y hasta una regla encadenada — para reservar la cámara hiperbárica hace falta una cita previa de consultorio en los últimos 7 días. Y todo eso está limpiamente separado de la interfaz.

Ejecución

Lo corrí de verdad de dos formas. Primero, arranqué la GUI en modo headless (streamlit run src/app_streamlit.py --server.headless true): arrancó limpia, sirvió la portada con HTTP 200 y sin ningún Traceback. Segundo, ejercité tu lógica de negocio importando storage_eventos.py / storage_clientes.py sobre una copia de tu data.json, probando muchos flujos válidos e inválidos.

Todo se comportó bien: cliente/recurso inexistente, turno basura (99:00-99:00), fecha mal formateada, fecha pasada, fecha a +30 días, plan que no cubre el recurso, cliente inactivo, capacidad llena, reserva duplicada, cancelar una reserva ya cancelada — cada uno devolvió el mensaje correcto y ninguno reventó. También verifiqué el camino feliz de la cámara hiperbárica (inyectando una cita de consultorio reciente): se autorizó correctamente. Muy buen trabajo de robustez.

Lo que está bien

• Separación lógica/GUI de manual: tus storage_*.py no importan streamlit, así que pude testear todo el núcleo sin la interfaz. Esto es exactamente lo que se busca.
• Manejo de errores consistente: cada regla es un raise Exception(mensaje) y cada página lo captura con try/except mostrando st.error. Uniforme y claro.
• Reglas de dominio no triviales bien resueltas: el caso "Sala de musculación con/sin entrenador" según el plan (storage_eventos.py:62-71) y la autorización encadenada de la cámara hiperbárica están bien pensados y funcionan.
• Rutas robustas: usas os.path.dirname(__file__) + normpath en vez de rutas relativas frágiles. Detalle de madurez.

Qué mejorar

• Tienes un bloque de validación que nunca se ejecuta. La comprobación de disponibilidad de personal (storage_eventos.py:111-123) va después de la de capacidad (:87-97). Como Fisioterapia, Consultorio y Nutricionista tienen capacidad 1 en tu data.json, en cuanto hay una reserva la capacidad ya está llena y el flujo aborta antes de mirar el personal. Lo confirmé ejecutando. Solución: subir esas capacidades a lo que dice tu informe (2), o mover la validación de personal antes de la de capacidad.
• Clases sin usar en models.py: defines Plan, Evento y Gimnasio pero no las instancias en ningún flujo real (Plan incluso pide precio_mensual, que tu JSON no tiene). Deja solo lo que usas; el resto confunde al lector.
• Sidebar duplicado: las ~30 líneas de botones del menú están copiadas literalmente en las 4 páginas. Extráelo a una función render_sidebar() en un módulo compartido y llámala desde cada página — si mañana cambias un botón, lo cambias en un solo sitio.
• Generación de IDs: id = len(clientes) + 1 (clientes_registro.py:56) funciona hoy porque nunca borras físicamente, pero es frágil. Lo idiomático es max(c["id"] for c in clientes) + 1.
• Limpieza: quedaron src/tempCodeRunnerFile.py (basura del editor) y un import timedelta sin usar en storage.py:4.

Sobre el informe

Bien estructurado y en general fiel al código, sin exageraciones groseras. Tres desajustes que conviene corregir: (1) la tabla dice Fisioterapia = 2 y Nutricionista = 2, pero tu data.json las tiene en 1 — y justo esa diferencia es la que deja muerto tu código de personal; (2) listas los estados como INACTIVA, pero el código usa FINALIZADA y EN_CURSO; (3) hablas de "entrenadores" en el personal, pero tu personal en el JSON no incluye ningún rol Entrenador. Detalles de precisión, no de invención.

En conjunto: un proyecto sólido, con una lógica ambiciosa y correcta que verifiqué ejecutándola. Cierra la brecha entre lo que dice el informe y lo que dice el data.json, quita el andamiaje que no usas, y tendrás un trabajo muy pulido. ¡Buen trabajo!