Pular para o conteúdo
Menu

Produto

Soluções

Integrações

Desenvolvedores

Idioma

Desenvolvedores

Contribua com o ai-memory

190 pessoas já colocaram código no projeto. Esta página leva você de uma ideia até a issue certa, o crate certo e um pull request que passa no review de primeira.

Escolha por onde entrar

Cada item leva para a página exata no GitHub.

Faça o build funcionar

O build é autocontido. Nenhum destes comandos precisa de variável de ambiente.

  1. Clone e compile

    O Rust 1.95 é obrigatório e está fixado no rust-toolchain.toml, com rustfmt e clippy, então o rustup instala a toolchain certa no primeiro build. O SQLite vem embutido e a libgit2 é vendorizada. Você precisa de uma toolchain C padrão e mais nada.

    setup de dev
    git clone https://github.com/akitaonrails/ai-memory
    cd ai-memory
    cargo build --workspace
    cargo test --workspace --all-targets
    
  2. Use o loop do dia a dia

    cargo t precisa do nextest: cargo install cargo-nextest --locked. Ele pula os módulos chamados slow ou stress, que o hook de pre-push e o CI rodam mesmo assim.

    enquanto você trabalha
    cargo t                        # tudo menos o tier lento, ~20s com cache quente
    cargo t -p ai-memory-store     # um crate: compila só os binários de teste dele
    cargo t -E 'test(/purge/)'     # um assunto (compila tudo, roda um subconjunto)
    
  3. Instale o hook de pre-push

    Uma vez por clone. Ele só mexe no próprio bloco dentro de .git/hooks/pre-push. Em um branch de trabalho em andamento, git push --no-verify pula o hook.

    uma vez por clone
    scripts/install-git-hooks.sh
    
  4. Passe nos gates antes do push

    O CI exige os cinco. Sem o nextest, cargo test --workspace --all-targets equivale a cargo tf. Se o último estiver faltando: cargo install cargo-deny cargo-audit.

    gates obrigatórios
    cargo fmt --all -- --check
    git diff --check
    cargo clippy --workspace --all-targets -- -D warnings
    cargo tf                            # todos os testes (alias: cargo nextest run -P full)
    cargo deny check                    # política de dependências
    
  5. Confira quem seus commits dizem que você é

    Use um email verificado na sua conta do GitHub ou o endereço noreply dela. O histórico da main nunca é reescrito para corrigir autoria.

    autoria dos commits
    git log --format='%h %an <%ae>' "$(git merge-base HEAD origin/main)"..HEAD
    

Regras básicas e o critério de aceitação

O AGENTS.md é o arquivo de regras canônico, para pessoas e para agentes de código. O CONTRIBUTING.md condensa tudo nisto.

Como se espera que o trabalho chegue

  • O changelog é um gate de merge

    Toda mudança visível para o usuário adiciona uma entrada em [Unreleased] no mesmo pull request. Os revisores tratam entrada faltando como bloqueio. Refactors e mudanças só de teste ficam isentos.

  • Testes antes do “pronto”

    O trabalho conta como pronto quando tem testes, principalmente parsers, derivação de IDs e a matemática de retenção.

  • Sem código morto, sem feature pela metade

    Stubs são documentados no comentário do módulo, com o milestone que vai terminá-los.

  • Fique dentro da mudança

    Não refatore código de que o milestone atual não precisa.

  • Comentários explicam o porquê

    Um comentário que repete a linha de cima é removido.

Invariantes que um pull request não pode quebrar

  • Todas as escritas no SQLite passam pelo único writer actor, o WriterHandle.
  • A config é lida uma vez na inicialização. Nada de std::env::var fora de Config::load.
  • Escritas em arquivo são atômicas: tmp, rename, fsync. Nunca in place.
  • Toda página da wiki tem namespace (workspace_id, project_id).
  • A CLI é um cliente HTTP fino. Ela nunca abre o arquivo SQLite nem o diretório da wiki.

A lista completa, com o bug que cada uma evita, está no AGENTS.md

Como o padrão se mantém alto

A IA escreve a maior parte do código. Uma pessoa lê tudo, e nada entra por confiança. Cada regra abaixo existe porque algo deu errado uma vez.

Um erro

Uma regra escrita

Teste que tenta quebrar

Gate por pull request

Gate por pull request

Um erro

Uma pessoa decide

Nada disso existia no primeiro dia. Cada regra foi adicionada depois de um erro real, e cada uma é verificada em todo pull request.
  • As regras vêm de erros

    Cada invariante nomeia o bug que a causou e o código que a evita. Uma regra que ninguém consegue rastrear até uma falha é removida.

  • Todo pull request é auditado

    As alegações de um pull request são checadas contra o código, os gates rodam de novo, e só o que foi verificado entra. Os checklists de auditoria são públicos.

  • Uma pessoa decide

    A IA faz a maior parte da digitação. O mantenedor lê, corrige, e transforma o que deu errado na próxima regra.

Leia os checklists de auditoria

Dois modelos, um checklist de auditoria

