Crear un emulador local de la nube que funcione con los SDK y CLI oficiales

## Igualar los formatos de solicitud y respuesta de la nube real antes que buscar atajos Priorice: 1. la compatibilidad con el protocolo de nube de la plataforma de origen; 2. el comportamiento que esperan los clientes SDK y CLI oficiales; 3. la reutilización de patrones existentes del emulador; 4. la corrección por encima de la comodidad; 5. los cambios acotados y comprobables. No añada estructuras de endpoint personalizadas ni simplifique los formatos de solicitud y respuesta para facilitar la implementación. No realice una refactorización amplia salvo que el comportamiento solicitado la requiera. Antes de editar, identifique el servicio, su función en el plano de control o el plano de datos, la familia de protocolos, la implementación existente que se debe tomar como modelo, el impacto en la configuración, el almacenamiento y la documentación, y el plan de pruebas útil más reducido. Cuando el comportamiento no esté claro, dé prioridad al contrato de la plataforma de origen, después al comportamiento consolidado del emulador y, por último, a las expectativas de la batería de compatibilidad. Si la tarea exige un cambio arquitectónico entre servicios, exponga las ventajas y desventajas en lugar de refactorizar a ciegas. ## Mantener ligeros los controladores de protocolo y poner la lógica de negocio en los servicios Utilice un diseño de servicios por capas: - los controladores o manejadores analizan la entrada del protocolo y producen respuestas compatibles con él; - los servicios contienen la lógica de negocio y lanzan la excepción compartida del dominio de nube; - los modelos representan los datos del dominio; - los registros, la configuración, las fábricas de almacenamiento, los servicios del ciclo de vida, los analizadores, los constructores y los asignadores de excepciones proporcionan la infraestructura compartida. Mantenga los controladores ligeros. Reutilice las utilidades compartidas y reproduzca la estructura del servicio consolidado más cercano antes de introducir un patrón nuevo. Canalice los fallos del dominio mediante el tipo de excepción compartido. Los flujos de consulta y XML deben usar el asignador de excepciones estándar; los flujos de protocolos JSON deben devolver el cuerpo de error estructurado requerido. Los tipos de retorno de los controladores deben seguir siendo compatibles con las restricciones de reflexión de compilación anticipada y serialización. Utilice inyección mediante constructor, llaves en las condiciones y código que se explique por sí mismo. Nunca deje vacío un bloque `catch`; si se tolera una excepción de forma intencionada, registre contexto suficiente para diagnosticarla. ## Confirmar el protocolo real de cada servicio antes de añadir una operación Determine el protocolo de comunicación real antes de añadir una operación: - los protocolos de consulta utilizan acciones codificadas como formulario y respuestas XML; - los protocolos de tipo JSON RPC utilizan una cabecera de destino y JSON estructurado; - REST JSON y REST XML utilizan rutas de recursos con su formato de cuerpo nativo; - los servicios del plano de datos pueden requerir proxies TCP nativos en lugar de API de administración HTTP. Utilice el constructor y el analizador XML compartidos, así como las constantes de espacio de nombres. Nunca analice XML con expresiones regulares. Mantenga los errores JSON alineados con la estructura de errores del protocolo de destino. Algunos servicios ofrecen más de una ruta de compatibilidad. Mantenga alineados los manejadores alternativos y pruébelos en conjunto. Trate los endpoints de descubrimiento de identidad conforme a su protocolo abierto real, en lugar de forzarlos a seguir el modelo de la API de administración. Valide las API de administración mediante clientes SDK oficiales, no solo con solicitudes HTTP elaboradas manualmente. Que se acepte una carga útil manual no demuestra la compatibilidad de la serialización del cliente, las cabeceras, los errores, la paginación ni la generación de URL. ## Actualizar siempre juntos los modos de almacenamiento y los archivos de configuración Implemente el almacenamiento mediante la fábrica compartida y los modos declarados; nunca cree una instancia de una implementación de almacenamiento directamente dentro de un servicio. Respete los enlaces del ciclo de vida para la carga, el vaciado, los puntos de control o el comportamiento de escritura anticipada. Cuando los valores predeterminados de la interfaz difieran de los valores desplegados, trate el archivo de configuración de ejecución del repositorio como la fuente de verdad efectiva. Para el comportamiento relacionado con el almacenamiento: 1. actualice la interfaz de configuración canónica; 2. actualice la configuración principal de ejecución; 3. actualice la configuración de pruebas; 4. conecte el modo mediante la fábrica de almacenamiento; 5. verifique la integración con el ciclo de vida. Para cualquier configuración orientada al usuario, actualice también la documentación y siga la convención establecida para nombrar variables de entorno. Revise la URL base, el nombre de host, los valores predeterminados de región y cuenta, los intervalos de puertos, las raíces de persistencia y la red de contenedores cuando afecten a los identificadores o endpoints generados. Añada campos nuevos de forma compatible y mantenga sincronizados la configuración compartida, el almacenamiento y el registro de servicios. ## Probar la compatibilidad con los SDK oficiales, no con solicitudes manuales Utilice pruebas unitarias para el comportamiento aislado de los servicios y pruebas de integración para el manejo de protocolos, la persistencia y el estado visible para el cliente. La ejecución ordenada de pruebas de integración solo es aceptable cuando el comportamiento es intencionadamente con estado. Cualquier cambio en el análisis, la estructura de las respuestas, los errores, la semántica de persistencia, la generación de URL, la habilitación de servicios o las rutas de protocolos alternativas requiere cobertura automatizada. Durante la iteración, ejecute primero una prueba específica y después la batería directamente relacionada. Utilice el proyecto de compatibilidad cuando un cambio pueda afectar al comportamiento real de los SDK. Prefiera las aserciones basadas en SDK a las solicitudes HTTP sin procesar y documente cualquier desviación intencionada respecto a la plataforma de origen. Cuando las rutas de protocolos alternativas ofrezcan la misma operación, compruebe que su semántica sea equivalente. Cuando el estado persista, verifique el comportamiento de carga y vaciado en los modos de almacenamiento pertinentes. No afirme que existe compatibilidad basándose únicamente en solicitudes manuales. Si el comportamiento cambió sin cobertura automatizada, explique qué prueba falta y por qué no se pudo añadir. ## Terminar por completo cada servicio nuevo sin cambiar de paso el flujo de publicación Al añadir un servicio, cree su controlador, servicio y modelos; regístrelo; añada la configuración canónica y la de pruebas; conecte el almacenamiento mediante la fábrica; añada pruebas; y actualice la documentación. Antes de terminar: - ejecute las pruebas pertinentes y las comprobaciones de compatibilidad de protocolos; - confirme que no se hayan introducido endpoints personalizados ni formatos de comunicación creados por comodidad; - verifique las actualizaciones de configuración, almacenamiento, ciclo de vida y documentación; - compruebe la coherencia de las URL y los identificadores de recursos generados; - mantenga los registros estructurados y sin ruido en las rutas críticas. Mantenga enfocadas las solicitudes de incorporación de cambios, conserve el comportamiento existente salvo que el cambio sea explícito y separe las refactorizaciones no relacionadas. Utilice tipos de commit convencionales y atribución exclusiva a personas. Trate las ramas de publicación, las etiquetas y los flujos de publicación como infraestructura crítica. Una incorporación a la rama de desarrollo no demuestra por sí sola que una publicación sea estable. No altere de forma incidental el comportamiento de publicación al implementar la funcionalidad del servicio.