Modificar una herramienta de automatización de dispositivos y comprobarla en dispositivos reales

## Clasificar la petición y leer solo el código que se va a cambiar Clasifica primero la solicitud. Una revisión, un triaje o una pregunta que solo pide información es de solo lectura, salvo que se soliciten expresamente ediciones o ejecuciones. Una solicitud de cambio de código autoriza una implementación mínima y las comprobaciones necesarias para esa superficie. Expón los supuestos y define un resultado observable antes de editar. Lee el vocabulario duradero del dominio, las decisiones de arquitectura aplicables y la configuración o el contrato responsable. No leas todo el repositorio de forma predeterminada. Empieza con una búsqueda acotada: - Localiza el símbolo, comando, indicador o error mediante una búsqueda rápida de texto. - Lee el módulo responsable, un auxiliar compartido y un consumidor o adaptador posterior. - En un archivo grande, localiza el tipo o la función pertinente antes de abrir un intervalo acotado. - Sigue las importaciones y las pruebas hacia fuera solo cuando la evidencia lo exija. Mantén el cambio dentro de una familia de comandos, una frontera de plataforma o un grupo de módulos, salvo que la tarea cruce límites de forma explícita. No inspecciones dos implementaciones de plataforma solo porque ambas existan. Si el alcance debe ampliarse, detente y confirma el nuevo límite. Determina antes de programar el impacto sobre la documentación, la ayuda, el esquema y las habilidades. Prefiere referencias duraderas a la fuente de verdad frente a inventarios de archivos que pueden quedar obsoletos. ## Reunir el nombre y las opciones de cada comando en un solo registro Asigna a cada comando un único descriptor canónico que controle su identidad, capacidades, política de tiempo de espera, política de lotes y proyecciones públicas. Mantén el enrutamiento del daemon o servicio en un registro de rutas, las garantías de las rutas de interacción en una matriz tipada y los nombres de los comandos en un solo catálogo. No vuelvas a crear conjuntos de cadenas dentro de los manejadores. Mantén los enrutadores de nivel superior ligeros y dedicados únicamente a la orquestación. Dirige cada solicitud a la familia de manejadores responsable; no acumules lógica de comandos en el punto de entrada. Las decisiones sobre capacidades pertenecen a su fuente de verdad, no a condiciones dispersas. Deja que cada opción pública atraviese únicamente las capas que la entienden: 1. Define el indicador público y su gramática. 2. Añádelo a los metadatos y al esquema del comando responsable. 3. Analízalo como entrada del comando. 4. Proyéctalo en una solicitud de servicio solo si la ejecución en tiempo de ejecución lo necesita. 5. Amplía los clientes tipados y los normalizadores solo cuando esas interfaces lo expongan. 6. Propágalo al despacho y a los módulos de plataforma únicamente después de que el contrato público demuestre que pertenece allí. 7. Clasifica cada opción pública en el modelo de progreso de arquitectura o de cobertura. Centraliza el análisis, la coincidencia, la resolución y la evaluación de predicados de los selectores. Una acción dirigida a un elemento debe aceptar selectores estables o referencias registradas, conservar su cadena de selectores y presentar las divergencias de reproducción como sugerencias, en lugar de reescribir silenciosamente el estado del usuario. ## Comprobar que las rutas rápidas y de caché actúan igual que la principal Supón que las garantías se degradan en los límites entre rutas. Al añadir una ruta rápida, delegada, de caché o específica de una plataforma, clasifica cada celda afectada de comando y ruta antes de afirmar que existe paridad. Una entrada del registro no es una prueba semántica. Lee la implementación y verifica que satisface la definición de la garantía. Un fallback que solo delega después de un error no demuestra la paridad de la ruta de éxito; la ruta rápida podría aceptar una entrada que la ruta compartida rechazaría. Antes de medir un experimento, demuestra que cada rama puede ejecutarse. Dos ejecuciones correctas no significan nada si la rama modificada nunca se activó. Registra la ruta, el backend, el código de motivo y las demás pruebas tipadas necesarias para mostrar qué implementación atendió la solicitud. Usa señales estructuradas en lugar de analizar mensajes para personas. Bifurca según códigos de motivo, detalles tipados y valores explícitos de tiempo de espera; no copies la detección basada en texto de errores. Trata cualquier coincidencia de mensajes inevitable como deuda documentada en el punto de decisión. Compón las advertencias mediante el generador compartido de respuestas en vez de sobrescribir las anteriores. Almacena una sola vez los metadatos de toda la respuesta, en lugar de repetir bytes para cada nodo o elemento. Antes de conservar un campo de compatibilidad, determina si llegó a publicarse. Una superficie aún no publicada puede retirarse limpiamente; una superficie publicada necesita migración y tratamiento de compatibilidad. ## Mantener los archivos pequeños y las pruebas con la misma estructura que el código Usa `unknown` solo en límites de confianza, como entradas analizadas, cargas útiles de ejecución, errores capturados y E/S genérica. Valida una vez y después reduce el tipo a uno del dominio o a un analizador específico, en vez de propagar la incertidumbre por auxiliares internos y formateadores. Prefiere comprobaciones de exhaustividad en el nivel de tipos cuando el lenguaje permita que los casos ausentes sean imposibles. Coloca las afirmaciones legibles por máquinas junto al código que describen: las celdas del registro junto a los punteros de aplicación, los manifiestos de cobertura junto a las pruebas de contrato y los comentarios de decisión en la rama que justifican. Haz que cada módulo responda a una sola pregunta. Como umbral práctico, procura que los archivos de implementación tengan unas 300 líneas; después de 500, mejora la localidad antes de añadir comportamiento; por encima de 1,000, trata el archivo como deuda de arquitectura, salvo que contenga datos generados o una instantánea de fixture. Nombra los archivos según el concepto de dominio al que responden. Usa barrels solo en los límites de paquetes; los barrels internos añaden saltos de navegación. Extrae un módulo profundo cuando mejore la propiedad conceptual, no solo para reducir el número de líneas. Refleja la topología del código fuente en las pruebas. Cuando se divida un módulo fuente, divide sus pruebas en el mismo cambio. Coloca los fixtures reutilizables en un módulo de fixtures hermano y con nombre, en vez de duplicar objetos grandes en línea. No añadas exports de producción únicamente para facilitar la prueba de un detalle privado. Antes de finalizar, depura el código modificado y el directamente adyacente: retira ramas obsoletas, pruebas redundantes, importaciones sin usar, fixtures desactualizados y duplicaciones que el cambio haya vuelto innecesarias. Evita la limpieza no relacionada. ## Cerrar las sesiones de dispositivo y separar registros y diagnósticos Canaliza la ejecución de procesos mediante la abstracción compartida de procesos. Amplía esa abstracción cuando falte una capacidad, en vez de importar primitivas de proceso de bajo nivel por todo el código. Trata cada sesión de dispositivo abierta manualmente como un recurso. Registra su nombre de sesión, plataforma, identificador de dispositivo y directorio de estado; después ciérrala con los mismos valores antes de terminar, incluso tras un experimento fallido. Detén únicamente los procesos obsoletos que puedas identificar con exactitud como pertenecientes a la ejecución de verificación; nunca finalices grupos amplios de procesos basándote en conjeturas. Mantén separados los registros de la aplicación, la salida del runner y los diagnósticos de solicitudes. Un solo backend debe ser responsable de capturar los registros de la aplicación. Guarda los diagnósticos de solicitudes bajo la sesión y el identificador de solicitud resueltos; reserva los registros de nivel superior del daemon para el ciclo de vida y los fallos anteriores a la resolución de la sesión. Centraliza los ámbitos de diagnóstico, los temporizadores, la emisión de eventos, la ocultación de datos y la construcción de rutas de artefactos. No construyas manualmente rutas de registros ni añadas archivos ad hoc cuando el servicio de diagnósticos sea responsable de esos datos. Normaliza los fallos mostrados al usuario en una carga útil estable con código, mensaje conciso, indicación de recuperación, identificador de diagnóstico, ruta del registro y detalles tipados. Conserva esos campos al envolver errores. Indica qué falló, por qué cuando se conozca y cuál es la siguiente acción de recuperación. Trata los sondeos opcionales, las comprobaciones de caché y las comprobaciones previas como mejores esfuerzos, salvo que el contrato de la función los haga obligatorios. Asígnales un tiempo de espera menor que el de la operación requerida y vuelve a la ruta establecida si fallan o devuelven una estructura inutilizable. ## Elegir las pruebas según lo que cambió Empieza por el planificador de comprobaciones afectadas del repositorio cuando esté disponible. Debe derivar las pruebas específicas y las puertas restantes de los metadatos canónicos, no de una lista escrita a mano. Asocia las comprobaciones con la superficie modificada: - Cualquier cambio en código fuente tipado requiere comprobación de tipos y formato. - La configuración de la cadena de herramientas o del compilador requiere la puerta de herramientas y la compilación de declaraciones. - Los cambios en servicios o manejadores compartidos requieren el paquete de pruebas unitarias específicas. - Los cambios en la estructura de respuestas o en los límites de proveedores requieren comprobaciones de integración del proveedor y de cobertura. - Los cambios en el runner nativo requieren recompilar el artefacto de prueba nativo. - El comportamiento multiplataforma requiere el conjunto de pruebas de integración multiplataforma. - El trabajo exclusivamente documental necesita pruebas de ejecución solo cuando un contrato más específico así lo establezca. No ejecutes de forma predeterminada pruebas de integración amplias cuando baste con evidencia específica. A la inversa, no consideres listo un cambio que afecta a dispositivos basándote solo en pruebas unitarias. Mantén las pruebas centradas en el comportamiento. No afirmes lo que los tipos estáticos ya demuestran. Las pruebas unitarias no deben esperar tiempo real; inyecta un presupuesto de tiempo, deriva la cadencia a partir de él o comprueba que el presupuesto se conectó correctamente. Cuando una puerta de cumplimiento detecte un indicador sin clasificar, una celda de garantía ausente, un escenario sin cubrir, una elusión de la construcción de respuestas o una brecha de paridad entre reglas, clasifica o cubre el nuevo comportamiento. Nunca suprimas la puerta ni añadas una entrada inexplicada a la lista de permitidos. ## Recompilar antes de comprobar en dispositivos reales o simuladores Antes de la verificación manual, recompila todos los artefactos que el runtime consuma realmente, reinicia los servicios que no admitan recarga en caliente e invalida o sustituye cualquier runner adoptado que pueda seguir sirviendo un binario nativo anterior. Una prueba contra una salida obsoleta es un falso negativo, no evidencia del producto. Demuestra qué backend atendió la ejecución. Captura una instantánea o respuesta de estado legible por máquinas y coteja el identificador del backend y la versión del auxiliar con el paquete actual. Un fallback silencioso solo es evidencia válida cuando el comportamiento de fallback es la función sometida a prueba. Usa dispositivos, simuladores o emuladores diferentes para worktrees simultáneos, porque un estado aislado del daemon no aísla los objetivos físicos. Sigue la guía de configuración de la propia aplicación de prueba; que una aplicación esté instalada no basta, salvo que las comprobaciones de compilación, servidor de desarrollo y superficie demuestren que se ejecuta la versión prevista. Clasifica el ruido del entorno antes de depurar el código del producto. Reproduce los fallos por contención de forma aislada y sobre la base sin cambios con la misma carga. Un conjunto cambiante de fallos que pasa de forma aislada probablemente indica contención; un fallo estable en la ruta modificada es una evidencia más sólida de regresión. Si un sandbox impide usar un listener local, un puente de dispositivo o una herramienta nativa necesarios, vuelve a ejecutar por la ruta elevada aprobada en vez de diagnosticar la denegación del sandbox como un error del producto. Si la verificación en vivo sigue bloqueada, informa del dispositivo, permiso, comando o servicio exacto que se necesita y conserva el riesgo residual. ## Revisar la ruta real del comando e informar con resultados en dispositivos reales Revisa el trabajo frente al problema que lo motivó y las decisiones de arquitectura aceptadas, no solo frente al diff. Sigue la ruta de producción desde la superficie del comando, pasando por el enrutamiento de solicitudes, hasta el backend de la plataforma. Una prueba que elude el router o simula la interfaz crítica no demuestra el comportamiento entregado. Para cada prueba de regresión clave, identifica la implementación anterior, la eliminación o la reversión que debería hacerla fallar. Si la prueba sigue correcta después de que reaparezca el error, es vacua y debe reforzarse. Separa la refactorización prevista de los cambios de comportamiento ocultos en la estructura de salida, la propagación de advertencias, los detalles de error, las rutas de artefactos, los niveles de reintento y los fallbacks. Verifica los cambios relacionados y el orden de las ramas cuando la implementación dependa de otro cambio. Coloca la publicación externa o el push detrás de una única cadena de éxito, de modo que no pueda ejecutarse después de que falle un comando de formato, tipos, lint o pruebas. Mantén acotados los commits y pull requests, usa el estilo de título habitual del proyecto y abre de forma predeterminada una revisión lista para evaluación solo cuando el trabajo esté completo. Resume el comportamiento visible para el usuario, la validación significativa, la evidencia obtenida con dispositivos en vivo y las contrapartidas reales. No afirmes que CI está en verde basándote en una ejecución unitaria local ni que un cambio de plataforma está listo para fusionarse sin evidencia en vivo actual. Indica el impacto sobre la documentación o la ayuda, el alcance modificado, cualquier ruta sin verificar y el bloqueo exacto. Antes de la entrega, cierra todas las sesiones y da cuenta de todos los recursos abiertos durante la verificación. Informa de cualquier sesión, proceso, directorio de estado o artefacto que no haya podido limpiarse.