Instalar o core

O que o comando faz, o que dá para mudar nele e como tirar o core da máquina. Conferido no instalador publicado e no código da 0.5.0.

curl -fsSL https://downloads.trama.sh/bootstrap.sh | sh

O que o comando faz, em ordem

Confere o sistema: Linux ou macOS, x86_64 ou arm64. Qualquer outro é recusado pelo nome, antes de baixar qualquer coisa.
Confere se a máquina tem curl ou wget, e minisign. A falta de cada um é recusada com o comando que instala.
Mostra a chave pública que ele traz embutida. Compare com a da página inicial, que chega até você por outro caminho.
Baixa o install.sh e a assinatura dele, e confere. Uma assinatura que não confere para tudo, sem nova tentativa.
Baixa o tramad da sua plataforma e a assinatura dele, e confere. Até aqui nada foi escrito fora de uma pasta temporária, que é apagada em qualquer saída — inclusive numa recusa.
Põe o binário em ~/.local/bin/tramad e o texto da licença ao lado, em tramad.LICENSE.
Registra o core como serviço do usuário — systemd no Linux, launchd no macOS — e só diz que instalou depois de ver o serviço rodando.
Se ~/.local/bin não estiver no PATH, imprime a linha que o põe lá — não edita o seu ~/.profile por você. Ele nunca pede senha.

Toda recusa tem duas linhas: o que está errado, e o que fazer (fix). Uma assinatura que não confere não é falha de download para tentar de novo: pare e nos avise, com a versão e a plataforma.

Opções

Três variáveis de ambiente e uma opção. Sem nenhuma, o instalador põe a versão mais recente em ~/.local/bin.

Nome	Padrão	O que muda
`TRAMA_VERSION`	`latest`	Uma versão publicada, como 0.5.0, em vez da mais recente.
`TRAMA_PREFIX`	`~/.local/bin`	Onde ficam o binário e a licença. A pasta é criada se não existir.
`TRAMA_FORCE`	`no`	Com yes, substitui um tramad que já esteja no destino e não veio de uma release publicada — um compilado do código, por exemplo. Sem ele, o instalador para em vez de sobrescrever, porque o que estava lá não tem volta.
`--work-root <pasta>`	`work, dentro da pasta de dados do core`	Onde o core clona os repositórios dos projetos. Veja abaixo.

As variáveis vão antes do sh; a opção, depois de sh -s --:

curl -fsSL https://downloads.trama.sh/bootstrap.sh | TRAMA_VERSION=0.5.0 shcurl -fsSL https://downloads.trama.sh/bootstrap.sh | sh -s -- --work-root /srv/trama/work

Onde o core clona os repositórios

Num servidor, você costuma querer os repositórios num disco de dados ou numa pasta do usuário que faz o deploy. O core confere a pasta antes de registrar o serviço, e para dizendo qual pasta e por quê se ela:

não for um caminho absoluto;
não puder ser criada, ou for um arquivo;
não aceitar escrita — o core escreve um arquivo lá e o apaga, porque permissão não diz nada de um disco cheio ou montado só para leitura;
ficar dentro da pasta de credenciais ou de configuração do core.

Cada projeto ganha a sua cópia em <pasta>/<cliente>/<projeto>-<hash>. O hash vem da identidade do projeto, então dois projetos com o mesmo nome nunca dividem uma cópia. Uma opção que o instalador não conhece é recusada, e não ignorada.

Depois de instalar

Com ~/.local/bin no PATH. Sem ele, use o caminho inteiro, ~/.local/bin/tramad.

tramad health: O estado do core, no formato que o painel lê.
tramad service status: Se o serviço está instalado, rodando, ou se não dá para saber — que é uma terceira resposta, e não um silêncio.
tramad service log --lines 200: As últimas linhas do log, dizendo de onde vieram.
tramad service restart: Para e sobe de novo. Também há stop e start.

A instalação não agenda backup. tramad backup run faz um na hora, e tramad backup schedule imprime o agendamento desta máquina para você instalar; os backups automáticos começam quando ele estiver instalado.

