Modifica un proyecto C portable y veterano sin romper la compatibilidad

## Antes de cambiar, comprueba qué plataformas y variantes de funciones deben seguir funcionando - Trata la portabilidad, la estabilidad, la robustez y la compatibilidad con versiones anteriores como restricciones principales de diseño. - Ten en cuenta compilaciones que van desde una configuración mínima compatible con los estándares hasta una configuración gráfica completa con interfaces de scripts opcionales. - Lee la política de diseño de alto nivel del repositorio antes de cambiar la arquitectura o el comportamiento de cara al público. - Distingue el código fuente principal, los recursos de ejecución, las traducciones, las pruebas, la documentación, los subproyectos y el código incorporado desde upstream. - No presupongas el compilador, sistema operativo, conjunto de funciones o entorno gráfico más reciente. - Mantén un comportamiento coherente entre las variantes compatibles, salvo que el cambio esté controlado explícitamente por una puerta de funcionalidad. ## Compila y prueba la configuración afectada sin advertencias nuevas - Usa la ruta de compilación documentada para la plataforma y la cadena de herramientas actuales. - Regenera las declaraciones de funciones u otras interfaces derivadas mediante su generador, en vez de editar manualmente la salida generada. - Durante la iteración, ejecuta el archivo de prueba específico e inspecciona tanto la salida de mensajes como el registro detallado de pruebas. - Antes de entregar, exige una compilación limpia sin advertencias nuevas, las pruebas pertinentes aprobadas y un estilo de código que coincida con el archivo editado. - Cuando los procedimientos de compilación difieran entre plataformas, consulta la guía de instalación de esa plataforma en lugar de traducir los comandos por conjetura. - Amplía las pruebas cuando se vean afectados el código compartido, las combinaciones de funciones o los archivos de ejecución. ## Regenera los archivos generados desde su generador y respeta a sus responsables - Averigua qué directorios se generan, se importan desde upstream, se comparten con proyectos relacionados o tienen un responsable designado. - Cambia un archivo generado solo cuando cambie su fuente y mantén cualquier regeneración no relacionada fuera de los parches funcionales. - Tramita los cambios de recursos de ejecución mantenidos mediante el flujo documentado del responsable, sin eludir esa propiedad. - Actualiza las fechas o descripciones de cambio obligatorias al editar archivos de ejecución y ayuda que se distribuyen. - Añade la entrada de seguimiento de parches exigida por el repositorio para cambios en el código fuente principal, salvo donde exista una excepción explícita de directorio. - Nunca mezcles en un mismo parche actualizaciones de terceros, ruido generado, traducciones y limpieza de código no relacionada. ## Escribe el problema, no la solución, en el asunto del commit - Sigue exactamente la estructura de asunto y cuerpo de parche del repositorio. - Expón el problema en el asunto, no la implementación de la solución. - Escribe una oración completa para el problema y otra concisa para la solución, con la atribución y la puntuación exigidas. - Cuando el formato lo requiera, coloca la explicación opcional después del encabezado obligatorio de problema y solución, en prosa y no como lista. - Etiqueta las referencias corregidas, cerradas y relacionadas según sus significados distintos. - Incluye la certificación de desarrollo obligatoria y reconoce la ayuda de IA únicamente mediante el mecanismo de coautoría aceptado. ## Sigue el estilo C existente y evita sintaxis que los compiladores antiguos no admiten - Conserva la indentación lógica de 4 espacios y respeta las reglas específicas de cada archivo sobre tabuladores o solo espacios. - Coloca las llaves de apertura en líneas propias tanto en funciones como en estructuras de control. - Da formato a las definiciones de funciones con el tipo de retorno y el nombre de la función en la disposición establecida por el repositorio. - Respeta la ubicación de declaraciones del archivo circundante, en vez de modernizarla de forma oportunista. - Usa únicamente el lenguaje C de base documentado y las funciones más recientes que estén aprobadas; no introduzcas estructuras incompatibles con compiladores antiguos. - Ejecuta cualquier formateador específico del archivo después de editar y revisa sus diferencias. ## Usa los tipos del proyecto y pasa a los auxiliares la longitud de cadena ya conocida - Usa el sufijo de tipo personalizado del repositorio y evita los sufijos reservados por los estándares del sistema. - Conserva la migración de booleanos en curso: usa de forma coherente dentro de un parche la forma booleana establecida localmente y evita conversiones masivas. - Inicializa variables locales cuando la primera asignación no resulte evidente, pero no añadas inicializaciones redundantes que puedan ocultar una lectura sin inicializar. - Usa el auxiliar de longitud literal para literales de cadena y el formateador que devuelve la longitud cuando se necesite el tamaño escrito. - Cuando ya se conozca la longitud de una cadena, pásala a la operación que admite longitud en vez de volver a recorrerla. - Mantén cada puntero a un búfer de bytes junto a su longitud `size_t`; usa tipos enteros más estrechos solo cuando una interfaz heredada lo exija. ## Gestiona la memoria con los envoltorios del proyecto y libérala en cada error - Prefiere los envoltorios del repositorio frente a las operaciones directas de asignación, liberación, copia, movimiento, caracteres y espacios en blanco de la biblioteca estándar. - Elige los envoltorios por su gestión documentada de valores nulos, falta de memoria, solapamientos, codificación y coherencia entre plataformas. - Comprueba explícitamente que el divisor no sea cero antes de cada división, aunque una condición compuesta anterior parezca implicarlo. - Para cada asignación nueva, verifica las rutas de limpieza en caso de éxito, retorno anticipado y cada rama de error. - Conserva los tamaños de búfer en bytes y especifica el comportamiento de truncamiento, terminación y longitud escrita. - No sustituyas un envoltorio más seguro del proyecto por una llamada genérica a una biblioteca solo porque esta resulte más familiar. ## Sigue las reglas de nombres y macros, y mantén portables los archivos de make - Sigue las restricciones de nombres reservados, los identificadores prohibidos, los límites de longitud de los nombres de función, el espaciado y la regla de una instrucción por línea. - Usa el prefijo de funcionalidad establecido y la convención de macros en mayúsculas. - Comprueba las macros de funcionalidad mediante el patrón condicional compatible con el repositorio. - Mantén los archivos principales de compilación dentro del dialecto portable de make documentado; evita extensiones de asignación, patrones, shell y condicionales específicas de una implementación. - Reutiliza los tipos de cadena y bytes del proyecto y sus macros correspondientes. - Lee las referencias de estilo autorizadas antes de introducir un identificador, una macro o una regla de compilación nuevos. ## Escribe scripts de ejecución que funcionen también en entornos y versiones derivadas - Usa el estilo de scripts actual en los archivos nuevos y considera la compatibilidad con entornos de ejecución y variantes relacionadas. - Si la compatibilidad no está clara, pregunta antes de adoptar una construcción más reciente del lenguaje. - Sigue las convenciones de nombres de variables locales en las pruebas de scripts. - No repitas una puerta de funcionalidad dentro de pruebas individuales cuando el archivo ya controle esa función en su nivel superior. - Si el archivo no tiene una puerta de nivel superior, añade una puerta específica solo a las pruebas que requieran la función opcional. - Mantén los cambios de scripts de ejecución separados de una modernización no relacionada del lenguaje principal. ## Escribe pruebas de regresión que reproduzcan el fallo reportado - Prefiere una aserción determinista frente a una prueba que solo verifique que el programa no falla. - Para defectos de renderizado, añade una comparación de captura de pantalla; para datos incorrectos, comprueba la salida exacta. - Añade cobertura completa para el comportamiento nuevo, preferiblemente en un archivo de prueba pertinente ya existente. - Al corregir un defecto notificado, reproduce el escenario original y no solo un caso sintético simplificado. - Usa los auxiliares estándar para sesiones de terminal, volcados de pantalla, carga correcta de scripts y fallos esperados al cargar scripts. - Coloca las pruebas de sintaxis e indentación de los recursos de ejecución en sus conjuntos específicos. ## Actualiza la ayuda en el mismo parche y conserva su formato - Actualiza la documentación orientada al usuario en el mismo parche que cualquier cambio de opción o función. - Actualiza el encabezado de cambios del archivo de ayuda cuando edites documentación existente. - Conserva el formato de ayuda autorizado para encabezados de archivo, líneas de modo, ancho, alineación con tabuladores, etiquetas únicas, referencias cruzadas, títulos, ejemplos de código y notación resaltada. - Usa la operación segura de retabulación y revisa sus diferencias; no fuerces una reescritura amplia de espacios en blanco. - Mantén las etiquetas de enlace únicas en todo el conjunto y antepón un prefijo a las etiquetas específicas de extensiones cuando sea necesario. - Prefiere lenguaje neutral en cuanto al género para texto nuevo o modificado, sin reescribir texto no afectado solo con ese fin. ## Comprueba primero la fase de versiones y mantén accesible el comportamiento obsoleto - Determina si el proyecto está en un ciclo de desarrollo o en un período de estabilidad antes de proponer el alcance. - Durante un período de estabilidad, limita los cambios aceptados a correcciones claras de defectos, correcciones de seguridad, documentación, traducciones y mantenimiento de recursos de ejecución. - No introduzcas funciones nuevas ni cambios incompatibles con versiones anteriores en el núcleo durante la estabilidad. - Conserva el comportamiento publicado del núcleo entre versiones menores. - Mantén el comportamiento obsoleto accesible mediante configuración, documéntalo como obsoleto, permite desactivarlo durante la compilación cuando sea compatible y elimínalo solo en un ciclo posterior permitido. - Trata los recursos de ejecución conforme a su flexibilidad de mantenimiento documentada, sin debilitar las garantías del núcleo. ## Entrega parches en los que cada commit compile y pase las pruebas por sí solo - Lee la política de seguridad antes de informar de una posible vulnerabilidad o cambiar código sensible para la seguridad. - Asegúrate de que estén completos el formato del commit, la compilación limpia, las pruebas pertinentes, la cobertura de regresión, la documentación y la certificación. - Limita las diferencias al problema declarado: sin cambios de espacios aislados, refactorizaciones no relacionadas ni salida generada ajena. - En una serie de varios parches, exige que cada commit compile y apruebe sus propias pruebas por separado. - No dejes un cambio intermedio roto de forma intencionada para que otro posterior lo repare; combínalos. - Confirma que el comportamiento documentado y el comportamiento aplicado sigan coincidiendo, y describe los cambios intencionados en el registro del problema y la solución. ## Haz el cambio más pequeño y pregunta antes de actuar fuera del árbol de trabajo - Realiza el cambio mínimo que alcance el objetivo y respeta el código circundante, en vez de imponer una mejora amplia. - Divide un parche que resuelva varios problemas independientes. - Si un parche solo corrige un síntoma, indica el problema más profundo y la limitación de alcance elegida. - Reproduce un defecto antes de afirmar que existe y lee la implementación antes de afirmar lo que hace el código. - No dependas del contenido de archivos recordado cuando esté disponible el código fuente actual. - Confirma con el usuario antes de instalar paquetes, modificar archivos fuera del árbol de trabajo, hacer push de ramas o usar operaciones de red.