Las pruebas del cliente verifican que el CRM se comporta bien contra el EFC que el
cliente CREE que existe. Si EFC renombra una ruta o una clave del payload, esas
pruebas siguen verdes y el carril se rompe en produccion: los dos repos se despliegan
por separado y nada obliga a que sus mitades evolucionen juntas.
Se agrega el contrato como dato -tests/contracts/efc_crm_contract.json- y su
afirmacion del lado CRM: que cada operacion del cliente pegue en la ruta declarada,
que el alta de expediente mande exactamente las claves acordadas -ni una de mas, que
el serializer de EFC ignoraria en silencio, ni una de menos-, que la subida vaya en
multipart con sus campos, que toda peticion lleve el header de autenticacion, que el
code que dispara el ensure-then-upload siga siendo el mismo, y que las rutas del API
de usuario registradas sean exactamente las del contrato en las dos direcciones.
Fija tambien dos invariantes que ya costaron decisiones: que la respuesta de un
documento nunca exponga la copia local -se borra al confirmar la entrega, asi que
seria una referencia que va a dejar de existir- y que el cliente NO tenga metodo de
borrado hacia EFC, para que nadie lo llame "porque estaba ahi".
EFC debe afirmar su mitad contra una copia identica de este JSON cuando aterricen sus
fases 1-4; mientras tanto, el lado del CRM ya no puede derivar en silencio.
Refs: T2026-08-046 (verificacion 15.2)
marcos
a1ed6e518d