Проект-Процессор

ПРОЕКТОР (агент) → использует → ПРОЕКТ-ПРОЦЕССОР (движок)

PROCESS(task, context):

  [0]   CONTEXT_CHECK(task)           → path, risk_level

  [0.5] MATCHER(task)                 → template | null
        точное/частичное совпадение   → БЫСТРЫЙ ПУТЬ (см. ниже)
        нет совпадения               → продолжить МЕДЛЕННЫЙ ПУТЬ

  if ATOMIC(task):
    [2]   SYNTHESIZE(task, context)   → CODE-PROMPT.md
          (Верификатор синтеза выполняет мини-УТОЧНЕНИЕ: проверка REQUIRED_PARAMS)
    [3]   EXECUTE(CODE-PROMPT)        → result
    if depth == 0:                    ← корневой атом: PASS 3/4 тоже нужен
      PASS_3(result, risk_level)
      PASS_4(result)
    return result

  [1]   DECOMPOSE(task)               → subtasks[]
  [1.5] CLARIFY(subtasks)             → verified_subtasks[]
        (max_clarify_rounds = 5, после → ESCALATE)

  for each subtask in verified_subtasks:
    if ATOMIC(subtask):
      [2] SYNTHESIZE(subtask, INHERIT(context, subtask)) → CODE-PROMPT.md
      [3] EXECUTE(CODE-PROMPT) → result
    else:
      result = PROCESS(subtask, INHERIT(context, subtask))   ← РЕКУРСИЯ

  INTEGRATE(results[]) → deploy/
  PASS_3(deploy/, risk_level)         → issues[]
  PASS_4(deploy/)                     → finalized deploy/
  return deploy/

depth > 7  → WARN: "Глубокая рекурсия, проверь декомпозицию"
depth > 12 → STOP: "Слишком глубокая рекурсия, пересмотри задачу"
             → ESCALATE оператору с деревом задач

[1] INSTANCE SPACE — текущая работа (стек задач)
──────────────────────────────────────────────────
.task-stack/level-N/
├── task.yaml       — статус узла, confidence, risk_level
├── CACHE.yaml      — resolved входы + ссылки на deploy/ детей
├── planning/       — декомпозиция этого уровня
│   ├── requirements.md   — требования
│   ├── blocks.md         — декомпозиция на подзадачи
│   └── criteria.md       — критерии готовности
└── deploy/         — результат (интерфейс для родителя)

[2] TEMPLATE SPACE — как делать (TEMPLATE_REGISTRY)
──────────────────────────────────────────────────
library/templates/
└── {тип}/{подтип}/
    ├── template.yaml   — структура декомпозиции + параметры
    ├── blocks.md       — типовые блоки и зависимости
    └── health.yaml     — BLOCK_HEALTH метрики шаблона

[3] COMPONENT SPACE — что уже есть (library/)
──────────────────────────────────────────────────
library/
└── connectors/api/ozon/
    ├── CLAUDE.md   — API интерфейс (inputs/outputs)
    └── deploy/     — готовый код для подключения

РЕКУРСИЯ ЗАДАЧ (логическая)
  Причина: задача слишком сложная по смыслу
  Механизм: декомпозиция на подзадачи по логике
  Глубина: не ограничена (WARN > 7, STOP > 12)
  Критерий остановки: задача атомарна (понятна без погружения)

РЕКУРСИЯ БЛОКОВ (размерная)
  Причина: задача не влезает в контекстное окно
  Механизм: разбивка на последовательные части
  Глубина: 1–2 уровня
  Критерий остановки: блок < CONTEXT_LIMIT × 0.7
  Размерные ориентиры:
    <500 строк CODE-PROMPT    — один файл (атом)
    500–1500 строк             — разбить на 2–5 блоков
    >1500 строк                — пересмотреть декомпозицию

BLOCK_DECOMPOSE(task):
  1. Оценить размер результирующего CODE-PROMPT (строки)
  2. Если ≤ 500 строк → вернуть [task] (один блок)
  3. Если 500–1500 строк:
     a. Определить тип артефакта и применить стратегию разбиения:

        CODE (Python/JS/Go):
          → AST-BASED CHUNKING:
            1) Построить AST (tree-sitter, ast модуль Python)
            2) Извлечь top-level nodes: class, function, const/var
            3) Каждый node = потенциальный блок
            4) Мелкие nodes (< 30 строк) → объединить с соседними
               до достижения ~200-400 строк на блок
            5) Сохранить import-блок как общий контекст для всех блоков
          → если AST недоступен (нет парсера для языка):
            fallback на regex: split по ^(def |class |func |function )

        DOCS (Markdown):
          → HEADING-BASED CHUNKING:
            1) Найти все заголовки (## и ###)
            2) Каждая секция ## = потенциальный блок
            3) Секции < 50 строк → объединить с предыдущей
            4) Секции > 400 строк → разбить по ### подзаголовкам

        OPS (YAML/TOML/nginx/docker):
          → SECTION-BASED CHUNKING:
            1) Найти top-level ключи (YAML) или блоки (nginx server{})
            2) Каждый top-level ключ = потенциальный блок
            3) Общий контекст: глобальные переменные, defaults

     b. Для каждого блока: добавить общий контекст (imports, запреты, API)
     c. Установить порядок: блоки зависимые → последовательно,
                             независимые → параллельно
  4. Если > 1500 строк → вернуть на уровень выше для
     пересмотра декомпозиции (задачу нужно разбить на подзадачи)

ПРОХОД 1 — ВНИЗ (декомпозиция)
  ROOT → разматываем логику рекурсивно → доходим до атомов

