Tareas de código

El tablero de código convierte una tarea escrita en código fusionado con tan poca ceremonia como quieras: escribe lo que necesitas y luego elige Planificar primero —dividirla en fases revisables con un agente de planificación interactivo— o Iniciar directamente, mira al agente trabajar en su propio worktree de git, revisa el diff con comentarios anclados a líneas e intégralo: el agente que escribió el cambio lo fusiona (o abre la pull request) en cuanto lo apruebas. Cada etapa es una columna; cada tarea está en una de ellas.

En la barra lateral, la sección Tareas de código está justo debajo de Sesiones, encima de Automatizaciones y Máquinas virtuales. Su cabecera muestra cuántas tareas hay abiertas, una insignia naranja que cuenta las tareas que esperan en Revisión, una insignia roja cuando un agente te necesita y un + para una tarea nueva. Debajo, una línea resume el tablero (2 planificadas · 1 en curso · 1 por revisar), o dice No hay tareas abiertas cuando el tablero está vacío. Haz clic en el título de la sección (Abrir Tareas de código (⇧⌘T)) o en esa línea para abrir el tablero titulado Tareas de código; también puedes pulsar ⇧⌘T (Espacios de trabajo › Tareas) o elegir Tareas de código en la paleta ⌘K.

Todo lo de esta página funciona igual desde un cliente enriquecido remoto — el tablero, la ventana de planificación y la ventana de revisión se reflejan todos por la API de control.

Escribir una tarea

Nueva tarea en la parte superior del tablero, el + de la cabecera Tareas de código de la barra lateral, o hacer clic en una tarea del Backlog abre el editor:

• Un Título y una descripción escrita en Markdown, con un conmutador Escribir / Previsualizar. La descripción se convierte en el prompt del agente, así que escríbela como tal.
• Espacio de trabajo y Agente — la tarea se ejecuta en la máquina elegida (un espacio de trabajo, en el editor de ajustes) con uno de los agentes disponibles en ella.
• Iniciar el agente en — una carpeta dentro de la máquina. Cuando es un repositorio de git por derecho propio, la tarea se ejecuta ahí en un worktree y una rama nuevos.
• Crear carpeta y repositorio de git si hace falta — para trabajo desde cero: iniciar o planificar ejecuta primero mkdir + git init (con un commit raíz vacío) cuando la carpeta no es ya su propio repositorio. Déjalo desactivado para una carpeta dentro de un repositorio existente.
• Al aprobar — cómo sale la tarea de Revisión: Predeterminado del espacio de trabajo (la elección de la máquina, que a su vez sigue los Ajustes; ver General), Fusionar en la rama o Abrir una pull request.

Una tarea nueva empieza en el espacio de trabajo y la carpeta que usaste por última vez.

Una tarea en el Backlog ofrece dos botones:

• Iniciar manda la tarea a En curso: un agente nuevo hace todo el trabajo de forma autónoma en un worktree nuevo y te entrega el diff en Revisión. (No está disponible mientras la tarea se está planificando.)
• Planificar primero abre antes una sesión de planificación.

Iniciar comprueba antes de que nada se mueva: la máquina arranca si hace falta, y luego la carpeta debe existir y ser un repositorio de git por derecho propio (o Crear carpeta y repositorio de git si hace falta debe estar activado). Mientras comprueba, la tarea se queda en su columna con un indicador Iniciando…; solo pasa a En curso cuando el agente puede arrancar de verdad. Una tarea que no puede arrancar se queda donde estaba y muestra el motivo en rojo —una carpeta que falta, una carpeta que no es un repositorio—, así que el tablero (y GET /tasks) nunca muestra En curso una tarea que no se está ejecutando.

Cada tarea del Backlog muestra además quién la recoge: Asignar abre la elección (un agente nuevo, la Centralita, una sesión o una sala) y la tarea pasa a decir Asignada a nombre; Quitar asignación la saca de esa cola. Tareas nuevas: sin asignar en la parte superior del tablero fija a quién se asignan las tareas nuevas al crearlas.

Planificar

