@dzhechkov/keysarium 1.1.2 → 1.3.0

package/templates/docs/keysarium-core/05-user-guide.md

@@ -0,0 +1,599 @@
+# Руководство пользователя @dzhechkov/keysarium-core
+
+> Полное руководство по использованию keysarium-core -- домен-агностичного фреймворка для мультиагентных AI-пайплайнов.
+
+---
+
+## 1. Что такое keysarium-core?
+
+**keysarium-core** -- это «операционная система» для мультиагентных AI-пайплайнов. Фреймворк предоставляет инфраструктурные протоколы, а вы приносите доменную экспертизу и навыки.
+
+### Ключевые принципы
+
+- **Domain-agnostic:** протоколы не привязаны к конкретной предметной области. Банкинг, ритейл, DevOps, образование -- keysarium-core работает везде.
+- **Protocol-as-Code:** все протоколы написаны в markdown. AI-агенты читают их и следуют инструкциям. Нет компиляции, нет бинарных зависимостей.
+- **Модульность:** шесть независимых модулей. Используйте один, три или все шесть -- каждый работает автономно.
+- **Инфраструктура, а не логика:** keysarium-core управляет координацией, верификацией и обучением. Доменную логику реализуют ваши скиллы.
+
+### Модули
+
+| Модуль | Назначение |
+|--------|-----------|
+| **governance/** | Конституция, governance-шарды, чекпоинты |
+| **memory/** | Обучение на основе наград, dream-циклы |
+| **orchestration/** | Координация агентов, топологии, маршрутизация моделей |
+| **verification/** | SHA-256 цепочка свидетелей, аттестация судей |
+| **trust-tiers/** | 4-уровневая классификация качества |
+| **platform/** | Поддержка Cursor, OpenCode, GitHub Copilot |
+
+---
+
+## 2. Быстрый старт
+
+### Шаг 1. Установка
+
+```bash
+npm install @dzhechkov/keysarium-core
+```
+
+### Шаг 2. Выберите структуру пайплайна
+
+Определите, какой тип пайплайна вы строите:
+
+| Тип | Пример | Типичное кол-во стадий |
+|-----|--------|------------------------|
+| Исследовательский | Анализ рынка, конкурентный анализ | 5-7 |
+| Оценочный | Мультиагентная оценка качества | 3-4 |
+| Разработочный | Feature development pipeline | 5-9 |
+| Пользовательский | Любой мультиэтапный процесс | 3-7 |
+
+### Шаг 3. Загрузите конституцию
+
+В начале работы пайплайна агент-координатор читает файл `governance/constitution.md`. Это загружает набор инвариантов -- правил, которые никогда не нарушаются:
+
+```
+Агент, прочитай governance/constitution.md и следуй всем инвариантам INV-001..INV-007.
+```
+
+### Шаг 4. Создайте шарды для стадий
+
+Для каждой стадии вашего пайплайна создайте governance-шард (см. раздел 4). Минимальный шард:
+
+```markdown
+# Stage 1: Анализ Governance Shard
+
+## Time Budget
+- Allocated: 20% of total pipeline time
+
+## Rules for This Stage
+1. Собрать данные из 3+ источников
+2. Верифицировать каждое утверждение
+
+## Quality Gates
+- [ ] Минимум 3 источника данных
+- [ ] Нет неподтверждённых утверждений
+
+## Promise Tag
+On successful completion, emit: `<promise>ANALYSIS_COMPLETE</promise>`
+```
+
+### Шаг 5. Запустите первый пайплайн
+
+Координатор (Queen) следует 10-шаговому протоколу: INIT, HEALTH, LOAD, DETECT, SHARD, ORCHESTRATE, MONITOR, COLLECT, STORE, REPORT. При первом запуске memory будет пустой -- система начнёт накапливать опыт после первого чекпоинта.
+
+---
+
+## 3. Создание собственного пайплайна
+
+### 3.1. Определите стадии
+
+Типичный пайплайн содержит 3-7 стадий. Каждая стадия:
+- имеет идентификатор (например, `stage-0-init`),
+- загружает свой governance-шард,
+- производит артефакт,
+- завершается чекпоинтом с promise-тегом.
+
+**Пример стадий для аналитического пайплайна:**
+
+```
+stage-0: Сбор данных        → data_collection.md
+stage-1: Анализ             → analysis_report.md
+stage-2: Рекомендации       → recommendations.md
+stage-3: Финальный отчёт    → final_report.md
+```
+
+### 3.2. Создайте governance-шарды
+
+Для каждой стадии создайте файл по шаблону из `governance/shard-protocol.md`:
+
+```markdown
+# {Название стадии} Governance Shard
+
+## Time Budget
+- Allocated: {N}% of total pipeline time
+- Hard limit: {M} minutes
+
+## Prerequisites
+- Required upstream promises: [{PROMISE_TAG}]
+- Required input files: [{список файлов}]
+
+## Skill to Load
+- Primary: {название скилла}
+
+## Rules for This Stage
+1. {Правило 1}
+2. {Правило 2}
+
+## Quality Gates
+- [ ] {Гейт 1}
+- [ ] {Гейт 2}
+
+## Promise Tag
+On successful completion, emit: `<promise>{TAG}</promise>`
+
+## Anti-Patterns for This Stage
+| Pattern | Fix |
+|---------|-----|
+| {Анти-паттерн} | {Исправление} |
+```
+
+### 3.3. Выберите топологию для каждой стадии
+
+Модуль `orchestration/topology-selection.md` предлагает 6 топологий:
+
+| Топология | Когда использовать | Пример |
+|-----------|--------------------|--------|
+| **Star** | Простые параллельные задачи | 3 агента ищут данные параллельно |
+| **Mesh** | Отказоустойчивый research | Агенты подстраховывают друг друга |
+| **Hierarchical** | Сложная многоуровневая работа | Queen -> Managers -> Workers |
+| **Ring** | Итеративное улучшение | Черновик -> Ревью -> Полировка -> Финал |
+| **Hybrid** | Гетерогенные подзадачи | Star для поиска + Ring для доработки |
+| **Adaptive** | Неопределённая сложность | Начинает как Star, эволюционирует |
+
+### 3.4. Настройте маршрутизацию моделей
+
+Не каждая задача требует самую мощную модель. Создайте таблицу маршрутизации:
+
+```markdown
+| Задача | Тир | Обоснование |
+|--------|-----|-------------|
+| Форматирование файлов | Tier 1 (haiku) | Простая трансформация |
+| Анализ данных | Tier 2 (sonnet) | Аналитическая работа |
+| Написание отчёта | Tier 3 (opus) | Креативная работа |
+```
+
+### 3.5. Включите witness chain
+
+На каждой границе стадий вычисляйте SHA-256 хеш артефакта и добавляйте запись в цепочку:
+
+```json
+{
+  "sequence": 0,
+  "stage": "stage-0",
+  "artifact": "data_collection.md",
+  "hash": "sha256:a1b2c3...",
+  "previous_hash": "sha256:0000...0000",
+  "timestamp": "2026-03-02T10:00:00Z",
+  "promise_tag": "DATA_COLLECTED"
+}
+```
+
+### 3.6. Включите memory protocol
+
+Добавьте два вызова в каждую стадию:
+- **memory_query()** в начале -- загрузка исторических паттернов,
+- **memory_store()** после чекпоинта -- сохранение результата с наградой.
+
+### 3.7. Добавьте поддержку платформ (опционально)
+
+Если ваш пайплайн будет работать не только в Claude Code, используйте `platform/adapter-registry.md` для генерации конфигов Cursor, OpenCode или GitHub Copilot.
+
+---
+
+## 4. Governance -- как управлять пайплайном
+
+### Конституция: инварианты
+
+Конституция (`governance/constitution.md`) определяет 7 базовых инвариантов, которые защищают ваш пайплайн:
+
+| ID | Инвариант | На что влияет |
+|----|-----------|---------------|
+| INV-001 | Целостность артефактов | Артефакт должен совпадать с хешем в witness chain |
+| INV-002 | Сигнал завершения | Стадия не завершена без promise-тега |
+| INV-003 | Человеческий чекпоинт | Запрет авто-перехода между стадиями |
+| INV-004 | Независимость оценщиков | Судьи не видят оценки друг друга |
+| INV-005 | Детекция циклов | Агент не повторяет одно действие 3+ раз подряд |
+| INV-006 | Консистентность памяти | Нет противоречивых паттернов в memory |
+| INV-007 | Верификация утверждений | Нет непроверенных фактов без пометки |
+
+Вы можете добавить доменные инварианты в `constitution-{domain}.md`, нумеруя их с INV-100.
+
+### Шарды: правила для каждой стадии
+
+Проблема: в длинных сессиях (более 40 минут) агент «забывает» правила, загруженные в начале.
+
+Решение: каждая стадия перечитывает свой шард -- компактный набор правил (30-50 строк), актуальный именно для текущей стадии. Шард включает:
+
+- **Time Budget** -- сколько времени отведено,
+- **Prerequisites** -- какие promise-теги должны быть получены,
+- **Skill to Load** -- какой скилл прочитать,
+- **Rules** -- правила конкретной стадии,
+- **Quality Gates** -- чеклист качества,
+- **Promise Tag** -- какой тег эмитировать при завершении,
+- **Anti-Patterns** -- что НЕ делать.
+
+### Чекпоинты: формат и обработка
+
+После каждой стадии пайплайн останавливается и показывает:
+
+```
+=====================================================
+CHECKPOINT 2: Анализ Complete
+<promise>ANALYSIS_COMPLETE</promise>
+
+Проанализированы 5 источников данных, выявлены 3 тренда.
+Artifacts created: analysis_report.md
+
+Options:
+- "ok" -- перейти к следующей стадии
+- "углуби раздел X" -- расширить конкретный раздел
+- "переделай подход" -- существенная переработка
+=====================================================
+```
+
+Реакция человека определяет reward-оценку: "ok" = 1.0, мелкие правки = 0.7, серьёзная переработка = 0.3, полный рестарт = 0.0.
+
+---
+
+## 5. Memory -- как система учится
+
+### memory_query(): загрузка паттернов
+
+Вызывается в начале каждой стадии. Алгоритм:
+
+1. Проверить наличие `{memory-root}/config.json`.
+2. Найти записи для текущей стадии и домена.
+3. Отфильтровать просроченные записи.
+4. Отсортировать по награде (desc) и времени (desc).
+5. Вернуть топ-10 записей и обнаруженные паттерны.
+
+Если записей нет (первый запуск) -- пайплайн работает без подсказок.
+
+### memory_store(): сохранение результатов
+
+Вызывается после каждого чекпоинта, когда человек ответил. Сохраняет:
+
+```json
+{
+  "stage": "stage-2",
+  "domain": "banking",
+  "reward": 0.7,
+  "reward_label": "good",
+  "reward_reason": "Пользователь попросил добавить ещё один источник",
+  "outcome": {
+    "artifacts_created": ["analysis_report.md"],
+    "promise_emitted": "ANALYSIS_COMPLETE"
+  }
+}
+```
+
+### Шкала наград
+
+| Поведение пользователя | Награда | Метка |
+|------------------------|---------|-------|
+| Одобряет сразу ("ok", "ок", "продолжай") | 1.0 | excellent |
+| Мелкая правка (один раздел) | 0.7 | good |
+| Серьёзная переработка (3+ области) | 0.3 | needs_work |
+| Полный рестарт стадии | 0.0 | failed |
+
+### Просмотр статистики
+
+Модуль `memory/reward-tracker.md` предоставляет аналитику:
+- средняя награда по стадиям,
+- средняя награда по доменам,
+- детекция узких мест (стадии с наградой < 0.5),
+- анализ трендов (улучшается или ухудшается качество со временем).
+
+### Dream-циклы
+
+Модуль `memory/dream-engine.md` -- фоновый анализ, который строит граф концепций из накопленных данных и генерирует кросс-доменные инсайты.
+
+**Триггеры запуска:**
+- прошло более 60 минут с последнего dream-цикла,
+- накоплено 20+ новых reward-записей,
+- произошло специальное событие (провал quality gate, завершение кейса).
+
+**Результат:** файл `dream-{timestamp}.json` с инсайтами:
+- какие стадии проблемны для определённого домена,
+- какие скиллы работают лучше в определённых контекстах,
+- обнаруженные анти-паттерны.
+
+---
+
+## 6. Orchestration -- как организовать агентов
+
+### Queen Protocol: 10-шаговый жизненный цикл
+
+Координатор (Queen) управляет пайплайном по протоколу из 10 шагов:
+
+```
+INIT -> HEALTH -> LOAD -> DETECT -> SHARD -> ORCHESTRATE -> MONITOR -> COLLECT -> STORE -> REPORT
+```
+
+| Шаг | Назначение |
+|-----|-----------|
+| INIT | Создание рабочей директории |
+| HEALTH | Проверка доступности скиллов и шардов |
+| LOAD | Загрузка исторических паттернов из memory |
+| DETECT | Определение домена проекта |
+| SHARD | Загрузка governance-шарда текущей стадии |
+| ORCHESTRATE | Выбор топологии, назначение моделей, запуск агентов |
+| MONITOR | Чекпоинты, трекинг времени |
+| COLLECT | Сбор и верификация артефактов |
+| STORE | Сохранение reward-записи в memory |
+| REPORT | Финальный отчёт |
+
+Шаги 1-3 и 7-10 универсальны. Шаги 4-6 настраиваются под ваш домен.
+
+### Выбор топологии
+
+**Star** -- самая частая. Координатор раздаёт задачи параллельным воркерам и собирает результаты. Используйте для независимых подзадач.
+
+**Ring** -- для итеративного улучшения. Каждый агент дорабатывает результат предыдущего: черновик -> ревью -> полировка -> финал.
+
+**Hierarchical** -- для масштабных задач (10+ агентов). Queen делегирует менеджерам, менеджеры -- воркерам.
+
+**Adaptive** -- когда сложность неизвестна заранее. Стартует как Star, переключается на Mesh при разногласиях, на Hierarchical при росте сложности.
+
+### Фоновые воркеры
+
+Для задач, которые не блокируют основной пайплайн, используйте протокол из `orchestration/background-workers.md`:
+
+- **Максимум 3 параллельных воркера.**
+- Воркеры пишут только в свою директорию.
+- Воркеры используют Tier 1 или Tier 2 (никогда Tier 3).
+- Запуск только с подтверждения пользователя.
+
+### Маршрутизация моделей: экономия до 71%
+
+Правильная маршрутизация сокращает расходы в разы:
+
+```
+Без маршрутизации:  20 задач x Tier 3 (75x) = 1500x
+С маршрутизацией:   8 x Tier 1 (1x) + 8 x Tier 2 (15x) + 4 x Tier 3 (75x)
+                    = 8 + 120 + 300 = 428x
+Экономия: 71%
+```
+
+**Правила:**
+- Tier 1 (haiku, ~500ms, 1x): форматирование, структурные проверки, ранжирование.
+- Tier 2 (sonnet, ~2s, 15x): анализ, синтез, панели судей, мутации.
+- Tier 3 (opus, ~5s, 75x): креативная работа, сложное решение проблем, сторителлинг.
+
+**Строгие запреты:**
+- Tier 3 для структурных проверок -- пустая трата бюджета.
+- Tier 1 для панели судей -- недостаточное качество оценки.
+- Tier 1 для креативной работы -- поверхностный результат.
+
+---
+
+## 7. Verification -- как гарантировать целостность
+
+### Witness Chain: SHA-256 хеш-цепочка
+
+Каждый артефакт пайплайна получает хеш, который включает хеш предыдущего артефакта. Это создаёт цепочку: изменение любого артефакта ломает все последующие хеши.
+
+**Как это работает:**
+1. Первый артефакт хешируется с NULL_HASH (64 нуля) -- это genesis record.
+2. Каждый последующий: `SHA-256(содержимое_файла + предыдущий_хеш)`.
+3. Цепочка хранится в `.witness-chain.json` рядом с артефактами.
+4. Верификация: пройти всю цепочку и сравнить хеши.
+
+**При легитимном изменении** (после обратной связи на чекпоинте) цепочка перестраивается каскадно: пересчитываются хеши изменённого и всех последующих артефактов.
+
+### Judge Attestation: независимость оценщиков
+
+При мультиагентной оценке (панель из 3+ судей) каждый судья:
+1. Получает один и тот же артефакт.
+2. Пишет оценку в отдельный файл.
+3. Не видит оценок других судей.
+4. Подписывает оценку хешем: `SHA-256(judge_id | artifact_hash | score | rationale)`.
+
+Результат хранится в `.judge-attestations.json`. Это криптографическое доказательство изоляции.
+
+### Audit Trail: полная история
+
+Файл аудита содержит полную историю оценок: кто оценивал, когда, какие баллы поставил, были ли разногласия, привлекался ли мета-судья.
+
+---
+
+## 8. Trust Tiers -- как классифицировать качество
+
+### 4 уровня доверия
+
+| Тир | Метка | Требования | Уверенность |
+|-----|-------|-----------|-------------|
+| Tier 0 | Advisory | Базовый SKILL.md | Низкая -- используйте с осторожностью |
+| Tier 1 | Structured | SKILL.md + references/ или modules/ | Средняя -- хорошо организован |
+| Tier 2 | Validated | Панель из 3 судей, средний балл >= 7.0 | Высокая -- протестирован и оценён |
+| Tier 3 | Verified | Балл >= 8.5 + детерминистические тесты | Наивысшая -- готов к продакшену |
+
+### Как повысить тир скилла
+
+```
+Tier 0 (Advisory)
+    | Добавить references/ или modules/ + полную документацию
+    v
+Tier 1 (Structured)
+    | Пройти оценку панелью из 3 судей (score >= 7.0)
+    v
+Tier 2 (Validated)
+    | Создать eval-тесты + набрать score >= 8.5
+    v
+Tier 3 (Verified)
+```
+
+**Повышение до Tier 1** -- структурная проверка (формальная оценка не нужна).
+**Повышение до Tier 2** -- три судьи (Domain Expert 0.4 / Critic 0.3 / Auditor 0.3) независимо оценивают скилл. Если средний балл >= 7.0 и ни один судья не поставил ниже 5.0 -- повышение.
+**Повышение до Tier 3** -- дополнительно к Tier 2 нужен набор детерминистических тестов (минимум 5), которые стабильно проходят.
+
+### Что тир означает для пайплайна
+
+- **Tier 0** -- при загрузке выводится предупреждение.
+- **Tier 1** -- стандартное использование.
+- **Tier 2** -- полное доверие, метаданные оценки включаются в brain export.
+- **Tier 3** -- наивысшее доверие, автоматическая валидация доступна.
+
+---
+
+## 9. Platform -- мультиплатформенная поддержка
+
+### Поддерживаемые платформы
+
+| Платформа | Формат | Сложность адаптации |
+|-----------|--------|---------------------|
+| Claude Code | `.claude/` (нативный) | Не нужна |
+| Cursor | `.cursorrules` | Низкая |
+| OpenCode | `.opencode/` | Низкая |
+| GitHub Copilot | `.github/copilot-instructions.md` | Средняя |
+
+### Как генерировать конфиги
+
+Источник истины -- директория `.claude/`. Адаптеры из `platform/templates/` трансформируют её в формат целевой платформы:
+
+- **Cursor:** ключевые инструкции собираются в единый `.cursorrules` файл (< 10 000 токенов).
+- **OpenCode:** структура повторяет Claude Code, файлы копируются в `.opencode/`.
+- **GitHub Copilot:** все инструкции конденсируются в один `.github/copilot-instructions.md` (< 8 000 токенов).
+
+При адаптации: ссылки на Agent tool заменяются на «разбей на подзадачи», model routing опускается (управляется платформой), promise-теги сохраняются как маркеры.
+
+---
+
+## 10. Примеры использования
+
+### Пример 1: Простой 3-стадийный пайплайн (исследование -> анализ -> отчёт)
+
+```
+Стадии:
+  stage-0: Research      -> research_data.md      <promise>RESEARCH_DONE</promise>
+  stage-1: Analysis      -> analysis.md           <promise>ANALYSIS_DONE</promise>
+  stage-2: Report        -> final_report.md       <promise>REPORT_READY</promise>
+
+Топологии:
+  stage-0: Star (3 агента ищут параллельно по разным направлениям)
+  stage-1: один агент (opus -- аналитическая работа)
+  stage-2: Ring (черновик -> ревью -> финал)
+
+Model routing:
+  stage-0 workers: sonnet (research synthesis)
+  stage-1: opus (deep analysis)
+  stage-2 Ring agents: sonnet -> sonnet -> opus
+
+Memory:
+  memory_query() в начале каждой стадии
+  memory_store() после каждого чекпоинта
+
+Witness chain:
+  Genesis record после stage-0
+  Append record после stage-1 и stage-2
+```
+
+### Пример 2: Мультиоценочная система качества
+
+```
+Стадии:
+  stage-0: Layer 0 -- структурные проверки (haiku)
+  stage-1: Layer 1 -- семантическая проверка (haiku)
+  stage-2: Layer 2 -- панель из 3 судей (sonnet x3)
+  stage-3: Meta-judge -- при разногласии > 3 баллов (sonnet)
+
+Топология stage-2: Star (изолированные судьи)
+  - Domain Expert (вес 0.4)
+  - Critic (вес 0.3)
+  - Completeness Auditor (вес 0.3)
+
+Judge attestation:
+  Каждый судья хеширует свою оценку до раскрытия баллов.
+  .judge-attestations.json фиксирует изоляцию.
+
+Гейт перехода:
+  Layer 0 -> Layer 1: все структурные проверки пройдены
+  Layer 1 -> Layer 2: семантическая когерентность OK
+  Layer 2 -> Done: средний балл >= 7.0
+```
+
+### Пример 3: Полный пайплайн с memory и dream-циклами
+
+```
+Пайплайн из 5 стадий с полной интеграцией:
+
+1. Queen запускает INIT -> HEALTH -> LOAD.
+2. LOAD: memory_query() загружает паттерны от предыдущих запусков.
+   Лог: "Loaded 12 historical patterns for stage-0 in fintech domain"
+3. DETECT: определяет домен -- "fintech".
+4. Для каждой стадии:
+   a. SHARD: загрузка governance-шарда.
+   b. ORCHESTRATE: выбор топологии + model routing.
+   c. Выполнение стадии.
+   d. Witness chain: вычисление хеша артефакта + append в цепочку.
+   e. MONITOR: чекпоинт с promise-тегом.
+   f. memory_store(): сохранение reward (0.0-1.0).
+5. COLLECT + STORE + REPORT.
+6. trigger-state.json обновляется.
+   Если накоплено 20+ записей -- предложение запустить dream-цикл.
+7. Dream-цикл (по запросу):
+   - Строит граф концепций из 200 записей.
+   - Обнаруживает кросс-доменные ассоциации.
+   - Генерирует инсайты: "Stage-2 consistently underperforms in fintech domain.
+     Consider allocating extra time budget."
+```
+
+---
+
+## 11. FAQ
+
+### Можно ли использовать только один модуль?
+
+Да. Все 6 модулей полностью независимы -- у них нет внутренних зависимостей друг от друга. Хотите только governance? Используйте только `governance/`. Нужна только верификация? Берите только `verification/`. Граф зависимостей:
+
+```
+governance    --> (standalone)
+memory        --> (standalone)
+orchestration --> (standalone)
+verification  --> (standalone)
+trust-tiers   --> (standalone)
+platform      --> (standalone)
+```
+
+### Нужен ли Claude Code для работы?
+
+Нет. Протоколы написаны в markdown -- это инструкции, которые любой AI-агент может прочитать и выполнить. Claude Code -- нативная платформа, но через адаптеры поддерживаются Cursor, OpenCode и GitHub Copilot. Протоколы можно использовать даже с LLM через API -- агент просто читает markdown и следует инструкциям.
+
+### Как работает оптимизация расходов?
+
+Через 3-уровневую маршрутизацию моделей. Вместо использования самой мощной (и дорогой) модели для всех задач, каждая задача назначается на подходящий тир:
+
+- Tier 1 (haiku, 1x стоимость): простые проверки, форматирование.
+- Tier 2 (sonnet, 15x): аналитика, судейство, синтез.
+- Tier 3 (opus, 75x): креативная работа, сложные решения.
+
+На практике это даёт экономию порядка 71% по сравнению с подходом «всё на opus».
+
+### Что если memory-система откажет?
+
+Graceful degradation -- пайплайн продолжает работу. Memory -- это advisory-система, а не обязательный гейт. Если `memory_query()` не находит данных или падает, стадия выполняется без исторических подсказок. Если `memory_store()` не может записать -- ошибка логируется, но пайплайн не блокируется.
+
+### Как добавить доменные инварианты?
+
+Создайте файл `governance/constitution-{domain}.md` и нумеруйте инварианты с INV-100. Например, для банковского домена:
+
+```markdown
+### INV-100: Data Perimeter
+**Rule:** No customer data may leave the security perimeter.
+**Enforcement:** All LLM calls must be to on-premise models.
+**On violation:** HALT
+```
+
+### Можно ли использовать keysarium-core вне экосистемы Keysarium?
+
+Именно для этого он и создан. keysarium-core -- это cleanroom-экстракция, свободная от доменной специфики Keysarium. Терминология обобщена: «stage» вместо «phase», «project» вместо «research», «domain» вместо конкретной предметной области. Используйте маппинг из `index.md` для адаптации терминов под ваш проект.