Cambiar un monorepo autoalojado de automatización de certificados sin exponer secretos

## Entender el ciclo de vida de los certificados y los secretos que guarda el sistema Trata el sistema como un producto privado y autoalojado que gestiona la solicitud, renovación, implantación, supervisión y notificación de certificados, así como las integraciones mediante API. Su pipeline principal puede solicitar certificados a través de ACME, completar una validación DNS-01, HTTP-01, mediante proxy CNAME o específica de un proveedor, exportar formatos como PEM, PFX, DER, JKS y P7B, e implantar en servidores, proxies, clústeres, CDN, servicios en la nube o paneles de control. El sistema almacena certificados, credenciales de proveedores en la nube, datos de SSH, claves de API y otras configuraciones sensibles. Nunca expongas datos locales ni secretos en cambios del código fuente, logs, fixtures, capturas de pantalla, informes o metadata generada. ## Mantener separados los workspaces del monorepo y no tocar los datos de ejecución Usa el package manager, la definición de workspace y el lockfile designados por el repositorio; no introduzcas lockfiles de otro package manager. Si un paquete constituye un workspace independiente de control de versiones, inspecciona su estado y su diff desde el interior de ese workspace y mantén sus cambios separados de los del repositorio raíz. No modifiques ni incluyas en commits datos de runtime, logs, resultados temporales, metadata generada, distribuciones o manifiestos de plugins exportados, salvo que la tarea los señale explícitamente como objetivo. Puedes inspeccionar en modo de solo lectura un directorio de dependencias de runtime cuando sea necesario comprender un SDK instalado dinámicamente, pero ese directorio no es código fuente y no debe entrar en el conjunto de cambios. ## Poner cada cambio en el paquete o plugin responsable Determina la responsabilidad antes de editar: los clientes de protocolo son responsables del comportamiento de las cuentas, órdenes y desafíos; los paquetes del pipeline, de los modelos de ejecución y los ciclos de vida de las tareas; los módulos del servidor, de las entidades, servicios, controladores, permisos y migraciones; los módulos del cliente, de las vistas, formularios, rutas y adaptadores de API; y los plugins de proveedores, del comportamiento de DNS, implantación y notificación específico del proveedor. Mantén los defectos de un único proveedor dentro del plugin de ese proveedor. Traslada un comportamiento al núcleo del pipeline o a una biblioteca compartida de plugins solo cuando represente una semántica reutilizable que deba ser coherente entre varios proveedores. Prefiere los módulos, servicios, componentes y patrones de plugins establecidos frente a implementaciones paralelas. ## Usar los comandos de cada paquete sin instalar dependencias de más Lee los comandos documentados antes de ejecutar una validación. Usa los comandos de pruebas unitarias, lint, formato y build propios del paquete afectado, y amplía la comprobación únicamente cuando el cambio cruce claramente los límites de varios paquetes. No sustituyas la validación por archivo admitida por una comprobación de tipos que se sabe defectuosa ni por un script de prueba provisional. No instales dependencias de forma preventiva. Si la falta de dependencias, los requisitos del terminal o el acceso a la red impiden una comprobación necesaria, detén ese intento e informa de la limitación del entorno. Cuando el comportamiento de un SDK dependa de la versión, inspecciona la dependencia de runtime instalada realmente y la documentación incluida con ella, en lugar de confiar en la memoria o en otra versión. ## Escribir código legible con pasos con nombre y comentarios que expliquen el porqué Da prioridad a la legibilidad frente a una sintaxis compacta. Divide las condiciones complejas, los ternarios anidados, las cadenas largas, los objetos inline y las llamadas a helpers en varias capas en valores intermedios con nombres claros o en métodos enfocados. No coloques una llamada a un método directamente dentro del argumento de otro cuando una variable local significativa pueda mostrar la transición. Usa parámetros de objeto cuando, de otro modo, un método necesitaría más de tres argumentos. Explica mediante comentarios por qué existen las reglas de negocio, las restricciones de compatibilidad, los detalles del protocolo y los riesgos ocultos. Mantén local la lógica pequeña, pero extrae reglas de negocio, conversiones de campos, comprobaciones de permisos, selección de repositorios, propagación de transacciones o cálculos recurrentes cuando sus copias deban permanecer sincronizadas. ## Escribir primero una prueba que falle y luego hacer el arreglo más pequeño Añade pruebas unitarias enfocadas para el comportamiento empresarial principal. Ante una nueva funcionalidad o la corrección de un defecto, empieza preferentemente por una prueba que reproduzca el comportamiento esperado y falle antes de la implementación; después, realiza el cambio mínimo y vuelve a ejecutar la prueba del paquete. Si una prueba añadida posteriormente exigiera cambiar un comportamiento establecido, confirma antes de modificarlo que se trata de un defecto y no de un requisito vigente. Coloca las pruebas unitarias puras cerca del código fuente y mantenlas fuera de los builds de producción. Usa una herramienta adecuada de mocking de módulos para imports ESM estáticos, en lugar de reestructurar el código de producción solo para la prueba. Define explícitamente el entorno de pruebas unitarias del paquete y ejecuta builds más amplios únicamente cuando el impacto entre paquetes los haga necesarios. ## Añadir migraciones SQL a los cambios de tablas y pasar bien las transacciones Acompaña cada cambio de estructura de tablas con una migración SQL explícita; nunca dependas de la sincronización de schemas del ORM. Convierte las claves temporales de subida mediante el servicio de archivos aprobado antes de almacenarlas de forma permanente y conserva el propietario requerido y la visibilidad pública o privada. Para propagar una transacción, pasa un contexto que contenga el transaction manager opcional antes del objeto de solicitud y usa los helpers compartidos de repositorio y transacciones. No añadas contexto de transacción a consultas sencillas ni a funciones puras. Crea los predicados opcionales de tenant o proyecto con el helper de consultas canónico, de modo que los valores null o undefined no puedan convertirse en una condición de igualdad no válida. Evita nombres y firmas de métodos de servicio que entren en conflicto con métodos base heredados. Elige nombres específicos que conserven el contrato base y hagan explícito el alcance de la operación. ## Crear pantallas de administración con el framework CRUD y los diálogos de formulario existentes Localiza la vista de la funcionalidad responsable y su módulo de API antes de editar. Usa el framework CRUD aprobado para la administración rutinaria, la búsqueda de registros y la gestión mediante tablas. Crea una lista personalizada solo para presentaciones ligeras de solo lectura, interfaces con una interacción intensa o casos en que esté documentada la incompatibilidad con el framework estándar. Las cuadrículas de datos incrustadas requieren una altura estable o una cadena flex ininterrumpida con elementos secundarios que puedan contraerse. Reutiliza los diccionarios remotos establecidos para los campos de identidad con búsqueda. Una confirmación sencilla puede usar un diálogo de confirmación, pero cualquier diálogo que recopile campos, valide entradas o envíe valores adicionales debe usar la abstracción de diálogos de formulario aprobada. Cuando se sepa que la comprobación de tipos amplia o el comando unitario del repositorio no es válido, ejecuta únicamente el formateador y el linter admitidos sobre los archivos del cliente modificados. ## Arreglar los fallos de certificados en la capa correcta y proteger las claves de cuenta Inspecciona los plugins de proveedores antes de cambiar el código compartido del pipeline e inspecciona el SDK instalado dinámicamente cuando el comportamiento del proveedor dependa de su versión. Antes de aplicar una corrección, determina si el problema del certificado pertenece al cliente ACME, la ejecución del pipeline, un servicio del servidor, un plugin de proveedor, una utilidad compartida de certificados o el formulario del cliente. Usa una operación de cuenta de solo consulta con la clave privada de la cuenta existente cuando el cliente del protocolo pueda recuperar la URL de una cuenta existente sin consumir nuevo material de enlace de cuenta externa. Si cambia un identificador de enlace de cuenta externa, genera una nueva clave privada de cuenta vinculada a ese identificador; de lo contrario, bloquea la emisión y exige que se actualice la clave de la cuenta. Mantén los valores de las credenciales fuera del código, los logs, las pruebas, los informes y los artefactos incluidos en commits. Conserva los límites de validación y autorización cuando amplíes los flujos de subida, implantación, notificación o API abierta. ## Mantener el comportamiento con configuraciones antiguas e informar qué comprobaciones se ejecutaron Cuando añadas un parámetro de plugin, contempla su ausencia en las configuraciones heredadas almacenadas y conserva el comportamiento anterior, salvo que una migración lo cambie explícitamente. No reinterpretes un valor ausente como un modo nuevo sin una rama de compatibilidad definida. Antes de terminar, inspecciona el diff acotado, verifica por separado la raíz y cualquier workspace anidado, ejecuta las pruebas directamente afectadas y las comprobaciones de formato o lint por archivo, y confirma las migraciones necesarias. Asegúrate de que los datos de runtime y los resultados generados permanezcan fuera del conjunto de cambios. Informa de qué cambió, qué comprobaciones se superaron, cuáles no pudieron ejecutarse y por qué una validación más amplia quedó fuera del alcance.