KAUT — Актуализация знаний на основе доверия

Делает легаси-кодовые базы ИИ-нативными. KAUT — это самоподдерживающаяся, ориентированная на ИИ документация для вашего проекта — слой знаний, который делает недокументированный, слабоконтекстный код понятным для ИИ-агентов. Не память о разговорах — база знаний о самой системе: что она делает, как устроена и почему. Он превращает то, что агенты узнают во время работы, в живую документацию — так что ни одна сессия не начинается с нуля.

Node.js без зависимостей (≥ 20, разработано на 24), Apache-2.0. Разработано и протестировано на macOS и Linux (CI работает на Linux, Node 20 и 24); Windows не поддерживается.

Полноценный автономный продукт. Один git clone — это вся установка; укажите вашему харнесу на встроенный MCP-сервер (или вызывайте CLI из любого скилла/промпта) — и он работает: ни оркестратора, ни фреймворка, ни сервисов, ни аккаунтов, ничего больше разворачивать не нужно. Он сочетается с родственным фреймворком оркестрации TAUT (TAUT управляет агентами, KAUT — это то, что они знают) — но эта интеграция опциональна, а не обязательна.

Статус: v0.8.1 — полный цикл работает. Чтение: lookup (готовый ответ за один вызов) с вердиктами свежести (привязанными к merge-base, никогда не кричащими «свежо» при неуверенности), уровнями доверия и полосой покрытия altitude; защита от подделки скрывает всё, что отредактировано вне конвейера. Мультирепозиторность: реестр рабочего пространства, хранилища для каждого участника, одно системное хранилище, привязанное к репозиторию-запускателю. Запись: многоуровневый шлюз записи (обновления уровня агента попадают напрямую; слои, управляемые владельцем, и новые документы ставятся в очередь как черновики для асинхронного ревью). Обслуживание: refresh (дельта-пакеты повторного вывода), touched (датчик мест изменений), digest/note (телеметрия использования и результатов). Совместимость: хранилища соответствуют планке конформности OKF v0.2, а kaut okf export создаёт идиоматические OKF-пакеты. Любая обвязка, поддерживающая MCP, подключается через встроенный MCP-сервер. Что именно работает, подробно: docs/HANDBOOK.md §16.

Проблема, которую он решает

Каждая новая ИИ-сессия начинается с амнезии: агент заново исследует ваш проект, снова задаёт те же вопросы и — что хуже всего — продолжает совершать самую дорогостоящую ошибку: код, который компилируется и проходит тесты, но тихо нарушает бизнес-правило, о котором он не мог знать.

«Почему» проекта обычно нигде не записано. KAUT даёт этому место для жизни — и поддерживает его в живом состоянии.

Это больнее всего сказывается на легаси-коде: годы недокументированных решений, рядом нет авторов, бизнес-правила видны только как побочные эффекты. Именно здесь современные ИИ-инструменты для кодинга показывают худшие результаты — и именно для таких кодовых баз создан KAUT. KAUT — первый шаг к более крупной цели: сделать легаси-кодовые базы ИИ-нативными — структурированными так, чтобы агенты могли безопасно и дёшево работать с ними.

Related MCP server: 50 First Tapes MCP Server

Что такое KAUT — и чем он не является

Не очередная система памяти. Память отвечает на вопрос «о чём мы говорили, что предпочитает этот пользователь?» — личное, эпизодическое, непроверяемое. KAUT отвечает на вопрос «как работает этот проект и почему?» — документация: организованная по доменам, привязанная к источникам, проверенная на свежесть, помеченная уровнем доверия и читаемая любым агентом и людьми. Личные заметки никогда не попадают в KAUT; знания о проекте никогда не остаются запертыми в памяти одного агента. Эта граница встроена в путь записи.

