Workspaces

Un workspace es la carpeta raíz que abrís. Fetchpier recuerda una lista de workspaces recientes; cuando no hay ninguno abierto, el sidebar ofrece los puntos de entrada para abrir o crear uno y lista los recientes para reabrirlos rápido. Abrir una entrada reciente que ya no existe —o que ya no es un workspace de Fetchpier— no lo recrea en silencio: recibís un mensaje explicativo y la entrada muerta se saca de la lista de recientes. Reabrir el último workspace al arrancar sigue exactamente la misma regla: si esa carpeta se vació o se eliminó entre sesiones, Fetchpier no escribe nada en ella, explica por qué, la saca de la lista y arranca sin ningún workspace abierto. Lo que convierte a una carpeta en workspace es la marca que Fetchpier puso ahí al crearlo, no el mero hecho de que la carpeta exista. Crear un workspace nuevo es una acción separada y explícita de abrir uno existente. Cada workspace contiene:

• requests/ — el árbol que escribís. Las subcarpetas son “colecciones”, los archivos .http son solicitudes individuales, y las carpetas se anidan arbitrariamente para formar subcolecciones.
• environments/<name>/config.json — una carpeta por entorno nombrado, cada una con su propio conjunto de variables. La carpeta se llama según el entorno.
• environments/<name>/.state/cookies.json — el cookie jar de ese entorno (vive junto a su config, así un rename o un delete se lleva las cookies con él).
• requests/.runs/*.http — el log de actividad por envío (un registro .http por solicitud enviada).
• requests/.state/ui-state.json — estado de UI por solicitud (qué sub-tab del editor y qué sub-tab de respuesta estuvieron activos por última vez), indexado por el identificador estable de la solicitud.
• requests/.state/tree-state.json — qué carpetas de colección están expandidas en el árbol del sidebar, para restaurar el layout en el próximo arranque.
• .fetchpier/.state/workspace-state.json — estado personal y local a la máquina: el conjunto de tabs abiertos (y cuál está activo) y la selección de entorno activo, para restaurar tu working set y tu entorno seleccionado en el próximo arranque.
• .fetchpier/settings.json — defaults HTTP a nivel workspace que viajan con el equipo.
• .fetchpier/certs/ — material TLS con alcance de workspace (CAs y certificados de cliente).
• .env (opcional, en la raíz del workspace) — archivo dotenv usado como fuente de valores para las referencias {{$env.NAME}} dentro de las variables de entorno.

Un workspace nuevo arranca con un entorno. Crear un workspace también crea un entorno llamado Default con una sola variable baseUrl, y lo registra como el seleccionado, así ya quedás posicionado en un entorno: el selector lo muestra, {{baseUrl}} resuelve, hay un cookie jar en uso, y una corrida de línea de comandos encuentra el entorno al que recurre por default. En todo lo demás es un entorno común — se puede renombrar, editar y eliminar. Abrir un workspace nunca hace esto: un workspace existente sin entornos queda así, y eliminar el último entorno es definitivo en lugar de deshacerse en el próximo arranque.

Cuando un workspace no tiene .gitignore al abrirse, Fetchpier crea uno con un default sensato —que excluye los directorios de estado personal **/.state/, los logs de actividad por envío **/.runs/ y el .env opcional— y muestra un toast por única vez avisándolo. El directorio .fetchpier/, que se comparte con el workspace, deliberadamente no se ignora, así los defaults HTTP del equipo y el material TLS viajan con el workspace bajo control de versiones. Si el workspace ya tiene un .gitignore —incluso un archivo vacío— Fetchpier nunca lo modifica: la presencia del archivo es tu señal de propiedad.

El layout de archivos del workspace es la fuente de verdad. Renombrar una carpeta renombra una colección; eliminar un archivo .http elimina una solicitud; editar un archivo .http en otro editor y guardarlo se refleja de inmediato en la UI gracias a un watcher de carpetas.

El árbol sobrevive a un watcher roto. El seguimiento de archivos puede detenerse por razones fuera del control de la app: la carpeta observada se elimina o se renombra desde otro programa, la máquina se suspende y despierta, o el workspace vive en un share de red que nunca reporta cambios. Nada de esto te interrumpe: el árbol se vuelve a leer cada vez que la ventana recupera el foco, así que el ritmo normal de irte a editar a otro lado y volver es en sí mismo el refresh. El seguimiento también se restablece automáticamente después de que la máquina reanuda, y ante una falla se reintenta unas cuantas veces. Solo cuando esos reintentos se agotan aparece un aviso, explicando que el seguimiento automático se detuvo, que el árbol igual se refresca al recuperar el foco, y que reabrir el workspace lo restaura. Una falla que la app puede arreglar sola nunca se te muestra.

Podés cerrar el workspace sin abrir otro. Esto detiene el file watcher y todo acceso posterior a la carpeta, limpia sus pestañas y vuelve al estado sin workspace. Antes se ejecuta el aviso normal de guardar/descartar/cancelar si existen cambios sin guardar.

Qué se comparte y qué queda local

Fetchpier no tiene una base de datos embebida. Los archivos planos del workspace son el modelo de datos durable:

Dato	Ubicación	¿Compartirlo?
Solicitudes	requests/**/*.http	Sí.
Entornos	environments/<id>/config.json	Sí; los valores secretos son ciphertext.
Settings del workspace	.fetchpier/settings.json	Sí.
Manifest de secretos	.fetchpier/secrets.json	Sí; no contiene ninguna clave de workspace.
Certificados del workspace	.fetchpier/certs/	Sí, sujeto a tu política de seguridad.
Cookies	environments/<id>/.state/cookies.json	No, ignorado por default.
Registros de actividad	requests/.runs/*.http	No, ignorado por default.
Estado de tabs, del árbol y de UI por solicitud	archivos .state/	No, ignorado por default.
Valores de .env	.env en la raíz del workspace	No, ignorado por default.

Los settings de la aplicación, los certificados globales de la app, el estado de las ventanas y la clave de workspace envuelta localmente viven en la carpeta de datos de usuario de la aplicación, no en el workspace.

Las escrituras de contenido del workspace son atómicas: Fetchpier reemplaza un archivo como una unidad, así un crash, un disco lleno o un corte de energía durante un guardado deja la versión anterior completa o la versión nueva completa, en lugar de un archivo truncado. Los destinos de export elegidos por el usuario y los archivos de reporte de la CLI quedan fuera de esta garantía. Del mismo modo, importar un certificado nunca sobrescribe los bytes guardados de un certificado distinto: el material idéntico se reutiliza, y el material distinto que colisionaría en su nombre de archivo generado se guarda junto al existente.

Respaldá un workspace copiando su carpeta. Auditalo con el historial de Git, y sincronizalo con el flujo de intercambio de archivos que controle tu equipo.