kin v0.4.5

Gli agenti IA possono scrivere una modifica più velocemente di quanto un team possa stabilire cosa tocca, se annulla una correzione precedente e quanto lontano arrivano le sue conseguenze. Git registra file e cronologia delle righe. Kin registra il software stesso come un grafo di entità, relazioni, modifiche e provenienza, poi offre a umani e agenti un'unica autorità semantica da interrogare e revisionare. Cosa tocca una modifica emerge prima che venga integrata, e gli agenti lavorano da un contesto esatto invece di rileggere il repository.

Kin è il sistema semantico di registrazione per software scritto da IA. È un'alpha iniziale, utilizzabile oggi come CLI locale, daemon, server MCP, superficie di revisione e proiezione del filesystem basata su grafo. È pre-1.0, quindi aspettati spigoli e modifiche di rottura. Vedi la versione stabile più recente e le limitazioni attuali prima di adottarlo in un flusso di lavoro critico.

Vedilo su un repository reale

Una modifica di firma su una sola riga in ripgrep sembra innocua nel diff. Chiedi a kin impact a riguardo, prima che qualsiasi compilatore venga eseguito, e nomina cosa raggiunge la modifica. I chiamanti della firma modificata vengono prima, poi tutto ciò che quei chiamanti trascinano dietro di sé.

Registrato su un grafo preparato al commit di ripgrep e89fff89ac9af12e8d4ce9d5fd07beb408ca730f. Una modifica di firma su una riga, e Kin fa emergere le entità che tocca prima che un compilatore venga eseguito. Il grafo è stato costruito in precedenza. Nessun compilatore è stato eseguito. Comandi esatti: kinlab.ai/proof. La directory di esecuzione grezza non è ancora pubblica, quindi questa è una ricetta che puoi rieseguire, non una traccia che puoi verificare.

Kin fa emergere cosa tocca la modifica. Se la modifica sia corretta resta a carico del tuo compilatore, dei test e della revisione. Il grafo viene costruito in anticipo da kin init, e costruirlo è la parte costosa; dopo di che, le domande sull'impatto vengono risposte dalla verità del grafo, non rileggendo l'albero.

Lo stack

Kin è un unico sistema con alcune superfici pubbliche chiare:

Come si incastrano i pezzi

