[Proyecto I] Centro de Investigación Científica #322

Activity

1. apiad

   changed the title [-]Centro de Investigación Científica[/-] [+][Proyecto I] Centro de Investigación Científica[/+] on Jul 6, 2026
2. apiad commented on Jul 6, 2026

   

   apiad

   on Jul 6, 2026

   Member

   More actions

   🔧 Título corregido al formato [Proyecto I] para disparar la verificación automática.

   /revisar

   👍React with 👍1Reacted by Sabrina Socarras

   👀React with 👀1Reacted by github-actions
3. github-actions commented on Jul 6, 2026

   

   github-actionsBot

   on Jul 6, 2026 – with GitHub Actions

   More actions

   Verificación Automática — Proyecto I 🤖

   Repositorio analizado: https://github.com/SabrinaSocarras/centro-investigacion-planner

   1. Repositorio

   ✅ El repositorio es accesible y fue clonado correctamente.

   2. Informe (report.md)

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

   3. Proyecto Python

   ⚠️ Sin pyproject.toml.
   ⚠️ Sin requirements.txt.

   Archivos Python (10, 1,481 líneas en total):

   • src/cientifico.py
   • src/sistema_cientifico.py
   • src/run_app.py
   • src/experimento.py
   • src/sistema_recursos.py
   • src/planner.py
   • src/recursos_iniciales.py
   • src/recurso.py
   • src/gui.py
   • src/sistema_experimentos.py

   4. Punto de Entrada

   ⚠️ No se encontró un punto de entrada claro (main.py, app.py, etc.).

   5. Ejecución

   ⚠️ Sin punto de entrada identificado — no se intentó ejecutar.

   Resumen

   • ✅ Repositorio accesible
   • ❌ report.md con ≥2000 palabras
   • ✅ Archivos Python
   • ❌ Configuración de dependencias
   • ❌ Punto de entrada
   • ❌ Ejecución

   2/6 verificaciones pasadas.

   ---

   Verificación automática — los resultados son orientativos. El profesor revisará en detalle.
4. apiad commented on Jul 15, 2026

   

   apiad

   on Jul 15, 2026

   Member

   More actions

   🔍 Revisión de Código — Claude Code

   Repositorio: https://github.com/SabrinaSocarras/centro-investigacion-planner

   Qué hace tu proyecto

   Construiste un planificador de experimentos de laboratorio con interfaz gráfica en Tkinter: registro y login de científicos, creación de experimentos con selección de recursos, y un motor de restricciones de seguridad que valida automáticamente nivel de acceso, exclusiones entre equipos, co-requisitos de materiales radioactivos y el horario de apertura del centro. Lo más valioso: cuando hay un conflicto de horario, el sistema busca y sugiere fechas alternativas. Y todo persiste en JSON entre sesiones.

   Ejecución

   Compilé los 10 módulos (todos sin errores de sintaxis) y ejecuté directamente la lógica de negocio con tus datos reales, probando más de una docena de escenarios válidos e inválidos. La GUI no arrancó en mi entorno Linux por una sola línea: self.state("zoomed") (gui.py:36) usa un estado de ventana que solo existe en Windows — en tu máquina arranca perfectamente, no es un bug de tu lógica. Cambiando esa línea por self.geometry(...), la ventana y todos los widgets se construyen bien. Por eso el foco de la revisión fue tu motor de restricciones, que es donde está la sustancia.

   Lo que está bien

   • Arquitectura ejemplar para primer año. Separaste la lógica de negocio (Planner, tus clases Cientifico/Recurso/Experimento, y los sistema_*) de la GUI de forma tan limpia que pude ejecutar y verificar todo el núcleo sin abrir la ventana. Eso es exactamente lo que hace testeable un programa.
   • Todas las restricciones funcionan verificadas en ejecución real: nivel insuficiente → rechazado; láser + vibración → rechazado; radioactivos sin sala blindada/dosímetro → rechazado (y con ambos → aceptado); domingo → rechazado; fuera de horario → rechazado; conflicto de recurso+horario → rechazado. Todas con su mensaje correcto.
   • Persistencia bien pensada. Guardas el email del científico y los IDs de recursos en lugar de duplicar objetos, y al cargar resuelves las referencias. Es el patrón correcto (como claves foráneas) y evita datos inconsistentes.
   • Búsqueda de huecos correcta. Verifiqué que buscar_varios_huecos devuelve fechas válidas respetando horario y conflictos (ej. desde un recurso ocupado a las 09:00 me ofreció 11:00 / 11:30 / 12:00).
   • Código limpio y legible, con comentarios que explican el porqué. Por encima de la media del curso.

   Qué mejorar

   • Bug de caso límite: experimentos que cruzan la medianoche. Un experimento que empieza lunes 18:00 y dura 10h (termina martes 04:00) tu sistema lo acepta, aunque corre toda la noche con el centro cerrado. La causa está en planner.py:68: comparas fin.time() > time(hora_cierre), pero cuando el fin pasa de medianoche, fin.time() es 04:00, que es menor que 20:00, así que la validación no lo pilla. Solución: compara el datetime completo del fin contra la hora de cierre del día de inicio (o rechaza si fin.date() != inicio.date()). Fíjate que tu se_solapa_con sí usa datetime completos — es solo el chequeo de horario el que se quedó mirando solo la hora.
   • IDs de experimento no estables al recargar. Asignas el id en el constructor desde un contador de clase (experimento.py:13), así que cada vez que se re-instancian los experimentos el contador sube y los IDs cambian. En tu GUI no molesta porque cargas los datos una sola vez al arrancar, pero es frágil: ya guardas el id en el JSON (sistema_experimentos.py:69), así que sería más robusto leerlo al cargar en vez de regenerarlo.
   • Detalle defensivo: tu constructor de Cientifico avisa si el nivel no es 1/2/3 pero no lo rechaza; y textos_nivel[nivel] (gui.py:436) daría IndexError con un nivel fuera de rango. En la práctica estás a salvo porque el nivel siempre viene de los radio buttons, pero conviene tenerlo presente.

   Sobre el informe

   El informe es honesto y preciso — describe exactamente lo que hace el código, sin inventar features. La afirmación de que comparas el objeto time completo para no aceptar un experimento que termina a las 20:30 es cierta para el caso normal (lo confirmé); solo se le escapó el caso del cruce de medianoche que menciono arriba. El único pero es formal: tiene 878 palabras y la asignatura pide un mínimo de 2000. Te recomiendo ampliarlo — tienes material de sobra (podrías desarrollar decisiones de diseño, el patrón de persistencia por referencias, y ejemplos concretos de cada restricción).

   Muy buen trabajo, Sabrina. El diseño que lograste es el tipo de estructura que hace que un programa sea fácil de mantener y probar. Corrige el caso de medianoche y amplía el informe, y queda redondo. 👏