Не RAG. Генерация с дополнением извлечением (RAG) индексирует любой существующий текст и подаёт наиболее подходящие фрагменты — без понятия, актуальны ли они. KAUT хранит противоположный отбор: только знания, которые дорого перевыводить и которые не видны напрямую в коде (лакмусовая бумажка хранения), дистиллированные в короткие документы, которые модель читает целиком — без эмбеддингов, ранжирования и каши из фрагментов. И каждый документ несёт машинно-проверяемый вердикт свежести: привязан к коммиту, из которого он выведен, сравнивается с отслеживаемой основной веткой при каждом чтении, склоняясь к устареванию, когда git не может доказать обратное. Запускайте RAG по своему коду, если хотите — KAUT для того, что код не говорит: почему, сквозные инварианты, племенные знания.

Не LLM-вики. Автоматически сгенерированная документация — это правдоподобный текст, непроверенный при рождении и заброшенный после первого коммита. Документ KAUT не может существовать без типизированных привязок к источникам и якорного коммита — и не может оставаться неверным молча, потому что источники сравниваются при каждом чтении. Путь записи — вторая половина: механические слои регенерируются автоматически, агенты могут размещать операционные факты, которые они проверили в ходе сессии, но знания уровня суждений (решения, семантика домена, контракты) попадают только через одобренный человеком шлюз — обновления ставятся в очередь как черновики, которые вы просматриваете пакетно. Вики по умолчанию разлагается; умолчание KAUT — признаваться.

И это не проприетарное хранилище. KAUT — реализация вендоронейтрального Open Knowledge Format (OKF) v0.2 — хранилища представляют собой типизированные markdown-документы концепций, которые на месте удовлетворяют планке конформности OKF, а kaut okf export проецирует любое хранилище в полностью идиоматический OKF v0.2-пакет (включая семейства происхождения, доверия и жизненного цикла), читаемый любым OKF-потребителем. Механизмы свежести/доверия KAUT работают поверх как защищённые OKF-ключи расширений: формат записывает знания — движок поддерживает их истинность. Нормативное отображение находится в SCHEMA.md.

Принципы

1. Привязанность к источникам и коммитам. Каждый факт называет файлы, из которых он получен, и коммит, на котором он выведен. Нет источника — нет документа: контракт проверяется на входе.

2. Склонность к устареванию. Свежесть — это чистое вычисление на основе git (merge-base относительно отслеживаемой основной ветки). Когда git не может доказать актуальность документа, вердикт говорит об этом. KAUT никогда не кричит «свежо» при неуверенности — ложное «устарело» стоит повторной проверки; ложное «свежо» выпускает баг.

3. Знание информирует; оно никогда не авторизует. Здоровый вердикт — это разрешение пропустить повторное выведение, а не разрешение действовать. Вердикты направляют доверие: здоровый + точный = можно использовать как есть; устаревший / сломанный / грубой высоты = сначала подтвердите в коде.

4. Не подавайте то, за что не можете поручиться. Хранилище читается ИИ-агентами, поэтому правка вне конвейера — это канал инъекций, а не удобство. Всё, что не побайтово идентично последнему коммиту конвейера, полностью скрывается (tampered), пока не будет восстановлено или легитимно размещено.

5. Люди владеют суждениями; агенты владеют механикой. Многоуровневый шлюз записи: карты регенерируются свободно, проверенные операционные факты попадают на уровень агента, а знания о решениях/доменах/контрактах ждут в очереди черновиков для одноклавишного ревью владельцем.

6. Ремонт там, где это дешевле всего. С устареванием борются структурно, а не героически: место изменения (touched называет документы, которые код-изменение должно обновить), место чтения (устаревший вердикт приходит с дельта-пакетом refresh — что именно изменилось, относительно чего перевыводить) и честная телеметрия (digest), чтобы видеть, успевает ли обслуживание.

7. Локально-ориентированный, без зависимостей, не трогает репозиторий. Один клон, без шага установки, без демона, без облака; хранилище знаний живёт вне вашего репозитория, а проверки свежести стоят сравнений git — а не вызовов моделей.

