kin v0.3.6

ИИ-агенты могут написать изменение быстрее, чем команда успеет установить, чего оно касается, не отменяет ли оно более ранний фикс и насколько далеко простираются его последствия. Git фиксирует файлы и историю строк. Kin фиксирует само программное обеспечение как граф сущностей, связей, изменений и происхождения (provenance), а затем даёт людям и агентам единый семантический авторитет для запросов и ревью. То, чего касается изменение, видно до его слияния, а агенты работают с точным контекстом, а не перечитывают репозиторий.

Kin — это семантическая система записи (system of record) для программного обеспечения, написанного ИИ. Это публичная альфа, которую уже сегодня можно использовать как локальный CLI, демон, MCP-сервер, поверхность ревью и проекцию файловой системы на основе графа. Это версия до-1.0, так что ожидайте шероховатостей и ломающих изменений. Ознакомьтесь с последним стабильным релизом и текущими ограничениями, прежде чем внедрять его в критически важный рабочий процесс.

Посмотрите на реальном репозитории

Однострочное изменение сигнатуры в ripgrep выглядит в диффе безобидным. Спросите об этом kin impact до запуска любого компилятора — и он назовёт то, чего достигает правка. Сначала идёт вызывающий код изменённой сигнатуры, затем всё, что этот код тянет за собой.

Записано на подготовленном графе на коммите ripgrep e89fff89ac9af12e8d4ce9d5fd07beb408ca730f. 13 затронутых сущностей в пределах 3 хопов, включая 3 прямых вызывающих изменённой сигнатуры. Граф был построен заранее. Ни один компилятор не запускался. Точные команды: kinlab.ai/proof. Сырая директория запуска пока не публична, так что это рецепт, который можно перезапустить, а не трасса, которую можно проверить.

Kin показывает, чего касается изменение. Корректность изменения остаётся на вашем компиляторе, тестах и ревью. Граф заранее строится командой kin init, и его построение — дорогостоящая часть; после этого вопросы о влиянии получают ответы из истины графа, а не из повторного чтения дерева.

Стек

Kin — это одна система с несколькими понятными публичными поверхностями:

Как части сочетаются друг с другом

Kin — это семантическая система записи для ПО, написанного ИИ, и всё на схеме ниже либо обращается к этому авторитету, либо поддерживает его. Люди и ИИ-агенты входят через CLI, встроенный MCP-сервер или расширение VS Code. Все три интерфейса обращаются к одному и тому же демону, и демон отвечает из авторитета графа, а не перечитывая дерево. kin-vfs проецирует тот же граф обратно через обычные вызовы файловой системы, поэтому редакторы, компиляторы и сборочные системы продолжают видеть файлы. Git находится рядом с графом как граница импорта и экспорта, а не как путь для ответов, а KinLab — это хостинговый слой поверх того же авторитета.

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

Под этими поверхностями находятся слои, из которых построена система:

Это слои реализации одной системы, а не отдельные продукты, которые новому пользователю нужно собирать самостоятельно. Ни один из них не устанавливается отдельно.

Открытый исходный код и экосистема Kin

Ядро Kin открыто под лицензией Apache-2.0: kin, kin-db, kin-vfs и kin-editor, а также вспомогательные библиотеки kin-model, kin-blobs, kin-search, kin-vector, kin-infer, kin-lsp и kin-actions.

KinLab — проприетарный продукт, построенный на этом открытом ядре: хостинговый слой совместной работы и управления (control plane), описанный выше.

Та же граница действует и в отношении того, как публикуются бенчмарк-результаты. Спецификация бенчмарка и автономный верификатор бандлов без зависимостей являются публичными, так что утверждение можно проверить без доступа к системе, которая его породила. Раннер и инфраструктура доказательств, создающие запечатанные бандлы свидетельств (оркестрация, шлюз доказательств на закреплённых релизах и хостинговое измерительное окружение), пока остаются приватными. Сначала открываются спецификация и верификатор; раннер может быть открыт позже.

Самый короткий путь через граф

1. Установите и настройте Kin

На macOS или Linux:

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

Установщик находит последний стабильный релиз, проверяет его опубликованную SHA-256 контрольную сумму, устанавливает управляемые бинарники в ~/.kin и запускает настройку. Явное указание интента agent настраивает встроенный MCP-сервер для обнаруженных поддерживаемых клиентов. Используйте --intent local для использования CLI и файловой системы без настройки MCP или --intent editor для пути через VS Code.

Чтобы удалить только интеграции, управляемые настройкой, выполните kin setup uninstall. Для корневой управляемой директории по умолчанию (~/.kin) команда kin setup uninstall --all также останавливает все демоны Kin, удаляет точные блоки PATH от прежних установщиков и рекурсивно удаляет управляемую установку (--dry-run показывает предпросмотр). Пользовательский KIN_HOME никогда не удаляется рекурсивно: сначала выполните удаление в пределах учётной области (ledger-scoped), затем явно просмотрите и удалите эту директорию. Изменённые срезы, принадлежащие настройке, блокируют полное удаление, если не добавить --force, поэтому удаление никогда молча не перезаписывает отредактированную пользователем конфигурацию клиента или шелла. На Windows CLI планирует удаление своей заблокированной установочной директории сразу после завершения работающего процесса. Windows намеренно сохраняет один инертный сайдкар авторитета, доступный только текущему пользователю; сохранение стабильной идентичности этой блокировки предотвращает создание двух независимых авторитетов мутаций при сбое или при будущей параллельной установке. CLI и JSON-результат раскрывают эти сохранённые координационные метаданные, а не заявляют о нулевых остаточных байтах.

