Proyectos, sesiones y git
Cada sesión trabaja en su propia rama; los pull requests se siguen por ti.
Apunta motita a un repositorio y se convierte en un proyecto. Todo lo que hace una sesión ocurre en una copia aislada, así que puedes correr varios trabajos a la vez sin que se pisen entre sí ni toquen tu copia de trabajo.
Sesiones y worktrees
- Cada sesión de un proyecto tiene su propio git worktree en su propia rama (
motita/<sesión>). Las carpetas de dependencias comonode_modulesse enlazan en vez de reinstalarse. - Cada turno es un punto de control. Vuelve a cualquier turno; la conversación retrocede, y los archivos también si lo pides.
- Pídele al agente que integre su trabajo: hace commit y fusiona la rama en la del proyecto. La sesión pasa a solo lectura y continuar abre una nueva desde la base actualizada.
- Borrar pregunta primero. Ves exactamente qué archivos sin confirmar se perderían.
- Se leen los archivos de instrucciones:
AGENTS.md(oCLAUDE.md) desde la raíz de git hacia abajo, y tu propio~/.motita/AGENTS.md. Guían cómo trabajar y nunca pasan por encima de tu petición ni de tu configuración de seguridad.
Hosts de git
Conecta GitHub, GitLab, Bitbucket, o un GitLab, Gitea o GitHub Enterprise propio, una sola vez, desde Ajustes → Conexiones git o con /git connect. GitHub inicia sesión con un clic. Los otros hosts necesitan una aplicación OAuth tuya o un token que creas a mano; un token hace todo lo que hace el inicio de sesión y se valida antes de guardarse.
Después, git clone, pull y push funcionan dentro de una sesión. Las credenciales solo van a comandos que aprobaste y se guardan en ~/.motita/auth/ con permisos solo para tu usuario, nunca en el archivo de configuración.
Pull requests y CI
- Los mensajes de commit y los títulos de pull request deben ser semánticos (
tipo(ámbito): descripción); cualquier otro se rechaza antes de crearse. - El agente abre un pull request con
motita forge pr create(te pregunta antes) y te da su enlace. - Desde ese momento el gateway sigue el CI, las revisiones y el estado de la fusión sin usar el modelo, así que esperar no gasta tokens. Cuando falla un job o alguien comenta, se envía al agente a arreglarlo, hasta un límite que tú fijas (5 por defecto).
- Un proyecto puede fusionar solo (
auto_merge) y abrir la siguiente sesión solo (auto_continue).
Agentes en segundo plano
Un trabajo con partes independientes no tiene que hacerse pieza por pieza. El agente puede iniciar agentes en segundo plano, cada uno en su propia rama, hasta agent.max_parallel (3 por defecto). Cada uno tiene un rol: code escribe, review y research leen y no cambian nada. Ves el propósito, estado, tiempo y costo en tokens de cada uno en la terminal (Ctrl+G) y en el panel de agentes del navegador.