Kin è il sistema semantico di registrazione per software scritto da IA, e tutto nella mappa qui sotto o raggiunge quell'autorità o la supporta. Umani e agenti IA entrano tramite la CLI, il server MCP integrato o l'estensione VS Code. Tutti e tre interrogano lo stesso daemon, e il daemon risponde dall'autorità del grafo piuttosto che rileggendo l'albero. kin-vfs proietta lo stesso grafo di nuovo attraverso normali chiamate al filesystem, così che editor, compilatori e sistemi di build continuino a vedere i file. Git si affianca al grafo come confine di importazione ed esportazione piuttosto che come percorso di risposta, e KinLab è il livello ospitato sulla stessa autorità.```mermaid 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

Sotto quelle superfici ci sono i layer su cui è costruito il sistema:

| Layer | Ruolo |
| --- | --- |
| **[kin-db](https://github.com/firelock-ai/kin-db)** | Archiviazione a grafo, snapshot, indicizzazione, ricerca testuale e ricerca vettoriale. |
| **[kin-model](https://github.com/firelock-ai/kin-model)** | Tipi canonici e modelli di dominio condivisi in tutto lo stack. |
| **[kin-blobs](https://github.com/firelock-ai/kin-blobs)** | Archiviazione di blob con indirizzamento per contenuto. |
| **[kin-search](https://github.com/firelock-ai/kin-search)** | Primitive di ricerca lessicale e recupero a fasi. |
| **[kin-vector](https://github.com/firelock-ai/kin-vector)** | Substrato vettoriale e dei nearest-neighbor. |
| **[kin-infer](https://github.com/firelock-ai/kin-infer)** | Substrato di inferenza ed embedding. |
| **[kin-lsp](https://github.com/firelock-ai/kin-lsp)** | Arricchimento tramite language-server che alimenta il layer semantico. |

Questi sono layer di implementazione di un unico sistema, non prodotti separati
che un nuovo utente deve assemblare. Nessuno di essi viene installato separatamente.

## Open source ed ecosistema Kin

Il nucleo di Kin è open source con licenza Apache-2.0: [kin](https://github.com/firelock-ai/kin),
[kin-db](https://github.com/firelock-ai/kin-db), [kin-vfs](https://github.com/firelock-ai/kin-vfs),
e [kin-editor](https://github.com/firelock-ai/kin-editor), oltre alle librerie di
supporto kin-model, kin-blobs, kin-search, kin-vector, kin-infer, kin-lsp e
kin-actions.

[KinLab](https://kinlab.ai) è un prodotto proprietario costruito su questo nucleo
open: il layer di collaborazione e control-plane ospitato descritto sopra.

Lo stesso confine si applica alla condivisione del lavoro di benchmark. La
[specifica di benchmark e un verifier standalone e senza dipendenze](https://github.com/firelock-ai/kin-bench-spec)
sono pubblici, così un'affermazione può essere verificata senza accesso al sistema
che l'ha prodotta. Il runner e l'infrastruttura di prova che generano bundle di
evidenze sigillate (l'orchestrazione, il proof gate delle release bloccate e
l'ambiente di misurazione ospitato) restano privati per ora. La spec e il verifier
si aprono per primi; il runner può aprirsi in seguito.

## Percorso più breve basato su grafo

### 1. Installare e configurare Kin

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

L'installer risolve l'ultima versione stabile, ne verifica il checksum SHA-256 pubblicato, installa i binari gestiti in ~/.kin e avvia la configurazione. L'esecuzione dell'intento esplicito agent configura il server MCP integrato per i client supportati rilevati. Usa --intent local per l'uso da CLI e filesystem senza configurazione MCP, oppure --intent editor per il percorso di VS Code.

Per rimuovere solo le integrazioni gestite dalla configurazione, esegui kin setup uninstall. Per la root gestita predefinita (~/.kin), kin setup uninstall --all arresta anche tutti i daemon di Kin, rimuove i blocchi PATH esatti del vecchio installer e cancella ricorsivamente l'installazione gestita (--dry-run ne mostra l'anteprima). Una KIN_HOME personalizzata non viene mai rimossa ricorsivamente: esegui prima la disinstallazione limitata al ledger, poi controlla e rimuovi esplicitamente quella directory. Le sezioni modificate di proprietà della configurazione bloccano la rimozione completa a meno che non aggiungi --force, quindi la disinstallazione non sovrascrive mai silenziosamente la configurazione del client o della shell modificata dall'utente. Su Windows, la CLI pianifica l'eliminazione della propria directory di installazione bloccata immediatamente dopo l'uscita del processo in esecuzione. Windows conserva intenzionalmente un sidecar di autorità gemello inerte, visibile solo all'utente corrente; mantenere stabile quell'identità di blocco impedisce a un crash o a una futura installazione concorrente di creare due autorità di mutazione indipendenti. La CLI e il risultato JSON rivelano questi metadati di coordinamento conservati anziché dichiarare zero byte residui.

Per l'installazione manuale, ogni archivio e il relativo file .sha256 sono pubblicati in https://github.com/firelock-ai/kin/releases/latest/download/. I nomi degli asset mobili sono kin-macos-aarch64, kin-macos-x86_64, kin-linux-aarch64, kin-linux-x86_64 e kin-windows-x86_64; usa il suffisso .tar.gz per gli archivi macOS e Linux e il suffisso .zip per Windows, come mostrato nella pagina dell'ultima release. Lo zip di Windows è anche ciò che l'installer PowerShell e il launcher npm scaricano.

Il punto di ingresso npm risolve lo stesso canale di release pubblico:```sh npm install -g @kinlab/kin@latest

