game — Copilot Instructions

• El backend está construido con NestJS y sigue la arquitectura CQRS (Command Query Responsibility Segregation). • Principio clave: Los controladores NUNCA acceden directamente a los repositorios. Toda modificación de estado (crear, editar, borrar) se realiza mediante comandos (Command) y sus handlers (CommandHandler), usando el CommandBus. • Las queries (lecturas) se gestionan con QueryBus y sus respectivos handlers. • Los comandos encapsulan la intención de modificar el estado y reciben los datos necesarios (por ejemplo, el usuario autenticado y el id del recurso). • Los handlers de comandos son responsables de: • Verificar permisos (por ejemplo, user.isAdmin() o usando el PermissionsService). • Llamar al repositorio correspondiente para realizar la acción. • Lanzar excepciones si no hay permisos o el recurso no existe. • Los comandos y handlers deben estar registrados en commands.module.ts y exportados en core/application/commands/index.ts. • Los endpoints de los controladores sólo deben instanciar el comando y ejecutarlo con el CommandBus, devolviendo la respuesta adecuada (por ejemplo, { success: true }). • El backend expone una API REST que es consumida por el frontend.

• El frontend está construido con Angular y estructurado en módulos, servicios y componentes reutilizables. • El panel de administración permite crear, editar y borrar sets, items y places. • Cada card de administración tiene un botón rojo de borrar, que muestra una confirmación nativa (window.confirm) antes de proceder. • Si el usuario confirma, se llama al método de borrado del servicio correspondiente (deleteItem, deleteSet, deletePlace), que hace un fetch DELETE al endpoint REST. • Tras borrar, se refresca la lista de resultados para reflejar el cambio. • El frontend espera respuestas { success: true } tras un borrado exitoso.

• Frontend: • El usuario ve una lista de sets, items y places en el admin. • Cada card tiene un botón rojo de borrar, que muestra un window.confirm antes de proceder. • Si se confirma, se llama al método de borrado del servicio correspondiente, que hace un fetch DELETE al endpoint REST. • Tras borrar, se refresca la lista. • Backend: • Los endpoints DELETE de los controladores (items.controller.ts, set.controller.ts, places.controller.ts) NO acceden al repositorio directamente, sino que crean y ejecutan un comando de borrado (por ejemplo, DeleteItemCommand) usando el CommandBus. • Cada comando tiene su handler (DeleteItemHandler, etc.) que: • Verifica permisos (isAdmin() o usando el PermissionsService). • Llama al método delete del repositorio correspondiente. • Lanza excepciones si no hay permisos o el recurso no existe. • Los comandos y handlers están registrados en commands.module.ts y exportados en core/application/commands/index.ts.

• Todos los deletes en el backend son soft delete: los recursos tienen un campo deletedAt (fecha). • Para considerar un recurso como "no borrado", en los métodos de búsqueda o listados (find/search/getAll) se debe filtrar por deletedAt: null o por fecha superior a la actual (si aplica). • Nunca mostrar ni operar sobre recursos con deletedAt no nulo (o en el pasado). • El método delete de los repositorios debe marcar el recurso con la fecha actual en deletedAt, no eliminarlo físicamente. • Los handlers de borrado deben usar este mecanismo. • Los listados y búsquedas deben filtrar correctamente.