Documentação / Referência

Limites e segurança

O que o Stellar se recusa a fazer, e por quê — consentimento, sandbox, escritor único e ausência de telemetria.

Os limites do Stellar são escolhas, não pendências. Cada uma existe para fechar um modo de falha concreto.

Consentimento e privilégio mínimo

Operações com efeito colateral em disco ou em processos — escrever arquivo, rodar um comando, criar um card, abrir uma URL — exigem aprovação explícita no fluxo padrão. O agente pede, com um motivo declarado; você decide.

Um board pode ser posto em modo autônomo. Nesse caso o despacho automático segue, mas respeita estritamente o teto de concorrência configurado e o teto de profundidade da cadeia de spawns. Autonomia não é ausência de regra.

Isolamento do sandbox

Comandos executados por agentes no Linux são confinados por sandbox. O diretório pessoal fora da raiz do projeto é mascarado, o que impede a leitura de chaves, credenciais e dotfiles do host.

Gates exigem sandbox

Uma task pode declarar gates — comandos que o app roda sozinho depois de um relatório aceito, e cujo stdout, stderr e exit code são gravados como evidência. O gate roda confinado, e é por isso que declará-lo num sistema sem sandbox é recusado na hora de criar a task, nomeando o fato e a saída honesta: declarar sem gates e cobrir o mesmo terreno no relatório, rodando os comandos você mesmo. Limpar um gate que já existe continua permitido — senão a máquina ficaria presa na promessa que não pode cumprir.

Na prática, isso atinge macOS e Windows, onde o confinamento do Stellar não existe (o sandbox é bubblewrap, no Linux). A recusa acontece na declaração e não na execução de propósito: um campo gates que nunca vai rodar é pior que um campo ausente — ele promete evidência que não existe, e a descoberta chegaria tarde, no relatório, como “gate não rodou”.

Escritor único, por desenho

O app abre uma instância por banco. Dois escritores colidem nos identificadores de card no primeiro card criado. Não é bug: é premissa, documentada e defendida. É também o motivo pelo qual o trabalho em time é um problema de escrita concorrente — e não de kanban.

Sem telemetria

Nada do que você faz no Stellar é enviado para lugar nenhum. Não há servidor de métricas, e o app roda inteiro sem conta. O que mede o seu trabalho — rodadas, tempos, custo por modelo — fica no seu banco, para você.

A exceção é uma requisição, e é honesto nomeá-la em vez de escondê-la atrás da frase acima: o app consulta as releases do GitHub para saber se há versão nova. É um pedido, não telemetria — não leva nada sobre o seu trabalho, e a direção é a inversa (o app pergunta, ninguém é informado). A alternativa era o app dizer “sem novidades” para sempre, que foi exatamente o que aconteceu quando o projeto saiu do GitHub e o feed ficou ausente em silêncio. Hoje a ausência de feed é um estado próprio, com motivo declarado, nunca um sucesso vazio — e o install no macOS sem assinatura troca o bundle por swap, deixando um log do que fez.

O que um relatório de agente vale

Um relatório é um registro, não um fato verificado. Quando a afirmação tem consequência, ela se confere: rodando o gate em worktree isolado, lendo a linha gravada no banco, repetindo a medição. Relatar sobre código que não está instalado já custou um dia inteiro de conclusões erradas — a build que roda pode não ser o código do repositório, e conferir isso é parte do trabalho.