5. Pestañas, sesiones en segundo plano, vista dividida, Fork y checkpoints

Objetivo del tema

Dominar las herramientas que permiten trabajar con varias tareas, comparar alternativas y recuperar estados anteriores: pestañas, ejecución en segundo plano, vista dividida, Fork y checkpoints.

5.1 Pestaña, sesión y tarea no son lo mismo

Una sesión guarda la conversación y su trabajo. Una pestaña es una vista abierta dentro de la interfaz. La tarea es el objetivo que el usuario asigna al agente.

Bionic puede abrir como pestañas:

• Sesiones de conversación.
• Archivos del proyecto y sus previsualizaciones.
• Páginas del navegador integrado.

Esta separación permite mantener visibles, por ejemplo, una conversación, el documento que está produciendo y una fuente web relacionada.

5.2 Administrar pestañas

Las pestañas se usan para cambiar rápidamente entre vistas sin perder el contexto de cada sesión. Una organización simple consiste en mantener abiertas sólo las vistas necesarias para la decisión actual.

Ejemplos de uso de pestañas

Combinación	Uso recomendado
Sesión + archivo generado	Comparar el pedido original con el entregable.
Dos sesiones	Supervisar tareas independientes o comparar dos enfoques.
Sesión + navegador	Revisar una fuente citada mientras se mantiene visible el análisis.
Archivo original + archivo revisado	Comprobar estructura, contenido y cambios entre versiones.

Las versiones recientes también permiten abrir en el navegador integrado enlaces locales como localhost o enviarlos al navegador del sistema.

5.3 Vista dividida

Para mostrar dos vistas lado a lado, arrastra una pestaña hacia la mitad izquierda o derecha del panel actual. Cuando aparezca el destino de acoplamiento, suelta la pestaña.

La vista dividida resulta especialmente útil para:

• Comparar dos respuestas obtenidas desde una bifurcación.
• Mantener el prompt visible mientras se revisa un archivo.
• Observar una sesión activa y trabajar en otra.
• Revisar código o un documento junto a la explicación del agente.

Algunos archivos editados ofrecen directamente la acción Open in Split. Esto evita tener que arrastrar manualmente la pestaña.

5.4 Sesiones en segundo plano

Cambiar de pestaña o de proyecto no detiene una sesión activa. Bionic continúa la tarea en segundo plano y muestra un indicador cuando termina. Esto permite aprovechar los tiempos de espera sin permanecer en una sola conversación.

Un flujo responsable consiste en:

1. Iniciar una tarea con un resultado claramente definido.
2. Cambiar a otra sesión sólo cuando la nueva tarea no dependa del resultado pendiente.
3. Observar los indicadores de actividad en las sesiones y proyectos.
4. Regresar al finalizar y revisar acciones, permisos y entregables.

No es necesario enviar mensajes repetidos para preguntar si terminó. El indicador de estado informa cuándo corresponde volver.

5.5 Límites del trabajo paralelo

Varias sesiones pueden ejecutarse al mismo tiempo, pero la independencia debe planificarse.

Paralelismo seguro y situaciones de riesgo

Situación	Evaluación	Recomendación
Dos investigaciones que producen archivos distintos.	Bajo riesgo de interferencia.	Pueden ejecutarse en paralelo.
Dos sesiones editan el mismo documento.	Riesgo de sobrescritura.	Usar copias con nombres distintos o trabajar en secuencia.
Dos sesiones modifican la misma rama Git.	Alto riesgo de conflictos e incoherencia.	Separar ramas, archivos o etapas antes de ejecutar.
Varias sesiones usan modelos cloud.	Consumo simultáneo de créditos.	Controlar Billing and Usage y limitar trabajos innecesarios.
Varias sesiones usan modelos locales grandes.	Competencia por RAM, VRAM y cómputo.	Reducir concurrencia o utilizar modelos/dispositivos diferentes.

5.6 ¿Qué es Fork?

Fork crea una rama de una sesión a partir de una respuesta elegible. La rama conserva el contexto hasta ese punto, pero permite continuar con instrucciones diferentes sin borrar el recorrido original.

En Bionic 1.1.1, las sesiones bifurcadas reciben nombre automático después de enviar el nuevo mensaje. También se corrigió el movimiento de sesiones para que trasladar un Fork no mueva accidentalmente su sesión padre.

5.7 Fork, nueva sesión o simple continuación

Elegir la operación correcta

Necesidad	Operación	Efecto
Corregir o ampliar el mismo resultado.	Continuar.	Agrega mensajes al mismo historial lineal.
Probar otra dirección desde un punto conocido.	Fork.	Conserva el contexto común y crea una rama independiente.
Empezar una tarea que no necesita ese historial.	Nueva sesión.	Comienza otro hilo dentro del proyecto.
Descartar lo ocurrido después de un estado anterior.	Rollback o rewind.	Regresa la sesión y los cambios administrados al checkpoint elegido.

