Intelligence Layer — 4 Столпа

Как Arc OS валидирует, учится, фокусируется и улучшает себя.

Обзор

Intelligence Layer располагается между сообщениями пользователя и ответами Claude. Он работает в четыре этапа:

         INPUT                    PROCESSING                 OUTPUT
    ┌──────────────┐        ┌──────────────────┐       ┌─────────────────┐
    │ User Message  │───────►│  Context Router   │       │ Claude Response  │
    │               │        │  (skill scoring)  │       │  + eval warnings │
    │ Fix It / 👎   │        │                  │       │                 │
    │ (feedback)    │        │  Learnings       │       │ Quality metrics │
    │               │        │  (correction     │       │  logged         │
    └──────────────┘        │   injection)     │       └────────┬────────┘
                            │                  │                │
                            │  buildGsdPrompt()│        ┌───────┴────────┐
                            └────────┬─────────┘        │ Nightly Loop   │
                                     │                  │ (improvement   │
                                     ▼                  │  proposals)    │
                              Claude CLI                └────────────────┘

Столп 1: Binary Eval Engine

Что: Декларативные правила, которые проверяют каждый ответ перед отправкой.

Зачем: Вывод AI должен проходить через quality gates — как юнит-тесты для кода.

Как:

Каждый скил может иметь файл .evals.json с правилами:

{
  "rules": [
    { "id": "gm-001", "type": "string_not_contains", "value": "--force", "severity": "warning" },
    { "id": "gm-002", "type": "max_length", "value": 4000, "severity": "info" }
  ]
}

После того как Claude генерирует ответ, eval engine прогоняет все применимые правила:

Pass: ответ доставляется как есть
Fail: ответ доставляется + добавляется предупреждение в сноске

