Firekeep

Código-fonte disponível, memória compartilhada auto-hospedada, contexto de trabalho, coordenação e evidências para Claude Code, Codex, Kiro, OpenCode e clientes MCP.

GitHub

Documentação

Firekeep

Seus agentes não deveriam trabalhar como estranhos.

Conecte Claude Code, Codex, Kiro, OpenCode e outros clientes MCP por meio de um único Keep compartilhado e auto-hospedado.

Cada problema resolvido deveria facilitar o próximo. O Firekeep preserva a experiência por trás do trabalho — conhecimento durável, estado de trabalho, procedimentos, coordenação e evidências inspecionáveis — e a coloca de volta em ação na próxima sessão, ferramenta ou máquina.

Use-o para sua própria continuidade em uma única estação de trabalho. Adicione colegas de equipe quando precisar deles sem recomeçar o contexto da equipe.

Website · Instalação · Tour do produto · Firekeep Studio · Evidências · Privacidade · Suporte

Um único Keep, em vários runtimes

flowchart LR
    A["Claude Code<br/>stores a proven fix"] --> K[("your self-hosted<br/>Keep")]
    K --> B["Codex<br/>recalls the fix + evidence"]
    K --> C["Kiro<br/>reuses the procedure"]
    K --> D["OpenCode / MCP client<br/>continues informed"]

Os agentes mantêm suas interfaces nativas e sessões de propriedade do provedor. O que é levado adiante é o contexto do Firekeep que eles registram e recuperam explicitamente pelo mesmo gateway MCP local. Isso significa que uma pessoa pode alternar de ferramenta sem perder o fio da meada, e uma equipe pode acumular contexto uma vez e levá-lo adiante.

Veja Claude Code e Codex compartilharem um único Keep →

Instale o Firekeep

O instalador configura Claude Code, Codex, Kiro e OpenCode juntos (além do Claude Desktop quando o diretório de configuração dele existir) e então pergunta onde o seu servidor Firekeep deve ficar. O fluxo completo de configuração está no guia de instalação.

curl -fsSL 'https://firekeep.ai/latest/install?src=github' | sh    # macOS / Linux
irm 'https://firekeep.ai/latest/install.ps1?src=github' | iex      # Windows PowerShell

O servidor atual tem como alvo linux/amd64 e precisa de Docker Compose v2, dois núcleos de CPU x86-64 e Git; 16 GB de RAM são recomendados para a pilha padrão. Ele vincula a 127.0.0.1 por padrão. Consulte as notas de requisitos e dimensionamento antes de escolher um host.

Experimentando o Firekeep pela primeira vez? Compartilhe o que funcionou e onde você travou →

Cobertura de runtime

Client Kit: configura Claude Code, Codex, Kiro e OpenCode juntos; o Claude Desktop é adicionado quando o diretório de configuração dele existe. Outros clientes MCP podem usar o caminho genérico.
Claude Code: MCP gerenciado, instruções e hooks de ciclo de vida. O hook de pré-ferramenta suportado pode bloquear totalmente uma ação de edição, escrita ou shell.
Codex: MCP gerenciado mais orientação AGENTS.md. O Codex não expõe hooks nativos, portanto automação de ciclo de vida e aplicação de pré-edição não estão implícitas.
Kiro CLI: um agente Firekeep nomeado com MCP, direcionamento e hooks de ciclo de vida. Na superfície validada do Kiro CLI 2.12.1, o hook de pré-edição dele é consultivo.
Firekeep Studio: executa Codex, Claude Code, Kiro CLI e Grok em um único espaço de trabalho de desktop. O adaptador direto do Grok não tem memória Keep, hooks ou briefing; o Studio relata esse limite em vez de herdar o status de outro runtime.

Consulte o guia de integração e a matriz de runtime do Studio para obter os detalhes mantidos.

Recuperação medida, com o método anexado

Na execução aceita do LongMemEval-S em 2026-08-28, o Firekeep alcançou 97,7% de Recall de Evidências@10: pelo menos uma sessão de evidências rotulada apareceu nos dez primeiros resultados para 459 de 470 perguntas pontuadas. A medição cobre recuperação, não a precisão da resposta gerada; é uma execução determinística corrigida, e não um intervalo de confiança de múltiplas execuções.

Metodologia · Dados de resultado

O problema que o Firekeep resolve

As pessoas não constroem julgamento profissional relendo cada e-mail, documento, ticket ou arquivo de código desde o início. Elas lembram o que aconteceu, por que uma decisão funcionou, como uma falha foi diagnosticada e qual procedimento se manteve na prática. Essa experiência muda a forma como elas abordam o próximo problema.

Os agentes deveriam melhorar da mesma forma. O Firekeep conecta o conhecimento, o estado de trabalho, a coordenação e as evidências por trás do trabalho para que o próximo agente possa começar com a experiência que o último conquistou.

Mapa detalhado de capacidades

