Desarrolla una plataforma de automatización multiinquilino sin mezclar inquilinos ni ediciones

## Separa los datos de cada inquilino y deja el código prémium fuera de la edición comunitaria Trata el ámbito de cada inquilino, las ediciones del producto, el acceso a funciones y la identidad visual como contratos de seguridad y comportamiento. ### Impón el aislamiento - Modela explícitamente la propiedad en los niveles de plataforma, proyecto y usuario. - Limita cada consulta a la base de datos con el identificador correcto del proyecto o de la plataforma; nunca dependas de que quien llama filtre los resultados después. - Exige una declaración de control de acceso en cada endpoint. - Aplica la autorización del backend y el middleware de funciones antes del comportamiento protegido, devuelve la respuesta estándar `402` para las funciones de pago no disponibles y refleja la misma restricción en el guard del frontend y en la habilitación de consultas. ### Mantén una dirección entre ediciones - Permite que las ediciones prémium o alojadas amplíen el núcleo comunitario mediante hooks o interfaces registrados. - Nunca importes código de aplicación exclusivo de la edición prémium en el código comunitario. - Mantén los valores predeterminados de la edición comunitaria sin una marca específica, aplica la identidad visual configurada en entornos alojados y restringe la identidad visual empresarial autoalojada según la capacidad correspondiente del plan. - Verifica el comportamiento de cara al cliente en 5 rutas: edición comunitaria autoalojada, edición empresarial autoalojada, edición alojada gratuita, edición alojada de pago y edición empresarial alojada. - Haz que todos los nombres, colores, logotipos, pantallas de inicio de sesión y mensajes de cara al cliente procedan de la apariencia configurada, en vez de codificar la marca del producto de forma fija. ## Declara las dependencias en cada espacio de trabajo y bloquea los datos compartidos entre servidores Haz explícitas la propiedad de las dependencias y la conducta concurrente de los datos para que el éxito local coincida con el despliegue en producción. ### Mantén los límites de los paquetes - Ordena las bibliotecas compartidas desde bases ligeras e independientes del framework hasta paquetes pesados del nivel de aplicación. - Permite que las integraciones reutilizables y los motores de ejecución dependan solo de paquetes ligeros; expón el comportamiento necesario de la aplicación mediante una capa de framework estrecha. - Declara cada dependencia de ejecución en el espacio de trabajo que la importa y cada dependencia de pruebas o herramientas en las dependencias de desarrollo de ese espacio de trabajo. - Reserva el manifiesto raíz para herramientas de todo el repositorio o verdaderos requisitos de arranque. - Fija las versiones de forma coherente y actualiza el archivo de bloqueo con el instalador canónico después de cambiar dependencias. ### Protege la persistencia y la concurrencia - Registra explícitamente las entidades nuevas cuando el mapeador de objetos no las detecte automáticamente. - Separa los efectos secundarios en módulos específicos e invócalos explícitamente después de que las mutaciones concluyan correctamente. - Para tareas con varios servidores, usa un bloqueo distribuido, deduplicación de colas o bloqueo de filas con semántica `skip-locked`. - Evita extensiones de base de datos que no estén disponibles en los servicios administrados. - Sanea los objetos suministrados desde el exterior antes de almacenarlos en la base de datos. ## Evita any y las conversiones de tipo forzadas, y usa los helpers compartidos del proyecto Usa interfaces, flujo de datos, organización de archivos y utilidades compartidas que sean predecibles. ### Conserva la integridad de los tipos - No uses `any`; usa tipos exactos o `unknown` con guards de tipo. - No fuerces los valores mediante conversiones de tipo. Corrige el tipo de origen, añade validación o estrecha el tipo del valor. - Consulta la documentación de la biblioteca antes de usar una API y sustituye todo lo marcado como obsoleto. - Usa un único parámetro de objeto desestructurado en toda función con más de 1 parámetro. - Prefiere un flujo de datos inmutable entre funciones; crea y devuelve colecciones nuevas en lugar de modificar objetos que pertenecen a quien llama. ### Explicita las convenciones - Usa los helpers de resultado compartidos del proyecto para gestionar errores síncronos y asíncronos. - Convierte los mensajes de validación para usuarios en claves de localización; usa claves compartidas para errores comunes de formularios y crea claves nuevas cuando sea necesario. - Tras comprobar la rama actual, incrementa la versión de parche de un paquete compartido para correcciones o incorporaciones compatibles y su versión menor para nuevas exportaciones o comportamientos. - Define los helpers no exportados como funciones independientes, coloca primero la lógica ejecutable y agrupa al final las constantes y los tipos exportados, sin intercalarlos con la lógica. - Comenta por qué existe una decisión, no qué hace un código que ya se explica por sí mismo. - Exporta varias utilidades sencillas mediante 1 objeto con nombre y conserva los componentes React como exportaciones con nombre. ## Envía el HTTP saliente por el cliente seguro para evitar SSRF y sigue las reglas de la API Aplica semántica explícita para las solicitudes y clientes de red seguros en cada límite no confiable. ### Estandariza los endpoints - Usa `POST` para todas las mutaciones de creación y actualización, y `DELETE` para eliminar; nunca uses `PUT` ni `PATCH` cuando el contrato de la API los excluya. - Proporciona a cada endpoint una configuración explícita de acceso de seguridad. - Usa los identificadores, tipos de error, bases de esquemas, helpers de colecciones y saneadores de base de datos canónicos en lugar de volver a implementarlos. ### Evita la falsificación de solicitudes del lado del servidor - Dirige las solicitudes HTTP salientes de los componentes del servidor a través del cliente seguro aprobado. - Nunca uses `fetch` sin envoltura ni una fábrica de clientes sin restricciones para URL procedentes de entradas del usuario, configuraciones de administración, endpoints OAuth o integraciones de terceros. - Conserva el filtrado de direcciones privadas, de bucle invertido y de metadatos de la nube. - Mantén la conversión de tipos, la validación de URL y el saneamiento de objetos externos en el límite. ### Trata las migraciones como cambios controlados - Lee el manual de migraciones del repositorio antes de crear o modificar una migración. - Sigue el proceso documentado de generación y estructura en lugar de inventar la disposición de la migración. - Mantén las migraciones compatibles con el entorno de base de datos administrada admitido. ## Muestra el diálogo de error global solo cuando fallan los datos principales de la página Muestra los fallos globales de consultas solo cuando los datos que han fallado sean esenciales para la página actual. ### Clasifica las consultas por impacto - Configura el indicador de metadatos de la consulta que activa el diálogo de error global para datos principales de la página, como filas de tablas o listas principales. - No lo habilites para datos auxiliares como indicadores de funciones, metadatos, búsquedas individuales, opciones de filtro o detalles del usuario. - Usa esta regla de decisión: muestra el diálogo si, de otro modo, el fallo dejaría una página en blanco sin explicación o una vista principal vacía. - Permite que las consultas menores fallen silenciosamente cuando la interfaz circundante siga siendo útil. - Mantén deshabilitadas las consultas restringidas por funciones hasta que la capacidad correspondiente del plan esté disponible. ## Prueba el aislamiento entre inquilinos y cada edición con el gestor de tareas del monorepositorio Ejecuta pruebas específicas mediante el gestor de tareas canónico del monorepositorio y verifica las rutas que difieren según la edición. ### Ejercita el código y los datos - Ejecuta pruebas unitarias para el código compartido y de ejecución, y pruebas de integración para el comportamiento de la API. - Usa los helpers estándar del entorno de pruebas y del contexto de solicitudes para que la autenticación y el enrutamiento coincidan con el comportamiento en producción. - Garantiza que los datos de pruebas estén aislados y se limpien entre pruebas. - Añade pruebas de concurrencia cuando el código use bloqueos, deduplicación o selección de base de datos con `skip-locked`. - Prueba el aislamiento entre inquilinos demostrando que no se pueden devolver datos de otro proyecto o plataforma. ### Usa los comandos admitidos - Ejecuta el comando obligatorio del repositorio para comprobar y corregir el lint antes de considerar que la tarea está completa. - Usa el gestor de tareas configurado del monorepositorio y los comandos que filtran paquetes; no invoques un sistema de compilación ajeno. - Cuando un frontend alojado apunte a un backend remoto, evita los flujos OAuth que redirijan al dominio alojado; usa credenciales que no redirijan o un backend completamente local. - Verifica las restricciones de edición, la identidad visual, los límites y la disponibilidad de funciones en todas las rutas admitidas. ## Etiqueta el cambio y termina solo cuando pasen las comprobaciones obligatorias Usa documentación de funciones, etiquetas y comprobaciones finales para que el cambio sea comprensible y se pueda publicar. ### Prepara la implementación - Antes de modificar una función, lee su documentación específica sobre entidades, servicios, flujos de datos y restricciones de integración. - Mantén breves las reglas críticas de seguridad transversales y sepáralas de los flujos de trabajo paso a paso de la función. - Revisa los manifiestos de dependencias, el registro de entidades, los filtros de inquilinos, las importaciones entre ediciones, las declaraciones de acceso y el orden de los efectos secundarios. ### Prepara la contribución - Aplica exactamente 1 etiqueta principal de cambio que distinga una función, una corrección de errores o un cambio interno exento del registro de cambios. - Añade una etiqueta separada del área de integración cuando el cambio afecte a una integración de terceros o del núcleo. - Confirma que el archivo de bloqueo, la versión del paquete, las claves de localización, las pruebas y los artefactos generados coincidan con la implementación. - Ejecuta las comprobaciones obligatorias de lint, pruebas y seguridad, e informa de cualquier comprobación que no se haya podido ejecutar. - No declares la finalización hasta que la diferencia final y los resultados de la verificación la respalden.