kin v0.3.6

Les agents d'IA peuvent écrire une modification plus vite qu'une équipe ne peut établir ce qu'elle touche, si elle annule un correctif antérieur et jusqu'où s'étendent ses conséquences. Git enregistre les fichiers et l'historique des lignes. Kin enregistre le logiciel lui-même sous forme de graphe d'entités, de relations, de modifications et de provenance, puis offre aux humains et aux agents une autorité sémantique unique à interroger et à revoir. Ce qu'une modification touche apparaît avant qu'elle ne soit fusionnée, et les agents travaillent à partir d'un contexte exact au lieu de relire le dépôt.

Kin est le système d'enregistrement sémantique pour les logiciels écrits par IA. C'est une alpha publique, utilisable dès aujourd'hui comme CLI locale, démon, serveur MCP, surface de revue et projection de système de fichiers adossée à un graphe. Il est en pré-1.0, attendez-vous donc à des aspérités et à des changements cassants. Consultez la dernière version stable et les limitations actuelles avant de l'adopter dans un workflow critique.

Voyez-le sur un dépôt réel

Une modification de signature sur une seule ligne dans ripgrep semble anodine dans le diff. Interrogez kin impact à son sujet, avant qu'aucun compilateur ne s'exécute, et il nomme ce que la modification atteint. Les appelants de la signature modifiée viennent en premier, puis tout ce que ces appelants entraînent derrière eux.

Enregistré sur un graphe préparé au commit ripgrep e89fff89ac9af12e8d4ce9d5fd07beb408ca730f. 13 entités impactées dans un rayon de 3 sauts, dont 3 appelants directs de la signature modifiée. Le graphe a été construit au préalable. Aucun compilateur n'a été exécuté. Commandes exactes : kinlab.ai/proof. Le répertoire d'exécution brut n'est pas encore public, c'est donc une recette que vous pouvez ré-exécuter, et non une trace que vous pouvez auditer.

Kin fait apparaître ce que la modification touche. La question de savoir si la modification est correcte reste du ressort de votre compilateur, de vos tests et de votre revue. Le graphe est construit au préalable par kin init, et sa construction est la partie coûteuse ; ensuite, les questions d'impact sont résolues depuis la vérité du graphe, et non en relisant l'arborescence.

La pile

Kin est un système unique avec quelques surfaces publiques claires :

Comment les pièces s'assemblent

Kin est le système d'enregistrement sémantique pour les logiciels écrits par IA, et tout ce qui figure dans le schéma ci-dessous atteint cette autorité ou la soutient. Les humains et les agents d'IA entrent par la CLI, le serveur MCP intégré ou l'extension VS Code. Les trois interrogent le même démon, et le démon répond depuis l'autorité du graphe plutôt qu'en relisant l'arborescence. kin-vfs reprojette ce même graphe à travers des appels système ordinaires, afin que les éditeurs, compilateurs et systèmes de build continuent de voir des fichiers. Git se tient à côté du graphe comme frontière d'import et d'export, et non comme chemin de réponse, et KinLab est la couche hébergée au-dessus de la même 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

Sous ces surfaces se trouvent les couches qui composent le système :

Ce sont des couches d'implémentation d'un seul système, et non des produits séparés qu'un nouvel utilisateur doit assembler. Aucune d'elles ne s'installe séparément.

Open source et écosystème Kin

Le cœur de Kin est open source sous licence Apache-2.0 : kin, kin-db, kin-vfs et kin-editor, ainsi que les bibliothèques de support kin-model, kin-blobs, kin-search, kin-vector, kin-infer, kin-lsp et kin-actions.

KinLab est un produit propriétaire construit sur ce cœur ouvert : la couche hébergée de collaboration et de plan de contrôle décrite ci-dessus.

