Documentação do SynaBun

Visão geral #

O SynaBun é um sistema local de memória persistente e um kit de automação para assistentes de IA. Qualquer ferramenta de IA compatível com MCP — Claude Code, Codex, Gemini, OpenCode, Cursor, Windsurf ou qualquer outra — pode se conectar e manter o conhecimento entre sessões. Claude Code, Codex e OpenCode têm painéis laterais dedicados, e o Assistente do SynaBun atua como um orquestrador com acesso às suas memórias e despacha trabalho para essas três CLIs.

As memórias ficam em um único banco de dados SQLite local, com índices de palavras-chave e embeddings vetoriais gerados localmente. O recall usa recuperação híbrida — busca por palavras-chave com SQLite FTS5, embeddings de documentos e refinamento por trechos, combinados por reciprocal rank fusion — e encontra a memória certa tanto se você lembra de um identificador exato quanto se lembra só da ideia por trás dele.

Principais recursos #

• 157 ferramentas MCP — memória (8), loop (1), perfil (1), escolha (1), automação de navegador (46: 21 ferramentas gerais, incl. browser_batch, browser_console e browser_cheatsheet, mais 25 ferramentas de plataforma), BlueSky (15), Google Search Console (30), YouTube (11), orquestração do Assistente do SynaBun (12 ferramentas agent_*), uso do computador (4), Leonardo AI (5), quadro branco (5), cartões (5), discord (8), git (1), imagem (1), guia de estilo (1), MoreLogin (1), tictactoe (1)
• Mais de 500 endpoints de API REST — API HTTP completa para integrações externas e para a Neural Interface
• Assistente do SynaBun — um orquestrador central que pensa com o cérebro que você escolher (Claude Code, Codex ou OpenCode), recupera memórias a cada turno e despacha workers autônomos com roteamento de modelos, briefings de esclarecimento, orçamentos e contabilidade de tokens. Veja Assistente do SynaBun.
• Motor de memória v2 — recuperação híbrida (FTS5 + embeddings + refinamento por trechos), recuperação compacta com orçamento, histórico de revisões com desfazer, escritas idempotentes e manutenção reversível. Veja Motor de memória v2.
• Uso do computador (macOS) — o Assistente pode operar seu Mac com capturas de tela, mouse, teclado, apps e a árvore de acessibilidade, limitado por proteções sempre ativas e controles de parada
• 3 painéis laterais dedicados — Claude Code, Codex e OpenCode, com docks de atividade de ferramentas, cancelamento por agente, cartões de permissão, gaveta de TODOs, medidor de contexto, menu de sessão, modal de nova sessão (seletor de projeto + branch) e Multi-CLI Resume com seletor de provedor
• Estúdio de automações — pastas recolhíveis criadas pelo usuário, padrões de execução por template (CLI / Modelo / Esforço / perfil MCP) e suporte de primeira classe a 4 CLIs (Claude Code, Codex, Gemini, OpenCode)
• Gerenciamento universal de MCP — formulário de adição com colagem inteligente (detecta sozinho 5 formatos de configuração), sincronização multiplataforma entre Claude Code / Codex / Gemini / OpenCode, cofre central de variáveis de ambiente com mascaramento de valores sensíveis, registro automático de perfis e instalação em um clique direto do GitHub
• Presets de perfil de recuperação — Rápido / Equilibrado / Profundo / Personalizado, com 6 controles de ajuste fino e um indicador de impacto em tempo real (tokens por recuperação, memórias alcançáveis, contexto da sessão)
• Hooks do Claude Code — 10 scripts de hook com 11 registros em 9 eventos do ciclo de vida, para recuperação automática, captura de memórias, briefing de subagentes e gerenciamento de contexto
• Regras do SynaBun — um conjunto curto de regras, instalado e mantido em dia automaticamente para Claude Code, Codex, Gemini e OpenCode quando você conecta uma ferramenta
• Guia de estilo — um sistema de marca e design por projeto, escrito como DESIGN.md mais design tokens e entregue a todos os agentes pela ferramenta style_guide
• Embeddings locais — Transformers.js (all-MiniLM-L6-v2, 384 dimensões) sem nenhuma configuração; a inferência de embeddings nunca envia o texto das memórias para um provedor de nuvem
• Decisões por IA (opcional) — julgamentos tipados do Jev (TypeSafe) substituem heurísticas de regex para duplicatas, relevância, obsolescência e mais; quando essa opção está desligada, cada recurso volta a usar uma heurística local
• Conexão com o WhatsApp — converse com o Assistente pelo celular, como dispositivo vinculado, com níveis de permissão aplicados no seu computador
• Neural Interface 3D — um mapa de memórias de todo o seu acervo em localhost:3344
• Suporte a vários projetos — as memórias são marcadas por projeto, e a busca cobre todos ou filtra por projeto
• Categorias hierárquicas — sistema de categorias pai/filha com schema dinâmico
• Renderização moderna de código — realce de sintaxe, caminhos de arquivo transformados em links, rótulos de linguagem, botões de copiar que só aparecem no hover, streaming limitado a 30 fps e streaming em tempo real dos blocos de raciocínio
• Self-hosted, local-first — o banco de dados, os embeddings e a recuperação rodam todos na sua máquina

Como funciona #

Quando seu assistente de IA chama remember, o SynaBun gera o embedding do conteúdo localmente com Transformers.js (all-MiniLM-L6-v2, 384 dimensões) e grava tudo no SQLite com os metadados (categoria, projeto, importância, etiquetas, tipo, arquivos relacionados) e uma primeira revisão. Documentos longos também são divididos em trechos de origem, para que uma evidência lá no fim do documento continue fácil de encontrar.

Quando ele chama recall, a busca por palavras-chave (SQLite FTS5) e os embeddings de documentos indicam candidatos, cada um por sua conta; o refinamento por trechos afina a seleção, e o reciprocal rank fusion combina os rankings. As pontuações de ranking são sinais de relevância, não probabilidades de confiança. Um filtro project explícito nunca se estende a outros projetos, e format: "compact" devolve trechos dentro do orçamento em vez de memórias completas. Veja Motor de memória v2.

Início rápido #

Pré-requisitos #

• Node.js 22.5+ — para o servidor MCP, o banco de dados SQLite (pelo node:sqlite nativo) e a Neural Interface
• Sem chaves de API, sem Docker — os embeddings rodam localmente com Transformers.js e o banco de dados é um único arquivo
• Ferramentas de build opcionais — o terminal embutido usa node-pty, um addon nativo. Sem ferramentas de build, o npm install avisa e segue em frente; todo o resto funciona. Instale-as com xcode-select --install (macOS), sudo apt install build-essential python3 (Linux) ou o VS Build Tools 2022 com "Desktop development with C++" (Windows).

Instalação #

# Clone the repository
git clone --depth=1 https://github.com/danilokhury/Synabun.git
cd Synabun

# Start everything (installs deps, builds MCP, launches Neural Interface)
npm start

# Install globally via npm
npm install -g synabun

# Launch (installs deps, builds MCP, opens onboarding wizard)
synabun

O que o npm start faz #

O npm start e o comando synabun executam o mesmo script de configuração:

1. Verifica o diretório de dados (~/.synabun por padrão) e, nas instalações que guardavam o estado dentro do checkout, faz a migração antes de iniciar qualquer outra coisa
2. Verifica a versão do Node.js e instala as dependências da Neural Interface e do servidor MCP
3. Instala o navegador Chromium do Playwright, usado na automação de navegador
4. Faz o build do servidor MCP (transportes stdio e HTTP, compatível com todos os clientes MCP)
5. Corrige os registros do SynaBun que já existem nas suas ferramentas de IA para que apontem para o build atual
6. Inicia a Neural Interface na porta 3344 e a abre no seu navegador — na primeira execução, com o assistente de configuração inicial

O banco de dados SQLite é criado em ~/.synabun/mcp-data/memory.db, e o modelo de embedding local (Xenova/all-MiniLM-L6-v2, ONNX de ~23MB) é baixado uma única vez e fica em cache.

Conecte ao Claude Code #

O assistente de configuração inicial e Ajustes → Conexões de IA registram o SynaBun no Claude Code, Codex, Gemini e OpenCode e instalam as Regras do SynaBun de cada ferramenta que você conectar. Para registrar manualmente, adicione o SynaBun ao .mcp.json do seu projeto:

// .mcp.json
{
  "mcpServers": {
    "SynaBun": {
      "command": "node",
      "args": ["/path/to/Synabun/mcp-server/run.mjs"]
    }
  }
}

Ou registre globalmente, para todos os projetos:

claude mcp add SynaBun node "/path/to/Synabun/mcp-server/run.mjs" -s user

Verifique a instalação #

# Check database exists
ls ~/.synabun/mcp-data/memory.db

# Inspect database, migration, client-registration, and backup health
synabun doctor

# Check Neural Interface API
curl http://localhost:3344/api/stats

# Open Neural Interface in browser
open http://localhost:3344

Reinicie o Claude Code e rode /mcp — o servidor SynaBun deve aparecer na lista com suas ferramentas. A partir de um checkout do git, rode os subcomandos da CLI como npm start -- doctor. Veja Comandos da CLI.

Arquitetura #

O SynaBun segue uma arquitetura em camadas: seu assistente de IA se comunica via MCP, o servidor MCP cuida do despacho das ferramentas, os embeddings são gerados localmente e as memórias são armazenadas e buscadas no SQLite. Tudo roda na sua máquina — sem serviços externos, sem Docker, sem chaves de API.

┌─────────────────────────────────────────────────────────────┐
│                     AI ASSISTANT                            │
│    (Claude Code, Codex, Gemini, OpenCode, Cursor, ...)      │
└───────────────────────┬─────────────────────────────────────┘
                        │  Model Context Protocol (stdio or HTTP)
                        ▼
┌─────────────────────────────────────────────────────────────┐
│                  SYNABUN MCP SERVER                         │
│                                                             │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐     │
│  │ remember │  │  recall  │  │ reflect  │  │  forget  │     │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘     │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐     │
│  │ restore  │  │ memories │  │   sync   │  │ category │     │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘     │
│  + loop, profile, choice and 21 switchable tool groups      │
└─────────────┬───────────────────────┬───────────────────────┘
              │                       │
              ▼                       ▼
┌─────────────────────┐  ┌───────────────────────────────────┐
│  LOCAL EMBEDDINGS   │  │  SQLITE                           │
│                     │  │  ~/.synabun/mcp-data/memory.db    │
│  • Transformers.js  │  │                                   │
│  • all-MiniLM-L6-v2 │  │  Memories + revision history      │
│  • 384 dimensions   │  │  FTS5 keyword index               │
│  • Isolated worker  │  │  Vectors as Float32 BLOBs         │
│    process          │  │  Session evidence, trash          │
└─────────────────────┘  └───────────────────────────────────┘
                                        │
                                        ▼
                        ┌───────────────────────────────────┐
                        │    NEURAL INTERFACE               │
                        │    (Express REST API + 3D UI)     │
                        │    localhost:3344                 │
                        └───────────────────────────────────┘

Fluxo de dados #

Escrita de uma memória: a IA chama remember(content, category, project) → os formatos conhecidos de credenciais presentes no texto são ocultados → o embedding do conteúdo é gerado localmente → a memória, seus metadados e sua primeira revisão são gravados no SQLite → o UUID completo é retornado.

Leitura de memórias: a IA chama recall(query) → a busca por palavra-chave do FTS5 e a busca por embedding indicam, cada uma, seus candidatos → o refinamento por trechos compara os melhores documentos pai trecho a trecho → a fusão por ranking recíproco combina os rankings → os resultados voltam como memórias completas ou como trechos compactos, dentro de um orçamento de tokens.

Neural Interface: o navegador se conecta à API REST do Express na porta 3344 → carrega as memórias → renderiza o mapa de memórias 3D com Three.js → permite buscar memórias, movê-las para o Lixo, restaurá-las, fazer backup e sincronizar.

Recuperação híbrida #

A recuperação não é mais uma única pontuação de similaridade. O motor Memory v2 combina vários sinais:

• Canal de palavras-chave — o FTS5 do SQLite encontra identificadores exatos e evidências que aparecem no fim de documentos longos
• Canal de embeddings — vetores de documento gerados pelo modelo MiniLM local encontram memórias pelo significado
• Refinamento por trechos — até 50 candidatos por canal indicam no máximo 100 documentos pai, cujos trechos são então comparados. Ele refina candidatos; não é uma varredura exaustiva de todos os trechos.
• Fusão por ranking recíproco — combina os rankings em uma lista só. O min_score filtra pela similaridade de cosseno bruta ou pela cobertura de palavras-chave antes da fusão.
• Fallback — se o modelo de embedding estiver ausente ou falhar, a recuperação por palavra-chave continua disponível e as novas memórias são salvas com a indexação semântica pendente

Sem um filtro project, a recuperação busca em todos os projetos e dá prioridade ao atual; o recency_boost desloca o ranking para as memórias recentes (meia-vida de 14 dias, peso de 55% para a recência). O caminho de recuperação anterior à 2.0 continua disponível como rollback: defina SYNABUN_MEMORY_ENGINE=legacy no servidor e reinicie.

Ferramentas MCP #

O SynaBun expõe 157 ferramentas pelo Model Context Protocol. Onze ficam sempre ativas — remember, recall, reflect, forget, restore, memories, category, sync, loop, profile e choice — e as outras 146 ficam em 21 grupos de ferramentas que os perfis de ferramentas ligam e desligam. As ferramentas de memória abaixo são o núcleo do sistema; cada um dos outros grupos está documentado em sua própria seção.

Grupos de ferramentas #

As demais ferramentas são organizadas em grupos. Um perfil decide quais grupos um runtime enxerga; dois grupos são liberados conforme quem está chamando, e não pelo perfil.

remember #

Armazena uma memória com conteúdo, categoria, projeto e metadados opcionais. Retorna o UUID completo da memória criada.