Что делает KAUT

• Одно известное место для поиска. Агент проверяет KAUT перед повторным исследованием вашего кода. Либо ответ там есть, либо KAUT отмечает пробел, чтобы он был заполнен позже.

• Знание собирается само. После выполнения задачи полезные вещи, которые агент только что узнал, конденсируются в базу — побочный продукт уже оплаченной работы, а не отдельный проект документации.

• Оно никогда не лжёт уверенно. Каждый сохранённый факт остаётся привязанным к коду, из которого он получен. Когда этот код меняется, факт автоматически помечается как возможно устаревший. При сомнении KAUT говорит «перепроверьте это» вместо того, чтобы притворяться, что всё свежо.

• Оно отказывается подавать то, за что не может поручиться. База знаний читается ИИ-агентами, поэтому файл, отредактированный за спиной KAUT (вне его собственного контроля версий), — потенциальный канал инъекций. Такой контент полностью скрывается, пока не будет восстановлен или правильно перекоммичен — каждый ответ, который видит агент, исходит из коммита с отслеживаемым происхождением.

• Вы остаётесь судьёй. Слои, управляемые владельцем, и новые документы никогда не попадают без вашего одобрения: обновления ставятся в очередь как черновики (kaut draft), и вы принимаете или отклоняете весь пакет за один присест (kaut review). Вам не нужно присутствовать, когда агент заканчивает.

• Ваш репозиторий никогда не затрагивается. Все знания живут в отдельной папке вне проекта. Ваша история git, ветки и коллеги никогда этого не видят.

• Любой агент может подключиться. Помимо CLI, KAUT поставляет MCP-сервер (node <engine>/mcp.mjs, без зависимостей) — те же поиски, вердикты свежести и управляемые записи в виде MCP-инструментов для любой обвязки или оркестратора, поддерживающих MCP. Один сервер обслуживает целое мультирепозиторное рабочее пространство (каждый вызов называет свой репозиторий).

Архитектура

flowchart LR
    subgraph clients["Clients"]
        direction TB
        HARNESS["AI agents\nany MCP-capable harness"]
        HUMAN["Humans and CI\nshell, scripts"]
        ORCH["Orchestrator, e.g. TAUT\n(optional)"]
    end

    subgraph engine["KAUT engine - stateless, zero-dep Node, no daemon"]
        direction TB
        SURF["Two surfaces\nmcp.mjs - 7 MCP tools\nkaut.mjs - CLI"]
        READP["READ path (lock-free)\nlookup / stale / digest\nfreshness verdict = pure git computation\n+ trust tier + altitude on every answer"]
        WRITEP["WRITE path (one chokepoint)\nlayered write gate + draft queue\nagent tier lands, judgment tier\nwaits for owner review"]
        MAINTP["Maintenance loop\nrefresh / touched / note\nmap collectors (stack adapters)"]
    end

    subgraph home["Knowledge data home - set once with kaut home"]
        direction TB
        STORES["One store per repo\ntyped markdown + frontmatter\nown private git = audit + rollback\njournal telemetry"]
        REG["workspaces registry\nmember stores + one system store"]
        BACK["backups/\nkaut backup / restore"]
    end

    REPOS["Your repositories\nREAD-ONLY sources\n(at most one git-ignored pointer file)"]
    OKFB["OKF v0.2 bundle\nkaut okf export"]

    HARNESS --> SURF
    HUMAN --> SURF
    ORCH --> SURF
    SURF --> READP
    SURF --> WRITEP
    SURF --> MAINTP
    READP -- "diff sources against\nthe anchor commit" --> REPOS
    MAINTP -- "derive maps from code" --> REPOS
    READP <--> STORES
    WRITEP --> STORES
    STORES --> OKFB

