Especificar antes de construir
Un agente de definición conversa con el equipo funcional, acepta texto, fotos y documentos, y deja una especificación con decisiones abiertas que alguien con autoridad cierra.
Describes lo que necesitas, el equipo funcional lo concreta con un agente, tu operador lo construye con otro en el repositorio de tu proyecto y quien aprueba firma cada fase en Azure DevOps. El código no se integra sin esa firma.
Factoría reparte el trabajo entre el Hub, que lo coordina todo, y un nodo local por proyecto, que corre en el equipo de tu operador. Los agentes escriben especificaciones y código; las personas aprueban.
Un agente de definición conversa con el equipo funcional, acepta texto, fotos y documentos, y deja una especificación con decisiones abiertas que alguien con autoridad cierra.
El nodo local reclama una fase, crea la rama, pasa las pruebas, abre el pull request con la referencia al work item y reporta. Cada fase es un cambio pequeño y revisable.
Quien aprueba mueve el work item a Aprobada o Cerrada. El Hub registra quién, cuándo y qué versión firmó, y solo entonces el check factory/signed deja pasar la fusión.
El mismo recorrido sirve con Azure Repos y con GitHub, y sigue funcionando para quien ya está trabajando si Azure DevOps se cae un rato.
El admin del cliente aplica el proceso en Azure DevOps, elige aprobadores por área y los modelos permitidos.
El funcional conversa con el agente de definición hasta validar el Epic; el approver lo cierra.
Los usuarios describen funcionalidades y el operador adopta las peticiones que valen.
El agente redacta la spec en el nodo local, se revisa en Azure DevOps y el approver firma la Feature.
El agente construye cada fase, el approver firma, y el Hub deja fusionar a mano o automáticamente.
Las pantallas de Factoría están dentro de Azure DevOps (extensión) y en esta misma web. Acceso en /app/.
Los roles salen de los grupos de Microsoft Entra y de Azure DevOps. Si no tienes ninguno, la web te lo dice en lugar de enseñarte pantallas vacías.
Un único binario Go hace de Hub y de nodo local. El nodo local abre un túnel con certificado hacia el Hub, así que el equipo del operador no expone ningún puerto.
Las garantías están en el diseño, no en la buena voluntad del agente.
Cada llamada lleva un token validado contra las claves públicas del tenant. Los permisos se leen de los grupos, no de lo que diga el cliente.
Cada instancia tiene un certificado de 24 horas emitido por la CA del Hub. Un certificado revocado pierde también sus claves de modelo.
El check factory/signed sigue en rojo hasta que firma la persona correcta. Quien firma sin ser el approver del área ve su firma revertida.
Fastex diseña, despliega y opera la plataforma. Te acompañamos desde el proceso en Azure DevOps hasta el primer pull request firmado.