Um experimento pequeno com o ai-jail, o sandbox que pode receber uma execução com --yolo. O mesmo checklist de security-audit, rodado por dois modelos no mesmo commit, depois comparado.

  • O alvo

    O ai-jail roda um agente de código dentro de um sandbox do sistema operacional: bubblewrap com Landlock e seccomp no Linux, sandbox-exec no macOS. É uma camada, não um substituto para uma máquina descartável quando o código é hostil.

    aijail.io
  • A primeira rodada

    O Genesys Pi, conduzido pelo OpenCode, primeiro fez um trabalho comum de implementação no ai-jail e mesclou o código. Depois rodou a skill security-audit do repositório público de skills contra a v2.3.0.

    O post sobre as skills
  • A segunda rodada

    O Claude Fable 5.1 rodou a mesma skill no mesmo commit sem ler o primeiro relatório. Depois que a lista dele foi fechada, ele refez a derivação de cada pista em comum a partir do código-fonte e escreveu a comparação.

  1. Achado pelos dois11
  2. Só o Genesys Pi11
  3. Só o Claude Fable 5.13
Todas as gravidades como cada relatório as declarou. Os dois relatórios reproduziram sozinhos as mesmas duas descobertas de gravidade alta (High).
  • As mesmas duas High

    Metadados forjados de worktree davam leitura e escrita em um diretório do host, e entradas duplicadas de variável de ambiente driblavam o segredo fantasma. Cada modelo reproduziu as duas sem ver a outra.

  • Genesys Pi foi mais longe

    Onze descobertas só dele, entre elas toda a superfície do macOS e os limites de recursos do proxy, com avaliações de gravidade mais precisas. O Fable tinha rejeitado um bug real e deixado outros dois sem resolver até o cruzamento dos relatórios.

  • O Fable achou a brecha mais grave

    Duas válvulas de escape só de teste no binário de release, lidas a partir do ambiente, ficavam exatamente no caminho que as credenciais fantasmas protegem. Ele também rodou os exploits onde o outro relatório só tinha raciocinado sobre eles.

Os três relatórios, no repositório do ai-jail

Um mapa da base de código

Dez crates vão no binário. Cada um tem uma responsabilidade e uma API tipada, e não há dependências circulares.

cli

hooks

mcp

web

consolidate

workstream

store

wiki

llm

core

Nomes dos crates sem o prefixo ai-memory-. Tudo depende do core, e só o crate cli depende de tudo.
CrateO que mora lá
ai-memory-coreTipos de domínio, erros e ids. Sem IO.
ai-memory-storeSQLite, o writer actor, o pool de leitores e a matemática de decaimento.
ai-memory-wikiEscritas atômicas de markdown, o file watcher e o git.
ai-memory-mcpO transporte MCP, o roteador de ferramentas e as rotas de admin.
ai-memory-hooksSchemas de payload dos hooks, o sanitizador e o endpoint /hook.
ai-memory-llmA fronteira de autenticação dos provedores e as traits de LLM e de embedder.
ai-memory-consolidateIngestão, lint, sweep e o pipeline de auto-improve.
ai-memory-webPáginas web e API JSON somente leitura. Ações de conta e aprovação chamam rotas autenticadas.
ai-memory-workstreamLeitores somente leitura de transcripts nativos e os adapters de abertura por trás do ai-memory run.
ai-memory-cliO binário ai-memory e seus subcomandos HTTP finos.

Fora de crates/

DiretórioO que mora lá
companions/ai-memory-importer, um pacote standalone fora do workspace raiz. Compile com --manifest-path.
hooks/Pacotes de hooks de ciclo de vida, uma pasta por agente, em shell e nativos.
evals/O harness de benchmark. É membro do workspace e nunca é distribuído.
docs/Arquitetura, decisões de design e guias de instalação, deploy e uso.
tests/Smoke tests de ponta a ponta, testes de shell dos hooks e fixtures.

Os testes de integração ficam em tests/suite/ dentro de cada crate. Helpers compartilhados entre crates vão em crates/ai-memory-test-support, que nunca é distribuído.

Como os pull requests são revisados

Os reviews seguem o template de pull request, então preencher com honestidade é a maior parte do trabalho.

  • O template é o checklist

    Ele pede o que mudou, por quê, um plano de testes com os gates marcados, autoria dos commits, impacto na release e a entrada do changelog.

  • Diga que tipo de release é

    Marque patch, minor ou major. Uma correção registrada em “Added” pode subir a versão errada, então coloque a entrada do changelog sob o título certo.

  • Breaking changes esperam uma major

    Destaque na descrição. Elas recebem o label breaking-change e são agendadas, então não seguram as releases de patch e minor.

  • O CI é rápido por merge

    Um merge depende dos jobs rápidos de Linux. As etapas de macOS e Windows rodam por label, toda noite ou na mão, e sempre antes de uma release.

  • Correções saem primeiro

    Um bug fix sai na próxima release de patch e não fica esperando trabalho de feature. Um harness ou provedor novo sai na próxima minor.

Um pull request de harness roda este gate mais curto, registra a versão da CLI contra a qual foi testado e inclui uma rodada manual contra o harness real.

de managed-harness-contributions.md
cargo fmt --check
git diff --check
cargo test --workspace
cargo clippy --workspace --all-targets -- -D warnings

Experimente antes de mudar.

Rode nos seus próprios projetos por um dia. O bug que você achar é a sua primeira issue.