Форма в четырех предложениях. Движок не хранит состояние — каждая команда (CLI или MCP-инструмент) вычисляет ответ из двух git-историй и завершается; нет ничего резидентного, что можно было бы запустить, синхронизировать или повредить. Знания живут вне ваших репозиториев — одно хранилище на репозиторий в домашней папке данных, и каждое хранилище — это собственный приватный git-репозиторий, что и делает возможными шлюз записи, изоляцию от подделок, аудит и откат. Путь чтения никогда не блокируется и никогда не гадает: вердикт выводится сравнением типизированных источников документа с его якорным коммитом в момент запроса. Путь записи имеет ровно одну точку контроля, поэтому политику (уровень агента против проверки владельцем) нельзя обойти, выбрав другую команду.

Быстрый старт

1. Клонируйте движок рядом с репозиториями, которым он будет служить (соседняя папка — установка сканирует соседей; npm install не нужен, у движка ноль зависимостей):

cd ~/projects && git clone https://github.com/yurgeno/kaut.git

2. Запустите setup — три вопроса, и у каждого ответа есть флаг для скриптовой установки:

node kaut/kaut.mjs setup

• Папка данных знаний — где живут хранилища (по умолчанию: <siblings>/kaut-data). Сохраняется один раз (редирект kaut home): каждая последующая команда и MCP-сервер разрешают её сами — ничего экспортировать или передавать не нужно. Эта папка — живые данные: движок только добавляет в неё; ничего существующего не стирается и не перезаписывается.

• Какие репозитории — setup перечисляет все соседние git-репозитории; ответьте all, номерами или именами.

• Запустить bootstrap сейчас? — «да» создаёт/актуализирует хранилище для каждого выбранного репозитория на месте (идемпотентно: существующие хранилища актуализируются, но никогда не пересоздаются); «нет» — просто записывает конфигурацию и печатает команды для каждого репозитория на потом.

Нелинейный режим: node kaut/kaut.mjs setup --data <dir> --repos all --bootstrap --yes (--no-bootstrap, --scan <dir> для сканирования в другом месте).

3. Следуйте напечатанным следующим шагам — setup завершается ровно двумя: подключите MCP-сервер к вашей обвязке и вставьте контракт знаний в инструкции вашего агента (оба — ниже). При желании сгенерируйте механическую карту для каждого репозитория:

node kaut/kaut.mjs map

(bootstrap уже определил ваш стек и засеял нужные коллекторы — см. Поддерживаемые стеки ниже; коллектор, чей вход отсутствует, пропускает себя с пометкой, а map.collectors: [] означает, что слой карты просто остаётся пустым).

Поддерживаемые стеки

Bootstrap, цикл знаний, вердикты свежести, шлюз записи — всё это не зависит от стека: подходит любой git-репозиторий. Только механический слой map/ зависит от стека, и bootstrap автоопределяет стек и засевает map.collectors соответственно (существующие конфигурации никогда не трогаются; каждая ручка остаётся переопределяемой):

Репозиторий без узнаваемого стека получает пустой слой карты, и всё остальное работает так же. Лексические коллекторы — честные сканирования «по мере возможности», помеченные как таковые в сгенерированном документе. Адаптеры для дополнительных стеков — намеренно небольшие модули — см. CONTRIBUTING.md, если вашего стека нет.

Подключение агентов — шаг, который делает всё реальным

Хранилище само по себе ничего не меняет: ваш агент должен знать, что оно существует и когда к нему обращаться. Два шага (полное руководство с готовыми к вставке блоками и разобранной сессией: docs/AGENT-INTEGRATION.md):

1. Подключите MCP-сервер к вашей обвязке (.mcp.json для Claude Code, config.toml для Codex — фрагменты в руководстве). Семь инструментов kaut_* появляются в каждой сессии, и их описания уже обучают модель дисциплине: ищи перед повторным исследованием, доверяй по вердикту, записывай через шлюз.

