kin v0.3.6

KI-Agenten können eine Änderung schneller schreiben, als ein Team feststellen kann, was sie berührt, ob sie einen früheren Fix rückgängig macht und wie weit ihre Folgen reichen. Git zeichnet Dateien und Zeilenhistorie auf. Kin zeichnet die Software selbst als Graphen aus Entitäten, Beziehungen, Änderungen und Provenienz auf und gibt Menschen und Agenten damit eine einzige semantische Autorität, die sie abfragen und reviewen können. Was eine Änderung berührt, zeigt sich, bevor sie gemerged wird, und Agenten arbeiten mit exaktem Kontext, statt das Repository erneut zu lesen.

Kin ist das semantische System of Record für KI-geschriebene Software. Es ist eine öffentliche Alpha, die heute als lokale CLI, Daemon, MCP-Server, Review-Oberfläche und graphgestützte Dateisystem-Projektion nutzbar ist. Es ist Pre-1.0, also rechne mit rauen Kanten und Breaking Changes. Sieh dir die neueste stabile Version und die aktuellen Einschränkungen an, bevor du es in einem kritischen Workflow einsetzt.

Sieh es an einem echten Repository

Eine einzeilige Signaturänderung in ripgrep sieht im Diff harmlos aus. Frage kin impact danach, bevor irgendein Compiler läuft, und es benennt, was die Änderung erreicht. Die Aufrufer der geänderten Signatur kommen zuerst, dann alles, was diese Aufrufer hinter sich herziehen.

Aufgezeichnet gegen einen vorbereiteten Graphen beim ripgrep-Commit e89fff89ac9af12e8d4ce9d5fd07beb408ca730f. 13 betroffene Entitäten innerhalb von 3 Hops, darunter 3 direkte Aufrufer der geänderten Signatur. Der Graph wurde vorab erstellt. Kein Compiler lief. Exakte Befehle: kinlab.ai/proof. Das rohe Ausführungsverzeichnis ist noch nicht öffentlich – es ist also ein Rezept, das du erneut ausführen kannst, keine Spur, die du prüfen kannst.

Kin zeigt auf, was die Änderung berührt. Ob die Änderung korrekt ist, bleibt deinem Compiler, deinen Tests und deinem Review überlassen. Der Graph wird vorab von kin init erstellt, und das Erstellen ist der teure Teil; danach werden Auswirkungsfragen aus der Graph-Wahrheit beantwortet, nicht durch erneutes Lesen des Baums.

Der Stack

Kin ist ein System mit einigen klaren öffentlichen Oberflächen:

Wie die Teile zusammenpassen

Kin ist das semantische System of Record für KI-geschriebene Software, und alles in der Karte unten erreicht diese Autorität oder unterstützt sie. Menschen und KI-Agenten kommen über die CLI, den gebündelten MCP-Server oder die VS-Code-Erweiterung herein. Alle drei fragen denselben Daemon, und der Daemon antwortet aus der Graph-Autorität, statt den Baum erneut zu lesen. kin-vfs projiziert denselben Graphen über gewöhnliche Dateisystemaufrufe zurück, sodass Editoren, Compiler und Build-Systeme weiterhin Dateien sehen. Git sitzt neben dem Graphen als Import- und Exportgrenze und nicht als Antwortpfad, und KinLab ist die gehostete Schicht über derselben Autorität.

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

Unter diesen Oberflächen liegen die Schichten, aus denen das System aufgebaut ist:

Das sind Implementierungsschichten eines Systems, keine separaten Produkte, die ein neuer Benutzer zusammensetzen muss. Keines davon wird separat installiert.

Open Source und das Kin-Ökosystem

Der Kern von Kin ist Open Source unter Apache-2.0: kin, kin-db, kin-vfs und kin-editor, plus die unterstützenden Bibliotheken kin-model, kin-blobs, kin-search, kin-vector, kin-infer, kin-lsp und kin-actions.

KinLab ist ein proprietäres Produkt, das auf diesem offenen Kern aufbaut: die oben beschriebene gehostete Kollaborations- und Control-Plane-Ebene.

Dieselbe Grenze gilt dafür, wie Benchmark-Arbeit geteilt wird. Die Benchmark-Spezifikation und ein eigenständiger, dependencyfreier Bundle-Verifier sind öffentlich, sodass eine Behauptung ohne Zugriff auf das System geprüft werden kann, das sie hervorgebracht hat. Die Runner- und Proof-Infrastruktur, die versiegelte Beweis-Bundles erzeugt (die Orchestrierung, das Pinned-Release-Proof-Gate und die gehostete Messumgebung), bleibt vorerst privat. Spezifikation und Verifier öffnen zuerst; der Runner kann später folgen.

