Cambia un espacio de trabajo de Rust con bibliotecas y CLI y compáralo con la herramienta de referencia

## Pon los cambios en el crate responsable y mantén ligeras las API de bajo nivel Trata el repositorio como un espacio de trabajo con múltiples crates que atiende tanto a usuarios de bibliotecas como de línea de comandos. Lee los manifiestos del espacio de trabajo antes de editar para conocer la versión mínima compatible de Rust, el grafo de funcionalidades, las responsabilidades de cada crate y los puntos de entrada públicos. Separa los mecanismos de bajo nivel de las interfaces de alto nivel: - las API de bajo nivel deben favorecer las referencias, exponer explícitamente el estado de trabajo mutable y evitar clonaciones por conveniencia; - las API de alto nivel pueden aceptar cierta asignación de memoria o transferencia de propiedad a cambio de facilidad de uso; - los objetos ligeros de plataforma normalmente deben tomar prestado el repositorio; - las cachés costosas pueden poseer o clonar el estado del repositorio cuando, de otro modo, los tiempos de vida dominarían la API. Usa `Options` para comportamientos con ramificaciones que puedan tener valores predeterminados. Usa `Context` para los datos necesarios a fin de realizar la operación y que, por tanto, no admitan un valor predeterminado seguro. Coloca los cambios en el crate propietario de la estructura de datos o la operación correspondiente. Mantén el comportamiento compartido de línea de comandos en una capa común de CLI, en lugar de duplicarlo en distintos binarios. Antes de cambiar una superficie pública, considera tanto a quienes llaman directamente a la biblioteca como el comportamiento de la línea de comandos. ## Empieza con una prueba que falla y compara con la herramienta de referencia Inicia los cambios de comportamiento con una prueba de regresión que falle por el motivo previsto. Mantén la prueba centrada en el comportamiento observable y deja que el compilador de Rust detecte los errores habituales de tipos y propiedad. Al implementar un protocolo o formato de archivo establecido, usa la implementación de referencia dominante como oráculo siempre que sea viable. Ejecuta casos equivalentes en ambas implementaciones e investiga cualquier diferencia semántica, en lugar de suponer que son compatibles. Ejecuta las pruebas existentes antes de editar para no atribuir al cambio fallos preexistentes. Usa: - pruebas unitarias para algoritmos locales y transformaciones de datos; - pruebas de integración para los límites entre crates; - pruebas de recorrido para el comportamiento integral de la línea de comandos; - repositorios reales o conjuntos de datos realistas para rutas sensibles a la compatibilidad. Cada mensaje de aserción debe explicar la invariante que se comprueba, no limitarse a indicar que una aserción falló. Añade documentación clara de los fixtures que describa el comportamiento sometido a prueba y qué detalles son esenciales. Prefiere cadenas de documentación cuando el sistema de fixtures las admita. ## Sustituye unwrap() por errores que digan qué falló y dónde Nunca uses `unwrap()` en código de producción. Evítalo también en las pruebas; prefiere `?`, o usa `expect()` únicamente con una explicación concisa de por qué debe cumplirse la condición. Conserva las cadenas de errores completas para que los usuarios entiendan qué falló y dónde. Los binarios de línea de comandos pueden usar un tipo de error flexible en el nivel superior, pero los crates de nivel inferior deben seguir la convención de errores estructurados del espacio de trabajo. Antes de añadir un error, revisa el manifiesto del crate y el código cercano: - si el crate ya usa el marco de errores más reciente que incorpora contexto, continúa con ese patrón; - si todavía usa una enumeración de errores heredada basada en derive, mantén la coherencia dentro de ese crate, salvo que la migración forme parte explícita del alcance. En el patrón que incorpora contexto: - crea mensajes estáticos o con formato mediante el auxiliar del proyecto; - añade contexto al propagar el error de una función llamada; - genera un mensaje independiente cuando no exista un error de una función llamada; - borra los tipos de los errores solo cuando lo exija el límite de un callback; - convierte el wrapper de excepciones del proyecto en un error estándar únicamente en los límites de interoperabilidad. Si el wrapper de excepciones del proyecto no implementa deliberadamente el trait de error estándar, no lo fuerces a entrar en API de errores genéricas. Conviértelo con el método de límite proporcionado. Las pruebas que devuelvan errores estándar encajonados deben transformar el wrapper antes de usar `?`. Usa los traits de extensión de errores y las importaciones existentes, en lugar de reconstruir manualmente las cadenas de errores. ## Evita clones de más y trata las rutas del repositorio como bytes Prefiere las referencias en los crates de bajo nivel para evitar clonaciones costosas. No desvincules un identificador respaldado por el repositorio salvo que se requiera explícitamente un valor en propiedad y la API no pueda aceptar la forma vinculada. Usa la abstracción de concurrencia del espacio de trabajo para la mutabilidad interior. No la sustituyas por primitivas de sincronización no relacionadas sin comprobar la compatibilidad de funcionalidades y el comportamiento de la plataforma. Trata las rutas del control de versiones como datos orientados a bytes, incluso en plataformas cuyas API de rutas nativas usan codificaciones diferentes. Convierte las rutas del repositorio en rutas del sistema operativo únicamente mediante las utilidades de rutas del proyecto o un tipo de límite dedicado. No supongas que una ruta válida del repositorio sea Unicode válido. Evita las conversiones con pérdida en el análisis, la comparación, el almacenamiento y el código de protocolos. Mide las rutas críticas antes de añadir propiedad, almacenamiento en caché o asignaciones de memoria. La comodidad pertenece a la capa de alto nivel; las primitivas de bajo nivel deben conservar el control y un coste predecible. ## Prueba todas las combinaciones de funcionalidades, no solo la compilación por defecto Usa el ejecutor de tareas del repositorio para el comando de pruebas completo, las comprobaciones de configuración del espacio de trabajo, el lint, las pruebas de recorrido y las compilaciones de documentación. Usa directamente `cargo test` solo cuando sea suficiente de forma intencionada una ejecución limitada a pruebas unitarias. Verifica las variantes de publicación compatibles, incluida la compilación predeterminada y cualquier conjunto reducido o mínimo de dependencias. Un cambio está incompleto si solo funciona con las funcionalidades predeterminadas. Ejercita las combinaciones de funcionalidades documentadas del espacio de trabajo, incluidas las variantes pequeña, reducida, máxima y pura cuando existan. Comprueba que las dependencias opcionales y las abstracciones de plataforma compilen en cada combinación afectada. En plataformas donde varíe el contenido de los fixtures generados, usa el mecanismo del repositorio para estabilizar archivos comprimidos. Prefiere archivos empaquetados de fixtures a su generación local en cada plataforma cuando importe la estabilidad byte a byte. Si el repositorio define una variable de entorno específica de plataforma para las pruebas de archivos comprimidos en macOS o Windows, aplícala exactamente como se documenta. No omitas silenciosamente las pruebas afectadas en otras plataformas. Ejecuta pruebas integrales de comandos para cambios de CLI visibles para el usuario y compara con la implementación de referencia cuando sea práctico. ## Escribe commits útiles para el changelog y marca los cambios incompatibles Usa commits convencionales con una finalidad clara: - añade un prefijo convencional solo cuando el cambio deba aparecer en el registro de cambios; - usa `feat:` y `fix:` para funcionalidades y correcciones visibles para el usuario; - omite el prefijo en refactorizaciones y tareas internas; - marca cada cambio incompatible con el sufijo `!`. Escribe asuntos de commit que indiquen el propósito visible para el usuario e incluyan la referencia a la incidencia o revisión cuando el proyecto la requiera. Cuando un cambio incompatible afecte a varios crates, divídelo por crate si un único mensaje de commit no puede describir con precisión todos los efectos. Coloca el cambio incompatible de la API en el primer commit y las adaptaciones posteriores en otro commit. Trata los mensajes de commit como datos de entrada de la publicación cuando la automatización obtenga de ellos las versiones o los registros de cambios. Actualiza las guías de alto nivel, las instrucciones de contribución, las notas de desarrollo, los registros de estado de los crates y la documentación de estabilidad siempre que el cambio de código los afecte directamente. Usa como referencia de compatibilidad la versión de la herramienta de referencia disponible en el entorno principal de CI, salvo que el proyecto defina un objetivo más estricto. ## Repasa la lista final, desde la capa del crate hasta los mensajes de commit Antes de terminar: 1. identifica si el cambio pertenece a los mecanismos de bajo nivel o a la interfaz de alto nivel; 2. revisa los patrones establecidos en crates similares; 3. confirma que el manejo de errores coincida con el marco actual de ese crate; 4. verifica que no se haya introducido ningún `unwrap()` en producción; 5. comprueba todas las combinaciones de funcionalidades y variantes de publicación afectadas; 6. considera por separado a los usuarios de la biblioteca y de la línea de comandos; 7. ejecuta las pruebas focalizadas, del espacio de trabajo, de recorrido y de compatibilidad según corresponda; 8. confirma que las rutas orientadas a bytes no sufran pérdidas entre plataformas; 9. revisa si las nuevas clonaciones, desvinculaciones, cachés y sincronizaciones responden a una necesidad medible; 10. actualiza la documentación directamente relacionada; 11. confirma que los mensajes de commit describan correctamente el impacto en el registro de cambios y de los cambios incompatibles. Informa de cualquier conjunto de funcionalidades, plataforma, comparación con la referencia o variante de publicación que no se haya probado, junto con el requisito previo exacto que falte. No afirmes que existe compatibilidad en todo el espacio de trabajo basándote en una ejecución de pruebas unitarias con las funcionalidades predeterminadas.