Proyectos

Un proyecto es un repo de git que Thulu usa como base de las tareas: lo clona de GitHub o lo arma con una carpeta que subís desde tu computadora. Cuando una tarea vinculada a un proyecto sale de la primera columna, Thulu le arma una rama task-<id> desde la rama por defecto y el agente trabaja ahí. El proyecto también guarda lo que un agente necesita saber del repo: una descripción que lee al arrancar, qué agente va en cada etapa, cómo levantar la app en el sandbox y dónde corre en producción.

Una tarea puede no tener proyecto (una investigación, una pregunta), pero un agente que trabaja sobre código se queda bloqueado hasta que le vincules uno.

Antes de empezar

• Para crear o editar un proyecto necesitás el rol admin del workspace. En un proyecto subido, con el rol developer alcanza para subir una versión nueva de la carpeta e integrar la rama de una tarea. Con un rol menor la página se ve, pero el script de arranque queda de sólo lectura.
• Si el repo es privado, necesitás una de dos cosas: la GitHub App instalada en tu organización o un token de GitHub. Los dos se explican en Git y GitHub.
• Para que la plantilla de etapas sirva, creá antes los agentes. La plantilla lista las columnas del tablero que no son ni de inicio ni de fin: en el tablero de fábrica, “In progress”.

Conectar un repo

1. Abrí “Proyectos” en la barra lateral y tocá “Nuevo proyecto” (o la tecla N).

2. Escribí el “Nombre”. Es único dentro del workspace y es lo que vas a ver en las tarjetas del tablero, así que conviene uno corto (conduit-api, no “API de Conduit versión nueva”).

3. En “Origen del código” dejá elegido “Repositorio Git” (viene así). La otra opción, “Subir carpeta”, se explica en Crear un proyecto desde una carpeta.

4. En “Acceso al repositorio” elegí cómo entra Thulu al repo. El modal preselecciona la opción que menos decisiones pide:

   • “GitHub App”: aparece sólo si el operador configuró la App. Elegís la organización y el repo de dos listas, y Thulu completa la URL, el nombre (si estaba vacío) y la rama por defecto. Si la App todavía no está instalada en tu organización, “Conectar GitHub” te lleva a GitHub y, al volver, el modal se reabre con lo que ya habías escrito. Si tu usuario no es admin de la organización, GitHub deja la instalación pendiente hasta que un admin la apruebe.
   • “Credencial guardada”: elegís un token de la página de credenciales. Con “Nueva credencial…” lo cargás ahí mismo: nombre, “Token de acceso personal” y “Guardar credencial”. Thulu lo prueba contra GitHub al guardarlo; si GitHub lo rechaza, queda guardado igual y un aviso te dice que no va a poder clonar. Un token clásico necesita el permiso repo (y workflow si los agentes van a disparar Actions).
   • “Repo público”: clona sin credencial.

   

   Al elegir acme/pagos-api, Thulu completó el nombre, la URL y la rama. "Instalar en otra organización" lleva a GitHub para sumar otra organización.