2. Вставьте контракт знаний в то, что ваш агент загружает в каждой сессии (CLAUDE.md / AGENTS.md / системный промпт) — блок примерно на 15 строк из руководства, который делает поведение надёжным, а не случайным: читай перед повторным выводом; здоровый и точный = используй как есть, устаревший/грубый = подтверди в коде; помечай результаты тегом kaut_note; после редактирования файлов запускай kaut_touched и чини или ставь в очередь то, что должно изменение.

При желании оформите контракт как навык обвязки (шаблон в руководстве) или позвольте оркестрационному фреймворку собрать подключение за вас — TAUT делает это по одному ответу из setup. Затем: работайте как обычно. Если захотите просмотреть сами, node <engine>/kaut.mjs lookup печатает каталог тем.

Повседневное использование — его нет

KAUT спроектирован быть невидимым. Вы заметите его ровно в три момента:

• По вашей команде — скажите агенту сохранить то, что он только что узнал («persist this to KAUT»): он пропускает находки сессии через лакмусовый тест, записывает их с правильными привязками к источникам и коммитит в git хранилища. Знания, требующие проверки владельцем, по-прежнему останавливаются в очереди черновиков для вашего ревью.

• Когда накапливаются черновики — kaut review перечисляет ожидающее вас; одобрите или отклоните партию за один присест (doctor также предупреждает, пока очередь ожидает).

• Изредка агент задаёт вопрос, на который может ответить только человек («это правило намеренно или случайность?»). Ваш ответ становится самым ценным видом знания в базе.

Всё остальное — поиск, проверка свежести, пересборка карты — происходит автоматически и незаметно.

Команды

Запускайте из любого места внутри git-репозитория проекта:

node <engine>/kaut.mjs setup         # guided install: data home, sibling-repo scan, bootstrap (run once, from anywhere)
node <engine>/kaut.mjs bootstrap     # create/repair the project's knowledge store (idempotent)
node <engine>/kaut.mjs index         # regenerate INDEX.md (under lock; auto-commits changes)
node <engine>/kaut.mjs doctor        # integrity checks; exit 0 = healthy
node <engine>/kaut.mjs home [<dir>]  # show or set the knowledge-data home (redirect at ~/.kaut/config.json)
node <engine>/kaut.mjs paths         # print resolved {projectId, root, engine, repo, mainBranch, source}
# reading core:
node <engine>/kaut.mjs lookup [<id>] # one-call ready block; no id = catalog; unknown id = miss (exit 0)
node <engine>/kaut.mjs stale [<id>…] # freshness verdicts for all/selected docs (read-path, no lock)
node <engine>/kaut.mjs map           # regenerate L0 maps per config map.collectors + commit
# maintenance loop:
node <engine>/kaut.mjs refresh [<id>…]        # per-doc re-derivation delta bundles (read-only)
node <engine>/kaut.mjs draft <id>             # queue a finished doc update for async owner review
node <engine>/kaut.mjs review [<id>…]         # owner side: list / diff / --approve / --reject
node <engine>/kaut.mjs touched <file>…        # which docs bind the given changed files
# telemetry:
node <engine>/kaut.mjs note <topic> <result>  # record an in-session outcome (trusted|confirmed|insufficient|stale-misled)
node <engine>/kaut.mjs digest [--since <ISO>] # aggregate journal telemetry across workspace stores
# backup / restore (the whole data home — stores, registry, setup record):
node <engine>/kaut.mjs backup                 # dated, versioned .tar.gz under <data>/backups/
node <engine>/kaut.mjs restore [latest|<file>] [--force]   # no arg = list; never overwrites without --force
# open format (OKF v0.2):
node <engine>/kaut.mjs okf check              # store-as-OKF-bundle conformance report (exit 0 = conformant)
node <engine>/kaut.mjs okf stamp              # backfill `type:` on legacy docs (through the write gate)
node <engine>/kaut.mjs okf export --out <dir> # project committed HEAD into an idiomatic OKF v0.2 bundle
# workspace (multi-repo):
node <engine>/kaut.mjs workspace init --manifest <conductor>/manifest.json
                                     # registry + member stores + ONE system store anchored to the launcher