// Store a bug fix
remember({
  content: "Fixed race condition in auth middleware by adding mutex lock around token refresh logic. Root cause was concurrent requests hitting the token expiry check simultaneously.",
  category: "bug-fixes",
  project: "my-app",
  importance: 8,
  tags: ["auth", "race-condition", "middleware"],
  kind: "issue",
  source: "self-discovered",
  related_files: ["src/middleware/auth.ts"],
  idempotency_key: "fix:auth-race"
})

category e project são obrigatórios em toda chamada. kind pode ser note (padrão), decision, issue, preference, fact ou session. O campo source aceita user-told, self-discovered ou auto-saved. A importância vai de 1 (trivial) a 10 (fundamental), e o padrão é 5.

idempotency_key deixa as novas tentativas seguras: dentro de um projeto e de uma categoria, a mesma chave com o mesmo conteúdo retorna o UUID existente em vez de gravar uma cópia. source_ref registra um identificador de sessão ou de evento. Formatos conhecidos de credenciais (chaves de API, tokens, blocos de chave privada) são ocultados antes de a memória passar pelo embedding e ser armazenada.

recall #

Busca nas memórias armazenadas com recuperação híbrida. Encontra memórias relevantes pelo significado, mesmo quando as palavras não batem, e pela palavra-chave exata quando batem.

// Compact, budgeted discovery with filters
recall({
  query: "authentication issues token refresh",
  project: "my-app",
  tags: ["auth", "middleware"],
  tag_match: "all",
  after: "2026-09-01T00:00:00Z",
  format: "compact",
  token_budget: 1500,
  explain: true
})

Todos os parâmetros de filtro são opcionais. Sem project, a busca cobre tudo, com um reforço para o projeto atual. Prefira format: "compact" para descobrir o que existe e depois busque os originais completos com memories, ação get ou get-batch.

reflect #

Atualiza uma memória existente. Informe só os campos que você quer mudar. Se content for atualizado, o vetor de embedding é gerado de novo automaticamente.

// Update importance and add a tag, only if nothing changed since revision 3
reflect({
  memory_id: "8f7cab3b-644e-4cea-8662-de0ca695bdf2",
  importance: 9,
  add_tags: ["critical"],
  subcategory: "auth",
  expected_revision: 3
})

// Mark this memory as the replacement for an older one
reflect({
  memory_id: "8f7cab3b-644e-4cea-8662-de0ca695bdf2",
  supersedes: "2c1d7e90-5b1a-4f6e-9a3c-7d2e8f4b6a10"
})

expected_revision rejeita a atualização se a memória mudou desde aquela revisão. supersedes vincula explicitamente esta memória como substituta de outra memória ativa no mesmo projeto; ciclos são rejeitados, e uma memória substituída fica fora da recuperação do estado atual.

forget / restore #

forget move uma memória para o Lixo (exclusão reversível). restore a traz de volta. Você também pode gerenciar as memórias do Lixo pelo painel Lixo da Neural Interface.

// Soft-delete
forget({ memory_id: "8f7cab3b-644e-4cea-8662-de0ca695bdf2" })

// Restore from trash
restore({ memory_id: "8f7cab3b-644e-4cea-8662-de0ca695bdf2" })

memories #

Navegue pelas memórias, busque uma por inteiro, revise as revisões e controle a manutenção. As ações de listagem cortam o conteúdo em 150 caracteres; get o retorna sem cortes.

// Get recent memories
memories({ action: "recent", limit: 10 })

// Fetch one memory in full
memories({ action: "get", id: "8f7cab3b-644e-4cea-8662-de0ca695bdf2" })

// Project briefing without a search query
memories({ action: "context", project: "my-app", token_budget: 1500 })

// Review revisions, then roll back to revision 2
memories({ action: "history", id: "8f7cab3b-644e-4cea-8662-de0ca695bdf2" })
memories({ action: "undo", id: "8f7cab3b-644e-4cea-8662-de0ca695bdf2", revision: 2, expected_revision: 4 })

sync #

Detecta memórias cujos related_files mudaram desde a última atualização da memória. Compara os hashes SHA-256 dos arquivos com os checksums armazenados e retorna uma lista compacta (IDs e arquivos alterados, sem conteúdo). Passe categories para restringir a varredura; o limit padrão é 50 (máximo 1.000).

// Check one project, scoped to two categories
sync({ project: "my-app", categories: ["my-app-architecture", "my-app-bugs"] })

// Raise the limit for a narrow category
sync({ categories: ["my-app-config"], limit: 200 })

category #

Uma única ferramenta gerencia a taxonomia de categorias; o parâmetro action escolhe entre criar, atualizar, apagar ou listar. Categorias podem ter relações de pai e filho. Criar ou atualizar uma categoria dispara uma atualização dinâmica do schema, então as descrições das ferramentas mudam na hora.

// Create a parent category
category({
  action: "create",
  name: "myproject",
  description: "All knowledge for My Project",
  is_parent: true,
  color: "#3b82f6"
})

// Create a child category
category({
  action: "create",
  name: "myproject-bugs",
  description: "Bug fixes and known issues",
  parent: "myproject"
})

// Rename a category
category({ action: "update", name: "myproject-bugs", new_name: "myproject-issues" })

// Delete, reassigning memories to another category
category({ action: "delete", name: "myproject-issues", reassign_to: "myproject-notes" })

// List all categories as a tree
category({ action: "list", format: "tree" })

list aceita format tree (padrão), flat ou parents-only. Ao apagar uma categoria pai, reassign_children_to move as filhas para outra categoria pai.

profile #

O roteador de capacidades, sempre disponível. action: "get" retorna o perfil atual, os grupos ativos e os presets; action: "set" troca o perfil apenas neste runtime e atualiza a lista de ferramentas do host. A troca nunca afeta outras sessões nem o padrão das sessões futuras.

// Inspect this runtime
profile({ action: "get" })

// Switch to a preset, or pass comma-separated groups
profile({ action: "set", profile: "linkedin" })
profile({ action: "set", profile: "git,image,browser,gsc" })

• O Claude Code sempre roda o perfil full: ele carrega os schemas das ferramentas sob demanda, então não precisa de restrição.
• Os painéis laterais do Codex anunciam o catálogo completo desde o início de cada turno, com as definições das ferramentas carregadas sob demanda; ali, um perfil é só uma seleção de foco e não exige recarregar nada.
• Os grupos agents e computer nunca fazem parte de um preset. profile set não consegue nem revelá-los nem ocultá-los.
• Os perfis que você adiciona na Neural Interface aparecem ao lado dos presets nativos. No shell, synabun profile list, synabun profile get e synabun profile set <name> mostram os perfis e alteram o perfil padrão armazenado.

choice #

Um prompt de múltipla escolha que aguarda a resposta do usuário para hosts sem uma ferramenta nativa de perguntas, como o Codex no modo Default. Ele envia de uma a três perguntas pelos formulários de elicitação do MCP; cada pergunta tem de duas a quatro opções mutuamente exclusivas, e uma resposta livre "Outro" é sempre oferecida. Se o host informar que não oferece elicitação, o assistente faz as mesmas escolhas numeradas uma única vez, em texto puro.

choice({
  questions: [{
    id: "scope",
    header: "Scope",
    question: "Which memories should the audit cover?",
    options: [
      { label: "This project", description: "Only memories tagged with the current project" },
      { label: "Everything", description: "All projects and categories" }
    ]
  }]
})

Motor de memória v2 #

O SynaBun 2.0.0 leva todos os recursos de memória — as ferramentas MCP, a busca da Neural Interface, os hooks do Claude Code, a indexação de sessões e a interface de terminal — para um único motor local compartilhado. Os nomes de ferramentas, argumentos obrigatórios, UUIDs, rótulos de projeto e conteúdos armazenados que você já tem continuam funcionando.

Recuperação híbrida #

A recuperação híbrida é o padrão. Ela combina SQLite FTS5, embeddings de documentos e refinamento de trechos usando reciprocal rank fusion.

• Filtros de projeto explícitos nunca se estendem a outros projetos. Aliases de projeto registrados e diferenças de maiúsculas e minúsculas são resolvidos sem renomear os registros armazenados.
• Por padrão, basta a memória ter qualquer uma das etiquetas informadas; tag_match: "all" exige todas.
• Documentos longos ganham trechos de origem conferidos pelo tokenizador e um vetor agregado do documento, então identificadores exatos e evidências que aparecem no fim de documentos longos são encontrados.
• Até 50 candidatos por canal de recuperação indicam no máximo 100 documentos pai para o refinamento de trechos.
• As pontuações de ranking são sinais de relevância, não probabilidades de confiança.

Recuperação compacta e contexto #

O formato de saída original e os limites de recuperação que você configurou continuam valendo. Mas os agentes podem pedir evidências concisas:

{
  "query": "SQLite backup checkpoint policy",
  "project": "synabun",
  "format": "compact",
  "token_budget": 1500,
  "include_sessions": true
}

• O orçamento compacto inclui os metadados e usa uma estimativa local em UTF-8. Busque a evidência original com a ação get de memories, ou com get-batch para até 50 UUIDs.
• A ação context de memories, com um projeto explícito, retorna um resumo extrativo e limitado das decisões, problemas, preferências e notas recentes, sem gerar o embedding de uma consulta. Ela preserva os IDs de origem e não inventa uma narrativa.
• A injeção automática de memórias no Claude Code usa um teto estimado de 600 tokens. Evidências repetidas são suprimidas apenas para o mesmo chamador, a mesma sessão, a mesma revisão da memória e a mesma geração de contexto; recuperações explícitas continuam repetíveis.

Revisões, desfazer e substituição #

• remember — kind, source_ref e idempotency_key são opcionais. As chaves de repetição têm escopo de projeto e categoria.
• reflect — expected_revision rejeita uma atualização desatualizada. supersedes vincula explicitamente uma substituta a outra memória ativa do mesmo projeto.
• memories — history lista as revisões; undo precisa de id, revision e expected_revision, e cria uma nova revisão. feedback aceita useful, irrelevant ou incorrect.
• Cartões de memória mostram o histórico de revisões e os controles de restauração. Se houver um conflito de revisão, as edições de conteúdo ficam guardadas como rascunho não salvo.
• Checagem de origem — as verificações de checksum dos arquivos rodam de forma assíncrona depois da recuperação; um arquivo relacionado alterado ou ausente marca a memória como pendente de nova checagem.

Manutenção reversível #

A manutenção roda localmente, em tarefas limitadas, e você pode pausar, retomar ou repetir em Ajustes → Memória e backups → Manutenção ou com a ação maintenance de memories. Ela indexa trechos, agrupa cópias exatas dentro de limites compatíveis de projeto, categoria, origem e etiqueta, e propõe para revisão registros parecidos ou possivelmente conflitantes. As heurísticas de similaridade e de negação só criam sugestões de revisão; sozinhas, elas nunca reescrevem nem substituem um fato. Com as decisões por IA ativadas, um julgamento confiante pode marcar uma memória como substituída, e cada substituição dessas aparece listada com Desfazer e Manter.

Ingestão de sessões #

Os arquivos de transcrição gerenciados do Claude Code e do Codex entram em um leitor JSONL limitado e retomável, e o histórico do OpenCode é normalizado para a mesma ingestão. A ingestão de novas transcrições cria evidências de sessão, e não memórias duplicadas. O raciocínio interno e as injeções de sistema ficam de fora, e as transcrições originais nunca são editadas. Um cliente sem suporte precisa expor sua transcrição para que a captura automática funcione — o MCP sozinho não revela uma conversa.

Migração e rollback #

• Na primeira abertura do banco de dados, um snapshot consistente memory.db.pre-v2-*.bak é criado se já houver dados, e então o schema é migrado de forma aditiva; uma falha desfaz o trabalho no schema. Uma atualização posterior do schema gera seu próprio snapshot memory.db.pre-v3-*.bak.
• Depois de atualizar, reinicie a Neural Interface e os processos MCP conectados para que todos carreguem o mesmo motor.
• Para reverter a recuperação, defina SYNABUN_MEMORY_ENGINE=legacy no servidor e reinicie. Isso mantém o banco de dados v2 e todas as novas gravações.
• Se o modelo de embedding ainda não estiver em cache, instale os assets dele uma vez depois do build:

npm --prefix mcp-server run setup:embeddings

Presets de perfil de recuperação #

Controle quanto contexto entra em cada chamada de recall. Configure em Ajustes → Memória e backups na Neural Interface.

4 presets #

6 controles de ajuste fino #

• Número de resultados — limite padrão por recall.
• Limiar de similaridade — pontuação mínima de similaridade de cosseno.
• Intensidade do filtro de etiquetas — o quanto as etiquetas coincidentes reordenam os resultados.
• Inclusão de trechos de sessão — inclui trechos da transcrição das conversas.
• Piso de importância — descarta memórias abaixo de uma importância mínima.
• Viés temporal — desloca o peso para a recência ou para a similaridade semântica.

Indicador de impacto #

O painel de ajustes mostra uma estimativa em tempo real de tokens por recuperação, memórias alcançáveis e tamanho do contexto de sessão, para você planejar quanto da janela de contexto quer usar. O endpoint /api/recall-impact faz o cálculo (usando avg_tags_len, avg_files_len e estatísticas de sessão por projeto).

Padrões do servidor #

Configure os parâmetros padrão da recuperação globalmente com getRecallDefaults(). Toda CLI segue os padrões do servidor, a menos que a chamada da ferramenta os sobrescreva explicitamente.

Sistema de categorias #

As categorias são o principal eixo de organização do SynaBun. Cada memória pertence a exatamente uma categoria. Elas aceitam hierarquia pai/filha, cores personalizadas e descrições que aparecem nas dicas de schema da ferramenta recall.

Hierarquia #

Uma categoria pode ter uma categoria pai, formando uma estrutura em árvore. As categorias pai funcionam como os ramos de organização de nível mais alto. As categorias filhas fazem o roteamento fino dentro de um ramo. Ao rotear uma memória, use a categoria aplicável mais específica.

myproject (parent)
├── myproject-bugs        # Bug fixes and known issues
├── myproject-arch        # Architecture decisions
├── myproject-api         # API design notes
└── myproject-deploy      # Deployment and infrastructure