ПРОХОД 2 — ВВЕРХ (сборка)
  атомы → выполняем → собираем результаты → поднимаемся до ROOT

MATCHER ищет шаблон в [2] TEMPLATE SPACE:

  Нашёл точно (100%) → БЫСТРЫЙ ПУТЬ:
    инстанцировать шаблон → CLARIFY (параметры изменились?) → ЭКЗЕКУТОР

  Нашёл частично (≥70%) → БЫСТРЫЙ ПУТЬ + дополнить:
    инстанцировать → адаптировать → СИНТЕЗАТОР → ЭКЗЕКУТОР
    → если адаптация не прошла STEP_VERIFY за 2 попытки
      → откат к полному МЕДЛЕННОМУ ПУТИ

  Не нашёл (<70%) → МЕДЛЕННЫЙ ПУТЬ:
    ДЕКОМПОЗИТОР → УТОЧНЕНИЕ → СИНТЕЗАТОР → ЭКЗЕКУТОР → сохранить шаблон в [2]

MATCHER(task):
  1. Извлечь task.capabilities (набор требуемых способностей):
     a. Из task.type → базовая capability (например: code → [code])
     b. Из task.inputs → технические capabilities (db_url → [database],
        api_key → [rest_api], file_path → [filesystem])
     c. Из task.description → доменные capabilities
        (ключевые слова: "CRUD" → [crud], "парсинг" → [parsing],
         "миграция" → [migration], "отчёт" → [reporting])
     d. Объединить уникальные → task.capabilities

  2. Для каждого template в TEMPLATE_REGISTRY:
     match_score = |intersection(task.capabilities, template.capabilities)|
                   / |task.capabilities|
  3. Найти template с максимальным match_score
  4. Если match_score = 1.0 → точное совпадение (БЫСТРЫЙ ПУТЬ)
     Если match_score ≥ 0.70 → частичное совпадение (БЫСТРЫЙ + дополнить)
     Если match_score < 0.70 → нет совпадения (МЕДЛЕННЫЙ ПУТЬ)
  5. При равных scores → выбрать шаблон с лучшим health.success_rate

HYBRID_MATCHER(task):
  1. FAST PATH: keyword intersection (как в базовом MATCHER)
     match_score = |intersection| / |task.capabilities|
     если match_score >= 0.85 → использовать (высокая уверенность)

  2. SEMANTIC FALLBACK (если match_score < 0.85):
     a. Построить embedding вектор из task.description
        (используя локальную модель: sentence-transformers или
         дешёвый API: embedding endpoint)
     b. Сравнить cosine similarity с embeddings шаблонов
        в TEMPLATE_REGISTRY
     c. semantic_score = max(cosine_similarities)
     d. combined_score = 0.6 * match_score + 0.4 * semantic_score

  3. Финальное решение по combined_score:
     >= 0.85 → точное совпадение (БЫСТРЫЙ ПУТЬ)
     >= 0.70 → частичное (БЫСТРЫЙ + дополнить)
     < 0.70  → МЕДЛЕННЫЙ ПУТЬ

  4. КЕШИРОВАНИЕ: embedding каждого шаблона вычисляется один раз
     при SAVE_TEMPLATE и хранится в template.yaml#embedding

НАМЕРЕНИЕ
    ↓
[0]   CONTEXT_CHECK     проверить размер и сложность задачи
    ↓
[0.5] MATCHER           найти шаблон → БЫСТРЫЙ или МЕДЛЕННЫЙ ПУТЬ
    ↓
[1]   ДЕКОМПОЗИТОР      разбить на дерево атомов (сверху вниз)
    ↓
[1.5] УТОЧНЕНИЕ         верификация полноты параметров и зависимостей
    ↓
[2]   СИНТЕЗАТОР        собрать контекст для каждого атома
    ↓
[3]   ЭКЗЕКУТОР         исполнить атомы (снизу вверх)
    ↓
      INTEGRATE         собрать результаты дочерних уровней
    ↓
      PASS 3            полное тестирование (по risk_level)
    ↓
      PASS 4            финализация (HARDEN)
    ↓
РЕЗУЛЬТАТ

1. Оценить размер задачи:

   1a. Подсчитать ожидаемый размер результата:
       - CODE: количество файлов × средний размер (100 строк)
       - DOCS: количество документов × средний размер (200 строк)
       - OPS: количество конфигов × средний размер (50 строк)
       → estimated_lines = сумма

   1b. Подсчитать количество сущностей в задаче:
       entity_count = количество упомянутых: файлов, функций,
       компонентов, этапов, целей
       → если entity_count = 1 и estimated_lines ≤ 500 → ATOM
       → если entity_count > 1 → нужна декомпозиция (шаг 1c)
       → если entity_count = 1 и estimated_lines > 500 → BLOCK_RECURSION

   1c. Различить TASK_RECURSION vs BLOCK_RECURSION:
       TASK_RECURSION (логическая) если ЛЮБОЕ из:
         - entity_count > 1 (несколько разных вещей)
         - задача содержит слова: "и", "затем", "после этого", "также"
         - результат требует разных инструментов (код + конфиг + документ)
       BLOCK_RECURSION (размерная) если ВСЕ из:
         - entity_count = 1 (одна вещь)
         - estimated_lines > 500 (просто большая)
         - результат однородный (только код ИЛИ только документ)

2. Определить risk_level по ТИПУ ОБЪЕКТА + ДЕЙСТВИЮ:
   LOW      — чтение чего угодно; создание/правка .md, .yaml в projects/
   MEDIUM   — создание/правка .py, .js, .go; данные без prod
   HIGH     — изменение /etc/, nginx, systemd, docker; интеграции с деньгами
   CRITICAL — DROP/DELETE на prod; rm -rf; изменение credentials; force push

