Onde ficam os dados

O Stellar guarda o seu trabalho na pasta de configuração da sua máquina. Saber o que está lá dentro — e o que não está — é o que torna honesta a promessa de levar a sua casa de trabalho para outro PC.

O que fica em disco

O banco roda em WAL, e o schema é versionado. Um novo tipo de card não pede migração: o kind é texto solto.

Três desses arquivos merecem uma frase:

• providers.json é como você ensina o Stellar a spawnar um CLI que ele não conhece. O app observa o arquivo: editar não exige reiniciar, e o registro vivo re-sincroniza dizendo quantos providers entraram, saíram e qual entrada foi recusada. O arquivo tem versão de formato, e uma versão desconhecida é recusada inteira — nunca “interpretada por sorte”, que é como um formato quebra config de usuário em silêncio.
• update-prefs.json guarda a versão que você adiou. Só uma, e é string, não relógio: uma versão mais nova avisa de novo. “Pular esta versão” não existe de propósito — pular é promessa mais forte que adiar, e quem pula deixa de ser avisado de uma correção.
• update-swap.log existe só no macOS, onde instalar sem assinatura troca o bundle por swap. O app diz o caminho desse arquivo na própria tela: é o que você manda se a troca falhar.

A tela do card não é guardada por default

Fechar um card guarda a identidade e os fatos do registry — quando morreu, se foi morte por cota, se o kill foi pedido. A tela, não: o scrollback não vira texto durável.

Não é timidez técnica. A tela é tela de trabalho real, com caminhos e trechos de código, e persistir isso muda o regime de “pixels efêmeros no seu monitor” para “texto durável, lido por qualquer agente que consiga abrir o banco do board”. Esta casa já foi mordida uma vez por um card que fez grep recursivo no diretório do usuário; guardar tela sem pensar repetiria o erro com mais alcance. Quem liga a persistência assume o ônus — ela vem com redação de segredo, mas a redação é por padrão, não por semântica, e não alcança um segredo escrito em prosa livre.

Três baldes

Quando se fala em sincronizar, cada item cai em um de três baldes.

Viaja — o conteúdo do board (cards, notas, tarefas, relatórios, conectores, sprints, assets) e as preferências inócuas. Também viaja, por git, a metade que já estava resolvida: AGENTS.md, CLAUDE.md, a camada ai/ e as skills de repositório.

Fica — o que é local por natureza: caches do Chromium, sockets, portas do MCP, pan/zoom (que nem persiste), PIDs, e identidades de sessão amarradas a caminhos de projeto.

Você decide — chaves de API e credenciais dos providers. Elas viajariam tecnicamente, mas custam segurança; redigitar em cada máquina é zero custódia, e custódia é responsabilidade sobre chave de terceiro.

A exceção que não dá para esconder

As chaves guardadas via keychain do sistema não abrem em outra máquina: o material criptográfico vive no cofre do SO. Copiar o arquivo de segredos deixa chaves opacas, e o app trata isso como “sem chave” — o que é correto, e é por isso que a tela de entrada diz “você decide” sobre elas, em vez de prometer “igual em qualquer PC” sem a exceção.

Caminhos absolutos

Boards e cards guardam caminhos absolutos do diretório de trabalho. Um board que aponta para um caminho que não existe na outra máquina quebra mais do que não sincronizar — por isso o remapeamento de caminho é uma decisão declarada, não um efeito colateral do sync.