5.8 Checkpoints automáticos

Bionic guarda checkpoints automáticos durante el trabajo. Estos puntos permiten revisar cambios y volver a un estado anterior cuando una iteración no resulta satisfactoria.

Un checkpoint es útil cuando:

• Una revisión empeora un documento que ya era correcto.
• El agente interpreta mal una instrucción y modifica varios elementos.
• Se desea experimentar y conservar una ruta de retorno.
• Una rama necesita regresar al punto anterior a una decisión.

Internamente, Bionic representa mensajes y recursos como nodos de un grafo dirigido. Sus puntos de sincronización permiten que el rollback y el Fork mantengan coordinadas la sesión principal y las sesiones auxiliares que participan en determinadas funciones.

5.9 Volver a un checkpoint

Para recuperar un estado anterior, localiza en la conversación la respuesta o punto que ofrece la acción de volver, rebobinar o restaurar. Antes de confirmarla:

1. Identifica qué mensajes y cambios se realizaron después del punto elegido.
2. Guarda por separado cualquier variante que quieras conservar.
3. Comprueba si intervienen Project Files, archivos externos o un repositorio.
4. Ejecuta la recuperación y revisa tanto el transcript como los archivos afectados.

5.10 Relación entre Fork y checkpoints

Ambas funciones parten de un estado anterior, pero persiguen objetivos opuestos:

• Fork conserva: mantiene el recorrido original y abre una alternativa.
• Rollback descarta: vuelve atrás dentro del recorrido elegido y elimina de la continuidad activa lo que vino después.

Si no estás seguro de querer perder la iteración actual, crea primero una rama o guarda el resultado con otro nombre. El rollback debe utilizarse cuando se comprende claramente qué estado se recuperará.

5.11 Práctica: comparar dos ramas lado a lado

La práctica utiliza archivos con nombres diferentes para evitar que las ramas sobrescriban el mismo resultado.

1. Crea un proyecto sin coding llamado Campaña de biblioteca.
2. En una sesión nueva, envía el prompt de preparación y espera la respuesta.

3. Sobre la respuesta con el resumen, elige Fork. Conserva abiertas la sesión original y la rama.
4. En la sesión original solicita una versión formal con el siguiente prompt.

5. En la rama creada con Fork solicita una versión cercana y juvenil.

6. Arrastra una pestaña hacia un lateral para mostrar ambas sesiones en vista dividida.
7. Abre version-formal.md y version-cercana.md y compara tono, exactitud y cumplimiento.
8. Renombra las sesiones como Anuncio formal y Anuncio cercano.

5.12 Práctica controlada de recuperación

Haz esta prueba sólo con un archivo descartable del proyecto:

1. Pide a una de las sesiones que cree prueba-checkpoint.md con tres líneas numeradas.
2. En el mensaje siguiente, solicita reemplazar todo su contenido por una sola palabra.
3. Localiza la acción de volver al checkpoint anterior a ese reemplazo.
4. Antes de confirmar, observa qué mensajes y archivos indica que se verán afectados.
5. Ejecuta la recuperación y comprueba si reaparecen las tres líneas.
6. Elimina el archivo de prueba sólo cuando hayas terminado el ejercicio.

Si tu versión o el tipo de respuesta no ofrece esa acción, no fuerces la prueba: consulta el menú de la respuesta y el changelog de la versión instalada.

5.13 Errores frecuentes

Problemas y prevención

Error	Prevención
Crear dos ramas que escriben el mismo archivo.	Asignar nombres de salida diferentes antes de ejecutar.
Confundir una pestaña con una copia independiente.	Recordar que dos vistas pueden mostrar el mismo recurso.
Iniciar tareas dependientes en paralelo.	Esperar el resultado anterior o materializarlo primero en un archivo.
Volver a un checkpoint sin revisar el alcance.	Identificar mensajes, archivos y acciones posteriores antes de confirmar.
Confiar en checkpoints como único respaldo.	Mantener Git o copias externas para material importante.

5.14 Resumen

• Las pestañas son vistas; las sesiones conservan el historial y la tarea.
• La vista dividida facilita comparar sesiones, fuentes y entregables.
• Las sesiones continúan trabajando al cambiar de pestaña o proyecto.
• Fork crea una alternativa sin destruir el recorrido original.
• Los checkpoints permiten regresar a estados anteriores, pero no sustituyen un respaldo independiente.
• El paralelismo requiere evitar que varias sesiones modifiquen el mismo recurso.

En el próximo tema compararemos en profundidad los modelos cloud, locales y remotos para elegir el más adecuado en cada tarea.

Fuentes oficiales consultadas: proyectos, sesiones y pestañas, presentación de Bionic y checkpoints, arquitectura de Fork y rollback, Bionic 1.1.0 y Bionic 1.1.1.