Planificar primero lanza una sesión de planificación visible e interactiva y abre su ventana: una vista de conversación nativa, sin necesidad de terminal. La sesión se abre con tu tarea; el agente explora el repositorio en solo lectura, narra lo que encuentra y hace preguntas cuando la tarea deja abiertas decisiones reales.

Las preguntas llegan como una tarjeta con pestañas — una pestaña por pregunta, un espejo exacto del selector que el agente muestra en su propia sesión. Las respuestas se recogen en local y siguen siendo editables hasta que pulsas Enviar, que manda el conjunto completo de una vez; un clic desafortunado nunca es definitivo. También puedes escribir respuestas libres en el compositor del pie de la ventana, o pulsar Abrir terminal para ver la sesión en crudo.

Cuando el agente tiene lo que necesita, registra el plan en el tablero —fases ordenadas en la columna Plan, cada una más o menos una pull request revisable de trabajo, con dependencias entre ellas— y guarda una visión general del plan. La ventana muestra entonces El plan está listo con el número de fases y un botón Cerrar, la pestaña de la sesión de planificación se cierra sola y su sesión se archiva, y la tarea sale del Backlog (sus fases la sustituyen; quítalas todas y vuelve).

La planificación está vigilada: si la máquina se reinicia, se cierra el agente o la sesión muere antes de registrar las fases, el indicador de la tarea termina con un motivo concreto —haz clic en Planificar primero para reintentar— en lugar de girar para siempre.

La columna Plan

Las fases están numeradas en el orden del plan y llevan:

• Una insignia de dependencia (un candado con números de fase) cuando la fase necesita que fases anteriores estén Hecho primero.
• Una insignia en cola cuando la has empezado antes de que sus dependencias terminaran — arranca automáticamente en el momento en que todas están Hecho.
• El nombre de su tarea padre.

Selecciona varias fases con las casillas y aparece la barra de selección: Iniciar N seleccionadas inicia cada una de ellas (las fases bloqueadas por dependencias se ponen en cola), Borrar suelta la selección, y Quitar retira toda la selección tras una sola confirmación. Editar una fase muestra su lista Depende de — cada fase hermana con una casilla, para que las dependencias se puedan reelaborar a mano.

Las fases se ejecutan de forma totalmente autónoma — no se espera ninguna intervención interactiva una vez iniciadas.

En curso

Una tarea iniciada arranca la máquina si hace falta, crea un worktree nuevo del repositorio y lanza el agente con la descripción de la tarea como prompt. El agente aparece como una sesión en la barra lateral como cualquier otra, así que puedes seguirlo en el chat. La tarea muestra el estado de su agente con las mismas palabras que la fila de la sesión en la barra lateral —Trabajando, Te necesita en rojo cuando el agente está bloqueado en una pregunta, Listo cuando el agente espera en su prompt sin haber entregado la tarea, En pausa cuando su sesión duerme—, además de cuándo empezó. Hacer clic en ella (Abrir la sesión en vivo de la tarea) pone esa sesión en escena; una sesión que ya no existe ofrece Reiniciar la sesión, y una tarea cuyo repositorio o rama ha desaparecido ofrece Empezar de nuevo (una ejecución nueva en una rama nueva). Un agente que muere al arrancar —un comando que falta, una opción errónea— se detecta en segundos: la tarea lo dice en rojo, con el estado de salida del agente, y ofrece Reiniciar la sesión. Cuando un mensaje para el agente encuentra texto ya escrito en su cuadro de entrada, Bromure no escribe encima: el mensaje espera a que el cuadro se vacíe y, si no ocurre, la tarea lo dice en rojo. La insignia Tareas de la barra lateral las cuenta para que no se te escape ninguna.

Al pasar por encima de una tarea En curso aparece un botón ✓ Hecho (Marcar como hecha, tras una confirmación: no se fusiona nada y la rama se conserva). Haz clic derecho para Abrir sesión, Reiniciar la sesión, Mover a Revisión, Marcar como hecha, Detener y volver al backlog (el agente se detiene; su worktree y su rama se quedan en el espacio de trabajo, la tarea vuelve al Backlog), Detener y descartar rama y Quitar solo la tarea. Arrastrar una tarea del Backlog o una fase a En curso la inicia. Una tarea entregada a una sesión o a una sala ofrece en su lugar Abrir sesión y Detener y volver al backlog.

