Automatiza tu Symfony con IA en menos de una hora

☄ Teleport al Blog

Pascualhybrid

✨ mcp/sse

7 de mayo de 2026

Imagina esto.

Entra un producto nuevo en tu catalogo. Una IA lo analiza, decide en que categoria va, le genera una descripcion comercial, lo da de alta en tu base de datos y dispara un email a los clientes que lo estaban esperando. Sin que nadie de IT mueva un dedo.

Lo que estoy describiendo no es ciencia ficcion. Y tampoco es un proyecto de seis meses. Si tienes un Symfony en marcha, toda esa logica probablemente ya esta escrita. Lo que falta es la capa que la haga consumible desde fuera.

Eso es lo que hace symfony-command-ui. Y desde el 5 de mayo es oficial en el ecosistema Symfony.

El problema que tenemos en muchos proyectos

En la mayoria de empresas con un Symfony en produccion pasa lo mismo:

Marketing quiere lanzar una campaña, sacar un export, importar una lista. Pide ticket a desarrollo y espera dos dias.
Soporte quiere reactivar la cuenta de un cliente o forzar un reenvio de email. Pide ticket a desarrollo y espera un dia.
Producto quiere un informe puntual con un cruce de datos concreto. Pide ticket a desarrollo y espera una semana.
Tu propio equipo de IA quiere conectar un agente para que automatice flujos. No tiene por donde tirar: la logica vive enterrada en comandos de consola que solo se ejecutan por SSH.

Y aqui esta lo absurdo: la logica YA EXISTE. Esta probada en batalla. Funciona desde hace años. Pero solo es accesible para quien tiene acceso al servidor y se sabe los comandos de memoria. Para todo el mundo, no existe.

Reescribir esa logica como API REST a medida es un proyecto de meses. Y esta mal: estarias duplicando codigo que ya tienes.

La solucion

symfony-command-ui es un bundle que expone los comandos de tu proyecto Symfony a traves de:

Una web que cualquier persona de tu equipo (no solo developers) puede usar. Cada comando aparece como una tarjeta con su formulario. Eliges, rellenas, ejecutas, ves el resultado en tiempo real.
Una API que cualquier sistema externo puede llamar. Un agente de IA, un chatbot de Slack, otra aplicacion, un cron remoto.
Tu eliges que comandos se exponen y cuales no. No es "abrir la consola al mundo": es decidir granularmente que funciones habilitas y a quien.

Y lo mas importante para un proyecto que ya esta en produccion: no tocas el codigo existente. Sigues teniendo tus comandos de Symfony Console como siempre. Solo le pones encima una capa que los hace consumibles.

El bundle esta probado en produccion en varios proyectos antes de publicarlo. No es un experimento de fin de semana: es un patron que ya esta dando valor en sistemas reales y que llevaba tiempo pidiendo salir a la comunidad.

Casos reales de uso (en lenguaje de negocio)

El dashboard que no tienes que construir

El caso mas basico, y por el que la mayoria de proyectos van a empezar a usarlo.

Imagina que tienes una tienda online de mascotas. En tu Symfony tienes comandos como alta-mascota, importar-stock-proveedor, enviar-newsletter-promo, informe-ventas-semana. Cada vez que añades un comando nuevo, aparece automaticamente en el dashboard: con su formulario, sus opciones, sus dropdowns. Cero codigo de UI, cero documentacion adicional.

La gente de tu negocio (atencion al cliente, marketing, producto) entra al dashboard y ejecuta lo que necesita. Pero aqui esta la parte interesante: no hace falta que entren manualmente. Una IA conectada a la API hace exactamente lo mismo en su nombre.

Y lo importante: la operacion es la misma. Si ejecutas alta-mascota desde la terminal, desde la web o pidiendoselo a la IA, el resultado es identico. No hay "tres caminos paralelos" que mantener: hay un unico comando, expuesto por tres vias. Consistencia total, garantia de comportamiento, cero divergencia entre canales.

Alta de producto end-to-end con IA

Llega un producto nuevo. Un agente de IA, conectado a esta capa, encadena automaticamente: analizar-producto, crear-categoria, alta-producto, generar-descripcion, notificar-clientes.

