kin v0.3.6

Agentes de IA conseguem escrever uma alteração mais rápido do que uma equipe consegue estabelecer o que ela afeta, se ela reverte uma correção anterior e até onde alcançam suas consequências. O Git registra arquivos e histórico de linhas. O Kin registra o próprio software como um grafo de entidades, relações, alterações e procedência, e então dá a humanos e agentes uma única autoridade semântica para consultar e revisar. O que uma alteração afeta aparece antes de ela ser mesclada, e os agentes trabalham a partir de contexto exato em vez de reler o repositório.

O Kin é o sistema semântico de registro para software escrito por IA. É um alpha público, utilizável hoje como CLI local, daemon, servidor MCP, superfície de revisão e projeção de sistema de arquivos baseada em grafo. Está em pré-1.0, então espere arestas ásperas e mudanças que quebram compatibilidade. Veja a última versão estável e as limitações atuais antes de adotá-lo em um fluxo de trabalho crítico.

Veja em um repositório real

Uma alteração de assinatura de uma linha no ripgrep parece inofensiva no diff. Pergunte ao kin impact sobre ela, antes que qualquer compilador rode, e ele nomeia o que a edição alcança. Os chamadores da assinatura alterada vêm primeiro, depois tudo o que esses chamadores puxam junto.

Registrado contra um grafo preparado no commit e89fff89ac9af12e8d4ce9d5fd07beb408ca730f do ripgrep. 13 entidades impactadas em até 3 saltos, incluindo 3 chamadores diretos da assinatura alterada. O grafo foi construído antecipadamente. Nenhum compilador rodou. Comandos exatos: kinlab.ai/proof. O diretório bruto da execução não é público ainda, então isto é uma receita que você pode reexecutar, não um rastro que você pode auditar.

O Kin revela o que a alteração afeta. Se a alteração está correta permanece com seu compilador, seus testes e sua revisão. O grafo é construído antecipadamente pelo kin init, e construí-lo é a parte cara; depois disso, perguntas de impacto são respondidas a partir da verdade do grafo, não relendo a árvore.

A stack

O Kin é um único sistema com algumas superfícies públicas bem definidas:

Como as peças se encaixam

O Kin é o sistema semântico de registro para software escrito por IA, e tudo no mapa abaixo alcança essa autoridade ou a suporta. Humanos e agentes de IA entram pela CLI, pelo servidor MCP empacotado ou pela extensão do VS Code. Os três falam com o mesmo daemon, e o daemon responde a partir da autoridade do grafo, em vez de reler a árvore. O kin-vfs projeta esse mesmo grafo de volta por chamadas comuns de sistema de arquivos, para que editores, compiladores e sistemas de build continuem vendo arquivos. O Git fica ao lado do grafo como uma fronteira de importação e exportação, em vez de um caminho de resposta, e o KinLab é a camada hospedada sobre a mesma autoridade.

flowchart TD
    people["Humans and AI agents"]

    subgraph surfaces["Access surfaces"]
        cli["kin CLI"]
        mcp["Kin MCP server"]
        editor["kin-editor for VS Code"]
    end

    daemon["kin daemon"]
    authority["Graph authority<br/>entities, relations, changes, provenance"]
    db["kin-db<br/>graph storage, snapshots,<br/>index, text and vector search"]
    prims["kin-model, kin-blobs, kin-search,<br/>kin-vector, kin-infer, kin-lsp"]
    vfs["kin-vfs<br/>transparent file projection"]
    tools["Editors, compilers, build systems"]
    git["Git<br/>import and export boundary"]
    kinlab["KinLab<br/>hosted collaboration and control plane"]

    people --> cli
    people --> mcp
    people --> editor
    cli --> daemon
    mcp --> daemon
    editor --> daemon
    daemon --> authority
    authority --> db
    db --> prims
    authority <-->|"kin init imports, kin git export"| git
    authority -->|"publish and sync"| kinlab
    authority --> vfs
    vfs --> tools

Abaixo dessas superfícies estão as camadas a partir das quais o sistema é construído:

São camadas de implementação de um único sistema, não produtos separados que um novo usuário precisa montar. Nenhuma delas é instalada separadamente.

Open source e o ecossistema Kin

O núcleo do Kin é open source sob Apache-2.0: kin, kin-db, kin-vfs e kin-editor, além das bibliotecas de suporte kin-model, kin-blobs, kin-search, kin-vector, kin-infer, kin-lsp e kin-actions.

KinLab é um produto proprietário construído sobre esse núcleo aberto: a camada hospedada de colaboração e plano de controle descrita acima.

A mesma fronteira se aplica a como o trabalho de benchmark é compartilhado. A especificação do benchmark e um verificador de pacotes autônomo e sem dependências são públicos, para que uma afirmação possa ser verificada sem acesso ao sistema que a produziu. O runner e a infraestrutura de prova que produzem pacotes de evidência selados (a orquestração, o portão de prova de versão fixada e o ambiente de medição hospedado) permanecem privados por enquanto. A especificação e o verificador abrem primeiro; o runner pode abrir depois.

Caminho mais curto com suporte de grafo

1. Instale e configure o Kin

No macOS ou Linux:

curl -fsSL https://get.kinlab.dev/install | sh
exec "$SHELL" -l
kin setup --intent agent

O instalador resolve a última versão estável, verifica o checksum SHA-256 publicado, instala os binários gerenciados em ~/.kin e inicia o setup. Executar a intenção explícita agent configura o servidor MCP embutido para clientes suportados detectados. Use --intent local para uso de CLI e sistema de arquivos sem configuração de MCP, ou --intent editor para o caminho do VS Code.

Para remover apenas as integrações gerenciadas pelo setup, execute kin setup uninstall. Para a raiz gerenciada padrão (~/.kin), kin setup uninstall --all também interrompe todos os daemons do Kin, remove blocos exatos de PATH de instaladores legados e exclui recursivamente a instalação gerenciada (--dry-run a pré-visualiza). Um KIN_HOME personalizado nunca é removido recursivamente: primeiro execute o uninstall com escopo de ledger, depois revise e remova esse diretório explicitamente. Fatias modificadas de propriedade do setup bloqueiam a remoção completa a menos que você adicione --force, então o uninstall nunca sobrescreve silenciosamente a configuração de cliente ou shell editada pelo usuário. No Windows, a CLI agenda a exclusão do diretório de instalação bloqueado imediatamente após a saída do processo em execução. O Windows retém intencionalmente um sidecar inerte de autoridade irmã, restrito ao usuário atual; manter essa identidade de bloqueio estável impede que uma falha ou uma instalação futura concorrente crie duas autoridades de mutação independentes. A CLI e o resultado JSON divulgam esses metadados de coordenação retidos em vez de alegar zero bytes residuais.

Para instalação manual, cada arquivo e seu arquivo .sha256 são publicados em https://github.com/firelock-ai/kin/releases/latest/download/. Os nomes dos artefatos que acompanham o último release são kin-macos-aarch64, kin-macos-x86_64, kin-linux-aarch64, kin-linux-x86_64 e kin-windows-x86_64; use o sufixo .tar.gz mostrado na página do último release. O Windows também publica kin-windows-x86_64.zip, que é o que o instalador PowerShell e o launcher npm baixam.

O ponto de entrada npm resolve o mesmo canal público de releases:

npm install -g @kinlab/kin@latest

Um tap do Homebrew acompanha o mesmo canal de releases:

brew install firelock-ai/kin/kin

A fórmula do tap é gerada em vez de mantida manualmente. Sua versão e seu SHA-256 por plataforma são regenerados a partir de cada release do Kin por update-formula.yml no repositório do tap, em um dispatch que o próprio release envia, com uma reconciliação a cada seis horas que se autocorrige quando uma é perdida. É por isso que o checksum que o Homebrew verifica é o publicado ao lado do arquivo, em vez de uma cópia curada separadamente. Confirme o que você instalou com kin --version, como deve fazer em qualquer caminho de instalação.