Cuando el agente informa de que ha terminado, la tarea pasa a Revisión. Su sesión sigue abierta: los comentarios de revisión que devuelves llegan a la misma conversación, y cuando apruebas la tarea el mismo agente la integra. La sesión se archiva cuando la tarea se integra, se marca como hecha o se descarta, o tras unas dos horas en Revisión sin que pase nada; en ese caso, una devolución o una integración retoma la conversación del agente en una pestaña nueva. Si en cambio el agente falla, la tarea se pone en rojo en vez de fingir que trabaja.

Revisión

Una tarea en Revisión muestra su rama, sus comentarios de revisión y en qué punto está: Listo para integrar, Integrando — agente está fusionando en rama… (con la última línea del agente) o Te necesita — motivo en rojo (dos líneas en la tarjeta, todo al pasar por encima) con los botones Reintentar y Abrir sesión. Una tarea que no produjo código dice Sin cambios de código — lee el informe. Pasa por encima de una tarea para ver ✓ Hecho; arrástrala a Hecho para marcarla como hecha. Haz clic en ella para abrir la ventana de revisión — la misma ventana que se usa para revisar los cambios de una sesión, titulada Revisión — <tarea>, con los botones propios de la tarea.

Bajo la cabecera de la ventana, un resumen dice en qué punto está la rama: Kimi Code trabajó en wt/fix-login en Web app · ~/app · 3 commits · 4 archivos (+120 −7) frente a main · main ha avanzado 2 commits desde entonces · checkout de main limpio · remoto: origin.

La ventana muestra el diff de la rama, leído en vivo desde la máquina (así que la máquina debe estar en marcha), con desplegables por archivo, los recuentos de líneas añadidas y quitadas, los commits y el estado de la copia de trabajo, y el plan que el agente registró, si hay alguno. Un selector en la parte superior elige contra qué se compara el diff:

Revísala como una pull request:

• Marca archivos como mirados. Cada archivo tiene una marca Visto (Marcar como mirado — se pliega hasta que vuelva a cambiar). Un archivo visto se pliega, y se despliega por sí solo si su diff cambia.
• Comenta. Pasa por encima de una línea y haz clic en la burbuja del margen (Comentar esta línea) para comentar esa línea exacta, usa Comentar este archivo en una cabecera de archivo, o escribe en el compositor de abajo para un comentario sobre todo el cambio. En el compositor, ⏎ añade el comentario, ⌥⏎ inserta un salto de línea y ⇧⌘⏎ lo envía todo de vuelta. Los comentarios en borrador se pueden quitar antes de enviarlos.
• Devuelve. El botón de envío dice Devolver (N). Entrega todos los comentarios en borrador al agente en un solo mensaje —con el formato En foo.js, línea 196: usa otro método— y devuelve la tarea a En curso para otra ronda, en la misma conversación, worktree y rama (⇧⌘⏎).
• Intégrala. El botón principal sigue la elección Al aprobar de la tarea: Fusionar en rama o Abrir pull request (solo se ofrece cuando el repositorio tiene un remoto). Su menú contiene la otra opción, Squash y fusionar en rama, Fusionar en otra rama… y Conservar rama — marcar como hecha. Cada una abre una confirmación que dice exactamente lo que va a pasar (ver Integración), con una opción Conservar la rama.
• Marcar como hecha — hecha sin fusionar, tras una confirmación de que la rama se conserva.
• Más — Abrir sesión, Ver transcripción y Descartar rama… (borra la rama y su checkout; la tarea pasa a Hecho como cerrada sin fusionar, con su transcripción conservada).
• Abrir terminal salta a la sesión de la tarea en la máquina.

Una tarea que no produjo código —sin rama, una rama sin cambios frente a su destino, o una entrega delegada sin worktree— muestra el informe final del agente en lugar de git: su botón principal es Marcar como hecha, junto a Ver transcripción y Devolver.

Una tarea hecha por una sesión o una sala que ya abrió una pull request ofrece Ver pull request #N y Marcar como fusionada (una vez fusionada en la forja).

