[Proyecto I] Centro Recreativo

[mmaacr1012-coder]

Nombre: Marco Antonio Camacho Ramos
Grupo: C122
Repositorio: https://github.com/mmaacr1012-coder/-Proyecto-I-Centro_Recreativo

Descripción

Un gestor de eventos para un Centro Recreativo, permite además la creación de recursos para ser utilizados en dichos eventos.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/mmaacr1012-coder/-Proyecto-I-Centro_Recreativo

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

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

3. Proyecto Python

✅ pyproject.toml — proyecto estructurado correctamente.
✅ requirements.txt encontrado.
Dependencias declaradas: streamlit

Archivos Python (7, 301 líneas en total):

• __init__.py
• page_core.py
• Home.py
• pages/__init__.py
• pages/3_Recursos.py
• pages/2_Lista de Eventos.py
• pages/1_Agregar Evento.py

4. Punto de Entrada

✅ Punto de entrada detectado: Home.py

5. Ejecución

✅ El proyecto se ejecuta.

2026-06-26 08:02:24.764 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 08:02:24.764 WARNING streamlit.runtime.state.session_state_proxy: Session state does not function when running a script without `streamlit run`
2026-06-26 08:02:24.764 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.

[apiad]

🔍 Revisión de Código — Claude Code

Repositorio: https://github.com/mmaacr1012-coder/-Proyecto-I-Centro_Recreativo

Qué hace tu proyecto

Construiste un gestor de eventos para un centro recreativo con Streamlit, en tres páginas: agregar eventos, listarlos y administrar recursos. Lo más valioso es tu motor de validación: cuando armas un evento y eliges recursos, el programa comprueba en cascada que no haya incompatibilidades entre recursos, que respeten sus horarios de trabajo, y que queden copias libres en ese tiempo — y si no las hay, hasta busca recursivamente el próximo día disponible y te lo sugiere. Eso es ambicioso y está bien hecho para primer año.

Ejecución

Como es una app web (no consola), la ejecuté de dos formas. Primero arranqué el servidor de verdad (streamlit run Home.py --server.headless true): levantó limpio, sin Traceback, y respondió ok en su endpoint de salud. Segundo, aislé toda tu lógica de page_core.py y la corrí directamente con tu data.json real, probando decenas de combinaciones válidas e inválidas. Casi todo se comportó exactamente como esperaba: Piloto+Arbitro se bloquea, el Avion sin Piloto se bloquea, los horarios de trabajo se respetan, las exclusiones/inclusiones del Trampolin funcionan, y la saturación del Avion (que solo hay 1) devuelve una sugerencia de fecha. Nada reventó.

Lo que está bien

• Separaste lógica de presentación de verdad: todas las validaciones viven en page_core.py y las páginas solo las llaman. Eso es exactamente lo que se busca.
• La búsqueda recursiva del próximo hueco disponible cuando un recurso está agotado funciona end-to-end. Es la parte más difícil del proyecto y la resolviste.
• Tienes dos sistemas de restricciones conviviendo: las fijas del centro (en código) y las de usuario (guardadas en datos). El segundo, data-driven, es la aproximación correcta y la implementaste bien.
• La app arranca y se sirve sin errores, con las páginas y las tablas formateadas.

Qué mejorar

• Bug real: una regla nunca se cumple por un typo. En page_core.py:27 escribiste "Pelota de tennis" (dos n), pero en data.json el recurso es "Pelota de tenis" (una n). Verifiqué en ejecución: usar Protectores junto a la pelota de tenis debería bloquearse y no se bloquea, porque los nombres no coinciden. Además, en otras líneas del mismo archivo (:33, :39) sí escribiste "tenis" con una n, así que tienes las dos ortografías mezcladas. Arregla la línea 27 a "Pelota de tenis".
• Bug menor: la fecha sugerida se pasa por un día. Si el Avion está ocupado solo el día 20 y lo pides ese día, el programa sugiere el día 22, cuando el primer día libre es el 21. Ocurre porque en page_core.py:87 haces newsd = sd + 1 día y en :89 sumas otro día antes de comprobar, saltándote el 21. Empieza a comprobar desde newsd sin sumar de más.
• Duplicación: el bloque que abre data.json y rellena st.session_state está copiado en las 4 páginas. Muévelo a una función en page_core.py y llámala desde cada página — si mañana cambias cómo cargas los datos, hoy tendrías que editar 4 sitios.
• Trampa latente: en pages/3_Recursos.py:16 llamas a una variable open, que es el nombre de una función propia de Python que tú mismo usas más arriba (open("data.json")). Funciona por el orden, pero es peligroso. Renómbrala a apertura.
• Detalle idiomático: type(amount) == int mejor como isinstance(amount, int), y valid_date puede ser simplemente return sd < ed.

Sobre el informe

Coincide bien con el código y es honesto: describes el flujo real, distingues correctamente los recursos "propios" (reglas en código) de los de usuario (reglas en datos), y —muy bien— adviertes tú mismo el comportamiento de que guardar sin cargar antes sobrescribe la base de datos. No exageras ni afirmas cosas que no probaste. Dos apuntes: quedó corto (652 palabras frente al mínimo de 2000), y no mencionaste la búsqueda recursiva de fechas disponibles, que es justo lo más lucido que hiciste — merecía un párrafo. Además, tu pyproject.toml referencia un README.md que no está en el repo.

Muy buen trabajo. Corrige el typo de la línea 27 y tienes un proyecto que funciona de punta a punta con un motor de validación por encima del nivel esperado. Sigue así.