Ola 0 · Sebas 0.1: conectar el guard de aceptación única

[heysebitas]

Tarea 0.1 · va sobre #12, mergear ese primero.

El problema

RoutingStore.respond() ya tenía idempotencia por requestKey, verificaba accepted_destination y bajo Postgres usa pg_advisory_xact_lock + select … for update. Estaba bien hecho y no lo llamaba nadie.

La ruta que acepta de verdad es POST /handshake/respond, que solo miraba el estado de ese handshake y nunca preguntaba si otra sede ya aceptó el caso. Lo que tapaba el hueco era que el fan-out es secuencial. El día que alguien active fan-out paralelo —la optimización obvia— dos hospitales preparan cama para el mismo paciente.

Qué trae

• HandshakeService inyecta RoutingService y reserva el destino antes de escribir la aceptación. requestKey = handshakeId + decisión, para que el doble toque siga siendo idempotente.
• Si el guard rechaza: aplicada: false + codigo, el handshake no se toca (sigue enviado y vence solo) y la sede perdedora no suma una aceptación que nunca ocurrió a su P(aceptación).
• RespondResponse.codigo (opcional, espejado): el caso que importa no se ve en handshake.estado. Telegram y /hospital ahora dicen "otra sede ya aceptó este caso · no prepare cama" en vez de "ya estaba enviado".

Dos decisiones que quiero que miren

1. No llamo RoutingService.respond() directo. Exige evidencia de despacho para ese destino, y la sede que acepta casi nunca es la Init sdd config #1 del ranking (el fan-out toca varias, el vigilante re-rutea). Encadenar la reserva a esa precondición dejaba la carrera abierta justo cuando hay varias sedes tocadas. Agregué aceptarDestino(): mismo store.respond —el guard es uno solo, no dupliqué nada—, adjunta evidencia si existe. respond() sigue exigiéndola y ahora delega ahí.
2. RoutingResponseCommand.evidence pasó a opcional. Sin evidencia se reserva igual pero no se escribe fila de auditoría: los checks de pulso_routing_decision_audit exigen modelVersion/configVersion y rellenarlos sería falsificar el acta. El hueco queda declarado en el log.

Hecho cuando

• Dos sedes aceptan el mismo caso → la segunda recibe aplicada: false
• El doble toque sigue siendo idempotente
• El webhook de Telegram no dice "aceptado" cuando no se aplicó
• Test de concurrencia real, no secuencial

Verificado que el test detecta la ausencia del guard: desconectándolo fallan 4 de 14 tests de handshake; conectado pasan los 14. El de concurrencia pone dos procesarRespuesta en vuelo a la vez con frontera asíncrona en el store, así que ambas pasan el chequeo de estado antes de que ninguna reserve. La concurrencia entre procesos ya la cubre postgres-routing.store.spec.ts, que necesita PULSO_TEST_DATABASE_URL — se enciende en 1.7.

🤖 Generated with Claude Code