La même frontière s'applique au partage des travaux de benchmark. La spécification du benchmark et un vérificateur de bundles autonome et sans dépendances sont publics, afin qu'une affirmation puisse être vérifiée sans accès au système qui l'a produite. L'exécuteur et l'infrastructure de preuve qui produisent des bundles de preuve scellés (l'orchestration, la porte de preuve à version épinglée et l'environnement de mesure hébergé) restent privés pour l'instant. La spécification et le vérificateur s'ouvrent en premier ; l'exécuteur pourra s'ouvrir plus tard.

Le chemin le plus court adossé au graphe

1. Installer et configurer Kin

Sur macOS ou Linux :

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

L'installeur résout la dernière version stable, vérifie sa somme de contrôle SHA-256 publiée, installe les binaires gérés sous ~/.kin et lance la configuration. Exécuter l'intention explicite agent configure le serveur MCP intégré pour les clients pris en charge détectés. Utilisez --intent local pour une utilisation en CLI et système de fichiers sans configuration MCP, ou --intent editor pour le parcours VS Code.

Pour retirer uniquement les intégrations gérées par kin setup, exécutez kin setup uninstall. Pour la racine gérée par défaut (~/.kin), kin setup uninstall --all arrête également tous les démons Kin, supprime les blocs PATH exacts de l'ancien installeur et supprime récursivement l'installation gérée (--dry-run en donne un aperçu). Un KIN_HOME personnalisé n'est jamais supprimé récursivement : exécutez d'abord la désinstallation limitée au registre, puis examinez et supprimez ce répertoire explicitement. Les tranches modifiées appartenant à la configuration bloquent la suppression complète à moins d'ajouter --force, afin que la désinstallation n'écrase jamais silencieusement la configuration client ou shell modifiée par l'utilisateur. Sous Windows, la CLI planifie la suppression de son répertoire d'installation verrouillé immédiatement après la sortie du processus en cours. Windows conserve intentionnellement un sidecar d'autorité frère inerte, réservé à l'utilisateur courant ; maintenir cette identité de verrou stable empêche un plantage ou une installation future concurrente de créer deux autorités de mutation indépendantes. La CLI et le résultat JSON divulguent ces métadonnées de coordination conservées plutôt que de prétendre à zéro octet résiduel.

Pour l'installation manuelle, chaque archive et son fichier .sha256 sont publiés sous https://github.com/firelock-ai/kin/releases/latest/download/. Les noms d'artefacts évolutifs sont kin-macos-aarch64, kin-macos-x86_64, kin-linux-aarch64, kin-linux-x86_64 et kin-windows-x86_64 ; utilisez le suffixe .tar.gz affiché sur la page de la dernière version. Windows publie également kin-windows-x86_64.zip, qui est ce que l'installeur PowerShell et le lanceur npm récupèrent.

Le point d'entrée npm résout le même canal de publication public :

npm install -g @kinlab/kin@latest

Un tap Homebrew suit le même canal de publication :

brew install firelock-ai/kin/kin

La formule du tap est générée, et non maintenue à la main. Sa version et son SHA-256 par plateforme sont régénérés à partir de chaque version de Kin par update-formula.yml dans le dépôt du tap, sur un dispatch envoyé par la version elle-même, avec une réconciliation toutes les six heures qui auto-répare un dispatch manqué. C'est pourquoi la somme de contrôle vérifiée par Homebrew est celle publiée à côté de l'archive, et non une copie conservée séparément. Confirmez ce que vous avez installé avec kin --version, comme vous devriez le faire sur tout chemin d'installation.

Sous Windows, exécutez irm https://get.kinlab.dev/install.ps1 | iex dans PowerShell. La prise en charge native de Windows x86_64 est précoce. L'admission de dépôt fonctionne : kin init importe un dépôt Git et publie l'autorité du graphe, et les requêtes de graphe, lexicales et adossées au démon répondent nativement. La projection transparente du système de fichiers n'est pas fournie sous Windows, et la preuve d'installation de bout en bout ne couvre pas encore les workflows MCP ou de revue sur cette plateforme ; WSL2 reste donc le chemin recommandé pour l'expérience Kin complète. Lisez Plateforme et maturité ci-dessous avant de choisir un chemin d'installation Windows.

