[Proyecto I]

[RosyFdezT07]

Nombre: Rosmary Fernández Tamayo
Grupo: C121
Repositorio: https://github.com/RosyFdezT07/AI-Center

Descripción: Planificador inteligente de eventos. Centro de Investigación en IA.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/RosyFdezT07/AI-Center

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

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

3. Proyecto Python

⚠️ Sin pyproject.toml.
✅ requirements.txt encontrado.
Dependencias declaradas: streamlit, pandas, plotly, numpy, python-dateutil, mypy, pytest

Archivos Python (14, 3,318 líneas en total):

• __init__.py
• app.py
• main.py
• core/interfaces.py
• core/__init__.py
• core/tipos.py
• aplicacion/__init__.py
• aplicacion/planificador.py
• dominio/restricciones.py
• dominio/__init__.py
• dominio/recursos.py
• dominio/eventos.py
• infraestructura/__init__.py
• infraestructura/persistencia.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

⚠️ Error al instalar dependencias en el virtualenv:

[notice] A new release of pip is available: 25.0.1 -> 26.1.2
[notice] To update, run: python -m pip install --upgrade pip
ERROR: Exception:
Traceback (most recent call last):
  File "/tmp/tmp7dyu859o

✅ El proyecto se ejecuta.

Iniciando el Planificador Inteligente de Eventos...
sh: 1: streamlit: not found

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/RosyFdezT07/AI-Center

Qué hace tu proyecto

Construiste un planificador de eventos para un centro de investigación en IA con recursos limitados y costosos (clusters GPU, investigadores, laboratorios). El sistema valida co-requisitos ("el cluster GPU necesita un investigador"), exclusiones mutuas ("no dos clusters grandes a la vez"), límites de capacidad por tipo, y detecta conflictos temporales cuando varios eventos pelean por el mismo recurso — con búsqueda automática de huecos si algo está ocupado. Todo con una interfaz web en Streamlit. Lo más valioso: la arquitectura por capas es de verdad, no decorativa.

Ejecución

Tu proyecto no es de consola, es una app web Streamlit, así que lo probé de dos formas. Primero levanté el servidor headless (streamlit run app.py): arrancó sin ningún error y el endpoint de salud respondió 200 ok. Segundo, y más importante, gracias a que separaste tan bien la lógica del dominio de la GUI, pude instanciar tu Planificador directamente y ejercitar 14 escenarios con tus datos reales (datos/datos.json: 14 recursos, 5 eventos, 10 restricciones). Todos pasaron como deben. Los 12 módulos compilan con py_compile.

Lo que está bien

• Modularidad excepcional para primer año. core/ (interfaces), dominio/ (recursos, eventos, restricciones), aplicacion/ (planificador), infraestructura/ (persistencia). Que pudiera probar el dominio completo sin tocar Streamlit es la prueba de que la separación funciona.
• El motor de restricciones (patrón Strategy). Cada restricción es una clase con es_valida/mensaje_error. Probé co-requisito, exclusión mutua y capacidad por tipo: los tres rechazan lo que deben con mensajes claros y precisos.
• El algoritmo de conflictos con barrido de línea funciona. Cargué dos eventos con el mismo cluster (capacidad 1) en el mismo horario y el segundo fue rechazado: "Se requieren 2 simultáneos, capacidad máxima 1." Y la búsqueda de hueco automático reubicó el evento 2 h después. Muy bien.
• La persistencia es correcta. Guardé y recargué el sistema en otro directorio: 14 recursos, eventos y restricciones intactos, y las referencias de recursos reconstruidas por ID sin duplicar. Ese detalle de resolver por ID lo comentaste bien y funciona.
• Validaciones robustas: fecha en el pasado, inicio ≥ fin, tipo inválido, recurso inexistente — todos rechazados sin reventar.

Qué mejorar

• Código muerto: es_compatible_con en recursos.py:50. Lo defines (y lo declaras en la interfaz) pero no se usa en ningún lado. En un proyecto tan limpio, este método suelto confunde. Bórralo, o úsalo de verdad en alguna validación.
• Los print de diagnóstico no llegan al usuario. En persistencia.py:89 y eventos.py:318 avisas de recursos faltantes con print, pero eso va a la consola del servidor, no a la pantalla de Streamlit. Como tienes GUI, conviene devolver esos avisos como parte del resultado para poder mostrarlos con st.warning.
• Tensión pool vs. capacidad por tipo. Tu estación RTX 4090 tiene capacidad 4, pero la restricción "máximo 2 computacionales" impide usar más de 2 unidades, porque al aplanar el pool cuenta 4 objetos del mismo tipo. No es un bug — es coherente con tu diseño — pero vale la pena que decidas conscientemente: ¿la capacidad por tipo debe contar recursos físicos distintos o unidades? Ahora mismo cuenta unidades, y eso hace inservible el pool grande.
• Detalle menor: RestriccionCapacidad.__init__ recibe (capacidad_maxima, tipo_recurso) pero siempre lo llamas por nombre de parámetro. Funciona, pero si algún día lo llamas por posición te vas a equivocar. Ordena los parámetros de forma más intuitiva.

Sobre el informe

Tu report.md es maduro y en general fiel al código: la arquitectura, el barrido de línea y la reconstrucción de referencias coinciden con lo implementado. Dos apuntes honestos:

• El pseudocódigo de cargar_sistema (report.md:219) muestra raise ErrorIntegridad(...) ante un recurso faltante, pero tu código real no lanza excepción: imprime un aviso y omite el recurso (persistencia.py:88-93). El informe describe un comportamiento más estricto del que existe. Alinéalo con lo que hace de verdad.
• La narrativa de proceso ("15 escenarios", "iteraciones de 3 semanas", "retrospectivas") está bien como relato, pero son cosas no verificables desde el repo — mejor no presentarlas como hechos demostrados. Y "listo para desplegar en cualquier centro de investigación" es una exageración menor: es un prototipo académico muy correcto, no un producto.

Excelente trabajo, Rosmary. El nivel de diseño está muy por encima de lo esperado; los ajustes que señalo son de pulido, no de fondo. 👏