node <engine>/kaut.mjs workspace list

MCP-сервер: node <engine>/mcp.mjs — JSON-RPC-сервер stdio с нулевой зависимостью, предоставляющий глаголы сессии как MCP-инструменты (kaut_lookup, kaut_note, kaut_refresh, kaut_touched, kaut_write, kaut_draft, kaut_status). Каждый инструмент принимает необязательный аргумент repo, так что один сервер обслуживает целое мультирепозиторное рабочее пространство. Эскап-команды владельца (review --approve, index --approve) намеренно не предоставляются через MCP.

Флаги: --dry-run (печатать действия без выполнения) · --json (машинный вывод для stale|lookup|refresh|review|touched|digest) · --quiet · --approve / --reject (выполняется владельцем) · --force (restore: перезаписать существующие данные; okf export: запись в непустую папку) · --out <dir> (okf export) · --note <text> (note, review --reject) · --manifest <path> (workspace init) · --workspace <name> (doctor/stale/digest по рабочему пространству) · --since <ISO-date> (digest) · --help/-h (справка, выход 0).

Коды выхода: 0 — успех · 1 — ошибка валидации/doctor · 2 — хранилище занято (удерживается блокировка) · 3 — окружение отсутствует (не git-репозиторий / хранилище не инициализировано).

lookup и stale — путь чтения — они не берут блокировку и только дописывают строку в journal.jsonl (телеметрия использования, не отслеживается). Вердикт свежести — это данные, а не ошибка: stale завершается с кодом 0, даже если документы устарели. Строка вердикта, максимум одна, по приоритету tampered > disputed > broken > stale > branch-advisory; здоровый документ выводится чисто.

Операционная глубина — структура хранилища на диске, порядок разрешения, изоляция от подделок и шлюз записи в деталях, удаление, внутренности движка: docs/OPERATIONS.md.

Конфигурация

Один файл: kaut.config.json в хранилище (создаётся bootstrap, разумные значения по умолчанию). Большинство людей трогают только блок map (список коллекторов и расположение файлов — см. примечание в быстром старте выше). Полный справочник того, что движок реально читает: docs/HANDBOOK.md §15.

Действительно ли это помогает?

KAUT построен так, чтобы оставаться честным перед собой:

• Он ведёт журнал использования для каждого хранилища (journal.jsonl): каждый поиск с его вердиктом, каждая запись через шлюз, каждый зафиксированный результат. kaut digest агрегирует его по рабочему пространству в показатели охвата / самоподдержки / ценности.

• Сессии фиксируют, как документ реально показал себя (kaut note <topic> trusted|confirmed|insufficient|stale-misled) — сигнал ценности на честном слове, показывающий, где знания сэкономили работу, а где ввели в заблуждение.

• Бенчмаркинг выполняется внешне (запустите одну и ту же задачу с KAUT и без и сравните); движок намеренно не поставляет собственный бенчмарк-харнесс.

Журнал — это телеметрия только на добавление, не отслеживаемая, и растёт без ограничений; безопасно вручную обрезать старые строки (это никогда не знания, и digest просто увидит более короткую историю).

Резервное копирование

Папка данных — это вся база данных; относитесь к ней соответственно. kaut backup упаковывает весь домашний каталог данных (каждое хранилище с его git-историей, реестр рабочих пространств, запись установки) в датированный, версионированный архив в <data>/backups/ — обычный .tar.gz (собственный ustar + node:zlib, ноль зависимостей), который также читается любым стандартным tar-инструментом. kaut restore latest (или имя файла) возвращает его; ничего существующего никогда не перезаписывается без --force — отказавший restore перечисляет конфликты и ничего не трогает.

Тесты

cd <engine> && node --test          # 213 tests, zero deps (node:test)

Запускайте голый node --test — не передавайте каталог тестов как аргумент (на Node ≥ 24 такая форма не может разрешить набор тестов).

