[Proyecto I] War is Coming

[cymir01]

Nombre: Cynthia Moreno Miranda
Grupo: C-122
Repositorio: https://github.com/cymir01/War-is-Coming.git

Descripción

War is Coming es un planificador de eventos bélicos ambientado en el universo de la saga A Song of Ice and Fire. Permite al usuario organizar campañas bélicas (asedios, batallas navales, asaltos, emboscadas, etc) asignando recursos limitados (unidades militares de distintas casas, personajes clave y recursos especiales) mientras respeta determinadas reglas de co‑requisito, exclusión mutua y enemistades entre casas y personajes de la saga. El sistema valida automáticamente conflictos horarios, sugiere el próximo hueco disponible en el calendario de eventos y mantiene toda la planificación en un archivo JSON, ofreciendo una interfaz de consola enriquecida con colores y tablas usando la librería rich

[cymir01]

/revisar

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/cymir01/War-is-Coming.git

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

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

3. Proyecto Python

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

Archivos Python (18, 1,096 líneas en total):

• main.py
• data/default_data.py
• tests and resources/calendar_function.py
• tests and resources/resource.py
• tests and resources/tests.py
• src/models/__init__.py
• src/models/event.py
• src/models/resource.py
• src/interface/command_delete_event.py
• src/interface/command_list_events.py
• src/interface/main_menu.py
• src/interface/__init__.py
• src/interface/command_add_event.py
• src/interface/command_view_details.py
• src/services/__init__.py
• (y 3 más)

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

╭──────────────────────────────────────────────────────────────────────────────╮
│                               ¡War is Coming!                                │
╰──────────────────────────────────────────────────────────────────────────────╯
¿Cuál es tu nombre?: Hola !. A continuación los comandos para realizar acciones:
a - agregar evento
l - listar eventos
d - eliminar evento
v - ver detalles d

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/cymir01/War-is-Coming.git

Qué hace tu proyecto

Construiste un planificador de campañas bélicas ambientado en A Song of Ice and Fire: el usuario crea eventos (asedios, batallas navales, asaltos, emboscadas, misiones diplomáticas...) asignando recursos de las distintas casas, y el sistema valida automáticamente co‑requisitos, exclusiones mutuas y enemistades entre casas, detecta conflictos de horario, sugiere el próximo hueco libre y lo persiste todo en JSON. La interfaz de consola con rich (tablas, colores, paneles) está muy cuidada. Es un proyecto ambicioso y bien resuelto para primer año.

Ejecución

Lo corrí de verdad con Python 3.12 y rich: recorrí todo el menú por consola alimentándolo con entradas simuladas, y además probé la lógica de negocio directamente para los casos difíciles. No apareció un solo Traceback en ninguna ruta, ni con entradas válidas ni con basura. Entre lo que verifiqué: agregar una Batalla campal válida, rechazar Stark + Lannister ("la casa Stark no puede aliarse con la casa Lannister"), rechazar una Misión diplomática sin Embajador, recuperarte de un año escrito como "abc", detectar un conflicto de recurso y sugerir el hueco siguiente con la hora exacta correcta (14:00–20:00 justo tras un evento de 08:00–14:00), eliminar un evento y comprobar que al reiniciar la persistencia era correcta. También armé una Batalla naval con su cuádruple co‑requisito (Almirante + Flota + Fuego valyrio + Piromante) y funcionó; al quitarle el Fuego valyrio, la rechazó bien.

Lo que está bien

• Arquitectura en tres capas real: modelos / servicios / interfaz bien separados, un archivo por comando. No es decorativo, se nota en el mantenimiento.
• Motor de restricciones parametrizado por datos: las reglas viven en default_data.json, no en el código, y se aplican por tipo de recurso. Verifiqué que funcionan en todas las combinaciones que probé (co‑requisitos de recurso y de evento, exclusiones, enemistades de casa).
• Validación de entrada muy robusta: IDs inexistentes, IDs no numéricos, fechas mal escritas, fecha fin ≤ inicio, comandos de menú desconocidos — todo se maneja con mensajes claros y re‑pregunta, sin reventar.
• Buscador de huecos correcto: la sugerencia del próximo intervalo respetó tanto los conflictos de recurso como las restricciones del dominio.
• Persistencia sólida con tildes correctas (ensure_ascii=False) y fechas en ISO.

Qué mejorar

• Argumento por defecto mutable en Event.__init__ (src/models/event.py:10): resources_ids: list = []. Es un pozo clásico de Python — ese [] se crea una sola vez y se comparte entre todos los eventos que no pasen la lista. Lo comprobé: dos Event creados sin resources_ids terminan apuntando a la misma lista. En tu programa no explota porque add_event siempre pasa una lista explícita, pero conviene arreglarlo: pon resources_ids: list = None y dentro if resources_ids is None: resources_ids = []. Lo mismo aplica a los demás parámetros por defecto que sean listas.
• Higiene del repositorio: subiste al repo .venv/ (con binarios de Windows), la carpeta .idea/ y __pycache__/. Eso no debería viajar en git — crea un .gitignore con esas entradas. El repo queda más limpio y liviano.
• Valor mágico en el buscador de huecos (src/services/planner.py:143): cuando event_type llega vacío, asumes "Batalla campal". En el flujo actual siempre le pasas el tipo real, así que no molesta, pero es frágil si algún día reutilizas la función; mejor exigir el tipo o dejarlo neutro.
• Restos de borrador: la carpeta tests and resources/ tiene código comentado (tests.py está entero comentado) y archivos duplicados. Si no son tests que corras, mejor sácalos para no confundir a quien lea el repo. Y un par de docstrings quedaron con "Workflow: 1. 2. 3." vacíos (p.ej. command_list_events.py): rellénalos o quítalos.

Sobre el informe

Tu informe es de los mejores que he revisado: coincide con el código con mucha fidelidad y, sobre todo, es honesto. Documentas bugs reales que tú misma cazaste y corregiste (el typo type vs resource_type, la indentación que solo evaluaba el último evento), distingues con claridad lo hecho de lo que dejas para el futuro (update_event_status, recursos con cantidad), y eres transparente sobre dónde te apoyaste en IA y en qué fuentes estudiaste cada cosa. Un par de matices menores: llamas al buscador de huecos "robusto que maneja todos los casos" — es funcional y lo verifiqué, pero con el valor mágico y la granularidad de 1 hora yo diría "correcto" más que "blindado"; y un ejemplo de la tabla de listar omite columnas que el código sí muestra. Detalles cosméticos que no restan a un informe excelente.

Muy buen trabajo, Cynthia. La combinación de un dominio rico, una arquitectura limpia, validación exhaustiva y un informe honesto es exactamente lo que se busca. Sigue así. 🐺