Saltar al contenido principal
Una sesión de agente en TYBA no es una ventana de chat. Es un pipeline, y cada etapa la impone el core en Rust — la interfaz solo dibuja lo que él decidió. Entender estas siete etapas es entender el producto entero.

1. Crear

Describes la tarea. El core resuelve la raíz del repositorio y deriva un branch:
El sufijo aleatorio corto es lo que impide que dos sesiones sobre la misma tarea peleen por el mismo nombre de branch.

2. Worktree

git worktree add a partir de la base actual — y el SHA de la base se fija aquí. Eso es lo que hace utilizable la revisión del paso 5: todo diff que ves después es base_sha..HEAD. Un agente que pasó dos horas trabajando no te ahoga con todo lo que entró en main mientras tanto. Si el repositorio tiene un .tyba/setup.sh, se ejecuta ahora — es el lugar para hacer symlink del .env, correr bun install, levantar una base de datos por worktree.

3. Levantar

El PTY nace dentro del sandbox, con un entorno construido por allowlist. Tu DATABASE_URL y tus tokens simplemente no están ahí — el agente recibe seis variables y lo que el .tyba/config.toml del repositorio autorice, después de que lo apruebes. La escritura queda en el worktree y en temp. La lectura depende de la plataforma — y esa diferencia está en Plataformas.

4. Seguir

La sesión reporta estado: Cuando algo necesita tu aprobación, se convierte en un ítem del inbox con notificación nativa — y la sesión queda bloqueada hasta que respondas. Respondes ahí mismo, sin cambiar de ventana, y la respuesta se escribe directo en ese PTY. Qué necesita aprobación y qué pasa solo está en Clasificación de riesgo.
El estado no se adivina raspando la pantalla. TYBA inyecta hooks en el agente y escucha los eventos en un canal local: la herramienta que va a ejecutarse se vuelve Running, el fin de turno se vuelve Idle, y una petición de respuesta se vuelve AwaitingInput. Es el mismo canal que alimenta el inbox de aprobaciones — cómo TYBA habla con el agente.

5. Revisar

La revisión se construye solo desde el git local — no hay ida al GitHub. Timeline de commits, resumen por archivo, y los hunks cargados bajo demanda al hacer clic.
El diff de un lockfile tiene decenas de miles de líneas. Queda cerrado hasta que lo pidas.
Lo que el agente dejó sin commitear también aparece.

6. Integrar

Merge local, squash, o gh pr create a través de tu propio gh.
El push y el merge los ejecuta TYBA, fuera de la jaula. La sesión del agente nunca tuvo credenciales de red — y ese es exactamente el punto. El botón que aprueba un push vive dentro de la revisión, después de que hayas visto el diff.
Y, pase lo que pase: un push de agente a main o master lo rechaza el core. Siempre.

7. Limpiar

git worktree remove y recolección de los branches huérfanos.

Qué hacer ahora

Ejecuta dos sesiones a la vez en el mismo repositorio. Ahí es donde el diseño se ve: la sesión A editando src/ no ve ni pisa el árbol de la sesión B, y ninguna de las dos toca tu copia de trabajo.

Clasificación de riesgo

Lo que el agente hace solo y lo que te espera a ti.

Configuración

Entorno y agente por defecto, por repositorio.