Kürzester graphgestützter Weg

1. Kin installieren und konfigurieren

Auf macOS oder Linux:

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

Das Installationsprogramm ermittelt die neueste stabile Version, verifiziert ihre veröffentlichte SHA-256-Prüfsumme, installiert die verwalteten Binaries unter ~/.kin und startet das Setup. Die Ausführung der expliziten agent-Absicht konfiguriert den eingebauten MCP-Server für erkannte unterstützte Clients. Verwende --intent local für CLI- und Dateisystemnutzung ohne MCP-Konfiguration oder --intent editor für den VS-Code-Pfad.

Um nur die vom Setup verwalteten Integrationen zu entfernen, führe kin setup uninstall aus. Für das standardmäßig verwaltete Verzeichnis (~/.kin) stoppt kin setup uninstall --all außerdem alle Kin-Daemons, entfernt exakte Legacy-Installer-PATH-Blöcke und löscht die verwaltete Installation rekursiv (--dry-run zeigt eine Vorschau). Ein benutzerdefiniertes KIN_HOME wird niemals rekursiv entfernt: Führe zuerst die auf den Ledger bezogene Deinstallation aus und prüfe und entferne dann dieses Verzeichnis explizit. Modifizierte, dem Setup gehörende Slices blockieren die vollständige Entfernung, es sei denn, du fügst --force hinzu – die Deinstallation überschreibt also niemals stillschweigend eine bearbeitete Client- oder Shell-Konfiguration eines Benutzers. Unter Windows plant die CLI die Löschung ihres gesperrten Installationsverzeichnisses unmittelbar nach dem Beenden des laufenden Prozesses. Windows behält absichtlich einen inerten, nur für den aktuellen Benutzer gültigen Sidecar für die Schwesterautorität; die Stabilität dieser Sperridentität verhindert, dass ein Absturz oder eine gleichzeitige zukünftige Installation zwei unabhängige Mutationsautoritäten erzeugt. Die CLI und das JSON-Ergebnis legen diese beibehaltenen Koordinationsmetadaten offen, statt null Restbytes zu behaupten.

Für die manuelle Installation wird jedes Archiv zusammen mit seiner .sha256-Datei unter https://github.com/firelock-ai/kin/releases/latest/download/ veröffentlicht. Die beweglichen Asset-Namen sind kin-macos-aarch64, kin-macos-x86_64, kin-linux-aarch64, kin-linux-x86_64 und kin-windows-x86_64; verwende das auf der neuesten Release-Seite angezeigte .tar.gz-Suffix. Windows veröffentlicht außerdem kin-windows-x86_64.zip, das vom PowerShell-Installer und dem npm-Launcher abgerufen wird.

Der npm-Einstiegspunkt nutzt denselben öffentlichen Release-Kanal:

npm install -g @kinlab/kin@latest

Ein Homebrew-Tap folgt demselben Release-Kanal:

brew install firelock-ai/kin/kin

Die Formel des Taps wird generiert und nicht von Hand gepflegt. Ihre Version und ihre plattformspezifischen SHA-256-Werte werden bei jeder Kin-Version von update-formula.yml im Tap-Repository neu erzeugt, ausgelöst durch ein Dispatch, das die Version selbst sendet, mit einem sechsstündlichen Abgleich, der einen verpassten Lauf selbst heilt. Deshalb ist die Prüfsumme, die Homebrew verifiziert, die neben dem Archiv veröffentlichte und keine separat gepflegte Kopie davon. Bestätige, was du installiert hast, mit kin --version, wie du es bei jedem Installationspfad tun solltest.

Unter Windows führst du irm https://get.kinlab.dev/install.ps1 | iex in PowerShell aus. Die native Windows-x86_64-Unterstützung steht am Anfang. Die Repository-Aufnahme funktioniert: kin init importiert ein Git-Repository und veröffentlicht Graph-Autorität, und Graph-, lexikalische und daemon-gestützte Abfragen antworten nativ. Die transparente Dateisystem-Projektion wird unter Windows nicht ausgeliefert, und der End-to-End-Installationsbeweis deckt MCP- oder Review-Workflows dort noch nicht ab. Daher bleibt WSL2 der empfohlene Pfad für die volle Kin-Erfahrung. Lies unten Plattform und Reifegrad, bevor du einen Windows-Installationspfad wählst.

2. Ein bestehendes Repository als Graph-Wahrheit aufnehmen

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