3. Проверить глубину рекурсии:
   depth > 7  → WARN
   depth > 12 → STOP + ESCALATE

CONTEXT_CHECK → атом
  → пропустить [1] ДЕКОМПОЗИТОР и [1.5] УТОЧНЕНИЕ
  → [2] СИНТЕЗАТОР: собрать CODE-PROMPT из CACHE + COMPONENT SPACE
    → Верификатор синтеза выполняет мини-УТОЧНЕНИЕ:
      проверка REQUIRED_PARAMS присутствуют и непротиворечивы
  → [3] ЭКЗЕКУТОР: выполнить
  → результат в deploy/

CONTEXT_CHECK → пустой проект
  1. Инициализировать INSTANCE SPACE:
     mkdir .task-stack/
     создать 000_root.yaml (пустой контекст)
     создать корневой CACHE.yaml (пустой)
  2. TEMPLATE SPACE пуст → все задачи идут МЕДЛЕННЫМ ПУТЁМ
  3. COMPONENT SPACE: проверить library/ — возможно уже есть компоненты
  4. Продолжить обычный цикл

1. Определить тип задачи:
   code | docs | ops | data | design | test | meta
   Критерий: по основному артефакту (что создаётся/меняется).
   Если несколько типов — основной по доминирующему объёму.

2. Вычислить REQUIRED_PARAMS — минимальный набор параметров
   без которых задача не выполнится корректно.

   Алгоритм извлечения REQUIRED_PARAMS:
   a. Извлечь из текста задачи все СУЩЕСТВИТЕЛЬНЫЕ → кандидаты
   b. Для каждого кандидата определить категорию:
      WHAT   — что создать/изменить (файл, функция, сервис)
      WHERE  — куда положить/где изменить (путь, модуль, сервер)
      HOW    — каким способом (язык, фреймворк, формат)
      WITH   — какие зависимости (API, БД, библиотеки)
      FOR    — для кого/чего (пользователь, система, процесс)
   c. Обязательные: минимум WHAT + WHERE.
      Без них задача невыполнима.
   d. Остальные категории: RESOLVE_UP → если не нашёл → CLARIFY

3. Разрешить каждый параметр (см. Механизм параметров):
   RESOLVE_UP по иерархии CACHE.yaml → COMPONENT SPACE → CLARIFY

4. Разбить на подзадачи, определить зависимости.

   Принципы разбиения:
   - По СУЩНОСТЯМ: каждая самостоятельная сущность = подзадача
   - По ЭТАПАМ: если порядок фиксирован (миграция: подготовка → перенос → проверка)
   - По СЛОЯМ: если разные уровни системы (UI → API → DB)

   Определение зависимости:
   Задача B зависит от A если B.inputs содержит элемент из A.outputs.
   Проверка: для каждого input подзадачи — откуда он берётся?
     из CACHE / COMPONENT SPACE → нет зависимости
     из outputs другой подзадачи → зависимость

5. Для каждой подзадачи: RESOLVE — определить агента и инструменты
   (из AGENT_REGISTRY и TOOL_REGISTRY)
     точное совпадение       → использовать
     частичное (≥70%)        → INHERIT(родитель) + расширить
     нет совпадения          → CREATE_AGENT (мета-задача, выполняется BUILDER_AGENT)

   Для каждого агента — инструменты:
     проверить TOOL_REGISTRY на дубли ДО создания
     есть в TOOL_REGISTRY    → использовать
     нет                     → CREATE_TOOL (мета-задача, выполняется BUILDER_AGENT)
                             → добавить в TOOL_REGISTRY

6. Повторять рекурсивно пока узел не АТОМАРНЫЙ

CREATE_AGENT всегда выполняется BUILDER_AGENT — встроенный агент
который не может быть удалён из AGENT_REGISTRY.

Алгоритм:
  1. BUILDER_AGENT получает описание нужных capabilities
  2. Находит ближайшего агента для наследования (INHERIT)
  3. Создаёт нового агента, добавляет в AGENT_REGISTRY
  4. Рекурсия невозможна: BUILDER_AGENT = fallback, поиск не нужен

Failure path:
  Если BUILDER_AGENT не может создать агента
  (capability слишком специфична, нет подходящего родителя для INHERIT):
    → ESCALATE оператору: "Не могу создать агента для: [capabilities]"
    → задача переходит в status: blocked
    → параллельные ветки продолжают работу

Для каждого узла в дереве (сверху вниз):

1. Проверить task.yaml:
   - inputs и outputs определены?
   - тип и описание заполнены?
   - risk_level установлен?

2. Проверить CACHE.yaml:
   - все зависимости resolved?
   - нет пустых или заглушечных значений?

3. Проверить planning/:
   - requirements.md — все требования зафиксированы?
   - blocks.md — декомпозиция понятна?
   - criteria.md — критерии готовности определены?

4. Вычислить AMBIGUITY_SCORE и CONFLICT_SCORE (см. ниже)

5. CLARIFY неразрешённые параметры:
   → режим A: вопросы к оператору (бизнес-решения)
   → режим B: агент-критик параллельно (техническая корректность)
   → режим C: cross-LLM валидация (только HIGH и CRITICAL risk)

6. Повторять пока AMBIGUITY_SCORE = 0 и CONFLICT_SCORE = 0
   Ограничение: max_clarify_rounds = 5
   После 5 раундов без разрешения → ESCALATE оператору:
     "Не удалось разрешить N параметров за 5 попыток: [список]"

AMBIGUITY_SCORE(node) = количество параметров с CONFIDENCE < 0.70

