[Proyecto I]

[Winterwolf270]

Nombre: Bryan Etzel Blanco Galbán
Grupo: C-122
Repositorio: https://github.com/Winterwolf270/Calendario-de-eventos-y-excursiones.git

Descripción:

Un planificador de eventos y excursiones sencillo y de fácil manejo.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/Winterwolf270/Calendario-de-eventos-y-excursiones.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.
⚠️ Sin requirements.txt.

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

• calendario.py
• agregar.py
• logica.py
• main.py
• guia.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

Traceback (most recent call last):
  File "/tmp/tmpat5eza7c/repo/main.py", line 37, in <module>
    main()
  File "/tmp/tmpat5eza7c/repo/main.py", line 7, in main
    root = tk.Tk()
           ^^^^^^^
  File "/opt/hostedtoolcache/Python/3.12.13/x64/lib/python3.12/tkinter/__init__.py", line 2346, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, us

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.

[Winterwolf270]

/revisar

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/Winterwolf270/Calendario-de-eventos-y-excursiones.git

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

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

3. Proyecto Python

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

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

• calendario.py
• agregar.py
• logica.py
• main.py
• guia.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

Traceback (most recent call last):
  File "/tmp/tmprw1rzqct/repo/main.py", line 37, in <module>
    main()
  File "/tmp/tmprw1rzqct/repo/main.py", line 7, in main
    root = tk.Tk()
           ^^^^^^^
  File "/opt/hostedtoolcache/Python/3.12.13/x64/lib/python3.12/tkinter/__init__.py", line 2346, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, us

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/Winterwolf270/Calendario-de-eventos-y-excursiones.git

Qué hace tu proyecto

Construiste un planificador de excursiones con interfaz gráfica (Tkinter): una ventana principal con cuatro botones que llevan a la Guía (catálogo de 9 eventos con sus detalles), a Agregar (un formulario para reservar con evento, fecha y personas) y al Calendario (un mes pintado día a día que muestra la ocupación en colores y deja ver o eliminar reservas). El corazón del sistema es un límite de 2 transportes por día, y todo se guarda en dos archivos JSON. Lo más valioso es que aislaste esa regla de ocupación en su propio módulo (logica.py), separada de la interfaz.

Ejecución

No es una app de consola, así que no la alimenté con printf: es una GUI. Compilé los cinco módulos con py_compile sin ningún error. Intenté arrancar las ventanas en un display virtual (headless) pero esta máquina aborta Tkinter por un problema del entorno (una assertion de xcb) incluso con una ventana mínima que no es tuya — así que no pude ver la interfaz aquí, y quede constancia de que el fallo no es de tu código. Lo que sí hice fue ejecutar de verdad tu lógica de negocio con el eventos.json real: el alta de reservas, la validación de cupo, el cálculo de costo, la limpieza automática de fechas pasadas y el borrado.

Lo que está bien

• Separaste calcular_ocupacion en logica.py como función pura. Esa fue la mejor decisión del proyecto: es lo que me permitió probar tu programa sin la interfaz. Buen instinto.
• La validación de capacidad funciona: al intentar una tercera reserva en un día ya con 2, el programa la rechaza con mensaje de error. Verificado ejecutándolo.
• El costo se calcula bien: Buceo $50 × 4 personas = $200, Escalada $70 × 2 = $140. Correcto.
• La limpieza automática de fechas pasadas funciona: puse una reserva vieja y una futura, y solo conservó la futura.
• Que los tres campos del formulario sean Combobox de solo lectura es una buena defensa: hace imposible meter basura (fechas raras, texto donde va un número). Bien pensado.

Qué mejorar

• El "arrastre" de ocupación al día siguiente está aplicado al revés (logica.py:17-19). Tu regla suma ocupación al día siguiente cuando la duración empieza por "1 día", pero en tu catálogo todos los eventos son de 1 día. Al ejecutarlo, dos eventos de un día bloquean el día siguiente, aunque esos eventos ya terminaron. En cambio, un evento de 2 días no ocupa su segundo día. Lo que el informe describe (que los de "un día para otro" ocupen dos días) es lo contrario de lo que hace el código. La causa: comparas contra el texto "1 día" en vez de contra la duración real cuando es mayor que 1.
• Raíz del problema: la duración se representa de dos formas. En eventos.json es un número (duracion: 1), pero en la reserva la guardas como texto ("1 día(s)"). Esa asimetría es la que te obliga a usar startswith y la que confunde la regla. Si usaras el mismo tipo (por ejemplo, siempre el número de días) en catálogo y en reserva, la lógica quedaría directa y sin ese bug.
• El borrado elimina reservas "gemelas" (calendario.py:151-154). Borras filtrando por nombre + fecha, pero tu propio modelo permite 2 reservas del mismo evento el mismo día. Al probarlo, borrar una borró las dos. Dale a cada reserva un identificador único (un contador, o un id) y borra por ese id.
• Detalle menor: except Exception: a secas (agregar.py:78) se traga cualquier error y lo esconde. Mientras desarrollas, imprime el error; te ahorrará dolores de cabeza.

Sobre el informe

Tu informe es honesto y se nota el recorrido real: cuentas que empezaste en consola y migraste a Tkinter, qué te costó y qué quitaste. No exagera — incluso avisas de que probablemente no habrá reservas al revisar (por el borrado automático), y así fue. El único desajuste es el que menciono arriba: describes la intención correcta de los eventos de dos días, pero el código hace lo opuesto. Detalles menores: quita los **negrita**, *cursiva* que quedaron pegados en los títulos (parecen restos de una plantilla) y revisa "Excuriones" y "Enseñansa". Muy buen trabajo en general — seguí adelante así.