Una installazione globale richiede un prefisso npm scrivibile. Quando il prefisso è di proprietà di root e tu
non sei root, npm rifiuta con `EACCES: permission denied, mkdir
'/usr/local/lib/node_modules/@kinlab'` prima ancora che Kin venga eseguito, che è il caso usuale
all'interno di un container il cui utente predefinito non è root. Usa il percorso zero-install,
`npx -y @kinlab/kin setup --intent agent --no-interactive`, oppure sposta il prefisso in una posizione
di tua proprietà e aggiungilo al tuo `PATH`:```sh
npm config set prefix ~/.npm-global
export PATH="$HOME/.npm-global/bin:$PATH"   # add this to your shell profile too
npm install -g @kinlab/kin@latest

Un prefisso utente è sul PATH della tua shell interattiva e da nessun'altra parte. Gli script, i passaggi CI, docker exec e i client agent non lo ereditano, quindi fornisci loro il percorso assoluto al binario piuttosto che un semplice kin. Vedi Funziona con il tuo agente per la forma di registrazione.

Un tap Homebrew tiene traccia dello stesso canale di rilascio:```sh brew install firelock-ai/kin/kin

La formula del tap è generata piuttosto che mantenuta a mano. La sua versione e il suo
SHA-256 per piattaforma vengono rigenerati da ogni release di Kin da
`update-formula.yml` nel repository del tap, su un dispatch che la release stessa
invia, con una riconciliazione ogni sei ore che auto-ripara un evento mancato. Ecco perché il
checksum che Homebrew verifica è quello pubblicato accanto all'archivio piuttosto che una
copia curata separatamente. Conferma ciò che hai installato con `kin --version`,
come dovresti fare su qualsiasi percorso di installazione.

