Workspaces

Um workspace é a pasta raiz que você abre. O Fetchpier lembra uma lista de workspaces recentes; quando nenhum está aberto, a sidebar oferece os pontos de entrada para abrir ou criar um e lista os recentes para reabrir rapidamente. Abrir uma entrada recente que não existe mais — ou que já não é um workspace do Fetchpier — não a recria em silêncio: você recebe uma mensagem explicativa e a entrada morta é removida da lista de recentes. Reabrir o último workspace ao iniciar segue exatamente a mesma regra — se essa pasta foi esvaziada ou apagada entre sessões, o Fetchpier não escreve nada nela, explica o motivo, remove-a da lista e inicia sem nenhum workspace aberto. O que torna uma pasta um workspace é o marcador que o Fetchpier colocou nela ao criá-la, não o simples fato de a pasta existir. Criar um workspace novo é uma ação separada e explícita de abrir um existente. Cada workspace contém:

• requests/ — a árvore que você cria. Subpastas são “coleções”, arquivos .http são requisições individuais, e pastas se aninham arbitrariamente para formar subcoleções.
• environments/<name>/config.json — uma pasta por ambiente nomeado, cada uma com seu próprio conjunto de variáveis. A pasta recebe o nome do ambiente.
• environments/<name>/.state/cookies.json — o cookie jar daquele ambiente (vive ao lado de sua config, então um rename ou delete leva os cookies junto).
• requests/.runs/*.http — o log de atividade por envio (um registro .http por requisição enviada).
• requests/.state/ui-state.json — estado de UI por requisição (qual sub-aba do editor e qual sub-aba de resposta estiveram ativas por último), indexado pelo identificador estável da requisição.
• requests/.state/tree-state.json — quais pastas de coleção estão expandidas na árvore da sidebar, para restaurar o layout na próxima inicialização.
• .fetchpier/.state/workspace-state.json — estado pessoal e local à máquina: o conjunto de abas abertas (e qual está ativa) e a seleção de ambiente ativo, para restaurar seu working set e seu ambiente selecionado na próxima inicialização.
• .fetchpier/settings.json — defaults HTTP no nível do workspace que viajam com a equipe.
• .fetchpier/certs/ — material TLS no escopo do workspace (CAs e certificados de cliente).
• .env (opcional, na raiz do workspace) — arquivo dotenv usado como fonte de valores para as referências {{$env.NAME}} dentro das variáveis de ambiente.

Um workspace novo começa com um ambiente. Criar um workspace também cria um ambiente chamado Default com uma única variável baseUrl, e o registra como o selecionado, então você já está posicionado em um ambiente: o seletor o mostra, {{baseUrl}} é resolvida, um cookie jar está em uso, e uma execução pela linha de comando encontra o ambiente ao qual recorre por padrão. Em todo o resto é um ambiente comum — pode ser renomeado, editado e apagado. Abrir um workspace nunca faz isso: um workspace existente sem ambientes continua assim, e apagar o último ambiente é definitivo, não é desfeito na próxima inicialização.

Quando um workspace não tem .gitignore ao ser aberto, o Fetchpier cria um com um default sensato — excluindo os diretórios de estado pessoal **/.state/, os logs de atividade por envio **/.runs/ e o .env opcional — e mostra um toast único avisando. O diretório .fetchpier/, compartilhado com o workspace, deliberadamente não é ignorado, então os defaults HTTP da equipe e o material TLS viajam com o workspace sob controle de versão. Se o workspace já tem um .gitignore — mesmo um arquivo vazio — o Fetchpier nunca o modifica: a presença do arquivo é seu sinal de propriedade.

O layout de arquivos do workspace é a fonte da verdade. Renomear uma pasta renomeia uma coleção; apagar um arquivo .http apaga uma requisição; editar um arquivo .http em outro editor e salvá-lo é refletido imediatamente na UI graças a um observador de pastas.

A árvore sobrevive a um observador quebrado. O rastreamento de arquivos pode parar por razões fora do controle da app: a pasta observada é apagada ou renomeada por outro programa, a máquina suspende e acorda, ou o workspace vive em um compartilhamento de rede que nunca reporta mudanças. Nada disso te interrompe: a árvore é relida sempre que a janela recupera o foco, então o ritmo normal de sair para editar em outro lugar e voltar é em si o refresh. O rastreamento também é reestabelecido automaticamente depois que a máquina retoma, e após uma falha é tentado novamente algumas vezes. Só quando essas tentativas se esgotam aparece um aviso, explicando que o rastreamento automático parou, que a árvore ainda se atualiza ao recuperar o foco, e que reabrir o workspace o restaura. Uma falha que a app pode corrigir sozinha nunca é exibida.

Você pode fechar o workspace atual sem abrir outro. Fechar encerra o observador de arquivos e todo acesso posterior a essa pasta, limpa suas abas e volta a app ao estado sem workspace. Se uma aba tem alterações não salvas, o aviso normal de salvar/descartar/cancelar é exibido antes de fechar qualquer coisa.

O que é compartilhado e o que fica local

O Fetchpier não tem banco de dados embutido. Os arquivos simples do workspace são o modelo de dados durável:

Dado	Local	Compartilhar?
Requisições	requests/**/*.http	Sim.
Ambientes	environments/<id>/config.json	Sim; os valores secretos são texto cifrado.
Configurações do workspace	.fetchpier/settings.json	Sim.
Manifesto de segredos	.fetchpier/secrets.json	Sim; não contém a chave do workspace.
Certificados do workspace	.fetchpier/certs/	Sim, conforme sua política de segurança.
Cookies	environments/<id>/.state/cookies.json	Não, ignorado por padrão.
Registros de atividade	requests/.runs/*.http	Não, ignorado por padrão.
Estado de abas, da árvore e de UI por requisição	arquivos .state/	Não, ignorado por padrão.
Valores do .env	.env na raiz do workspace	Não, ignorado por padrão.

As configurações da aplicação, os certificados globais da app, o estado da janela e a chave do workspace envolvida localmente ficam na pasta de dados do usuário da aplicação, não no workspace.

As escritas de conteúdo do workspace são atômicas: o Fetchpier substitui um arquivo como uma unidade, então uma falha, um disco cheio ou uma queda de energia durante um salvamento deixa a versão anterior completa ou a nova versão completa, nunca um arquivo truncado. Os destinos de exportação escolhidos pelo usuário e os arquivos de relatório da CLI ficam fora dessa garantia. Da mesma forma, importar um certificado nunca sobrescreve os bytes armazenados de outro certificado: material idêntico é reaproveitado, e material diferente que colidiria no nome de arquivo gerado é armazenado ao lado do existente.

Faça backup de um workspace copiando sua pasta. Audite-o com o histórico do Git e sincronize-o com o fluxo de compartilhamento de arquivos que sua equipe controla.