In einem erkannten Git-Repository nimmt kin init atomar die vollständige erreichbare Historie, Refs, Rohobjekte, den exakten Workspace-Baum und die Aufnahmerichtlinie in die repository-v6-Graph-Autorität auf. Ein Worktree mit nicht committeten Änderungen, gestageten Änderungen oder nicht verfolgten Dateien wird trotzdem aufgenommen: kin init nimmt den committeten Zustand auf und legt offen, was es nicht aufgenommen hat. Es ersetzt niemals einen Exact-HEAD-Snapshot oder einen semantischen Rohdateisystem-Neuaufbau. Unterstützte repository-lokale Remote-URLs, Refspecs, Branch-Tracking und Push-Standardwerte werden in Kins Git-Koexistenzkonfiguration versiegelt; unsichere, mehrdeutige oder nicht unterstützte Übertragungseinstellungen schlagen vor der Veröffentlichung geschlossen fehl.

Die Aufnahme leitet außerdem für jede unterstützte Entitätsquellendatei in dieser Historie die semantische Entitäts- und Beziehungsebene ab, und kin init meldet die dauerhaften, generationsgebundenen Zählwerte, die es committet hat. kin status meldet diese Repository-Autoritätssicht; kin graph status meldet separat den veränderlichen Live-Abfragegraphen des Daemons, der später abgeleitete Anreicherungen enthalten kann. Abfrageoberflächen nutzen grapheigene Anreicherungen, wenn sie vorhanden sind, und melden deren Fehlen, statt die Lücke hinter einer Rohdateisuche zu verbergen.

Welche Dateien zu Entitäten werden

„Unterstützte Entitätsquellendatei“ bedeutet eine Datei, die einer von Kins Sprachadaptern für sich beansprucht. Die Adapter-Registry ist die vollständige Menge, und jede Datei in einem Repository wird über sie aufgelöst:

Ein .h-Header wird als C++ gelesen, wenn sein Inhalt das nahelegt, sodass ein C++-Projekt Namespaces und Templates nicht an die C-Grammatik verliert.

Alles andere wird als Inhalt aufgenommen und bleibt als Historie und Text durchsuchbar, wird aber nicht in Entitäten und Beziehungen geparst. Dazu gehören Markdown, HTML und CSS, SQL, YAML, JSON und TOML, Shell-Skripte, Objective-C, Scala, Elixir, Dart, Lua, R, Zig, Haskell und Nix. Wenn deine Sprache auf dieser Liste steht, werden locate und refs darin keine Symbole finden.

3. Stelle dem Graphen eine echte Frage

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

Ersetze ExactEntityName durch ein von locate zurückgegebenes Symbol. locate findet die für eine Absicht relevanten Entitäten, refs zeigt grapheigene Aufrufer/Importeure und Referenzen, und trace gibt die Fokalentität plus nahen semantischen Kontext zurück. Sobald die Embeddings vollständig sind, kann dein konfigurierter KI-Agent das vektorgestützte Tool semantic_locate verwenden; get_context_pack, find_references und trace_data_flow legen die Graph-Nachbarschaft direkt offen.

Die Aufnahme leitet die semantischen Entitäten ab, nicht ihre Vektoren. Führe kin embed aus, um lokale Vektorähnlichkeit über ihnen hinzuzufügen, und bestätige die Abdeckung mit kin graph status.

Eine KI-geschriebene Änderung reviewen

KI schreibt Code. Kin beweist, was sich geändert hat.

Führe kin init auf dem Branch aus, den du reviewen möchtest, damit die relevante Git-Historie im Graphen ist, und übergib dann explizite Commit-SHAs an das reine Berichts-Schattengate:

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

Das Ergebnis ist PASS, NEEDS ATTENTION oder WOULD BLOCK, und es wird mit den Auswirkungen geliefert, die Kin aus dem Graphen abgeleitet hat, dem Kontext, der zur Behebung nötig ist, und den Belegen hinter beidem. Die Autorenschaft wird deklariert, nicht verifiziert. Der Befehl blockiert deinen Merge nicht und verändert den Graph-Zustand nicht. Er übergibt die Belege an einen Menschen oder eine CI-Richtlinie und endet dort.

Wie Kin zu Git steht

Heute neben Git. Repository-Autorität im Laufe der Zeit. Bei der Brownfield-Einführung bleibt Git eine explizite Import/Export-Interoperabilitätsgrenze; es beantwortet niemals Kin-Laufzeitabfragen und repariert keine fehlende Graph-Wahrheit.