Descrições de roteamento #

O campo description de cada categoria aparece no schema da ferramenta MCP como dica para os assistentes de IA. Uma boa descrição explica o que entra aqui em linguagem de roteamento:

Good: "Bug fixes, known issues, and error resolutions for My Project"
Good: "Architecture decisions, system design patterns, and rationale"

Bad: "Bugs"
Bad: "My stuff"

Atualização dinâmica do schema #

Quando você cria, renomeia ou atualiza uma categoria, o SynaBun atualiza automaticamente o schema da ferramenta MCP e envia notifications/tools/list_changed. Sua ferramenta de IA busca de novo a lista de ferramentas e vê as descrições de categoria atualizadas — sem reiniciar o servidor.

Categorias padrão #

As categorias são definidas pelo usuário. Uma instalação nova já vem com algumas das quais os hooks e as ferramentas dependem, e cada projeto registrado ganha uma categoria pai com quatro filhas:

Embeddings locais #

O SynaBun gera embeddings localmente com Transformers.js. Não há provedor para escolher, nem chave de API, nem dependência de rede depois do primeiro download do modelo.

• Um processo worker sem estado por servidor cuida da inferência ONNX nativa, com uma fila de prioridade limitada e 256 embeddings de consultas e documentos em cache. Requisições interativas têm prioridade sobre o trabalho em segundo plano.
• A inferência de embedding usa só arquivos em cache e nunca envia o texto das memórias a um provedor de nuvem.
• Se o modelo de embedding estiver ausente ou falhar, a recuperação por palavra-chave continua disponível e as novas memórias são salvas com a indexação semântica pendente.

Decisões de IA (Jev) #

O SynaBun pode pedir ao Jev (TypeSafe System One) um julgamento tipado em todo ponto onde uma regex ou uma constante de similaridade fazia as vezes de uma decisão semântica. A camada é opcional: cada ponto de chamada mantém uma heurística de fallback que funciona, e Ajustes → Decisões de IA controla tudo isso em tempo de execução.

Como funciona #

• Respostas tipadas — um julgamento é uma escolha com um grau de confiança, uma probabilidade de sim/não ou uma pontuação. O código do SynaBun aplica um limiar a ele; o julgamento nunca age sozinho.
• Sempre um fallback — sem chave, com a camada desligada, com um recurso desativado, em caso de timeout ou ao atingir o limite de requisições, a chamada não retorna nada e o recurso roda sua heurística local exatamente como antes.
• Configuração — a chave de API é TYPESAFE_API_KEY em ~/.synabun/.env. O controle geral, os controles de cada recurso, os timeouts e os limiares ficam nos Ajustes e valem em segundos, sem rebuild nem reinício.
• Kill switch — SYNABUN_TYPESAFE=off interrompe todas as chamadas de saída e prevalece sobre todo o resto.
• Log de julgamentos — uma linha por chamada (recurso, modelo, latência, tokens, o que o chamador fez com a resposta), as 20.000 linhas mais recentes, com uma prévia sem credenciais.

O que ele decide #

Consultivo desde o projeto #

• No navegador e no desktop, o Jev nunca controla nada: ele responde a perguntas tipadas sobre uma descrição minimizada do que está visível, e as ferramentas exibem essa resposta ao lado da saída normal.
• Texto digitado, rascunhos, valores de formulário, cookies e armazenamento nunca são enviados. O texto de páginas e telas é tratado como dado não confiável e chega ao Jev apenas como estado, nunca dentro de uma instrução.
• Os valores de possíveis credenciais são mascarados antes de o filtro de segredos enviá-los.
• Os dois recursos que agiriam com base em um julgamento — a autocorreção segura para um browser_click que falhou e o acionamento por intenção para computer_ax — vêm desligados e ficam bloqueados até que um benchmark seja aprovado para a configuração exata em execução.

Assistente do SynaBun #

O Assistente é o orquestrador central da Neural Interface, ciente das suas memórias. Ele pensa com o cérebro que você escolher (Claude Code, Codex ou OpenCode), recupera memórias do SynaBun a cada turno, resolve sozinho as coisas pequenas — operar seu Mac, navegar com o navegador do SynaBun, pequenas edições e comandos de shell, memória, loops e agendamentos — e delega o trabalho mais pesado aos três painéis laterais de IA, como execuções autônomas de workers que ele acompanha, direciona e resume.

O cérebro é o planejador: ele decide onde cada pedido que exige uma ação roda, no próprio modelo ou no modelo de um worker, e o SynaBun aplica o modo de roteamento da sessão, perguntando qual modelo usar quando o modo assim determina.

Como abrir #

A aba de terminal e o painel lateral montam o mesmo componente, então todo controle, cartão e comando de barra existe nos dois. Uma sessão vive em um lugar por vez, e Esc dentro do Assistente aborta um turno em andamento.

Cérebros, modos e contas #

• Provedor — Claude Code (Agent SDK), Codex (app-server) ou OpenCode (um opencode serve isolado). Trocar de provedor inicia uma nova sessão de servidor na mesma aba.
• Modelo e esforço (Claude, Codex) ou agente (OpenCode), projeto (o diretório de trabalho, que também define o projeto de memória), perfil MCP e modo de permissão (perguntar antes de usar ferramentas ou autônomo).
• Plano — uma chave separada para os três provedores. Com o Plano ligado, alterações de código ficam bloqueadas e todo o resto (comandos de shell, o navegador, uso do computador, outras ferramentas) roda no modo de aprovação da sessão. Aprovar o plano encerra o modo de plano.
• Contas (Claude e Codex) — escolha, adicione, renomeie ou remova uma conta salva. As contas do Claude são diretórios de configuração separados (~/.claude-accounts/<id> com CLAUDE_CONFIG_DIR); as contas do Codex usam ~/.codex-accounts.
• Modelos ocultos — desligue qualquer modelo de qualquer provedor em ⋯ → Modelos… ou com /models. Um modelo oculto nunca chega aos cartões de rota, ao catálogo, aos menus de modelo nem ao cérebro.

Memória em cada turno #

• Todo turno não trivial do usuário dispara uma recuperação com orçamento de tokens, usando o mesmo motor dos hooks do Claude Code. As memórias recuperadas aparecem como chips acima da transcrição.
• Depois de cada execução de worker concluída, o Assistente deve registrar o resultado com remember, usando o id da execução como source_ref. Se nada foi armazenado, o servidor grava automaticamente uma memória agent-runs.
• Uma sessão é uma única conversa contínua, não um contexto novo a cada prompt. O id de sessão ou de thread do provedor fica guardado no registro da sessão, então a conversa é retomada depois de um período ocioso ou de um reinício do servidor.

Briefs de esclarecimento #

A maioria dos pedidos é clara o bastante para agir. Quando um deles é ambíguo de verdade — duas leituras plausíveis com resultados diferentes, um alvo incerto, escopo destrutivo ou irreversível, gasto, ou memórias que entram em conflito com ele — o cérebro pergunta primeiro, uma vez só, antes de rotear.

• O cartão — Antes de começar mostra de 1 a 3 perguntas (de 2 a 4 opções cada, a recomendada primeiro) e, abaixo delas, as suposições que o cérebro vai adotar para tudo o que não perguntar. Escolha uma opção, digite sua própria resposta ou pule e siga com as suposições.
• Espera — agent_clarify espera até 45 segundos por padrão. Depois disso, o cérebro encerra o turno e suas respostas chegam mais tarde como um evento de caixa de correio; o cartão fica aberto até ser respondido.
• O trabalho dependente espera — enquanto houver perguntas abertas, agent_route responde clarifying e agent_dispatch é recusado com CLARIFICATION_PENDING. O trabalho que não depende das respostas segue em frente.
• O brief — seu pedido original, suas respostas, as restrições e as suposições formam o brief da sessão (brief_id). Todo worker desse pedido o lê como uma seção USER BRIEF; respostas e restrições prevalecem sobre o texto da tarefa quando há conflito, e as suposições ficam marcadas como não confirmadas.
• Ajustes — clarify.enabled e clarify.waitSeconds em ~/.synabun/data/assistant-config.json.

Comandos de barra #

/dispatch <claude|codex|opencode> [--model m] [--effort e] [--agent a] [--project p] [--mcp profile] [--account id] [--ask] <task>
/agents   /stop [runId|all]   /recall <query>   /remember <text>   /model   /project
/routes [always|unsure|never]   /computer [on|off]   /budget   /models
/new   /resume   /compact   /clear   /help

Ferramentas agent_* #

O cérebro só vê o grupo de ferramentas agents quando sua sessão MCP tem o papel de assistente. Workers despachados nunca o recebem, então um worker não pode despachar outros workers. As chamadas são feitas uma de cada vez.

Roteamento de modelos #

O cérebro chama agent_route uma vez antes de qualquer tarefa que exija uma ação, com uma classe de tarefa, um resumo de uma linha, sua confiança (0–1) e de 1 a 3 propostas: direct (aqui, no próprio modelo) ou dispatch (um provedor e um modelo de worker). O seletor de modo de rota na barra de ferramentas do Assistente decide o que acontece em seguida.

Modos de rota #

• Os cartões de rota esperam até 45 segundos dentro da chamada da ferramenta. Depois disso, o cérebro encerra o turno e sua escolha posterior chega como um evento de caixa de correio.
• Escolher aqui em outro modelo do provedor do cérebro executa uma continuação de um turno nesse modelo, na mesma conversa; o turno seguinte volta para o modelo da sessão.
• Os modelos são validados contra o catálogo. Execuções que falham ou são bloqueadas trazem um escalonamento de um nível, mostrado no cartão da execução como Escalonar para ‹modelo›. Com as decisões de IA ativadas, uma falha transitória (timeout, limite de requisições, indisponibilidade) oferece uma nova tentativa no mesmo modelo, e uma execução que precisa de acesso ou de uma resposta sua não oferece escalonamento.
• Os ajustes ficam em ~/.synabun/data/assistant-config.json, na chave routing, e no editor Rotas de modelos (⋯ → Rotas de modelos…, ou /routes).

Classes de tarefa #

chat, quick, code, complex, review, research, browser, computer, automation, design, image_gen e video_gen. Três delas têm regras de capacidade:

• Criação de imagem (image_gen) e Criação de vídeo (video_gen) sempre rodam em um worker cujo modelo gera a mídia por conta própria. Sem um modelo capaz, agent_route recusa com no_capable_model. O SynaBun copia os arquivos gerados para ~/.synabun/data/media/<runId>/ e os mostra no cartão da execução.
• Design (design) sempre roda em um único worker cujo modelo tem visão. O worker recebe as regras de design do SynaBun — que você pode substituir em ~/.synabun/data/playbooks/design.md — e o bloco do Guia de estilo do projeto, e captura telas em 375 / 768 / 1440 px no navegador do SynaBun.
• Uma instalação padrão não tem nenhum modelo que gere vídeo: Codex e Claude não geram. A linha Criação de vídeo em Rotas de modelos avisa isso até que você conecte um provedor cujos modelos produzam vídeo.

A barreira de rota #

Todo turno do cérebro começa sem rota. Até o cérebro chamar agent_route naquele turno, toda ferramenta fora de um pequeno conjunto isento — as ferramentas de memória, as ferramentas agent_*, as ferramentas de pergunta, profile, image_staged, computer_status, ToolSearch e TodoWrite — é recusada antes de rodar, com um erro de ferramenta que diz ao modelo o que fazer em seguida. Depois de 8 recusas em um turno, o turno é abortado. Workers despachados, os painéis laterais do Claude Code / Codex / OpenCode e as sessões de CLI não têm barreira.

Workers e despacho #

Peça em linguagem natural ("escreva a documentação dos hooks com o Codex e depois peça para o Claude revisar") ou use /dispatch. Cada despacho vira uma execução de tarefa: uma conversa com o provedor que executa a tarefa, termina com um bloco ## Result (status, summary, changes, follow_ups, uma question opcional e media para execuções de imagem, vídeo e design) e depois fica ativa para continuações até o Assistente concluí-la ou o tempo limite de ociosidade estourar.

A execução entra como uma aba de automação no painel lateral correspondente, sem roubar o foco. O dock de agentes, abaixo da transcrição, lista as execuções com provedor, modelo, conta, status, tempo decorrido e custo, além de Focar / Parar / Ler e Parar tudo.

// Dispatch a worker on an approved route
agent_dispatch({
  assistant_session_id: "<assistant-session-id>",
  route_id: "<route-id>",
  task: "Write reference docs for the hooks in docs/hooks.md. End with a ## Result block.",
  cwd: "/Users/me/my-project",
  capability: "workspace",
  max_minutes: 30,
  budget_usd: 3,
  title: "Hooks docs"
})

// Block until it goes idle, then read the parsed result
agent_wait({ run_id: "<run-id>", until: "idle", timeout_seconds: 50 })
agent_read({ run_id: "<run-id>", format: "result" })

Parâmetros de agent_dispatch #

Travas e limites #

Valores padrão, editáveis em ~/.synabun/data/assistant-config.json, na chave limits, e lidos em tempo real:

• Concorrência por provedor — Claude 3, Codex 4 no total (2 por conta), OpenCode 3
• Por sessão — 6 execuções em andamento e 20 na fila, fan-out de 6
• Tempo — teto de 45 minutos por execução, timeout de inatividade de 20 minutos, timeout de permissão de 10 minutos, timeout de pergunta de 30 minutos
• Continuações — 6 turnos de continuação por execução

Execuções que leem o navegador ou conteúdo não confiável precisam ser read-only ou workspace, a menos que tenham a etiqueta user-authorized-full.

Caixa de correio e resultados #

Os eventos do ciclo de vida das execuções — resultado, aguardando entrada, pedido de permissão, falha, travamento, aviso de orçamento, teto rígido atingido — são agrupados e entregues ao cérebro em um único turno [SynaBun Mailbox] quando ele está ocioso, e aparecem como chips na transcrição. agent_wait e agent_status dão ao cérebro visões enxutas das execuções (status por turno e um resumo curto); agent_read com format: "text" devolve o texto completo.

