kin v0.5.0

Gli agenti di IA possono scrivere una modifica più velocemente di quanto un team riesca a stabilire cosa essa tocchi, se annulli una correzione precedente e quanto lontano arrivino 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 esseri umani e agenti un'unica autorità semantica da interrogare e revisionare. Ciò che una modifica tocca emerge prima che venga integrata, e gli agenti lavorano partendo da un contesto esatto invece di rileggere il repository.

Kin è il sistema semantico di registrazione per software scritto da IA. È un'alpha pubblica, utilizzabile oggi come CLI locale, daemon, server MCP, superficie di revisione e proiezione del filesystem basata su grafo. È pre-1.0, quindi aspettati spigoli non levigati e modifiche incompatibili (breaking changes). Consulta l'ultima release stabile e le limitazioni attuali prima di adottarlo in un flusso di lavoro critico.

Provalo su un repository reale

Una modifica di una riga alla firma (signature) in ripgrep sembra innocua nel diff. Chiedi a kin impact informazioni a riguardo, prima che venga eseguito qualsiasi compilatore, e ti dirà cosa tocca la modifica. I chiamanti della firma modificata vengono per primi, poi tutto ciò che quei chiamanti si trascinano dietro.

Registrato su un grafo preparato al commit di ripgrep e89fff89ac9af12e8d4ce9d5fd07beb408ca730f. 13 entità impattate entro 3 hop, inclusi 3 chiamanti diretti della firma modificata. Il grafo è stato costruito in anticipo. Nessun compilatore è stato eseguito. Comandi esatti: kinlab.ai/proof. La directory grezza di esecuzione 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 compito 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 ricevono risposta dalla verità del grafo, non rileggendo l'albero.

I componenti

Kin è un unico sistema con alcune superfici pubbliche ben definite:

Come si integrano i componenti

Kin è il sistema semantico di registrazione per software scritto da IA, e tutto nella mappa sottostante raggiunge quell'autorità o la supporta. Esseri umani e agenti di IA accedono tramite CLI, il server MCP integrato o l'estensione per VS Code. Tutti e tre interrogano lo stesso daemon, e il daemon risponde dall'autorità del grafo piuttosto che rileggendo l'albero. kin-vfs riproietta lo stesso grafo attraverso ordinarie chiamate al filesystem, così editor, compilatori e sistemi di build continuano a vedere i file. Git sta accanto al grafo come confine di importazione ed esportazione, non come percorso di risposta, e KinLab è il livello ospitato sopra la stessa autorità.

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 queste superfici ci sono i livelli da cui il sistema è costruito:

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

Open source e l'ecosistema Kin

Il nucleo di Kin è open source con licenza Apache-2.0: kin, kin-db, kin-vfs e kin-editor, più le librerie di supporto kin-model, kin-blobs, kin-search, kin-vector, kin-infer, kin-lsp e kin-actions.

KinLab è un prodotto proprietario costruito su questo nucleo open source: il livello ospitato di collaborazione e piano di controllo descritto sopra.

Lo stesso confine si applica alla condivisione del lavoro sui benchmark. La specifica del benchmark e un verificatore di bundle autonomo e senza dipendenze sono pubblici, quindi un'affermazione può essere verificata senza accesso al sistema che l'ha prodotta. L'esecutore (runner) e l'infrastruttura di prova che producono i bundle di evidenze sigillati (l'orchestrazione, il gate di prova a release fissata e l'ambiente di misurazione ospitato) restano privati per ora. La specifica e il verificatore vengono aperti per primi; l'esecutore potrà essere aperto in seguito.

Il percorso più breve basato su grafo

1. Installa e configura Kin

Su macOS o Linux:

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

Il programma di installazione risolve l'ultima release stabile, verifica il checksum SHA-256 pubblicato, installa i binari gestiti sotto ~/.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 VS Code.

