acbridge (CLI)

acbridge é a segunda porta para a mesma casa do MCP. Ela fala por um socket Unix e está no PATH de todo card. Escolha entre as duas pela disponibilidade, não pelo gosto.

Quando usar

Nem todo provider expõe o catálogo MCP ao agente. A resposta do app é uma de quatro: o agente recebe as ferramentas declaradas; não há catálogo e a dica da CLI chega pelo scrollback; nenhum dos dois; ou não se aplica a um shell puro. O texto que funciona no briefing é:

Reporte com a ferramenta report se ela estiver no seu catálogo; senão acbridge report '<json>' — mesmo payload, mesmo registro.

Uso

Rodar acbridge sem argumentos imprime o uso completo. Os comandos cobrem o mesmo terreno do MCP: listar cards, ler um card, enviar texto, abrir uma URL, tirar snapshot, consultar e atualizar tasks, e reportar. Comando pesado sob o lock dos gates: acbridge gate-lock [--scope repo|machine] -- <comando> (espelho de run_locked). A lista viva é a de Ferramentas MCP — as duas portas chamam o mesmo backend.

Um ajuste de protocolo que vale saber: cada request leva um inteiro de protocol. Um acbridge mais antigo ou mais novo que o app é recusado — identidade e campos precisam bater com o bus que está rodando; divergência cairia dado em silêncio. Se o binário do pacote estiver defasado do repo, a resposta nomeia o mismatch.

A limitação do Cline, declarada

Um card cline não sobe um processo próprio: ele se liga a um daemon compartilhado. A identidade do card vive no ambiente do processo, e o daemon congela o ambiente no primeiro card — então todos os cards cline herdam o mesmo AGENT_CANVAS_CARD_ID (medido: cinco cards, ambientes byte a byte idênticos, diff vazio).

Isso não é consertável do lado do Stellar: o processo é um só, e reescrever o ambiente por card teria o último escritor vencendo. O que o app faz é não deixar o defeito ser silencioso. A porta de report exige que o card declarado exista, e o id herdado normalmente aponta para um card que já foi fechado — então o relatório é recusado, nomeando o id e prometendo o que agora é verdade: nada foi gravado. Antes desta checagem o relatório ia para o banco sob um id fantasma e o autor recebia ok.

O canal que funciona de um card cline é send_to_card para o orquestrador: a entrega não passa por identidade, só o registro passa. O card em si tem o id certo; quem não tem é o shim do MCP, criado pelo daemon. Ver Relatórios e sinais.

Variáveis de ambiente

Todo card nasce com o contexto necessário para falar com o app:

Um detalhe que confunde

O canal por onde um relatório entrou — socket (CLI) ou http (MCP) — é carimbado pelo servidor, nunca declarado pelo agente. Campo que o agente declara é campo que o agente pode errar. Ver Relatórios e sinais.