Regras

O medo de verdade não é espaço desperdiçado, é perder trabalho. É para isso que servem as regras do Devbroom, e nenhuma delas é uma opção de ajuste.

O escaneamento só lê

O escaneamento não altera nenhum arquivo. A menos que você defina uma regra como “Fazer por conta própria” na Manutenção automática, nada é tocado sem que você tenha visto na prévia e confirmado.

Todo veredito vem com um motivo

Nenhum item fica Pronto ou Bloqueado sem um motivo. Os motivos de cada veredito aparecem ao lado do item e, na linha de comando, com --details.

Bloqueado e Desconhecido não podem ser selecionados

Isto é um limite, não uma preferência. Itens em Revisar só são limpos com “Incluir mesmo assim”; na linha de comando isso é --include-review, que pede confirmação no terminal.

Verificado de novo logo antes de apagar

Quando você clica em Limpar, cada item é verificado de novo contra os processos rodando naquele momento. Um item cujo veredito ou conteúdo mudou desde o escaneamento fica onde está, e você fica sabendo por que foi pulado.

Lixeira primeiro

A Lixeira é o padrão, e cada item pode ser restaurado pelo Histórico. Apagar permanentemente é uma escolha à parte, confirmada mantendo o botão pressionado; sua organização pode desativar essa opção. O espaço movido para a Lixeira não conta como liberado até você esvaziá-la.

Worktrees: nunca --force

• Uma worktree com alterações sem commit, ou arquivos não rastreados ou em stage, fica Bloqueada. O git não a remove sem --force; o Devbroom nunca usa --force.
• Arquivos ignorados a deixam em Revisar, porque git worktree remove os apaga sem perguntar.
• Commits sem push num branch continuam lá quando a worktree é removida; num HEAD destacado, não continuariam. Por isso, antes de remover, o Devbroom salva o HEAD em refs/devbroom/removed; se não conseguir, não remove.
• Há só três ações para worktrees: remover (remove), podar (prune) e reparar (repair).

Não mexe no que está rodando

Se uma sessão de agente roda naquela pasta ou na pasta pai, um processo roda a partir dela, ou um arquivo dela está aberto, o item fica Bloqueado. Para pastas de build, uma sessão rodando na pasta pai as deixa em Revisar.

O Devbroom nunca toca nos processos de uma sessão de agente em execução. Ele só pede para encerrar processos que os agentes deixaram para trás quando você manda, e só depois de verificar de novo; nunca processos do sistema nem de outros usuários.

Só o nome não basta

O nome de uma pasta, sozinho, não é evidência:

Sem o marcador, a pasta fica em Revisar. Ela também precisa ser uma pasta ignorada pelo git, sem nenhum arquivo dentro rastreado pelo git.

Tamanho real

Espaço compartilhado com outras pastas por hard links e clones APFS (como faz o pnpm) não é contado. O número que você vê é o que apagar libera. Links simbólicos não são seguidos, e volumes montados são pulados.

Do jeito do próprio agente

Bancos de dados e credenciais dos agentes nunca são tocados. Quando um agente tem seu próprio comando de limpeza, é assim que a limpeza é feita ou mostrada a você. O histórico do Claude Code é apagado com claude purge ou arquivado: as conversas primeiro são gravadas num arquivo na pasta do Devbroom e verificadas contra os originais, e só então movidas para a Lixeira; a memória do projeto (memory/) fica onde está, e o arquivo pode ser reaberto pelo Histórico. Para sessões do Codex, é mostrado o codex delete. As sessões dos outros agentes são só lidas.

Tudo no seu Mac

Sem conta, sem telemetria; nada sobre você é enviado. O app verifica atualizações; se você inserir uma licença Pro, ele a ativa uma vez e a verifica de novo, discretamente, mais ou menos uma vez por mês (só a chave da licença e o nome do seu Mac). Sem licença, a verificação de atualizações é a única requisição de rede. Dos registros de sessão ele só pega contagens de tokens e nomes de modelos; a busca nas sessões lê os registros naquele momento, não guarda índice nem registro, e oculta nos trechos o que parece ser segredo. Detalhes na página de Privacidade.

Última atualização: 7 de outubro de 2026