[Proyecto I]

[johanpauleg]

Nombre: Johan Paul Echevarría González
Grupo: C122
Repositorio: https://github.com/johanpauleg/The_Panama_Canal

Descripción

Gestor de eventos asociado al funcionamiento del Canal de Panamá.
Usa Streamlit para la interfaz, tiene dos archivos principales: app.py (funcionamiento de la interfaz e interacción con el usuario) y scheduler.py (lógica de validación de los eventos), y usa archivos .json para guardar la información de los eventos, los recursos existentes y las restricciones principales.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/johanpauleg/The_Panama_Canal

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

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

3. Proyecto Python

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

Archivos Python (2, 703 líneas en total):

• app.py
• scheduler.py

4. Punto de Entrada

✅ Punto de entrada detectado: app.py

5. Ejecución

⚠️ Error al instalar dependencias en el virtualenv:

ERROR: Could not find a version that satisfies the requirement Python>=3.10 (from versions: none)

[notice] A new release of pip is available: 25.0.1 -> 26.1.2
[notice] To update, run: python -m pip i

✅ El proyecto se ejecuta.

Traceback (most recent call last):
  File "/tmp/tmpe1iy3a01/repo/app.py", line 1, in <module>
    import streamlit as st
ModuleNotFoundError: No module named 'streamlit'

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/johanpauleg/The_Panama_Canal

Qué hace tu proyecto

Construiste un planificador de eventos del Canal de Panamá con restricciones de dominio realistas: 3 carriles con 3 esclusas cada uno, pilotos junior/senior, remolcadores y equipos de mantenimiento. El usuario crea eventos únicos o recurrentes (tránsitos o mantenimientos) desde una interfaz web en Streamlit, y tu sistema valida tiempo, duración, composición de recursos y —lo más difícil— disponibilidad real frente a los eventos ya programados. Cuando algo choca, no dices solo "no": buscas y sugieres el próximo horario libre. Muy ambicioso y bien logrado para primer año.

Ejecución

Tu proyecto es una app web (Streamlit), no de consola, así que no la alimenté con printf. Aproveché que separaste limpiamente la lógica (scheduler.py no depende de la GUI) y ejecuté tu clase Event directamente con datos reales del repo, en 16 escenarios. Además arranqué la GUI en modo headless: arranca perfecta (HTTP 200, health ok, sin ningún Traceback). Todo compila bajo Python 3.12.

Un detalle importante: tu código usa comillas dobles anidadas dentro de f-strings de comillas dobles (p. ej. scheduler.py:95). Eso solo funciona en Python 3.12 o superior (PEP 701). Tu requirements.txt dice Python>=3.10, pero en 3.10 u 3.11 el proyecto ni siquiera compila. Vale la pena alinear ese requisito.

Lo que está bien

• Separación GUI / lógica de dominio ejemplar. scheduler.py no importa streamlit; toda la lógica de reglas vive en la clase Event. Gracias a eso pude probar tu lógica en aislamiento — es una decisión de diseño madura.
• El motor de disponibilidad funciona de verdad. Verifiqué solapamiento de esclusas en el mismo carril ("Lock A1 is already in use at 2026-07-17 09:00"), agotamiento de pilotos junior con dos tránsitos concurrentes, y la sugerencia del próximo horario libre (te ofreció 15:00–22:00 justo cuando se liberaba el carril). La contabilidad hora a hora de recursos acumulativos es correcta.
• Recurrencias: se expanden bien (3 repeticiones con intervalo 2 días → fechas correctas) y validas que la serie completa no salga de la ventana de 60 días.
• Persistencia: guardar, expandir recurrencias y borrar por ID funcionan; lo probé de punta a punta.
• Datos externalizados en JSON en vez de hard-codeados. Buen instinto.

Qué mejorar

• Bug real (fácil de arreglar): en la página "Scheduled events" muestras los remolcadores con event.get("tugboat") (app.py:433 y app.py:444), pero la clave que guardas es "tugboats" en plural (app.py:286). Resultado: todo tránsito programado muestra "Tugboats: None". Cámbialo a event.get("tugboats") y queda resuelto.
• requirements.txt: declara la versión real que necesitas (3.12), no 3.10 — porque en 3.10/3.11 ni compila.
• Duplicación en validate_duration_restrictions (scheduler.py:54-72): las ramas Small/Medium/Large son idénticas salvo la clave. Puedes colapsarlas con un solo lookup restrictions_data[f"{vessel_size.lower()} vessel transit"], igual que ya haces en validate_resources_restrictions (scheduler.py:111).
• Detalle idiomático: usas type como nombre de variable (app.py:105, etc.), lo que sombrea el builtin type(); mejor event_type. Y type(x) == str se escribe idiomáticamente como isinstance(x, str).

Sobre el informe

Muy bueno: 2.710 palabras, bien escrito y honesto. Los números (recursos, duraciones por tamaño de embarcación, ventana de 60 días) coinciden exactamente con resources.json/restrictions.json. No exageras: describes las validaciones como reglas implementadas, no afirmas haberlas "probado", e incluso listas "añadir pruebas automatizadas" como mejora futura, reconociendo que no las tienes. Ese tipo de honestidad es justo lo que se busca. Enhorabuena por un trabajo cuidado y ambicioso.