Política de navegador #

O cérebro e os workers que ele despacha só olham páginas — web pública ou localhost, tanto faz — pelas ferramentas browser_* do SynaBun, que abrem o navegador configurado no SynaBun. Eles não rodam código próprio de Playwright, Puppeteer ou Selenium, não iniciam binários de navegador, não tiram screenshots em modo headless e não usam ferramentas próprias de busca na web ou de fetch. Verificações visuais passam por browser_screenshot, e erros de página, por browser_console. Quando o navegador do SynaBun não consegue fazer alguma coisa, eles param e avisam, em vez de trocar de ferramenta. Rodar a suíte de testes automatizados do próprio projeto continua permitido.

Orçamento #

⋯ → Orçamento… (também /budget, ou um clique no chip de gastos) define os tetos de gasto. Eles ficam em assistant-config.json e valem sem reiniciar.

Todo valor fica entre US$ 0,10 e US$ 1.000, com padrão ≤ maior ≤ teto rígido, aviso < teto rígido e teto do cérebro ≤ teto rígido. Um salvamento que quebra essas regras é recusado.

Como os tetos são aplicados #

• Uma nova execução recebe, no máximo, o que sobra do teto rígido depois do gasto da sessão e das reservas das execuções ativas. Se não sobra nada, o despacho é recusado com BUDGET_EXCEEDED.
• Uma execução que atinge o próprio teto para, e qualquer continuação dela é recusada.
• No teto rígido da sessão, todas as execuções ativas, na fila e retidas da sessão param, novos despachos e continuações são recusados, e os turnos do cérebro ficam recusados até o teto ser aumentado.
• Se o preço do modelo não é conhecido, os tetos bloqueiam a execução: o modelo não é despachado (BUDGET_UNPRICED).

Como os gastos de cada provedor são contabilizados #

• O Claude informa o próprio custo. O teto da execução é passado para a CLI na inicialização e conferido entre as chamadas ao modelo, então uma chamada pode ultrapassá-lo.
• O OpenCode informa o custo por mensagem do assistente. A execução para no primeiro passo depois do teto, então um passo pode ultrapassá-lo.
• O Codex informa só tokens; o custo é calculado a preço de tabela. Os tetos são conferidos depois de cada turno, então um turno pode ultrapassá-los.
• Nenhum teto consegue interromper uma chamada ao modelo que já está em andamento. O cérebro é conferido antes de cada turno; um turno em andamento termina.

Uso de tokens #

O Assistente conta cada token de uma sessão a partir do que cada provedor informa e mostra o total acumulado em um medidor acima do campo de mensagem: a sessão inteira, com entrada e saída separadas e o valor em dólares a preço de tabela. Os tetos em dólar de Orçamento são outra coisa — eles medem dinheiro; aqui a conta é de tokens.

Sessões, tarefas e execuções #

• Uma tarefa é uma mensagem sua mais tudo o que ela desencadeia: os turnos do cérebro, as execuções que ele despacha, os subagentes dessas execuções, as chamadas a modelos auxiliares e os julgamentos de decisões de IA.
• O total da sessão é a soma das tarefas. Um prompt de continuação abre uma nova tarefa do zero e soma na sessão; ele nunca zera o número principal.
• O total é montado a partir de um registro somente de acréscimo em ~/.synabun/data/assistant-usage/<sessionId>.jsonl, então recarregar a página ou reiniciar o servidor mostra o mesmo número.

Classes de tokens #

Toda contagem é dividida em cinco classes que nunca se sobrepõem: entrada (sem cache), escrita em cache, leitura de cache, saída (visível) e raciocínio. Os números de cada provedor são convertidos para essas classes, e todo objeto tokens também traz inputTotal (entrada + escrita em cache + leitura de cache), outputTotal (saída + raciocínio) e total.

Status #

"Exato" quer dizer igual ao que cada provedor informa; não é uma medição independente. Os valores em dólar seguem os preços de tabela da API, e a linha de cada modelo diz como o valor é conhecido: informado pela CLI, equivalente a preço de tabela, gratuito ou sem preço de tabela.

Como ler #

// Session totals plus the current task
agent_usage({ assistant_session_id: "<assistant-session-id>" })

// Every task of the session, narrowed to one run
agent_usage({ assistant_session_id: "<assistant-session-id>", task: "all", run_id: "<run-id>" })

Os mesmos dados estão disponíveis em GET /api/assistant/sessions/:id/usage. agent_usage só lê, então o cérebro pode chamá-la em um turno que ainda não tem rota.

Uso do computador #

No macOS, o Assistente pode operar seu Mac como uma pessoa faria: ele tira capturas de tela, move e clica o mouse, digita, aciona atalhos, abre e foca apps e lê a árvore de acessibilidade de um app. Ele é totalmente autônomo — não há pedidos de aprovação a cada ação — e fica limitado por proteções que estão sempre ativas e por controles de parada que você pode acionar a qualquer momento.

Só o cérebro do próprio Assistente e as execuções de workers que ele dispara com uses_computer: true recebem as ferramentas. O uso do computador exige macOS 14 ou mais recente; outras plataformas retornam unsupported.

Configuração inicial #

1. Compile o auxiliar. O SynaBun compila um pequeno auxiliar nativo em Swift com as Xcode Command Line Tools. Se o swiftc não estiver instalado, a bandeja de configuração oferece a instalação (xcode-select --install).
2. Conceda as permissões. O macOS associa Gravação de Tela e Acessibilidade ao app que abriu o SynaBun, normalmente seu terminal. Ative esse app nos Ajustes do Sistema e verifique de novo.
3. Pronto. Novas sessões do Assistente já começam com a opção Computador ativada. Desative por sessão com a própria opção ou com /computer off.

Ferramentas #

// Read the frontmost app's controls, then press one by ref
computer_ax({ action: "snapshot" })
computer_ax({ action: "press", snapshot_id: "s7", ref: "e12" })

// Click a coordinate of the latest screenshot
computer({ action: "left_click", coordinate: [640, 400] })

As coordenadas são pixels da captura de tela mais recente. Uma ação por coordenada precisa de evidência recente — uma captura feita depois da última ação, há no máximo dois minutos, sem entrada do usuário nem mudança de tela desde então — caso contrário, ela é recusada com STALE_SCREENSHOT e uma nova captura de tela vem anexada.

Proteções #

Controles de parada #

Pare com o botão vermelho Parar · Esc, com Esc (vale no sistema inteiro enquanto um agente controla o desktop), jogando o ponteiro no canto superior esquerdo da tela principal ou com POST /api/desktop/stop. Parar aborta a ação, solta as teclas pressionadas, interrompe o turno do Assistente e encerra os workers de uso do computador. Depois disso, o uso do computador permanece bloqueado até você pressionar Retomar — os agentes não podem se reativar sozinhos.

Conexão com o WhatsApp #

Converse com o Assistente do SynaBun pelo WhatsApp. Você escreve em uma conversa do WhatsApp no celular; a mensagem chega ao Assistente rodando no seu computador, e as respostas, perguntas e aprovações dele voltam como mensagens do WhatsApp. Tudo é configurado e controlado em Ajustes → Mensagens → WhatsApp.

O SynaBun se conecta ao WhatsApp do mesmo jeito que o WhatsApp Web, como um aparelho conectado de uma conta, usando o Baileys (um cliente não oficial). Não há conta de desenvolvedor da Meta, aluguel de número de telefone nem webhook público, e nenhum servidor do SynaBun fica no meio do caminho. Seu computador precisa estar ligado e com o SynaBun rodando.

Duas formas de conversar #

No modo Mensagem para si mesmo, o SynaBun lê apenas a sua conversa "Mensagem para si mesmo"; todas as outras conversas, grupos e contatos são ignorados. Com um segundo número, quem enviar primeiro o código de vínculo de uso único vira o dono, e ninguém mais recebe resposta.

Níveis de permissão #

Ajustes → Mensagens → WhatsApp → Segurança define o que uma mensagem vinda do celular pode levar o Assistente a fazer. O nível é aplicado no seu computador, pelo runtime do Assistente, pelo dispatcher dele e pelos hooks do cérebro — não pelo celular.

• Perguntar e Autônomo precisam de um cérebro Claude. Com um cérebro Codex ou OpenCode, a conversa roda em Somente leitura, não importa o que o nível diga.
• O uso do computador pelo WhatsApp fica desligado, a menos que você ative a chave dele em Ajustes, no computador. Nenhuma mensagem do celular consegue ativá-lo.
• Em todos os níveis, comandos e caminhos que alcançam credenciais, a própria sessão do WhatsApp, pontos de persistência ou perfis de navegador são recusados. Essa lista de bloqueio é uma barreira simples, não um sandbox.
• Pausar agora faz o SynaBun parar na hora de agir sobre mensagens do WhatsApp; o celular não consegue desfazer uma pausa feita no computador.

Comandos #

Níveis, modelos e ajustes nunca mudam pelo celular. Texto e imagens são lidos (4 imagens por mensagem, 5 MB cada); voz, vídeo, documentos e figurinhas ainda não são lidos. As mensagens recebidas têm limite de 20 por minuto e 300 por dia.

Neural Interface #

A Neural Interface é um mapa de memórias 3D do seu acervo em localhost:3344 e a sala de controle de todo o resto: categorias, hooks, skills, registro de MCP, os painéis laterais e o Assistente do SynaBun.

Recursos principais #

• Mapa de memórias 3D — cada memória é um ponto. As categorias são ilhas agrupadas em continentes pela categoria pai, e dentro de uma ilha as posições vêm de um UMAP dos embeddings das memórias, então memórias parecidas ficam lado a lado. Memórias mais novas flutuam mais alto, e mais brilho significa mais recente.
• Rótulos que acompanham o zoom — continentes, depois ilhas, depois regiões nomeadas, depois títulos das memórias. Clique em uma memória para abri-la e ver linhas até as memórias mais próximas em qualquer ponto do mapa.
• Alternativa 2D — uma visão 2D das mesmas memórias para workflows com foco em desempenho.
• Busca semântica — pressione / para focar a barra de busca. Os resultados acendem e todo o resto escurece.
• Inspetor de memórias — abra qualquer memória para ver o conteúdo completo, os metadados, os arquivos relacionados e as etiquetas. Os cartões de memória mostram o histórico de revisões e os controles de restauração.
• Barra lateral de categorias — filtros, edição da hierarquia e logos personalizados para categorias pai.
• Painel do Lixo — veja, restaure ou apague de vez as memórias do Lixo sem sair do navegador.
• Painel de sincronização — detecta memórias desatualizadas cujos arquivos de origem mudaram (comparação de hash SHA-256).
• Backup e restauração — exporte e importe snapshots verificados do banco de dados.
• Exportação de categoria — baixe todas as memórias de uma categoria em Markdown.
• OpenClaw Bridge — uma integração somente leitura que sobrepõe as memórias de workspaces do OpenClaw ao mapa.
• Tour do workspace — o botão ? na barra de título abre um tour do workspace desenhado à mão: uma tela de boas-vindas e 14 etapas em seis capítulos, em inglês e português do Brasil.

Recursos de IDE #

• Assistente do SynaBun — o orquestrador central, como uma aba de terminal ou em um painel lateral próprio. Veja Assistente do SynaBun.
• Painéis laterais para Claude Code, Codex e OpenCode — três painéis de chat dedicados, com interrupção por agente, dock de atividade de ferramentas, cartões de permissão, gaveta de TODO, medidor de contexto (com ativação de contexto de 1M), menu de sessões, modal de nova sessão (seletor de projeto + branch) e Multi-CLI Resume. Veja Painéis laterais.
• Estúdio de Skills — navegue, crie, edite, importe e exporte skills e agentes. Suporte a vários arquivos, upload de ícone, validação e gerenciamento de instalação e desinstalação. /synabun e /leonardo rodam tanto no Claude Code quanto no Codex; /synabun changelog é um botão de ação rápida dentro do painel lateral do OpenCode.
• Painel do Guia de estilo — edite a marca e o design system de um projeto com prévias em claro e escuro, importações, histórico e propostas dos agentes. Veja Guia de estilo.
• Estúdio de automações — editor visual de templates para loops e agentes, com pastas recolhíveis criadas pelo usuário (arrastar e soltar, ícones, cores), padrões de execução por template (CLI / Modelo / Esforço de raciocínio / Perfil de MCP) e suporte de primeira classe a 4 CLIs (Claude Code, Codex, Gemini, OpenCode). Veja Estúdio de automações.
• Gerenciamento de MCP — formulário universal de adição com colagem inteligente (detecta sozinho 5 formatos de configuração), sincronização multiplataforma entre as 4 CLIs, cofre central de variáveis de ambiente com mascaramento de valores sensíveis, registro automático de perfis e instalação a partir do GitHub com um clique. Veja Gerenciamento de MCP.
• Terminal com várias abas — terminal baseado em PTY em uma única interface xterm.js, com suporte a cores ANSI (256 cores + truecolor), acompanhamento da branch do git, histórico de comandos, trava de sessão, visão dividida, dicas de ConPTY do Windows e comandos unificados de atualização das CLIs via npm install -g para todas as 4 CLIs.
• Explorador de arquivos — árvore de arquivos do projeto com cores de pasta personalizadas, opções de ordenação e seções recolhíveis.
• Canvas do quadro branco — superfície de desenho compartilhada para a colaboração entre IA e pessoas. Caneta livre, texto, formas, setas, imagens e seções de wireframe, com desfazer e refazer.
• Cartões de memória flutuantes — abra memórias como cartões que você pode arrastar e fixar. Modo compacto (minicartões de 220×120px), posição persistente e capturas de tela do workspace.
• Widget de custos — acompanhamento do custo da API do Claude, com detalhamento por sessão e noção do custo de cada modelo. Pode ser recolhido e encaixado.
• Painel de estatísticas — contagem de memórias por categoria e projeto, distribuição por importância, distribuição por idade e verificações de saúde (memórias desatualizadas, categorias órfãs).

