Harness MaxxingDocumentação
📚 Todas as páginas

🧩 Estender · 4 min de leitura

🎨Personalizando o Harness Maxxing

Seu servidor, seu produto: você pode mudar qualquer coisa, e as atualizações mantêm as suas mudanças. Basta pedir ao Claude ("coloque um jogo da cobrinha no meu painel", "permita 20 sessões por tópico") - ele escolhe o nível certo abaixo, registra o que fez e leva isso consigo a cada atualização.

Três níveis

Nível Para Onde Na atualização
Extensões widgets (Card ou HTML livre: jogos, canvas), páginas, a API delas <workspace>/extensions/ nunca são tocadas
Workspace como o Claude se comporta em um tópico, tarefas agendadas, suas próprias skills arquivos CLAUDE.md, página Crons, .claude/skills/ nunca são tocados
Personalizações mudar o próprio produto (uma regra do servidor, um limite, um comando da CLI…) o diretório do código, registradas com maxxing custom save reaplicadas sobre a nova versão

O Claude sempre tenta os dois primeiros níveis antes de mexer no código do produto. A interface web em si não pode ser personalizada (ela é distribuída já compilada): adições visuais são extensões. Veja Widgets do painel e Extensões de página.

Personalizações

Uma personalização é uma mudança no diretório do código (/opt/claude-maxxing) salva como um commit do git com um título e o motivo:

maxxing custom save "Allow 20 sessions per topic" --why "I run many research threads in parallel"
maxxing custom                 # list, unsaved changes, pending update
maxxing custom drop <id>       # remove one

Toda personalização é listada em <workspace>/CUSTOMIZATIONS.md (título, motivo, arquivos) e exportada como um patch em <workspace>/customizations/. Ambos fazem parte do backup da memória.

Atualizações inteligentes

Antes: Configurações -> Sistema mostra o que a próxima atualização fará no seu servidor - testada em uma cópia descartável, nada foi alterado ainda (maxxing update --preflight no servidor). Cada personalização é mantida, é mantida em um código que mudou (verificada depois), já está incluída no produto (o Harness se oferece para removê-la) ou precisa ser adaptada. Edições não salvas, edições nos arquivos da interface e extensões que a nova versão não suporta mais também são listadas.

  • Tudo compatível: Atualizar faz tudo. Depois da reinicialização, suas extensões e personalizações são verificadas automaticamente, e o Harness aplica as novidades de workspace da versão em uma sessão de system/harness.
  • Algo para adaptar: Atualizar com o Harness abre uma sessão que adapta cada mudança ao novo código a partir do que ela serve (registrado junto com ela), testa e só depois atualiza. A versão atual continua rodando até tudo funcionar.

Depois: "Verificado após a atualização: suas extensões e mudanças funcionam" - ou o que parou de funcionar, com Corrigir com o Harness. Verifique quando quiser com maxxing update --verify (ou "Verificar agora").

Dê a cada personalização uma verificação - um comando que tem sucesso enquanto ela funciona - e ela será testada a cada atualização: maxxing custom save "..." --why "..." --check "<command>", ou depois maxxing custom check <id> "<command>". As extensões declaram a versão do contrato de extensão que usam ("api": 1 no manifest.json): uma versão que deixa de suportá-lo é anunciada antes de você atualizar.

Atualizações cuidadosas

maxxing update (ou o tópico system/harness (system/update em servidores mais antigos), ou Configurações -> Sistema) mantém você em segurança:

  1. As edições não salvas do código são primeiro salvas como uma personalização - nada se perde. As edições da interface pré-compilada (web/) não podem ser personalizações: elas são postas de lado (git stash) em vez de bloquear a atualização, e o Harness refaz o que elas faziam como uma extensão.
  2. Suas personalizações são reaplicadas sobre a nova versão.
  3. Sem conflito: a atualização termina ("N personalizações mantidas").
  4. Conflito (a nova versão mudou as mesmas linhas): nada muda, a versão atual continua rodando, e Configurações -> Sistema mostra "A atualização espera pelo Harness". No tópico system/harness (system/update em servidores mais antigos), o Claude lê o CUSTOMIZATIONS.md, adapta cada personalização ao novo código e conclui a atualização (maxxing update --resume). Se uma personalização não for mais necessária (o produto agora já faz isso), o Claude avisa você e a remove.
  5. A nova versão não inicia: o sistema volta automaticamente para a versão anterior (e para o branch anterior depois de --branch).

maxxing update --rollback volta para a versão (e o branch) que rodava antes da última atualização. Ele se recusa a rodar enquanto o diretório do código tiver mudanças não salvas (nada é alterado): ponha-as de lado primeiro (git stash), execute o rollback e depois traga-as de volta (git stash pop). Uma personalização salva logo antes seria desfeita pelo rollback.

Atualizações automáticas

Desativadas por padrão. Configurações -> Sistema -> Atualizar sozinho quando ninguém estiver aqui: quando uma nova versão sai, ninguém está na interface e nada está em execução (nenhum turno, nenhuma mensagem na fila, nenhuma tarefa agendada, nada por 10 minutos), e a atualização é "simples" (nenhuma personalização para adaptar, nenhuma mudança não salva, nenhuma nota de atualização pedindo algo), o Harness executa maxxing update sozinho e reinicia por alguns segundos. Caso contrário, ele espera e avisa você nas notificações. Ele nunca mexe em um servidor cujo código esteja em um branch de teste (detached HEAD) nem em uma atualização que já esteja esperando por você (conflito, versão revertida), e tenta uma determinada versão no máximo uma vez por dia.

Servidor novo

Restaure o backup da sua memória no novo servidor (RESTORE_FROM=owner/name na instalação): o instalador reaplica suas personalizações. Caso contrário, execute maxxing custom restore.

Veja também: maxxing custom --help e a skill maxxing-customize (o que o Claude segue).

💡 Travou? Abra uma sessão no topic system › help e pergunte com suas palavras: o Claude lê esta documentação no seu servidor e responde.✏️ Melhorar esta página