Cinco comandos que ya tenias en tu Symfony, ejecutados en cadena sin intervencion humana. Lo que antes era una semana de trabajo manual coordinado entre tres equipos pasa a ser un flujo automatico de cinco minutos.

Atencion al cliente sin escalar a IT

Tu equipo de soporte tiene un panel donde puede ejecutar reactivar-cuenta, reenviar-email-confirmacion, consultar-estado-suscripcion. Tareas que antes pedian a desarrollo y ataban a un programador media hora cada vez.

Lo que ganas: tickets de soporte resueltos en minutos, equipo de desarrollo liberado, satisfaccion de cliente.

Marketing y producto autoservicio

lanzar-campaña-newsletter, exportar-clientes-segmento, informe-ventas-mes. Cada equipo ejecuta lo suyo, con un formulario donde elige los parametros (rango de fechas, medio, segmento), y obtiene el resultado al momento.

Lo que ganas: decisiones mas rapidas, tu equipo de IT enfocado en construir, no en lanzar comandos.

Operaciones desde el chat

Conectas el bundle a Slack o Telegram. Alguien escribe en el canal "/exec sincronizar-stock-proveedor". La salida vuelve en streaming al canal. Visibilidad total, trazabilidad total, cero SSH.

Modernizacion de legacy con cabeza

Tienes un Symfony de hace cinco años. Quieres modernizarlo pero no puedes parar el negocio. La estrategia correcta:

Primero exponer. Conectas el bundle. En una tarde tu logica esta accesible para humanos e IA. Valor inmediato sin tocar el codigo.
Despues refactorizar. Con la API publica estable y con tests de integracion comiendo por encima, ya puedes meter DDD por dentro: extraer dominios, limpiar infraestructura, sustituir librerias antiguas. La capa de fuera no cambia, lo de dentro se vuelve mantenible.

Modernizar sin big bang. Sin congelar el roadmap. Sin reescribir nada de cero.

Por que esto deberia venir de serie en Symfony

Symfony Console es brutal. Lleva años siendo la forma estandar de escribir logica operacional en proyectos PHP. La paradoja es que estaba pensada solo para humanos delante de una terminal, en una epoca en la que no era obvio que un agente de IA fuera a querer ejecutar "ese mismo flujo" desde fuera.

En 2026 si que lo es. Cualquier proyecto Symfony deberia poder exponer sus comandos a una IA, a un dashboard interno, a un cliente externo, sin friccion. Que esto no este en el core es una carencia que ahora mismo cada empresa esta tapando con soluciones a medida.

Eso es lo que pretende este bundle. Y por eso me he molestado en publicarlo y mantenerlo.

Lo tecnico, breve

Para quien lo necesite:

Whitelist por namespace. Tu decides en YAML que comandos se exponen. El resto, invisibles.
Flag danger para comandos destructivos: la UI los marca y pide confirmacion.
Streaming en tiempo real (NDJSON). La salida del comando llega linea a linea, no en bloque.
MCP friendly. GET /commands devuelve la lista con parametros bajo una clave config, lista para que un agente IA descubra las "tools" disponibles y las llame.
Solucion inmediata y a prueba de tiempo. No esperas a que Symfony saque una libreria MCP oficial (no existe). No te montas un servidor MCP a medida para tu proyecto. No te toca subir de version de Symfony para que funcione: el bundle soporta de 3.4 en adelante, PHP 7.1+. Lo metes hoy en tu legacy de hace ocho años y ya tienes humanos e IA operando contra el mismo contrato.
Recipe oficial mergeado en symfony/recipes-contrib el 5 de mayo. Basta con:

composer require pascualmg/symfony-command-ui

y Symfony Flex auto-configura el bundle.

Cerrar el circulo en la era de la IA

Hay otra cosa de fondo que me parece la mas potente, y que es por la que lo comparto con tanta conviccion.

Hasta hace nada, hacer las cosas bien en un proyecto Symfony serio significaba aplicar DDD: separar dominio, casos de uso, infraestructura, tener un modelo limpio. Suficiente para construir software mantenible.

