kin v0.5.3

Los agentes de IA pueden escribir un cambio más rápido de lo que un equipo puede determinar qué toca, si revierte una corrección anterior y hasta dónde alcanzan sus consecuencias. Git registra archivos e historial de líneas. Kin registra el propio software como un grafo de entidades, relaciones, cambios y procedencia, y luego ofrece a humanos y agentes una única autoridad semántica que consultar y revisar. Lo que toca un cambio aparece antes de que se fusione, y los agentes trabajan con contexto exacto en lugar de volver a leer el repositorio.

Kin es el sistema de registro semántico para software escrito por IA. Es un alpha público, utilizable hoy como CLI local, daemon, servidor MCP, superficie de revisión y proyección de sistema de archivos respaldada por grafo. Es pre-1.0, así que espera asperezas y cambios que rompen la compatibilidad. Consulta la última versión estable y las limitaciones actuales antes de adoptarlo en un flujo de trabajo crítico.

Míralo en un repositorio real

Un cambio de una línea en la firma de ripgrep parece inofensivo en el diff. Pregunta a kin impact por ello, antes de que se ejecute cualquier compilador, y nombrará lo que alcanza la edición. Los llamantes de la firma modificada aparecen primero, y luego todo lo que esos llamantes arrastran consigo.

Registrado contra un grafo preparado en el commit e89fff89ac9af12e8d4ce9d5fd07beb408ca730f de ripgrep. 13 entidades afectadas dentro de 3 saltos, incluidos 3 llamantes directos de la firma modificada. El grafo se construyó de antemano. No se ejecutó ningún compilador. Comandos exactos: kinlab.ai/proof. El directorio de ejecución en bruto aún no es público, así que esto es una receta que puedes volver a ejecutar, no un rastro que puedas auditar.

Kin pone de manifiesto lo que toca el cambio. Que el cambio sea correcto queda en manos de tu compilador, tus pruebas y tu revisión. El grafo se construye de antemano con kin init, y construirlo es la parte costosa; después, las preguntas de impacto se responden desde la verdad del grafo, no releyendo el árbol.

El stack

Kin es un único sistema con unas pocas superficies públicas claras:

Cómo encajan las piezas

Kin es el sistema de registro semántico para software escrito por IA, y todo lo que hay en el mapa siguiente o bien alcanza esa autoridad o bien la respalda. Los humanos y los agentes de IA entran a través de la CLI, el servidor MCP incluido o la extensión de VS Code. Los tres consultan al mismo daemon, y el daemon responde desde la autoridad del grafo en lugar de volver a leer el árbol. kin-vfs proyecta ese mismo grafo de vuelta a través de llamadas ordinarias del sistema de archivos, de modo que los editores, compiladores y sistemas de construcción siguen viendo archivos. Git se sitúa junto al grafo como límite de importación y exportación, no como vía de respuesta, y KinLab es la capa alojada sobre esa misma autoridad.

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

Debajo de esas superficies están las capas con las que está construido el sistema:

Estas son capas de implementación de un único sistema, no productos separados que un nuevo usuario deba ensamblar. Ninguna de ellas se instala por separado.

Código abierto y el ecosistema Kin

El núcleo de Kin es de código abierto bajo Apache-2.0: kin, kin-db, kin-vfs y kin-editor, además de las bibliotecas de soporte kin-model, kin-blobs, kin-search, kin-vector, kin-infer, kin-lsp y kin-actions.

KinLab es un producto propietario construido sobre este núcleo abierto: la capa alojada de colaboración y plano de control descrita anteriormente.

El mismo límite se aplica a cómo se comparte el trabajo de benchmarks. La especificación del benchmark y un verificador de paquetes independiente y sin dependencias son públicos, de modo que una afirmación puede comprobarse sin acceso al sistema que la produjo. El ejecutor y la infraestructura de prueba que producen paquetes de evidencia sellados (la orquestación, la puerta de validación de versiones fijadas y el entorno de medición alojado) siguen siendo privados por ahora. La especificación y el verificador se abren primero; el ejecutor podrá abrirse después.

La ruta más corta con respaldo de grafo

1. Instala y configura Kin

En macOS o Linux:

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

El instalador resuelve la última versión estable, verifica su checksum SHA-256 publicado, instala los binarios gestionados en ~/.kin y lanza el setup. Ejecutar la intención explícita agent configura el servidor MCP integrado para los clientes compatibles detectados. Usa --intent local para uso de CLI y sistema de archivos sin configuración de MCP, o --intent editor para la ruta de VS Code.

