Modificar un kit de UI para consola según su documentación actual y comprobar la pantalla real

## Seguir la documentación actual del repositorio, no patrones de versiones anteriores - Cuando un proyecto anuncia una reescritura importante, se debe asumir que los patrones aprendidos anteriormente pueden ser incompatibles, aunque los nombres resulten familiares. - Leer la introducción vigente a la migración del repositorio antes de diseñar, editar o revisar código. - Usar el patrón mínimo de aplicación, la terminología, el ciclo de vida y las notas de compatibilidad actuales de la documentación del código fuente versionado. - Dar prioridad a la constitución del proyecto, la guía de contribución, el contexto legible por máquinas y las reglas anidadas frente a la memoria o los ejemplos de versiones anteriores. - Si la documentación actual contradice los conocimientos previos, seguir el repositorio actual y registrar la discrepancia en lugar de mezclar ambos diseños. ## Distinguir antes de empezar si se crea una app o se cambia el propio kit - Primero, clasificar la solicitud como creación de aplicaciones, contribución al kit de herramientas, corrección de errores o grabación y verificación visual. - Usar la guía específica de aplicaciones y el recetario de patrones para las aplicaciones consumidoras. - Usar el flujo de trabajo para contribuidores en las funciones y los defectos de la biblioteca. - Usar el flujo de grabación para los cambios visibles de la UI y las evidencias de interacción. - Leer la documentación de conceptos clave sobre el ciclo de vida, la jerarquía de vistas, el diseño, los eventos cancelables y la terminología del dominio antes de modificar esas áreas. - No aplicar componentes internos exclusivos para contribuidores a los ejemplos de aplicaciones ni atajos de aplicaciones al trabajo de la biblioteca central. ## Pasar las listas de comprobación antes de cada edición y después de escribir código - Antes de editar cualquier archivo, seguir la lista de actualización del repositorio para detectar errores comunes y restricciones locales. - Después de escribir o modificar código, aplicar la lista completa de validación posterior a la generación. - Leer la regla detallada de cada tema afectado, incluidos el formato, las declaraciones de tipos, la sintaxis de construcción, los patrones de eventos, el texto Unicode, la disposición del código, la documentación, las pruebas, los diagnósticos y las áreas frágiles. - En el modo de planificación, crear un plan en Markdown en el directorio designado para planes, con los pasos de implementación, los archivos afectados, las oportunidades de reutilización y la verificación. - Mantener el plan alineado con el alcance real y actualizarlo cuando las evidencias cambien la ruta de implementación. ## Poner las pruebas nuevas en la suite paralela por defecto - Restaurar las dependencias, compilar una vez y ejecutar pruebas específicas sin volver a compilar mientras la compilación siga vigente. - Colocar las pruebas nuevas en el conjunto paralelizable de forma predeterminada. - Usar el conjunto no paralelo únicamente cuando sea inevitable un estado estático para todo el proceso y explicar esa dependencia. - No añadir nunca cobertura nueva a un conjunto heredado que esté previsto reescribir o eliminar. - Seleccionar un solo método o una sola clase durante cada iteración y ampliar después al proyecto pertinente cuando el resultado específico sea satisfactorio. - Consultar el inventario de pruebas antes de elegir una cobertura de integración, estrés, rendimiento, paralela o no paralela. ## Grabar la terminal en marcha para comprobar los cambios de UI - No entregar un cambio visual sin observar la interfaz en ejecución. - Ejecutar la aplicación en un pseudoterminal, inyectar pulsaciones representativas y capturar la sesión renderizada. - Leer la grabación legible por máquinas fotograma a fotograma para verificar qué apareció realmente, en lugar de confiar únicamente en una vista previa humana. - Adjuntar un artefacto visual cuando los revisores necesiten evaluar la apariencia o la interacción. - Para aserciones deterministas, usar inyección de entrada dentro del proceso, tiempo virtual y captura de pantalla en el nivel del controlador. - Verificar el diseño, el foco, la gestión de entradas, los grafemas Unicode, la cancelación y el comportamiento de redibujado en el nivel afectado por el cambio. ## Seguir las reglas exactas de espacios y tipos del repositorio - Conservar los espacios exigidos por el repositorio alrededor de las llamadas y la indexación, la colocación de las llaves y las reglas sobre líneas en blanco. - Usar tipos explícitos, salvo el pequeño conjunto de tipos primitivos integrados que permita la guía local. - Dar prioridad a la construcción con tipo de destino y a la sintaxis de expresiones de colección cuando se exijan. - Usar un solo tipo public o internal por archivo. - Ordenar los miembros y los campos de respaldo según la regla de disposición del código. - Para los parámetros de devolución de llamada no utilizados, usar la convención de descarte del repositorio. - Ejecutar el formateador y los controles posteriores a la generación del repositorio; no restar importancia a las diferencias de estilo como si fueran meramente estéticas. ## Usar salidas tempranas y los términos propios del proyecto - Preferir las cláusulas de guarda y las salidas anticipadas; invertir las condiciones en lugar de envolver la ruta satisfactoria en anidamientos profundos. - Aplicar la misma regla de salida anticipada a métodos, devoluciones de llamada y bucles. - Usar de forma coherente los términos de contención del proyecto y reservar los términos genéricos de relación para referencias que no impliquen contención. - Escribir código que se explique por sus nombres, tipos y estructura antes de añadir comentarios. - En la documentación de referencia, procedimientos y API, indicar el objetivo y después proporcionar una acción imperativa directa. - Documentar los contratos públicos, el comportamiento de los flujos cancelables, la gestión de grafemas Unicode y las invariantes no evidentes con el formato de documentación exigido por el repositorio. ## Añadir pruebas de regresión sin reducir la cobertura - Marcar las pruebas generadas por agentes con la anotación de agente y modelo aceptada por el repositorio. - No reducir nunca la cobertura para conseguir que un cambio sea satisfactorio. - Evitar la inicialización global de la aplicación en las pruebas, salvo que el comportamiento requiera específicamente un estado para todo el proceso. - Dar prioridad a la preparación aislada, las entradas deterministas, el tiempo virtual y las aserciones observables. - Colocar cada prueba en el conjunto correspondiente a su modelo de estado, no solo en el que tenga el nombre de archivo más parecido. - Añadir cobertura de regresión para el defecto o comportamiento visible por el usuario, incluidos los casos de diseño y orden de eventos cuando sean pertinentes. ## Usar el registro del repositorio y no tocar código frágil ni ajeno a la tarea - Usar las funciones de registro, registro de pruebas y trazas del repositorio; no escribir directamente en la consola desde el código de la biblioteca o de las pruebas. - No refactorizar como limpieza incidental un subsistema documentado como frágil. - No modificar código no relacionado al implementar una función o corrección específica. - No introducir nuevas advertencias del compilador, analizador, documentación o pruebas. - Volver a leer las diferencias para comprobar el formato, la terminología, la ubicación de las pruebas y cualquier ampliación accidental del alcance antes de informar que el trabajo está terminado. - Si es imprescindible cambiar un área frágil, aislar la edición mínima necesaria y verificar su comportamiento específico antes de ejecutar pruebas más amplias.