4. Proyectos, sesiones, chats sin proyecto y espacios de trabajo

Objetivo del tema

Aprender a separar y relacionar el trabajo en Bionic mediante proyectos, sesiones y chats sin proyecto; comprender qué contexto comparte cada nivel y diseñar una organización que siga siendo clara cuando aumentan las tareas y los archivos.

Versión de referencia: Bionic 1.1.1. Los chats sin proyecto, la creación simplificada de proyectos y el movimiento de sesiones entre proyectos forman parte de la evolución reciente de Bionic 1.1.x.

4.1 Las unidades de organización

Bionic utiliza varios niveles que cumplen funciones distintas. No deben confundirse un proyecto, una sesión, una pestaña y un archivo:

Una pestaña no agrega otro nivel de contexto: es simplemente una vista abierta de una sesión, un archivo o una página del navegador.

4.2 ¿Qué es un proyecto?

Un proyecto mantiene juntas las sesiones y los archivos que pertenecen a una misma iniciativa. Sirve como frontera de organización: lo que comparte propósito, fuentes o base de código suele pertenecer al mismo proyecto.

Ejemplos apropiados:

  • Sitio de comercio electrónico: distintas sesiones para pagos, accesibilidad y pruebas, todas sobre el mismo repositorio.
  • Investigación de mercado: sesiones separadas para competidores, clientes y síntesis, con documentos fuente compartidos.
  • Informe trimestral: hojas de cálculo, notas, gráficos y borradores reunidos en un solo lugar.

No conviene crear un proyecto por cada pregunta. Tampoco conviene reunir en uno solo trabajos que no comparten objetivo ni archivos, porque el espacio se vuelve difícil de revisar y aumenta el riesgo de utilizar una fuente equivocada.

4.3 El espacio de archivos de un proyecto

Los archivos que se arrastran al proyecto y los que Bionic crea aparecen en el panel derecho bajo Project Files. Estos recursos están disponibles para las sesiones del mismo proyecto.

Para trabajo documental, Bionic proporciona un espacio administrado y aislado donde puede crear y revisar entregables. Para programación, se puede habilitar acceso a un directorio local; Bionic lo indexa y, si es un repositorio Git, muestra también el repositorio y la rama.

Archivo del proyecto no significa archivo externo: un archivo externo conserva su ubicación original. Si Bionic recibe permiso para editarlo, la modificación se realiza sobre ese original. Antes de trabajar, confirma siempre la ruta y el tipo de recurso.

4.4 ¿Qué es una sesión?

Una sesión es un hilo de conversación y tarea. Conserva las instrucciones, respuestas y acciones necesarias para un trabajo concreto. Dentro de un mismo proyecto se crean sesiones distintas cuando las tareas necesitan historiales independientes.

Una sesión puede:

  • Renombrarse para describir mejor su objetivo.
  • Fijarse mediante Pin cuando debe permanecer visible.
  • Archivarse cuando terminó pero conviene conservarla.
  • Eliminarse cuando ya no debe conservarse.
  • Moverse a otro proyecto en versiones recientes de Bionic.

El nombre automático es un punto de partida. Renombrar una sesión al terminar la primera interacción facilita encontrarla semanas después.

4.5 Qué comparten las sesiones y qué no

Relación entre sesiones del mismo proyecto
Elemento ¿Se comparte? Implicación práctica
Project Files Sí Una sesión puede producir un archivo y otra puede utilizarlo como fuente.
Directorio de código asociado Sí, dentro de su alcance Varias sesiones pueden trabajar sobre el mismo repositorio; hay que coordinar cambios concurrentes.
Historial de mensajes No Una sesión nueva no debe depender de instrucciones dichas solamente en otro chat.
Objetivo inmediato No Cada sesión necesita una tarea y un criterio de finalización propios.
Modelo principal No necesariamente El model picker permite escoger un modelo adecuado para cada sesión.
Patrón de traspaso: cuando una sesión necesita aprovechar el trabajo de otra, guarda el resultado en un archivo del proyecto y referencia ese archivo en la nueva instrucción. Es más claro y verificable que suponer que comparte el historial anterior.

