[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_131":132},"routes/modules.$creator.$moduleId",{"_14":15,"_16":17,"_18":19,"_20":21},"routes/modules.$creator.$moduleId.endpoints",{"_11":12,"_13":-5},"error","Module not found","tools","module",{"_20":22,"_23":24,"_25":26,"_27":28,"_29":30,"_31":32,"_33":34,"_35":26,"_36":37,"_38":-5,"_39":-5,"_40":-5,"_41":42,"_43":44,"_45":46,"_47":48,"_49":50,"_51":52,"_53":54,"_55":-5,"_56":48,"_57":58,"_59":60,"_61":-5,"_62":-5,"_63":-5,"_64":-5,"_65":66,"_67":68,"_69":70,"_71":72,"_73":74,"_75":-5,"_76":-5,"_77":-5,"_78":48,"_79":-5,"_80":81,"_82":83,"_84":85,"_86":87,"_88":89,"_90":91},"apiUrl","https://odel.app/api","creator","firelock-ai","moduleId","kin","@firelock-ai/kin","displayName","Kin","tagline","The system of record for AI-written software.","iconKey","https://avatars.githubusercontent.com/u/69090636?v=4","category","local","status","published","visibility","public","metaDescription","deploymentType","external","workerName","bindingName","mcpConfig","pricingModel","free","creatorUserId","system:external-import","createdAt",1786767543000,"updatedAt",1788754860000,"sourceRegistry","official-mcp-registry","sourceUrl","https://registry.modelcontextprotocol.io/v0/servers?search=ai.kinlab%2Fkin","sourceVerified",false,"sourceMissingSince","importedAt","upstreamStars",47,"upstreamUpdatedAt",1788731224000,"detectedTransport","detectedAuthType","probeStatus","lastProbedAt","githubRepoUrl","https://github.com/firelock-ai/kin","githubRepoFullName","firelock-ai/kin","releaseId","ext-firelock-ai-kin","version","0.7.2","descriptionMarkdown","

\n $\"Kin,$ \n

\n\n

The diff is not the change.

\n\n[![License: Apache-2.0](https://img.shields.io/badge/license-Apache--2.0-blue.svg)](LICENSE) [![Latest release](https://img.shields.io/badge/release-latest-6E56CF.svg)](https://github.com/firelock-ai/kin/releases/latest) [![kinlab.ai](https://img.shields.io/badge/hosted-kinlab.ai-111111.svg)](https://kinlab.ai)\n\n

\n\nAI agents can write a change faster than a team can establish what it touches,\nwhether it reverses an earlier fix, and how far its consequences reach. Git\nrecords files and line history. Kin records the software itself as a graph of\nentities, relations, changes, and provenance, then gives humans and agents one\nsemantic authority to query and review. What a change touches shows up before\nit merges, and agents work from exact context instead of re-reading the\nrepository.\n\nKin is the semantic system of record for AI-written software. It is an early\nalpha, usable today as a local CLI, daemon, MCP server, review surface, and\ngraph-backed filesystem projection. It is pre-1.0, so expect rough edges and\nbreaking changes. See the [latest stable release](https://github.com/firelock-ai/kin/releases/latest)\nand the [current limitations](#platform-and-maturity) before adopting it in a\ncritical workflow.\n\n## See it on a real repository\n\nA one-line signature change in ripgrep looks harmless in the diff. Ask\n`kin impact` about it, before any compiler runs, and it names what the edit\nreaches. The callers of the changed signature come first, then everything\nthose callers pull in behind them.\n\n

\n $\"kin$ \n

\n\nRecorded against a prepared graph at ripgrep commit\n`e89fff89ac9af12e8d4ce9d5fd07beb408ca730f`. A one-line signature edit, and Kin\nsurfaces the entities it affects before a compiler runs. The graph was built\nbeforehand. No compiler ran. Exact commands:\n[kinlab.ai/proof](https://kinlab.ai/proof). The raw run directory is not\npublic yet, so this is a recipe you can re-run, not a trace you can audit.\n\nKin surfaces what the change touches. Whether the change is correct stays with\nyour compiler, tests, and review. The graph is built beforehand by `kin init`,\nand building it is the expensive part; after that, impact questions are\nanswered from graph truth, not from re-reading the tree.\n\n## The stack\n\nKin is one system with a few clear public surfaces:\n\n| Surface | What it does |\n| --- | --- |\n| **[kin](https://github.com/firelock-ai/kin)** | Semantic system of record: CLI, daemon, graph lifecycle, MCP, review, provenance, and Git coexistence. |\n| **[kin-vfs](https://github.com/firelock-ai/kin-vfs)** | Projects graph-owned files through normal filesystem calls so existing tools can keep using files. |\n| **[kin-editor](https://github.com/firelock-ai/kin-editor)** | VS Code access to the entity explorer, semantic search, trace, review, and rename surfaces. |\n| **[Kin MCP](https://github.com/firelock-ai/kin/blob/main/docs/mcp-tools.md)** | Typed graph tools for AI agents, bundled into `kin` and launched with `kin mcp start`. |\n| **[KinLab](https://kinlab.ai)** | Hosted collaboration and control plane. Public repository connection is not a first-run flow yet. |\n\n## How the pieces fit\n\nKin is the semantic system of record for AI-written software, and everything in\nthe map below either reaches that authority or supports it. Humans and AI agents\ncome in through the CLI, the bundled MCP server, or the VS Code extension. All\nthree ask the same daemon, and the daemon answers from graph authority rather\nthan by re-reading the tree. `kin-vfs` projects that same graph back through\nordinary filesystem calls, so editors, compilers, and build systems keep seeing\nfiles. Git sits beside the graph as an import and export boundary rather than as\nan answer path, and KinLab is the hosted layer over the same authority.\n\n```mermaid\nflowchart TD\n people[\"Humans and AI agents\"]\n\n subgraph surfaces[\"Access surfaces\"]\n cli[\"kin CLI\"]\n mcp[\"Kin MCP server\"]\n editor[\"kin-editor for VS Code\"]\n end\n\n daemon[\"kin daemon\"]\n authority[\"Graph authority
entities, relations, changes, provenance\"]\n db[\"kin-db
graph storage, snapshots,
index, text and vector search\"]\n prims[\"kin-model, kin-blobs, kin-search,
kin-vector, kin-infer, kin-lsp\"]\n vfs[\"kin-vfs
transparent file projection\"]\n tools[\"Editors, compilers, build systems\"]\n git[\"Git
import and export boundary\"]\n kinlab[\"KinLab
hosted collaboration and control plane\"]\n\n people --> cli\n people --> mcp\n people --> editor\n cli --> daemon\n mcp --> daemon\n editor --> daemon\n daemon --> authority\n authority --> db\n db --> prims\n authority <-->|\"kin init imports, kin git export\"| git\n authority -->|\"publish and sync\"| kinlab\n authority --> vfs\n vfs --> tools\n```\n\nUnderneath those surfaces are the layers the system is built from:\n\n| Layer | Role |\n| --- | --- |\n| **[kin-db](https://github.com/firelock-ai/kin-db)** | Graph storage, snapshots, indexing, text search, and vector search. |\n| **[kin-model](https://github.com/firelock-ai/kin-model)** | Canonical types and domain models shared across the stack. |\n| **[kin-blobs](https://github.com/firelock-ai/kin-blobs)** | Content-addressable blob storage. |\n| **[kin-search](https://github.com/firelock-ai/kin-search)** | Lexical search primitives and staged retrieval. |\n| **[kin-vector](https://github.com/firelock-ai/kin-vector)** | Vector and nearest-neighbor substrate. |\n| **[kin-infer](https://github.com/firelock-ai/kin-infer)** | Inference and embedding substrate. |\n| **[kin-lsp](https://github.com/firelock-ai/kin-lsp)** | Language-server enrichment feeding the semantic layer. |\n\nThese are implementation layers of one system, not separate products a new user\nneeds to assemble. None of them is installed separately.\n\n## Open source and the Kin ecosystem\n\nThe core of Kin is open source under Apache-2.0: [kin](https://github.com/firelock-ai/kin),\n[kin-db](https://github.com/firelock-ai/kin-db), [kin-vfs](https://github.com/firelock-ai/kin-vfs),\nand [kin-editor](https://github.com/firelock-ai/kin-editor), plus the supporting\nlibraries kin-model, kin-blobs, kin-search, kin-vector, kin-infer, kin-lsp, and\nkin-actions.\n\n[KinLab](https://kinlab.ai) is a proprietary product built on this open core: the\nhosted collaboration and control-plane layer described above.\n\nThe same boundary applies to how benchmark work is shared. The [benchmark\nspecification and a standalone, dependency-free bundle verifier](https://github.com/firelock-ai/kin-bench-spec)\nare public, so a claim can be checked without access to the system that produced\nit. The runner and proof infrastructure that produce sealed evidence bundles (the\norchestration, the pinned-release proof gate, and the hosted measurement\nenvironment) remain private for now. The spec and verifier open first; the runner\ncan open later.\n\n## Shortest graph-backed path\n\nFive commands, and the last one is the answer:\n\n```sh\ncurl -fsSL https://get.kinlab.dev/install | sh\nexec \"$SHELL\" -l\ncd /path/to/your/repository\nkin init .\nkin locate \"where are webhook retries handled\"\n```\n\n`kin init` is the slow step and the one that earns the rest. It admits your Git\nhistory into the graph, and every answer after it comes from that graph rather\nthan from re-reading the tree. Measured on a fresh Debian 12 container with 4\nCPUs and 8 GiB against the release npm serves today, the installer took 4\nseconds, `kin init` took 139 seconds on a 503-file repository with 1,983\ncommits, and the first `kin locate` answered in 6.7 seconds while the daemon\ncold-started, then in 71 milliseconds warm. Those are separately measured legs\nof one sitting, not one timed run, and a repository with deeper history takes\nlonger.\n\nOne thing to expect on a small repository: `kin init` starts a background\ndownload of the roughly 523 MB embedding model, and a conversion that finishes\nin seconds can beat it. When that happens the first `kin locate` ranks on\nlexical and graph signals alone and says why on the line beneath its rows. If\nthat line reports the model still downloading, run the query again once it\nlands. If it reports that none of it arrived, do not wait on it: `kin embed`\nfetches the rest.\n\nWire your agent after `kin init`, not before. The rest of this section is the\nsame path with the detail behind each step.\n\n### 1. Install and configure Kin\n\nOn macOS or Linux:\n\n```sh\ncurl -fsSL https://get.kinlab.dev/install | sh\nexec \"$SHELL\" -l\nkin setup --intent agent\n```\n\nUse `kin setup --intent editor` for the VS Code path. Confirm the resulting\nmachine-readable health checklist with `kin setup status --json`.\n\nThe installer resolves the [latest stable release](https://github.com/firelock-ai/kin/releases/latest),\nverifies its published SHA-256 checksum, installs the managed binaries under\n`~/.kin`, and launches setup. Running the explicit `agent` intent configures the\nbuilt-in MCP server for detected supported clients. Use `--intent local` for CLI\nand filesystem use without MCP configuration, or `--intent editor` for the VS\nCode path.\n\nTo remove only setup-managed integrations, run `kin setup uninstall`. For the\ndefault managed root (`~/.kin`), `kin setup uninstall --all` also stops all Kin\ndaemons, removes exact legacy installer PATH blocks, and recursively deletes the\nmanaged install (`--dry-run` previews it). A custom `KIN_HOME` is never removed\nrecursively: first run the ledger-scoped uninstall, then review and remove that\ndirectory explicitly. Modified setup-owned slices block full removal unless you\nadd `--force`, so uninstall never silently overwrites a user's edited client or\nshell configuration. On Windows, the CLI schedules its locked install directory\nfor deletion immediately after the running process exits. Windows intentionally\nretains one inert, current-user-only sibling authority sidecar; keeping that lock\nidentity stable prevents a crash or concurrent future install from creating two\nindependent mutation authorities. The CLI and JSON result disclose this retained\ncoordination metadata rather than claiming zero residual bytes.\n\nFor manual installation, each archive and its `.sha256` file is published under\n`https://github.com/firelock-ai/kin/releases/latest/download/`. The moving asset\nnames are `kin-macos-aarch64`, `kin-macos-x86_64`, `kin-linux-aarch64`,\n`kin-linux-x86_64`, and `kin-windows-x86_64`; use the `.tar.gz` suffix for the\nmacOS and Linux archives and the `.zip` suffix for Windows, as shown on the\nlatest release page. The Windows zip is also what the PowerShell installer and\nthe npm launcher fetch.\n\nThe npm entry point resolves the same public release channel:\n\n```sh\nnpm install -g @kinlab/kin@latest\n```\n\nA global install needs a writable npm prefix. Where the prefix is root-owned and you are\nnot root, npm refuses with `EACCES: permission denied, mkdir\n'/usr/local/lib/node_modules/@kinlab'` before Kin runs at all, which is the usual case\ninside a container whose default user is not root. Either use the zero-install path,\n`npx -y @kinlab/kin setup --intent agent --no-interactive`, or move the prefix somewhere\nyou own and put it on your `PATH`:\n\n```sh\nnpm config set prefix ~/.npm-global\nexport PATH=\"$HOME/.npm-global/bin:$PATH\" # add this to your shell profile too\nnpm install -g @kinlab/kin@latest\n```\n\nA user prefix is on your interactive shell's `PATH` and nowhere else. Scripts, CI steps,\n`docker exec`, and agent clients do not inherit it, so give those the absolute path to the\nbinary rather than a bare `kin`. See\n[Works with your agent](#works-with-your-agent) for the registration shape.\n\nA Homebrew tap tracks the same release channel:\n\n```sh\nbrew install firelock-ai/kin/kin\n```\n\nThe tap's formula is generated rather than hand-maintained. Its version and its\nper-platform SHA-256 are regenerated from each Kin release by\n`update-formula.yml` in the tap repository, on a dispatch the release itself\nsends, with a six-hourly reconcile that self-heals a missed one. That is why the\nchecksum Homebrew verifies is the one published beside the archive rather than a\nseparately curated copy of it. Confirm what you installed with `kin --version`,\nas you should on any install path.\n\nOn Windows, run `irm https://get.kinlab.dev/install.ps1 | iex` in PowerShell.\nNative Windows x86_64 support is early. Repository admission works: `kin init` imports a Git repository and publishes graph authority, and graph, lexical, and daemon-backed queries answer natively. Transparent filesystem projection is not shipped on Windows, and the end-to-end install proof does not yet cover MCP or review workflows there, so WSL2 remains the recommended path for the full Kin experience.\nRead [Platform and maturity](#platform-and-maturity) below before choosing a\nWindows install path.\n\n### 2. Admit an existing repository as graph truth\n\n```sh\ncd /path/to/your/repository\nkin init .\n```\n\nIn a detected Git repository, `kin init` atomically admits complete reachable\nhistory, refs, raw objects, the exact workspace tree, and admission policy into\nrepository-v6 graph authority. A worktree with uncommitted edits, staged\nchanges, or untracked files still admits: `kin init` admits the committed state\nand discloses what it did not admit. It never substitutes an exact-HEAD snapshot or\nraw-filesystem semantic rebuild. Supported repository-local remote URLs,\nrefspecs, branch tracking, and push defaults are sealed into Kin's Git\ncoexistence configuration; unsafe, ambiguous, or unsupported transfer settings\nfail closed before publication.\n\nAdmission also derives the semantic entity and relation layer for every\nsupported entity-source file in that history, and `kin init` reports the durable,\ngeneration-bound counts it committed. `kin status` reports that repository\nauthority view; `kin graph status` separately reports the daemon's mutable live\nquery graph, which may include later derived enrichment.\nQuery surfaces consume graph-owned enrichment when it exists and report its\nabsence instead of hiding the gap behind raw file search.\n\n#### Which files become entities\n\n\"Supported entity-source file\" means a file one of Kin's language adapters\nclaims. The adapter registry is the whole set, and every file in a repository\nresolves through it:\n\n| Language | Extensions |\n| --- | --- |\n| TypeScript | `.ts`, `.tsx` |\n| JavaScript | `.js`, `.jsx`, `.mjs`, `.cjs` |\n| Python | `.py`, `.pyi` |\n| Go | `.go` |\n| Java | `.java` |\n| Rust | `.rs` |\n| C | `.c`, `.h` |\n| C++ | `.cpp`, `.hpp`, `.cc`, `.cxx` |\n| C# | `.cs` |\n| Ruby | `.rb` |\n| PHP | `.php` |\n| Swift | `.swift` |\n| Kotlin | `.kt`, `.kts` |\n| HCL / Terraform | `.tf`, `.tfvars` |\n\nA `.h` header is read as C++ when its contents say so, so a C++ project does not\nlose namespaces and templates to the C grammar.\n\nEverything else is admitted as content and stays queryable as history and text,\nbut is not parsed into entities and relations. That includes Markdown, HTML and\nCSS, SQL, YAML, JSON and TOML, shell scripts, Objective-C, Scala, Elixir, Dart,\nLua, R, Zig, Haskell, and Nix. If your language is on that list, `locate` and\n`refs` will not find symbols in it.\n\n### 3. Ask the graph a real question\n\n```sh\nkin locate \"where are webhook retries handled\"\nkin refs ExactEntityName\nkin trace ExactEntityName\nkin overview\n```\n\nReplace `ExactEntityName` with a symbol returned by `locate`. `locate` finds the\nentities relevant to an intent, `refs` shows graph-owned callers/importers and\nreferences, and `trace` returns the focal entity plus nearby semantic context.\nOnce embeddings are complete, your configured AI agent can use the vector-backed\n`semantic_locate` tool; `get_context_pack`, `find_references`, and\n`trace_data_flow` expose the graph neighborhood directly.\n\nAdmission derives the semantic entities, not their vectors. Run `kin embed` to\nadd local vector similarity over them, and confirm coverage with\n`kin graph status`.\n\n## Version control without Git\n\nKin keeps a full change history with no Git underneath it. In an empty\ndirectory with no `.git`, the same binary records changes, branches, merges,\nand history, and Git never runs. This is that loop, with the output it printed\non one real run of a build of `main`. `kin init`, `kin status`, and `kin diff`\nsay more than is shown here; the lines below are theirs, unedited, with the\nrest trimmed.\n\nStart an empty repository and record a first change:\n\n```sh\nmkdir kin-demo && cd kin-demo\nkin init\n```\n\n```\n Authority: repository-v6 (graph-owned)\n Default ref: refs/heads/main\n History: unborn (no synthetic commit)\n Workspace: empty exact tree\n Store size: 17.4 KiB under .kin/ (no Git object store here to compare against)\n```\n\n```sh\ncat > retry.py <<'PY'\ndef backoff(attempt):\n return min(2 ** attempt, 30)\nPY\nkin commit -m \"Add the retry backoff\"\n```\n\n```\n starting the kin daemon for this repository; the first query after a start waits for it to load the graph\n kin daemon ready in 1.8s\nCreated semantic change f635b52070f2944aa1c8651fec50cfa62e1cc21c00760137f62f971a7c27642f on branch 'refs/heads/main' (2 entities, 0 relations, 1 artifacts)\nRecorded in Kin authority, not in git. `git status` stays dirty until you run `kin eject` or push this branch to a Kin remote.\n```\n\nThe first commit starts the repository's daemon. Before that, right after\n`kin init`, `kin status` reports durable authority alone and says so on its\n`Tree:` line; once the daemon is up, every `kin status` measures the working\ncopy. Who made the change comes from your Git identity when you have one, and\notherwise from `default_author` in `.kin/config.toml`. Kin refuses to record a\nchange attributed to nobody.\n\nBranch, change the function on the branch, and commit there:\n\n```sh\nkin branch create cap-backoff\nkin branch switch cap-backoff\n```\n\n```\nCreated refs/heads/cap-backoff at change f635b52070f2944aa1c8651fec50cfa62e1cc21c00760137f62f971a7c27642f (authority generation 3)\nSwitched to refs/heads/cap-backoff at change f635b52070f2944aa1c8651fec50cfa62e1cc21c00760137f62f971a7c27642f (1 projected entries, authority generation 4)\n```\n\n```sh\ncat > retry.py <<'PY'\ndef backoff(attempt):\n \"\"\"Exponential backoff, capped at a minute.\"\"\"\n return min(2 ** attempt, 60)\nPY\nkin status\n```\n\n```\nKin repository-v6 status\nHead: symbolic refs/heads/cap-backoff\nTree: 198609d9406becdd1fb97f1f3d16d8d869dc382c38823f2b88aa75f72d927029 (1 artifacts, ahead of its base change as admitted 0s ago)\nRefs: 2, default refs/heads/main\nDurable semantic enrichment: present (2 entities, 0 relations, 1 changes at authority generation 5, workspace generation 3; completion not attested)\nUntracked host content: none, measured 0s ago\n```\n\n```sh\nkin commit -m \"Raise the backoff cap to a minute\"\n```\n\n```\nCreated semantic change 64cce9085641a7eee86bd2b870567ac524835e2e80488f7e5444f7cf9b42c065 on branch 'refs/heads/cap-backoff' (2 entities, 0 relations, 1 artifacts)\n```\n\nBack on `main`, record a second change so the merge has two real parents, then\nmerge the branch:\n\n```sh\nkin branch switch main\ncat > retry_test.py <<'PY'\nfrom retry import backoff\n\ndef test_first_attempt_waits_one_second():\n assert backoff(0) == 1\nPY\nkin commit -m \"Add a first backoff test\"\nkin merge cap-backoff\n```\n\n```\nSwitched to refs/heads/main at change f635b52070f2944aa1c8651fec50cfa62e1cc21c00760137f62f971a7c27642f (1 projected entries, authority generation 7)\nCreated semantic change 18abd82f3a295696fa4938fc078613c0abe4a3214dd6ec0eb81f8a7c1f747105 on branch 'refs/heads/main' (2 entities, 3 relations, 1 artifacts)\nMerged refs/heads/cap-backoff into refs/heads/main as change 4137af4647e6b838771d5e4ce98d8a604304b9d0a66fdb4e0931e828d6b75c9c (2 projected entries, authority generation 9)\n```\n\nThe merge composed both sides by entity identity against their common base,\nwith no line-level text merge, and published one change carrying both parents.\n`kin log` walks that history and `kin diff` shows what the merge brought in,\nas artifacts, as entities, and as lines:\n\n```sh\nkin log\n```\n\n```\nchange 4137af4647e6b838771d5e4ce98d8a604304b9d0a66fdb4e0931e828d6b75c9c\nAuthor: Kin Demo \nDate: 2026-09-05T01:15:32.635348+00:00\nOrigin: native\nParents: 18abd82f3a295696fa4938fc078613c0abe4a3214dd6ec0eb81f8a7c1f747105 64cce9085641a7eee86bd2b870567ac524835e2e80488f7e5444f7cf9b42c065\nDeltas: entities=2 relations=0 tree=1 policy=false\n Merge refs/heads/cap-backoff into refs/heads/main\n\nchange 18abd82f3a295696fa4938fc078613c0abe4a3214dd6ec0eb81f8a7c1f747105\nAuthor: Kin Demo \nDate: 2026-09-05T01:15:32.339226+00:00\nOrigin: native\nParents: f635b52070f2944aa1c8651fec50cfa62e1cc21c00760137f62f971a7c27642f\nDeltas: entities=2 relations=3 tree=1 policy=false\n Add a first backoff test\n\nchange 64cce9085641a7eee86bd2b870567ac524835e2e80488f7e5444f7cf9b42c065\nAuthor: Kin Demo \nDate: 2026-09-05T01:15:31.791709+00:00\nOrigin: native\nParents: f635b52070f2944aa1c8651fec50cfa62e1cc21c00760137f62f971a7c27642f\nDeltas: entities=2 relations=0 tree=1 policy=false\n Raise the backoff cap to a minute\n\nchange f635b52070f2944aa1c8651fec50cfa62e1cc21c00760137f62f971a7c27642f\nAuthor: Kin Demo \nDate: 2026-09-05T01:15:30.609174+00:00\nOrigin: native\nDeltas: entities=2 relations=0 tree=1 policy=true\n Add the retry backoff\n```\n\n```sh\nkin diff HEAD~1 HEAD\n```\n\n```\nKin repository-v6 diff\nBase: HEAD~1 (e5aa80af2498ad1d8f8c5a756f24467773a7f12c46039395deb691a0e09ff0bc)\nHead: HEAD 4137af4647e6b838771d5e4ce98d8a604304b9d0a66fdb4e0931e828d6b75c9c (f86d6f68558a54372da1c08cedd8549dd98733110e3f2db6193dc8314ba10c11)\nArtifacts: +0 ~1 -0\nEntities: +0 ~2 -0\nRelations: +0 ~0 -0\nM retry.py -> retry.py [aab37f62-f986-4543-8187-4af2b8984e0a] blob 0ceda974a82e648bf6e6d40efccc9489eb4b73fa5ab3f0c5cfd35df4911cd524 mode=100644 -> blob c0b44cec88f49e73cc31f7f439ec1b10d9d73cfe1c414dc539106886d4747cce mode=100644\nE~ 0a69467a-63d6-5c34-ac35-632cefde30b7 retry -> retry\nE~ 6cd876cf-cc8a-50bd-94be-e0a2fde3208d backoff -> backoff\n @@ -1,2 +1,3 @@\n def backoff(attempt):\n - return min(2 ** attempt, 30)\n + \"\"\"Exponential backoff, capped at a minute.\"\"\"\n + return min(2 ** attempt, 60)\n```\n\n`HEAD~1` is the merge's first parent, the test commit, so the diff is exactly\nwhat `cap-backoff` contributed: one artifact, the two entities in it (the\nmodule and the function), and the lines. `kin checkout`, `kin stash`,\n`kin rollback`, `kin blame`, and `kin conflicts` with `kin resolve` round out\nthe set, and `kin capabilities` prints where each one stands.\n[The CLI reference](https://github.com/firelock-ai/kin/blob/main/docs/cli-reference.md#branches-merges-and-exact-trees) has\nevery flag.\n\nSharing a native repository between machines is still in progress, and public\nrepository connection through KinLab is not a first-run flow yet. What the\ntransfer commands do today: `kin clone` takes a KinLab locator or the HTTP\nendpoint of another machine's running Kin daemon, adopts that repository's\nidentity into a fresh local workspace, and remembers the origin it came from.\n`kin push` sends your new changes to that saved origin one verified pack at a\ntime, and refuses rather than forces when the remote has moved past you.\n`kin pull` admits what the origin has that you do not and moves your working\ntree onto it, and when uncommitted work stops the tree from following, it says\nso and keeps the history it received. Each of the three is exercised between two\nKin daemons over HTTP by the test suite.\n\n## Works with your agent\n\nKin ships its own agent, and it is the path we recommend for agent work. `kin\nagent run` drives any OpenAI-compatible endpoint, so a local model in LM Studio,\nOllama, llama.cpp or vLLM works from the same flags as a hosted one, and it\nreaches the graph over the same MCP server every other client uses.\n\n```sh\nkin agent run --task \"Find where the retry backoff is computed and document it\" \\\n --model qwen/qwen3.6-35b-a3b --base-url http://localhost:1234/v1\n```\n\nWhat makes it different from pointing another agent at the MCP server is that the\nrule is enforced inside the agent rather than borrowed from a vendor's permission\nlayer. It has Kin's tools plus exactly two local ones, `edit_file` and\n`write_file`. There is no shell, no grep and no file-reading tool, so it cannot\nanswer a repository question from raw file search, and a tool it invents is\nrefused by name. When Kin reports that an empty result cannot be trusted, the\nagent is told the answer is unknown and given the named gap instead of concluding\nthe thing does not exist. Every edit runs inside a Kin transaction under a Kin\nsession, so the change carries provenance naming the agent. Run `kin agent doctor\n--base-url ` first to check both halves answer. See\n[the CLI reference](https://github.com/firelock-ai/kin/blob/main/docs/cli-reference.md#kin-agent) for the full surface.\n\nWorking with Claude Code, Codex, Cursor, Gemini and anything else that speaks MCP\nstays first class. `kin setup --intent agent` configures every client it detects\nin one pass. These are the per-client one-liners when you would rather install Kin\ndirectly.\n\nRun `kin init .` in the repository before you wire a client, not after. These\ntools answer from the graph, so a client pointed at a directory with no graph\ngets a tool surface with nothing behind it. `kin setup` says so itself: its\nround-trip check reports \"no initialized Kin repository at or above\" the\ndirectory it ran in, and tells you to run `kin init` there and re-run setup.\n\nClaude Code, from inside a session:\n\n```\n/plugin marketplace add firelock-ai/kin\n/plugin install kin@kin\n```\n\nCodex:\n\n```sh\ncodex plugin marketplace add firelock-ai/kin\ncodex plugin add kin@kin\n```\n\nGemini CLI:\n\n```sh\ngemini extensions install https://github.com/firelock-ai/kin\n```\n\nCursor takes a one-click install link. Paste this into Cursor or into your\nbrowser's address bar:\n\n```\ncursor://anysphere.cursor-deeplink/mcp/install?name=kin&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIkBraW5sYWIva2luIiwibWNwIiwic3RhcnQiXX0=\n```\n\nKiro takes the same thing as a web link:\n[Add Kin to Kiro](https://kiro.dev/launch/mcp/add?name=kin&config=%7B%22command%22%3A%22npx%22%2C%22args%22%3A%5B%22-y%22%2C%22%40kinlab%2Fkin%22%2C%22mcp%22%2C%22start%22%5D%7D).\n\nCline takes the standard entry below rather than a one-liner. Its CLI reads\n`~/.cline/mcp.json`. In the VS Code extension, open the MCP Servers panel, then\nthe Configure tab, then Configure MCP Servers, and add the entry there.\n\nEvery other client that reads a standard MCP config takes this entry:\n\n```json\n{\n \"mcpServers\": {\n \"kin\": { \"command\": \"npx\", \"args\": [\"-y\", \"@kinlab/kin\", \"mcp\", \"start\"] }\n }\n}\n```\n\n`kin setup status` and `kin doctor` recognize this exact shape, alongside the\nabsolute-path form `kin setup` writes, and grade anything else MISCONFIGURED. Do\nnot shorten `command` to a bare `kin`, because agent clients do not reliably\ninherit your shell `PATH`. `@kinlab/kin-mcp` is the older launcher and keeps\nworking for configurations that already name it; new ones should point at\n`@kinlab/kin`, which ships the same MCP server as one mode of the full CLI.\n\nThe wrapper needs Node 20 or newer, and on its first run it downloads the\nmatching Kin release, verifies its published SHA-256, and caches the binaries per\nuser. Codex CLI wants the same thing as TOML under `[mcp_servers.kin]`.\n\nOne caveat worth repeating: these tools answer from the graph, so the repository\nhas to be admitted with `kin init .` and embedded with `kin embed` before\n`semantic_locate` can rank anything. [llms-install.md](https://github.com/firelock-ai/kin/blob/main/llms-install.md) is that\nwhole path written so an agent can follow it unattended, from a bare machine to a\nfirst verified tool call.\n\n## Review an AI-written change\n\n**AI writes code. Kin proves what changed.**\n\nRun `kin init` on the branch you want to review so the relevant Git history is in\nthe graph, then pass explicit commit SHAs to the report-only shadow gate:\n\n```sh\nkin review shadow \"$(git rev-parse main)..$(git rev-parse HEAD)\"\n```\n\nThe result is `PASS`, `NEEDS ATTENTION`, or `WOULD BLOCK`, and it comes with the\nimpact Kin derived from the graph, the context needed to repair it, and the\nevidence behind both. Authorship is declared, not verified. The command will not\nblock your merge or change graph state. It hands evidence to a human or a CI\npolicy and stops there.\n\n## How Kin relates to Git\n\nBeside Git today. Repository authority over time. During brownfield adoption,\nGit remains an explicit import/export interoperability boundary; it never\nanswers Kin runtime queries or repairs missing graph truth.\n\n- `kin init` imports complete reachable Git history and exact parent edges.\n Kin deliberately has no partial-history or snapshot-only initialization mode.\n- After import, Kin's graph owns repository identity, tree state, history, refs,\n and semantic relations. Filesystem and Git views are projections.\n- `kin git export --output ../repo.git` writes a new bare Git projection from\n one graph-owned authority generation. It does not consult working files or an\n ambient `.git/` object store, and it refuses an existing or in-repository\n destination. Objects, refs, and directories are flushed before the\n no-replace destination publication is acknowledged. Capability-anchored\n publication is currently available on Unix hosts; other hosts refuse before\n creating the export.\n\nThis lets a team migrate an existing repository without giving up its editor,\ncompiler, build system, or Git interoperability while Kin becomes authoritative.\n\n## Platform and maturity\n\nThe core runtime and the filesystem projection have different support\nboundaries:\n\n| Platform | Core Kin runtime | `kin-vfs` projection |\n| --- | --- | --- |\n| macOS, Apple Silicon and Intel | Native graph, vector, daemon, setup, MCP, and review surfaces ship in the release archive. | Shipped and exercised on both architectures. It uses `DYLD_INSERT_LIBRARIES`; SIP-protected or hardened programs may reject injection. |\n| Linux x86_64 and arm64 | `kin` and `kin-daemon` are static musl builds intended to run on glibc and musl distributions. | The public VFS executable and shim are GNU/glibc builds, not musl builds. They are built against a pinned glibc floor of 2.31 and link OpenSSL 3, so a projection host needs both; Debian 12 loads them, and Alpine and other musl distributions are not supported projection hosts. The release refuses to publish a Linux archive whose binaries ask for more glibc than that floor. The arm64 release proof runs on Ubuntu 24.04. |\n| Native Windows x86_64 | Early support: repositories admit and graph and lexical queries answer natively, but MCP and review workflows are not yet covered end to end by the install proof. WSL2 remains the recommended path for full Kin. | Not shipped. Use WSL2 with a Linux distribution that meets the glibc boundary for projection. |\n\nThe graph is the authority in every case above. The shim, an NFS mount, a FUSE\nmount, and Windows ProjFS are four ways to see that truth as files, and Kin\npicks between them by probing what this host can run: a mount where one is\navailable, because the kernel serves it and no process can have it stripped,\nwith the injected shim as the compatibility fallback on macOS and Linux and\nProjFS leading on Windows, where no shim exists. `kin vfs on` engages the chosen\none, `kin vfs off` disengages it, and `kin doctor` carries a row saying which is\nin force and whether it is working. Where a mode is missing, Kin prints the\nexact line that installs or enables it for your platform.\n[docs/projection.md](https://github.com/firelock-ai/kin/blob/main/docs/projection.md) has the full per-platform table.\n\nFirst indexing reads the entire reachable Git history, so `kin init` on a\nlarge or long-lived repository takes minutes, not seconds, before embedding\nbegins. After `init` returns, the daemon continues preparing in the\nbackground, and the first agent calls on a large repository can take\nnoticeably longer to answer.\n\nBounded arm64 testing found the core graph and lexical path usable at 512 MB,\nbut full embedding downloads a roughly 522 MB model and currently needs 2 GB as\nthe safe operating floor; 1 GB is an unsafe edge and 512 MB can terminate during\nembedding. These are observed alpha constraints, not universal sizing promises.\n\nA successful `kin --version` establishes only that the core binary runs. It\ndoes not establish VFS compatibility or a live graph-backed projection. On a\nsupported Unix host, use `kin vfs status`, which probes each projection mode and\nprints what is actually in force, then `kin setup status` and a real\n`kin-vfs exec --workspace . -- ` launch. The VFS launcher includes an\ninterposition canary and reports when the operating system strips the shim.\nThe [kin-vfs README](https://github.com/firelock-ai/kin-vfs#current-platform-and-package-boundaries)\ncontains the full boundary.\n\nRelease assets are checksum-published and the release workflow runs anonymous\ninstallation, daemon/MCP, embedding, and real graph-backed VFS projection checks\nacross its supported runner matrix. The workflow itself is public:\n[Install Proof](https://github.com/firelock-ai/kin/actions/workflows/install-proof.yml).\nA green release establishes those exact artifacts and environments; it is not a\nclaim that every distribution, tool, or repository shape is already covered.\n\n## FAQ\n\n### Does Kin replace Git?\n\nBeside Git today. Repository authority over time. Git stays an explicit\nimport/export interoperability boundary during brownfield adoption, so a team\ncan migrate an existing repository without giving up its editor, compiler,\nbuild system, or Git interoperability.\n\n### Does my code leave my machine?\n\nKin keeps local repository work in your environment, so repository ingestion,\ngraph storage, and local queries all run there. KinLab is a separate product\nthat adds hosted collaboration under explicit access and early-access\nagreements.\n\n### Which agents does it work with?\n\nWorking with Claude Code, Codex, Cursor, Gemini and anything else that speaks MCP\nstays first class. `kin setup --intent agent` configures every client it detects\nin one pass.\n\n### Does it block a merge?\n\nReview is advisory, so it flags risk without blocking and the merge decision\nstays with your team. `kin review shadow` hands evidence to a human or a CI\npolicy and stops there.\n\n## Proof posture\n\nThe published preregistered Multi-SWE-Bench Go proof package is pinned to an\nolder build, not the moving latest release, and does not establish a broad\nspeed, token-savings, or category-win claim. Comparative results are withheld\nhere pending independent verification.\n\nRead the methodology, task set, build identity, and artifacts in the\n[public proof package](https://firelock.ai/labs/kin-proof). Treat claims outside\nthat measured scope as hypotheses until they have their own reproducible proof.\n\n## Writing\n\nEngineering notes from building Kin, written down so a stranger can reuse them,\nlive at [kinlab.ai/blog](https://kinlab.ai/blog) with a feed at\n[kinlab.ai/rss.xml](https://kinlab.ai/rss.xml).\n\n- [The check that passed because it measured nothing](https://kinlab.ai/blog/checks-that-cannot-fail)\n- [Your code search says nothing uses it. Can you delete it?](https://kinlab.ai/blog/empty-answer-safe-to-delete)\n\n## Learn and contribute\n\n- [Quickstart and advanced configuration](https://github.com/firelock-ai/kin/blob/main/docs/quickstart.md)\n- [CLI reference: every command, with its flags and defaults](https://github.com/firelock-ai/kin/blob/main/docs/cli-reference.md)\n- [Store size and what drives it](https://github.com/firelock-ai/kin/blob/main/docs/store-size.md)\n- [MCP tool reference](https://github.com/firelock-ai/kin/blob/main/docs/mcp-tools.md)\n- [Language support and what each tier extracts](https://github.com/firelock-ai/kin/blob/main/docs/language-support.md)\n- [Environment variable reference](https://github.com/firelock-ai/kin/blob/main/docs/env-vars.md)\n- [Graph-first thesis](https://github.com/firelock-ai/kin/blob/main/docs/thesis.md)\n- [Write-authority model and its transitional state](https://github.com/firelock-ai/kin/blob/main/docs/write-authority-model.md)\n- [GitHub Discussions](https://github.com/firelock-ai/kin/discussions)\n- [Bug reports and feature requests](https://github.com/firelock-ai/kin/issues/new/choose)\n- [Contributing guide](https://github.com/firelock-ai/kin/blob/main/CONTRIBUTING.md)\n- [Private security reporting](https://github.com/firelock-ai/kin/blob/main/SECURITY.md)\n\n## License\n\n[Apache-2.0](https://github.com/firelock-ai/kin/blob/main/LICENSE).\n\n

Software that remembers itself.

\n","changelogMarkdown","videoKey","requiredSecretsJson","publishedAt","priceCents","trialDays",0,"upstream",{"_109":110,"_111":112,"_113":114,"_115":116,"_117":118,"_119":120},"requiredSecrets",[],"tags",[94,95,96,97,98,99,100,101,102,103,104,105,106,107,108],"assets",[],"stats",{"_92":81,"_93":81},"ratingAvg","reviewCount","ai","ai-agents","ai-native","claude","code-review","copilot","cursor","developer-tools","gemini-cli-extension","graph-database","knowledge-graph","llm","open-source","rust","semantic","topics",[94,95,96,97,98,99,100,101,102,103,104,105,126,127,106,107,108,128,129,130],"license","Apache-2.0","language","Rust","registryName","ai.kinlab/kin","homepage","https://kinlab.ai","packages",[121],{"_122":123,"_124":125,"_71":72},"registryType","npm","identifier","@kinlab/kin-mcp","mcp","mcp-server","static-analysis","tree-sitter","version-control","ENV",{"_133":134,"_135":136,"_137":138},"ENVIRONMENT","production","TURNSTILE_SITE_KEY","0x4AAAAAAB8-rEI2gNDf_QhU","SENTRY_DSN","https://45fd1229f78089d5c3ee78be128030e1@o4510583261757440.ingest.de.sentry.io/4510584253448272"]