kin v0.5.3

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

Kin es el sistema de registro semántico para software escrito por IA. Es un alfa temprano, utilizable hoy como CLI local, daemon, servidor MCP, superficie de revisión y proyección de sistema de archivos respaldada por grafos. Es pre-1.0, así que espera bordes ásperos y cambios disruptivos. 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 firma de una línea en ripgrep parece inofensivo en el diff. Pregunta a kin impact sobre él, antes de que se ejecute cualquier compilador, y nombra lo que alcanza la edición. Los llamadores de la firma modificada aparecen primero, luego todo lo que esos llamadores arrastran detrás.

Registrado contra un grafo preparado en el commit e89fff89ac9af12e8d4ce9d5fd07beb408ca730f de ripgrep. Una edición de firma de una línea, y Kin muestra las entidades que afecta antes de que se ejecute un compilador. 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 esta es una receta que puedes re-ejecutar, no un rastro que puedas auditar.

Kin muestra lo que toca el cambio. Si el cambio es 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 solo 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 en el mapa siguiente o alcanza esa autoridad o la respalda. Humanos y agentes de IA entran a través del 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 releyendo el árbol. kin-vfs proyecta ese mismo grafo de vuelta a través de llamadas ordinarias al sistema de archivos, para que editores, compiladores y sistemas de construcción sigan viendo archivos. Git se sitúa junto al grafo como frontera de importación y exportación, no como vía de respuesta, y KinLab es la capa alojada sobre la misma autoridad.```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

Bajo esas superficies se encuentran las capas sobre las que está construido el sistema:

| Capa | Función |
| --- | --- |
| **[kin-db](https://github.com/firelock-ai/kin-db)** | Almacenamiento de grafos, instantáneas, indexación, búsqueda de texto y búsqueda vectorial. |
| **[kin-model](https://github.com/firelock-ai/kin-model)** | Tipos canónicos y modelos de dominio compartidos en toda la pila. |
| **[kin-blobs](https://github.com/firelock-ai/kin-blobs)** | Almacenamiento de blobs direccionables por contenido. |
| **[kin-search](https://github.com/firelock-ai/kin-search)** | Primitivas de búsqueda léxica y recuperación por etapas. |
| **[kin-vector](https://github.com/firelock-ai/kin-vector)** | Sustrato vectorial y de vecinos más cercanos. |
| **[kin-infer](https://github.com/firelock-ai/kin-infer)** | Sustrato de inferencia y embeddings. |
| **[kin-lsp](https://github.com/firelock-ai/kin-lsp)** | Enriquecimiento mediante language-server que alimenta la capa semántica. |

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](https://github.com/firelock-ai/kin),
[kin-db](https://github.com/firelock-ai/kin-db), [kin-vfs](https://github.com/firelock-ai/kin-vfs),
y [kin-editor](https://github.com/firelock-ai/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](https://kinlab.ai) es un producto propietario construido sobre este núcleo abierto: la
capa de colaboración alojada y de plano de control descrita anteriormente.

El mismo límite se aplica a cómo se comparte el trabajo de benchmarks. La [especificación
de benchmarks y un verificador de paquetes independiente y sin dependencias](https://github.com/firelock-ai/kin-bench-spec)
son públicos, de modo que una afirmación puede verificarse sin acceso al sistema que la
produjo. La infraestructura de ejecución y prueba que genera paquetes de evidencia sellados (la
orquestación, la puerta de verificación de versiones fijadas y el entorno de medición
alojado) permanecen privados por ahora. La especificación y el verificador se abren primero; el ejecutor
puede abrirse más adelante.

## Ruta más corta basada en grafos

### 1. Instalar y configurar Kin

En macOS o Linux:```sh
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 e inicia la configuración. 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 MCP, o --intent editor para la ruta de VS Code.

