Laravel Prompts 0.3.15 añadió stream(), task(), autocomplete(), notify() y title(). Estas APIs hacen que un comando Artisan se parezca menos a un script silencioso y más a una interfaz con tiempo, feedback y señales de recuperación.
La API de streaming muestra salida incremental y encaja con respuestas de IA que llegan token por token. task() mantiene un log bajo un spinner y deja un estado persistente de éxito, advertencia o error. El autocomplete sugiere rutas, claves de configuración o paquetes, y una selección puede mostrar información contextual. Las notificaciones nativas cubren trabajos largos en background.
La consecuencia para gestión es práctica. Las herramientas internas pierden adopción cuando nadie sabe si funcionan, qué esperan o qué ocurrió tras un fallo. Un buen comando no necesita una aplicación web completa; necesita entrada clara, progreso y un resultado accionable. Laravel Prompts reduce el costo de implementar esas bases en PHP.
La adopción de un comando interno depende de feedback visible
La herramienta interna compite con el tiempo de quien está en un incidente o en un onboarding. Si el comando se queda mudo dos minutos, la persona mata el proceso, abre otro camino o llama a alguien. El paquete ahora ofrece el mínimo que un producto de terminal necesita: entrada con sugerencia, progreso con log, resultado que permanece en pantalla y título de ventana mientras corre el job.
Joe Tannenbaum describió el origen: varios primitivos salieron de la Cloud CLI y aterrizaron en Prompts. Eso importa porque la API dejó de ser solo inputs bonitos y pasó a cubrir el ciclo de una operación larga. task() recibe un logger para líneas, mensajes estables de éxito, aviso o error, y un label que cambia a mitad de camino. title() actualiza la pestaña. callout() empaqueta un resumen con lista y metadato. Quien opera de verdad lee eso; no lee un muro de texto al final.
Midan la adopción con números del propio equipo, no con impresión. Cuántas veces se ejecutó el comando en la semana. Cuántas ejecuciones terminan en error. Cuántas personas siguen pegando el runbook en Slack. Si el gráfico no se mueve después de una interfaz nueva, el problema no era el spinner. Era permiso, entorno o un paso que el comando no cubre.
No construyan una TUI para una operación que debería ser un job en CI. El wizard interactivo sirve a quien elige una opción. El pipeline sirve a quien necesita repetición y auditoría. Ambos pueden llamar la misma función PHP. La cáscara cambia.
Stream en el TTY y log en CI piden caminos distintos
stream() existe para texto que llega poco a poco: token de modelo, log de API, salida de un proceso hijo. En un TTY humano, wrap, ANSI y fade-in ayudan a leer. En GitHub Actions, el mismo flujo necesita línea estable, sin control de cursor, y un artefacto que otro sistema pueda parsear.
La documentación de Prompts describe fallbacks para entornos sin soporte y la extensión PCNTL para animar el spinner. Sin PCNTL, la tarea aparece estática. Eso es aceptable en el portátil. En un runner efímero, asuman el fallback y prueben los dos. Un prompt interactivo en CI es un fallo de diseño: la Cloud CLI ya desactiva prompts cuando no hay TTY. El comando interno debería hacer lo mismo, con --no-interaction o una detección explícita.
El streaming de un agente también es superficie de dato. Token a token en pantalla puede incluir un trozo de .env, PII de un dump o una clave que el modelo repitió. Definan qué puede ir al terminal y qué solo entra en un log redactado. stream() no hace esa distinción. El producto que montan alrededor sí.
autocomplete() con un closure que consulta disco o base a cada tecla es excelente en el portátil y caro si la fuente es una API lenta. Cacheen la lista. Acoten el conjunto. El panel info del select debe mostrar lo que la persona necesita para no elegir el entorno equivocado: nombre, región, si es producción. El precio de un paquete es ilustración de la docs; en el comando interno, el metadato crítico es el impacto.
Un spinner bonito no prueba que el proceso sea seguro
Deploy, migrate y seed siguen siendo operaciones con efecto. Una barra viva reduce ansiedad. No reduce la chance de correr migrate en producción sin backup, ni la de que un agente Artisan aplique un diff sin revisión. Prompts mejora la cáscara. La política de quién puede disparar el comando, en qué entorno, con qué confirmación, sigue en el código y en el acceso.
Usen confirm() con default negativo en cualquier acción destructiva. Usen el panel info para repetir el objetivo ("producción, eu-west, clúster X"). Graben un identificador de la ejecución en el log estructurado, el mismo que el callout puede mostrar al pie. Si el equipo solo tiene el spinner, el post-mortem vira captura de pantalla.
El paquete trae tests para prompts. Traten el comando como producto: cubran el camino feliz, la cancelación y el fallback sin TTY. Un comando de diagnóstico que solo se pulsó en el Mac de una persona fallará en el primer Windows sin WSL o en el primer job programado.
La notificación del sistema no cierra el incidente
notify() en macOS puede llevar subtítulo y sonido; en Linux, icono. Sirve a quien disparó un seed y fue a otra pestaña. No sustituye alerta en el canal de operación, ticket ni el estado persistente en el terminal. Quien no estaba en ese portátil no oye la notificación local.
Separe los públicos. Quien espera en el escritorio gana notify y title. Quien necesita saber después gana línea de log, código de salida distinto de cero y, si el comando es de deploy, la misma señal que ya usa el pipeline. Mezclar ambos genera la ilusión de que "el equipo fue avisado".
Prompts bajó el costo de una CLI que alguien quiera usar. La decisión de liderazgo es qué operaciones merecen esa cáscara, cuáles deben seguir mudas en CI, y qué evidencia queda cuando el spinner desaparece. Sin ese triaje, el equipo gana un chat de LLM en Artisan y sigue con el bash de 400 líneas para lo que realmente toca producción.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