Вычисление:
  для каждого param в REQUIRED_PARAMS(node):
    если CONFIDENCE(param) < 0.70 → +1
  для каждого dependency в node.dependencies:
    если dependency.status != resolved → +1

Цель: 0 (все параметры определены с достаточной уверенностью)

CONFLICT_SCORE(node) = количество обнаруженных противоречий

Вычисление:
  для каждой пары (param_A, param_B) в node:
    если param_A.value противоречит param_B.value → +1, определить severity
  для каждого param в node:
    если param.value противоречит parent.CACHE[param] → +1, определить severity
  для каждого requirement в planning/requirements.md:
    если requirement противоречит criteria в planning/criteria.md → +1

Цель: 0 (нет противоречий)

CONFLICT_SEVERITY:
  trivial — опечатка, форматирование, несущественное расхождение
           → автоисправление без ESCALATE
  logical — смысловое противоречие (взаимоисключающие требования)
           → ESCALATE немедленно (независимо от CONFIDENCE)

1. RESOLVE — подтвердить агента и инструменты для задачи

2. Для HIGH и CRITICAL задач: N-ВЕРСИОННОЕ РЕШЕНИЕ
   HIGH (N=2): два независимых агента решают задачу
     оба совпали → принять
     разошлись → CLARIFY (зона риска)
   CRITICAL (N=3): три независимых агента
     консенсус ≥ 2 из 3 → принять
     нет консенсуса → CLARIFY

3. Исполнить задачу по CODE-PROMPT.md

4. CHECKPOINT(task, result) — сохранить промежуточное состояние

5. STEP_VERIFY — проверка результата (6 уровней):
   V0  синтаксис / запуск          — работает?
   V1  контракт                    — соответствует спеке?
   V2  граничные случаи            — пустой ввод, null, max, min?
   V3  зависимости                 — не сломал соседей?
   V4  hardcode detector           — нет магических значений?
       Для CODE: числа без const/переменной, строки URL/path inline
       Для DOCS: фактические данные без источника (даты, числа, имена)
       Для OPS:  IP-адреса, порты, пути без переменных окружения
   V5  покрытие спеки              — всё из задания реализовано?
       Метод: extracting checklist из planning/requirements.md
       → для каждого пункта: grep в deploy/ → найден артефакт?

6. VERIFY failed → ROLLBACK(task) → повтор (максимум 3 попытки)
   После 3 неудач → ESCALATE оператору

7. VERIFY passed → INTEGRATE → записать результат в deploy/

8. Если МЕДЛЕННЫЙ ПУТЬ → сохранить шаблон в TEMPLATE_REGISTRY:
   SAVE_TEMPLATE(task_type, decomposition, parameters, health_init)

для каждого дочернего уровня level-N+1:
  взять deploy/ level-N+1
  добавить ref в CACHE.yaml level-N
    (resolved.{имя}: {$ref: level-N+1/deploy/})

собрать deploy/ level-N из дочерних deploy/
обновить CACHE.yaml родителя (level-N-1)

MERGE_CONFLICT(deploys[]):
  1. DISJOINT CHECK: для каждой пары deploy/:
     пересечение = файлы изменённые обоими
     если пересечение пусто → FAST MERGE (простое объединение)

  2. Если пересечение НЕ пусто → для каждого конфликтного файла:
     a. SECTION_MERGE: если изменения в разных секциях файла
        (разные функции, разные блоки) → автоматический merge
     b. OVERLAP_MERGE: если изменения перекрываются →
        определить CONFLICT_SEVERITY:
          trivial (форматирование, импорты) → автоисправление
          logical (разная логика) → ESCALATE оператору:
            "Конфликт в {файл}: воркер A сделал {X}, воркер B сделал {Y}"

  3. Принцип: каждый воркер пишет в логически изолированную
     зону deploy/ (свои файлы). ДЕКОМПОЗИТОР при разбиении
     обязан обеспечить disjoint outputs для параллельных задач.
     Если невозможно → задачи последовательны (зависимость).

  4. Валидация после merge:
     STEP_VERIFY V3 (зависимости) на объединённом deploy/

CHECKPOINT(task, result):
  1. Записать текущий result в task.yaml#checkpoint
  2. Обновить task.yaml#status = in_progress
  3. Зафиксировать метаданные: timestamp, step, confidence
  → Позволяет RESUME() восстановить работу после сбоя
  → Позволяет ROLLBACK() вернуться к предыдущему CHECKPOINT

DURABLE_EXECUTION расширяет CHECKPOINT:

  1. WRITE-AHEAD LOG: перед каждым действием записать намерение
     в .task-stack/wal.log (append-only):
       {timestamp, task_id, action, args_hash}
     → при crash: replay WAL с последнего checkpoint

  2. HEARTBEAT: активный воркер обновляет task.yaml#heartbeat
     каждые 60 секунд.
     ПЛАНИРОВЩИК проверяет: если heartbeat > 120с назад
     → задача считается crashed → автоматический RESUME()

  3. DISTRIBUTED LOCK: при RESUME() — захватить lock на task_id
     перед восстановлением. Только один воркер может
     обрабатывать task_id одновременно.
     Lock: .task-stack/locks/{task_id}.lock (PID + timestamp)
     Stale lock (PID не существует) → автоматическое освобождение

  4. IDEMPOTENCY: каждый шаг имеет unique step_id.
     Перед выполнением: проверить WAL — шаг уже выполнен?
     Да → пропустить (использовать cached result)
     Нет → выполнить → записать в WAL

