[Proyecto I]

[Sourcecamp06]

Nombre: Damiam David Fuentes Campos
Grupo: C121
Repositorio: https://github.com/Sourcecamp06/How-to-manager-your-dragon

Descripción

Proyecto de organizador de eventos ambientado en la peli How to train your dragon

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/Sourcecamp06/How-to-manager-your-dragon

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

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

3. Proyecto Python

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

Archivos Python (9, 1,318 líneas en total):

• main.py
• UI/__init__.py
• models/__init__.py
• models/gestor_de_recursos.py
• models/validador_de_reglas.py
• models/creador_de_eventos.py
• UI/page/__init__.py
• UI/page/events.py
• UI/page/form.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

2026-06-25 22:03:08.032 WARNING streamlit.runtime.state.session_state_proxy: Session state does not function when running a script without `streamlit run`
2026-06-25 22:03:08.129 
  �[33m�[1mWarning:�[0m to view this Streamlit app on a browser, run it with the following
  command:

    streamlit run main.py [ARGUMENTS]
Traceback (most recent call last):
  File "/tmp/tmpw0fj7f0m/venv/lib/python3.12

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/Sourcecamp06/How-to-manager-your-dragon

Qué hace tu proyecto

Construiste un organizador de eventos para la Isla de Berk con Streamlit: un menú, un formulario para crear eventos (tipo, arena, fechas, guerreros, dragones, armas, armaduras, ovejas) y una vista de eventos activos con imágenes y opción de eliminar. Lo más valioso es que separaste muy bien las capas: los modelos y las 9 reglas de negocio viven aparte de la interfaz, como funciones puras (...) -> (bool, mensaje). Esa decisión es limpia y madura para un primer año.

Ejecución

No es una app de consola, así que la corrí de dos formas. Primero ejercité toda la lógica de negocio en aislado (instanciando GestorEventos, creando objetos Evento reales y llamando las 9 reglas con datos concretos), precisamente porque tu código lo permite gracias a la buena separación. Luego levanté la GUI en modo headless con streamlit run main.py --server.headless true y arrancó correctamente (HTTP 200, sin ningún traceback tuyo). Todos los módulos pasan py_compile.

Lo que está bien

• Las 9 reglas funcionan de verdad, verificado una por una: disponibilidad de arena (solapamientos), dragón-con-su-guerrero (Astrid necesita Tormenta, los hermanos van juntos), balance de cremallerus, ovejas sólo en la Playa, excursión sólo en la Guarida, colisiones Hippo/Patán y Bocón/Estoico. Todas devolvieron el mensaje correcto.
• La persistencia funciona: creé un evento con muchos recursos, lo guardé en JSON, y al recargar en un gestor nuevo se restauraron eventos, inventario y participación diaria intactos.
• Devuelves los recursos al inventario cuando eliminas un evento (events.py:190-210) — un detalle de coherencia que muchos olvidan.
• La validación de fechas en el constructor del Evento (creador_de_eventos.py:7-10) rechaza correctamente fecha de fin anterior o igual a la de inicio.

Qué mejorar

• Participación multi-día: al crear un evento sólo registras la participación en start_date (form.py:457-460), pero tu propio compilar_participacion_diaria (que usas al recargar) sí expande todo el rango de días. Resultado: en la misma sesión un evento de varios días sólo bloquea su día inicial. Solución: llama a compilar_participacion_diaria también al crear, para que la Regla 2 aplique igual antes y después de recargar.
• recomendar_fecha tiene un IndexError latente (gestor:133-150): si la lista de eventos de esa arena está vacía, events_list[len-1] revienta. Hoy no te afecta porque sólo se llama cuando la arena ya está ocupada, pero conviene blindarlo con un if not events_list: return ... al inicio.
• Código muerto: verificar_recursos_disponibles es un pass (gestor:106) y cargar_eventos en events.py:68-74 nunca se usa. Bórralos para que el código diga sólo lo que hace.
• except: desnudos en events.py (líneas 98, 122, 145, 164, 186): atrapan cualquier error y esconden bugs. Usa except FileNotFoundError o el error específico que esperas.

Sobre el informe

El report.md (2.041 palabras) está bien escrito y coincide con el código en lo importante: los 6 tipos de evento, las 5 arenas, las 9 reglas y el inventario. Un par de detalles menores para pulir: el informe lista 4 armaduras pero tu código define 5 (te falta "Cinturón de cuero" en el texto, gestor:82), y describe la Regla 2 como "guerrero y su dragón" cuando la implementación rastrea participantes de franquicia (con el matiz multi-día de arriba). Nada grave — es honesto y refleja bien tu trabajo.

¡Buen proyecto! La arquitectura limpia que lograste es exactamente el tipo de decisión que hace que un programa crezca sin dolor. Con los ajustes de participación diaria y la limpieza del código muerto queda redondo.