Para eliminar solo las integraciones gestionadas por el setup, ejecuta kin setup uninstall. Para la raíz gestionada predeterminada (~/.kin), kin setup uninstall --all además detiene todos los daemons de Kin, elimina los bloques exactos de PATH del instalador heredado y borra recursivamente la instalación gestionada (--dry-run muestra una vista previa). Un KIN_HOME personalizado nunca se elimina recursivamente: primero ejecuta la desinstalación acotada al ledger y luego revisa y elimina ese directorio explícitamente. Las porciones modificadas propiedad del setup bloquean la eliminación completa a menos que añadas --force, de modo que la desinstalación nunca sobrescribe silenciosamente la configuración de cliente o shell editada por un usuario. En Windows, la CLI programa la eliminación de su directorio de instalación bloqueado inmediatamente después de que el proceso en ejecución termine. Windows conserva intencionadamente un sidecar de autoridad inerte, hermano y exclusivo del usuario actual; mantener estable esa identidad de bloqueo impide que un fallo o una instalación futura concurrente creen dos autoridades de mutación independientes. La CLI y el resultado JSON revelan estos metadatos de coordinación retenidos en lugar de declarar cero bytes residuales.

Para la instalación manual, cada archivo y su archivo .sha256 se publican en https://github.com/firelock-ai/kin/releases/latest/download/. Los nombres móviles de los assets son kin-macos-aarch64, kin-macos-x86_64, kin-linux-aarch64, kin-linux-x86_64 y kin-windows-x86_64; usa el sufijo .tar.gz de Unix o .zip de Windows que se muestra en la página de la última versión.

El punto de entrada de npm resuelve el mismo canal público de publicación:

npm install -g @kinlab/kin@latest

Un tap de Homebrew sigue el mismo canal de publicación:

brew install firelock-ai/kin/kin

La fórmula del tap se genera en lugar de mantenerse a mano. Su versión y su SHA-256 por plataforma se regeneran a partir de cada versión de Kin mediante update-formula.yml en el repositorio del tap, en un dispatch que envía la propia versión, con una reconciliación cada seis horas que se autocorrige si se pierde una. Por eso el checksum que Homebrew verifica es el publicado junto al archivo y no una copia seleccionada por separado. Confirma lo que instalaste con kin --version, como deberías hacer en cualquier ruta de instalación.

En Windows, ejecuta irm https://get.kinlab.dev/install.ps1 | iex en PowerShell. El soporte nativo para Windows x86_64 está en fase inicial. La admisión de repositorios funciona: kin init importa un repositorio Git y publica la autoridad del grafo, y las consultas de grafo, léxicas y respaldadas por el daemon responden de forma nativa. La proyección transparente del sistema de archivos no se incluye en Windows, y la prueba de instalación de extremo a extremo aún no cubre los flujos de MCP ni de revisión allí, por lo que WSL2 sigue siendo la ruta recomendada para la experiencia Kin completa. Lee Plataforma y madurez antes de elegir una ruta de instalación en Windows.

2. Admite un repositorio existente como verdad del grafo

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

En un repositorio Git limpio, kin init admite atómicamente el historial completo alcanzable, las refs, los objetos en bruto, el árbol exacto del workspace y la política de admisión en la autoridad de grafo repository-v6. Nunca sustituye una instantánea exacta de HEAD ni una reconstrucción semántica del sistema de archivos en bruto. Las URLs de remoto locales al repositorio, los refspecs, el seguimiento de ramas y los valores predeterminados de push compatibles se sellan en la configuración de coexistencia con Git de Kin; los ajustes de transferencia inseguros, ambiguos o no compatibles se deniegan por defecto antes de la publicación.

La admisión también deriva la capa semántica de entidades y relaciones para cada archivo de origen de entidades compatible en ese historial, y kin init informa de los recuentos duraderos, ligados a la generación, que confirmó. kin status informa de esa vista de autoridad del repositorio; kin graph status informa por separado del grafo de consulta vivo y mutable del daemon, que puede incluir enriquecimiento derivado posteriormente. Las superficies de consulta consumen el enriquecimiento propiedad del grafo cuando existe e informan de su ausencia en lugar de ocultar la carencia tras la búsqueda en archivos en bruto.

Qué archivos se convierten en entidades

«Archivo de origen de entidades compatible» significa un archivo que uno de los adaptadores de lenguaje de Kin reivindica. El registro de adaptadores es el conjunto completo, y cada archivo de un repositorio se resuelve a través de él:

Un encabezado .h se lee como C++ cuando su contenido lo indica, de modo que un proyecto C++ no pierde namespaces ni plantillas a manos de la gramática de C.

Todo lo demás se admite como contenido y sigue siendo consultable como historial y texto, pero no se analiza en entidades y relaciones. Eso incluye Markdown, HTML y CSS, SQL, YAML, JSON y TOML, scripts de shell, Objective-C, Scala, Elixir, Dart, Lua, R, Zig, Haskell y Nix. Si tu lenguaje está en esa lista, locate y refs no encontrarán símbolos en él.

3. Hazle al grafo una pregunta real

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

Reemplaza ExactEntityName con un símbolo devuelto por locate. locate encuentra las entidades relevantes para una intención, refs muestra los llamantes/importadores y referencias propiedad del grafo, y trace devuelve la entidad focal más el contexto semántico cercano. Una vez que los embeddings estén completos, tu agente de IA configurado podrá usar la herramienta semantic_locate respaldada por vectores; get_context_pack, find_references y trace_data_flow exponen directamente la vecindad del grafo.