Para eliminar solo las integraciones gestionadas por la configuración, ejecuta kin setup uninstall. Para la raíz gestionada predeterminada (~/.kin), kin setup uninstall --all también detiene todos los daemons de Kin, elimina los bloques PATH exactos del instalador heredado y borra recursivamente la instalación gestionada (--dry-run lo previsualiza). Un KIN_HOME personalizado nunca se elimina recursivamente: primero ejecuta la desinstalación limitada al ledger y luego revisa y elimina ese directorio explícitamente. Los fragmentos modificados propiedad de la configuración bloquean la eliminación completa a menos que añadas --force, por lo que la desinstalación nunca sobrescribe silenciosamente la configuración editada del cliente o shell del 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 salga. Windows conserva intencionalmente un sidecar de autoridad hermano inerte, exclusivo del usuario actual; mantener esa identidad de bloqueo estable evita 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 afirmar 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 de activos móviles 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 para los archivos de macOS y Linux y el sufijo .zip para Windows, como se muestra en la página de la última versión. El zip de Windows también es lo que descargan el instalador de PowerShell y el lanzador de npm.

El punto de entrada de npm resuelve el mismo canal de publicación público:```sh npm install -g @kinlab/kin@latest

Una instalación global necesita un prefijo npm escribible. Cuando el prefijo pertenece a root y tú no
eres root, npm se niega con `EACCES: permission denied, mkdir
'/usr/local/lib/node_modules/@kinlab'` antes de que Kin siquiera se ejecute, que es el caso habitual
dentro de un contenedor cuyo usuario predeterminado no es root. O bien usa la ruta de instalación cero,
`npx -y @kinlab/kin setup --intent agent --no-interactive`, o mueve el prefijo a un lugar que te
pertenezca y añádelo a tu `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 prefijo de usuario está en el PATH de tu shell interactivo y en ningún otro lugar. Los scripts, pasos de CI, docker exec y clientes de agentes no lo heredan, así que dales la ruta absoluta al binario en lugar de un kin simple. Consulta Funciona con tu agente para conocer la forma de registro.

Un tap de Homebrew sigue el mismo canal de lanzamiento:```sh 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 lanzamiento de Kin mediante
`update-formula.yml` en el repositorio del tap, bajo un despacho que el propio
lanzamiento envía, con una reconciliación cada seis horas que se autocorrige si
se pierde uno. Por eso el checksum que Homebrew verifica es el que se publica
junto al archivo, en lugar de una copia curada 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 es temprano. 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 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 completa de Kin.
Lee [Plataforma y madurez](#platform-and-maturity) a continuación antes de
elegir una ruta de instalación en Windows.

### 2. Admitir un repositorio existente como verdad del grafo```sh
cd /path/to/your/repository
kin init .

En un repositorio Git detectado, kin init admite atómicamente el historial completo alcanzable, las refs, los objetos sin procesar, el árbol de trabajo exacto y la política de admisión en la autoridad de grafo repository-v6. Un árbol de trabajo con ediciones sin confirmar, cambios en el área de preparación o archivos sin seguimiento aún se admite: kin init admite el estado confirmado y revela lo que no admitió. Nunca sustituye una instantánea exacta de HEAD ni una reconstrucción semántica del sistema de archivos sin procesar. Las URL de repositorio remoto compatibles, los refspecs, el seguimiento de ramas y los valores predeterminados de push se sellan en la configuración de coexistencia de Git de Kin; los ajustes de transferencia inseguros, ambiguos o no compatibles fallan de forma cerrada antes de la publicación.

La admisión también deriva la capa de entidad y relación semántica para cada archivo fuente de entidad compatible en ese historial, y kin init informa los recuentos durables vinculados a la generación que confirmó. kin status informa esa vista de autoridad del repositorio; kin graph status informa por separado el grafo de consulta en vivo mutable del daemon, que puede incluir enriquecimiento derivado posteriormente. Las superficies de consulta consumen el enriquecimiento propiedad del grafo cuando existe e informan su ausencia en lugar de ocultar la brecha detrás de la búsqueda de archivos sin procesar.

Qué archivos se convierten en entidades

"Archivo fuente de entidad compatible" significa un archivo que uno de los adaptadores de lenguaje de Kin reclama. El registro de adaptadores es el conjunto completo, y cada archivo en un repositorio se resuelve a través de él:

Un archivo de cabecera .h se lee como C++ cuando su contenido lo indica, por lo que un proyecto de C++ no pierde espacios de nombres y plantillas ante la gramática de C.

Todo lo demás se admite como contenido y permanece 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 una pregunta real al grafo```sh

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 llamadores/importadores y
referencias que pertenecen al 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 puede usar la herramienta
`semantic_locate` respaldada por vectores; `get_context_pack`, `find_references` y
`trace_data_flow` exponen la vecindad del grafo directamente.

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`.