Ajustes e personalização #

• Ajustes — onze páginas de tarefas: Conexões de IA, Memória e backups, Decisões da IA, Projetos, Navegador, Ferramentas conectadas, Acesso a ferramentas, Automações, Mensagens, Notificações e Aparência. Um campo de busca no topo da barra lateral dos Ajustes (Cmd+F / Ctrl+F) encontra qualquer página, seção ou controle.
• Idiomas — inglês e português do Brasil, selecionados em Ajustes → Aparência → Idioma.
• Skins personalizadas — envie temas CSS próprios para a interface inteira.
• Atalhos de teclado — ações que você pode vincular a teclas (alternar painéis, abrir ferramentas, navegação, busca), com importação e exportação das configurações de atalhos.
• Workspaces — salve e restaure layouts de painéis, o estado da barra lateral e as posições dos terminais. Predefinições de layout por variante (2D/3D).
• Ícones de arquivo personalizados — ícones por extensão ou por nome de arquivo, com suporte a PNG/SVG.
• Acesso de convidado — gere links de convite válidos por 24 horas, com controle de permissão por recurso. Suporte a proxy por túnel da Cloudflare para acesso remoto.

API REST #

A Neural Interface roda um servidor Express com 500+ endpoints REST. A interface, os hooks e as integrações externas usam esse servidor:

# List all memories
GET http://localhost:3344/api/memories

# Hybrid search
POST http://localhost:3344/api/search
{ "query": "auth bug", "limit": 5 }

# Get, update, or trash a specific memory
GET    http://localhost:3344/api/memory/:id
PATCH  http://localhost:3344/api/memory/:id
DELETE http://localhost:3344/api/memory/:id

# Revision history and undo
GET  http://localhost:3344/api/memory/:id/history
POST http://localhost:3344/api/memory/:id/undo

# Trash
GET  http://localhost:3344/api/trash
POST http://localhost:3344/api/trash/:id/restore

# Categories and stats
GET http://localhost:3344/api/categories
GET http://localhost:3344/api/stats

# Download a verified full system backup (ZIP)
GET http://localhost:3344/api/system/backup

O mesmo servidor expõe o endpoint MCP por HTTP em /mcp — veja Suporte a vários clientes.

Painéis laterais (Claude, Codex, OpenCode) #

O SynaBun traz três painéis laterais de chat dedicados, que se encaixam ao lado do seu editor e conversam com o mesmo backend de memória. Eles compartilham a mesma linguagem visual e o mesmo conjunto de recursos, sem deixar de expor os recursos nativos de cada CLI.

Matriz de recursos #

Renderização de código #

• Realce de sintaxe em blocos de código delimitados por crases.
• Links em caminhos de arquivo — path/to/file.ts:42 vira um link clicável que leva ao explorador de arquivos.
• Rótulos de linguagem no cabeçalho do código, mais um botão de copiar que só aparece ao passar o mouse.
• Streaming limitado a 30 fps, para manter fluidos os streams longos de tokens sem sobrecarregar o DOM.
• Blocos de raciocínio em tempo real, renderizados progressivamente conforme o modelo transmite o raciocínio (nas CLIs que o emitem).

Chat temporário (Claude Code) #

O estado vazio de uma nova aba do Claude Code tem um botão Chat temporário. Clique nele antes da primeira mensagem para ter uma conversa em que nada é salvo e a memória continua disponível para leitura.

• Nada é salvo — nenhuma transcrição em disco, nenhuma aba salva, nenhuma entrada na lista de sessões. O chat termina quando a aba é fechada, a página é recarregada ou o servidor reinicia.
• A memória pode ser lida, mas não escrita — recall e as outras ferramentas de leitura funcionam, e as memórias relacionadas continuam sendo adicionadas ao seu prompt. remember, reflect, forget, restore e sync não estão na sessão.
• Os hooks saem do caminho — os hooks do SynaBun não registram nada, nunca seguram uma parada por causa de uma memória, não capturam nada na compactação e não guardam nenhum plano.
• As ferramentas que agem fora do SynaBun — navegador, git, Discord e assim por diante — funcionam normalmente, e tudo o que elas criam fica onde foi criado.

Painéis de subagentes (OpenCode) #

• Cada subagente da sessão no painel principal tem sua própria cápsula, na ordem em que foram iniciados, e seu próprio painel, com transcrição, caixa de composição, fila e cartões de permissão e de pergunta.
• A cápsula mostra um ponto enquanto o subagente está em execução, uma marca âmbar enquanto ele espera uma permissão ou uma resposta, um check verde quando termina e uma marca vermelha quando falha.
• Nada abre sozinho: um novo subagente é uma cápsula e um toast. Um clique na cápsula mostra o painel daquele subagente no lugar do painel principal.
• Minimizar esconde o painel e mantém a cápsula; Fechar remove os dois. Nenhum dos dois apaga ou interrompe a sessão do subagente.

Atalhos de teclado #

• Esc — interrompe o turno atual (funciona no painel inteiro, não só quando o campo de entrada está em foco).
• Ctrl/Cmd+Shift+A — mostra ou oculta o dock de atividade das ferramentas do OpenCode.
• Enter — envia a partir do modal de nova sessão; Esc pula.

Estúdio de automações #

Um editor visual de templates para loops autônomos e agentes. Monte uma vez, rode em qualquer CLI.

Pastas recolhíveis #

• Organize templates personalizados em pastas criadas por você; os presets ficam em categorias fixas no código (Social / Produtividade / Monitoramento).
• Arraste templates para o cabeçalho de uma pasta para movê-los; arraste os cabeçalhos das pastas para reordenar.
• Ícone (conjunto de 13 ícones + ícones de plataformas sociais), cor (paleta de 8 amostras), nome e estado recolhido por pasta.
• Menus de clique direito nos templates (Mover para a pasta ▸ / Apagar) e nos cabeçalhos das pastas (Renomear/Mudar a cor, Recolher/Expandir, Apagar).
• O estado recolhido persiste por dispositivo no localStorage; a flag collapsed do servidor é o padrão na primeira execução.
• Cobertura completa de backup e restauração via loop-folders.json; a exportação/importação passa para version: 2, com um array de pastas explícito.

Padrões de execução por template #

• Salve CLI (Claude Code, Codex, Gemini, OpenCode), Modelo, Esforço de raciocínio (só no Claude) e Perfil de MCP (Codex / Gemini / OpenCode) por template.
• O modal de configuração de execução abre já preenchido com as escolhas salvas no template e ainda deixa o usuário alterá-las antes de iniciar o loop.
• O cartão de runtime usa elementos <select> nativos, para que nomes longos de perfil de MCP (por exemplo, "memory-full — 40 tools") não sejam truncados.
• Templates antigos, sem esses campos, usam padrões sensatos (Claude Code / modelo padrão / esforço desligado / MCP "full").

Suporte a 4 CLIs #

• O modo loop roda nas quatro CLIs. cat <taskfile> | opencode run --model <m> é o equivalente não interativo de codex exec para o OpenCode.
• O modo agente é exclusivo do Claude (integração profunda com subagentes). Quando você seleciona uma CLI que não é do Claude, o modo agente é desativado automaticamente e a interface volta à força para o modo loop.
• Os chips de raciocínio / esforço somem no OpenCode (não há flag de raciocínio em opencode run). A seção de perfil de MCP aparece automaticamente nas CLIs que não são do Claude.
• Um template pode anexar ao prompt o Guia de estilo do projeto selecionado.

Gerenciamento de MCP #

Uma tela só para instalar, configurar e sincronizar todos os servidores MCP que você usa — em todas as CLIs.

Formulário universal de adição (Colagem inteligente) #

• Detecta automaticamente 5 formatos de configuração: JSON stdio, URL HTTP, TOML do OpenCode, comando mcp add do Claude e JSON puro.
• Chips de argumentos em estilo de etiqueta, linhas de variáveis de ambiente e caixas de seleção de plataforma com detecção automática.
• Valores sensíveis (tokens, chaves de API) ficam mascarados no formulário e são armazenados no cofre de variáveis de ambiente.

Sincronização multiplataforma #

Uma única entrada de servidor MCP é sincronizada com Claude Code, Codex, Gemini e OpenCode com um clique. Endpoints REST:

# List platforms SynaBun can sync to
GET http://localhost:3344/api/mcp/platforms

# Sync the selected server to every targeted platform
POST http://localhost:3344/api/mcp/sync
{ "serverId": "...", "platforms": ["claude-code", "codex", "gemini", "opencode"] }

# Remove the sync (per platform)
DELETE http://localhost:3344/api/mcp/sync?serverId=...&platform=codex

Cofre de variáveis de ambiente e registro automático em perfis #

• Os segredos são armazenados uma única vez no cofre de variáveis de ambiente centralizado e referenciados pelo nome em todos os servidores MCP.
• Variáveis sensíveis ficam mascaradas no formulário de adição e nas telas de ajustes.
• Servidores recém-adicionados são registrados automaticamente nos perfis, para que você possa ativá-los e desativá-los por grupo com a ferramenta MCP profile.
• Instalação simplificada a partir do GitHub — cole a URL de um repositório e o SynaBun clona, faz o build e registra o servidor.
• A estrutura da pasta data/mcp/ dá aos servidores instalados pelo usuário uma organização previsível.

Guia de estilo #

Cada projeto pode ter um Guia de estilo: cores em claro e escuro com paletas de 11 tons, tipografia, espaçamento, forma, movimento, ícones, arquivos de logo, direção de imagens, especificações de componentes e regras. Ele fica em um só lugar e é entregue a todo agente que trabalha no projeto. Ao salvar, são gravados os arquivos que os agentes e as ferramentas de build já leem:

O painel #

• Abra o Guia de estilo no menu Skills da Neural Interface e selecione um projeto registrado.
• O painel edita todas as quatorze seções, com salvamento automático, prévias de componentes em claro e escuro, diffs de importação, exportações, histórico e propostas dos agentes.
• Oito presets — SynaBun Default, Minimal SaaS, Dark Developer, Editorial, Playful, Enterprise, Fintech Precision e Warm Organic.
• Importações — de um DESIGN.md, de um arquivo de design tokens do W3C, de propriedades personalizadas de CSS (incluindo um @theme do Tailwind v4 ou variáveis no estilo shadcn), de um tema do Tailwind em JSON, do próprio código do projeto ou da coleção de DESIGN.md da comunidade. A prévia devolve o guia resultante e um diff, sem salvar nada.
• Histórico — toda revisão salva é mantida, da mais recente para a mais antiga, até o limite de 30. Restaurar uma revisão traz o design dela de volta como uma nova revisão.

A ferramenta style_guide #

Passe projectPath — a raiz do projeto ou qualquer caminho dentro dele. O padrão é o diretório de trabalho do servidor, que normalmente não é o projeto de quem faz a chamada.

// The compact brand block
style_guide({ action: "summary", projectPath: "/Users/me/my-project" })

// Tokens as CSS custom properties
style_guide({ action: "tokens", projectPath: "/Users/me/my-project", format: "css" })

// Check contrast for two colors or aliases
style_guide({ action: "contrast", projectPath: "/Users/me/my-project", fg: "{semantic.text}", bg: "{primary.500}" })

// Propose a change for the user to review
style_guide({
  action: "propose",
  projectPath: "/Users/me/my-project",
  changes: { colors: { status: { danger: "#dc2626" } } },
  reason: "The current danger red fails AA on the dark surface"
})

O que os agentes recebem #

• Os workers que o Assistente despacha para trabalhos de código, engenharia complexa, design, imagem e vídeo encontram um bloco STYLE GUIDE no briefing: de 300 a 500 tokens para um guia preenchido, nunca mais de 600.
• As Regras do SynaBun mandam toda ferramenta conectada ler o DESIGN.md antes de qualquer trabalho de UI, design, texto ou criação, e o Estúdio de automações pode anexar o guia do projeto selecionado ao prompt de um template.
• Os agentes nunca escrevem o guia. A única escrita deles é uma proposta — um JSON merge patch e um motivo — e nada muda até você aceitá-la no painel. Pode haver no máximo 200 propostas pendentes.
• Por padrão, o contraste é verificado segundo a WCAG 2.2 AA: 4,5:1 para texto, 3:1 para texto grande e UI.
• A ferramenta style_guide fica no grupo styleguide, que faz parte dos presets de perfil core, standard, codex-browser, browser e full.

Hooks do Claude Code #

O SynaBun traz 10 scripts de hook para o Claude Code, registrados como 11 handlers em 9 eventos do ciclo de vida. Eles recuperam o contexto no início da sessão, passam um briefing de memória aos subagentes antes de eles serem lançados e garantem a captura de memórias depois que o trabalho termina.

Como instalar os hooks #

Instale os hooks pela Neural Interface: Ajustes → Projetos → Workspaces → Ativar para um único projeto, ou Ajustes → Automações → Comportamento das automações → Hooks para todos os projetos. Isso grava a configuração dos hooks no .claude/settings.json correspondente.

Hook SessionStart #

Roda quando o Claude Code inicia uma nova sessão. Injeta a árvore completa de categorias, as regras de detecção de projeto, 5 diretivas obrigatórias (recuperação no início da sessão, memorização automática, recuperação antes de decisões, armazenamento automático na compactação, aprendizado sobre o usuário) e o contexto de recuperação pós-compactação. Acrescenta uma linha quando o diretório de trabalho tem um DESIGN.md. Tudo isso entra no início da sessão, antes de o usuário digitar qualquer coisa.

Hook UserPromptSubmit #

Intercepta cada mensagem do usuário antes que ela chegue ao Claude. Analisa o prompt com um sistema de gatilhos em vários níveis — edições não armazenadas de uma tarefa anterior, frases de recuperação de conversas, os níveis de recuperação must / should / consider, detecção de idiomas diferentes do inglês e um lembrete discreto de aprendizado sobre o usuário depois de um número configurável de interações — e injeta lembretes adequados ao contexto. A injeção automática de memórias fica limitada a 3 memórias e 600 tokens. Com as decisões por IA ativadas, uma urgência avaliada pela IA substitui os níveis baseados em regex.