Удаление

Удалите каталог хранилища (~/.kaut/<project-id>) и файл-указатель (<repo>/.kaut.json), и уберите строку .kaut.json из <repo>/.git/info/exclude. Ваш репозиторий и так никогда не изменялся — больше нечего чистить.

FAQ

Это просто очередная система памяти агента? Нет. Память агента запоминает разговоры и предпочтения; KAUT — это документация проекта — AI-first, привязанная к источникам, с проверкой свежести. Путь записи обеспечивает границу: знания проекта идут в KAUT, личные предпочтения — в собственную память агента.

Это RAG? Нет. Здесь нет эмбеддингов, нет чанкинга, нет ранжирования при поиске. KAUT хранит небольшой набор дистиллированных документов, которые агент читает целиком, каждый с происхождением и вердиктом свежести, вычисленным через git, — и намеренно хранит только то, что не дёшево выводится из кода. RAG по вашей кодовой базе и KAUT отвечают на разные вопросы и прекрасно сосуществуют.

Это автогенерируемая вики? Нет. Ничто не попадает в хранилище как непроверенная сгенерированная проза: каждый документ должен нести типизированные привязки к источникам и якорь коммита, механические слои регенерируются (а не галлюцинируются), а знания уровня суждений проходят шлюз с одобрением человека. И в отличие от вики, документ KAUT не может тихо протухнуть — его источники сравниваются при каждом чтении.

Формат хранилища проприетарный? Нет — наоборот. KAUT реализует вендор-нейтральный Open Knowledge Format (OKF) v0.2: обычные типизированные markdown-документы-концепты. Любой OKF-потребитель может читать хранилище, а kaut okf export создаёт полностью идиоматичный OKF-бандл. Никакой привязки: ваши знания — это переносимый markdown в git-репозитории в любом случае.

Будет ли он что-то коммитить в мой репозиторий? Нет. Максимум один игнорируемый файл-указатель. Хранилище знаний находится вне репозитория.

Должна ли моя команда его внедрять? Нет. KAUT — локальный по своей природе: один разработчик устанавливает его и получает выгоду; никто другой не вовлекается и не затрагивается.

Что если сохранённый факт неверен? Каждый факт несёт своё происхождение и метку доверия; агент относится к фактам с низким доверием скептически и проверяет их по коду. Хранилище сохраняет полную историю, поэтому ошибочные записи можно отследить и откатить.

Сколько это стоит в эксплуатации? Первая сборка карты — самая затратная часть (минуты). Повседневное обслуживание спроектировано так, чтобы стоить почти ничего: проверки актуальности — это чистые сравнения git, без вызовов ИИ.

Узнать больше

• Вики проекта — «Начало работы», «Подключение вашего проекта», «Основные концепции», «Цикл обслуживания», «FAQ и устранение неполадок» в виде руководства

• docs/HANDBOOK.md — как всё это работает, человеческим языком, но во всех деталях

• docs/OPERATIONS.md — справочник оператора: структура на диске, разрешение, защита от вмешательства, шлюз записи, внутренности движка

• docs/AGENT-INTEGRATION.md — подключение агентов к хранилищу: контракт знаний, фрагменты для каждой обвязки, шаблон навыка, проработанный сеанс

• docs/MCP.md — справочник MCP-сервера: регистрация, все 7 инструментов, протокол

• SCHEMA.md — нормативный контракт данных, который реализует этот движок (включая карту соответствия OKF v0.2)

• CHANGELOG.md — история релизов

• CONTRIBUTING.md · SECURITY.md · CODE_OF_CONDUCT.md

Лицензия и цитирование

Apache-2.0 — см. LICENSE и NOTICE. Если вы используете KAUT или строите на концепциях, которые он реализует, пожалуйста, цитируйте его через CITATION.cff.

Контакт: Yuriy Orlov yuriy.orlov@undertrust.dev