How Kin keeps code connected.

• The graph

  Repository identity, tree state, history, refs and semantic relations, once kin init has imported the reachable Git history. Filesystem and Git views are projections of it.

• The daemon

  Holds the graph for a repository and answers queries. It discovers language servers once at startup, enriches the graph with resolved edges where one is wired, and runs embedding in the background under its own memory allowance.

• The CLI

  One caller of the daemon. kin locate, kin refs, kin trace and kin impact ask it questions; kin commit, kin branch, kin merge, kin blame and kin stash change and read the ledger; kin doctor grades the install.

• The MCP server

  The same graph, exposed to any agent client that reads a standard MCP config. kin setup writes the entry; kin mcp start serves it.

• Kin's own agent

  kin agent run drives any OpenAI-compatible endpoint over that same MCP server, with Kin's tools plus edit_file and write_file and nothing else.

• The filesystem projection

  kin-vfs serves graph content as ordinary files so compilers, editors and shells need no change. Four modes: an injected shim, an NFS mount, a FUSE mount and Windows ProjFS.

• The Git export

  kin git export writes a new bare Git repository from one generation of the graph. It reads no working files and no ambient .git store.

• KinLab

  The hosted product for teams, in development. It is a separate product over the same model and is not part of the local release claim.

Some coding tools save a checkpoint of your working files on a timer, so you can roll back to any minute of the afternoon. That is useful, and Kin does not replace it. A checkpoint restores text. It cannot tell you which other code uses the piece you just changed, because it never recorded that.

Kin records history per entity rather than per file, and it records semantic changes rather than snapshots, so a change carries what it did to the graph: which entities were added or modified, how a signature moved, which relations appeared. That is what makes kin history answer about a function and kin blame answer with the signature at each revision. It is also why a change committed with Git alone does not appear in either: Kin history is built from semantic changes, and a Git commit does not create one.

Run both. A checkpoint tool and Kin answer different questions, and neither one covers for the other. The history page walks the recording path end to end.

Admission reads a Git repository and builds Kin authority from it, keeping the origin of every change, and Git keeps working the whole time: recording a change in Kin does not move Git, and export writes a new Git repository back out from graph truth. That is a coexistence path today rather than a replacement, which is what kin capabilities says about itself.

The Git page walks that path with the commands run and the output they printed, including what git status and git log report while Kin holds a change.

Compilers, linters and editors expect a raw filesystem; none of them know what a code graph is. Rather than write a FUSE mount driver, kin-vfs's default mode achieves transparent filesystem projection through dynamic library interposition: a shim injected with LD_PRELOAD on Linux or DYLD_INSERT_LIBRARIES on macOS intercepts low-level libc calls such as open(), openat() and read().

Kin's test suites and benchmarks evaluate core repository subsystems through reproducible runs:

• The native CLI and daemon on new projects, imported Git repositories, and complete version-control sessions.
• Model Context Protocol (MCP) tool integration: connecting AI coding agents to graph status, references, and focused context queries.
• Native branching, merging, conflict resolution, multiple undo tiers, and semantic history inspection.
• Git export integrity: full tree export where working-tree files match their exported copy by SHA-256 across multiple independent runs.
• Local network transport: HTTP-based clone, push and pull between distinct repositories, preserving history and file contents byte for byte.