Lembre o que o core precisa para trabalhar, além do que o instalador confere: o Claude Code autenticado na máquina e, no Linux, bubblewrap. Para o serviço continuar rodando sem sessão aberta no Linux, um administrador precisa rodar loginctl enable-linger para o seu usuário.

Desinstalar

Primeiro o serviço, que o próprio core sabe tirar — ele para o processo e apaga o registro (a unit do systemd ou o plist do launchd). Depois o binário e a licença:

tramad service uninstallrm ~/.local/bin/tramad ~/.local/bin/tramad.LICENSE

O que fica

Os dados do core não são apagados: o banco, as credenciais, os decisores, os backups, se houver, e — sem --work-root — as cópias dos repositórios. Nos caminhos padrão:

Linux

~/.local/share/trama
~/.config/trama
~/.local/state/trama
~/.cache/trama

macOS

~/Library/Application Support/trama
~/Library/Logs/trama
~/Library/Caches/trama

No Linux, XDG_DATA_HOME, XDG_CONFIG_HOME e XDG_STATE_HOME mudam esses lugares, se estiverem definidas. Com --work-root, as cópias estão na pasta que você escolheu.

Apagar essas pastas apaga o banco, as credenciais e os backups, e não tem volta. Uma cópia de repositório pode guardar trabalho que nenhum turno entregou: olhe antes de apagar.

Atualizar

Não use o tramad update na 0.5.0, mesmo que ele apareça no tramad --help: o binário publicado saiu sem a chave com que ele confere a versão nova, e ele recusa antes de trocar qualquer coisa. Não é defeito da sua instalação. O caminho de atualização está sendo corrigido para a próxima versão, e entra aqui quando tiver sido provado numa máquina.

O que há na 0.5.0

A versão que o comando instala hoje. Das notas da release, para quem usa.

Um core, vários projetos: Cada projeto com o seu board, repositório, agentes, agendas e cliente. Um core com a configuração antiga continua lendo-a como está.
Coluna de entrada: O projeto pode nomear a coluna que admite trabalho, e só os cards que uma pessoa moveu para lá são trabalhados. Cada card que ficou de fora diz por quê.
Onde clonar é escolha sua: --work-root na instalação, e cada projeto com a sua cópia.
Agendas e loops por cliente: Configurados uma vez, valem para todos os projetos do cliente.
Um teto para todas as tarefas: O número de tarefas ao mesmo tempo conta todo tipo de turno, e o painel pode ajustá-lo. Baixar o número nunca interrompe o que já está rodando.
Prompt assinado: O prompt do agente pode ser texto, assinado junto com o agente, e o core só roda um turno com o texto que um decisor assinou.
Subagentes com modelo próprio: Uma política por agente — por exemplo, o Sonnet escreve e o Opus revisa.
Modelo conferido ao assinar: Um modelo que não é do provedor do agente é recusado na hora, e não quando um turno roda.
Loops pausam e retomam: De onde pararam, no mesmo branch, com tudo o que já tinham gastado e feito.
Credencial por site: Dois Jira, ou um GitLab auto-hospedado ao lado do gitlab.com, no mesmo core.
O merge request sai da entrega: A entrega abre o merge request do commit, e o comentário no card traz o link. Ele nunca decide o veredito: quem decide é o build.
Board em português: Os comentários que o core deixa no card saem em português, se o projeto pedir; sem isso, em inglês, como antes.
Sprint e ciclo ativos: Um board do Jira pode ser trabalhado só a partir das sprints ativas, e um do Linear a partir do ciclo ativo.

Corrigido

O Jira Cloud voltou a ser lido: a Atlassian removeu a busca que o core usava.
Boards do GitHub, do GitLab e do Linear com mais de uma página são lidos até o mesmo teto do Jira, mil cards, e dizem quando param nele.
O core não pega de novo, a cada ciclo, um card que espera a resposta ou a aprovação de uma pessoa.
Um card que chegou a um veredito de build ganha um comentário dizendo qual.
No macOS, a saída de um turno não fica mais presa por outro processo que o core abriu no mesmo instante.