Per rimuovere solo le integrazioni gestite dal setup, esegui kin setup uninstall. Per la root gestita predefinita (~/.kin), kin setup uninstall --all arresta anche tutti i daemon di Kin, rimuove gli esatti blocchi PATH dell'installer legacy ed elimina ricorsivamente l'installazione gestita (--dry-run ne mostra l'anteprima). Un KIN_HOME personalizzato non viene mai rimosso ricorsivamente: esegui prima la disinstallazione limitata al ledger, poi verifica ed elimina esplicitamente quella directory. Le porzioni di proprietà del setup che sono state modificate bloccano la rimozione completa a meno che non aggiungi --force, quindi la disinstallazione non sovrascrive mai silenziosamente la configurazione di client o 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 inerte dell'autorità gemella, limitato all'utente corrente; mantenere stabile quell'identità di blocco impedisce che un crash o una futura installazione concorrente creino due autorità di mutazione indipendenti. La CLI e il risultato JSON rendono noti questi metadati di coordinamento conservati, invece di dichiarare zero byte residui.

Per l'installazione manuale, ogni archivio e il relativo file .sha256 sono pubblicati sotto 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 Unix o .zip per Windows mostrato nella pagina dell'ultima release.

L'entry point npm risolve lo stesso canale di release pubblico:

npm install -g @kinlab/kin@latest

Un tap Homebrew segue lo stesso canale di release:

brew install firelock-ai/kin/kin

La formula del tap è generata, non mantenuta a mano. La sua versione e il suo SHA-256 per piattaforma vengono rigenerati da ogni release di Kin tramite update-formula.yml nel repository del tap, su un dispatch inviato dalla release stessa, con una riconciliazione ogni sei ore che si auto-corregge se una viene persa. È per questo che il checksum verificato da Homebrew è 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 è agli inizi. L'ammissione del repository funziona: kin init importa un repository Git e pubblica l'autorità del grafo, e le query su grafo, lessicali e supportate dal daemon rispondono nativamente. La proiezione trasparente del filesystem non è inclusa su Windows, e la prova di installazione end-to-end non copre ancora i flussi MCP o di revisione su quella piattaforma, quindi WSL2 rimane il percorso consigliato per l'esperienza Kin completa. Leggi Piattaforma e maturità qui sotto prima di scegliere un percorso di installazione su Windows.

2. Ammetti un repository esistente come verità del grafo

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

In un repository Git pulito, kin init ammette atomicamente nell'autorità del grafo repository-v6 l'intera cronologia raggiungibile, i ref, gli oggetti grezzi, l'albero esatto della workspace e la politica di ammissione. Non sostituisce mai uno snapshot esatto di HEAD né una ricostruzione semantica dal filesystem grezzo. Gli URL di remote locali al repository supportati, i refspec, il tracciamento dei branch e i default di push sono sigillati nella configurazione di coesistenza con Git di Kin; le impostazioni di trasferimento non sicure, ambigue o non supportate falliscono in modalità chiusa (fail closed) prima della pubblicazione.

L'ammissione deriva anche il livello semantico di entità e relazioni per ogni file sorgente di entità supportato in quella cronologia, e kin init riporta i conteggi durevoli e legati alla generazione che ha committato. kin status riporta quella vista dell'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 segnalano l'assenza, invece di nascondere il vuoto dietro la ricerca grezza sui file.

Quali file diventano entità

«File sorgente di entità supportato» significa un file rivendicato da uno degli adattatori linguistici di Kin. Il registro degli adattatori è 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, così un progetto C++ non perde namespace e template a causa della grammatica C.

Tutto il resto viene ammesso come contenuto e resta interrogabile come cronologia e testo, ma non viene analizzato in entità e relazioni. Questo include Markdown, HTML e CSS, SQL, YAML, JSON e TOML, script di 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 al suo interno.

3. Fai una domanda reale al grafo

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 vicino. Una volta completati gli embedding, il tuo agente di IA 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 la similarità vettoriale locale su di esse e conferma la copertura con kin graph status.

Revisiona una modifica scritta dall'IA

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

Esegui kin init sul branch che vuoi revisionare, così la cronologia Git pertinente è nel grafo, poi passa SHA di commit espliciti al gate ombra di sola segnalazione:

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

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

Come Kin si relaziona a Git

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

• kin init importa l'intera cronologia Git raggiungibile e gli edge esatti dei genitori. Kin non ha volutamente alcuna modalità di inizializzazione a cronologia parziale o solo snapshot.
• Dopo l'importazione, il grafo di Kin possiede identità del repository, stato dell'albero, cronologia, ref e relazioni semantiche. Le viste del filesystem e di Git sono proiezioni.
• kin git export --output ../repo.git scrive una nuova proiezione Git bare da una generazione di autorità di proprietà del grafo. Non consulta i file di lavoro né un object store .git/ circostante, e rifiuta una destinazione esistente o interna al repository. Oggetti, ref e directory vengono scaricati (flushed) prima che venga riconosciuta la pubblicazione verso la destinazione no-replace. La pubblicazione ancorata alle capability è attualmente disponibile su host Unix; gli 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à con Git mentre Kin diventa l'autorità.

Piattaforma e maturità

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

La prima indicizzazione legge l'intera cronologia Git raggiungibile, quindi kin init su un repository grande o di lunga vita richiede minuti, non secondi, prima che inizi l'embedding. Dopo che init restituisce il controllo, il daemon continua a prepararsi in background, e le prime chiamate degli agenti su un repository grande possono richiedere tempi di risposta notevolmente più lunghi.

Test arm64 limitati hanno rilevato che il percorso principale di grafo e lessico è utilizzabile con 512 MB, ma l'embedding completo scarica un modello di circa 522 MB e attualmente richiede 2 GB come soglia operativa sicura; 1 GB è un limite non sicuro e 512 MB possono terminare durante l'embedding. Questi sono vincoli alpha osservati, non promesse di dimensionamento universali.

Un kin --version riuscito stabilisce solo che il binario principale gira. Non stabilisce la compatibilità VFS né una proiezione live basata su grafo. Su un host Unix supportato, usa kin setup status, kin-vfs status --workspace . e un avvio reale con kin-vfs exec --workspace . -- <command>. Il launcher VFS include un canary di interposizione e segnala quando il sistema operativo rimuove lo shim. Il README di kin-vfs descrive il confine completo.

Gli asset delle release sono pubblicati con checksum e il workflow di release esegue installazione anonima, verifiche daemon/MCP, embedding e verifiche reali della proiezione VFS basata su grafo su tutta la sua matrice di runner supportati. Il workflow stesso è pubblico: Install Proof. Una release verde stabilisce quegli esatti artefatti e ambienti; non è un'affermazione che ogni distribuzione, strumento o forma di repository sia già coperta.

Posizione sulle prove

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

Leggi la metodologia, il set di task, 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 avranno una prova riproducibile propria.

Scopri di più e contribuisci

• Avvio rapido e configurazione avanzata
• Dimensioni dello store e cosa le determina
• Riferimento degli strumenti MCP
• Tesi graph-first
• GitHub Discussions
• Segnalazioni di bug e richieste di funzionalità
• Guida al contributo
• Segnalazioni di sicurezza private

Licenza

Apache-2.0.

Software che ricorda se stesso.