Для ручной установки каждый архив и его файл .sha256 публикуются по адресу https://github.com/firelock-ai/kin/releases/latest/download/. Имена перемещаемых артефактов: kin-macos-aarch64, kin-macos-x86_64, kin-linux-aarch64, kin-linux-x86_64 и kin-windows-x86_64; используйте суффикс .tar.gz, указанный на странице последнего релиза. Windows также публикует kin-windows-x86_64.zip — именно его загружают установщик PowerShell и npm-лаунчер.

Точка входа npm использует тот же публичный канал релизов:

npm install -g @kinlab/kin@latest

Homebrew tap отслеживает тот же канал релизов:

brew install firelock-ai/kin/kin

Формула tap генерируется, а не поддерживается вручную. Её версия и SHA-256 для каждой платформы перегенерируются из каждого релиза Kin с помощью update-formula.yml в репозитории tap, по dispatch-событию, которое отправляет сам релиз, с шестичасовой сверкой, самовосстанавливающей пропущенное событие. Именно поэтому контрольная сумма, которую проверяет Homebrew, — это та, что опубликована рядом с архивом, а не отдельно поддерживаемая её копия. Подтвердите установленную версию командой kin --version, как и на любом другом пути установки.

На Windows выполните irm https://get.kinlab.dev/install.ps1 | iex в PowerShell. Нативная поддержка Windows x86_64 находится на ранней стадии. Приём репозитория работает: kin init импортирует Git-репозиторий и публикует авторитет графа, а графовые, лексические запросы и запросы через демон отвечают нативно. Прозрачная проекция файловой системы в Windows не поставляется, и сквозное доказательство установки пока не покрывает там MCP- и ревью-сценарии, поэтому WSL2 остаётся рекомендованным путём для полного опыта Kin. Прочтите раздел Платформа и зрелость ниже, прежде чем выбирать путь установки на Windows.

2. Примите существующий репозиторий как истину графа

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

В обнаруженном Git-репозитории kin init атомарно принимает в графовый авторитет repository-v6 полную достижимую историю, ссылки (refs), сырые объекты, точное рабочее дерево и политику приёма. Рабочее дерево с незакоммиченными правками, изменениями в индексе или неотслеживаемыми файлами всё равно принимается: kin init принимает закоммиченное состояние и раскрывает, что именно не было принято. Он никогда не подменяет приём точным снапшотом HEAD или семантической пересборкой из сырой файловой системы. Поддерживаемые локальные URL удалённых репозиториев, refspec, отслеживание веток и настройки push по умолчанию запечатываются в конфигурацию сосуществования Kin с Git; небезопасные, неоднозначные или неподдерживаемые параметры передачи завершаются отказом (fail closed) до публикации.

Приём также выводит семантический слой сущностей и связей для каждого поддерживаемого файла-источника сущностей в этой истории, и kin init сообщает долговечные, привязанные к поколению счётчики, которые он зафиксировал. kin status сообщает представление авторитета репозитория; kin graph status отдельно сообщает о мутируемом живом графе запросов демона, который может включать более позднее производное обогащение. Поверхности запросов потребляют обогащение, принадлежащее графу, когда оно существует, и сообщают о его отсутствии, а не скрывают пробел за сырым поиском по файлам.

Какие файлы становятся сущностями

«Поддерживаемый файл-источник сущностей» означает файл, который заявляет один из языковых адаптеров Kin. Реестр адаптеров — это всё множество, и каждый файл в репозитории разрешается через него:

Заголовочный файл .h читается как C++, когда его содержимое говорит об этом, поэтому C++-проект не теряет пространства имён и шаблоны из-за грамматики C.

Всё остальное принимается как контент и остаётся доступным для запросов как история и текст, но не разбирается на сущности и связи. Сюда входят Markdown, HTML и CSS, SQL, YAML, JSON и TOML, shell-скрипты, Objective-C, Scala, Elixir, Dart, Lua, R, Zig, Haskell и Nix. Если ваш язык есть в этом списке, locate и refs не найдут в нём символы.

3. Задайте графу настоящий вопрос

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

Замените ExactEntityName на символ, возвращённый locate. locate находит сущности, релевантные намерению, refs показывает вызывающие/импортирующие объекты и ссылки, принадлежащие графу, а trace возвращает фокусную сущность вместе с ближайшим семантическим контекстом. После завершения эмбеддингов ваш настроенный ИИ-агент может использовать векторный инструмент semantic_locate; get_context_pack, find_references и trace_data_flow напрямую открывают окрестности графа.