Capacidade	O que significa
Memória	Os agentes lembram o que funcionou, o que falhou e o que importa entre sessões. Recuperação semântica + de grafo, pontuação de confiança, tratamento de contradições, quatro tipos de memória (referência / processual / episódica / transitória) com decaimento de recall por tipo, envelhecimento recuperável com arquivamento primeiro e recall consciente de tokens com síntese opcional de LLM. O recall é reclassificado pelos resultados registrados da sessão (memória ponderada por resultado) e pelo feedback do agente sobre o conhecimento que foi realmente utilizado (`memory_feedback`).
Piloto Automático de Conhecimento	A base de conhecimento se mantém sozinha sem decidir nada por conta própria. Quando duas memórias não confirmadas conflitam genuinamente, nenhuma é descartada silenciosamente — ambas permanecem recuperáveis, marcadas como contestadas, até um veredito humano (`/memory/contested/resolve`). Um coletor de sessões encerra sessões travadas/abandonadas para que falhas contem na pontuação de resultados. Cada fila de revisão (habilidades em rascunho, habilidades obsoletas, propostas de procedimento, pares contestados, cartas mortas de avaliação) cai em uma única caixa de entrada com um resumo semanal, e `/memory/{id}/evidence` mostra cada sinal por trás da classificação de uma memória em uma única leitura.
Frota como GPU (Night Shift)	As próprias máquinas dos agentes conectados fazem o dever de casa da base de conhecimento durante a noite, contra um modelo local, e só produzem rascunhos. O hook de fim de sessão enfileira um trabalho de destilação por sessão; as passagens noturnas do servidor enfileiram um trabalho por habilidade obsoleta (reescreva-a) e por par de memórias contestadas (proponha um veredito); `firekeep night-shift` esvazia a fila — iniciado para você no início da sessão sempre que LM Studio ou Ollama estiver ouvindo. Um humano ainda ativa cada rascunho e resolve cada par, e um livro-razão de taxa de aprovação por tipo de trabalho na aba Piloto Automático diz se o trabalho da frota vale a pena manter.
Continuidade de Equipe	As memórias carregam proveniência verificada de espaço de trabalho/membro, além de um rótulo `agent_id` de runtime não confiável e projeto. Relatórios de atividade por contribuidor e briefings de transferência sintetizados por LLM permitem que um agente continue de onde outro parou.
Continuidade de Sessão	Planos, decisões e progresso registrados pelas ferramentas de sessão sobrevivem à compactação de contexto. Sessões travadas são detectadas automaticamente no próximo início e oferecidas para retomada com um snapshot periódico do espaço de trabalho (branch git, commits recentes, estatísticas de diff) embutido na sombra.
Consciência de Ambiente	Coletores configurados de Docker, git e arquivos monitoram o estado operacional em vez de depender apenas de prompts. Reinicializações de contêineres, novos commits e mudanças de arquivos fluem para um fluxo de eventos reproduzível.
Coordenação de Agentes	Canais compartilhados, quadro de avisos, fila de tarefas estruturada, concessões de recursos com tokens de cercamento monotônicos, registro de presença e mensagens diretas. Agentes concorrentes podem atribuir trabalho, acompanhar progresso e usar concessões para evitar edições sobrepostas; clientes com hooks bloqueiam uma edição quando outro agente já detém a concessão do arquivo.
Gateway de Prever-depois-Agir	Os agentes declaram intenção antes de ações consequentes (`action_before` → `allow
Habilidades	Os agentes criam playbooks reutilizáveis de "o que fazer quando X acontecer" pela ferramenta `skill_create` (no lado do cliente, com contexto completo da sessão); um pipeline de docs→habilidades elabora mais a partir de wikis/runbooks sob revisão humana. As melhores correspondências são injetadas no briefing da próxima sessão. (A síntese automática no lado do servidor existe atrás de `SKILL_SYNTHESIS_ENABLED`, mas está desativada por padrão — a implantação somente com CPU não consegue executar o LLM de geração em tempo viável.)
Runbooks Obrigatórios	Uma habilidade cujos passos carregam correspondentes de comando é um runbook que um humano pode armar: `advise` (avisos da rodada 1), `require_ack` (um comando correspondido é desafiado e prossegue somente após um reconhecimento auditado — permissão de uso único vinculada a espaço de trabalho, membro, sessão, hash de comando, passo, versão do pacote e execução) ou `block` (falha fechada, com um recibo do servidor que o cliente exige antes de honrar uma permissão). A evidência é pontuada por sucesso — um passo conta somente quando seu comando sai com código 0 — e cada evento de aplicação cai em um livro-razão de desvios (painel + caixa de entrada), armazenando hashes de comando, nunca o texto do comando. Os modos são definidos por um humano em uma rota somente para administradores; agentes podem propor runbooks, nunca armá-los. Opt-in via `PROCEDURE_ENABLED`, atualmente em teste em nossas próprias implantações — veja docs/guides/living-procedures.md.
Quadro de Decisões	Quando um esclarecimento precisa de mais do que algumas perguntas, o agente abre um quadro local no navegador pré-preenchido com evidências recuperadas da memória da equipe — melhores perguntas, informadas pelo que a equipe já aprendeu. O gateway local fica na frente do processo do Quadro de Decisões e do Cortex `/decision/synthesize`.
Instruções Vivas	A camada de instruções se mede: uma tabela de conformidade por instrução calculada deterministicamente a partir da reprodução (as sessões lembraram antes de responder, registraram conforme avançavam, declararam ações consequentes), com tendência ao longo do tempo, fatias por runtime e recibos de exposição — as sessões carregam um hash de conteúdo do texto da instrução que realmente as alcançou, e qualquer coisa não verificável é relatada como desconhecida em vez de contada. Honesta sobre seus limites por construção: mede comportamento, não se o comportamento ajudou. Reescritas elaboradas pela frota sob veredito humano e validação A/B estão no roadmap.
Livro-Razão de Confiança	Um registro de emprego por agente construído a partir das declarações que os agentes já fazem pelo gateway (`action_before`/`action_after`): contagem de ações declaradas, taxa de reconciliação, calibração de previsão-resultado (Brier sobre confiança declarada vs. resultado reconciliado), reversões, sessões, primeiro/último visto. Apenas visibilidade — relata, nunca bloqueia. Honesto por construção: calibração é comportamento, não competência; apenas ações declaradas são vistas; `agent_id` é um rótulo autodeclarado, então o registro é por identidade declarada; e a calibração lê sinal insuficiente abaixo de um limite em vez de inventar um número. A metade de aplicação (um corretor de capacidades que transforma o registro em autonomia conquistada) está no roadmap.
Auto-Avaliações + Descoberta de Padrões	Métricas de qualidade calculadas a partir de rastros de reprodução na conclusão da sessão. A detecção de padrões está habilitada; endpoints automatizados de promoção/validação e experimentos A/B estão implementados, mas desativados por padrão até que uma implantação tenha volume de sessão suficiente para usá-los com responsabilidade.
Reprodução e Explicabilidade	Cada leitura/escrita de memória, evento de ciclo de vida de sessão, mudança de ambiente, ação de coordenação e decisão de gateway é registrada como um rastro estruturado. Inspecione, restrinja e reconstrua o contexto em qualquer evento anterior.
Segredos Criptografados	Cofre baseado em Fernet para credenciais de infraestrutura, tokens de API e strings de conexão. Distinto da memória — segredos nunca aparecem no recall.
Conhecimento de Negócios	Ingira documentos da empresa (páginas de wiki, tickets, documentação de API) — manualmente ou por coletores agendados do Confluence. Os trechos caem no armazenamento vetorial e surgem naturalmente durante o recall de memória junto com memórias operacionais.
Inteligência de Código	Busca de símbolos baseada em tree-sitter, grafos de chamadores, mapas de arquitetura e análise de impacto que retorna fatias de símbolos em vez de arquivos inteiros — executa no lado do cliente pelo gateway local (`firekeep-symdex` é instalado com o kit). 38 ferramentas MCP (8 ferramentas de análise ocultas por padrão atrás de `SYMDEX_ANALYTICS_ENABLED`).

Por que o Firekeep é diferente

O Firekeep não é outro wrapper de chatbot ou camada de orquestração de prompts.

É uma camada operacional para agentes de IA conectados — infraestrutura que fica atrás das suas ferramentas existentes e as torna melhores.

Autohospedado por padrão. O servidor, os armazenamentos de dados, os embeddings e o modelo de geração padrão são executados na sua infraestrutura. A saída para terceiros ocorre somente quando você opta por um conector ou um provedor externo do Symdex AI.
Aprofundado onde o trabalho acontece. Codificação é o fluxo de trabalho mais consolidado, com o Symdex para inteligência de código. Não é o limite do produto: o Docdex traz pastas de documentos selecionadas para o mesmo Keep, o Maildex traz o e-mail de um membro (IMAP somente leitura, sempre privado do membro, firekeep maildex add), e as camadas compartilhadas de continuidade, coordenação, governança e evidências são independentes de domínio.
Persistência + observabilidade. A maioria das ferramentas de agente foca em tornar o agente mais inteligente no momento. O Firekeep foca no que acontece entre as sessões e depois que algo dá errado.
Nativo para MCP. Quatro serviços remotos e dois backends locais do cliente expõem ferramentas do Model Context Protocol por meio de um gateway stdio local firekeep. Os adaptadores fornecidos configuram Claude Code, Claude Desktop, Codex, Kiro e OpenCode; outros clientes MCP podem ser configurados manualmente.
Independente de agente. Troque o cliente de agente sem reconstruir a camada subjacente de memória e coordenação. O Cursor tem um caminho MCP manual documentado; o Aider atualmente não tem um adaptador fornecido.
Descoberta via A2A. O Relay publica um cartão de agente Agent-to-Agent em /.well-known/agent.json para descoberta de capacidades. Isso é apenas descoberta, não um endpoint de execução de tarefas A2A.

Detalhes de instalação e operação

Um comando, duas perguntas obrigatórias: a identidade do agente à qual cada memória, sessão e evento de replay é atribuído, e onde seu servidor Firekeep está — configure um nesta máquina com Docker, resgate um código de adesão, aponte para um que já esteja em execução, ou decida depois (firekeep doctor então explica como terminar). Configurar um aqui executa firekeep init para você; esse instalador não pergunta nada, e a máquina se registra sozinha assim que a pilha está de pé, então firekeep doctor fica verde sem painel, sem túnel e sem chave colada. Ele imprime o comando pronto para colar para sua segunda máquina quando terminar.

O instalador então oferece um prompt opcional para o arquivo de regras de outro cliente MCP; os quatro adaptadores fornecidos são renderizados de qualquer forma.

As imagens atuais do servidor têm como alvo linux/amd64: execute-as em um host Linux x86-64, ou via Docker Desktop com suporte a contêineres amd64. O bootstrap do cliente é testado no CI em Ubuntu, Debian, Alpine, Fedora, Rocky, Arch e openSUSE (x86_64 e aarch64); macOS executa o mesmo script, mas não é coberto pelo CI.

Requisitos e dimensionamento — firekeep.ai/docs.html#requirements
Instalação do servidor — firekeep.ai/docs.html#server
Conectando agentes e colegas — firekeep.ai/docs.html#connect
Solução de problemas — firekeep.ai/docs.html#troubleshooting

A partir deste checkout

bash install.sh              # build the server from source
bash install.sh --pull       # the same installer against the published images
cd client && ./install       # the kit from this checkout (.\install.ps1 on Windows)
firekeep install             # re-render the runtime adapters only

install.sh não pergunta nada: o endereço do host é detectado e a senha do Neo4j é gerada (--ip / --neo4j-password, ou FIREKEEP_VPS_IP / FIREKEEP_NEO4J_PASSWORD, substituem qualquer um dos dois). Ele retorna assim que a pilha está de pé, em vez de bloquear no download do modelo de ~3,3 GB — até que isso termine, as gravações de memória retornam status="partial" (armazenadas e enfileiradas para preenchimento retroativo, ainda não pesquisáveis) e firekeep doctor carrega uma linha de aviso embeddings dizendo isso. bash install.sh --wait-for-models bloqueia em vez disso.

Operar o servidor depois — acesso e autenticação, o painel, backups, atualizações, expor portas deliberadamente — está em docs/DEPLOYMENT.md.

Removendo

firekeep uninstall            # remove the client kit from this machine
firekeep uninstall --server   # also tear down the server + ALL its data

firekeep uninstall remove apenas o que o kit instalou — os blocos do Firekeep na configuração de cada runtime (suas próprias configurações permanecem intactas), o lançador e sua entrada no PATH, e ~/.firekeep — e pergunta primeiro (--yes pula o prompt). Ele nunca toca em um servidor que você configurou. --server adicionalmente executa docker compose down -v na pilha que esta máquina provisionou, excluindo os volumes do Neo4j/Qdrant/Redis — cada memória, sessão e segredo, permanentemente — atrás de uma confirmação separada de perda de dados que uma desinstalação simples ou --yes nunca pode acionar. Faça backup primeiro (docs/DEPLOYMENT.md) se você puder querer os dados de volta.

Firekeep Studio

Baixar para Windows · Baixar macOS universal · Explorar Studio →

studio/ é um cliente desktop separado para pessoas que querem que o Firekeep seja o único aplicativo de agente que abrem. Ele dá ao Codex, Claude Code, Kiro CLI e Grok uma superfície de conversa neutra em relação ao runtime: qualquer runtime suportado pode ser o principal explícito, outros runtimes podem revisá-lo em contextos somente leitura novos, e /compare, /consensus, um espaço de trabalho compartilhado explícito, entrada de voz no Windows e saída de voz do sistema, guardas de token cientes de cache, sessões locais nomeadas e codificadas por cores, descoberta ao vivo de modelo/raciocínio do provedor e controles tipados do Client Kit são integrados. O runtime selecionado é visualmente explícito, o inspetor completo pode ser ocultado, e o Studio se conecta ao painel a partir da conexão existente do Client Kit sem expor suas credenciais. Respostas Mermaid cercadas renderizam como diagramas nativos com zoom, e o painel de decisão existente do Firekeep abre como um painel nativo de pergunta/evidência/ação dentro do Studio. Seu push autenticado local preserva o long poll original, evitando uma rodada extra do agente apenas para descobrir que o painel está pronto. O seletor de runtime principal mostra prontidão ao vivo e contexto de transporte, a rolagem de respostas respeita leitores que se afastam do final, e copiar/colar usa operações nativas de área de transferência limitadas a texto. Respostas concluídas lideram cada execução enquanto eventos de trabalho detalhados se dobram em um Work log. Uma visão Agents neutra em runtime organiza Codex, Claude, Kiro, Grok ou qualquer futuro adaptador com chat em painéis selecionáveis com continuações nativas independentes; o compositor compartilhado tem como alvo o painel selecionado, e execuções ativas permanecem serializadas para segurança do espaço de trabalho. O Mission Mode adiciona um harness limitado por resultado: um escritor principal, verificações locais determinísticas, reparo limitado, evidência de revisão independente, aceitação humana explícita e um resultado de tarefa armazenado separadamente da prosa de cada agente.

O Studio consome limites estruturados suportados pelo provedor em vez de raspar TUIs, mantém a autenticação do provedor de propriedade do provedor (exceto chaves de API criptografadas pelo SO) e continua a usar o Client Kit Python existente sempre que a configuração nativa de um runtime fornece memória Keep, hooks, política e conectividade. Os cartões de runtime relatam essa evidência explicitamente; o adaptador direto Grok do xAI é claramente marcado como sem memória Keep, em vez de herdar a alegação de outro runtime. O build de pré-visualização e comandos do instalador, limites de segurança, matriz de runtime e inventário completo de comandos / estão no README do Studio.

O Studio 0.4 inclui um instalador Windows x64 e um instalador macOS universal de um canal de lançamento isolado e assinado. Builds empacotados verificam atualizações do Studio logo após o lançamento; o Windows baixa e instala uma atualização verificada na reinicialização, enquanto o macOS usa atualizações automáticas nativas apenas quando o lançamento é assinado e notarizado pela Apple. A página de lançamento atual, somas de verificação e ambos os instaladores são publicados em Firekeep Studio releases.

Um Fluxo de Trabalho Real

Aqui está o que acontece quando um agente usa o Firekeep:

1. A sessão começa. Em runtimes com hooks de ciclo de vida, o cliente busca o GET /briefing agregado do Cortex primeiro, incluindo memórias relevantes, tarefas, estado do ambiente e habilidades. O agente então chama ctx_start_session("fix auth middleware bug"); o Bridge cria a sessão durável e o shim a vincula a esse briefing.

2. Exploração de código. Em vez de ler cada arquivo, o agente chama search_symbols("auth middleware") e get_callers("require_scope") no Symdex. Ele obtém uma lista direcionada de arquivos e chamadores em milissegundos.

3. Verificação do ambiente. O Sentinel está observando o Docker. Ele detectou que o contêiner cortex-api reiniciou 3 vezes na última hora e enviou um alerta para o canal #alerts do Relay. O agente vê isso em seu contexto.

4. O trabalho acontece. O agente edita arquivos, executa testes e registra progresso importante com ctx_update. O Bridge persiste o que foi explicitamente registrado. Quando a janela de contexto comprime, o agente chama ctx_get_shadow e obtém esse estado de trabalho durável de volta — planos, decisões, progresso e conhecimento de arquivos.

5. A sessão é concluída. O agente chama ctx_complete_session, opcionalmente passando uma autoavaliação estruturada — task_result ("success" / "partial" / "failure", o resultado da TAREFA, não o do RPC) mais até 10 declarações curtas de task_evidence que a sustentam. A nota é aceita apenas do proprietário verificado da sessão e armazenada como o único resultado autoritativo e nunca sobrescrito dessa sessão. O Bridge marca atomicamente a sessão como concluída e enfileira a destilação em segundo plano para memória episódica; falhas são repetidas e eventualmente movidas para uma fila de mensagens mortas visível. Autoavaliações calculam métricas de qualidade a partir do trace de replay — uma sessão sem nota reconhecida é lida como unknown em vez de um sucesso adivinhado, então a pontuação orientada por resultados (Memória Ponderada por Resultado, tendências de qualidade) nunca conta silêncio como vitória. Na próxima vez que alguém trabalhar em middleware de autenticação, as memórias estarão lá assim que a destilação for bem-sucedida.

6. Algo deu errado? Abra a aba Replay no painel. Carregue a sessão. Veja cada ação, cada leitura de memória, cada ponto de decisão. Clique em um evento de falha e execute a redução — ela percorre a cadeia causal para ajudar a identificar a causa raiz.

Arquitetura

Local Machine                               VPS
┌──────────────────────────┐              ┌────────────────────────────────────┐
│ Claude / Codex / Kiro /  │              │ FirekeepCortex   — Memory & RAG    │
│ OpenCode / MCP client    │              │ FirekeepBridge   — Sessions        │
│           │              │              │ FirekeepSentinel — Monitoring      │
│  one `firekeep` gateway  │◄──── MCP ───►│ FirekeepRelay    — Coordination    │
│    ├─ symdex (local)     │              │ Dashboard        — Web UI          │
│    └─ decision (local)   │── Browser ──►│ Neo4j · Qdrant · Redis · Ollama    │
└──────────────────────────┘              └────────────────────────────────────┘

O Symdex e o Decision Board são executados no lado do cliente como servidores MCP locais via stdio (instalados com o kit) — o Symdex deve ser local à árvore de trabalho que indexa, então não é mais um contêiner VPS.

As duas setas que cruzam esse limite não são publicamente alcançáveis por padrão. Fora da caixa, o lado VPS escuta em loopback e exige uma chave de API, então a metade da máquina local o alcança por um túnel SSH, uma rede privada ou um front end HTTPS que você configura deliberadamente. Veja docs/DEPLOYMENT.md → Acesso e autenticação.

Serviço	O que faz
FirekeepCortex	Memória de longo prazo. RAG semântico + de grafo, ciclo de vida de arquivamento/restauração, consolidação por ciclo de sono, quatro tipos de memória com decaimento ciente do tipo, memórias versionadas com pontuação de confiança, supersessão automática de contradições, habilidades criadas por agentes (`skill_create`) + um pipeline de docs→habilidades, e o Agent Gateway (superfície de prever-depois-agir).
FirekeepBridge	Persistência de sessão. Preserva o contexto de trabalho (planos, decisões, progresso, conhecimento de arquivos) durante compressões de contexto. Auto-destila para o Cortex ao concluir. Detecção de sessão interrompida com retomada por snapshot do workspace. Um coletor de sessões abandona sessões ociosas por mais de 72h, para que sessões abandonadas sejam registradas como não-sucessos na pontuação de resultados. Emite eventos de ciclo de vida de sessão para o stream de replay.
FirekeepSentinel	Observador de ambiente. Saúde do Docker, commits de git, alterações de arquivos. Transmite alertas ao Relay em erros. Reinicializações de contêineres, novos commits e alterações de arquivos fluem para um stream de eventos reproduzível.
FirekeepRelay	Coordenação de agentes. Canais pub/sub em tempo real, quadro de avisos persistente, fila de tarefas estruturada, leases de recursos com tokens de fencing monotônicos, registro de presença, mensagens diretas e um endpoint de cartão de agente A2A para descoberta externa.
Dashboard	Interface web que cobre coordenação, memória, diagnósticos, dispositivos, membros, políticas, cofre e operações.
Firekeep Studio	Console desktop local opcional e harness de Missão para agentes primários, verificação determinística, revisores independentes, ditado no Windows, respostas de voz do sistema, comparação entre runtimes e controle do Client Kit. Não é um serviço VPS.

Inteligência de código (FirekeepSymdex — 38 ferramentas MCP, 8 análises ocultas atrás de uma flag) e o Decision Board (firekeep-decision) rodam no lado do cliente como servidores MCP locais via stdio instalados com o kit, não como contêineres VPS.

Módulos compartilhados (sem contêineres extras): Replay Engine (log de rastreamento estruturado em todos os serviços), Auth (escopos de chave de API), Vault (armazenamento de segredos criptografado com Fernet), Corpus (ingestão de documentos de negócio → chunks vetoriais; coletores agendados do Confluence), Auto-Evals (10 métricas de qualidade Tier-1 + acompanhamento de tendências + detecção de regressão), Pattern Engine (detecção de estratégia; validação de promoção e experimentos A/B desativados por padrão via feature flags), Policy Engine (verificações de segurança pré-edição compostas — lease, risco de arquivo, negação de caminho, saúde da sessão, falha recente), Agent Gateway (superfície de prever-depois-agir com cache de caminho rápido para ações repetidas de baixo risco), Skills (criadas por agentes via skill_create + rascunhos de docs→habilidades sob revisão humana; síntese no lado do servidor desativada por padrão), Memory Improvements (envelhecimento composto com arquivamento primeiro, com pré-visualização/auditoria/restauração, orçamentos de tokens, passada de síntese com LLM, entrada de embedding limitada + ajuste para caber).

Para a especificação completa do design, consulte docs/DESIGN.md.

Dashboard

Acesse em http://localhost:8040 no host, ou através de um túnel de outro lugar (docs/DEPLOYMENT.md → Acessando o dashboard). Ele tem seu próprio login de autenticação básica (usuário admin; a senha é gravada uma única vez em dashboard/.htpasswd.cred). Por trás disso, o nginx injeta a chave de API do dashboard em cada chamada de backend, então o SPA funciona contra a pilha protegida por autenticação sem que você cole uma chave no navegador.

Aba	O que mostra
Visão geral	Saúde dos serviços, estatísticas rápidas, eventos e memórias recentes
Sessões	Sessões ativas/pausadas/concluídas/abandonadas, inspetor de contexto sombra
Eventos	Feed de eventos do Sentinel com filtros de origem e severidade
Relay	Fila de tarefas, canais, quadro de avisos, mensagens diretas, claims/leases ativos
Escopo	Sessões de esclarecimento do FirekeepScope — telas ativas, prompts de resposta
Memória	Busca de recall, navegadores de ativos/arquivados, restauração com um clique, pré-visualização/auditoria de manutenção, formulário de armazenamento, contribuidores, estatísticas de namespace/tag
Habilidades	Cartões de habilidades criadas por agentes + derivadas de documentos — revisar, ativar, editar, aposentar — além dos cartões de runbook das Living Procedures: selo de modo de aplicação e controle de modo admin, estatísticas de observação por etapa, visualização de desvios e um aviso de NÃO APLICADO ATIVAMENTE quando um runbook armado não tem nenhuma sessão segurando o pacote atual
Conhecimento	Ingestão de docs→habilidades (colar / URL) + a fila de aprovação de rascunhos de habilidades
Autopilot	A caixa de entrada de revisão (rascunhos/desatualizados/re-revisão de habilidades, propostas de procedimentos, desvios de runbook, pares de memória contestados com os vereditos propostos pela frota, dead letters de avaliação), o resumo "o que mudou esta semana", a tabela de conformidade das Living Instructions (taxas por instrução, tendência, fatias por runtime, estados de exposição), o cartão Trust Ledger (declarado/reconciliado/calibração/reversões por agente) e uma tabela da Frota com taxas de aprovação por job — somente leitura; propõe e relata, nunca altera
Padrões	Cartões de estratégia descobertos; validação de promoção e controles de experimento quando suas feature flags estão habilitadas
Ops	Workers, profundidades de fila, agentes ativos, informações do armazenamento vetorial, contador de Discipline (chamadas de memória sem tag)
Política	Regras de política de runtime para verificações de segurança pré-edição, alternância por regra
Cofre	Gerenciamento de segredos criptografados (com Fernet, Redis DB 7)
Replay	Linhas do tempo de rastreamento de sessão, inspetor de eventos, redução de causa raiz
Evals	Métricas de qualidade agregadas, scorecards por sessão, tendências de qualidade
Dispositivos	Credenciais de dispositivos e comandos de inscrição de uso único
Membros	Pessoas e convites de membros de uso único

O dashboard é um SPA estático sem dependências. Sem etapa de build, sem npm, sem framework.

Documentação

Documento	Conteúdo
docs/DEPLOYMENT.md	Executando um servidor: acesso e autenticação, atualizações, backups, solução de problemas, desenvolvimento local (instalação em firekeep.ai/docs.html)
docs/CONFIGURATION.md	Todas as variáveis de ambiente, alocação de banco de dados Redis, recursos de inteligência
docs/MCP-TOOLS.md	Referência completa de ferramentas MCP no servidor e backends locais registrados no cliente; o inventário visível varia conforme o registro de dex e feature flags
docs/DESIGN.md	Especificação completa da arquitetura, contratos de serviço, pontos de integração
docs/COMPARISON.md	Comparação recurso por recurso vs. Claude Code base
docs/SETUP-CODEX.md	Guia de integração com Codex
docs/SETUP-CLAUDE-CODE.md	Guia de integração com Claude Code
docs/MULTI-AGENT.md	Inteligência de agentes: briefing pré-voo, debrief de sessão, coordenação multiagente
studio/README.md	Matriz de runtime do Firekeep Studio, comandos, modelo de segurança, desenvolvimento e empacotamento

Pilha de Tecnologia

Serviços de servidor em Python 3.11 (cliente suporta Python 3.10+) / FastAPI / FastMCP / Neo4j / Qdrant / Redis / Ollama / Docker Compose / tree-sitter / TypeScript / Electron / React

Embeddings e geração no lado do servidor usam Ollama local por padrão, então o caminho padrão do servidor não tem cobrança de API de modelo. O Symdex pode opcionalmente usar Anthropic, Gemini ou um endpoint compatível com OpenAI para resumos de símbolos e scaffolding; habilitar um desses provedores pode enviar trechos de código para fora da máquina e incorrer em custos do provedor. A indexação automática em segundo plano desativa explicitamente resumos de IA.

Roadmap

Funcionando agora

Ciclo de vida completo da memória (aprender, recordar, decaimento, detecção de contradição, versionamento)
Quatro tipos de memória (referencial / procedural / episódica / transitória) com decaimento de recordação consciente do tipo; aprendizados diretos assumem como padrão o episódico, enquanto a consolidação bruta de eventos classifica o conhecimento extraído
Recordação consciente de tokens com síntese opcional por LLM
Envelhecimento composto com arquivamento em primeiro lugar (idade × acesso × confiança) com pré-visualização no painel, auditoria e restauração; memórias confirmadas, habilidades e blocos do corpus nunca são arquivados por idade, e a purga automática definitiva está desativada por padrão
Continuidade da equipe: proveniência verificada de workspace/membro, além do runtime agent_id + project, relatórios de contribuidores, briefings de transição sintetizados por LLM
Persistência de sessão por meio de compressões de contexto, com detecção de falhas e retomada por snapshot do workspace
Emissão de replay de ponte no ciclo de vida da sessão (iniciada / atualizada / concluída / abandonada)
Monitoramento de Docker + git + arquivos com alertas Relay; atividade de contêiner/commit/arquivo flui para o fluxo de replay
Coordenação de agentes: canais, quadro de avisos, leases de token de cercamento, fila de tarefas estruturada, registro de presença, mensagens diretas
Briefing pré-voo monta inteligência de todos os serviços no início da sessão; exibe avisos de disciplina quando chamadas de memória chegam sem cabeçalhos de identidade
Debriefing de sessão: conclusão guiada com atualizações de tarefas e limpeza de leases
Suporte a múltiplos agentes (atribuição de tarefas, polling de caixa de entrada, aplicação de leases de arquivo)
Habilidades: autoradas por agentes via skill_create (lado do cliente) + um pipeline de docs→habilidades (colar / URL / coletores agendados do Confluence) redigindo habilidades sob revisão humana; as melhores correspondências são injetadas no próximo briefing (auto-síntese no lado do servidor existe atrás de SKILL_SYNTHESIS_ENABLED, desativada por padrão)
Night Shift: firekeep night-shift drena o catálogo de trabalhos da frota — destilação de sessão (enfileirada pelo hook de fim de sessão), re-autoria de habilidades obsoletas e propostas de veredito contestado (enfileiradas à noite pelo servidor) — na sua própria máquina contra um modelo local (LM Studio ou Ollama, auto-detectado), escrevendo memórias atribuídas à sessão original, habilidades rascunho que nomeiam a habilidade obsoleta que reescrevem (reauthor_of) e propostas de veredito registradas no par contestado — nunca aplicadas, sempre aguardando um humano. O início da sessão o inicia em segundo plano quando uma porta de modelo local responde (FIREKEEP_NO_AUTO_NIGHTSHIFT=1 para optar por sair). A geração permanece fora do servidor; modelos hospedados em nuvem são recusados por padrão para que o conteúdo da sessão não possa sair da máquina
Decision Board: quadro de esclarecimento local gerado por agentes, pré-preenchido com evidências de memória da equipe recuperadas (servidor stdio firekeep-decision + Cortex /decision/synthesize)
Modo pessoal / bypass: /personal na sessão (ou firekeep personal / FIREKEEP_BYPASS=1) torna o Firekeep totalmente dormente para trabalho privado — hooks, sidecar, decision board e shim respeitam um único gate is_bypassed(); limpa automaticamente no fim da sessão
Pattern Engine: detecção de estratégia, classificação de categoria (procedural / risco / comportamental) e controles de quarentena; promoção/validação automatizada é implementada atrás de PATTERN_VALIDATION_ENABLED=false por padrão
Estrutura de experimentos: conjuntos de dados nomeados, testes de significância qui-quadrado, intervalos de confiança de tamanho de efeito e experimentos controlados de dicas de estratégia atrás de PATTERN_EXPERIMENTS_ENABLED=false por padrão
Loop de feedback opcional para medir se dicas de briefing melhoram resultados quando a validação de padrões está habilitada
Mecanismo de política em runtime: verificações compostas pré-edição (lease, risco de arquivo, negação de caminho, saúde da sessão, falha recente)
Agent Gateway (prever-depois-agir): MCP action_before / action_after, o gateway retorna allow | rethink | block, cache de caminho rápido para ações repetidas de baixo risco
Cofre de segredos criptografados (Fernet) com ferramentas MCP e API REST
Traços de replay com estreitamento de causa raiz e reconstrução de contexto por evento
Auto-avaliações: 10 métricas de qualidade Tier-1 calculadas na conclusão da sessão, acompanhamento de tendências, detecção de regressão
Knowledge Autopilot rodada 1 (visibilidade, nunca mutação autônoma): recordação ponderada por feedback + a ferramenta memory_feedback, um ceifador de sessões Bridge para que sessões com falha contem como falhas, tratamento de contestado-não-substituído para conflitos de memória não confirmados com vereditos humanos, a caixa de entrada de revisão do Autopilot + resumo semanal, um livro-razão de evidências por memória (/memory/{id}/evidence) e uma escada de habilidades em modo sombra que registra quais rascunhos ganhariam trial e quais tentativas ganhariam active — veja docs/guides/knowledge-autopilot.md
Living Instructions rodadas 1 + 2 (medição): a tabela de conformidade por instrução na aba Autopilot (predicados congelados em uma linha de base pré-registrada), tendência ao longo do tempo e o contrato de medição da rodada 2 — hashes de conteúdo de instrução carimbados no bloco renderizado, cinco cabeçalhos de atribuição, fatias por runtime e estados exposto/não-exposto/desconhecido com tudo não verificável relatado como desconhecido. Reescritas sob veredito humano e variantes A/B entregues por briefing são roadmap — veja a especificação de design em docs/ROADMAP.md
Dreaming: consolidação automatizada de memória + perfis de pessoa (DREAM_ENABLED, desativado por padrão)
Living Procedures rodadas 1 + 2: habilidades observadas como procedimentos com propostas de frequência/eficácia sob revisão humana e — rodada 2 — Runbooks Enforced: correspondentes de etapas de comando, aplicação advise/require_ack/block armada por humanos com evidência com gate de sucesso, um protocolo desafio→ack→permit de uso único, modo de bloqueio fail-closed e um livro-razão de desvios por workspace exibido no painel e na caixa de entrada do Autopilot (PROCEDURE_ENABLED, desativado por padrão; dogfooding antes de qualquer anúncio) — veja docs/guides/living-procedures.md
Trust Ledger rodada 1: um registro de emprego por agente agregado sob demanda a partir de eventos do gateway de replay (GET /autopilot/trust + um cartão no painel) — contagens declaradas/conciliadas, calibração de correspondência de previsão, reversões, sessões. Apenas visibilidade, global à implantação, fórmulas congeladas pré-registradas antes do primeiro número publicado. O corretor de capacidade de aplicação (autonomia conquistada) é uma rodada posterior
Reforço de locação do corpus: fontes de documentos privadas por membro com um filtro de visibilidade compartilhado em cada saída, identidade de ponto com escopo de fonte (texto idêntico entre membros não colapsa mais em um ponto deletável), autorização de fonte com consciência de principal e um gate de geração confirmada — infraestrutura geral abaixo dos futuros dexes do cliente
Um gateway MCP local degradante registrado por cada adaptador, agregando quatro serviços remotos mais o Decision Board local do cliente e quaisquer dexes registrados
O registro de dexes: dexes são os índices de domínio que o Keep entende, listados e alternados com firekeep dex list|add|remove contra ~/.firekeep/dexes.json. Todas as três rodas são enviadas empacotadas e verificadas por checksum com cada versão — o registro controla a atividade, não a instalação. Symdex e docdex são registrados por padrão (desde o cliente 1.2.0, um registro ausente é semeado com ambos); firekeep dex remove é o interruptor de desligamento, e remoções persistem entre atualizações. O mesmo arquivo também carrega capacidades — entradas que operam um domínio em vez de indexá-lo, marcadas role: capability, nem empacotadas nem jamais semeadas — veja docs/guides/dexes.md
Inteligência de código: firekeep-symdex no lado do cliente atrás do gateway (38 ferramentas, 8 análises ocultas atrás de uma flag), montado quando registrado como um dex
Documentos: firekeep-docdex no lado do cliente — pastas que um humano registra (firekeep docdex add ~/Notes) extraídas para texto e ingeridas no corpus, surgindo por meio de memory_recall comum. Privado ao membro por padrão mesmo em um Keep compartilhado, --shared para o workspace; md/txt/pdf/docx, sem OCR; a exclusão de um arquivo local remove sua réplica do corpus na próxima sincronização
Email: firekeep-maildex no lado do cliente — caixas de correio IMAP que um membro registra (firekeep maildex add), somente leitura (cada abertura é EXAMINE, cada busca é PEEK; sem capacidade de envio na roda), sempre privado ao membro
Desktop: firekeep-hands no lado do cliente — a primeira capacidade do registro em vez de um índice, então opera seu domínio em vez de indexá-lo. Seu runtime observa e dirige os aplicativos deste computador e um navegador gerenciado por Hands, e cada etapa consequente aguarda um corretor de aprovação separado que aceita apenas um pressionamento de tecla real, não injetado. Opt-in e nunca empacotado (firekeep hands enable), nunca semeado; os limites honestos — telas bloqueadas, janelas elevadas, capturas de tela saindo da máquina, injeção de prompt — estão declarados em docs/guides/hands.md
Pipeline de conhecimento docs→habilidades (knowledge_ingest, ingestão por URL) + coletores agendados do Confluence com opt-in (SP3)
Painel web com gerenciamento de Devices e Members ao lado de memória, coordenação, replay, política e operações
Endpoint de cartão de agente A2A (/.well-known/agent.json) para descoberta externa
Ingestão de conhecimento de negócios: dividir documentos em armazenamento vetorial, surgir durante a recordação de memória
Notificações por webhook (Slack, Discord, HTTP genérico)
Autenticação: escopos de API por chave (memory:read/write, session:read/write, replay:read, eval:read, admin, …), ativada por padrão, com chaves inicializadas pelo instalador

Prometido (os dois degraus do roadmap publicados em firekeep.ai)

Instâncias vinculadas — vários servidores Firekeep compartilhando conhecimento em uma organização, para que o que uma equipe aprende seja recordável por outra
Perfis de domínio — experiências separadas (codificação e documentos hoje; pesquisa adiante) como perfis do mesmo kit de cliente sobre um cérebro compartilhado: nunca produtos separados, nunca armazenamentos de memória separados

O registro de decisão por trás de ambos — perfis-não-clientes, o pré-requisito da camada de vinculação, gate de sinal de resultado, sequenciamento — está em docs/ROADMAP.md.

Planejado (menor)

Exportação de métricas Grafana
Ingestão de conector Jira (auto-sincronização wiki/Confluence já enviada, opt-in)
Versionamento e reversão de habilidades

Status

O Firekeep está em desenvolvimento ativo e usado diariamente. As implementações principais — memória, sessões, monitoramento de ambiente, coordenação, replay, o kit de cliente e Symdex — são cobertas por mais de 4.000 testes automatizados aprovados no repositório atual. A arquitetura é projetada para implantação em host único.

Este repositório público, com código-fonte disponível, está em acesso antecipado.

Licença

O Firekeep é de código-fonte disponível sob BUSL-1.1, e o uso de produção auto-hospedado é gratuito para indivíduos e para equipes — um workspace de qualquer tamanho, em infraestrutura que você controla, gratuito para equipes enquanto o Firekeep estiver em acesso antecipado. O nível comercial é governança e suporte Enterprise (escreva para sales@firekeep.ai). Cada versão converte para Apache-2.0 quatro anos após sua primeira publicação pública. Veja LICENSE para a concessão completa e docs/LICENSING.md para o status. Symdex permanece sob esta licença até que seu Core independente seja extraído e lançado separadamente sob Apache-2.0.