5. Pegá la “URL del repositorio” (HTTPS, por ejemplo https://github.com/org/repo.git). Una URL SSH de GitHub se convierte sola a HTTPS.

6. Revisá la “Rama por defecto”. Vacía, el proyecto usa la que tiene el repo.

   

   Lo obligatorio y la descripción entran arriba. Tablero y plantilla están en "Más opciones".

7. Escribí la “Descripción”. Va en el prompt de cada corrida que trabaja sobre el proyecto, así que sirve para lo que el agente no puede deducir del código: qué hace el repo y qué no tiene que tocar.

8. Abrí “Más opciones” si querés cambiar lo que queda:

   • “Tablero por defecto”: podés dejarlo en “— el de la instancia —”. Sólo se usa cuando una tarea se crea sin tablero (por la API o un agente desde un chat). Desde el tablero, una tarea nueva queda siempre en el tablero que tenés abierto.
   • “Plantilla de etapas”: el agente por defecto de cada etapa. La tabla lista las columnas que no son ni de inicio ni de fin. Una tarea nueva con este proyecto vinculado arranca con esos agentes ya asignados.

9. Tocá “Crear”. El modal se cierra y el clon sigue en segundo plano: la tarjeta dice “Clonando” hasta que termina y la página del proyecto se actualiza sola. Si el clon falla, la tarjeta dice “Falló el clon” con la causa (por ejemplo, que no se encontró el repositorio) y el detalle técnico de git plegado. Un clon fallido no se reintenta: borrá el proyecto y crealo de nuevo cuando esté resuelta la causa.

Cada tarjeta muestra la URL, la descripción y la rama por defecto; si la plantilla tiene agentes, también cuántas etapas los tienen ("2 por defecto"). Un clic abre el proyecto.

La plantilla desde el tablero

El selector “Agente por defecto” en la configuración de una columna del tablero escribe la plantilla de los proyectos de ese tablero. Si el proyecto ya existe, también la podés cambiar en su pestaña “Configuración”. El agente de cada tarea se puede asignar a mano en su panel.

Crear un proyecto desde una carpeta

Si el código no está en GitHub, o no querés darle a Thulu acceso a tu organización, podés subir la carpeta del proyecto. Thulu guarda el repositorio por su cuenta y los agentes trabajan sobre él igual que sobre un clon de GitHub: una rama task-<id> y un worktree por tarea, el script de arranque y la caché de dependencias funcionan igual.

Lo que cambia es la salida. Un proyecto subido no tiene pull requests, ni CI, ni revisión en GitHub, y las tools de GitHub de los agentes no aplican. El trabajo de una tarea vuelve a la rama principal con “Integrar en…” desde la tarea, y el código sale con “Descargar .zip” desde el proyecto.

Conviene	Cuando
“Repositorio Git”	El equipo trabaja en GitHub y quiere revisar cada cambio en un pull request, con CI y deploys por Actions.
“Subir carpeta”	El código está en tu computadora o te llegó en un .zip, no hay GitHub de por medio, o es un prototipo en el que alcanza con integrar y descargar.

1. En “Proyectos”, tocá “Nuevo proyecto” y, en “Origen del código”, elegí “Subir carpeta”.

2. Arrastrá la carpeta del proyecto al recuadro o tocá “Elegir carpeta” (el navegador puede pedirte que confirmes la subida). También sirve un .zip con “Elegir .zip”; si todo el zip está dentro de una carpeta, Thulu la saca.

3. Revisá lo que el navegador dejó afuera antes de mandar nada. El recuadro muestra cuántos archivos quedan y cuánto pesan, y dos listas desplegables:

   • “archivos afuera por parecer secretos”: .env y .env.<algo> (salvo .env.example, .sample, .template), claves privadas (id_rsa, *.pem, *.key), .aws/credentials, .netrc y parecidos.
   • “carpetas afuera”: node_modules, .venv, __pycache__, .next, .cache y otras carpetas de dependencias o caché, estén donde estén.

   El daemon vuelve a aplicar las mismas reglas cuando llega la subida. Los enlaces simbólicos tampoco se suben.

   

   El nombre se completa con el de la carpeta. Lo que queda afuera se ve antes de tocar "Crear".

4. Si querés cambiar el “Nombre”, hacelo ahora: Thulu lo completó con el de la carpeta. Escribí la descripción y abrí “Más opciones” para el tablero y la plantilla, igual que en Conectar un repo.

5. Tocá “Crear”. El botón pasa por “Empaquetando…” y “Subiendo…”, con una barra de progreso, y el modal muestra el resultado.

   

   Sin .git, la carpeta es el primer commit de main.

6. Tocá “Abrir proyecto”. En la lista, la tarjeta dice “Subido a Thulu” donde un proyecto clonado muestra la URL.

Si la carpeta trae su .git con commits, Thulu conserva el historial, las ramas y los tags, y la rama a la que apunta su HEAD pasa a ser la rama por defecto (“Se conservó el historial. main está en …”). Lo que difiere de ese commit entra arriba como un commit nuevo. Sin .git, la carpeta es el primer commit de main.

Límites: 200 MiB comprimido, 20.000 archivos y 1 GiB descomprimido. La subida cuenta para la cuota de almacenamiento del workspace. thulu export lleva el repositorio de un proyecto subido dentro del bundle, porque no hay un remoto de donde volver a traerlo.

El código de un proyecto subido

En un proyecto subido, la pestaña “Repositorio” muestra el panel “Código” en lugar de “Acceso a GitHub”, y el botón “Repo” de arriba no aparece.

Arriba se baja una rama; abajo se sube la carpeta entera como un commit nuevo en main.

Para bajar el código, elegí la “Rama” y tocá “Descargar .zip”. La lista trae la rama principal, las que venían en el .git de la carpeta y, en “Ramas de tareas”, la de cada tarea con su título una vez que la tarea se integró o publicó su rama.

Para cambiar el código desde tu computadora, subí la carpeta entera de nuevo:

1. Descargá la rama principal con “Descargar .zip” y trabajá sobre esa copia.
2. En “Versión nueva”, arrastrá la carpeta o tocá “Elegir carpeta” (o “Elegir .zip”). Valen las mismas exclusiones que al crear el proyecto.
3. Tocá “Subir versión nueva”. El panel confirma “Commit nuevo 0237388 en main.” o, si la carpeta es igual al último commit, “No cambió nada en main”.

La versión nueva reemplaza main entera

Lo que subís pasa a ser main: los archivos que no están en la carpeta se borran en ese commit y los que cambiaron se pisan. Una carpeta que sale de un .zip descargado acá sabe de qué commit viene: si main se movió desde entonces (por ejemplo, se integró una tarea), Thulu frena y ofrece “Integrar los cambios”, que trae lo nuevo de main y pone tus cambios encima, o “Reemplazar igual”, que deja main igual a tu carpeta y deshace esos commits. Si los mismos archivos cambiaron en tu carpeta y en main, bajá la rama de nuevo y pasale tus cambios. Una carpeta que no salió de un .zip de Thulu no trae ese dato. El .git de la carpeta se ignora en una versión nueva; los commits anteriores quedan en el historial del proyecto.

Integrar la rama de una tarea

En un proyecto clonado de GitHub, el trabajo de una tarea llega a main por un pull request. En un proyecto subido, lo llevás vos con “Integrar en…”, que aparece en la fila “Rama y PR” del panel de la tarea cuando la tarea ya tiene rama. Si todos los proyectos de la tarea son subidos, “Forzar PR” no aparece, ni en la fila ni en el menú “…”.

1. Abrí la tarea y, en “Rama y PR”, tocá “Integrar en…”.
2. En “En la rama” elegí el destino; viene la rama principal. Si la tarea tiene varios proyectos subidos, primero elegís el “Proyecto”.
3. Tocá “Integrar”.

La nota del modal dice qué va a pasar con la rama elegida.

Antes de integrar, Thulu commitea lo que el agente dejó sin commitear en el worktree y publica la rama en el repositorio del proyecto, poniéndola sobre la main actual. Después avanza main hasta la rama de la tarea si main no se movió, o crea un commit de merge si se movió. Aparece el aviso “Integrada en main (f20ef2c)” y la actividad de la tarea suma “Integró task-… en main”. La tarea sigue en su etapa: movela vos cuando corresponda. Si main ya tenía todo, el aviso dice “main ya tiene todos los commits de la tarea”.

El evento de la integración guarda el commit.

Si algún archivo choca con la rama destino, Thulu no escribe nada y el modal los lista:

Otra tarea ya había cambiado las mismas líneas de src/routes/recetas.js.

La rama de la tarea arrancó de una main que ya no existe, y hay que rehacer el cambio sobre la actual. El modal ofrece dos salidas:

• “Rehacer sobre main” crea una copia de la tarea, con “(rehecha sobre main)” en el título y una nota en la descripción que lista los archivos que chocaron. La copia arranca una rama nueva desde la main actual cuando sale de la primera columna. Integrá la copia y borrá la original.
• “Devolver al agente” aparece sólo con agentes en Kubernetes, donde el agente puede traer main a su rama y resolver en su copia. Deja un comentario con la lista de archivos: si hay una corrida trabajando en la tarea lo recibe en el momento, y si no, lo lee la próxima. Con agentes en Docker el agente ve el .git en sólo lectura y no puede resolverlo, así que el botón no aparece.

La página del proyecto

Al abrir un proyecto ves cuatro pestañas. Arriba a la derecha, “Tareas” abre el tablero por defecto del proyecto con el buscador filtrado por su nombre, y “Repo” abre el repo en GitHub.

Pestaña	Qué tiene
“Resumen”	Métricas del trabajo sobre el proyecto en un rango de fechas: tareas abiertas y terminadas, lead time, retrabajo, corridas, costo y dónde se acumula el tiempo por etapa.
“Entornos”	Dónde corre el repo (dev, staging, prod) y la conexión con la nube, la telemetría y Evidencia.
“Repositorio”	Con qué credencial o instalación de la GitHub App entra a GitHub (en un proyecto subido, el panel “Código”), el script de arranque con su caché de dependencias, los prompts y hooks por etapa y los worktrees activos.
“Configuración”	Nombre, URL, rama, tablero, descripción y plantilla, y “Eliminar proyecto”.

El Resumen se calcula con las tareas vinculadas al proyecto. Los presets 24h, 7d, 30d y 90d cambian el rango.

Las métricas del Resumen y cómo leerlas están en Métricas y dashboards. “Abiertas” cuenta todas las tareas sin terminar, también las que esperan en la primera columna, y “Caché del modelo” se refiere a la caché de prompts del modelo, no a la de dependencias.

Nota

El rango del Resumen se fija al cargar la página. “Actualizar” vuelve a pedir ese mismo rango, así que una tarea que termina después de abrir la página no aparece hasta que tocás un preset o recargás.

Escribir el script de arranque

El script de arranque dice cómo levantar el proyecto dentro del sandbox de una tarea: qué instalar, qué servicios arrancar y en qué puerto escucha la app. Los agentes lo corren con la herramienta init_run del MCP de sandbox en vez de adivinar los comandos, y si se rompe (una dependencia nueva, un puerto que cambió) lo corrigen y lo guardan como revisión nueva, que queda en el historial y en la auditoría con el agente como autor. Sin script, cada tarea empieza de cero. El sandbox en sí se explica en Sandbox.

1. Abrí el proyecto y la pestaña “Repositorio”. El panel “Script de arranque” muestra la revisión vigente, quién la guardó y su nota.

   

   La revisión 2 la guardó un agente: el rótulo "Agente" y la nota dicen qué cambió.

2. Escribí el “Script”. Es bash, corre desde el workdir y recibe los parámetros como variables de entorno. Un proyecto nuevo arranca con #!/usr/bin/env bash y set -euo pipefail. Si Thulu reconoce el stack por un archivo de la raíz del repo (npm, pnpm, Yarn, Go o pip), el panel dice “Este repo parece …” y ofrece “Arrancar desde una plantilla”, mientras el proyecto no tenga ninguna revisión guardada. El script tiene que dejar la app corriendo en segundo plano y terminar.

3. Si el script necesita valores que cambian por tarea, agregalos con “Agregar parámetro”: nombre en mayúsculas (PORT), default, descripción y “Obligatorio”. Los nombres que empiezan con OCTOPUS_ están reservados.

4. Completá “Puertos” (donde escucha la app, separados por coma) y el “Comando de listo”: un comando que sale con 0 cuando la app ya responde, por ejemplo curl -fsS http://localhost:3000/. init_run lo repite hasta que pasa o hasta el “Timeout de listo (s)” (300 por defecto, hasta 900). “Workdir” es la carpeta del repo donde corre el script; . es la raíz.

5. Escribí una “Nota” (opcional) con qué cambió y por qué: es lo que se ve en el historial.

6. Tocá “Guardar”. Aparece “Guardado como revisión N”.

Fase de instalación y snapshot

Instalar dependencias es lo que más tarda al levantar un proyecto. La sección desplegable “Fase de instalación” separa la instalación del arranque para que Thulu pueda saltearla o restaurarla de un snapshot.

Un lockfile que no existe en la rama por defecto se marca en rojo: sin él, el setup nunca se vuelve a disparar.

Campo	Qué poner	Ejemplo
“Setup”	Los comandos que instalan dependencias. Corre antes del script y se saltea si su resultado ya está.	npm ci
“Herramientas”	Versiones de lenguajes, como nombre=versión separadas por coma. Se instalan con mise una vez por workspace. Vacío usa el mise.toml o .tool-versions del repo.	go=1.25.1, node=22
“Lockfiles”	Archivos cuyo contenido define las dependencias. Si cambian, el setup vuelve a correr.	package-lock.json
“Directorios de caché”	Lo que deja armado el setup y se guarda en el snapshot. Rutas relativas al workdir.	node_modules
“Archivos de apoyo”	Archivos que el script usa y el repo no trae (un seed, un servidor estático). Se guardan en Thulu y el script los lee desde $OCTOPUS_INIT_FILES. Nunca se escriben en el repo.	seed-usuarios.mjs

Cuando init_run corre en una tarea, hace esto en orden: instala las herramientas (de la caché si ya están), y después saltea el setup si ese checkout ya instaló con los mismos lockfiles, o restaura el snapshot si hay uno para esa versión, o corre el setup con las cachés de paquetes del workspace ya llenas. Recién entonces corre el script.

El snapshot lo arma el precalentado, desde la rama por defecto y en un sandbox aparte: cuando guardás una revisión que cambia los lockfiles o el setup, cada 10 minutos si cambiaron en la rama por defecto, y a mano con “Precalentar ahora”. La línea “Último snapshot” muestra la clave, la fecha y el tamaño. Una tarea cuya rama cambió los lockfiles no usa el snapshot: corre el setup, que igual baja menos porque los paquetes ya están en la caché del workspace.

El precalentado necesita el runtime de sandboxes

Si la instalación no corre sandboxes, el bloque dice “Los snapshots necesitan el runtime de sandboxes, que esta instalación no corre.” y no hay botón. Si el precalentado falla, la línea “Último precalentado” dice el motivo en palabras (la imagen del sandbox no está, falló el setup en la rama por defecto, no apareció ningún directorio de caché, tardó demasiado) con el detalle técnico plegado. Si un lockfile que nombraste no está en la raíz de la rama por defecto, el panel lo avisa. “Precalentar ahora” usa la revisión guardada: con cambios sin guardar te pide guardar primero.

El panel “Caché de dependencias” de Infraestructura muestra, para el operador, la tasa de aciertos, cuánto tiempo se ahorró en esa instalación y cuánto ocupa la caché de cada workspace.

Historial y restaurar

Cada guardado, tuyo o de un agente, es una revisión que no se borra. Las de un agente llevan el rótulo “Agente” y dicen qué agente la guardó, en qué etapa y en qué tarea, con link a la tarea (“desarrollador en Desarrollo · tarea #578dfc”). El cambio también queda en la auditoría del workspace.

1. En el panel “Script de arranque” tocá “Historial”.
2. Elegí una revisión de la lista. A la derecha ves sus puertos, comando de listo, parámetros y el script.
3. Tocá “Restaurar esta revisión” y confirmá. Se guarda de nuevo como la revisión más nueva; la que estaba vigente queda en el historial.
4. “Volver al editor” te devuelve al formulario.

Restaurar nunca pisa: copia la revisión elegida como una nueva.

Vincular tareas a un proyecto

Al crear la tarea

En el modal “Nueva tarea”, “Repos” muestra los proyectos del workspace como chips: tocá los que la tarea va a tocar. Al crearla, la tarea toma los agentes de la plantilla de cada proyecto elegido. Si elegís varios y dos plantillas ponen agentes distintos en la misma etapa, gana el del proyecto que aparece primero en la lista.

El chip elegido queda con borde. Los repos son opcionales.

En una tarea existente

En el panel de la tarea, la propiedad “Proyectos” tiene un lápiz (“Editar los proyectos vinculados”). Buscá el proyecto y elegilo; para desvincular, sacalo de la misma lista.

Una tarea con dos proyectos tiene una rama y un worktree por repo.

Vincular un proyecto acá no aplica su plantilla: si la tarea no tenía agentes, asignalos a mano en “Agente”.

Una tarea que toca varios repos tiene una rama task-<id> y un pull request por proyecto. Si la creás por la API sin tablero y sus proyectos tienen distinto “Tablero por defecto”, Thulu la rechaza hasta que nombres uno.

Entornos

La pestaña “Entornos” describe dónde corre el repo de verdad. Con un entorno nombrado, un agente puede preguntar por la tasa de errores de prod en lugar de la del proyecto en general, y Evidencia sabe contra qué URL correr sus casos.

1. En “Entornos” tocá “Agregar entorno”.
2. Completá el nombre (en minúsculas: dev, staging, prod) y, si querés, un “Nombre visible” para Evidencia y un “Sistema” (el mismo valor en todos los repos de un mismo despliegue).
3. Elegí el proveedor. Hoy Thulu lee métricas de AWS y Google Cloud; Prometheus y “Otro” se pueden registrar pero no se recolectan.
4. Completá “Región”, “Cuenta” (id de cuenta de AWS o id de proyecto de GCP), “URL” y, si hace falta, “Selectores” (un clave=valor por línea para acotar los recursos).
5. Marcá “Producción” si es el entorno productivo. En Evidencia, editar un entorno de producción pide el rol admin.
6. Elegí la credencial de la nube o creá una ahí mismo, y tocá “Guardar”.

Cada entorno muestra su conexión y, debajo, cómo lo usa Evidencia. Los íconos de la derecha son recolectar, telemetría, editar y borrar.

Lo que cada entorno habilita está en otras páginas: las métricas, la telemetría y los dashboards en Métricas y dashboards, y las pruebas contra el entorno (logins de prueba, horario, entorno Sandbox) en Evidencia.

Configuración, prompts y hooks por etapa

La pestaña “Configuración” tiene los mismos campos que el alta (salvo el acceso a GitHub, que está en “Repositorio”) con su propio “Guardar”. Cambiar la plantilla no toca las tareas que ya existen.

La plantilla y el borrado viven en esta pestaña.

Los prompts y hooks por etapa están en la pestaña “Repositorio”, en el panel “Prompts y hooks por etapa”. “Administrar” abre un modal con una fila por etapa:

• Un prompt por etapa es texto que se suma al prompt del agente cuando trabaja en esa etapa sobre este proyecto (“en Revisión, corré npm test antes de aprobar”).
• Un hook es un script que corre dentro del worktree antes de que arranque el agente. Su salida y su código de salida entran al prompt. Sirve para darle al agente un dato fresco (el resultado de los tests, el estado de las migraciones) sin que tenga que pedirlo.

Tocá “+” en la etapa, escribí el archivo y guardalo con el botón o con ⌘S. Si borrás una etapa del tablero, sus archivos quedan como “Archivos huérfanos” con un botón “Limpiar”.

Prompts y hooks se definen por proyecto y por etapa.

Consejo

El script de arranque y el hook resuelven cosas distintas. El script lo corre el agente cuando necesita la app levantada; el hook corre siempre, antes de cada corrida de esa etapa, y su salida va directo al prompt.

Eliminar un proyecto

Desde el tacho de la tarjeta en “Proyectos” o desde “Eliminar proyecto” en la “Zona de peligro” de “Configuración”. Thulu pide confirmación, borra el clon y todos los worktrees, y las tareas vinculadas se quedan sin proyecto. No se puede deshacer, y las ramas de las tareas que no se pushearon se pierden con el clon: pusheá antes lo que quieras conservar. En un proyecto subido no hay remoto: Thulu borra también el repositorio que guardaba, así que descargá antes las ramas que quieras conservar.

Problemas comunes

El alta falla al guardar

Thulu valida la URL antes de clonar: rechaza rutas locales, protocolos que no sean HTTPS y URLs con usuario y contraseña adentro. Si el clon falla por permisos, el repo es privado y elegiste “Repo público”, o la credencial no tiene acceso a ese repo. Un nombre repetido en el workspace también se rechaza (“ya hay un proyecto llamado … en este workspace”).

• El agente no arranca en una tarea con proyecto. Mirá si la tarea tiene agente en esa etapa. La plantilla se copia sólo al crear la tarea con el proyecto ya vinculado.
• El agente vuelve a instalar todo en cada tarea. El script no tiene “Fase de instalación” o le faltan “Directorios de caché”: sin eso no hay snapshot. Si el bloque de snapshot dice “Completá setup y directorios de caché, y guardá”, es eso.
• “Integrar en…” no aparece. La tarea todavía no tiene rama (sigue en la primera columna) o ninguno de sus proyectos es subido. En una subtarea tampoco: la rama es de la tarea madre.
• “Crear” con “Subir carpeta” no sube nada. Si el recuadro dice “No quedan archivos para subir…”, la carpeta tenía sólo dependencias o secretos. Si el aviso dice “La subida pesa … el límite es 200 MiB”, dejá afuera los builds o los archivos pesados y probá de nuevo.
• “Precalentar ahora” no aparece. Hace falta el rol admin y una instalación con runtime de sandboxes.
• La tarjeta del proyecto dice “Falló el clon”. La causa está en el aviso de la página del proyecto; resolvela (URL, rama, credencial), borrá el proyecto y crealo de nuevo.
• El agente cambió el script y ahora no levanta. Abrí “Historial”, compará con la revisión anterior y restaurala.

Relacionado

Git y GitHubGitHub App, tokens, ramas y pull requests de las tareas.

SandboxDónde corre el script de arranque y qué puede hacer el agente ahí.

Tableros y etapasPrender "Correr un agente" en las etapas de la plantilla.

EvidenciaCasos de prueba que corren contra los entornos del proyecto.

TareasCrear tareas y elegir sus repos.

Métricas y dashboardsEl Resumen del proyecto y las métricas de cada entorno.