2. Admettre un dépôt existant comme vérité du graphe

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

Dans un dépôt Git détecté, kin init admet atomiquement l'historique complet atteignable, les références, les objets bruts, l'arbre de travail exact et la politique d'admission dans l'autorité de graphe repository-v6. Un arbre de travail avec des modifications non commitées, des changements indexés ou des fichiers non suivis est tout de même admis : kin init admet l'état committé et divulgue ce qu'il n'a pas admis. Il ne substitue jamais un instantané HEAD exact ni une reconstruction sémantique du système de fichiers brut. Les URLs de dépôts distants locaux pris en charge, les refspecs, le suivi de branche et les valeurs par défaut de push sont scellés dans la configuration de coexistence Git de Kin ; les paramètres de transfert dangereux, ambigus ou non pris en charge échouent en mode fermé avant la publication.

L'admission dérive également la couche sémantique d'entités et de relations pour chaque fichier source d'entités pris en charge dans cet historique, et kin init rapporte les compteurs durables liés à la génération qu'il a commités. kin status rapporte cette vue d'autorité du dépôt ; kin graph status rapporte séparément le graphe de requête vivant et mutable du démon, qui peut inclure un enrichissement dérivé ultérieurement. Les surfaces de requête consomment l'enrichissement détenu par le graphe lorsqu'il existe et signalent son absence au lieu de masquer l'écart derrière une recherche de fichiers bruts.

Quels fichiers deviennent des entités

« Fichier source d'entités pris en charge » désigne un fichier revendiqué par l'un des adaptateurs de langage de Kin. Le registre d'adaptateurs constitue l'ensemble complet, et chaque fichier d'un dépôt y est résolu :

Un en-tête .h est lu comme du C++ lorsque son contenu l'indique, afin qu'un projet C++ ne perde pas ses espaces de noms et ses templates au profit de la grammaire C.

Tout le reste est admis comme contenu et reste interrogeable en tant qu'historique et texte, mais n'est pas analysé en entités et relations. Cela inclut Markdown, HTML et CSS, SQL, YAML, JSON et TOML, les scripts shell, Objective-C, Scala, Elixir, Dart, Lua, R, Zig, Haskell et Nix. Si votre langage figure sur cette liste, locate et refs n'y trouveront pas de symboles.

3. Posez une vraie question au graphe

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

Remplacez ExactEntityName par un symbole retourné par locate. locate trouve les entités pertinentes pour une intention, refs affiche les appelants/importeurs et références détenus par le graphe, et trace retourne l'entité focale ainsi que le contexte sémantique proche. Une fois les plongements terminés, votre agent d'IA configuré peut utiliser l'outil semantic_locate adossé aux vecteurs ; get_context_pack, find_references et trace_data_flow exposent directement le voisinage du graphe.

L'admission dérive les entités sémantiques, pas leurs vecteurs. Exécutez kin embed pour ajouter une similarité vectorielle locale par-dessus, et confirmez la couverture avec kin graph status.

Revoyez une modification écrite par IA

L'IA écrit le code. Kin prouve ce qui a changé.

Exécutez kin init sur la branche que vous souhaitez revoir afin que l'historique Git pertinent soit dans le graphe, puis transmettez des SHA de commits explicites à la porte fantôme en mode rapport uniquement :

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

Le résultat est PASS, NEEDS ATTENTION ou WOULD BLOCK, accompagné de l'impact que Kin a dérivé du graphe, du contexte nécessaire pour le réparer et des preuves derrière les deux. La paternité est déclarée, non vérifiée. La commande ne bloquera pas votre fusion et ne modifiera pas l'état du graphe. Elle remet les preuves à un humain ou à une politique CI et s'arrête là.

Comment Kin se rapporte à Git

À côté de Git aujourd'hui. Autorité du dépôt au fil du temps. Lors d'une adoption en contexte existant, Git reste une frontière d'interopérabilité explicite d'import/export ; il ne répond jamais aux requêtes d'exécution de Kin et ne répare pas une vérité du graphe manquante.