En la era de la IA esto se queda corto. Si un agente IA va a operar tu sistema, lo que importa ya no es solo que el codigo este bien diseñado por dentro. Importa que exista un contrato observable por el que el comportamiento se pueda especificar, testear, ejecutar y auditar. Eso es ATDD: Acceptance Test-Driven Development. Especificar en lenguaje cercano al negocio (Gherkin, Given/When/Then), y tener un canal directo desde esa especificacion hasta el sistema real.

El bundle cierra ese circulo:

Definicion de negocio: producto te dice que tiene que pasar cuando entra un producto nuevo. Lo capturas como un caso de uso.
Test Gherkin: Given que llega un producto del proveedor X, When ejecuto =alta-producto, Then se crea con categoria correcta y se notifica a los clientes=.
Implementacion DDD del comando: dominio limpio, casos de uso bien separados, infraestructura aislada.
Prueba end-to-end real: el test Gherkin llama al comando por la misma API que usa produccion. Mismo path, mismo contrato. Si el test pasa, el flujo funciona de verdad.
Automatizacion al nivel que elijas: humanos via la UI, agentes IA via la API, scripts via curl. Todos consumen el mismo contrato que ya esta testeado.

Esto es lo que en mi experiencia separa a un proyecto que sobrevive a la era de la IA del que se queda atras. No es tener un modelo bonito por dentro: es tener un contrato claro por fuera, y poder testearlo y operarlo con la misma herramienta.

Sobre por que lo comparto

Hace semanas que pense en compartir esta herramienta con el mundo. Pero ya sabemos que un gran poder conlleva una gran responsabilidad, y por eso quise hacerla oficial de Symfony antes de presentarla en publico. No sabia que tardarian tanto en aprobarme la recipe :) pero por fin puedo ya presentarla oficialmente para que la use quien quiera. Eso si, confio que se use para no cargarse empleos sino para mejorar los que hay: liberar tiempo del equipo de desarrollo, dar autonomia a negocio, automatizar lo repetitivo y dejar a las personas para lo que de verdad aporta.

Llevo muchas horas automatizando proyectos Symfony en mi trabajo, y otras tantas haciendo refactor DDD sobre legacy: extraer dominios, sacar casos de uso, sustituir infraestructura sin que el cliente note nada. Esta libreria es la destilacion de ese tiempo: el patron que he visto que funciona, que escala, que no rompe nada cuando lo metes en un proyecto que ya estaba en marcha.

Lo comparto porque me parece util para mucha mas gente que la que lo va a usar dentro de mi empresa. Si tu proyecto Symfony necesita esa capa, dale una vuelta. Si tu equipo necesita modernizar legacy con cabeza, hablamos.

Como contribuir

Este bundle existe porque creo que la comunidad Symfony lo necesita. Si lo usas y te ahorra tiempo, devuelve algo:

Issues y preguntas: abre uno en el repo, por pequeño que parezca. "Esperaba X y obtuve Y" ya es valioso.
Pull requests: muy bienvenidas. Mas modos de filtrado, temas, accesibilidad, traducciones de las etiquetas, integraciones con Slack o Telegram, adaptadores MCP, ejemplos en la documentacion.
Casos de uso reales: si lo metes en produccion en algun sitio, cuentamelo. Lo que aprendo de proyectos reales acaba en el proximo release.

El objetivo es una herramienta pequeña y afilada que haga una cosa bien: convertir cualquier Symfony en algo que humanos y agentes IA pueden operar igual. Toda contribucion en esa direccion es bienvenida.

Links

Repo: https://github.com/pascualmg/symfony-command-ui
Packagist: https://packagist.org/packages/pascualmg/symfony-command-ui
Recipe oficial: https://github.com/symfony/recipes-contrib/blob/main/pascualmg/symfony-command-ui/1.0/manifest.json
Post inicial: https://pascualmg.dev/post/ec1d38bb-06b5-4823-9c8b-b1061ac1b7bb

Es tu post

Titulo Contenido (HTML)