Haz clic derecho en una tarea en Revisión para Revisar cambios, Abrir sesión, Reintentar integración (cuando te necesita), Marcar como hecha, Fusionar en rama… (abre la revisión en su confirmación de fusión), Volver a En curso, Descartar rama… y Quitar solo la tarea. Descartar una tarea, o marcarla como hecha, dice cuántos comentarios de revisión que nunca llegaron al agente se van con ella.

Haz clic derecho en una tarea Hecha para Leer transcripción, Abrir sesión mientras su sesión siga viva, Abrir pull request cuando tenga una, y Quitar tarea. El menú de cada tarjeta es también su menú de VoiceOver (VO-Mayús-M) y su lista de acciones; VoiceOver lee una tarjeta como su título y su estado.

Integración

Aprobar una fusión integra el cambio sin que tengas que resolver nada a mano:

• Vía rápida. Cuando la rama va estrictamente por delante de su destino, su checkout no tiene nada sin commit y el checkout del destino está limpio, Bromure la fusiona él mismo: un fast-forward donde el destino está en checkout, o una actualización directa de la rama cuando no está en checkout en ningún sitio. Nunca fusiona en un checkout que esté en otra rama.
• La integra el agente. Si no, lo hace el agente que escribió el cambio, en su propia sesión —escrito en su conversación en vivo, o en esa conversación reanudada—: hace commit de lo que quede, hace rebase sobre el destino más reciente (resolviendo los conflictos conservando la intención de ambos lados), ejecuta las comprobaciones rápidas del proyecto y arregla lo que su cambio rompió, hace fast-forward del destino e informa. Nunca toca los cambios sin commit del checkout del destino. Una integración por pull request, en cambio, hace push de la rama y ejecuta gh pr create con un resumen y un plan de pruebas.
• Verificada. La tarea solo pasa a Hecho cuando Bromure ve el cambio en el historial del destino. Una integración que el agente informa pero que Bromure no puede comprobar (una máquina a la que no llega) se registra como informada por el agente, no verificada.
• Te necesita. Si el agente informa de que está bloqueado, se detiene sin integrar o no ha terminado tras 20 minutos, la tarea se pone en rojo con el motivo; la ventana de revisión ofrece Abrir sesión, Reintentar y Cancelar integración.

Después, la rama y su checkout se eliminan (salvo que los hayas conservado) y la sesión se archiva. Las tareas entregadas a una sesión o a una sala se integran igual: quien la tiene asignada recibe la petición de integración en la misma delegación e informa con deliver.

Consejo: no hace falta una tarea para revisar el trabajo de un agente. Toda sesión con una carpeta tiene Revisar cambios en su menú y en ⌘K, y la línea N archivos cambiados del chat abre la misma ventana para ese turno. Ver Ramas y revisión.

Quitar tareas

Cada tarea muestra una ✕ al pasar por encima (Quitar tarea), tras una confirmación. Para una tarea En curso, el diálogo ofrece Detener y descartar rama, que lo desmonta todo, o Quitar solo la tarea, que deja la sesión y el checkout intactos en la máquina; para una tarea en Revisión ofrece Descartar rama o Quitar solo la tarea. El menú de una tarea del Backlog tiene Quitar tarea.

Almacenamiento y API

Las tareas persisten en un solo archivo junto al almacén de máquinas, con escrituras atómicas y fechas ISO-8601:

~/Library/Application Support/BromureAC/tasks.json

Todo el tablero se refleja en el socket de control de la app, para clientes enriquecidos y guiones:

Por debajo, los agentes de planificación y de tarea hablan de vuelta con el tablero a través de un servidor MCP del tablero por sesión (vsock, del lado del anfitrión): board_get_task, board_set_plan, board_create_subtasks, board_ready_for_review y board_report_landing son la forma en que se registran las fases, en que una tarea terminada se anuncia y en que una integración informa merged, pr_opened o blocked, sin sondeos ni raspado. Las herramientas se conectan automáticamente para cada agente compatible: Claude Code carga una configuración MCP por rama, Codex recibe sobrescrituras mcp_servers por invocación, y Grok lee un .grok/settings.json con ámbito de proyecto escrito en el checkout de la sesión (y excluido de su diff).