No Windows, execute irm https://get.kinlab.dev/install.ps1 | iex no PowerShell. O suporte nativo a Windows x86_64 está em fase inicial. A admissão de repositórios funciona: kin init importa um repositório Git e publica a autoridade do grafo, e consultas de grafo, lexicais e com suporte do daemon respondem nativamente. A projeção transparente de sistema de arquivos não é entregue no Windows, e a prova de instalação ponta a ponta ainda não cobre fluxos de trabalho de MCP ou revisão lá, então o WSL2 continua sendo o caminho recomendado para a experiência completa do Kin. Leia Plataforma e maturidade abaixo antes de escolher um caminho de instalação no Windows.

2. Admita um repositório existente como verdade do grafo

cd /path/to/your/repository
kin init .

Em um repositório Git detectado, kin init admite atomicamente o histórico alcançável completo, refs, objetos brutos, a árvore exata do workspace e a política de admissão na autoridade de grafo repository-v6. Um worktree com edições não commitadas, alterações em stage ou arquivos não rastreados ainda é admitido: kin init admite o estado commitado e divulga o que não admitiu. Ele nunca substitui um snapshot exato de HEAD nem uma reconstrução semântica bruta do sistema de arquivos. URLs de remoto suportadas e locais ao repositório, refspecs, rastreamento de branches e padrões de push são selados na configuração de coexistência do Kin com o Git; configurações de transferência inseguras, ambíguas ou não suportadas falham fechadas antes da publicação.

A admissão também deriva a camada semântica de entidades e relações para cada arquivo-fonte de entidade suportado nesse histórico, e kin init reporta as contagens duráveis e vinculadas à geração que commitou. kin status reporta essa visão de autoridade do repositório; kin graph status reporta separadamente o grafo de consulta vivo e mutável do daemon, que pode incluir enriquecimento derivado posteriormente. As superfícies de consulta consomem o enriquecimento de propriedade do grafo quando ele existe e reportam a sua ausência em vez de esconder a lacuna atrás da busca bruta de arquivos.

Quais arquivos se tornam entidades

"Arquivo-fonte de entidade suportado" significa um arquivo que um dos adaptadores de linguagem do Kin reivindica. O registro de adaptadores é o conjunto completo, e todo arquivo em um repositório é resolvido por meio dele:

Um cabeçalho .h é lido como C++ quando seu conteúdo assim indica, então um projeto C++ não perde namespaces e templates para a gramática de C.

Todo o resto é admitido como conteúdo e permanece consultável como histórico e texto, mas não é parseado em entidades e relações. Isso inclui Markdown, HTML e CSS, SQL, YAML, JSON e TOML, scripts de shell, Objective-C, Scala, Elixir, Dart, Lua, R, Zig, Haskell e Nix. Se a sua linguagem está nessa lista, locate e refs não encontrarão símbolos nela.

3. Faça uma pergunta real ao grafo

kin locate "where are webhook retries handled"
kin refs ExactEntityName
kin trace ExactEntityName

Substitua ExactEntityName por um símbolo retornado por locate. locate encontra as entidades relevantes a uma intenção, refs mostra chamadores/importadores e referências de propriedade do grafo, e trace retorna a entidade focal mais o contexto semântico próximo. Depois que os embeddings estiverem completos, seu agente de IA configurado pode usar a ferramenta semantic_locate com suporte vetorial; get_context_pack, find_references e trace_data_flow expõem a vizinhança do grafo diretamente.

A admissão deriva as entidades semânticas, não seus vetores. Execute kin embed para adicionar similaridade vetorial local sobre elas e confirme a cobertura com kin graph status.

Revise uma alteração escrita por IA

IA escreve código. Kin prova o que mudou.

Execute kin init no branch que você quer revisar para que o histórico Git relevante esteja no grafo e então passe SHAs de commit explícitos para o shadow gate somente de relatório:

kin review shadow "$(git rev-parse main)..$(git rev-parse HEAD)"

O resultado é PASS, NEEDS ATTENTION ou WOULD BLOCK, e ele vem com o impacto que o Kin derivou do grafo, o contexto necessário para repará-lo e a evidência por trás de ambos. A autoria é declarada, não verificada. O comando não bloqueará seu merge nem alterará o estado do grafo. Ele entrega a evidência a um humano ou a uma política de CI e para por aí.