• kin init importe l'historique Git complet atteignable et les arêtes parentes exactes. Kin n'a délibérément aucun mode d'initialisation à historique partiel ou limité aux instantanés.
• Après l'import, le graphe de Kin possède l'identité du dépôt, l'état de l'arborescence, l'historique, les références et les relations sémantiques. Les vues du système de fichiers et de Git sont des projections.
• kin git export --output ../repo.git écrit une nouvelle projection Git nue à partir d'une génération d'autorité détenue par le graphe. Elle ne consulte ni les fichiers de travail ni un magasin d'objets .git/ ambiant, et refuse une destination existante ou située dans le dépôt. Les objets, références et répertoires sont vidés avant que la publication vers la destination sans remplacement ne soit acquittée. La publication ancrée par capacité est actuellement disponible sur les hôtes Unix ; les autres hôtes refusent avant de créer l'export.

Cela permet à une équipe de migrer un dépôt existant sans renoncer à son éditeur, son compilateur, son système de build ni à son interopérabilité Git pendant que Kin devient l'autorité.

Plateforme et maturité

Le runtime principal et la projection du système de fichiers ont des frontières de prise en charge différentes :

La première indexation lit l'intégralité de l'historique Git atteignable, donc kin init sur un dépôt volumineux ou ancien prend des minutes, pas des secondes, avant le début du plongement. Après le retour d'init, le démon continue de préparer en arrière-plan, et les premiers appels d'agent sur un dépôt volumineux peuvent mettre sensiblement plus de temps à répondre.

Des tests arm64 limités ont montré que le chemin central de graphe et lexical est utilisable avec 512 Mo, mais le plongement complet télécharge un modèle d'environ 522 Mo et nécessite actuellement 2 Go comme plancher de fonctionnement sûr ; 1 Go est une limite dangereuse et 512 Mo peuvent provoquer une terminaison pendant le plongement. Ce sont des contraintes d'alpha observées, et non des promesses de dimensionnement universelles.

Un kin --version réussi établit seulement que le binaire principal s'exécute. Il n'établit ni la compatibilité VFS ni une projection vivante adossée au graphe. Sur un hôte Unix pris en charge, utilisez kin setup status, kin-vfs status --workspace . et un vrai lancement kin-vfs exec --workspace . -- <command>. Le lanceur VFS inclut un canari d'interposition et signale lorsque le système d'exploitation retire le shim. Le README de kin-vfs contient la frontière complète.

Les artefacts de version sont publiés avec leurs sommes de contrôle et le workflow de version exécute l'installation anonyme, le démon/MCP, le plongement et de véritables vérifications de projection VFS adossée au graphe sur sa matrice de runners prise en charge. Le workflow lui-même est public : Install Proof. Une version verte établit ces artefacts et environnements exacts ; ce n'est pas une affirmation que chaque distribution, outil ou forme de dépôt est déjà couvert.

Posture de preuve

Le package de preuve Go Multi-SWE-Bench préenregistré publié est épinglé à un build plus ancien, et non à la dernière version évolutive, et n'établit pas une affirmation large de vitesse, d'économies de tokens ou de victoire par catégorie. Les résultats comparatifs sont retenus ici dans l'attente d'une vérification indépendante.

Lisez la méthodologie, l'ensemble de tâches, l'identité de build et les artefacts dans le package de preuve public. Traitez les affirmations hors de ce périmètre mesuré comme des hypothèses jusqu'à ce qu'elles aient leur propre preuve reproductible.

Apprendre et contribuer

• Démarrage rapide et configuration avancée
• Taille du stockage et ce qui la détermine
• Référence des outils MCP
• Support des langages et ce que chaque niveau extrait
• Référence des variables d'environnement
• Thèse du graphe d'abord
• Modèle d'autorité d'écriture et son état transitoire
• Discussions GitHub
• Signalements de bugs et demandes de fonctionnalités
• Guide de contribution
• Signalement privé de sécurité

Licence

Apache-2.0.

Un logiciel qui se souvient de lui-même.