Propiedades que cambian de dueño o de estado

El estado de una reserva no es un dato que se escribe: es el resultado de algo que pasó. Pasa a confirmada porque la pasarela confirmó un pago; pasa a asistida porque un torniquete leyó un carné. Cada transición tiene su disparador, su comprobación y sus efectos (devolver una clase, sumar puntos). Lo mismo vale para el dueño: traspasar una reserva exige verificar a las dos personas.

Cuando esas propiedades entran en una edición genérica, la transición se salta su regla. Por eso se sacan de la edición y cada cambio tiene su propia operación, que comprueba que el estado de partida admite el cambio y que quien lo pide tiene derecho a hacerlo. Es la autorización a nivel de propiedad: el mismo campo puede ser legítimo para recepción y prohibido para el socio.

Abre el laboratorio, entra en la carpeta pulsoandino-reservas y lee ReservaController.php. El controlador busca la reserva entre las del propio socio, así que una ajena da 404: la comprobación del objeto está bien. El problema está en ActualizarReservaRequest.php, que admite como editables el dueño y el estado, y en que validated() devuelve justo esos campos. Ahora compara flujo-reservas.txt con auditoria-reservas.txt: cada transición tiene un origen esperado.

El comentario de la regla dice que el dueño es editable «porque lo necesita recepción», pero recepción tiene su propia ruta. Busca un cambio de dueño que no venga de esa ruta.

Según el flujo, solo el torniquete marca una asistencia, y cada asistencia suma 10 puntos. Cruza puntos.txt con la auditoría y mide cuántos puntos se otorgaron por asistencias que no marcó un torniquete.

El arreglo tiene que conservar lo que funciona (la búsqueda de la reserva entre las del socio) y quitar del camino genérico lo que es una operación del negocio.