Mantén ordenado el repositorio de código de un producto con app y línea de comandos

## Sigue primero el archivo de reglas principal y luego las reglas de cada carpeta Trata el archivo raíz de directrices como la fuente de verdad de todo el repositorio para los límites transversales, el flujo de trabajo y los comandos. Mantenlo lo bastante conciso para orientar a una persona que empieza a contribuir, sin duplicar los detalles de los módulos. - Publica un índice breve de los documentos de producto, arquitectura, contribución, revisión y planes vigentes. - Marca explícitamente las especificaciones archivadas y nunca trates las decisiones antiguas como comportamiento actual. - Dirige cada directorio principal a su propio archivo de directrices sobre responsabilidad y restricciones locales. - Antes de trabajar dentro de un directorio regulado, lee sus directrices locales además de las reglas raíz. - Cuando dos documentos discrepen, sigue la fuente de verdad designada e informa del conflicto en vez de mezclarlos. No copies las reglas de los módulos en el documento raíz. Actualiza cada regla en el nivel más específico que la abarque por completo y enlázala desde documentos más generales cuando sea necesario para encontrarla. ## Decide dónde van el código y las pruebas nuevas antes de hacer cambios Mantén un mapa del repositorio que explique qué posee cada área de nivel superior y qué dependencias pueden cruzar sus límites. Usa el mapa para decidir dónde deben ubicarse el código, las pruebas, las plantillas, la documentación y los datos de ejecución nuevos. - Separa las aplicaciones de usuario, los contratos compartidos, los componentes básicos de plataforma, las herramientas de orquestación, las pruebas de extremo a extremo y las extensiones de contenido. - Mantén la lógica de negocio de las aplicaciones aislada de los detalles internos del control de procesos y el empaquetado. - Impide que una aplicación importe el código fuente privado o las pruebas de otra aplicación. - Eleva los DTO, eventos, errores y formatos de tareas entre entornos a una capa pura de contratos compartidos. - Conserva las pruebas en el directorio propiedad de la capa que verifican; coloca las pruebas de coherencia entre aplicaciones en la capa de extremo a extremo. - Registra los directorios retirados o inactivos para evitar que se reconstruya por accidente una arquitectura obsoleta. Si un aspecto reutilizable no tiene una responsabilidad clara, detente y solicita una decisión de responsabilidad antes de crear otra ubicación compartida. ## Decide en un solo lugar dónde se guardan los datos y pásalo al resto Resuelve cada raíz, espacio de nombres e identidad de ejecución una sola vez en el límite responsable y después transmite el valor resuelto a los componentes posteriores. Los componentes deben consumir ese valor en lugar de reconstruirlo a partir de puertos, directorios de trabajo, nombres de aplicaciones o valores alternativos del entorno. - Deriva todas las rutas de datos propiedad del entorno de ejecución de la raíz de datos resuelta o de constantes derivadas de ella. - Trata las sustituciones limitadas y las fuentes de migración como excepciones explícitas, no como raíces alternativas. - Separa los detalles transitorios del transporte de la identidad persistente del entorno de ejecución. - Asigna espacios de nombres al estado empaquetado y de desarrollo antes de iniciar procesos secundarios. - Transmite el estado resuelto a los procesos secundarios; no permitas que adivinen sus propias ubicaciones de almacenamiento. - Documenta las rutas de escape heredadas conocidas como candidatas a retirada y nunca las uses como ejemplos. Cuando exista una corrección evidente, encamina la ruta mediante la raíz canónica o un argumento explícito. Cuando la responsabilidad correcta no esté clara, solicita una decisión del responsable del mantenimiento en vez de inventar una convención nueva. ## Añade cada función nueva a la app y a la línea de comandos Diseña las funciones de usuario en torno a un único contrato de servicio y ofrécelas mediante todas las interfaces de interacción compatibles. La paridad entre interfaces forma parte de una función completa; no es una mejora para más adelante. Para cada función nueva: 1. Define o actualiza los contratos compartidos de solicitud, respuesta, error y evento. 2. Implementa el punto de acceso del servicio como única fuente de comportamiento. 3. Añade la interfaz gráfica que llama a ese punto de acceso. 4. Añade la interfaz de línea de comandos que llama al mismo punto de acceso. 5. Cuando corresponda, proporciona resultados de comandos legibles por máquinas y entrada desde archivos para instrucciones largas. 6. Actualiza la lista de comprobación del cambio para identificar todas las interfaces afectadas. No implementes comportamientos divergentes en clientes distintos. Si una interfaz realmente no es aplicable, explica el motivo en el registro del cambio en vez de omitirla sin indicarlo. ## Crea piezas de pantalla reutilizables y fáciles de usar para todos Asigna la responsabilidad visual al componente estable más pequeño, a la vez que conservas los contratos globales deliberados. Reutiliza los componentes básicos compartidos antes de crear variantes locales. - Mantén la hoja de estilos global como un límite intencional de importaciones y variables de diseño. - Coloca los estilos propiedad de un componente junto a él y utiliza módulos con ámbito de forma predeterminada. - Reserva los selectores globales para reinicios, variables de diseño, estructuras de aplicación, contratos de contenido compartidos y puntos de integración con terceros. - Conserva el orden de la cascada al dividir hojas de estilos y verifica que la especificidad no cambie por accidente. - Usa controles semánticos y componentes básicos accesibles compartidos para botones, etiquetas ocultas y comportamientos comunes de formularios. - Añade un componente básico compartido solo cuando la necesidad sea verdaderamente reutilizable; mantén la disposición específica del producto en la capa del producto. - Mantén montados los elementos condicionales cuando importe la animación de salida y cambia su estado mediante clases. - Prefiere movimientos rápidos con desaceleración, salidas más cortas que las entradas y una escala inicial distinta de cero. Cuando un estilo global cercano pueda migrarse con seguridad mediante un cambio pequeño y comprobable, muévelo junto con el componente. No combines una migración mecánica amplia con cambios de comportamiento no relacionados. ## Revisa los cambios con la prueba más ligera que detecte el problema Elige la capa de validación más ligera que pueda observar el requisito y añade comprobaciones más amplias solo cuando el riesgo cruce límites. La verificación debe corresponderse con la responsabilidad y el impacto para el usuario del cambio. - Para los defectos, empieza con una prueba de regresión refutable y confirma que falla antes de corregirlos. - Limita la prueba al comportamiento comunicado; registra los defectos adyacentes como trabajo de seguimiento separado. - Ejecuta las protecciones del repositorio y las comprobaciones estáticas, además de pruebas o compilaciones específicas para los paquetes modificados. - Reproduce sesiones grabadas para cambios en analizadores o flujos de eventos de agentes antes de consumir llamadas reales a proveedores. - Usa comprobaciones en el navegador para interacciones visibles, animaciones o condiciones de carrera que las pruebas unitarias no puedan demostrar. - Para cambios en el espacio de trabajo o las dependencias, actualiza los enlaces generados y los códigos hash de empaquetado exigidos por el repositorio. - Compara con el estado de referencia cuando los conjuntos de pruebas próximos tengan fallos conocidos. Haz que la implementación exprese una invariante duradera en lugar de una excepción histórica. No afirmes que algo está listo solo porque las comprobaciones automatizadas sean satisfactorias cuando el criterio de aceptación exija una comparación visual humana. ## Separa las versiones de prueba y estables, y revisa cada versión antes de publicarla Haz explícitos la identidad de publicación, el comportamiento de empaquetado y las evidencias de revisión para cada canal de entrega. No permitas que los atajos convenientes borren la separación entre canales ni eludan una validación de confianza. - Asigna propósitos e identidades públicas diferentes a los canales de desarrollo, validación interna, vista previa y versión estable. - Define explícitamente las dependencias de promoción; no hagas que un canal estable dependa de una fase de vista previa no relacionada. - Mantén las rutas del entorno de ejecución empaquetado separadas por espacio de nombres e independientes de los puertos temporales. - Encauza la orquestación mediante los componentes básicos de los paquetes responsables, en lugar de reconstruir argumentos de procesos o reglas de análisis en el código llamador. - Exige que las descripciones de cambios indiquen el caso de uso que los motiva, el efecto visible para el usuario, las interfaces afectadas y las evidencias de validación. - Adjunta capturas de pantalla que muestren el punto de acceso para los cambios visibles en la interfaz, no solo imágenes aisladas del componente. - Vincula las correcciones de defectos con sus pruebas de regresión y registros de incidencias. - Mantén los hallazgos no relacionados fuera del cambio actual, salvo que bloqueen la corrección, la seguridad, la integridad de datos o la compatibilidad de contratos. Antes de publicar, verifica el artefacto mediante la misma ruta que usarán los usuarios. No apruebes cambios que infrinjan los límites del repositorio, omitan validaciones obligatorias, expongan secretos o puedan corromper datos persistentes.