Сценарии использования: Эволюция базы знаний

База знаний — почти живой организм, который должен расти естественно. В архитектуре сервера заложены сценарии для каждого этапа её зрелости.

---

🐣 Этап 1: Быстрый старт в режиме LUCA

Контекст: Ваша база знаний абсолютно новая или содержит небольшой набор хаотичных заметок. У вас еще нет структуры, нет ядер, нет паттернов. Вы не хотите тратить время на проектирование, вам нужно просто фиксировать информацию.

Сценарий взаимодействия: Вы можете подсказать структуру базы агенту, и он начнёт строить граф с простыми родительскими связями.

На этом этапе достаточно базового цикла:

1. Запустить index_all, чтобы сервер увидел Markdown-файлы.
2. Посмотреть обзор через list_files.
3. Открыть отдельные заметки через read_file.
4. Добавить простые hierarchy или temporary связи через update_metadata.

temporary особенно полезна для входящих заметок: материал уже не потерян, но его место в структуре можно выбрать позже.

---

🏗️ Этап 2: Кристаллизация ядер и паттернов (Осознанная структура)

Контекст: Ваша база выросла (например, до 50–100 заметок). В ней отчетливо начинают проступать сквозные темы: рабочие проекты, хобби, профессиональные дисциплины.

Сценарий взаимодействия: Выбирайте режим PRIZMA или SLOI и стройте онтологию, начиная с ядер - центральных осей структуры вашей базы.

• Результат: ИИ мгновенно меняет «оптику». Теперь, когда вы добавляете новую мысль, он не просто ищет случайные ассоциации, а проверяет, к какому ядру или модулю относится текст, предлагая структуру.

Технически этот этап начинается с config.yaml: вы описываете эталоны, запускаете calibrate_cores, затем index_all с with_embeddings=true. После этого suggest_metadata уже может показывать доменный знак, мосты, предупреждения по иерархии и качество тегов.

---

🏭 Этап 3: Квантовая фабрика

Контекст: База знаний превращается в полноценную рабочую среду. Вы накапливаете много сырого материала (заметок, промптов, логов, мыслей) и регулярно выпускаете готовый продукт (посты, статьи, отчеты, закрытые задачи).

• Сценарий взаимодействия:

  1. Сбор сырья: Вы сохраняете в базу утилитарные файлы. ИИ вешает на них знаки Артефактов.
  2. Кристаллизация продукта: Вы публикуете пост в свой Телеграм-канал на основе накопленного сырья и знаний.
  3. Фиксация транзакции: Вы просите ИИ зафиксировать результат. Сервер предлагает создать кванта и автоматически собирает для него сложный составной знак.

• Результат: ИИ за долю секунды понимает «генетический паспорт» этой заметки. База строго разделена: теоретические знания лежат в ядрах, сырье — в артефактах, а история ваших реальных достижений — в квантах. Граф защищен от логических петель валидацией DAG.

---

След происхождения: derived_from

Когда квант появляется из артефакта, эту связь лучше фиксировать отдельно от иерархии.

parents_meta:
  - entity: ТГ-канал
    link_type: hierarchy
  - entity: Лог разговора с пользователем
    link_type: derived_from

hierarchy отвечает за место результата в конвейере. derived_from показывает, из какого лога, источника, гипотезы, спецификации или предыдущего решения он появился.

Это особенно важно в фабрике контента: один лог может дать пост, тезис, задачу и будущий раздел статьи. Все эти кванты могут жить в своих модулях, но сохранять общий след происхождения.

---

Рабочий протокол агента

Хороший рабочий порядок:

1. list_files — посмотреть обзор базы.
2. read_file — открыть конкретную заметку и ее YAML.
3. get_parents / get_children — понять место заметки в графе.
4. suggest_metadata — получить предложения по уровню, знакам, связям и предупреждениям.
5. update_metadata — изменить только YAML, если текст трогать не нужно.
6. write_file — использовать для новой заметки или полной замены файла.

Для существующих заметок безопаснее начинать с чтения. Для чистой разметки подходит update_metadata. Для нового результата, выросшего из источника, добавляйте derived_from.

---

⚡ Важно

Этот сценарий работает всегда, защищая ваше контекстное окно и кошелек от перерасхода токенов LLM, но это не строгая классификация. Вы можете использовать типы сущностей под свои задачи и свою структуру базы. Для PRIZMA и SLOI важно отдельно проверить качество эталонов: если ядра плохо расходятся в embedding-пространстве, автоматические знаки и мосты будут слабыми. Подробно это разбирается в разделе Проверка качества эталонов.