Приём выводит семантические сущности, а не их векторы. Выполните kin embed, чтобы добавить локальное векторное сходство поверх них, и подтвердите покрытие командой kin graph status.

Ревью изменения, написанного ИИ

ИИ пишет код. Kin доказывает, что изменилось.

Выполните kin init на ветке, которую хотите просмотреть, чтобы соответствующая история Git оказалась в графе, затем передайте явные SHA коммитов теневому шлюзу только для отчёта (report-only shadow gate):

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

Результат — PASS, NEEDS ATTENTION или WOULD BLOCK, и он сопровождается влиянием, которое Kin вывел из графа, контекстом, необходимым для исправления, и свидетельствами, стоящими за обоими. Авторство декларируется, а не проверяется. Команда не заблокирует ваше слияние и не изменит состояние графа. Она передаёт свидетельства человеку или CI-политике и на этом останавливается.

Как Kin соотносится с Git

Рядом с Git сегодня. Авторитет репозитория со временем. При внедрении в существующую кодовую базу (brownfield) Git остаётся явной границей интероперабельности импорта/экспорта; он никогда не отвечает на запросы времени выполнения Kin и не восстанавливает отсутствующую истину графа.

• kin init импортирует полную достижимую историю Git и точные рёбра родителей. Kin намеренно не имеет режима частичной истории или инициализации только снапшотом.
• После импорта граф Kin владеет идентичностью репозитория, состоянием дерева, историей, ссылками и семантическими связями. Представления файловой системы и Git являются проекциями.
• kin git export --output ../repo.git записывает новую bare-проекцию Git из одного поколения авторитета, принадлежащего графу. Она не обращается к рабочим файлам или окружающему объектному хранилищу .git/ и отказывается от существующего назначения или назначения внутри репозитория. Объекты, ссылки и директории сбрасываются до подтверждения публикации в назначение без замены (no-replace). Публикация с привязкой к возможностям (capability-anchored) в настоящее время доступна на Unix-хостах; другие хосты отказываются до создания экспорта.

Это позволяет команде мигрировать существующий репозиторий, не отказываясь от своего редактора, компилятора, сборочной системы или интероперабельности с Git, пока Kin становится авторитетным.

Платформа и зрелость

Ядро выполнения и проекция файловой системы имеют разные границы поддержки:

Первая индексация читает всю достижимую историю Git, поэтому kin init на большом или долгоживущем репозитории занимает минуты, а не секунды, до начала эмбеддинга. После возврата init демон продолжает подготовку в фоне, и первые вызовы агента на большом репозитории могут отвечать заметно дольше.

Ограниченное тестирование на arm64 показало, что ядро графа и лексический путь работоспособны при 512 МБ, но полный эмбеддинг загружает модель примерно на 522 МБ и в настоящее время требует 2 ГБ как безопасный операционный минимум; 1 ГБ — опасная граница, а при 512 МБ процесс может завершиться во время эмбеддинга. Это наблюдаемые ограничения альфа-версии, а не универсальные обещания по ресурсам.

Успешный kin --version доказывает только то, что основной бинарник запускается. Он не доказывает совместимость VFS или живую проекцию на основе графа. На поддерживаемом Unix-хосте используйте kin setup status, kin-vfs status --workspace . и реальный запуск kin-vfs exec --workspace . -- <command>. VFS-лаунчер включает канареечную проверку интерпозиции (interposition canary) и сообщает, когда операционная система снимает шим. Полная граница описана в README kin-vfs.

Артефакты релиза публикуются с контрольными суммами, а релизный воркфлоу выполняет анонимную установку, проверки демона/MCP, эмбеддинга и реальной графовой VFS-проекции во всей матрице поддерживаемых раннеров. Сам воркфлоу публичен: Install Proof. Зелёный релиз подтверждает именно эти артефакты и окружения; это не заявление, что каждый дистрибутив, инструмент или форма репозитория уже покрыты.

Позиция по доказательствам

Опубликованный пререгистрированный доказательный пакет Multi-SWE-Bench Go закреплён за более старой сборкой, а не за движущимся последним релизом, и не устанавливает широких утверждений о скорости, экономии токенов или победе в категории. Сравнительные результаты здесь не приводятся до независимой проверки.

Ознакомьтесь с методологией, набором задач, идентичностью сборки и артефактами в публичном доказательном пакете. Относитесь к утверждениям за пределами измеренной области как к гипотезам, пока у них не появится собственное воспроизводимое доказательство.

Узнать больше и внести вклад

• Краткое руководство и расширенная конфигурация
• Размер хранилища и что на него влияет
• Справочник MCP-инструментов
• Поддержка языков и что извлекает каждый уровень
• Справочник переменных окружения
• Тезис «граф прежде всего»
• Модель авторитета записи и её переходное состояние
• Обсуждения на GitHub
• Отчёты об ошибках и запросы функций
• Руководство по участию
• Приватное информирование о безопасности

Лицензия

Apache-2.0.

Программное обеспечение, которое помнит себя.