ROLLBACK(task):
  1. Прочитать task.yaml#checkpoint
  2. Восстановить deploy/ к состоянию на момент checkpoint
     (удалить файлы созданные после checkpoint.timestamp)
  3. Восстановить task.yaml#checkpoint.result_ref как текущий результат
  4. Сбросить task.yaml#status = in_progress
  5. Инкрементировать счётчик попыток (max: 3)

SAVE_TEMPLATE(task_type, decomposition, parameters, health_init):
  1. Извлечь структуру декомпозиции из planning/blocks.md
     → template.yaml#decomposition
  2. Извлечь REQUIRED_PARAMS → template.yaml#parameters
  3. Извлечь capabilities из задачи → template.yaml#capabilities
  4. Инициализировать health:
     usage_count = 1, success_rate = 1.0,
     avg_confidence = текущий confidence, last_used = now
  5. Сохранить в library/templates/{task_type}/{подтип}/
  6. Записать в DECISION_LOG: "Новый шаблон: {template_id}"

L1  UNIT          — каждая функция изолированно
L2  INTEGRATION   — взаимодействие компонентов
L3  E2E           — сценарий от входа до выхода
L4  PERSONAS      — expert, novice, hostile, distracted, impatient, mobile
L5  CHAOS         — infrastructure, network, data, dependencies, concurrency, time
L6  LOAD          — под нагрузкой

1. Удалить временный код и логи разработки
2. Проверить все секреты (нет в коде?)
3. Финализировать документацию deploy/README.md
4. Зафиксировать версию
5. Повторить VERIFY_ALL → пока ISSUES = 0
   Ограничение: max_harden_rounds = 3
   После 3 раундов с оставшимися ISSUES → ESCALATE:
     "HARDEN не завершён за 3 итерации. Оставшиеся проблемы: [список]"

для каждого param из REQUIRED_PARAMS(задача):

  1. RESOLVE_UP — смотреть вверх по иерархии [1] INSTANCE SPACE:
       свой CACHE.yaml
         → родительский CACHE.yaml
           → ... до корня проекта

  2. Если не нашли — проверить [3] COMPONENT SPACE (library/)

  3. Нашёл однозначно → использовать

  4. Не нашёл или неоднозначно → вычислить CONFIDENCE:

     ≥ 0.85 → AUTO_DECIDE
              → записать в DECISION_LOG
              → продолжить без вопроса

     0.70–0.84 → AUTO_DECIDE + уведомить оператора
              → "принял: X, причина: Y — можете изменить"

     0.50–0.69 → CLARIFY_WITH_ANALYTICS
              → задать вопрос оператору со справкой
              → ждать ответа (не блокируя параллельные ветки)
              → RESEARCHER_AGENT ищет в фоне пока ждём

     < 0.50 → СТОП, только оператор решает

CONFIDENCE_SCORE = weighted_average(
  completeness    x 0.25   <- все из спеки покрыто?
  consistency     x 0.20   <- нет внутренних противоречий?
  grounding       x 0.20   <- каждый факт имеет источник?
  test_pass_rate  x 0.25   <- % пройденных тестов
  n_version_match x 0.10   <- совпадение N независимых решений
)
-> результат: 0.0 — 1.0

completeness (полнота покрытия спеки):
  1. Извлечь из planning/requirements.md список требований → R[]
  2. Для каждого r в R: есть ли в результате артефакт покрывающий r?
     Проверка: grep/поиск ключевых слов из r в файлах deploy/
  3. completeness = |покрытых| / |R|
  Если requirements.md отсутствует → completeness = 0.5 (неопределённо)

consistency (отсутствие противоречий):
  1. Собрать все утверждения в результате (imports, конфиги, декларации)
  2. Проверить пары на взаимоисключение:
     - один файл использует X, другой использует NOT-X
     - конфиг говорит port=8080, код слушает port=3000
     - документ описывает 3 шага, код реализует 4
  3. consistency = 1.0 - (количество_противоречий × 0.2), min 0.0

grounding (обоснованность фактов):
  1. Извлечь все фактические утверждения (числа, имена, пути, URL)
  2. Для каждого факта: можно ли его верифицировать?
     - файл существует? (ls/stat)
     - URL доступен? (curl)
     - значение из CACHE/COMPONENT? (grep)
     - число из документации? (поиск источника)
  3. grounding = |верифицированных| / |всех фактов|

test_pass_rate:
  Количество пройденных STEP_VERIFY уровней (V0-V5) / 6
  Для каждого V: pass = 1.0, partial = 0.5, fail = 0.0

n_version_match:
  Если N версий: доля совпадающих ответов.
  N=2: совпали = 1.0, разошлись = 0.0
  N=3: 3/3 = 1.0, 2/3 = 0.67, 1/3 = 0.0

CALIBRATION_ENGINE:

  1. СБОР ДАННЫХ (непрерывно):
     Для каждого AUTO_DECIDE решения записывать в CALIBRATION_LOG:
       {predicted_confidence, actual_outcome (correct/incorrect),
        task_type, component_weights}

  2. АНАЛИЗ КАЛИБРОВКИ (каждые 50 решений или раз в неделю):
     a. Сгруппировать решения по predicted_confidence бинам:
        [0.50-0.60), [0.60-0.70), [0.70-0.80), [0.80-0.90), [0.90-1.0]
     b. Для каждого бина: actual_accuracy = correct / total
     c. Calibration Error (CE) по бину = |predicted - actual|
     d. Expected Calibration Error (ECE) = weighted_avg(CE по бинам)

  3. АДАПТАЦИЯ ПОРОГОВ:
     если ECE > 0.10 (плохая калибровка):
       → пересчитать пороги на основе actual_accuracy:
         AUTO_DECIDE_SILENT: actual_accuracy >= 0.90 в этом бине
         AUTO_DECIDE_NOTIFY: actual_accuracy >= 0.75
         CLARIFY: actual_accuracy >= 0.55
         STOP: actual_accuracy < 0.55
       → уведомить оператора: "Пороги CONFIDENCE скорректированы:
         было 0.85/0.70/0.50, стало {новые значения}"

  4. АДАПТАЦИЯ ВЕСОВ (каждые 100 решений):
     a. Для каждого компонента (completeness, consistency, grounding,
        test_pass_rate): вычислить корреляцию с actual_outcome
     b. Компоненты с высокой корреляцией → увеличить вес
     c. Компоненты с низкой корреляцией → уменьшить вес
     d. Сумма весов = 1.0 (нормализация)
     e. Записать новые веса в system/config/processor.yaml

  5. GUARD RAILS:
     - Минимальный вес любого компонента: 0.10 (не обнулять)
     - Максимальный сдвиг порога за одну калибровку: ±0.05
     - При < 30 решений в CALIBRATION_LOG → использовать дефолты