Hook PreCompact #

Dispara antes da compactação do contexto. Captura o caminho da transcrição da sessão e os metadados e define uma flag pending-compact que o hook Stop vai fazer valer — garantindo que a sessão compactada seja indexada na memória antes que o Claude possa continuar.

Hook Stop #

Roda depois que o Claude conclui uma resposta. Impõe duas exigências: (1) se existe uma flag pending-compact, bloqueia o Claude até a sessão ser indexada com remember na categoria "conversations", e (2) se houve edições ainda não armazenadas, bloqueia até o trabalho ser memorizado. No máximo 3 tentativas por flag, para evitar loops infinitos. O hook Stop também conduz as iterações do loop autônomo.

Hook PostToolUse (post-remember) #

Corresponde a Edit, Write, NotebookEdit e às ferramentas remember, reflect e recall do SynaBun. Acompanha a contagem de edições e limpa as flags de bloqueio quando memórias são armazenadas — a categoria conversations limpa a flag de compactação, e as outras categorias zeram o contador de memorização. Um recall explícito bem-sucedido registra um recibo que o controle de despacho de subagentes lê.

Hook PreToolUse (pre-websearch) #

Intercepta chamadas das ferramentas WebSearch e WebFetch. Verifica se há uma sessão de navegador do SynaBun ativa ou se o loop atual usa o navegador — se for o caso, bloqueia a ferramenta e injeta uma mensagem dizendo ao Claude para usar as ferramentas de navegador do SynaBun. Se a Neural Interface estiver inacessível, deixa a chamada passar sem erro.

Hooks PreToolUse e PostToolBatch (pre-task) #

Recuperação antes dos subagentes. Antes de escrever prompts para Task ou Agent, o orquestrador precisa concluir um recall focado na tarefa e incorporar ao prompt os caminhos exatos, as correções anteriores e as restrições. Como garantia extra, o primeiro disparo sem briefing aciona um pedido de recuperação de até 5 memórias e 1.200 tokens; se houver memória relevante, esse primeiro lote é bloqueado uma vez e o briefing é devolvido, e os disparos paralelos compartilham o resultado. Em seguida, o PostToolBatch libera os disparos negados, e a nova tentativa é imediata.

Hook PostToolUse (post-plan) #

Dispara quando o Claude entra no modo de planejamento ou sai dele. Quando um plano é aprovado com ExitPlanMode, o hook armazena o plano final como uma memória na categoria plans, registrando decisões de arquitetura e estratégias de implementação sem intervenção manual.

Hooks SubagentStart e SubagentStop #

O subagent-start.mjs adiciona o contexto de memória de rotina a um worker quando o host fornece o texto da tarefa, usando o mesmo limite de 3 memórias / 600 tokens. O subagent-stop.mjs lembra o worker de salvar descobertas úteis antes de terminar; ele só roda quando a flag subagentRemember está ativada.

Integração com o Claude Code #

O SynaBun traz um único comando de barra — /synabun — que serve de porta de entrada para todos os recursos baseados em memória. Ele roda tanto no Claude Code quanto no Codex, e o painel lateral do OpenCode tem um botão de ação rápida dedicado para /synabun changelog. Digite o comando na sua CLI e um menu interativo aparece:

/synabun — central de comandos #

O comando /synabun mostra um menu interativo paginado — três opções e um espaço de navegação por página. Passar um argumento leva direto a uma opção e pula o menu.

/synabun
/synabun audit auth module
/synabun search how did we handle token refresh

Prompts interativos por runtime #

O menu é um cartão de opções interativo, não texto puro. A skill usa a ferramenta de perguntas de cada runtime:

• Claude Code — AskUserQuestion
• OpenCode — a ferramenta nativa question
• Codex — request_user_input
• Outros runtimes — uma pergunta de múltipla escolha concisa, em texto puro, quando não existe ferramenta interativa

Regras do SynaBun #

Sua ferramenta de IA precisa de um conjunto curto de regras para usar bem a memória: recuperar antes de qualquer trabalho de peso, memorizar depois de cada tarefa, chamar as ferramentas do SynaBun uma de cada vez. O SynaBun instala essas regras quando você conecta uma ferramenta e as mantém atualizadas. Você não precisa colar nada.

• Conectar uma ferramenta instala as regras dela, e desconectar as remove. Se você conectou uma ferramenta antes de o instalador existir, o SynaBun pergunta uma vez e não instala nada até você responder.
• As atualizações são automáticas para uma cópia que você não editou. Edite a cópia e o SynaBun para de atualizá-la; apague-a e o SynaBun não a coloca de volta.
• Suas edições estão seguras — o SynaBun nunca remove por conta própria regras que você editou. Desconectar uma ferramenta mantém a cópia editada no lugar, e Remover nos Ajustes pergunta antes e guarda um backup.
• Todo arquivo ganha um backup antes de o SynaBun alterá-lo, em ~/.synabun/backups/rulesets/.
• Cópias antigas coladas no CLAUDE.md, AGENTS.md ou GEMINI.md de um projeto aparecem listadas nos Ajustes. O SynaBun só remove uma delas quando você pede, e só se for uma cópia não editada.
• Codex — quando uma pasta home do Codex contém um AGENTS.override.md, o Codex lê esse arquivo em vez do AGENTS.md. Nesse caso, a configuração mostra as regras como Sobreposto.

Ajustes → Conexões de IA → Regras do SynaBun mostra o estado por ferramenta, com as ações Instalar, Atualizar, Substituir, Remover, Ver e Copiar.

Suporte a vários clientes #

O SynaBun é um único servidor MCP para todas as ferramentas de IA da sua máquina. Claude Code, Codex, OpenCode e clientes MCP genéricos usam as mesmas ferramentas e a mesma memória, então uma decisão guardada em uma ferramenta é recuperada em outra.

Transportes e contexto do chamador #

• stdio — o cliente inicia o mcp-server/run.mjs. O contexto do projeto vem de SYNABUN_PROJECT e do ambiente do terminal ou da sessão.
• HTTP — a Neural Interface monta o servidor MCP em http://localhost:3344/mcp; um caminho com chave, /mcp/<key>, é usado para acesso por túnel. O contexto do chamador pode ser informado com os headers X-Synabun-Project, X-Synabun-Memory-Session e X-Synabun-Context-Generation.
• Um cliente que anuncia uma única raiz de sistema de arquivos padrão do MCP fornece o contexto do projeto automaticamente. Argumentos project explícitos nas ferramentas têm precedência, e várias raízes exigem um projeto explícito, sem adivinhação.

Perfis de ferramentas por runtime #

Cada runtime MCP tem seu próprio perfil de ferramentas ativo, então trocar de perfil em um painel lateral, loop ou agendamento nunca altera outro. O Gerenciamento de MCP sincroniza uma única entrada de servidor entre Claude Code, Codex, Gemini e OpenCode, e as Regras do SynaBun mantêm as instruções de cada ferramenta atualizadas.

Ferramentas de quadro branco #

O SynaBun inclui um canvas visual compartilhado que a sua IA pode ver, usar para desenhar e aproveitar em diagramas de arquitetura, planejamento e esboços colaborativos. 5 ferramentas MCP controlam o quadro branco.

Tipos de elemento #

• text — Caixas de texto com tamanho de fonte e cor configuráveis
• list — Listas com marcadores ou numeradas
• shape — Retângulos, pílulas, círculos, triângulos e círculos desenhados à mão
• arrow — Conectores com 2 ou mais pontos cujas pontas podem se prender a outros elementos (startAnchor, endAnchor)
• pen — Traços de desenho livre com espessura configurável
• image — Imagens servidas pela Neural Interface, incorporadas ao canvas
• section — Blocos de wireframe (navbar, hero, sidebar, content, footer, card, form, image-placeholder, button, text-block, grid, modal)

// Add two shapes side by side with auto-layout
whiteboard_add({
  elements: [
    { type: "text", content: "Auth Flow", fontSize: 24 },
    { type: "shape", id: "login", shape: "rect" },
    { type: "shape", id: "token", shape: "pill" }
  ],
  layout: "row"
})

// Connect them: anchored ends snap to the target's edge
whiteboard_add({
  elements: [
    { type: "arrow", points: [[30, 50], [70, 50]], startAnchor: "login", endAnchor: "token" }
  ],
  coordMode: "pct"
})

Ferramentas de cartões #

Os cartões de memória são painéis flutuantes na Neural Interface que exibem o conteúdo das memórias. A sua IA pode abrir, organizar, fixar e capturar cartões para montar workspaces visuais de pesquisa, investigação ou material de referência.

// Open a memory as a compact card
card_open({
  memoryId: "8f7cab3b-644e-4cea-8662-de0ca695bdf2",
  left: 50,
  top: 10,
  coordMode: "pct",
  compact: true
})

Ferramentas do Discord #

8 ferramentas MCP para gerenciar um servidor do Discord por completo. Exige um DISCORD_BOT_TOKEN em ~/.synabun/.env. Defina DISCORD_GUILD_ID para ter um servidor padrão.

// Send a message
discord_message({
  action: "send",
  channel: "general",
  content: "Deployment complete! v2.1.0 is live."
})

// Create a role
discord_role({
  action: "create",
  name: "Beta Tester",
  color: "#3b82f6",
  mentionable: true
})

Loops autônomos #

A ferramenta loop permite iteração autônoma — sua IA pode executar tarefas longas com até 50 iterações (padrão 10) e um limite de tempo configurável de até 480 minutos (padrão 60). O progresso fica registrado em um diário que sobrevive às compactações de contexto.

// Start a monitoring loop
loop({
  action: "start",
  task: "Check the deploy status every iteration and report any failures",
  iterations: 20,
  max_minutes: 120
})

Ferramenta Git #

A ferramenta MCP git oferece operações de controle de versão direto pelo protocolo MCP — status, diff, commit, log e gerenciamento de branches.

// Check repo status
git({
  action: "status",
  path: "/Users/me/my-project"
})

// Commit specific files
git({
  action: "commit",
  path: "/Users/me/my-project",
  message: "Fix auth middleware race condition",
  files: ["src/middleware/auth.ts"]
})

Automação de navegador #

O SynaBun integra o Playwright para dar ao seu assistente de IA um navegador próprio, com sessões persistentes. Sua IA pode navegar em sites, interagir com elementos, preencher formulários, tirar screenshots, ler o console, executar JavaScript e extrair dados estruturados — tudo com comandos em linguagem natural via MCP.

Como funciona #

As sessões rodam no navegador configurado em Ajustes → Navegador: um perfil de navegador gerenciado pelo SynaBun, o seu Chrome de verdade ou um perfil do MoreLogin. Cada sessão mantém seus próprios cookies, estado de login e local storage entre as conversas com a IA — sua IA continua logada nas plataformas sem precisar se autenticar de novo a cada vez. Cada chamador trabalha na própria aba: verificações de posse de aba impedem que um agente aja na aba de outro chamador.

Ferramentas de navegador (21) #

• browser_navigate — Abre qualquer URL no navegador da IA
• browser_click — Clica em elementos por ref de snapshot, seletor CSS, conteúdo de texto, role ARIA ou data-testid. Um textHint permite que um localizador frágil se recupere quando o site mexe no DOM.
• browser_fill — Limpa e preenche campos de input e textareas
• browser_type — Digita texto caractere por caractere (para elementos contenteditable, como os editores de post das redes sociais)
• browser_snapshot — Observa a estrutura da página e as refs dos elementos como texto (alternativa aos screenshots que economiza tokens). Modos: ai (padrão; saída compacta com refs de elemento [ref=eN] para passar a click, fill e type), interactive, landmarks e full. Delimite o escopo com selector e depth, e use IDs de snapshot e diffs para ver só o que mudou.
• browser_screenshot — Captura a página como imagem: por padrão, o viewport em JPEG, reduzido para 1.024 px de largura. width / height emulam um breakpoint só para aquela captura, fullPage captura a página inteira, e save ou path grava um arquivo em resolução total.
• browser_console NOVO — Lê as mensagens do console e os erros de página não capturados da aba atual (os últimos 200), inclusive em páginas localhost. Filtre com level, since e limit; clear esvazia o buffer depois da leitura.
• browser_content — Extrai o conteúdo da página como texto (padrão) ou markdown, para uma saída otimizada para LLMs, com títulos e links preservados. selector limita a extração à subárvore de um elemento.
• browser_evaluate — Executa JavaScript arbitrário no contexto da página
• browser_hover — Passa o cursor sobre elementos da página
• browser_select — Seleciona opções em dropdowns
• browser_press — Pressiona teclas e atalhos de teclado
• browser_wait — Espera elementos aparecerem, estados de carregamento da página ou timeouts
• browser_scroll — Rola a página ou elementos específicos
• browser_go_back — Volta para a página anterior
• browser_go_forward — Avança para a próxima página
• browser_reload — Recarrega a página atual
• browser_upload — Envia arquivos por inputs de formulário
• browser_session — Cria, lista ou fecha sessões de navegador. As sessões são isoladas entre a CLI e os painéis laterais/loops da Neural Interface, para que os agentes não disputem o mesmo navegador.
• browser_cheatsheet — Mostra uma cola de seletores com seletores estáveis por platform (twitter, facebook, tiktok, whatsapp, instagram, linkedin, bluesky), com filtro opcional por action.
• browser_batch NOVO — Executa até 10 passos de navegador já conhecidos, em sequência, em uma única aba e retorna um snapshot final. Faz parte do Browser V2.

Browser V2 #

O Browser V2 é o caminho de execução mais rápido. Já vem ativado por padrão; você não precisa de nenhuma variável de opt-in.

