01 / Tablero de tareas e historial de ejecucionesLanding de Forge · captura del producto
Una interfaz real de Forge que muestra una tarea junto a su ejecución y el estado del entorno. El proyecto de ejemplo Ledger aparece en los materiales de la landing de Forge.
02 / Inspeccionar una ejecuciónLanding de Forge · captura del producto
La vista de ejecución muestra un comprobante, el resultado de la verificación y una línea de tiempo de eventos. Es la evidencia revisable detrás de una ejecución del agente.
03 / Espacio de trabajo supervisadoLanding de Forge · captura del producto
El editor reúne los archivos del proyecto, la interacción con el agente y una vista previa en vivo en el mismo espacio.
DOSIER DE INGENIERÍA / FORGEAI
Las decisiones detrás del sistema.
Un agente de código solo es útil cuando se pueden inspeccionar su autoridad, su trabajo, sus verificaciones y su entrega.
RESPONSABILIDAD
Arquitectura de la plataforma e implementación práctica. El sistema mantiene la tarea, la ejecución, la evidencia y la decisión de merge bajo responsables separados.
HITO DE DESARROLLO VERIFICADOUna tarea sintética en Kubernetes completó su verificación y llegó a Review en la validación de desarrollo de agosto de 2026.
La ejecución permaneció desactivada entre pruebas. La validación no demuestra operación general en producción ni despliegue autónomo.
ARQUITECTURA / REGISTRO DE DECISIONES01
Un contrato de tarea antes de que el agente se ejecute
CONTEXTO
El texto del backlog puede ser ambiguo y nunca debe convertirse en instrucciones sin restricciones para un worker.
ELECCIÓN
El controlador acepta campos con nombre para el alcance y la aceptación, fija el repositorio y la revisión, y resuelve el comando de verificación desde una clave controlada.
CONSECUENCIA
El worker puede actuar sobre una tarea acotada. Las entradas faltantes o contradictorias bloquean la ejecución antes de que empiece.
02
Separar la ejecución de la publicación
CONTEXTO
Un worker que puede cambiar código y además publicarlo tiene demasiada autoridad.
ELECCIÓN
Un worktree por tarea contiene el trabajo de código. El agente no recibe credenciales de push, de Plane ni de despliegue; la publicación y la revisión ocurren fuera de ese límite.
CONSECUENCIA
Una verificación aprobada genera evidencia revisable, mientras que una persona conserva la decisión de merge.
03
Que cada intento se pueda reconstruir
CONTEXTO
Un simple indicador de éxito no puede explicar reintentos, Jobs interrumpidos ni el origen de un cambio.
ELECCIÓN
TaskRun vincula la tarea, el intento del worker, la verificación y la entrega a un único ID de ejecución inmutable, con eventos de solo anexado.
CONSECUENCIA
Los operadores pueden inspeccionar la secuencia. El almacenamiento de evidencia multinodo sigue siendo un paso de escalado documentado, no un logro completado.
EVIDENCIA Y LÍMITES
El código privado y los artefactos de ejecución no se publican. El diagrama explica los límites de control documentados; no es una vista en vivo del clúster.
FuenteREADME de ForgeAI y contrato de arquitectura de TaskRun.
ValidaciónRunbook de desarrollo en Kubernetes del 22 y 23 de agosto de 2026; la tarea sintética de prueba llegó a Review.
Trabajo pendienteEl documento de paralelismo seguro registra la programación desactivada y el trabajo restante de almacenamiento multinodo.
MODELO DEL SISTEMAELIGE UN COMPONENTE PARA EXPLORAR →
COMPONENTE SELECCIONADOBacklog en Plane
Fuente de verdad del estado de la tarea, los criterios de aceptación y las etiquetas de rol.
01 / EL PROBLEMA
Lo que produce un agente no entra a producción por confianza.
Los agentes de código pueden escribir cambios útiles, pero un equipo no puede hacer merge de trabajo que no puede rastrear. Antes de que lo que produce un agente entre en un flujo real, necesita un contrato de tarea claro, un lugar aislado donde ejecutarse y un registro que alguien pueda revisar.
02 / EL ENFOQUE
Una tarea acotada, un worker aislado, un registro.
Plane guarda el backlog. Ralph, el controlador, reserva una tarea acotada, crea una rama y un worktree aislados, la asigna a un worker y ejecuta solo la verificación registrada para esa tarea. El resultado llega a GitHub como un pull request con su evidencia, para que una persona lo revise.
03 / LA DECISIÓN
Una verificación en verde es evidencia, no permiso.
Mantuve al worker lejos de las credenciales de despliegue y del permiso de push. Puede cambiar código dentro de su worktree, pero la publicación y el merge ocurren fuera de ese límite. Una verificación aprobada se convierte en evidencia para quien revisa, nunca en permiso para hacer merge.
04 / EL RESULTADO
El recorrido completo funciona. Producción es la siguiente prueba.
En la validación de desarrollo de agosto de 2026, una tarea sintética se ejecutó en Kubernetes, pasó su verificación y llegó a Review. El ejecutor de Kubernetes queda desactivado entre pruebas, así que esto demuestra que el recorrido funciona de punta a punta. No es un resultado de rendimiento en producción.
FUENTES
El README de ForgeAI, sus documentos de arquitectura y sus runbooks de Kubernetes. El código y los enlaces internos son privados. Esta página resume lo que muestran esos documentos.