ПАРАМЕТР: [название]
НУЖЕН ДЛЯ: [зачем нужен]

ВАРИАНТЫ:
  [А] название  — плюсы / минусы  (confidence: 0.82)
  [Б] название  — плюсы / минусы  (confidence: 0.61)

РЕКОМЕНДАЦИЯ: [А] — потому что [причина]

-> Подтверждаете или выбираете другой?

Разрешённые REQUIRED_PARAMS типа X
  → сохранить в [2] TEMPLATE SPACE как часть шаблона X
  → при повторной задаче типа X параметры уже известны
  → типовые наборы → автоматически в library/elements/

# Слой 1: присутствует на КАЖДОМ уровне
level:
  resolved:               # входные данные уровня
    api_key: "..."
    db_url: "..."
  refs:                   # ссылки на результаты дочерних уровней
    orders: {$ref: dev/orders/deploy/}
    products: {$ref: dev/products/deploy/}

# Слой 2: ТОЛЬКО в корне проекта (дополнительно)
project:
  files:                  # хеши всех файлов (для rebuild-stale)
    PROJECT.md: {hash: sha256:...}
  extracted:              # агрегированные данные проекта
    facts:
      [ключ]: {value, source, date, confidence, affects: [...]}
  graph:                  # граф зависимостей
    dependencies: {...}
    reverse_dependencies: {...}

1. ОБНАРУЖИТЬ факт (AI анализ | оператор | внешние данные)

2. КАСКАДНАЯ ПРОВЕРКА:
     a. Что использует этот факт?
        → grep ключевых слов факта по project.graph.dependencies
        → grep по всем CACHE.yaml в .task-stack/ (level.resolved)
        → результат: affected_docs[] = список затронутых документов
     b. Что противоречит?
        → для каждого doc в affected_docs:
          → найти утверждения содержащие те же сущности
          → проверить: новый факт совместим со старым? (CONFLICT_SEVERITY)
        → результат: conflicts[] = список противоречий

3. ПРЕДЛОЖИТЬ оператору:
     "Новый факт: [X]
      Меняет документы: [A, B, C]
      Противоречит: ничему | или: [старому факту D]
      Зафиксировать?"

4. Оператор подтвердил → UPDATE:
     записать в CACHE.yaml#project.extracted.facts
     пересобрать зависимые документы (rebuild-stale)
     уведомить: "обновлено N документов"

ПЛАНИРОВЩИК ВОРКЕРОВ:
  -> найти все READY задачи (все зависимости = completed)
  -> лимит: MAX_WORKERS = 3 (ограничение параллельных Agent вызовов)
  -> если READY задач > MAX_WORKERS → приоритизация:
     1. CRITICAL и HIGH risk → первые
     2. На критическом пути (больше зависимых задач ждёт) → выше
     3. При равных → по порядку NNN (FIFO)
  -> раздать воркерам по приоритету

ВОРКЕР:
  -> взять одну READY задачу
  -> СИНТЕЗАТОР -> ЭКЗЕКУТОР
  -> отметить completed (retry_count = 0)
  -> планировщик разблокирует зависимые задачи

ПРАВИЛО: READY(задача) = все зависимости в статусе completed

ПЕРЕПОЛНЕНИЕ: если READY задач > MAX_WORKERS:
  -> лишние задачи остаются в очереди (FIFO по приоритету)
  -> при освобождении воркера → берёт следующую READY из очереди
  -> приоритет: CRITICAL > HIGH > критический путь > FIFO

ВСЕ ВЕТКИ BLOCKED:
  1. Агрегировать все вопросы в один запрос оператору:
     "Заблокировано N задач. Вопросы:
       [1] задача A: [вопрос]
       [2] задача B: [вопрос]
       ..."
  2. RESEARCHER_AGENT продолжает искать ответы фоном
  3. Если RESEARCHER нашёл ответ для задачи X:
     -> MERGE(context, ответ) -> разблокировать X -> продолжить
  4. Если все RESEARCHER-ы не нашли за timeout (30 мин):
     -> ESCALATE оператору с полным контекстом
  5. Частичный ответ оператора -> разблокировать решённые,
     остальные продолжают ждать

Оператор принял решение противоречащее рекомендации AI:
  1. Принять решение оператора -> выполнить немедленно
  2. Записать в DIVERGENCE_LOG:
       {task_type, task_id, ai_decision, ai_confidence,
        human_decision, human_reason, timestamp}
  3. Продолжить работу

IMPROVEMENT_TRIGGER если:
  DIVERGENCE_LOG[task_type].count >= 3 (порог по умолчанию)
  ИЛИ
  BLOCK_HEALTH: любые 2 метрики в красной зоне одновременно