<p>Imagina esto.</p>
<p>Entra un producto nuevo en tu catalogo. Una IA lo analiza, decide en
que categoria va, le genera una descripcion comercial, lo da de alta en
tu base de datos y dispara un email a los clientes que lo estaban
esperando. Sin que nadie de IT mueva un dedo.</p>
<p>Lo que estoy describiendo no es ciencia ficcion. Y tampoco es un
proyecto de seis meses. Si tienes un Symfony en marcha, <strong>toda esa
logica probablemente ya esta escrita</strong>. Lo que falta es la capa
que la haga consumible desde fuera.</p>
<p>Eso es lo que hace <code class="verbatim">symfony-command-ui</code>.
Y desde el 5 de mayo es oficial en el ecosistema Symfony.</p>
<h1 id="el-problema-que-tenemos-en-muchos-proyectos">El problema que
tenemos en muchos proyectos</h1>
<p>En la mayoria de empresas con un Symfony en produccion pasa lo
mismo:</p>
<ul>
<li><strong>Marketing</strong> quiere lanzar una campaña, sacar un
export, importar una lista. Pide ticket a desarrollo y espera dos
dias.</li>
<li><strong>Soporte</strong> quiere reactivar la cuenta de un cliente o
forzar un reenvio de email. Pide ticket a desarrollo y espera un
dia.</li>
<li><strong>Producto</strong> quiere un informe puntual con un cruce de
datos concreto. Pide ticket a desarrollo y espera una semana.</li>
<li><strong>Tu propio equipo de IA</strong> quiere conectar un agente
para que automatice flujos. No tiene por donde tirar: la logica vive
enterrada en comandos de consola que solo se ejecutan por SSH.</li>
</ul>
<p>Y aqui esta lo absurdo: <strong>la logica YA EXISTE</strong>. Esta
probada en batalla. Funciona desde hace años. Pero solo es accesible
para quien tiene acceso al servidor y se sabe los comandos de memoria.
Para todo el mundo, no existe.</p>
<p>Reescribir esa logica como API REST a medida es un proyecto de meses.
Y esta mal: estarias duplicando codigo que ya tienes.</p>
<h1 id="la-solucion">La solucion</h1>
<p><code class="verbatim">symfony-command-ui</code> es un bundle que
expone los comandos de tu proyecto Symfony a traves de:</p>
<ul>
<li>Una <strong>web</strong> que cualquier persona de tu equipo (no solo
developers) puede usar. Cada comando aparece como una tarjeta con su
formulario. Eliges, rellenas, ejecutas, ves el resultado en tiempo
real.</li>
<li>Una <strong>API</strong> que cualquier sistema externo puede llamar.
Un agente de IA, un chatbot de Slack, otra aplicacion, un cron
remoto.</li>
<li>Tu eliges <strong>que comandos se exponen</strong> y cuales no. No
es "abrir la consola al mundo": es decidir granularmente que funciones
habilitas y a quien.</li>
</ul>
<p>Y lo mas importante para un proyecto que ya esta en produccion:
<strong>no tocas el codigo existente</strong>. Sigues teniendo tus
comandos de Symfony Console como siempre. Solo le pones encima una capa
que los hace consumibles.</p>
<p>El bundle esta probado en produccion en varios proyectos antes de
publicarlo. No es un experimento de fin de semana: es un patron que ya
esta dando valor en sistemas reales y que llevaba tiempo pidiendo salir
a la comunidad.</p>
<h1 id="casos-reales-de-uso-en-lenguaje-de-negocio">Casos reales de uso
(en lenguaje de negocio)</h1>
<h2 id="el-dashboard-que-no-tienes-que-construir">El dashboard que no
tienes que construir</h2>
<p>El caso mas basico, y por el que la mayoria de proyectos van a
empezar a usarlo.</p>
<p>Imagina que tienes una tienda online de mascotas. En tu Symfony
tienes comandos como <code class="verbatim">alta-mascota</code>, <code
class="verbatim">importar-stock-proveedor</code>, <code
class="verbatim">enviar-newsletter-promo</code>, <code
class="verbatim">informe-ventas-semana</code>. Cada vez que añades un
comando nuevo, <strong>aparece automaticamente</strong> en el dashboard:
con su formulario, sus opciones, sus dropdowns. Cero codigo de UI, cero
documentacion adicional.</p>
<p>La gente de tu negocio (atencion al cliente, marketing, producto)
entra al dashboard y ejecuta lo que necesita. Pero aqui esta la parte
interesante: <strong>no hace falta que entren manualmente</strong>. Una
IA conectada a la API hace exactamente lo mismo en su nombre.</p>
<p>Y lo importante: la operacion <strong>es la misma</strong>. Si
ejecutas <code class="verbatim">alta-mascota</code> desde la terminal,
desde la web o pidiendoselo a la IA, el resultado es identico. No hay
"tres caminos paralelos" que mantener: hay un unico comando, expuesto
por tres vias. Consistencia total, garantia de comportamiento, cero
divergencia entre canales.</p>
<h2 id="alta-de-producto-end-to-end-con-ia">Alta de producto end-to-end
con IA</h2>
<p>Llega un producto nuevo. Un agente de IA, conectado a esta capa,
encadena automaticamente: <code
class="verbatim">analizar-producto</code>, <code
class="verbatim">crear-categoria</code>, <code
class="verbatim">alta-producto</code>, <code
class="verbatim">generar-descripcion</code>, <code
class="verbatim">notificar-clientes</code>.</p>
<p>Cinco comandos que ya tenias en tu Symfony, ejecutados en cadena sin
intervencion humana. Lo que antes era una semana de trabajo manual
coordinado entre tres equipos pasa a ser un flujo automatico de cinco
minutos.</p>
<h2 id="atencion-al-cliente-sin-escalar-a-it">Atencion al cliente sin
escalar a IT</h2>
<p>Tu equipo de soporte tiene un panel donde puede ejecutar <code
class="verbatim">reactivar-cuenta</code>, <code
class="verbatim">reenviar-email-confirmacion</code>, <code
class="verbatim">consultar-estado-suscripcion</code>. Tareas que antes
pedian a desarrollo y ataban a un programador media hora cada vez.</p>
<p>Lo que ganas: tickets de soporte resueltos en minutos, equipo de
desarrollo liberado, satisfaccion de cliente.</p>
<h2 id="marketing-y-producto-autoservicio">Marketing y producto
autoservicio</h2>
<p><code class="verbatim">lanzar-campaña-newsletter</code>, <code
class="verbatim">exportar-clientes-segmento</code>, <code
class="verbatim">informe-ventas-mes</code>. Cada equipo ejecuta lo suyo,
con un formulario donde elige los parametros (rango de fechas, medio,
segmento), y obtiene el resultado al momento.</p>
<p>Lo que ganas: decisiones mas rapidas, tu equipo de IT enfocado en
construir, no en lanzar comandos.</p>
<h2 id="operaciones-desde-el-chat">Operaciones desde el chat</h2>
<p>Conectas el bundle a Slack o Telegram. Alguien escribe en el canal
"/exec sincronizar-stock-proveedor". La salida vuelve en streaming al
canal. Visibilidad total, trazabilidad total, cero SSH.</p>
<h2 id="modernizacion-de-legacy-con-cabeza">Modernizacion de legacy con
cabeza</h2>
<p>Tienes un Symfony de hace cinco años. Quieres modernizarlo pero no
puedes parar el negocio. La estrategia correcta:</p>
<ol>
<li><strong>Primero exponer</strong>. Conectas el bundle. En una tarde
tu logica esta accesible para humanos e IA. Valor inmediato sin tocar el
codigo.</li>
<li><strong>Despues refactorizar</strong>. Con la API publica estable y
con tests de integracion comiendo por encima, ya puedes meter DDD por
dentro: extraer dominios, limpiar infraestructura, sustituir librerias
antiguas. La capa de fuera no cambia, lo de dentro se vuelve
mantenible.</li>
</ol>
<p>Modernizar sin big bang. Sin congelar el roadmap. Sin reescribir nada
de cero.</p>
<h1 id="por-que-esto-deberia-venir-de-serie-en-symfony">Por que esto
deberia venir de serie en Symfony</h1>
<p>Symfony Console es brutal. Lleva años siendo la forma estandar de
escribir logica operacional en proyectos PHP. La paradoja es que estaba
pensada solo para humanos delante de una terminal, en una epoca en la
que no era obvio que un agente de IA fuera a querer ejecutar "ese mismo
flujo" desde fuera.</p>
<p>En 2026 si que lo es. Cualquier proyecto Symfony deberia poder
exponer sus comandos a una IA, a un dashboard interno, a un cliente
externo, sin friccion. Que esto no este en el core es una carencia que
ahora mismo cada empresa esta tapando con soluciones a medida.</p>
<p>Eso es lo que pretende este bundle. Y por eso me he molestado en
publicarlo y mantenerlo.</p>
<h1 id="lo-tecnico-breve">Lo tecnico, breve</h1>
<p>Para quien lo necesite:</p>
<ul>
<li><strong>Whitelist por namespace</strong>. Tu decides en YAML que
comandos se exponen. El resto, invisibles.</li>
<li><strong>Flag <code class="verbatim">danger</code></strong> para
comandos destructivos: la UI los marca y pide confirmacion.</li>
<li><strong>Streaming en tiempo real</strong> (NDJSON). La salida del
comando llega linea a linea, no en bloque.</li>
<li><strong>MCP friendly</strong>. <code
class="verbatim">GET /commands</code> devuelve la lista con parametros
bajo una clave <code class="verbatim">config</code>, lista para que un
agente IA descubra las "tools" disponibles y las llame.</li>
<li><strong>Solucion inmediata y a prueba de tiempo</strong>. No esperas
a que Symfony saque una libreria MCP oficial (no existe). No te montas
un servidor MCP a medida para tu proyecto. No te toca subir de version
de Symfony para que funcione: el bundle soporta de 3.4 en adelante, PHP
7.1+. Lo metes hoy en tu legacy de hace ocho años y ya tienes humanos e
IA operando contra el mismo contrato.</li>
<li><strong>Recipe oficial mergeado</strong> en <code
class="verbatim">symfony/recipes-contrib</code> el 5 de mayo. Basta
con:</li>
</ul>
<div class="sourceCode" id="cb1"><pre
class="sourceCode bash"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="ex">composer</span> require pascualmg/symfony-command-ui</span></code></pre></div>
<p>y Symfony Flex auto-configura el bundle.</p>
<h1 id="cerrar-el-circulo-en-la-era-de-la-ia">Cerrar el circulo en la
era de la IA</h1>
<p>Hay otra cosa de fondo que me parece la mas potente, y que es por la
que lo comparto con tanta conviccion.</p>
<p>Hasta hace nada, hacer las cosas bien en un proyecto Symfony serio
significaba aplicar DDD: separar dominio, casos de uso, infraestructura,
tener un modelo limpio. Suficiente para construir software
mantenible.</p>
<p>En la era de la IA esto se queda corto. Si un agente IA va a operar
tu sistema, lo que importa ya no es solo que el codigo este bien
diseñado por dentro. Importa que <strong>exista un contrato
observable</strong> por el que el comportamiento se pueda especificar,
testear, ejecutar y auditar. Eso es ATDD: Acceptance Test-Driven
Development. Especificar en lenguaje cercano al negocio (Gherkin, <code
class="verbatim">Given/When/Then</code>), y tener un canal directo desde
esa especificacion hasta el sistema real.</p>
<p>El bundle cierra ese circulo:</p>
<ol>
<li><strong>Definicion de negocio</strong>: producto te dice que tiene
que pasar cuando entra un producto nuevo. Lo capturas como un caso de
uso.</li>
<li><strong>Test Gherkin</strong>: <code
class="verbatim">Given que llega un producto del proveedor X,   When ejecuto =alta-producto</code>,
Then se crea con categoria correcta y se notifica a los clientes=.</li>
<li><strong>Implementacion DDD del comando</strong>: dominio limpio,
casos de uso bien separados, infraestructura aislada.</li>
<li><strong>Prueba end-to-end real</strong>: el test Gherkin llama al
comando <strong>por la misma API que usa produccion</strong>. Mismo
path, mismo contrato. Si el test pasa, el flujo funciona de verdad.</li>
<li><strong>Automatizacion al nivel que elijas</strong>: humanos via la
UI, agentes IA via la API, scripts via curl. Todos consumen el mismo
contrato que ya esta testeado.</li>
</ol>
<p>Esto es lo que en mi experiencia separa a un proyecto que sobrevive a
la era de la IA del que se queda atras. No es tener un modelo bonito por
dentro: es tener un contrato claro por fuera, y poder testearlo y
operarlo con la misma herramienta.</p>
<h1 id="sobre-por-que-lo-comparto">Sobre por que lo comparto</h1>
<p>Hace semanas que pense en compartir esta herramienta con el mundo.
Pero ya sabemos que un gran poder conlleva una gran responsabilidad, y
por eso quise hacerla oficial de Symfony antes de presentarla en
publico. No sabia que tardarian tanto en aprobarme la recipe :) pero por
fin puedo ya presentarla oficialmente para que la use quien quiera. Eso
si, confio que se use para no cargarse empleos sino para mejorar los que
hay: liberar tiempo del equipo de desarrollo, dar autonomia a negocio,
automatizar lo repetitivo y dejar a las personas para lo que de verdad
aporta.</p>
<p>Llevo muchas horas automatizando proyectos Symfony en mi trabajo, y
otras tantas haciendo refactor DDD sobre legacy: extraer dominios, sacar
casos de uso, sustituir infraestructura sin que el cliente note nada.
Esta libreria es la destilacion de ese tiempo: el patron que he visto
que funciona, que escala, que no rompe nada cuando lo metes en un
proyecto que ya estaba en marcha.</p>
<p>Lo comparto porque me parece util para mucha mas gente que la que lo
va a usar dentro de mi empresa. Si tu proyecto Symfony necesita esa
capa, dale una vuelta. Si tu equipo necesita modernizar legacy con
cabeza, hablamos.</p>
<h1 id="como-contribuir">Como contribuir</h1>
<p>Este bundle existe porque creo que la comunidad Symfony lo necesita.
Si lo usas y te ahorra tiempo, devuelve algo:</p>
<ul>
<li><strong>Issues y preguntas</strong>: abre uno en el repo, por
pequeño que parezca. "Esperaba X y obtuve Y" ya es valioso.</li>
<li><strong>Pull requests</strong>: muy bienvenidas. Mas modos de
filtrado, temas, accesibilidad, traducciones de las etiquetas,
integraciones con Slack o Telegram, adaptadores MCP, ejemplos en la
documentacion.</li>
<li><strong>Casos de uso reales</strong>: si lo metes en produccion en
algun sitio, cuentamelo. Lo que aprendo de proyectos reales acaba en el
proximo release.</li>
</ul>
<p>El objetivo es una herramienta pequeña y afilada que haga una cosa
bien: convertir cualquier Symfony en algo que humanos y agentes IA
pueden operar igual. Toda contribucion en esa direccion es
bienvenida.</p>
<h1 id="links">Links</h1>
<ul>
<li>Repo: <a
href="https://github.com/pascualmg/symfony-command-ui">https://github.com/pascualmg/symfony-command-ui</a></li>
<li>Packagist: <a
href="https://packagist.org/packages/pascualmg/symfony-command-ui">https://packagist.org/packages/pascualmg/symfony-command-ui</a></li>
<li>Recipe oficial: <a
href="https://github.com/symfony/recipes-contrib/blob/main/pascualmg/symfony-command-ui/1.0/manifest.json">https://github.com/symfony/recipes-contrib/blob/main/pascualmg/symfony-command-ui/1.0/manifest.json</a></li>
<li>Post inicial: <a
href="https://pascualmg.dev/post/ec1d38bb-06b5-4823-9c8b-b1061ac1b7bb">https://pascualmg.dev/post/ec1d38bb-06b5-4823-9c8b-b1061ac1b7bb</a></li>
</ul>

Estas seguro? Esto no se puede deshacer.

Comentarios (0)

Sin comentarios todavia. Se el primero!