• browser_batch — aceita de 1 a 10 passos {tool, args, observe?} para uma sessão e uma aba. Valida todos os passos antes de agir, executa em ordem as ferramentas protegidas que já existem, para na primeira falha e retorna os resultados concluídos até ali. O snapshot final é full (padrão), diff ou none. Os passos não podem alterar o roteamento nem executar JavaScript arbitrário.
• IDs de snapshot e diffs — browser_snapshot retorna um ID de snapshot compacto e aceita baselineId. Um diff precisa de um snapshot compatível, já entregue, do mesmo chamador e da mesma página; force: true pede uma visão completa.
• Snapshots automáticos com limite — a observação depois de um clique tem por padrão 6.000 caracteres; depois de navegação e rolagem, 12.000; e snapshots explícitos, 30.000. O corte sempre termina em linhas completas.
• Extração paginada — as ferramentas browser_extract_* aceitam fields e maxChars opcionais, eliminam itens duplicados pela identidade e informam por que pararam.
• Ritmo das ações em redes sociais — as ações de engajamento que alteram dados mantêm um intervalo aleatório de 30 a 90 segundos e são executadas em sequência dentro de cada sessão do navegador.
• Cancelamento — cancelar uma chamada de ferramenta interrompe as requisições pendentes e impede os passos seguintes do lote. Nunca repita um lote inteiro nem um clique incerto; confira antes o estado atual.
• Rollback — defina SYNABUN_BROWSER_V2=0 tanto para a Neural Interface quanto para os processos MCP dela e reinicie todos.

// Selectors and sequence are already known: one call, one final diff
browser_batch({
  steps: [
    { tool: "browser_fill", args: { selector: "#email", value: "[email protected]" } },
    { tool: "browser_click", args: { selector: "#save" } }
  ],
  snapshot: "diff"
})

Capturas de tela e console para QA visual #

// Full-page capture at a mobile breakpoint, saved as a file
browser_screenshot({ width: 375, fullPage: true, save: true })

// Only the errors since the last read
browser_console({ level: "error", clear: true })

Por padrão, uma captura de tela salva vai para ~/.synabun/data/media/screenshots/<date>/. Um path explícito precisa ser absoluto, terminar em .png, .jpg ou .jpeg e ficar dentro de um projeto registrado ou da pasta de capturas de tela.

Assistência do Jev (consultiva) #

Com as decisões de IA ativadas, as ferramentas de navegador acrescentam à saída normal uma leitura tipada da página. É só texto e nunca faz parte do fluxo de controle: com elas desativadas, cada ferramenta responde exatamente como antes.

• browser_navigate aceita um intent opcional. Uma linha pode vir depois do snapshot, como Jev assessment: authentication_required (94%) — pause for human sign-in. Um bloqueio significa parar e passar o controle para o humano; um diálogo de consentimento nunca é dispensado automaticamente.
• browser_snapshot aceita um intent opcional e pode acrescentar uma linha Jev target: indicando a melhor ref daquele mesmo snapshot. Nunca clica.
• Um clique, preenchimento, digitação, hover, seleção ou upload que falha ou é ambíguo retorna as dicas de sempre, reordenadas quando há uma correspondência confiável.
• Dentro de browser_batch não há assistência; um lote que navegou recebe uma única avaliação da página final depois de terminar.

MoreLogin #

O MoreLogin é um navegador antidetecção para múltiplas contas. O SynaBun pode gerenciar os perfis dele com a ferramenta morelogin e usar um deles como navegador padrão da IA, de modo que toda ferramenta browser_* controle esse perfil.

// Find a profile, then make it the default AI browser
morelogin({ action: "list" })
morelogin({ action: "use_default", envId: "<env-id>" })

MoreLogin como navegador padrão #

• Enquanto Ajustes → Navegador indicar o MoreLogin como padrão, todo loop, agendamento, execução despachada, recuperação e sessão interativa controla o perfil padrão do MoreLogin.
• Se o MoreLogin estiver inacessível, a execução falha e o log traz o motivo. Nada recorre ao Chrome.
• As ferramentas de página recusam uma sessão que não atende o navegador padrão; assim, um agente nunca age em uma página no navegador errado.
• Páginas em localhost abrem no perfil do MoreLogin como qualquer outra. A Port scan protection de cada perfil do MoreLogin decide quais portas locais carregam: liste as portas do seu servidor de desenvolvimento em Edit profile → Advanced settings → Port scan protection e reinicie o perfil. Uma navegação bloqueada falha com uma mensagem que informa a porta.

Automação de redes sociais #

Além das ferramentas gerais de navegador, o SynaBun traz 25 ferramentas de plataforma para Twitter/X, Facebook, TikTok, WhatsApp, Instagram e LinkedIn: 22 ferramentas de extração que convertem o conteúdo em JSON estruturado, duas sondas somente leitura do estado de composição e a ferramenta de diretório fb_groups. Elas são mais rápidas e confiáveis do que usar browser_snapshot, porque fazem o parsing específico de cada plataforma. As ferramentas de plataforma sempre rodam no navegador padrão.

Twitter / X #

• browser_extract_tweets — Analisa todos os tweets visíveis: autor, handle, texto, data e hora, URL, respostas, reposts, curtidas e número de visualizações. Funciona em timelines, resultados de busca e páginas de perfil.
• browser_x_compose_state NOVO — Inspeciona a área de composição em uma única chamada somente leitura: texto do editor, contagem de caracteres e indicador de limite excedido, o tipo do card de citação (quote, link ou none), o botão de envio com seu seletor e uma recommendedAction (submit, type, open-composer, fix-quote-url, trim-text ou unknown). Confira antes de publicar: só é seguro postar uma citação quando o tipo do card é quote.

TikTok #

• browser_extract_tiktok_videos — Extrai os vídeos do feed com handle, URL do vídeo, legenda, curtidas, comentários, salvamentos, compartilhamentos e informações da música
• browser_extract_tiktok_search — Analisa os resultados de busca com URLs dos vídeos, handles, legendas e número de visualizações
• browser_extract_tiktok_profile — Extrai as informações do perfil: nome, handle, bio, seguidores, seguindo e curtidas, além da grade de vídeos com URLs e visualizações
• browser_extract_tiktok_studio — Analisa a lista de conteúdo do TikTok Studio: título, URL, data, configuração de privacidade e estatísticas de desempenho

Facebook #

• browser_extract_fb_posts — Analisa os posts visíveis: autor, URL do autor, texto, data e hora, URL do post e reações. Funciona em feeds de notícias, feeds de grupos e Páginas de empresas.
• browser_fb_composer_state NOVO — Inspeciona a área de publicação em uma única chamada somente leitura: o diálogo de publicação aberto, os editores de posts da página (caixas de comentário são sinalizadas e nunca tratadas como editores de posts), o botão de envio, o estado do envio (visible-post, pending-approval, posting-failed, composer-open ou unknown), uma recommendedAction e boostRisk, que sinaliza controles pagos de Boost / Promote que nunca devem ser clicados. Tolera interfaces em PT, EN, TR, FR, ES e DE.
• browser_extract_fb_groups NOVO — Extrai todos os grupos de que você participa na página de grupos do Facebook, em um índice ordenado por região. Rola a lista virtualizada automaticamente e elimina duplicatas por URL em uma única chamada; cada grupo traz nome, URL, número de membros, região, idioma e moeda.
• fb_groups NOVO — Um diretório de grupos estruturado, com base em SQLite, e um checklist de publicação por grupo. Veja as ações abaixo.

WhatsApp #

• browser_extract_wa_chats — Analisa a barra lateral do WhatsApp Web: nome da conversa, última mensagem, horário, número de não lidas e status de silenciada/fixada
• browser_extract_wa_messages — Extrai as mensagens de uma conversa aberta: remetente, horário, data, direção (in/out) e texto

Essas ferramentas leem o WhatsApp Web no navegador. Para conversar com o Assistente pelo celular, veja Conexão com o WhatsApp.

Instagram #

• browser_extract_ig_feed — Analisa os posts do feed: nome de usuário, legenda, curtidas, comentários e data e hora
• browser_extract_ig_profile — Extrai os dados do perfil: bio, números de seguidores/seguindo, grade de posts e destaques dos stories
• browser_extract_ig_post — Extrai um post com todos os comentários (com paginação)
• browser_extract_ig_reels — Extrai reels com métricas de engajamento e nome/URL do áudio
• browser_extract_ig_search — Analisa os resultados do Explorar e da busca por hashtag

LinkedIn #

• browser_extract_li_feed — Extrai posts do feed com autor, título profissional, texto, reações, comentários e links de artigos
• browser_extract_li_profile — Extrai dados do perfil: título profissional, localização, conexões, experiência, formação e competências
• browser_extract_li_post — Extrai um post com todos os comentários (com suporte a paginação)
• browser_extract_li_notifications — Extrai notificações com texto, data e hora e status de leitura
• browser_extract_li_messages — Extrai as conversas e as mensagens da conversa ativa
• browser_extract_li_search_people — Extrai resultados da busca de pessoas com título do perfil e localização
• browser_extract_li_network — Extrai conexões da rede e sugestões de conexão
• browser_extract_li_jobs — Extrai vagas dos resultados de busca e das recomendações da página inicial (cargo, empresa, localização, salário, data de publicação)

Outras plataformas #

BlueSky e YouTube têm grupos de ferramentas dedicados — veja Ferramentas do BlueSky e Ferramentas do YouTube. As ferramentas gerais de automação de navegador interagem com qualquer plataforma web — Reddit, Pinterest ou qualquer site que abra no navegador. Use browser_navigate, browser_click, browser_type e browser_content para automatizar interações em qualquer site.

Ferramentas do BlueSky #

O SynaBun traz 15 ferramentas do BlueSky que chamam a API do AT Protocol direto da aba do bsky.app em que você está logado, em vez de fazer scraping da página. Faça login no bsky.app uma vez no navegador do SynaBun: as ferramentas reaproveitam essa sessão e renovam sozinhas um token de acesso expirado.

// Confirm the session, search, publish, and engage
bluesky_session({})
bluesky_search_posts({ q: "mcp server", sort: "latest", maxItems: 20 })
bluesky_post({ text: "Notes on wiring persistent memory into a coding agent: https://synabun.ai/docs" })
bluesky_action({ action: "follow", target: "alice.bsky.social" })

• As ferramentas de leitura retornam JSON compacto e um cursor; passe maxItems para paginar automaticamente.
• Cada chamada inteira tem um único prazo de 48 segundos. Uma requisição que não responde a tempo é informada como possivelmente concluída e nunca é repetida — confira antes de refazer uma escrita.
• Ative o grupo com o preset de perfil bluesky (git, image, browser e as ferramentas do BlueSky); ele também faz parte de browser e full.

Ferramentas do YouTube #

O SynaBun traz 11 ferramentas do YouTube para um pipeline completo de trailers de jogos: descobrir, baixar, publicar e analisar. A automação de navegador opera o YouTube Studio diretamente pela sua sessão do Google já conectada, o que evita o bloqueio em modo privado que a Data API impõe a projetos não auditados e a pequena cota diária de uploads. A descoberta e as métricas ficam a cargo da API da Neural Interface.

Descoberta e download (2) #

• youtube_source — Encontra trailers de jogos como candidatos à publicação via IGDB (metadados, app id da Steam, ids de trailers do YouTube) e pela Steam Storefront (URLs diretas de MP4). Aceita filtros de gênero, plataforma e hype, além de períodos de busca retroativa.
• youtube_download — Baixa um trailer para o disco. Prefere os MP4s das publicadoras na Steam, por HTTPS direto; recorre ao yt-dlp para trailers que só existem no YouTube.

Publicação no Studio (7) #

• youtube_navigate — Abre uma seção do YouTube Studio (dashboard, content, analytics, playlists, comments, subtitles, copyright, earn, customization). Identifica automaticamente o canal conectado.
• youtube_upload altera dados — Envia um vídeo local pelo diálogo Criar → Enviar vídeos: título, descrição, tags, conteúdo para crianças, depois Detalhes → Elementos do vídeo → Verificações → Visibilidade.
• youtube_metadata altera dados — Edita título, descrição, tags, categoria e a marcação de conteúdo para crianças de um vídeo existente.
• youtube_thumbnail altera dados — Envia uma miniatura personalizada para um vídeo.
• youtube_schedule altera dados — Define um horário futuro de publicação ou a visibilidade imediata. Aceita ISO ou YYYY-MM-DD HH:MM.
• youtube_playlist altera dados — Cria playlists, adiciona vídeos ou lista as playlists existentes.
• youtube_endscreen altera dados — Aplica um modelo de tela final a um vídeo.

Métricas (2) #

• youtube_analytics — Lê o YouTube Analytics pela YouTube Analytics API (OAuth), sem alterar dados: visualizações, tempo de exibição, curtidas e inscritos ganhos, do canal inteiro ou por vídeo.
• youtube_channel — Retorna informações do canal ou lista os uploads recentes para evitar duplicatas.

Ferramentas do Leonardo.ai #

O SynaBun inclui 5 ferramentas MCP do Leonardo.ai baseadas em navegador para gerar imagens e vídeos com IA. Elas automatizam a interface web do Leonardo.ai diretamente via Playwright — sem precisar de chave de API. Use as ferramentas genéricas de navegador para configurar as opções (modelo, estilo, dimensões, controles de movimento) e depois as ferramentas do Leonardo para gerar e obter os resultados.

Ferramentas de navegador (5) #

• leonardo_browser_navigate — Navega até páginas específicas do Leonardo.ai (início, biblioteca, editor de imagens, vídeo, upscaler, blueprints, canvas em tempo real, modelos).
• leonardo_browser_generate — Preenche o prompt e clica em Generate. Configure antes todas as opções da interface (modelo, estilo, dimensões, controles de movimento) com as ferramentas genéricas de navegador (browser_click, browser_fill, browser_snapshot).
• leonardo_browser_library — Navega ou busca na biblioteca de gerações pela interface web.
• leonardo_browser_download — Captura a página atual do Leonardo.ai como screenshot para ver os resultados da geração.
• leonardo_browser_reference — Envia imagens de referência e as anexa à próxima geração. Aceita filePaths e um type: image_ref, style_ref, content_ref, character_ref ou image_to_image para imagens; start_frame ou end_frame para vídeo.

Ferramentas do Google Search Console #