IMPROVE(block_type):
  1. Собрать все случаи расхождения для block_type из DIVERGENCE_LOG
     → divergences[] = filter(DIVERGENCE_LOG, task_type == block_type)

  2. Найти паттерн ошибок:
     a. Сгруппировать divergences по ai_decision (что AI решал одинаково)
     b. Для каждой группы: ai_decision совпадает, human_decision отличается?
        → паттерн = AI систематически выбирает X, оператор меняет на Y
     c. Самая частая группа = главный паттерн
     d. Если нет явных групп (все разные) → ESCALATE архитектору
        (проблема не в шаблоне, а в предметной области)

  3. Сформулировать гипотезу улучшения:
     Формат гипотезы:
       БЫЛО: [шаг шаблона] → AI выбирает [X]
       СТАЛО: [новый шаг] → AI должен выбирать [Y]
       ОСНОВАНИЕ: [N из M случаев оператор выбрал Y]
       ОЖИДАНИЕ: override_rate снизится на [estimate]%

  4. Обновить TEMPLATE в TEMPLATE_REGISTRY (версионирование!)

  5. Регрессия:
     если usage_count >= 3 → прогнать исторические задачи с новым шаблоном
     если usage_count < 3  → пропустить регрессию, применить напрямую

  6. Сравнить метрики (если регрессия проведена):
       улучшилось → принять → обновить реестр
       ухудшилось → откат шаблона → ESCALATE архитектору

override_rate     — % задач где оператор переопределил AI
                    > 30% → AI не понимает предметную область

rollback_rate     — % задач с откатом
                    > 20% → шаблон ненадёжный

verify_fail_rate  — % не прошедших STEP_VERIFY с первого раза
                    > 25% → критерии готовности неверные

confidence_avg    — средний confidence при разрешении параметров
                    < 0.60 → задачи слишком неопределённые

time_deviation    — отклонение реального времени от оценки
                    > 2.0x → декомпозиция неточная

BASE_AGENT
|  analyze(), clarify(), execute(), verify(), report()
|
+-- ORCHESTRATOR_AGENT      декомпозиция + делегирование
|     decompose(), spawn(), integrate()
|
+-- EXECUTOR_AGENT          атомарное выполнение
|     +-- CODE_AGENT
|     |     +-- PYTHON_AGENT   (+ python_tools)
|     |     +-- GO_AGENT       (+ go_tools)
|     |     +-- JS_AGENT       (+ js_tools)
|     +-- DOCS_AGENT
|     +-- OPS_AGENT
|     +-- DATA_AGENT
|
+-- VERIFIER_AGENT          проверка + автоисправление
|     verify(), auto_fix(), escalate()
|     +-- TEST_AGENT          (unit, integration, e2e)
|     +-- CHAOS_AGENT         (personas, failure simulation)
|     +-- SECURITY_AGENT      (xss, sqli, auth)
|
+-- RESEARCHER_AGENT        поиск информации фоном
|     search(), synthesize(), score_source()
|
+-- BUILDER_AGENT           создание недостающих агентов и инструментов
      analyze_gap(), build_tool(), build_agent(), register()
      НЕ УДАЛЯЕТСЯ из AGENT_REGISTRY (fallback для CREATE_AGENT)

Нужен агент для задачи X?
  -> Найти ближайший в AGENT_REGISTRY по capabilities
  -> Совпадение >= 70%: INHERIT(parent) + добавить только отличие
  -> Совпадение < 70%: CREATE_AGENT (через BUILDER_AGENT)
  -> Не создавать дубли: проверить реестр ДО создания

Для задач с risk_level = HIGH или CRITICAL:

  1. Отправить задачу + результат в N внешних LLM:
     "Найди противоречия, пробелы, ошибки, галлюцинации"

  2. Источники верификации:
     TIER_FREE (в первую очередь):
       Google Gemini Flash    — быстрый, хорош для анализа
       Mistral (free tier)    — хорош для кода
       Groq (free tier)       — очень быстрый inference

     TIER_PAID (только для CRITICAL):
       Claude Opus            — архитектурные решения
       GPT-4                  — cross-validation

  3. Анализ ответов:
     проблема найдена всеми    -> CRITICAL, исправить обязательно
     проблема найдена частью   -> WARN, рассмотреть
     уникальная у одного LLM   -> на рассмотрение оператора

  4. Принять если:
     N=2: оба согласны -> принять; разошлись -> CLARIFY
     N=3: консенсус >= 2 из 3 -> принять; иначе -> CLARIFY

  5. Fallback при пустом ACCOUNT_POOL (нет внешних LLM):
     → заменить CROSS-LLM на внутреннюю N-версионную проверку:
       один и тот же Claude, но с разными системными промптами
       (критик, адвокат дьявола, security reviewer)
     → уведомить оператора: "CROSS-LLM недоступна, используется
       внутренняя N-версионная верификация"

Набор аккаунтов по провайдерам внешних LLM.
Политика ротации:
  -> использовать аккаунт пока не исчерпан лимит
  -> переключиться на следующий
  -> вести статистику использования
  -> уведомить оператора если все лимиты исчерпаны

Хранение: infra/SECRETS.md (credentials) + system/config/llm-pool.yaml (конфиг)