La admisión deriva las entidades semánticas, no sus vectores. Ejecuta kin embed para añadir similitud vectorial local sobre ellas y confirma la cobertura con kin graph status.

Revisa un cambio escrito por IA

La IA escribe código. Kin demuestra qué cambió.

Ejecuta kin init en la rama que quieras revisar para que el historial de Git relevante esté en el grafo y, a continuación, pasa SHAs de commit explícitos a la puerta de validación shadow de solo informe:

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

El resultado es PASS, NEEDS ATTENTION o WOULD BLOCK, e incluye el impacto que Kin derivó del grafo, el contexto necesario para repararlo y la evidencia detrás de ambos. La autoría se declara, no se verifica. El comando no bloqueará tu merge ni cambiará el estado del grafo. Entrega la evidencia a un humano o a una política de CI y se detiene ahí.

Cómo se relaciona Kin con Git

Junto a Git hoy. Autoridad del repositorio con el tiempo. Durante la adopción brownfield, Git sigue siendo un límite explícito de interoperabilidad de importación/exportación; nunca responde a las consultas en tiempo de ejecución de Kin ni repara la verdad de grafo faltante.

• kin init importa el historial de Git completo alcanzable y las aristas padre exactas. Kin deliberadamente no tiene un modo de inicialización de historial parcial o solo de instantáneas.
• Después de la importación, el grafo de Kin es propietario de la identidad del repositorio, el estado del árbol, el historial, las refs y las relaciones semánticas. Las vistas del sistema de archivos y de Git son proyecciones.
• kin git export --output ../repo.git escribe una nueva proyección Git bare desde una generación de autoridad propiedad del grafo. No consulta los archivos de trabajo ni un almacén de objetos .git/ ambiental, y rechaza un destino existente o dentro del repositorio. Los objetos, las refs y los directorios se vacían antes de que se confirme la publicación en el destino sin reemplazo. La publicación anclada a capacidades está disponible actualmente en hosts Unix; otros hosts se niegan antes de crear la exportación.

Esto permite a un equipo migrar un repositorio existente sin renunciar a su editor, compilador, sistema de construcción o interoperabilidad con Git mientras Kin se vuelve autoritativo.

Plataforma y madurez

El runtime principal y la proyección del sistema de archivos tienen límites de soporte diferentes:

El primer indexado lee todo el historial de Git alcanzable, por lo que kin init en un repositorio grande o de larga vida tarda minutos, no segundos, antes de que comience el embedding. Después de que init devuelva el control, el daemon continúa preparándose en segundo plano, y las primeras llamadas de agentes en un repositorio grande pueden tardar notablemente más en responder.

Las pruebas acotadas en arm64 encontraron que el núcleo de grafo y la ruta léxica son utilizables con 512 MB, pero el embedding completo descarga un modelo de aproximadamente 522 MB y actualmente necesita 2 GB como mínimo seguro de funcionamiento; 1 GB es un borde inseguro y 512 MB pueden terminar durante el embedding. Estas son restricciones de alpha observadas, no promesas universales de dimensionamiento.

Un kin --version exitoso establece solo que el binario principal se ejecuta. No establece compatibilidad con VFS ni una proyección viva respaldada por grafo. En un host Unix compatible, usa kin setup status, kin-vfs status --workspace . y un lanzamiento real de kin-vfs exec --workspace . -- <command>. El lanzador VFS incluye un canario de interposición e informa cuando el sistema operativo elimina el shim. El README de kin-vfs contiene el límite completo.

Los assets de las versiones se publican con checksum y el workflow de publicación ejecuta comprobaciones de instalación anónima, daemon/MCP, embedding y proyección VFS real respaldada por grafo en su matriz de runners compatibles. El propio workflow es público: Install Proof. Una versión en verde establece esos artefactos y entornos exactos; no es una afirmación de que cada distribución, herramienta o forma de repositorio ya esté cubierta.

Postura sobre las pruebas

El paquete de prueba preregistrado Multi-SWE-Bench Go publicado está fijado a una build anterior, no a la última versión móvil, y no establece una afirmación amplia de velocidad, ahorro de tokens o victoria por categoría. Los resultados comparativos se omiten aquí a la espera de una verificación independiente.

Lee la metodología, el conjunto de tareas, la identidad de la build y los artefactos en el paquete de prueba público. Trata las afirmaciones fuera de ese alcance medido como hipótesis hasta que tengan su propia prueba reproducible.

Aprende y contribuye

• Inicio rápido y configuración avanzada
• Tamaño del almacén y qué lo determina
• Referencia de herramientas MCP
• Tesis del grafo primero
• GitHub Discussions
• Informes de errores y solicitudes de funciones
• Guía de contribución
• Notificación privada de seguridad

Licencia

Apache-2.0.

Software que se recuerda a sí mismo.