[Claude's response about git operations]
---
Eval: ⚠️ No force push | ℹ️ Response under 4000 chars

Типы правил

Тип	Что проверяет
`string_contains`	Ответ должен содержать точный текст
`string_not_contains`	Ответ НЕ должен содержать текст
`regex_match`	Ответ должен соответствовать regex-паттерну
`regex_not_match`	Ответ НЕ должен соответствовать regex
`max_length`	Ответ должен быть <= N символов
`min_length`	Ответ должен быть >= N символов

Ключевые решения

Неблокирующий: предупреждения не подавляют ответы. Пользователь видит и ответ, и замечание.
Per-skill: у разных скилов — разные критерии качества.
Per-project: один и тот же скил может иметь разные правила для разных технических стеков.
Без AI в валидации: правила детерминированы. Бинарный pass/fail. Никакой неоднозначности.

Референс дизайна: Anthropic Skill Creator — структурированные evals с бинарными assertions.

Столп 2: Context Router

Что: Умный выбор скилов, который инжектирует в каждый промпт только релевантные скилы.

Зачем: 25 скилов, загруженных одновременно = размытие контекста. Модель пытается применить советы по деплою к code review.

Как:

Перед сборкой промпта роутер оценивает каждый зарегистрированный скил относительно сообщения пользователя:

Score = (trigger matches x 2) + (keyword matches x 1)
Sort by score descending → take top 5

Пример:

User: "Review this code for XSS vulnerabilities"

Scoring:
  code-review:     trigger "review" (2) + keyword "XSS" (1) = 3
  code-review-protocol: trigger "code review" (2)            = 2
  deployment-flow: no match                                  = 0
  git-manager:     no match                                  = 0

Injected into prompt:
  SKILLS_HINT (focus on these):
  - code-review: Security audit and code quality review...
  - code-review-protocol: Structured code review with OWASP...

Почему рекомендательный, а не фильтрующий

Роутер предлагает скилы, но не блокирует остальные. Claude по-прежнему имеет полный доступ.

Подход	Риск
Жёсткая фильтрация (`--allowedTools`)	Неверная классификация ломает сессию
Мутации через symlink	Изменения файловой системы в работающем процессе
Advisory hints	Безопасно: неверный hint = Claude его игнорирует

Triggers vs Keywords

Triggers (2 pts): Явные сигналы вызова. Пользователь напрямую запрашивает эту возможность.

"deploy", "review", "scaffold", "audit"

Keywords (1 pt): Более широкий семантический контекст. Указывает на релевантность, не будучи командой.

"OWASP", "Docker", "CI/CD", "performance"

Референс дизайна: Context priming — сфокусированное внимание без жёсткой фильтрации.

Столп 3: Reflect Loop

Что: Автоматическое сохранение исправлений в виде постоянных правил.

Зачем: Исправления AI должны переживать перезапуски. Одно исправление = постоянное улучшение.

Как:

CEO нажимает 🛠️ Fix It
    │
    ├── addLearning(source: "fixit", rule: "Fix requested for: <last response>")
    ├── projectLearnings reloaded from disk
    └── Fix prompt sent to Claude for immediate correction

CEO нажимает 👎
    │
    ├── addLearning(source: "negative", rule: "Negative feedback on: <response>")
    ├── qualityTracker.logFeedback(positive: false)
    └── projectLearnings reloaded from disk

Правила хранятся в learnings.md:

# Learnings

## Rules

- [2026-04-03T14:22:00Z] [fixit] Always use t-call for translations in Odoo QWeb
- [2026-04-03T15:10:00Z] [negative] Avoid sudo in deployment scripts

При каждом последующем сообщении накопленные learnings инжектируются:

LEARNINGS (past corrections — follow these rules):
- Avoid sudo in deployment scripts
- Always use t-call for translations in Odoo QWeb

Ключевые свойства

Автоматический: никакого ручного написания правил. Нажал кнопку → правило создано.
Постоянный: переживает перезапуски бота. Записывается на диск как Markdown.
Per-project: у каждого child bot есть свой learnings.md. Исправления для Odoo не влияют на React-бота.
Сначала новые: самые последние исправления имеют наибольшую видимость в промпте.
С бюджетом: максимум 2000 символов в блоке LEARNINGS. Самые старые правила вытесняются.

Референс дизайна: Claude Reflect System — исправления становятся постоянными правилами, которые предотвращают регрессию.

Столп 4: Karpathy Loop

Что: Ночной автоматический анализ метрик качества с предложениями по улучшению, отправляемыми CEO.

Зачем: Люди забывают следить за производительностью. Система должна сама находить свои слабые места.

Как:

Каждый день в 03:00 UTC запускается scripts/nightly-improve.ts:

Читает реестр — перечисляет все child bots из bot_registry.json
Читает метрики — загружает quality-metrics.json для каждого child
Находит слабые места — фильтрует скилы, у которых:
- applied_count >= 3 (минимальный размер выборки во избежание шума)
- И либо success_rate < 80%, либо feedback_negative > feedback_positive
Читает learnings — извлекает связанные паттерны исправлений
Генерирует proposals — на основе шаблонов (детерминированно, без AI)
Отправляет CEO — сводный отчёт + карточки с предложениями в Telegram

Процесс одобрения CEO

Telegram: Proposal Card
┌──────────────────────────────────────┐
│ Improvement Proposal                  │
│                                       │
│ Child: citadel-v2                     │
│ Skill: code-review                    │
│ Reason: low success rate (72%)        │
│ Feedback: 👍 4 / 👎 6                │
│                                       │
│ Related learnings:                    │
│   • Always use t-call for i18n        │
│                                       │
│ [✅ Approve]  [❌ Reject]             │
└──────────────────────────────────────┘

Approve: резервная копия skill.md → skill.v1.md (максимум 3 версии). Помечается как одобренное.
Reject: помечается как отклонённое в proposals.json. Никаких изменений не вносится.

Ключевые решения

Proposals на основе шаблонов: AI не генерирует улучшения. Система находит проблему; человек решает, как её исправить.
CEO в петле: никакой автономной перезаписи скилов. Требуется одобрение одним нажатием.
Версионирование скилов: резервные копии предотвращают потерю данных. Максимум 3 версии на скил.
Минимальный размер выборки: скилы с менее чем 3 использованиями исключаются из анализа (избегаем ложных срабатываний).

Референс дизайна: Karpathy AutoResearch Loop — изменить → проверить → сохранить/отбросить → повторить. С критически важным добавлением: одобрением человека.

Как 4 столпа работают вместе

День 1:
  CEO отправляет сообщение → Context Router предлагает релевантные скилы
  Claude отвечает → Evals проверяют вывод → Warning: "No force push"
  CEO видит предупреждение, нажимает Fix It → Learning сохраняется в learnings.md

День 2:
  CEO отправляет похожее сообщение → Learnings инжектируются: "Don't use --force"
  Claude избегает ошибки → Нет eval warnings → thumbs-up
  Метрики качества улучшаются для этого скила

День 30:
  Nightly loop обнаруживает: скил git-manager имеет 95% success rate
  Proposal не нужен — скил в норме

День 30 (другой скил):
  Nightly loop обнаруживает: code-review на уровне 68% success
  Отправляет proposal CEO → CEO одобряет → скил бэкапится
  CEO вручную улучшает skill.md
  Следующий цикл: success rate растёт

Система создаёт положительную обратную связь: исправления становятся постоянными правилами → правила улучшают качество → метрики отражают улучшение → nightly loop подтверждает здоровье.

Столп 5: Sage Worker (Phase 40.11+)

Что: Анализ скилов на основе AI, бенчмаркинг и поиск в marketplace.

Зачем: Ручное улучшение скилов не масштабируется. Нужен автоматизированный анализ качества скилов и доступ к экспертизе сообщества.

Как:

Анализ скила

Выбери любой скил в UI Skill Evolution → нажми "Sage Analyze" → Sage (Claude Haiku) оценивает:

Чёткость и полноту инструкций скила
Покрытие eval rules
Рекомендации по улучшению

A/B Бенчмарки

Сравни две версии скила:

Выбери обновление скила (PR)
Запусти benchmark → Sage тестирует обе версии на примерах промптов
Результаты показывают сравнение качества с итоговым резюме

Поиск в Marketplace

Ищи скилы, созданные сообществом, на claudemarketplaces.com:

"Sage Scout" → поиск по ключевому слову
Анализируй совместимость с твоим проектом
Устанавливай глобально или форкай в конкретный проект

Референс дизайна: пакетные менеджеры (npm, pip) для управления AI-скилами, с LLM-анализом совместимости.