Como o Kin se relaciona com o Git

Ao lado do Git hoje. Autoridade de repositório ao longo do tempo. Durante a adoção brownfield, o Git permanece uma fronteira explícita de interoperabilidade de importação/exportação; ele nunca responde consultas de runtime do Kin nem repara a verdade de grafo ausente.

• kin init importa o histórico Git alcançável completo e arestas de pai exatas. O Kin deliberadamente não tem modo de inicialização de histórico parcial ou somente snapshot.
• Após a importação, o grafo do Kin é dono da identidade do repositório, do estado da árvore, do histórico, das refs e das relações semânticas. As visões de sistema de arquivos e Git são projeções.
• kin git export --output ../repo.git escreve uma nova projeção Git bare a partir de uma geração de autoridade de propriedade do grafo. Ele não consulta arquivos de trabalho nem um object store .git/ ambiente, e recusa um destino existente ou dentro do repositório. Objetos, refs e diretórios são descarregados antes que a publicação sem substituição no destino seja reconhecida. A publicação ancorada em capacidade está disponível atualmente em hosts Unix; outros hosts recusam antes de criar a exportação.

Isso permite que uma equipe migre um repositório existente sem abrir mão de seu editor, compilador, sistema de build ou interoperabilidade com o Git enquanto o Kin se torna autoritativo.

Plataforma e maturidade

O runtime principal e a projeção de sistema de arquivos têm fronteiras de suporte diferentes:

A primeira indexação lê todo o histórico Git alcançável, então kin init em um repositório grande ou de longa vida leva minutos, não segundos, antes que o embedding comece. Depois que init retorna, o daemon continua preparando em segundo plano, e as primeiras chamadas de agente em um repositório grande podem demorar visivelmente mais para responder.

Testes arm64 limitados constataram que o caminho principal de grafo e lexical é utilizável com 512 MB, mas o embedding completo baixa um modelo de aproximadamente 522 MB e atualmente precisa de 2 GB como piso seguro de operação; 1 GB é uma borda insegura e 512 MB pode terminar durante o embedding. Essas são restrições observadas de alpha, não promessas universais de dimensionamento.

Um kin --version bem-sucedido estabelece apenas que o binário principal roda. Ele não estabelece compatibilidade de VFS nem uma projeção viva com suporte de grafo. Em um host Unix suportado, use kin setup status, kin-vfs status --workspace . e um lançamento real de kin-vfs exec --workspace . -- <command>. O launcher do VFS inclui um canário de interposição e reporta quando o sistema operacional remove o shim. O README do kin-vfs contém a fronteira completa.

Os artefatos de release são publicados com checksum e o workflow de release executa instalação anônima, verificações de daemon/MCP, de embedding e de projeção VFS real com suporte de grafo em sua matriz de runners suportados. O próprio workflow é público: Install Proof. Um release verde estabelece exatamente esses artefatos e ambientes; não é uma alegação de que toda distribuição, ferramenta ou formato de repositório já está coberto.

Postura de prova

O pacote de prova Go Multi-SWE-Bench pré-registrado publicado está fixado em um build mais antigo, não na última release móvel, e não estabelece uma alegação ampla de velocidade, economia de tokens ou vitória de categoria. Resultados comparativos são omitidos aqui até verificação independente.

Leia a metodologia, o conjunto de tarefas, a identidade do build e os artefatos no pacote de prova público. Trate alegações fora desse escopo medido como hipóteses até que tenham sua própria prova reproduzível.

Aprenda e contribua

• Quickstart e configuração avançada
• Tamanho do store e o que o determina
• Referência de ferramentas MCP
• Suporte a linguagens e o que cada nível extrai
• Referência de variáveis de ambiente
• Tese graph-first
• Modelo de autoridade de escrita e seu estado transitório
• Discussões no GitHub
• Relatórios de bugs e pedidos de recursos
• Guia de contribuição
• Relato privado de segurança

Licença

Apache-2.0.

Software que se lembra de si mesmo.