4.6 ¿Cuándo crear otra sesión?

Continúa en la misma sesión cuando el nuevo mensaje corrige, amplía o revisa el mismo entregable. Crea otra sesión cuando cambia la pregunta central, el rol, las fuentes que deben priorizarse o el resultado esperado.

Misma sesión o sesión nueva
Situación Decisión Motivo
Acortar un informe ya generado. Misma sesión. Es una revisión directa del resultado anterior.
Analizar otro conjunto de fuentes del mismo estudio. Sesión nueva. Separa el historial, pero conserva los archivos del proyecto.
Corregir una prueba después de implementar la función. Misma sesión. Forma parte del mismo ciclo de cambio y validación.
Revisar seguridad y accesibilidad del mismo sitio. Dos sesiones. Son criterios independientes que pueden investigarse en paralelo.
Iniciar un producto sin relación con el actual. Proyecto nuevo. No comparte objetivo, fuentes ni base de código.

4.7 Chats sin proyecto

Desde Bionic 1.1.0 se pueden abrir sesiones sin proyecto. Son apropiadas para consultas aisladas que no necesitan compartir archivos ni integrarse en una iniciativa duradera.

Usa un chat sin proyecto Para una explicación rápida, una lluvia de ideas descartable o una consulta que no necesita archivos compartidos.
Usa un proyecto documental Para investigación, informes o entregables que compartirán fuentes y archivos entre varias sesiones.
Usa un proyecto con coding Para inspeccionar o modificar una carpeta local, utilizar Git y ejecutar comandos sobre una base de código.

Si una consulta empieza a producir archivos valiosos o se convierte en una iniciativa de varias etapas, conviene trasladar su resultado a un proyecto y continuar allí.

4.8 Proyectos documentales y proyectos con código

Las primeras versiones distinguían visualmente proyectos Work y Code. Bionic 1.1.0 simplificó la creación y unificó el concepto de proyecto, incorporando capacidades de programación opcionales. Por eso pueden encontrarse ambos nombres en ejemplos o capturas anteriores.

  • Sin Allow coding, el proyecto se orienta a documentos y archivos dentro de un entorno administrado.
  • Con Allow coding, se elige un directorio de trabajo y Bionic puede buscar, editar, utilizar Git y ejecutar comandos dentro del alcance concedido.

No habilites coding para una tarea que no lo necesita. El acceso debe corresponder al objetivo de la sesión.

4.9 Espacio de trabajo: dos usos del término

En la interfaz y en la documentación, workspace puede aparecer con dos sentidos relacionados:

  1. Ventana o entorno general: el lugar de la aplicación donde se muestran proyectos, sesiones y pestañas.
  2. Espacio administrado de un proyecto: el conjunto de archivos con el que Bionic trabaja para producir entregables.

No debe interpretarse como un historial global que mezcla todas las conversaciones. La frontera operativa sigue siendo el proyecto y cada sesión mantiene su propio hilo.

4.10 Sesiones en segundo plano y trabajo paralelo

Al cambiar de pestaña o de proyecto, una sesión activa continúa trabajando. Esto permite ejecutar varias tareas, incluso en proyectos diferentes, sin esperar frente a una sola conversación.

El paralelismo es útil cuando las tareas son independientes. Si dos sesiones modifican simultáneamente el mismo archivo o repositorio, pueden interferir entre sí. En ese caso, divide el trabajo por archivos o etapas y espera a que una sesión termine antes de iniciar la siguiente.

Paralelo no significa descontrolado: cada sesión activa puede consumir memoria local o créditos cloud. También puede solicitar permisos o modificar recursos. Mantén visible qué modelo y qué alcance utiliza cada tarea.

4.11 Práctica: coordinar tres sesiones mediante archivos

Esta práctica demuestra que las sesiones mantienen historiales separados y se coordinan mediante Project Files.

  1. Crea un proyecto llamado Lanzamiento de una aplicación sin habilitar coding.
  2. Abre una sesión, renómbrala Requisitos y envía el primer prompt.