## Funciona con tu agente

Kin incluye su propio agente, y es la vía que recomendamos para el trabajo con agentes. `kin
agent run` impulsa cualquier endpoint compatible con OpenAI, por lo que un modelo local en LM Studio,
Ollama, llama.cpp o vLLM funciona con las mismas banderas que uno alojado, y
accede al grafo a través del mismo servidor MCP que usa cualquier otro cliente.```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

Lo que lo diferencia de apuntar otro agente al servidor MCP es que la regla se aplica dentro del agente en lugar de tomarse prestada de la capa de permisos de un proveedor. Tiene las herramientas de Kin más exactamente dos locales, edit_file y write_file. No hay shell, ni grep ni herramienta de lectura de archivos, por lo que no puede responder una pregunta del repositorio a partir de una búsqueda de archivos sin procesar, y una herramienta que invente se rechaza por nombre. Cuando Kin informa de que un resultado vacío no se puede confiar, se le dice al agente que la respuesta es desconocida y se le da la brecha nombrada en lugar de concluir que la cosa no existe. Cada edición se ejecuta dentro de una transacción de Kin bajo una sesión de Kin, por lo que el cambio lleva una procedencia que nombra al agente. Ejecuta kin agent doctor --base-url <url> primero para comprobar que ambas mitades responden. Consulta la referencia de CLI para ver la superficie completa.

Trabajar con Claude Code, Codex, Cursor, Gemini y cualquier otra cosa que hable MCP sigue siendo de primera clase. kin setup --intent agent configura cada cliente que detecta en una sola pasada. Estos son los comandos de una línea por cliente cuando prefieres instalar Kin directamente.

Claude Code, desde dentro de una sesión:``` /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

Pega el enlace de instalación con un clic en Cursor. Pégalo en Cursor o en la
barra de direcciones de tu navegador:```
cursor://anysphere.cursor-deeplink/mcp/install?name=kin&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIkBraW5sYWIva2luLW1jcCJdfQ==

Kiro toma lo mismo que un enlace web: Añadir Kin a Kiro.

Cline toma la entrada estándar que aparece a continuación en lugar de una línea única. Su CLI lee ~/.cline/mcp.json. En la extensión de VS Code, abre el panel de Servidores MCP, luego la pestaña Configurar, luego Configurar Servidores MCP, y añade la entrada allí.

Cualquier otro cliente que lea una configuración MCP estándar toma esta entrada:```json { "mcpServers": { "kin": { "command": "npx", "args": ["-y", "@kinlab/kin-mcp"] } } }

El wrapper necesita Node 20 o superior, y en su primera ejecución descarga la
versión de Kin correspondiente, verifica su SHA-256 publicado y guarda en caché los binarios por
usuario. Codex CLI quiere lo mismo que TOML bajo `[mcp_servers.kin]`.