• kin init importiert die vollständige erreichbare Git-Historie und exakte Elternkanten. Kin hat bewusst keinen Initialisierungsmodus für Teilhistorie oder reine Snapshots.
• Nach dem Import besitzt Kins Graph die Repository-Identität, den Baumzustand, die Historie, Refs und semantische Beziehungen. Dateisystem- und Git-Sichten sind Projektionen.
• kin git export --output ../repo.git schreibt aus einer grapheigenen Autoritätsgeneration eine neue Bare-Git-Projektion. Es konsultiert weder Arbeitsdateien noch einen ambienten .git/-Objektspeicher und lehnt ein bestehendes oder im Repository liegendes Ziel ab. Objekte, Refs und Verzeichnisse werden geleert, bevor die Veröffentlichung am No-Replace-Ziel bestätigt wird. Fähigkeitsverankerte Veröffentlichung ist derzeit auf Unix-Hosts verfügbar; andere Hosts lehnen ab, bevor der Export erstellt wird.

Das ermöglicht einem Team, ein bestehendes Repository zu migrieren, ohne auf Editor, Compiler, Build-System oder Git-Interoperabilität zu verzichten, während Kin autoritativ wird.

Plattform und Reifegrad

Die Kernlaufzeit und die Dateisystem-Projektion haben unterschiedliche Unterstützungsgrenzen:

Die erste Indizierung liest die gesamte erreichbare Git-Historie. Daher dauert kin init bei einem großen oder langlebigen Repository Minuten, nicht Sekunden, bevor das Embedding beginnt. Nachdem init zurückgekehrt ist, bereitet der Daemon im Hintergrund weiter vor, und die ersten Agent-Aufrufe in einem großen Repository können deutlich länger brauchen, um zu antworten.

Begrenzte arm64-Tests ergaben, dass der Kern-Graph- und der lexikalische Pfad bei 512 MB nutzbar sind, aber volles Embedding lädt ein etwa 522 MB großes Modell herunter und benötigt derzeit 2 GB als sichere Betriebsuntergrenze; 1 GB ist eine unsichere Grenze, und bei 512 MB kann der Vorgang während des Embeddings abbrechen. Das sind beobachtete Alpha-Einschränkungen, keine universellen Größenversprechen.

Ein erfolgreiches kin --version belegt nur, dass die Kern-Binärdatei läuft. Es belegt keine VFS-Kompatibilität oder eine lebende graphgestützte Projektion. Verwende auf einem unterstützten Unix-Host kin setup status, kin-vfs status --workspace . und einen echten Start mit kin-vfs exec --workspace . -- <command>. Der VFS-Launcher enthält einen Interpositions-Canary und meldet, wenn das Betriebssystem den Shim entfernt. Die kin-vfs-README enthält die vollständige Grenze.

Release-Assets werden mit Prüfsummen veröffentlicht, und der Release-Workflow führt über seine unterstützte Runner-Matrix hinweg anonyme Installation, Daemon/MCP-, Embedding- und echte graphgestützte VFS-Projektionsprüfungen aus. Der Workflow selbst ist öffentlich: Install Proof. Ein grünes Release belegt genau diese Artefakte und Umgebungen; es ist keine Behauptung, dass bereits jede Distribution, jedes Tool oder jede Repository-Form abgedeckt ist.

Position zu Beweisen

Das veröffentlichte, vorregistrierte Multi-SWE-Bench-Go-Proof-Paket ist an einen älteren Build gebunden, nicht an das jeweils neueste Release, und begründet keinen breiten Anspruch auf Geschwindigkeit, Token-Ersparnis oder Kategoriesieg. Vergleichende Ergebnisse werden hier bis zur unabhängigen Verifizierung zurückgehalten.

Lies Methodik, Aufgabensatz, Build-Identität und Artefakte im öffentlichen Proof-Paket. Behandle Behauptungen außerhalb dieses gemessenen Rahmens als Hypothesen, bis sie einen eigenen reproduzierbaren Beweis haben.

Lernen und mitwirken

• Schnellstart und erweiterte Konfiguration
• Speichergröße und was sie bestimmt
• MCP-Tool-Referenz
• Sprachunterstützung und was jede Stufe extrahiert
• Referenz der Umgebungsvariablen
• Graph-First-These
• Schreibautoritätsmodell und sein Übergangszustand
• GitHub Discussions
• Fehlerberichte und Feature-Anfragen
• Leitfaden zum Mitwirken
• Private Sicherheitsmeldung

Lizenz

Apache-2.0.

Software, die sich an sich selbst erinnert.