O SynaBun vem com 30 ferramentas MCP do Google Search Console baseadas em navegador, que operam a interface web do GSC diretamente pelo Playwright — sem chave de API, sem cota, sem JSON de conta de serviço. Sua IA usa a sua própria sessão autenticada do Google no navegador gerenciado pelo SynaBun. Os seletores toleram qualquer idioma (caminhos de URL, ligaduras de material-icon e roles aria em vez de textos traduzidos da interface), então as ferramentas funcionam seja qual for o idioma de exibição do GSC.

Navegação e propriedade (2) #

• gsc_navigate — Abre qualquer seção do GSC (overview, performance_search/discover/news, inspect, pages, videos, sitemaps, removals, cwv_mobile/desktop, https, security, manual_actions, links, achievements, settings, crawl_stats, users, change_address, associations, disavow, shopping, merchant, além de 17 relatórios de melhorias). Mantém a propriedade ativa.
• gsc_property — Lista, seleciona, lê ou adiciona uma propriedade (domínio ou prefixo de URL).

Inspeção de URL (4) #

• gsc_inspect_url — Inspeciona uma URL, aguarda até 30s pelo painel de resultado e retorna JSON estruturado (indexingState, canonicals, lastCrawl, sitemap, robots, enhancements etc.).
• gsc_inspect_test_live — Clica em "Testar URL publicada" e aguarda até 90s pelos resultados do teste da URL publicada (o timeout do próprio Google).
• gsc_inspect_request_indexing altera dados — Envia a URL para a fila de indexação do Google.
• gsc_inspect_view_crawled — Abre o painel Ver página rastreada — alterna entre as abas html / screenshot / http_response / more_info.

Desempenho (3) #

• gsc_performance_query — Consulta um relatório de desempenho — searchType, dateRange (predefinido ou personalizado), dimension (query/page/country/device/searchAppearance/date), chips de filtro, alternância de comparação. Rola a grade automaticamente até limit linhas e retorna os totais + a tabela em JSON.
• gsc_performance_export — Aciona o menu Exportar do relatório (CSV / Excel / Google Sheets).
• gsc_performance_chart_screenshot — Captura a tela do gráfico de desempenho atual.

Indexação e cobertura (6) #

• gsc_pages_report — Lê o relatório Páginas (Cobertura) — totais, grupos por motivo e, se quiser, detalhamento até exemplos de URL.
• gsc_pages_validate_fix altera dados — Inicia uma validação de correção (Validate Fix) para o grupo de motivo escolhido.
• gsc_videos_report — Lê o relatório de indexação de vídeos (mesmo formato de gsc_pages_report).
• gsc_sitemap — Lista, envia, exclui ou mostra erros de sitemaps.
• gsc_removals — Lista ou cria solicitações de remoção de URL (temporária de 6 meses, conteúdo desatualizado, SafeSearch).
• gsc_removals_cancel altera dados — Cancela uma remoção temporária pendente.

Experiência e problemas (5) #

• gsc_cwv_report — Lê o relatório Core Web Vitals (mobile / desktop): contagem de URLs ruins / que precisam melhorar / boas e grupos por problema.
• gsc_https_report — Lê a cobertura de HTTPS e os motivos das URLs sem HTTPS.
• gsc_security_issues — Lê os problemas de segurança; opcionalmente, solicita uma revisão.
• gsc_manual_actions — Lê as ações manuais; opcionalmente, envia um pedido de reconsideração com texto personalizado.
• gsc_enhancements — Lê qualquer relatório de melhorias de dados estruturados (breadcrumbs, faq, sitelinks, videos, products, recipes, review, events, jobposting, speakable, qa, logos, sitenames, dataset, practice, math, merchant).

Links (2) #

• gsc_links_report — Lê as páginas mais linkadas / sites que linkam / textos de link / páginas com links internos. Pagina automaticamente.
• gsc_links_export — Aciona o menu Exportar do relatório de links.

Configurações e outros (8) #

• gsc_settings — Lê a página de configurações (propriedade, verificação, usuários); faz a mudança de endereço.
• gsc_crawl_stats — Lê as estatísticas de rastreamento: totais (solicitações, bytes, tempo de resposta) e detalhamento por host / código de resposta / tipo de arquivo / tipo de Googlebot.
• gsc_users — Lista, adiciona, remove e muda a função dos usuários da propriedade.
• gsc_associations — Lista, adiciona e remove associações (Analytics, Merchant Center, Ads, Play, YouTube, Actions, Chrome Web Store).
• gsc_disavow altera dados — Baixa / envia / exclui o arquivo de rejeição de links (Disavow Links).
• gsc_shopping — Lê o relatório Shopping / Merchant Listings.
• gsc_extract_table — Extrai grades do GSC em JSON quando nenhuma ferramenta específica cobre um painel.
• gsc_screenshot — Captura a página inteira da aba ativa do GSC.

Vibe coding com o SynaBun #

Vibe coding é um estilo de desenvolvimento em que você colabora com assistentes de IA em forma de conversa — descrevendo o que quer em linguagem natural enquanto a IA escreve, refatora e depura o código. Ferramentas como Claude Code, Cursor e Windsurf popularizaram o vibe coding.

O problema: a amnésia da IA #

Sem memória persistente, toda sessão de programação com IA começa do zero. Sua IA esquece decisões de arquitetura, bugs que você já corrigiu, convenções de código que você definiu e o contexto do projeto. Você acaba explicando as mesmas coisas a cada sessão, perdendo tempo e continuidade.

Como o SynaBun resolve #

O SynaBun dá à sua IA uma memória persistente que sobrevive de uma sessão para a outra:

• Captura automática de memórias — Os hooks do Claude Code guardam automaticamente decisões importantes, correções de bugs e padrões depois de cada tarefa
• Recuperação semântica — Sua IA encontra o contexto relevante pelo significado, não por palavras-chave exatas. Pergunte "como a gente resolveu a autenticação?" e ela encontra a memória sobre "fluxo de renovação de tokens JWT"
• Detecção de desvios — Quando os arquivos de origem mudam, o SynaBun sinaliza as memórias que fazem referência a eles como possivelmente desatualizadas
• Isolamento entre projetos — Cada projeto tem seu próprio espaço de memória, com busca entre projetos quando for preciso
• Continuidade entre sessões — A indexação da memória de conversas captura o contexto da sessão nos eventos de compactação, para recuperação em sessões futuras

Além da memória: um kit completo de IA #

O SynaBun oferece 157 ferramentas MCP que transformam qualquer editor de IA compatível em um ambiente de desenvolvimento completo:

• Assistente do SynaBun — Um orquestrador com acesso à memória que encaminha cada tarefa para o modelo certo e aciona workers do Claude Code, do Codex e do OpenCode, com orçamentos e contabilidade de tokens
• Geração de imagens e vídeos com IA — Crie imagens e vídeos pelo Leonardo.ai, com combinação de estilos, controles de movimento e imagens de referência anexadas
• Automação de navegador — Teste aplicações web, extraia dados e confira páginas em qualquer breakpoint com um navegador de verdade; browser_batch executa sequências conhecidas em uma única chamada e browser_console mostra os erros da página
• Uso do computador — No macOS, o Assistente pode operar apps de desktop, limitado por proteções sempre ativas e controles de parada
• Guia de estilo — Um DESIGN.md por projeto e design tokens que todo agente lê antes de mexer na interface
• Quadro branco visual — Diagramas de arquitetura, fluxogramas e planejamento colaborativo em um canvas compartilhado
• Cartões flutuantes — Fixe notas de pesquisa, investigações e decisões em um workspace visual
• Estúdio de automações — Editor visual de templates com pastas criadas pelo usuário, padrões de execução por template e suporte a Claude Code / Codex / Gemini / OpenCode
• Loops autônomos — Tarefas de IA de longa duração com intervalos configuráveis, em qualquer uma das quatro CLIs
• Painéis laterais — Painéis laterais dedicados para Claude Code, Codex e OpenCode, com interrupção por agente, dock de atividade das ferramentas, cartões de permissão e Multi-CLI Resume
• Estúdio de Skills — Crie workflows de IA reutilizáveis e comandos personalizados; /synabun e /leonardo rodam tanto no Claude Code quanto no Codex
• Ferramentas de redes sociais — Interaja com Twitter/X, TikTok, Facebook, Instagram, LinkedIn, WhatsApp, BlueSky e YouTube

Configuração #

O SynaBun funciona sem nenhuma configuração. Cada ajuste é uma variável de ambiente opcional, definida em ~/.synabun/.env ou no ambiente que inicia o SynaBun.

Diretório de dados #

O estado mutável do usuário fica fora da aplicação, por padrão em ~/.synabun, então atualizar o código nunca mexe nos seus dados:

~/.synabun/
├── .env            # optional settings and API keys
├── mcp-data/
│   └── memory.db   # the SQLite database: memories, vectors, revisions
├── data/           # Neural Interface state: assistant config and sessions, media, audit logs
└── backups/        # verified backups and ruleset backups

Instalações que guardavam o estado dentro do checkout podem simular uma migração segura com synabun migrate-data e aplicá-la com synabun migrate-data --apply.

Armazenamento #

# Root for mutable user state (default: ~/.synabun)
# SYNABUN_DATA_HOME=/custom/synabun

# Database file path (default: ~/.synabun/mcp-data/memory.db)
# SQLITE_DB_PATH=/custom/path/to/memory.db

# Data directory for MCP runtime files (default: ~/.synabun/mcp-data/)
# MEMORY_DATA_DIR=/custom/data/dir

# SQLite runs embedded in Node.js via node:sqlite
# No port, no API key, no external process needed

Servidor e integrações #

# Neural Interface server port (default: 3344)
# NEURAL_PORT=3344

# Setup wizard completion flag
# SETUP_COMPLETE=true

# Discord bot token for the Discord tools
# DISCORD_BOT_TOKEN=your-token-here

# TypeSafe API key for AI decisions (optional)
# TYPESAFE_API_KEY=your-key-here

Chaves de recursos #

Comandos da CLI #

O comando synabun é instalado com npm install -g synabun. Em um checkout do git, npm start é o mesmo ponto de entrada, e os subcomandos vão depois de --.

Scripts do npm #

# From a checkout: setup + launch (same as the synabun command)
npm start

# Run a CLI subcommand from a checkout
npm start -- doctor

# Start only the Neural Interface server
npm run server

# Rebuild the MCP server after changing its source
npm run mcp:build

# Install the local embedding model assets
npm --prefix mcp-server run setup:embeddings

# Migrate an older Qdrant-based installation into SQLite
npm --prefix mcp-server run migrate

Atualização #

• npm — npm install -g synabun@latest mantém o estado do usuário fora do pacote. O atualizador do app cria um snapshot verificado antes de substituir o código, e uma atualização manual pelo npm faz a mesma verificação na primeira execução.
• git — rode git pull --ff-only e depois inicie o SynaBun uma vez. A primeira execução migra o estado local do checkout antes da inicialização normal; não rode git clean -fdx até que essa execução termine.
• Raízes em conflito — O SynaBun nunca mescla automaticamente duas raízes de dados com conteúdo. Rode synabun doctor e depois escolha explicitamente com synabun migrate-data --choose external ou --choose legacy. As duas cópias são preservadas antes de a escolha entrar em vigor.

Self-hosting #

O SynaBun foi feito para ser self-hosted. Todos os dados ficam no seu banco de dados SQLite e no seu sistema de arquivos local, e você não precisa de conta.

Gerenciamento do banco de dados #

O SynaBun usa SQLite pelo módulo nativo node:sqlite do Node.js (requer Node.js 22.5+). O banco de dados é um único arquivo, por padrão em ~/.synabun/mcp-data/memory.db — sem Docker, sem processo separado, sem porta de rede.

# Database location
ls ~/.synabun/mcp-data/memory.db

# Inspect database, migration, client-registration, and backup health
synabun doctor

Backup e restauração #

Use Ajustes → Memória e backups → Backups para um backup consistente com o WAL e verificado por checksum, ou baixe um pela API. Os backups agendados são arquivos ZIP imutáveis, com data e hora no nome, checksums no manifesto e um snapshot consistente do SQLite.

# Download a verified full system backup
curl -o synabun-backup.zip http://localhost:3344/api/system/backup

# Verify a backup (dry run)
synabun restore-backup --from ./synabun-backup.zip

# Restore it, with SynaBun's MCP and server processes stopped
synabun restore-backup --from ./synabun-backup.zip --apply

A retenção padrão mantém todos os backups por 24 horas, um por dia durante 30 dias e um por semana durante 12 semanas, com limite de 10 GB.

Várias instâncias #

Você pode manter bases separadas — por exemplo, uma por ambiente — iniciando cada instância com seu próprio diretório de dados e sua própria porta:

SYNABUN_DATA_HOME=/srv/synabun-a NEURAL_PORT=3344 synabun
SYNABUN_DATA_HOME=/srv/synabun-b NEURAL_PORT=3345 synabun

Deploy em produção #

Em produção, rode o SynaBun como um processo Node.js com um gerenciador de processos como o PM2. O banco de dados SQLite e os embeddings locais rodam na mesma máquina — sem serviços externos:

# Start with PM2
pm2 start npm --name synabun -- start

# Running on this machine:
# - SQLite database (~/.synabun/mcp-data/memory.db)
# - MCP server + Neural Interface (:3344)

Veja Comandos da CLI para atualizar uma instalação existente com segurança.

Como contribuir #

O SynaBun é open source sob a licença Apache 2.0. Relatos de bugs e sugestões de recursos são bem-vindos. Não aceitamos pull requests — o código é mantido exclusivamente pelos autores do SynaBun.

• Relatos de bugs: Abra uma issue no GitHub Issues com os passos para reproduzir
• Sugestões de recursos: Abra uma issue no GitHub Issues descrevendo o problema e a solução proposta
• Forks: Você pode fazer um fork do SynaBun e modificá-lo livremente sob a Apache 2.0. Forks precisam usar outro nome (política de marcas).

Veja o CONTRIBUTING.md completo para detalhes, configuração do ambiente de desenvolvimento e o guia de forks.