Una advertencia que vale la pena repetir: estas herramientas responden desde el grafo, por lo que el repositorio
tiene que ser admitido con `kin init .` e incrustado con `kin embed` antes de que
`semantic_locate` pueda clasificar cualquier cosa. [llms-install.md](https://github.com/firelock-ai/kin/blob/main/llms-install.md) es ese
camino completo escrito para que un agente pueda seguirlo sin supervisión, desde una máquina limpia hasta una
primera llamada de herramienta verificada.

## Revisar 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 luego pasa SHAs de commit explícitos a la puerta de solo informe en modo sombra:```sh
kin review shadow "$(git rev-parse main)..$(git rev-parse HEAD)"

El resultado es PASS, NEEDS ATTENTION o WOULD BLOCK, y viene acompañado del impacto Kin derivado 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 a lo largo del tiempo. Durante la adopción brownfield, Git sigue siendo un límite explícito de interoperabilidad de importación/exportación; nunca responde consultas del runtime de Kin ni repara la verdad faltante del grafo.

• kin init importa el historial completo de Git 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 dueño 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 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 reconozca la publicación del destino sin reemplazo. La publicación anclada por capacidades está disponible actualmente en hosts Unix; otros hosts la rechazan antes de crear la exportación.

Esto permite que un equipo migre un repositorio existente sin renunciar a su editor, compilador, sistema de build 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 grafo es la autoridad en todos los casos anteriores. El shim, un montaje NFS, un montaje FUSE y Windows ProjFS son cuatro formas de ver esa verdad como archivos, y Kin elige entre ellas sondeando qué puede ejecutar este host: un montaje donde esté disponible, porque el kernel lo sirve y ningún proceso puede quitarlo, con el shim inyectado como respaldo de compatibilidad en macOS y Linux y ProjFS liderando en Windows, donde no existe shim. kin vfs on activa el elegido, kin vfs off lo desactiva, y kin doctor lleva una fila que indica cuál está en vigor y si funciona. Cuando falta un modo, Kin imprime la línea exacta que lo instala o habilita para tu plataforma. docs/projection.md tiene la tabla completa por plataforma.

La primera indexación lee todo el historial de Git alcanzable, por lo que kin init en un repositorio grande o de larga vida toma minutos, no segundos, antes de que comience el embedding. Después de que init regresa, 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 grafo principal y la ruta léxica son utilizables con 512 MB, pero la descarga completa de embeddings usa un modelo de aproximadamente 522 MB y actualmente necesita 2 GB como piso operativo seguro; 1 GB es un borde inseguro y 512 MB puede terminar durante el embedding. Estas son restricciones observadas de alfa, no promesas universales de tamaño.

Un kin --version exitoso establece solo que el binario principal se ejecuta. No establece compatibilidad VFS ni una proyección viva respaldada por el grafo. En un host Unix compatible, usa kin vfs status, que sondea cada modo de proyección e imprime lo que realmente está en vigor, luego kin setup status y un lanzamiento real de kin-vfs exec --workspace . -- <comando>. 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 activos de lanzamiento se publican con checksums y el flujo de trabajo de lanzamiento ejecuta instalación anónima, daemon/MCP, embedding y comprobaciones reales de proyección VFS respaldada por el grafo en su matriz de runners compatible. El flujo de trabajo en sí es público: Install Proof. Un lanzamiento 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.

FAQ

¿Kin reemplaza a Git?

Junto a Git hoy. Autoridad del repositorio a lo largo del tiempo. Git sigue siendo un límite explícito de interoperabilidad de importación/exportación durante la adopción brownfield, por lo que un equipo puede migrar un repositorio existente sin renunciar a su editor, compilador, sistema de build o interoperabilidad con Git.

¿Mi código sale de mi máquina?

Kin mantiene el trabajo local del repositorio en tu entorno, por lo que la ingesta del repositorio, el almacenamiento del grafo y las consultas locales se ejecutan allí. KinLab es un producto separado que añade colaboración alojada bajo acuerdos explícitos de acceso y acceso temprano.

¿Con qué agentes funciona?

Trabajar con Claude Code, Codex, Cursor, Gemini y cualquier otra cosa que hable MCP sigue siendo de primera clase. kin setup --intent agent configura cada cliente que detecta en una sola pasada.

¿Bloquea un merge?

La revisión es consultiva, por lo que señala el riesgo sin bloquear y la decisión del merge queda en tu equipo. kin review shadow entrega la evidencia a un humano o a una política de CI y se detiene ahí.

Postura de prueba

El paquete de prueba público preregistrado de Multi-SWE-Bench Go está fijado a un build más antiguo, no al último lanzamiento en movimiento, 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 verificación independiente.

Lee la metodología, el conjunto de tareas, la identidad del 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.

Escritura

Notas de ingeniería de la construcción de Kin, escritas para que un extraño pueda reutilizarlas, viven en kinlab.ai/blog con un feed en kinlab.ai/rss.xml.

• La comprobación que pasó porque no medía nada
• Tu búsqueda de código dice que nada lo usa. ¿Puedes eliminarlo?

Aprende y contribuye

• Inicio rápido y configuración avanzada
• Tamaño del almacén y qué lo impulsa
• Referencia de herramientas MCP
• Soporte de idiomas y qué extrae cada nivel
• Referencia de variables de entorno
• Tesis de grafo primero
• Modelo de autoría de escritura y su estado transitorio
• Debates de GitHub
• Informes de errores y solicitudes de funciones
• Guía de contribución
• Reporte privado de seguridad

Licencia

Apache-2.0.

Software que se recuerda a sí mismo.