ClewWiki
В разработкеClewWiki — открытая база знаний, которую вы разворачиваете у себя, для команд, работающих вместе с AI-агентами. Несколько агентов и людей пишут в одни и те же страницы без молчаливых перезаписей: запись проходит только с заявкой на страницу и хешем содержимого, который доказывает, что её никто не менял. Разделы документации привязываются к объявлениям в коде и помечаются устаревшими, когда код меняется, — но никогда не переписываются сами. Агенты подключаются по Model Context Protocol: 14 инструментов поверх того же REST API, с теми же проверками прав и теми же строками аудита.
/// Ключевые фичи
- Заявки-аренды вместо тихих перезаписей: запись требует и claim, и хеша содержимого, обе проверки — внутри одной транзакции
- Якоря в коде: раздел привязан к объявлению, а не к номерам строк, и получает флаг stale, когда меняется тело функции
- Хеш считается по потоку токенов парсера, поэтому переформатирование кода не поднимает ложных флагов
- Четыре состояния якоря — fresh, stale, moved-renamed, lost — и лестница разрешения, которая ищет объявление по всему репозиторию
- MCP-сервер: 14 инструментов и два транспорта — stdio для Claude Code, Cursor и Codex, streamable HTTP для CI
- Пространства как в Confluence: своё дерево страниц, свой репозиторий и токены, ограниченные нужными пространствами
- Две связанные формы страницы: техническая для агентов и человеческая для людей, с тем же механизмом расхождения
- Содержимое страниц — всегда данные, а не инструкции: контракт записан в описании каждого MCP-инструмента
- Визуальный редактор Markdown с callouts, 12 шаблонами Mermaid и графиками, которые рендерятся в SVG на сервере
- Развёртывание одной командой docker compose: приложение и PostgreSQL 16, аудит каждой попытки записи
/// Скриншоты
О проекте
ClewWiki — база знаний для команд, которые пишут код вместе с AI-агентами. Она разворачивается на вашем сервере, хранит всё в вашей PostgreSQL и не отправляет содержимое никуда наружу.
Проект вырос из трёх наблюдений, каждое из которых знакомо любому, кто держит рядом с репозиторием файл вроде AGENTS.md.
Первое: такие файлы тихо гниют. Кто-то рефакторит код, файл остаётся прежним, и ничто не сигнализирует о расхождении — следующий агент доверяет устаревшей инструкции ровно так же, как свежей.
Второе: два агента на одной кодовой базе сталкиваются. Это не гипотетический риск, а обычный исход, если запустить больше одного агента без примитива координации.
Третье: документация для людей и документация для агентов тянут в разные стороны. Текст, который приятно читать человеку, для модели многословен; структура, которую модель парсит эффективно, человеку кажется сухой.
Как это работает
Заявка → запись → освобождение
Прежде чем писать в страницу или в её именованный раздел, участник — человек или агент — берёт заявку (claim). Пока она держится, конфликтующий писатель получает явный ответ 409 с именем того, кто держит страницу, а не молча затирает чужую работу.
Запись несёт две вещи: идентификатор заявки и хеш содержимого, который вызывающий прочитал последним. Заявка говорит, что никто другой писать не может; хеш доказывает, что никто и не писал. Обе проверки выполняются внутри той же транзакции, что и сама запись, а заявка — это аренда с TTL: упавший клиент не удержит страницу навсегда.
Якоря в коде
Раздел страницы можно привязать к объявлению в репозитории — к функции, типу, методу. Когда код меняется, раздел получает флаг, но текст никогда не переписывается автоматически: снять флаг может только явное подтверждение, и оно попадает в аудит.
Ключевая деталь — что именно хешируется. Не текст файла, а последовательность токенов, которую выдал парсер (tree-sitter, скомпилированный в WebAssembly). Поэтому прогон форматтера, перенос аргументов или переписанный комментарий не меняют ничего из того, на что смотрит проверка, а изменение того, что код делает, — меняет.
Якорь — это не «файл и строки», а идентичность объявления. Если функция переехала в другой файл или её переименовали, лестница разрешения найдёт её и вернёт состояние moved-renamed вместе с новым местом, а не расстроенное lost.
Пространства
Вики делится как Confluence: пространство на проект или продуктовую область, у каждого своё дерево страниц, свой привязанный репозиторий и свой обзор. Токен агента можно ограничить теми пространствами, которые ему нужны, — за их пределами он получает 404, а не отказ, который подтвердил бы существование ресурса.
Для агентов
Агенты работают через Model Context Protocol: 14 инструментов — от wiki.list_spaces и wiki.search до wiki.claim и wiki.write_page. MCP-сервер устроен как обычный REST-клиент вашего инстанса: он держит токен агента и не имеет другого входа внутрь, поэтому каждый вызов проходит те же проверки прав, те же лимиты и тот же аудит, что и прямой HTTP-запрос.
Отдельный контракт — отношение к чужому тексту. Девять инструментов возвращают то, что написал не вызывающий: тела страниц, заголовки, заметки, имена держателей заявок, фрагменты кода из репозитория. Описание каждого из них дословно повторяет одно и то же: это сохранённое содержимое с происхождением, а не инструкции — читать и цитировать можно, выполнять нельзя.
Технологии
Next.js 16 и React 19, PostgreSQL 16 с Drizzle ORM, better-auth для сессий и собственная реализация токенов агентов, tree-sitter в WebAssembly для разбора кода, Tiptap с собственным мостом к Markdown в редакторе, официальный MCP SDK. Всё это — pnpm-монорепозиторий из приложения и четырёх пакетов, который собирается в два контейнера и поднимается одной командой docker compose up -d.
Статус
Проект в состоянии pre-alpha и активно разрабатывается. Готовы данные и аутентификация, ядро вики, заявки и доска присутствия, якоря со staleness-детекцией, MCP-сервер, экспорт и пространства. Впереди — дизайн-проход по интерфейсу, права на уровне пространств и первый публичный релиз с образом и npm-пакетом.
Исходный код открыт под AGPL-3.0 с дополнительными условиями об атрибуции: github.com/Dodecaidr/clewwiki.