Su Windows, esegui `irm https://get.kinlab.dev/install.ps1 | iex` in PowerShell.
Il supporto nativo per Windows x86_64 è iniziale. L'ammissione del repository funziona: `kin init` importa un repository Git e pubblica l'autorità del grafo, e le query basate su grafo, lessico e daemon rispondono nativamente. La proiezione trasparente del filesystem non è disponibile su Windows, e la prova di installazione end-to-end non copre ancora i flussi di lavoro MCP o di review lì, quindi WSL2 rimane il percorso consigliato per l'esperienza Kin completa.
Leggi [Piattaforma e maturità](#platform-and-maturity) qui sotto prima di scegliere un
percorso di installazione su Windows.

### 2. Ammettere un repository esistente come verità del grafo```sh
cd /path/to/your/repository
kin init .

In un repository Git rilevato, kin init ammette atomicamente l'intera storia raggiungibile, i ref, gli oggetti grezzi, l'albero di lavoro esatto e la policy di ammissione nell'autorità del grafo repository-v6. Un worktree con modifiche non committate, modifiche in staging o file non tracciati viene comunque ammesso: kin init ammette lo stato committato e rivela ciò che non ha ammesso. Non sostituisce mai uno snapshot esatto-HEAD o una ricostruzione semantica raw-filesystem. Gli URL remote supportati a livello di repository, i refspec, il branch tracking e i default di push vengono sigillati nella configurazione di coesistenza Git di Kin; le impostazioni di trasferimento non sicure, ambigue o non supportate falliscono in modo chiuso prima della pubblicazione.

L'ammissione deriva anche il livello di entità e relazioni semantiche per ogni file sorgente di entità supportato in quella storia, e kin init riporta i conteggi durabili e legati alla generazione che ha committato. kin status riporta quella vista di autorità del repository; kin graph status riporta separatamente il grafo di query live e mutabile del daemon, che può includere arricchimenti derivati successivamente. Le superfici di query consumano l'arricchimento di proprietà del grafo quando esiste e ne riportano l'assenza invece di nascondere il divario dietro la ricerca di file grezzi.

Quali file diventano entità

"File sorgente di entità supportato" significa un file che uno degli adapter linguistici di Kin rivendica. Il registro degli adapter è l'insieme completo, e ogni file in un repository viene risolto attraverso di esso:

Un header .h viene letto come C++ quando il suo contenuto lo indica, quindi un progetto C++ non perde namespace e template a favore della grammatica C.

Tutto il resto viene ammesso come contenuto e rimane interrogabile come storia e testo, ma non viene analizzato in entità e relazioni. Questo include Markdown, HTML e CSS, SQL, YAML, JSON e TOML, script shell, Objective-C, Scala, Elixir, Dart, Lua, R, Zig, Haskell e Nix. Se il tuo linguaggio è in quella lista, locate e refs non troveranno simboli in esso.

3. Fai una domanda reale al grafo```sh

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

Sostituisci `ExactEntityName` con un simbolo restituito da `locate`. `locate` trova le
entità rilevanti per un intento, `refs` mostra i chiamanti/importatori di proprietà del grafo e
i riferimenti, e `trace` restituisce l'entità focale più il contesto semantico circostante.
Una volta completati gli embedding, il tuo agente AI configurato può usare lo strumento
`semantic_locate` basato su vettori; `get_context_pack`, `find_references` e
`trace_data_flow` espongono direttamente il vicinato del grafo.

L'ammissione deriva le entità semantiche, non i loro vettori. Esegui `kin embed` per
aggiungere similarità vettoriale locale su di esse e conferma la copertura con
`kin graph status`.

## Funziona con il tuo agente

Kin include il proprio agente, ed è il percorso che raccomandiamo per il lavoro con gli agenti. `kin
agent run` guida qualsiasi endpoint compatibile con OpenAI, quindi un modello locale in LM Studio,
Ollama, llama.cpp o vLLM funziona con gli stessi flag di uno ospitato, e
raggiunge il grafo tramite lo stesso server MCP usato da ogni altro client.```sh
kin agent run --task "Find where the retry backoff is computed and document it" \
  --model qwen/qwen3.6-35b-a3b --base-url http://localhost:1234/v1

Ciò che lo distingue dal puntare un altro agente al server MCP è che la regola viene applicata all'interno dell'agente piuttosto che presa in prestito dal livello di autorizzazione di un fornitore. Ha gli strumenti di Kin più esattamente due locali, edit_file e write_file. Non c'è shell, né grep né strumento di lettura file, quindi non può rispondere a una domanda sul repository da una ricerca grezza di file, e uno strumento che inventa viene rifiutato per nome. Quando Kin segnala che un risultato vuoto non può essere considerato attendibile, all' agente viene detto che la risposta è sconosciuta e viene indicato il divario nominato invece di concludere che la cosa non esiste. Ogni modifica viene eseguita all'interno di una transazione Kin sotto una sessione Kin, quindi la modifica porta una provenienza che nomina l'agente. Esegui kin agent doctor --base-url <url> prima per verificare che entrambe le metà rispondano. Vedi il riferimento CLI per la superficie completa.

Lavorare con Claude Code, Codex, Cursor, Gemini e qualsiasi altra cosa che parli MCP rimane di prima classe. kin setup --intent agent configura ogni client che rileva in un unico passaggio. Questi sono i comandi one-liner per singolo client quando preferisci installare Kin direttamente.

Claude Code, dall'interno di una sessione:``` /plugin marketplace add firelock-ai/kin /plugin install kin@kin

Codex:```sh
codex plugin marketplace add firelock-ai/kin
codex plugin add kin@kin

Gemini CLI:```sh gemini extensions install https://github.com/firelock-ai/kin

Incolla questo link di installazione con un clic in Cursor o nella barra degli indirizzi del tuo browser:```
cursor://anysphere.cursor-deeplink/mcp/install?name=kin&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIkBraW5sYWIva2luLW1jcCJdfQ==

Kiro accetta la stessa cosa di un collegamento web: Aggiungi Kin a Kiro.

Cline accetta la voce standard qui sotto piuttosto che una riga singola. La sua CLI legge ~/.cline/mcp.json. Nell'estensione VS Code, apri il pannello MCP Servers, poi la scheda Configure, poi Configure MCP Servers, e aggiungi la voce lì.

Ogni altro client che legge una configurazione MCP standard accetta questa voce:```json { "mcpServers": { "kin": { "command": "npx", "args": ["-y", "@kinlab/kin-mcp"] } } }

Il wrapper richiede Node 20 o versioni successive e, al primo avvio, scarica la
release di Kin corrispondente, verifica il suo SHA-256 pubblicato e memorizza nella cache i binari per
utente. Codex CLI vuole la stessa cosa in TOML sotto `[mcp_servers.kin]`.

Un avvertimento che vale la pena ripetere: questi strumenti rispondono dal grafo, quindi il repository
deve essere ammesso con `kin init .` e incorporato con `kin embed` prima che
`semantic_locate` possa classificare qualsiasi cosa. [llms-install.md](https://github.com/firelock-ai/kin/blob/main/llms-install.md) è l'intero
percorso scritto in modo che un agente possa seguirlo senza supervisione, da una macchina vuota a una
prima chiamata di strumento verificata.

## Rivedere una modifica scritta dall'IA

**L'IA scrive codice. Kin dimostra cosa è cambiato.**

Esegui `kin init` sul ramo che vuoi rivedere così che la cronologia Git pertinente sia nel
grafo, poi passa SHA di commit espliciti al gate shadow solo-report:```sh
kin review shadow "$(git rev-parse main)..$(git rev-parse HEAD)"

Il risultato è PASS, NEEDS ATTENTION o WOULD BLOCK, e arriva con l'impatto Kin derivato dal grafo, il contesto necessario per ripararlo, e le prove dietro entrambi. La paternità è dichiarata, non verificata. Il comando non bloccherà il tuo merge né modificherà lo stato del grafo. Consegna le prove a un essere umano o a una policy CI e si ferma lì.

Come Kin si relaziona a Git

Accanto a Git oggi. Autorità del repository nel tempo. Durante l'adozione in contesti brownfield, Git rimane un confine esplicito di interoperabilità import/export; non risponde mai alle query runtime di Kin né ripara la verità mancante del grafo.

• kin init importa l'intera storia Git raggiungibile e gli archi padre esatti. Kin deliberatamente non ha una modalità di inizializzazione a storia parziale o solo snapshot.
• Dopo l'importazione, il grafo di Kin possiede identità del repository, stato dell'albero, storia, ref e relazioni semantiche. Le viste filesystem e Git sono proiezioni.
• kin git export --output ../repo.git scrive una nuova proiezione Git bare da una generazione di autorità posseduta dal grafo. Non consulta i file di lavoro né un object store .git/ ambientale, e rifiuta una destinazione esistente o interna al repository. Oggetti, ref e directory vengono scaricati prima che la pubblicazione della destinazione senza sostituzione venga riconosciuta. La pubblicazione ancorata alle capability è attualmente disponibile su host Unix; altri host rifiutano prima di creare l'export.

Questo consente a un team di migrare un repository esistente senza rinunciare al proprio editor, compilatore, sistema di build o interoperabilità Git mentre Kin diventa autorevole.

Piattaforma e maturità

Il runtime core e la proiezione filesystem hanno confini di supporto diversi:

Il grafo è l'autorità in ogni caso sopra. Lo shim, un mount NFS, un mount FUSE e Windows ProjFS sono quattro modi per vedere quella verità come file, e Kin sceglie tra loro sondando cosa questo host può eseguire: un mount dove disponibile, perché il kernel lo serve e nessun processo può rimuoverlo, con lo shim iniettato come fallback di compatibilità su macOS e Linux e ProjFS in testa su Windows, dove non esiste shim. kin vfs on attiva quello scelto, kin vfs off lo disattiva, e kin doctor riporta una riga che indica quale è in vigore e se funziona. Dove una modalità manca, Kin stampa la riga esatta che la installa o la abilita per la tua piattaforma. docs/projection.md contiene la tabella completa per piattaforma.

La prima indicizzazione legge l'intera storia Git raggiungibile, quindi kin init su un repository grande o longevo richiede minuti, non secondi, prima che inizi l'embedding. Dopo che init restituisce, il daemon continua a prepararsi in background, e le prime chiamate agente su un repository grande possono richiedere notevolmente più tempo per rispondere.

Test arm64 limitati hanno trovato il grafo core e il percorso lessicale utilizzabili a 512 MB, ma il download completo dell'embedding richiede un modello di circa 522 MB e attualmente necessita di 2 GB come minimo operativo sicuro; 1 GB è un limite pericoloso e 512 MB può terminare durante l'embedding. Questi sono vincoli alpha osservati, non promesse universali di dimensionamento.

Un kin --version riuscito stabilisce solo che il binario core gira. Non stabilisce la compatibilità VFS né una proiezione viva basata sul grafo. Su un host Unix supportato, usa kin vfs status, che sonda ogni modalità di proiezione e stampa cosa è effettivamente in vigore, poi kin setup status e un vero lancio kin-vfs exec --workspace . -- <comando>. Il launcher VFS include un canary di interposizione e segnala quando il sistema operativo rimuove lo shim. Il README di kin-vfs contiene il confine completo.

Gli asset di rilascio sono pubblicati con checksum e il flusso di lavoro di rilascio esegue installazione anonima, controlli daemon/MCP, embedding e proiezione VFS reale basata sul grafo attraverso la sua matrice di runner supportati. Il flusso di lavoro stesso è pubblico: Install Proof. Un rilascio verde stabilisce quegli artefatti e ambienti esatti; non è un'affermazione che ogni distribuzione, strumento o forma di repository sia già coperta.

FAQ

Kin sostituisce Git?

Accanto a Git oggi. Autorità del repository nel tempo. Git rimane un confine esplicito di interoperabilità import/export durante l'adozione brownfield, quindi un team può migrare un repository esistente senza rinunciare al proprio editor, compilatore, sistema di build o interoperabilità Git.

Il mio codice lascia la mia macchina?

Kin mantiene il lavoro del repository locale nel tuo ambiente, quindi l'ingestione del repository, l'archiviazione del grafo e le query locali girano tutte lì. KinLab è un prodotto separato che aggiunge collaborazione ospitata sotto accordi espliciti di accesso e accesso anticipato.

Con quali agenti funziona?

Funzionare con Claude Code, Codex, Cursor, Gemini e qualsiasi altra cosa che parli MCP rimane di prima classe. kin setup --intent agent configura ogni client che rileva in un unico passaggio.

Blocca un merge?

La review è consultiva, quindi segnala il rischio senza bloccare e la decisione di merge rimane al tuo team. kin review shadow consegna le prove a un essere umano o a una policy CI e si ferma lì.

Postura di prova

Il pacchetto di prova pubblicato e preregistrato Multi-SWE-Bench Go è ancorato a una build più vecchia, non all'ultimo rilascio in movimento, e non stabilisce un'ampia affermazione di velocità, risparmio di token o vittoria di categoria. I risultati comparativi sono trattenuti qui in attesa di verifica indipendente.

Leggi la metodologia, il set di attività, l'identità della build e gli artefatti nel pacchetto di prova pubblico. Tratta le affermazioni al di fuori di quell'ambito misurato come ipotesi finché non hanno la propria prova riproducibile.

Scrittura

Note di ingegneria dalla costruzione di Kin, scritte così uno sconosciuto può riutilizzarle, vivono su kinlab.ai/blog con un feed su kinlab.ai/rss.xml.

• Il check che è passato perché non misurava nulla
• La tua ricerca di codice dice che nulla lo usa. Puoi eliminarlo?

Impara e contribuisci

• Quickstart e configurazione avanzata
• Dimensione dello store e cosa la determina
• Riferimento strumenti MCP
• Supporto linguistico e cosa estrae ogni livello
• Riferimento variabili d'ambiente
• Tesi graph-first
• Modello di autorità di scrittura e il suo stato transitorio
• GitHub Discussions
• Segnalazioni di bug e richieste di funzionalità
• Guida ai contributi
• Segnalazione privata di sicurezza

Licenza

Apache-2.0.

Software che ricorda se stesso.