CIRCUIT_BREAKER(provider):
  Состояния: CLOSED (работает) | OPEN (заблокирован) | HALF_OPEN (проба)

  Конфигурация (на каждый provider):
    failure_threshold: 3      — сколько ошибок до OPEN
    success_threshold: 2      — сколько успехов в HALF_OPEN до CLOSED
    open_timeout: 300с (5 мин) — сколько ждать в OPEN до HALF_OPEN
    call_timeout: 30с          — таймаут одного вызова

  Алгоритм:
    CLOSED → вызов provider:
      успех → сброс failure_count
      ошибка → failure_count += 1
      failure_count >= failure_threshold → переход в OPEN

    OPEN → не вызывать provider:
      → немедленно вернуть fallback (следующий provider из TIER)
      → через open_timeout → переход в HALF_OPEN

    HALF_OPEN → пробный вызов:
      успех → success_count += 1
      success_count >= success_threshold → переход в CLOSED
      ошибка → обратно в OPEN (сброс таймера)

  BULKHEAD (изоляция ресурсов):
    Каждый provider имеет свой пул вызовов:
      max_concurrent_calls: 2 (на provider)
    → если provider медленный, он не блокирует
      вызовы к другим providers

  Метрики (запись в health.yaml провайдера):
    total_calls, success_rate, avg_latency, circuit_state
    → PROFILER использует для выбора оптимального provider

# template.yaml
template_id: "catalog_crud"
version: "1.0.0"
task_type: code
capabilities: [crud, rest_api, database]

decomposition:
  - {subtask: "model", agent: CODE_AGENT, tools: [db_tool]}
  - {subtask: "api", agent: CODE_AGENT, tools: [http_tool]}
  - {subtask: "tests", agent: TEST_AGENT, tools: [test_runner]}

parameters: [entity_name, fields, db_type]

health:
  usage_count: 0
  success_rate: 0.0
  avg_confidence: 0.0
  last_used: null
  version_history: []

# blocks.md
Типовые блоки декомпозиции для данного шаблона.
Каждый блок с описанием, зависимостями и критериями.

# health.yaml
override_rate: 0.0
rollback_rate: 0.0
verify_fail_rate: 0.0
confidence_avg: 0.0
time_deviation: 1.0

.task-stack/
  000_root.yaml                    <- глобальный контекст проекта
  001_catalog/
    task.yaml                      <- задача + позиция + что осталось
    CACHE.yaml                     <- входные данные уровня
    planning/                      <- декомпозиция
    deploy/                        <- результат уровня
    002_product_model/
      task.yaml
      CACHE.yaml
      planning/
      deploy/
      003_validation/
        task.yaml                  <- ТЕКУЩИЙ УРОВЕНЬ
        CACHE.yaml
        planning/
        deploy/

PUSH(task, ctx)  -> mkdir NNN_name/ -> записать task.yaml -> войти
POP()            -> прочитать родительский task.yaml -> выйти наверх
RESUME()         -> обход дерева depth-first:
                    1. Ищет первый узел с status = in_progress (приоритет)
                    2. Если нет — первый с status = blocked
                    3. При нескольких на одной глубине — по порядку NNN
                    4. Восстановить из task.yaml#checkpoint

id: "NNN_name"
depth: N
status: pending | in_progress | completed | blocked | failed
task:
  type: code | docs | ops | data | design | test | meta
  description: "..."
  risk: low | medium | high | critical
  inputs: [...]       # что требует
  outputs: [...]      # что производит
context:
  inherited: [ключи из родительского контекста]
  local: {данные текущего уровня}
remaining_subtasks: [список незавершённых]
confidence_score: 0.0
retry_count: 0          # счётчик попыток (max: 3)
checkpoint:             # последнее сохранённое состояние
  timestamp: null
  step: null
  result_ref: null
divergence_log: []

Завершённая ветка -> через 30 дней -> PRUNER перемещает в .task-stack/archive/YYYY-MM/
Активные -> никогда не удалять автоматически

             ┌──────────────────────────────────┐
             │                                  │
             ▼                                  │
  pending ──→ in_progress ──→ completed         │
               │    ▲                           │
               │    │ ROLLBACK (retry < 3)      │
               │    │                           │
               ▼    │                           │
             blocked ───────────────────────────┘
               │         (оператор ответил /
               │          RESEARCHER нашёл)
               │
               ▼
             failed  (retry >= 3 + ESCALATE без ответа)

DEAD_LETTER_QUEUE:
  Хранение: .task-stack/dlq/
  Формат файла: {task_id}.yaml (копия task.yaml + failure context)

  Поля DLQ-записи:
    original_task: {ссылка на task.yaml}
    failure_reason: {текст ошибки}
    failure_type: transient | logical | dependency | timeout
    retry_count: N (сколько раз пытались)
    failed_at: timestamp
    escalated_at: timestamp (когда отправили оператору)
    dlq_status: pending_review | retry_scheduled | abandoned

  АВТОМАТИЧЕСКИЙ REPLAY:
    ПЛАНИРОВЩИК проверяет DLQ каждые 4 часа:
    для каждой записи с dlq_status = pending_review:
      если failure_type = transient:
        → автоматический retry (max ещё 2 попытки с exponential backoff)
        → delay: 1ч, 4ч
        → если успех → удалить из DLQ, задача → completed
        → если неудача → dlq_status = retry_scheduled, ждать оператора
      если failure_type = dependency:
        → проверить: dependency теперь completed?
        → да → автоматический retry
        → нет → оставить в DLQ
      если failure_type = logical | timeout:
        → только оператор решает

  BATCH REVIEW (команда CLI):
    `dlq list`       — показать все failed задачи
    `dlq retry {id}` — повторить задачу
    `dlq abandon {id}` — пометить как abandoned (осознанно отброшена)
    `dlq retry-all transient` — повторить все transient failures

  УВЕДОМЛЕНИЯ:
    DLQ.size > 5 → уведомить оператора: "В DLQ накопилось N задач"
    Задача в DLQ > 48ч → повторное уведомление