Crea requisitos.md a partir de estos datos: - Producto: aplicación móvil para organizar tareas de estudio. - Público: estudiantes universitarios. - Funciones iniciales: materias, tareas, fechas límite y recordatorios. - Restricción: primera versión en ocho semanas. Incluye alcance, requisitos funcionales y elementos que deben quedar fuera de la primera versión. No busques información en Internet.
  1. Crea otra sesión en el mismo proyecto, llámala Riesgos y envía:
Crea riesgos.md para el mismo producto con estos datos: - Equipo de dos desarrolladores. - Plazo de ocho semanas. - Los recordatorios requieren permisos del dispositivo. - Aún no se realizaron pruebas con estudiantes. Organiza el documento como una tabla con riesgo, impacto, probabilidad y mitigación. No leas requisitos.md y no busques información en Internet.
  1. Comprueba que requisitos.md y riesgos.md aparecen en Project Files.
  2. Abre una tercera sesión, renómbrala Plan integrado y envía:
Lee requisitos.md y riesgos.md del proyecto. Crea plan-inicial.md con: 1. Objetivo del producto. 2. Alcance de la primera versión. 3. Un cronograma de ocho semanas. 4. Los cinco riesgos prioritarios y su mitigación. 5. Criterios para decidir si la versión está lista. Señala cualquier contradicción entre las fuentes. No agregues funciones que no aparezcan en requisitos.md.
  1. Abre plan-inicial.md, revisa sus referencias y confirma que integra ambos archivos.
  2. Fija la sesión Plan integrado y archiva las dos sesiones preparatorias para practicar su administración.
Resultado esperado: un proyecto con tres archivos compartidos y tres sesiones con historiales distintos. La tercera sesión obtiene el contexto mediante archivos explícitamente indicados, no mediante los mensajes de las otras dos sesiones.

4.12 Convenciones de nombres

Una convención sencilla evita que la barra lateral se vuelva caótica:

  • Proyecto: nombre de la iniciativa, cliente, producto o repositorio.
  • Sesión: verbo y resultado, por ejemplo Comparar proveedores o Corregir autenticación.
  • Archivo: nombre estable y descriptivo, preferentemente sin versiones como final-final-2.
  • Archivo de estado: para proyectos largos, mantener un estado.md o decisiones.md que facilite el traspaso entre sesiones.

4.13 Errores frecuentes de organización

Problemas y correcciones
Error Consecuencia Corrección
Usar una única sesión para tareas no relacionadas. El historial acumula instrucciones incompatibles. Separar cada hilo de trabajo en una sesión.
Crear un proyecto para cada pregunta breve. La barra lateral se llena de contenedores sin valor duradero. Utilizar chats sin proyecto para consultas aisladas.
Suponer que una sesión conoce otro chat. Falta contexto o el modelo completa huecos incorrectamente. Guardar el resultado en Project Files y referenciarlo.
Ejecutar cambios paralelos sobre el mismo archivo. Conflictos, sobrescritura o resultados inconsistentes. Asignar fronteras distintas o secuenciar las sesiones.
Mover una sesión sin revisar sus dependencias. Puede perder acceso a los archivos del proyecto anterior. Copiar o trasladar primero los recursos necesarios y validar las rutas.

4.14 Resumen

  • Un proyecto agrupa trabajo que comparte objetivo, archivos o base de código.
  • Una sesión conserva un hilo de conversación y tarea independiente.
  • Las sesiones de un proyecto comparten Project Files, no sus historiales de mensajes.
  • Los chats sin proyecto son apropiados para consultas aisladas.
  • Las capacidades de programación deben habilitarse sólo cuando la tarea necesita una carpeta local.
  • El trabajo paralelo resulta seguro cuando las sesiones no compiten por los mismos recursos.

En el próximo tema estudiaremos pestañas, sesiones en segundo plano, vista dividida, bifurcaciones y checkpoints.

Fuentes oficiales consultadas: proyectos y sesiones, creación del primer proyecto, trabajo con documentos, proyectos con código, Bionic 1.1.0 y Bionic 1.1.1.

Retornar