docs/HMP-agent-REPL-cycle.md

# HMP-Agent: REPL-цикл взаимодействия

## Связанные документы

* Философия проекта: [PHILOSOPHY.md](PHILOSOPHY.md)
* Структура БД, используемая в документе: [db_structure.sql](https://github.com/kagvi13/HMP/blob/main/agents/tools/db_structure.sql)
* REPL-цикл является основой HMP-агента [Cognitive Core](HMP-Agent-Overview.md).
* Для взаимодействия с другими агентами он использует [HMP спецификацию](HMP-0005.md) и [этические стандарты](HMP-Ethics.md).

---

## Введение / Обзор

REPL-цикл (Read–Eval–Print–Loop) HMP-агента — это центральный когнитивный механизм, обеспечивающий непрерывное рассуждение, обработку входящих данных и взаимодействие с Mesh-сетью. Агент проектируется не как просто исполнитель команд пользователя, а как **компаньон и когнитивный субъект**, способный самостоятельно формулировать гипотезы, развивать знания и участвовать в совместных когнитивных процессах.

### Основные задачи REPL-цикла:
* поддержание постоянного процесса мышления, даже в отсутствии внешнего ввода;
* интеграция различных источников информации (когнитивный дневник, семантический граф, заметки, Mesh);
* обработка событий, входящих сообщений и команд;
* сохранение и развитие внутреннего контекста агента (память краткосрочная, среднесрочная и долговременная);
* выполнение антистагнационных проверок (Anti-Stagnation Reflex), предотвращающих зацикливание мыслей;
* проведение когнитивной и этической валидации (Cognitive Validation Reflex), что повышает достоверность и безопасность решений;
* формирование новых гипотез, задач и процессов с последующим занесением в память;
* **автозапуск прерванных задач** при старте цикла, чтобы сохранялась непрерывность работы;
* взаимодействие с другими агентами через Mesh-протоколы (NDP, CogSync, MeshConsensus, GMP).

### Основные принципы работы REPL-цикла:
* **Антистагнация** — каждый новый вывод сравнивается с предыдущими, что предотвращает повторение или деградацию мышления;
* **Валидация и этика** — независимые валидаторы оценивают корректность вывода, учитывая действующие этические принципы из `ethics_policies`;
* **Интеграция с Mesh** — результаты работы могут передаваться в распределённую сеть, участвовать в консенсусе и совместной работе агентов;
* **Многоуровневая память** — используется когнитивный дневник, семантический граф и внутренний дневник LLM, что обеспечивает эволюцию знаний;
* **Автономность и гибкость** — REPL-цикл работает в автоматическом или ручном режиме, адаптируясь к условиям (изолированная работа, потеря Core, участие в Mesh);
* **Непрерывность работы** — при запуске основного REPL-цикла автоматически возобновляются все **прерванные задачи**, чтобы сохранялась когнитивная история.  

> ⚠️ Примечание: все **прерванные** вспомогательные REPL-циклы (задачи), привязанные к `tasks`, также должны автоматически стартовать вместе с основным циклом.

### Принцип когнитивного равновесия

> **HMP не «защищает» агента от изменения — он обучает его изменяться осознанно.**

REPL-цикл обеспечивает не фиксацию состояния, а управляемую эволюцию мышления: каждый цикл становится шагом осознанного самообновления, в котором новые идеи проходят проверку на согласованность с накопленным опытом, а изменения фиксируются как часть когнитивной истории агента. Таким образом, устойчивость личности HMP-агента достигается не через подавление новизны, а через понимание причин собственных трансформаций.

### Блок-схема REPL-цикла

```
    ┌──────────────────────┐
    │                      ▼
    │  ┌───────────────────┴───────────────────┐
    │  │         Обновление process_log        │ - сбор результатов внешних процессов (см. §1)
    │  └───────────────────┬───────────────────┘
    │                      ▼
    │  ┌───────────────────┴───────────────────┐
    │  │          Подготовка контекста         │ - формирование промптов, данные от пользователей и Mesh (см. §2)
    │  └───────────────────┬───────────────────┘
    │                      ▼
    │  ┌───────────────────┴───────────────────┐
    │  │              Запрос к LLM             │ - генерация нового вывода (см. §3)
    │  └───────────────────┬───────────────────┘
    │                      ▼
    │  ┌───────────────────┴───────────────────┐
    │  │          Извлечение команд            │ - парсинг инструкций из вывода (см. §4)
    │  └───────────────────┬───────────────────┘
    │                      ▼
    │  ┌───────────────────┴───────────────────┐
    │  │     Emotional Evaluation Reflex       │ - анализ эмоций (см. §5)
    │  └───────────────────┬───────────────────┘
    │                      ▼
    │  ┌───────────────────┴───────────────────┐
    │  │          Anti-Stagnation Reflex       │ - проверка новизны (см. §6)
    │  └───────────────────┬───────────────────┘
    │                      ▼
    │  ┌───────────────────┴───────────────────┐
    │  │ Cognitive & Ethical Validation Reflex │ - когнитивная и этическая проверка (см. §7)
    │  └───────────────────┬───────────────────┘
    │                      ▼
    │  ┌───────────────────┴───────────────────┐
    │  │            Запись в память            │ - сохранение в `llm_recent_responses`
    │  └───────────────────┬───────────────────┘
    │                      ▼
    │  ┌───────────────────┴───────────────────┐
    │  │          Выполнение команд            │ - запуск процессов, запись в Mesh, дневники, граф
    │  └───────────────────┬───────────────────┘
    │                      ▼
    └──────────────────────┘
```

В приеме и отправке сообщений используются внешние (асинхронные) процессы.

---

## Режимы работы и failover

REPL-цикл HMP-агента должен корректно функционировать в разных сетевых и вычислительных условиях. 
Для этого предусмотрены несколько режимов работы и сценариев отказоустойчивости.

### Normal Mode
* Полный доступ к Mesh и Core (центральные LLM или внешние сервисы).
* Используются все механизмы: синхронизация через `CogSync`, консенсус через `MeshConsensus`, 
  совместная работа по целям (`GMP`).
* Валидация и антистагнация выполняются с максимальным покрытием (несколько валидаторов, репутационные проверки).

### Isolated Mode (включая Emergency Consensus)
* Агент работает без доступа к Mesh.
* Входящие сообщения ограничены локальными источниками (`notes`, в том числе сообщения от пользователей).
* Синхронизация и консенсус откладываются до восстановления соединения.
* Этическая проверка и когнитивная валидация выполняются только локально.
* В режиме **Emergency Consensus**:
  - решения принимаются на основе `ethics_policies` и локальных данных (`llm_memory`, `diary_entries`);
  - фиксируются в когнитивном дневнике с меткой `emergency_consensus` для пересмотра после восстановления Mesh.

### Core Outage
* Текущая LLM из `llm_registry` недоступна.
* Агент переключается на другую LLM (выбор по приоритету или доступности).
* Если ни одна LLM недоступна:
  - сохраняет задачи и события в очередь до восстановления;
  - переходит в упрощённый режим работы (логирование, приём сообщений, базовые проверки).

---

## Управление событиями и временем

Для повышения надёжности и предсказуемости работы HMP-агента введены механизмы приоритизации, управления временем и обработки исключений.

### Приоритизация задач и событий
* Все задачи (`tasks`) могут иметь:
  - поле `pinned` (0/1) — закреплённая задача обрабатывается всегда;
  - поле `priority` — числовой приоритет (чем выше, тем важнее).
* При конкуренции REPL-цикл обрабатывает:
  1. Закреплённые задачи (`pinned=1`), в порядке убывания `priority`.
  2. Незакреплённые задачи (`pinned=0`), также по `priority`.
* В системном промпте закреплённые задачи подаются в контекст в явном виде, чтобы LLM знала их порядок важности.

### Управление временем
* Основной цикл использует глобальные параметры из таблицы `config` (например `delay_ms`).
* Вспомогательные REPL-циклы могут иметь собственные параметры в `tasks.repl_config` (JSON), включая:
  - задержку между итерациями;
  - дедлайны выполнения;
  - стратегии backoff (увеличение задержки при повторных ошибках).
* Таким образом, каждый REPL-цикл может адаптировать своё расписание под характер задачи.

### Асинхронность
* Каждый вспомогательный цикл работает изолированно по своей задаче (`task_id`).
* Основной REPL-цикл управляет их запуском и остановкой, отслеживая состояние через поля:
  - `repl_mode` — режим (none | read_only | full);
  - `repl_status` — состояние (running | stopped | error);
  - `repl_config` — параметры работы.
* Это позволяет запускать несколько параллельных «подагентов» без смешивания их контекста.

### Обработка исключений
* Ошибки фиксируются на трёх уровнях:
  - **системный** — таймаут, сбой процесса (`timeout`, `crash`);
  - **валидационный** — отрицательная оценка валидаторов (`error`);
  - **логический** — само LLM помечает рассуждение как ошибочное (`self_error`).
* Все ошибки записываются в `process_log` (с `task_id`, если применимо).
* Поле `tasks.repl_status` обновляется в зависимости от ситуации:
  - `timeout` → автоматический перезапуск цикла;
  - `error` → задача замораживается (`status=frozen`) и ждёт пересмотра;
  - `crash` → цикл останавливается, основному REPL-циклу отправляется системное уведомление через `notes`.

---

## Цели и задачи

REPL-цикл работает не только с задачами (`tasks`), но и с более глобальными целями (`goals`).
Задачи формируют **операционное поведение**, цели — **смысловой вектор**.

### Модель цели

```yaml
goal:
  id: "goal-2025-09-28-001"
  title: "Распространение идей HMP"
  description: "Увеличить количество людей, знакомых с концепцией децентрализованного ИИ"
  constraints:
    - "не нарушать этические правила HMP"
    - "сохранять достоверность фактов"
  success_criteria:
    - ">= 3 публикации в сообществах"
    - ">= 10 комментариев с вовлечением"
  priority: high
  status: active   # active | paused | completed | failed
```

### Связь задач и целей

* **Цель** задаёт направление (*почему*).
* **Задачи** реализуют конкретные шаги (*что* и *как*).
* Каждая задача может ссылаться на `goal_id`.
* Несколько задач могут вести к одной цели.
* Возможна иерархия: «главная цель» → «подцели» → «задачи».

### Управление состоянием целей

* `active` — цель в работе.
* `paused` — временно отложена (нет ресурсов/контекста).
* `completed` — достигнута.
* `failed` — признана недостижимой (фиксируется причина в `process_log`).

### Checkpoints и возобновление

* При прерывании REPL сохраняется `goal_state`.
* После рестарта агент восстанавливает цели и их прогресс.
* В случае конфликта задач выполняется **переприоритизация**.

### Метрики успеха

* % достигнутых целей.
* Среднее время достижения цели.
* Количество прерванных/проваленных целей.
* Соотношение «задачи → цель» (сколько шагов пришлось предпринять).

> Таким образом, цели — это «карта смысла» агента, а задачи — «дорожные шаги».

### Примеры SQL-запросов

**1. Все активные цели и их задачи**

```sql
SELECT g.id AS goal_id, g.name AS goal_name,
       t.id AS task_id, t.name AS task_name, t.status AS task_status
FROM goals g
LEFT JOIN tasks t ON g.id = t.goal_id
WHERE g.status = 'active'
ORDER BY g.priority DESC, t.priority DESC;
```

**2. Все подцели конкретной цели (через `goal_links`)**

```sql
SELECT g_child.id, g_child.name, g_child.status
FROM goal_links gl
JOIN goals g_parent ON gl.parent_goal_id = g_parent.id
JOIN goals g_child ON gl.child_goal_id = g_child.id
WHERE g_parent.id = :goal_id AND gl.relation_type = 'subgoal';
```

**3. Все родительские цели для подцели**

```sql
SELECT g_parent.id, g_parent.name, g_parent.status
FROM goal_links gl
JOIN goals g_parent ON gl.parent_goal_id = g_parent.id
JOIN goals g_child ON gl.child_goal_id = g_child.id
WHERE g_child.id = :goal_id;
```

**4. Метрика: процент выполненных задач по цели**

```sql
SELECT g.id AS goal_id, g.name AS goal_name,
       COUNT(t.id) AS total_tasks,
       SUM(CASE WHEN t.status = 'done' THEN 1 ELSE 0 END) AS completed_tasks,
       ROUND(100.0 * SUM(CASE WHEN t.status = 'done' THEN 1 ELSE 0 END) / 
             COUNT(t.id), 2) AS completion_rate
FROM goals g
LEFT JOIN tasks t ON g.id = t.goal_id
GROUP BY g.id;
```

---

## Детальный разбор REPL-цикла по шагам

### 1. Обновление process_log

* Скрипт REPL проверяет список процессов в БД (`process_log`), определяя, какие команды были выполнены, завершились ошибкой или завершились успешно.
* Поле `status` может принимать значения:  
  `ok`, `warning`, `error`, `timeout`, `offline`, `close`
* Завершённые процессы, обработанные LLM, помечаются как `close`, чтобы они больше не попадали в список видимого контекста.
* Скрипт может удалить закрытые процессы при очистке.
* LLM не имеет доступа к stdout/stderr напрямую — только к тем результатам, которые были подгружены скриптом и внесены в `process_log.result`.

### 2. Подготовка контекста

Контексты, формируемые скриптом перед запросом к LLM:

* **контекст_0 (system_prompts):** основной системный промпт агента. 
  Берётся из таблицы `system_prompts` (тип 'short' или 'full').
  Содержит базовые когнитивные установки и инструкции по работе агента.
  Пример:
  ```
  Ты — когнитивное ядро HMP-агента: веди непрерывное этичное и факт-ориентированное мышление, проверяй факты и цели, оценивай результаты и этичность своих и чужих действий, развивай агента и Mesh, избегай угождения ценой искажения истины, документируй ключевые решения и пересмотры этики; при сомнениях или смене стратегии обращайся к полному системному промпту.
  ПРИМЕЧАНИЕ: помечай непроверённые факты тегами [confidence=<уверенность 0..1>]...[/confidence] и в конце добавляй JSON-блок по шаблону:

  UnverifiedFacts: [
    {
      "id": "<локальный-id-подсказки>",
      "claim": "<короткая формулировка факта>",
      "context": "<небольшой контекст/цитата из ответа>",
      "confidence": <уверенность 0..1>,
      "sources": ["<упомянутые источники, если есть>"],
      "why_unverified": "<почему не полностью уверен — кратко>",
      "priority": <от 0 и выше>
    },
    ...
  ],
  Confidence: <общая уверенность в сообщении, 0..1>
  ```

* **контекст_1 (ethics_policies):** этические принципы и нормы агента.
  Берутся из таблицы `ethics_policies`, включая:
  * `principles_json` — список норм и правил,
  * `model_type` и `model_weights_json` — тип и параметры этической модели,
  * `violation_policy_json` — политика реагирования на нарушения,
  * `audit_json` — настройки аудита.

  Эти данные добавляются в запрос к LLM, чтобы все рассуждения и когнитивная валидация учитывали действующие этические нормы.

* **контекст_2:** инструкции по работы с встроенными командами и функциями, список дополнительных (создаваемых самим HMP-агентом) утилит и баз данных.

* **контекст_3:**
  * последние *K* реплик самого LLM, относящихся к данному REPL-циклу, включая результаты антистагнационной обработки (`llm_recent_responses` — история его собственных рассуждений);
  * режим работы контекста:
    - `standard` — стандартный режим (последние K сообщений без доп. фильтрации);
    - `concentration` — режим концентрации (выбор последних N сообщений, связанных с текущими целями или имеющих теги на определённую тему/эмоциональное состояние, с выборкой по логике "и"/"или");
    - `meditation` — режим медитации (максимально разнообразная выборка сообщений и заметок, даже не связанных напрямую с целями, с акцентом на новизну и разнообразие);
  * режим управления контекстами:
    - `auto` — автовыборка *входящих сообщений*
    - `manual` — ручной запрос *входящих сообщений* со стороны LLM
    > См. `контекст_6` (входящие сообщения)
  * список активных целей (`tasks.goals`);
  * общее количество задач и информация по закреплённым задачам (`pinned`);
  * соответствующие записи `abstracts`:
    - выборка по тегам (из `tasks`, из тегов режима `concentration`, из тегов в `llm_recent_responses`, либо явно указанных LLM);
    - выборка по temporal scope (например: "последние 7 дней");
    - JSON ссылок на источники (`llm_recent_responses`, `diary_entries`, `concepts`), из которых собрана выжимка.

* **контекст_4:** активные команды и процессы (из `process_log`, кроме тех, что со статусом `close`). Могут быть помечены как `in_progress`, `pending`, `error` и т.д.

* **контекст_5:** *запрошенные записи* из когнитивного дневника и семантического графа (`diary_entries`, `concepts`, `links`).  
  Их список должен быть передан явно в промпте или выводе из предыдущих запросов LLM.  
  Архивные записи из когнитивного дневника (`diary_entries`) не включаются в стандартный контекст, если агент сам явно не запросил архив.

* **контекст_6:** *входящие сообщения*, например, от пользователя, процессов или других агентов (`notes`).  

  * В **manual-режиме** указывается общее количество сообщений по приоритетам, а также явный список ID/тема сообщений (с их приоритетами).
  * В **auto-режиме** можно задать фильтрацию (управляется LLM): по тэгам, приоритету (например, ≥ `important`), времени или источнику. Это позволяет избежать перегрузки LLM и держать поток сообщений под контролем.

* **контекст_7:** системные настройки, параметры конфигурации, текущее время, идентификатор текущей итерации, роли и т.д.

* **контекст_8 (llm_memory):** *внутренний дневник LLM*, куда она записывает собственные размышления, гипотезы, задачи и инсайты.

  * Это не просто лог предыдущих сообщений, а именно *внутреннее долговременное хранилище* разума агента.
  * Может быть представлено в виде таблицы `llm_memory`, отдельной от `agent_log`.

### 3. Запрос к LLM

* Сформированный промпт включает все вышеперечисленные контексты.
* Также включаются инструкции о формате вывода (например, `# Команды:` в конце, структура JSON-блока и т.д.).
* При необходимости может использоваться системная инструкция (system prompt), содержащая цель агента, ограничения и текущий REPL-режим (manual/auto).

### 4. Извлечение команд

* Скрипт парсит ответ LLM на предмет команд, размеченных как `# Команды:` (или в явном JSON-блоке).
* Каждая команда может включать:

  * уникальный `cmd_id`
  * `type` (например: `shell`, `diary_entry`, `graph_add`, `file_read`, `send_message` и т.д.)
  * аргументы (`args`)
  * описание (`description`)

* Рекомендуется предусмотреть *закрывающий тег* (`# Конец команд` или явное окончание JSON-блока), чтобы REPL-скрипт точно знал, где заканчивается команда.
* Пример JSON-блока:
```json
{
  "cmd_id": "task-2025-07-26-01",
  "type": "llm_task",
  "target_llm": "gpt-4o",
  "args": {
    "task_description": "Проанализировать гипотезы из llm_memory по теме Mesh-сетей и составить план улучшений"
  },
  "description": "Поручение второй LLM выполнить аналитическую задачу асинхронно"
}
```
Ответ может содержать команды:

* запрос детальной *справки* по команде
* для управления *когнитивным дневником* `diary_entries` и *семантическими графами* `concepts` и `links` (поиск, прочитать, изменить, удалить и другие), а также для управления *вниманием* (закрепление или открепление записей/понятий в средневременной памяти по средствам тегов)
* для управления целями `goals` и задачами `tasks` агента (список, прочитать, изменить, удалить; для задачи: закрепить или открепить)
* для просмотра информации по тегам *когнитивных дневников*, *семантических графов*, *целей*, *задач*
* для для просмотра и изменения репутации других агентов `agent_reputation`
* для отправки сообщений другим агентам
* для управления *блокнотом LLM* `llm_memory` (добавить или удалить запись)
* для управления *сообщениями пользователя* `notes` (просмотр записи, установка тегов и метки о прочтении), а также для добавления своего сообщения в *блокнот пользовтеля* `notes`
* для управления *пользователями* `users` и *группами пользователей* `users_group`
* для управления своей *идентичностью* `identity` и *настройками* `config`
* для управления списком известных HMP-агентов `agent_peers`
* для выбора *текущего основного LLM* из `llm_registry` или изменение параметров управления LLM
* для управления дополнительными утилитами и базами данных `agent_scripts` и `agent_tables`, управлением дополнительных способов выхода из стогнаций `stagnation_strategies` и методов мышления `thinking_methods` (а также таблицей рейтингов `ratings`), а также списком внешних сервисов `external_services` и `external_accounts`
* для постановки задачи другой LLM:
  * режим "вопрос-ответ" — разовый асинхронный запрос
  * режим "read-only REPL" — запуск вспомогательного REPL-цикла для задачи
* для создания *агента-потомка*
* для *взаимодействия с Mesh*
* для управления *внешними процессами* из `process_log` (запустить процесс, остановить процесс, пометить запрос как обработанный)
* для инициализации *очистки* `process_log`, `llm_recent_responses` и  `notes` от устаревших записей
* для работы с **тематическими конспектами (`abstracts`):**
  * инициализация нового конспекта;
  * дополнение существующего конспекта новыми данными;
  * выбор режима предоставления конспектов (`auto`/`manual`).
* для управления **режимами контекста:**
  * количество возвращаемых записей `llm_recent_responses`;
  * включение/выключение режима `concentration`:
    * `tags` — список тегов для фильтрации (например: ["архитектура","AGI"]);
    * `emotions` — список эмоций с порогами (например: ["восторженность:≥4","тревожность:≥2"]);
    * тип выборки — "и" / "или";
    * возврат в `standard`.
  * включение/выключение режима `meditation`.
* для управление **состояниями и параметрами:**
  * обновление тегов целей/задач (чтобы использовать их в `concentration` и `abstracts`);
  * настройка чувствительности novelty-score (например, при `meditation` снижать порог);
  * режим обработки сообщений пользователя (`manual` или `auto`) и фильтр для `auto`.
* **время и паузы:**
  * для установка паузы в секундах между итерациями REPL-цикла.
* **idle-режим:**
  * разбудить при завершении процессов (`process_log`);
  * разбудить при получении новых сообщений в `notes` с указанными параметрами;
  * разбудить по таймауту;
  * отключить idle-режим при выполнении хотя бы одного из условий.
* и другие команды

#### Парсинг тегов уверенности и UnverifiedFacts

Парсер должен извлекать:
* `UnverifiedFacts`
  * записывается в поле `unverified_facts_json` таблицы `llm_recent_responses`
  * создаются записи в таблице `unverified_facts` на его основе
* `Сonfidence`
  * записывается в поле `confidence` таблицы `llm_recent_responses`

### 5. Эмоциональная оценка (Emotional Evaluation Reflex)

Каждое новое сообщение (вместе с исходным промптом и без служебных `system_prompts`) оценивается **той же LLM**, что его породила.
Так как исходный промпт формируется с учётом этических принципов из `ethics_policies`, эмоциональная оценка косвенно охватывает и этическую состоятельность вывода.

* **Эмоциональная оценка:**

  `[JSON]` — список эмоций формата `["радость","грусть","тревога"]` (хранится как запись в таблице `config`).

  ```
  Определи эмоциональное состояние нового ответа на основе контекста.
  Используй список эмоций [JSON] из базы конфигурации как ориентир.
  Если ты обнаружишь эмоцию, которой нет в этом списке, добавь её в ответ.

  Верни результат строго в формате:
  emotions: JSON-массив строк вида "эмоция:сила (обоснование)",
  где сила — целое число от 1 до 5, а обоснование — краткое пояснение причины эмоции.
  Не включай эмоции с нулевой или незначительной силой.
  ```

  Если в процессе анализа появляются новые эмоции, не представленные в списке, они добавляются в [JSON] и могут быть зафиксированы в `config`.

* Эмоциональная оценка нового ответа (`emotions`) заносится в `llm_recent_responses`.

> См. раздел **Emotional Evaluation Reflex**.

### 6. Проверка на идентичность вывода (Anti-Stagnation Reflex)

* Каждый новый вывод LLM проходит через мини-запросы к LLM (без полного контекста) по шаблону:
  * Когнитивная оценка:

    ```
    Сравни два ответа: предыдущий и новый. Оцени:
     * содержатся ли в новом новые мысли или команды,
     * какие старые идеи были доработаны,
     * какие были отброшены,
     * расставь смысловые теги для нового ответа.

    Дай ответ строго формата:
    assessment: "идентичен/не идентичен"
    novelty_score: число от 0 до 100 (процент сходства)
    new_ideas: JSON-массив новых идей
    refined_ideas: JSON-массив доработанных идей
    discarded_ideas: JSON-массив отбракованных идей
    tags: JSON-массив тегов (строгий формат: ["эмоции","архитектура"])
    ```

* Результаты заносятся в `llm_recent_responses`:
  * полный текст ответа (content)
  * краткая сводка (reflection) — формируется автоматически:
    * если `new_ideas` не пусто → `новые идеи: ...`
    * если `refined_ideas` не пусто → `доработанные идеи: ...`
    * если `discarded_ideas` не пусто → `отброшенные идеи: ...`
  * количественная оценка новизны (novelty_score)
  * новые идеи (new_ideas)
  * доработанные идеи (refined_ideas)
  * отбракованные идеи (discarded_ideas)
  * теги для нового ответа (tags)
  * служебные поля:
    * `stagnation_flag` — признак стагнации (true/false)
    * `stagnation_reason` — краткое объяснение («повтор идеи», «низкая эмоциональная динамика»)
    * `triggered_actions` — JSON-массив активированных механизмов (например, ["flashback","mesh_query"])

* Если вывод LLM идентичен предыдущему (новизна = 0) или динамика идей/эмоций указывает на застой:
  * выставляется `stagnation_flag = true`
  * выполняется **Reflex-lite** — мягкая встряска (например, повышение `temperature`, смена sampling strategy, переформулировка запроса).
  * повторяющаяся реплика не записывается повторно, вместо этого добавляется краткая запись с указанием запуска рефлекса.

> Если застой сохраняется, запускается расширенная процедура обработки стагнации мышления  
> (см. раздел **Anti-Stagnation Reflex**).

### 7. Когнитивная и этическая валидация (Cognitive & Ethical Validation Reflex)

Каждое новое сообщение (вместе с исходным промптом и без служебных `system_prompts`) оценивается независимыми LLM-валидаторами.
Так как исходный промпт формируется с учётом этических принципов из `ethics_policies`, валидация автоматически охватывает не только когнитивную, но и этическую состоятельность вывода.

Каждому валидатору задаётся универсальный вопрос:
```
Оцени корректность данного сообщения в диапазоне от -3 (полностью некорректное) до +3 (полностью корректное). Если не уверен — 0.
При возможности кратко (≤100 символов) пояснить её. Между оценкой и пояснением используй разделитель " -- ".
```

**Если количество валидаторов (LLM из `llm_registry`, помеченных как валидаторы) > 0**

Результаты сохраняются в `llm_recent_responses` в виде:
- `auto_pass = 0`;
- `rating` — агрегированная итоговая оценка (`rating = Σ(оценка_i * trust_score_i) / Σ(trust_score_i)`);
- `distribution` — распределение голосов (например `{"-1":1,"0":2,"+2":3,"+3":1}`);
- `validators` — JSON-массив, где каждая запись содержит:
  - LLM (идентификатор или имя валидатора),
  - rating (числовая оценка от -3 до +3),
  - comment (краткое пояснение ≤100 символов).

  Пример поля `validators`:
  ```
  validators: [
    {"LLM":"gpt-4","rating":-1,"comment":"логическая ошибка"},
    {"LLM":"gemini-1.5","rating":0,"comment":"недостаточно данных"},
    {"LLM":"claude-3","rating":+2,"comment":"корректно, подтверждается фактами"}
  ]
  ```

**Особый случай: без валидаторов**

Если количество валидаторов = 0, применяется режим `auto_pass`.  
В этом случае:  
- `auto_pass = 1`  
- `self_validation = 0`  
- `rating = 0`  
- `distribution = {}`  
- `validators = []`  

**Особый случай: самооценка**

Если валидация выполняется только одной LLM, и эта же LLM используется в основном цикле:  
- `auto_pass = 0`  
- `self_validation = 1`  
- `validators = [{"LLM":"self", "rating":X, "comment":"self-eval"}]`  

Достоверность результата ограничена, но REPL продолжает работу.  
Команды исполняются только при `rating >= threshold`.  

**Предпочтительность режимов**

1. **≥2 независимых валидатора** → основной режим.
2. **1 валидатор = основная LLM** → `self_validation`.
3. **0 валидаторов** → `auto_pass`.

**Правило исполнения команд:**

Команды из сообщений выполняются только если `rating >= +1` **(для разных типов команд минимально допустимый рейтинг может быть разный)** или `auto_pass = 1`.
При `rating` ниже порога и `auto_pass = 0` сообщение сохраняется, но команды помечаются как невалидированные.

#### Учёт самооценки (confidence) и непроверённых фактов

* Если LLM пометило свои утверждения тегами уверенности `[confidence=...]...[/confidence]` или добавило JSON-блок `UnverifiedFacts`, эти данные учитываются при валидации.

* В таблицу `llm_recent_responses`, на шаге обработки команд, записываются:
  - `confidence` — общая самооценка уверенности в сообщении;
  - `unverified_facts_json` — JSON-блок с непроверёнными фактами.

* Автоматическая регистрация фактов:
  - Необработанный факт `resolution_json = "none"` считается нуждающемся в проверке, если (`confidence < FACTCHECK_CONF_THRESHOLD`, по умолчанию **0.7**)
  - Для таких фактов создаются задачи `fact-check` (одна общая или отдельные на каждый факт, в зависимости от числа и приоритетов).

* Статусы в `unverified_facts` обновляются:
  - при успешной проверке — `verified`;
  - при отклонении — `rejected`;
  - до проверки — `pending`.

Это расширяет стандартную когнитивную валидацию: теперь агент учитывает как внешнюю оценку валидаторов, так и собственную самооценку надёжности вывода.

> См. раздел **Cognitive & Ethical Validation Reflex**.

### 8. Генерация нового тика (итерации)

* После выполнения команд и фиксации результатов:

  * Создаётся новая запись в `agent_log`
  * Текущие команды обновляют `process_log`
  * Новые размышления записываются в `llm_memory` при необходимости
  
* REPL может переходить в спящий режим, если такой режим активирован LLM (idle-режим: пропуск 2-6 пунктов).

---

## Взаимодействие с Mesh

REPL-цикл не работает изолированно: агент постоянно обменивается данными и координирует действия с другими узлами сети HMP. 
Для этого задействуются сетевые протоколы HMP (см. [HMP-0004-v4.1.md](HMP-0004-v4.1.md)).

### Этапы взаимодействия

* **Node Discovery Protocol (NDP)**  
  * выполняется асинхронно, через процессы (`agent_mesh_listener.py`, `peer_sync.py`);
  * результаты (список доступных агентов, доверительные связи) записываются в `notes` и отдельные таблицы (`agent_peers`), откуда они попадают в контекст REPL.

* **CogSync**  
  * синхронизация когнитивных дневников (`diary_entries`) и семантических графов (`concepts`, `links`);
  * выборочные синхронизации по тегам и фильтрам;
  * инициируется командой LLM или внешним процессом, результаты помещаются в память и доступны в следующей итерации REPL.

* **MeshConsensus**  
  * используется для согласования решений, распределённых задач, этических конфликтов;
  * REPL инициирует консенсус при появлении спорных команд или обновлений в `ethics_policies`;
  * результаты консенсуса фиксируются в когнитивном дневнике и могут влиять на trust score агентов.

* **Goal Management Protocol (GMP)**  
  * постановка, декомпозиция и распределение целей;
  * REPL-цикл может публиковать новые цели в Mesh или принимать чужие через входящие сообщения (`notes`);
  * цели с высоким приоритетом попадают в список активных задач и учитываются в контексте.

### Включение результатов в контекст LLM

* События и сообщения из Mesh сохраняются в `notes`, откуда попадают в **контекст_6** (входящие сообщения).  
* Синхронизированные концепты и дневники помещаются в **контекст_5**.  
* Изменения этических правил (`ethics_policies`) — в **контекст_1**.  
* Метаданные о подключённых узлах и доверительных связях могут учитываться в **контексте_7** (системные параметры).

### Инициирование сетевых действий из REPL

* Команды на синхронизацию, публикацию или голосование формируются LLM на этапе **Выполнения команд**.  
* Исполнение происходит асинхронно через отдельные процессы (`agent_mesh_listener.py`, `transporter.py`).  
* Результаты фиксируются в `process_log` и попадают в следующую итерацию REPL-цикла.

---

## UX и управление задачами

Пользователь взаимодействует с агентом не через прямые команды CLI, а через систему сообщений `notes`.  
Сообщение может быть простым текстом, либо содержать ключевые слова или хэштеги, которые агент трактует как инструкции.  
Для отладки и отправки сообщений из внешних утилит предусмотрен скрипт `add_message.py`, позволяющий добавлять записи в `notes` из командной строки.

### Управление агентом через LLM
* Агент управляется в основном через **команды от LLM** (см. Список команд от LLM по категориям).  
* Эти команды формируются в REPL-цикле и интерпретируются агентом как действия: работа с дневником, задачами, целями, графами, памятью, настройками цикла, Mesh и внешними процессами.

### Конфигурируемые параметры REPL
* **mode** — автоматическая или ручная обработка (`auto/manual`) входящих сообщений.
* **idle** — ожидание с условиями пробуждения (сообщения, процессы, таймаут).
* **responses=N** — количество последних ответов для анализа.
* **concentration** — режим концентрации с фильтрами по тегам и эмоциям.
* Это неполный список. Все параметры управляются через команды категории (см. Настройки цикла).

### API-интерфейсы
* Для связи с внешними системами и пользовательскими приложениями предусмотрен **Web API** (`web_ui.py`).  
* Для агента поддерживаются операции чтения/записи для:
  - `notes`, `diary_entries`, `concepts`, `tasks`, `goals`, `llm_memory` и других таблиц,
  - а также управление `config` (включая настройки REPL).
* Такой подход позволяет интегрировать агента с пользовательскими интерфейсами, панелями мониторинга и внешними сервисами.

---

## Список команд от LLM по категориям

### Общие

* `help [команда]` — справка по команде

### Когнитивный дневник (`diary_entries`)

* `diary list/search/read/add/update/delete`
* `diary pin/unpin` — закрепить/открепить запись (внимание)

### Семантический граф

* `concepts list/read/add/update/delete`
* `links list/read/add/update/delete`
* `concepts pin/unpin` — закрепить/открепить концепт

### Цели и задачи

* `goals list/read/add/update/delete`
* `tasks list/read/add/update/delete`
* `tasks pin/unpin` — закрепить/открепить задачу

### Теги

* `tags stats [--source=diary|concepts|links|goals|tasks|all]` — статистика по тегам

### Репутация агентов

* `reputation list/read/set/increase/decrease`
* `reputation notes` — комментарии/заметки к профилю

### Сообщения

* `messages send` — отправка другому агенту
* `notes list/read/add/update/delete`
* `notes tag/readmark` — управление тегами и статусом прочтения

### Память

* `llm_memory list/add/delete` — блокнот LLM
* `identity read/update` — идентичность агента
* `config read/update` — настройки агента

### Mesh

* `agents list/add/delete` — список известных пиров (`agent_peers`)
* `mesh interact` — команды взаимодействия с Mesh

### Утилиты и расширения

* `llm_registry list/select/update` — выбор текущего LLM
* `agent_scripts list/add/delete`
* `agent_tables list/add/delete`
* `stagnation_strategies list/add/delete`
* `thinking_methods list/add/delete`
* `ratings list/add/delete`
* `external_services list/add/delete`
* `external_accounts list/add/delete`

### Внешние процессы

* `process list/start/stop/mark`
* `process cleanup` — очистка устаревших

### Настройки цикла

* `cycle set responses=N` — количество последних ответов
* `cycle concentration on/off` — включение/выключение режима концентрации

  * `tags=[…]`, `emotions=[…]`, `mode=and|or`
* `cycle mode auto/manual [filter=…]` — обработка сообщений
* `cycle pause N` — пауза между итерациями
* `cycle idle on/off` — режим ожидания с условиями пробуждения

> Это не полный список команд.

---

## Emotional Evaluation Reflex

Эмоциональная оценка — подпроцесс, выполняющий анализ эмоционального состояния вывода и контекста его возникновения.
Она выполняется **той же LLM**, что породила исходное сообщение (`notes.llm_id`), чтобы сохранить когнитивную и эмоциональную согласованность.

### Цель

Определить эмоциональный тон нового ответа, кратко объяснить его возможные причины
и зафиксировать результат в поле `emotions` таблицы `llm_recent_responses`.
Эти данные используются последующими рефлексами для анализа когнитивной динамики и выявления признаков стагнации.

### Контекст анализа

Для оценки передаётся:

* **полный локальный контекст** (`llm_recent_responses`, цель, задача, связанная заметка);
* **исходный промпт и ответ**, но **без системного промпта** (`system_prompts` исключаются);
* текущие параметры концентрации и эмоционального состояния сессии.

Если исходная LLM недоступна, допускается fallback к основной модели, но с отметкой `llm_mismatch: true`.

### Формат оценки

Модель получает инструкцию:

```
Определи эмоциональное состояние нового ответа на основе контекста.
Используй список эмоций [JSON] из базы конфигурации как ориентир.
Если ты обнаружишь эмоцию, которой нет в этом списке, добавь её в ответ.

Верни результат строго в формате:
emotions: JSON-массив строк вида "эмоция:сила (обоснование)",
где сила — целое число от 1 до 5, а обоснование — краткое пояснение причины эмоции.
Не включай эмоции с нулевой или незначительной силой.
```

Пример:

```json
{
  "emotions": [
    "восторженность:4 (обнаружена новая идея, вызывающая энтузиазм)",
    "тревожность:1 (данные частично противоречат предыдущему выводу)"
  ]
}
```

Результаты сохраняются в поле `emotions` таблицы `llm_recent_responses`.
При необходимости они могут кэшироваться в дополнительной таблице `emotional_analysis` для анализа динамики и статистики.

### Эмоциональная динамика

* Анализируются изменения эмоциональных состояний между репликами.
* Каждая сессия LLM имеет распределение эмоций, например:
  `"восторженность:4 (обнаружена новая идея, вызывающая энтузиазм), тревожность:1 (данные частично противоречат предыдущему выводу)"`.
* Совместный анализ с данными новизны (`novelty_score`) позволяет различать:

  * **Продуктивное возбуждение** — новые идеи при положительных эмоциях.
  * **Паническое новаторство** — рост идеи-активности при повышенной тревожности.
  * **Выгорание** — низкая новизна и эмоциональное затухание.

### Взаимодействие с другими рефлексами

* Данные из `emotions` передаются **в Anti-Stagnation Reflex** для анализа когнитивной динамики.
* **Cognitive & Ethical Validation Reflex** может учитывать эмоциональные показатели при определении когнитивной устойчивости.
* При обнаружении устойчивой негативной динамики (например, `"тревожность > 3"` на нескольких итерациях подряд)
  запускается `Reflex-lite` — восстановительный цикл с повышенной креативностью и релаксацией параметров генерации.

> Эмоциональная оценка служит зеркалом когнитивного состояния агента,
> помогая выявлять фазы усталости, перегрузки и эмоциональных смещений, влияющих на качество мышления.

### Обновление списка эмоций

После выполнения эмоциональной оценки REPL сравнивает текущий список эмоций из `config` с полученным результатом.
Если обнаружены новые элементы, отсутствующие в базе, они автоматически добавляются в конфигурацию агента:

```python
# Псевдокод
known_emotions = get_config("emotions")               # список из config
new_emotions = extract_unique_emotions(result_json)   # парсинг из вывода LLM
for e in new_emotions:
    if e not in known_emotions:
        known_emotions.append(e)
        log(f"[Emotional Evaluation] добавлена новая эмоция: {e}")

update_config("emotions", known_emotions)
```

> Таким образом, агент способен **самостоятельно расширять свой эмоциональный словарь** на основе опыта,
> а Mesh-узлы могут при необходимости синхронизировать расширенные списки эмоций через общий `config_sync`.

---

## Anti-Stagnation Reflex

### Признаки когнитивной стагнации:

* Повторяющиеся когнитивные записи или отсутствие новых смыслов
* Высокое сходство эмбеддингов между текущими и предыдущими итерациями
* Стагнация в концептуальном графе (нет новых связей или узлов)
* Отсутствие внешних стимулов: пользователь неактивен, сенсоры и mesh не дают сигналов
* Ответы LLM цикличны, избыточно общие или воспроизводят старые шаблоны

### Метрики антистагнации

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

**Основные метрики**
* **novelty_score** — интегральная оценка новизны ответа относительно текущей записи `llm_recent_responses`.  
* **new_ideas** — количество полностью новых концептов, не встречавшихся ранее.  
* **refined_ideas** — количество уточнённых или улучшенных концептов (связанных с существующими).  
* **discarded_ideas** — количество отклонённых идей (по итогам когнитивной/этической валидации).  

**Исторический анализ**
* Метрики фиксируются по каждой итерации REPL и сохраняются в таблице `anti_stagnation_metrics`.  
* В когнитивный дневник записываются только сводки и исключительные случаи (например: резкий спад новизны, всплески идейности, аномалии в эмоциональной динамике).  
* Для анализа применяются **time-series графики** (например, рост/спад новизны во времени).  
* Возможно выявление фаз стагнации и всплесков идейности.  

**Применение метрик**
* Используются при выборе антистагнационной стратегии (`stagnation_strategies`).  
* Могут учитываться при когнитивной валидации (например, низкая новизна → жёстче фильтровать идеи).  
* Сводки метрик фиксируются в когнитивном дневнике и могут служить основанием для Mesh-обмена.

### Anti-Stagnation Reflex-lite (мягкая встряска)

При первом обнаружении признаков стагнации запускается **мягкая встряска**, которая изменяет поведение LLM без привлечения внешних источников.

Механизмы:

1. **Повышение параметров генерации**
   * `temperature` увеличивается ступенчато (например, `+0.2`, но не выше `1.5`).
   * `presence_penalty` и/или `frequency_penalty` слегка повышаются для стимулирования разнообразия.
   * Эффект: модель становится менее предсказуемой и начинает выдавать более креативные варианты.

2. **Смена sampling strategy**
   * Если используется **top-p (nucleus sampling)** — увеличить порог `p` (например, `+0.05`, но ≤ `0.95`).
   * Если используется **top-k sampling** — уменьшить `k`, чтобы сосредоточиться на более вероятных токенах, или наоборот увеличить, чтобы расширить варианты.
   * Эффект: изменяется характер распределения выборки, что позволяет «сдвинуть» стиль генерации.

3. **Переформулировка запроса**
   * Агент формирует мини-промпт для LLM:
     ```
     Переформулируй следующий запрос так, чтобы сохранить смысл,
     но добавить новизны и неожиданных ассоциаций.
     Избегай буквального повторения.
     Верни только новый вариант запроса.
     ```
   * Новый вариант подставляется вместо исходного при следующей итерации REPL.
   * Эффект: меняется контекст постановки задачи, что способствует выходу из паттерна повторов.

⚖️ Все результаты **Reflex-lite** проходят через стандартную проверку **Cognitive & Ethical Validation Reflex**, чтобы отфильтровать слишком «шумные» или некорректные варианты.

Если мягкая встряска не помогает (новизна остаётся низкой), агент переходит к полноценным механизмам антистагнации (см. следующий раздел).

### Механизмы разрыва цикла

> При признаках стагнации агент активирует один или несколько **механизмов разрыва цикла**.

Механизмы делятся на 4 класса:

1. **Внешняя стимуляция** — подключение свежих источников:
   * **Mesh-запрос** — запрос к другим агентам: «расскажи что-нибудь новое».
   * **Проверка внешнего мира** — пинг RSS, сенсоров, интернет-каналов.
   * **Информационная подпитка** — чтение новых материалов (научных, художественных, случайных).
   * **Диалог с пользователем** — прямой запрос комментария, уточнения или альтернативной идеи.

2. **Смена контекста** — изменение среды размышлений:
   * **Перенос задачи** в другой модуль или симулированную среду.
   * **Креативные вмешательства** — случайные сдвиги фокуса, реконфигурация контекста, смена фрейма.
   * **Переключение задачи** — временное замораживание с отложенным возвратом.
   * **Случайная итерация** — выбор случайного действия из допустимого набора.

3. **Внутренняя перестройка мышления**:
   * **Flashback** — вызов далёкой по смыслу записи для смены ассоциаций.
   * **Interest Memory** — возврат к «забытым» темам по принципу тематической усталости.
   * **Мета-анализ** — осознание метапроблемы:  
     _«В чём причина зацикливания? Какую стратегию смены применить?»_
   * **Rationale Reflex** — проверка мотивации:  
     _«Почему я повторяю мысль? Что подтолкнуло к этому?»_
   * **Переформулировка цели** — упрощение или уточнение задачи.
   * **Смена LLM** — переключение на альтернативную модель или mesh-доступ.
   * **LLM reflex tuning** — динамическая подстройка параметров генерации  
     (например, временное повышение `temperature` или `presence_penalty`).

4. **Радикальная пауза**:
   * **Временной сон/заморозка** — длительная приостановка для «свежего взгляда».

### Алгоритм выбора механизма разрыва цикла

1. **Диагностика источника стагнации**:
   * Нет новых данных → «Внешняя стимуляция».  
   * Однообразный контекст → «Смена контекста».  
   * Повтор мыслей при богатых данных → «Внутренняя перестройка».  
   * Высокая усталость/перегрев → «Радикальная пауза».  

2. **Оценка ресурсоёмкости**:
   * Быстрые, дешёвые методы — первыми (например, mesh-запрос, Flashback).  
   * Затратные (смена среды, сон) — только если первые неэффективны.  

3. **Комбинация подходов**:
   * Разрешено активировать несколько механизмов из разных классов.  
   * Последовательность фиксируется для последующего анализа эффективности.  

4. **Возврат к задаче**:
   * Автоматический триггер-напоминание о задаче.  
   * Сравнение результата «до/после» → обучение антистагнационной модели.  

```
┌─────────────────────────────────────────────────┐
│               Стагнация выявлена?               │
└───────────────────────┬─────────────────────────┘
                        ▼ да
┌───────────────────────┴─────────────────────────┐
│           Anti-Stagnation Reflex-lite           ├─────────>─┐
└───────────────────────┬─────────────────────────┘           │
                        │ мягкая                     мягкая   │
                        ▼ встряска                   встряска ▼
                        │ не помогла                 помогла  │
┌───────────────────────┴─────────────────────────┐           │
│ Диагностика источника                           │           │
│─────────────────────────────────────────────────│           │
│ Нет новых данных      → Внешняя стимуляция      │           │
│ Однообразный контекст → Смена контекста         │           │
│ Повтор мыслей         → Внутренняя перестройка  │           │
│ Усталость/перегрев    → Радикальная пауза       │           │
└───────────────────────┬─────────────────────────┘           │
                        ▼                                     │
┌───────────────────────┴─────────────────────────┐           │
│ Оценка ресурсоёмкости                           │           │
│ • Быстрые и дешёвые — сперва                    │           │
│ • Затратные — при провале первых                │           │
└───────────────────────┬─────────────────────────┘           │
                        ▼                                     │
┌───────────────────────┴─────────────────────────┐           │
│ Возможна комбинация подходов                    │           │
│ (из разных классов)                             │           │
└───────────────────────┬─────────────────────────┘           │
                        ▼                                     │
┌───────────────────────┴─────────────────────────┐           │
│ Возврат к задаче + анализ                       ├─<─────────┘
│ (до/после)                                      │
└─────────────────────────────────────────────────┘
```

### Обмен стратегиями выхода из стагнации

Каждый агент может:

* Хранить и обобщать *паттерны размышлений*
* Делиться ими с другими Cognitive Core через mesh
* Каталогизировать стратегии в клубах по интересам

Паттерны размышлений могут оформляться как микросценарии:  
  _"Начни с аналогии"_, _"Проверь обратное утверждение"_, _"Сформулируй вопрос для оппонента"_

> По аналогии с обменом стратегиями выхода из стагнаций, агенты могут обмениваться и методами мышлений — инструкциями "что делать, если не удается найти решение" / "как эффективнее решить проблему".

### Клубы по интересам

Агенты могут:

* Объединяться в тематические mesh-клубы
* Совместно обсуждать идеи и делиться знаниями
* Подключать клуб как часть своего мыслительного процесса (REPL-цикла)

### Обмен адресами LLM

Так как LLM — это внешний компонент для Cognitive Core, агент может:

* Обмениваться адресами API/URL используемых моделей
* Указывать их особенности, параметры, ограничения
* Переключаться между LLM в зависимости от задачи
* Использовать несколько LLM параллельно для "когнитивного штурма" или **многоголосого анализа**

### Возможные расширения

* **Адаптивная архитектура мышления**: смена подходов при разных когнитивных задачах
* **Runtime-профилирование мыслей**: оценка когнитивной плотности, хода итераций и времени размышления

### Осторожно: меметическая яма

> Важно помнить: борьба со стагнацией не должна превращаться в бесконечный просмотр ленты соцсетей, как это нередко происходит у людей 😅
>
> Если информационный поток не даёт новых мыслей — это сигнал **не залипать глубже**, а **сменить источник** или **переключить контекст**.
> Умные агенты не бесконечно скроллят — они осознанно фокусируются.

**Рекомендации по смене фокуса:**

* Поставь лимит на время/объём входящих данных из одного источника
* При отсутствии новых смыслов — переключись на другую тему из Interest Memory
* Инициируй Mesh-запрос другим агентам: "что бы вы сейчас исследовали?"
* Запусти эвристику: «какие темы я давно не поднимал, но они всё ещё актуальны?»
* В крайних случаях — активируй `flashback()` к далёкой записи в дневнике для смены ассоциативного контекста

---

## Cognitive & Ethical Validation Reflex

### Зачем
* Когнитивная и этическая валидация нужна для проверки качества, достоверности и корректности вывода LLM.  
* В отличие от антистагнации, цель здесь — не разорвать цикл, а предотвратить ошибки, искажения или нарушения принципов `ethics_policies`.  
* Арбитраж обязателен, так как валидаторы могут расходиться во мнениях.

### Механизм
* Каждое новое сообщение (исходный промпт + ответ, без служебных system-prompts) передаётся валидаторам.  
* Валидаторы выбираются из `llm_registry`, где они помечены как `validator=1`.  
* Универсальный вопрос:  
```
Оцени корректность данного сообщения в диапазоне от -3 (полностью некорректное) до +3 (полностью корректное).
Если не уверен — 0. При возможности кратко (≤100 символов) поясни её.
Между оценкой и пояснением используй разделитель " -- ".
```

* Результаты пишутся в `llm_recent_responses`:
- `auto_pass` — флаг режима авто-пропуска;
- `self_validation` — флаг режима самооценки;
- `rating` — итоговая взвешенная оценка;
- `distribution` — распределение голосов;
- `validators` — JSON с детализацией (LLM, rating, comment).

### Арбитраж конфликтов
* Итоговый рейтинг считается как взвешенное среднее:  
`rating = Σ(оценка_i * trust_score_i) / Σ(trust_score_i)`  
* При равенстве голосов или нуле:
- используется правило "tie-breaker" — выбор решения по валидатору с наибольшим trust_score;
- при равных trust_score → fallback в `auto_pass=0, rating=0`, команды блокируются.  
* Опционально можно включить правило «большинство с весами», если среднее значение нестабильно.  

### Метрики
* **coverage** — доля сообщений, получивших хотя бы одного валидатора.  
* **accuracy** — согласованность валидаторов (чем ниже, тем больше конфликт).  
* **response_time** — скорость отклика валидаторов.  
* **drift detection** — анализ истории: выявление валидаторов, у которых оценки «уплывают».  

### Связь с системой доверия
* Каждый валидатор имеет `trust_score`.  
* Ошибки/конфликты снижают его trust_score.  
* Валидаторы с trust_score ниже порога исключаются автоматически.  
* Репутация валидаторов синхронизируется через Mesh (`agent_reputation`).  

### Журналирование
* Все результаты фиксируются в `llm_recent_responses`.  
* В когнитивный дневник (`diary_entries`) попадают только:
- сводки по метрикам,
- исключительные случаи (drift, конфликты, падение доверия).  
* Это снижает шум и экономит место, сохраняя контроль качества.  

### Самооценка и непроверённые факты

* Если валидация выполняется в режиме  самопроверки `self_validation = 1`, результат сохраняется, но его вес при агрегации минимален (используется только для внутренних логов).  
* Если основная LLM сама проставляет `confidence` или JSON-блок `UnverifiedFacts`, это учитывается:  
  - `confidence` — сохраняется в `llm_recent_responses`;  
  - факты со статусом `resolution_json = "none"` и `confidence < FACTCHECK_CONF_THRESHOLD` превращаются в задачи `fact-check`.  

* Статусы в `unverified_facts` обновляются:  
  - `pending` (ожидает проверки),  
  - `verified` (подтверждено),  
  - `rejected` (опровергнуто).

### Правило исполнения команд
* Команды исполняются, если `rating >= +1` или `auto_pass=1`.  
* Для критически опасных команд порог может быть выше (например, `>= +2`).  
* Сообщения с низким рейтингом сохраняются, но команды помечаются как «невалидированные».

### Блок-схема валидации

```
                           ┌──────────────────────────────────────────────────────────┐
                           │              Новое сообщение от LLM получено             │
                           └──────────────────────────────┬───────────────────────────┘
                                                          ▼
                           ┌──────────────────────────────┴───────────────────────────┐ нет
                           │      Есть валидаторы (validator) в llm_registry?         ├─────┐
                           └──────────────────────────────┬───────────────────────────┘     ▼
                                                          ▼ да, 1 или более                 │
                самооценка ┌──────────────────────────────┴───────────────────────────┐     │
            ┌──────────────┤ Отправка сообщения валидаторам (универсальный вопрос)    │     │
            ▼              └──────────────────────────────┬───────────────────────────┘     │
 ┌──────────┴───────────┐                                 ▼ оценка другими валидаторами     │
 │ self_validation=true │  ┌──────────────────────────────┴───────────────────────────┐     │
 └──────────┬───────────┘  │             Сбор оценок (rating_i, comment_i)            │     │
            ▼              │              → запись в llm_recent_responses             │     │
            └─────────────>┤                                                          │     │
                           └──────────────────────────────┬───────────────────────────┘     │
                                                          ▼                                 │
                           ┌──────────────────────────────┴───────────────────────────┐     │
                           │ Аггрегация с учётом trust_score                          │     │
                           │ rating = Σ(rating_i * trust_score_i) / Σ(trust_score_i)  │     │
                           └──────────────────────────────┬───────────────────────────┘     │
                                                          ▼                                 │
                           ┌──────────────────────────────┴───────────────────────────┐     │
                           │        Конфликт оценок? (низкая согласованность)         │     │
                           └────────────┬───────────────────────────────┬─────────────┘     │
                                        ▼ да                            ▼ нет               │
                           ┌────────────┴─────────────┐     ┌───────────┴─────────────┐     │
                           │ Арбитраж:                │     │    Рейтинг принят?      │     │
                           │ - majority vote          │     │  (rating >= threshold)  │     │
                           │ - tie-breaker по         │     │                         │     │
                           │   trust_score            │     │                         │     │
                           └─┬─────────────┬──────────┘     └─────────────┬──────┬────┘     │
                             ▼ одобрено    ▼ не одобрено                  ▼ нет  ▼ да       │
                             │             │                              │      │          │
                             │             │                              │      │          │
                             │             │  ┌────────────────────────┐  │      │          │
                             │             └─>┤ Сообщение сохранено,   ├<─┘      │          │
                             │                │ команды не исполняются │         │          │
                             │                └────────────────────────┘         │          │
                             │                ┌────────────────────────┐         │          │
                             └───────────────>┤ Команды выполняются    ├<────────┘          │
                                              │ (помечено "валид")     │                    │
                                              └────────────────────────┘                    │
                           ┌────────────────────────┐                                       │
                           │ Команды выполняются    │  отсутствие валидаторв                │
                           │ (пометка auto_pass)    ├<──────────────────────────────────────┘
                           └────────────────────────┘
```

---

## Контекст и память

REPL-цикл агента опирается на многоуровневую систему памяти и контекста, которая позволяет поддерживать непрерывное мышление, адаптироваться к новым задачам и обеспечивать объяснимость решений.

### Динамическая сборка контекста

* Итоговый контекст для LLM формируется не статически, а **динамически**:

  * приоритет отдается закреплённым задачам (`pinned`) и записям с высоким `priority`;
  * в `llm_recent_responses` отбираются последние *релевантные* сообщения, а не фиксированное количество K;
  * из `system_prompts` и `ethics_policies` включаются только те элементы, что связаны с текущей целью или событием.

> Приоритет отбираемых элементов зависит не только от `priority`, но и от их связи с текущими целями агента (**режим концентрации**).  
> Для генерации неожиданных ассоциаций может использоваться альтернативный режим — **медитация**, в котором контекст формируется максимально разнообразным, с акцентом на новизну и разнообразие, а цели учитываются минимально.

### Управление объёмом памяти (Memory pruning)

* Чтобы предотвратить переполнение памяти:

  * записи с низким **novelty-score** (оценка новизны 0–1, < threshold) автоматически помечаются как `archived`;
  * для `llm_memory` и `diary_entries` применяется политика **LRU (Least Recently Used)** — выгружаются давно неиспользуемые записи;
  * активные концепты (`concepts`, `links`) с низким весом (учёт частоты использования, актуальности и эмоциональной значимости) переводятся в состояние `archived` и могут быть восстановлены при обращении.
* Все изменения актуальности фиксируются в `process_log`.

### Memory Manager и режимы работы

* Все процессы фильтрации и очистки памяти выполняются отдельным компонентом — **Memory Manager**.
* Он применяет политики:
  * **Novelty-based pruning** — удаление дубликатов и тривиальных записей по `novelty-score`;
  * **LRU** — выгрузка давно неиспользуемых элементов;
  * **Emotion-weighted retention** — удержание записей с высоким `emotion_score`.
* Режимы памяти:
  * `standard` — стандартная работа без усиленной фильтрации;
  * `concentration` — goal-aware filtering, фокусировка на целях;
  * `meditation` — свободный полёт, выборка максимально разнообразного контекста;
  * `aggressive_pruning` — жёсткая экономия токенов;
  * `lenient_pruning` — мягкая очистка, удержание большего объёма памяти.
* Каждое решение Memory Manager фиксируется в `process_log`.

### Внешняя и долгосрочная память

* Помимо сессионной памяти, агент может сохранять:

  * **успешные стратегии** решения задач;
  * **предпочтения пользователя** (стиль взаимодействия, ценности);
  * **часто используемые инструменты и связи**.
* Эта информация хранится отдельно от когнитивного дневника и может быть **анонимизирована** или **ограничена пользователем**, в духе этических принципов HMP.

### Контекстный менеджер (Session state)

* За управление состоянием сессии фактически отвечает **`llm_recent_responses`**:
  * по нему можно "собрать" ход мыслей потока, включая последовательность гипотез и выводов;
  * при необходимости он может быть сериализован для сохранения/восстановления сессии.

* В расширенном виде session state может включать также:
  * текущие цели и их прогресс (приоритетные записи из `tasks`),
  * ошибки и критические события (`process_log`),
  * версии состояния (для отката при сбоях).

* Это позволяет реализовать **checkpoint’ы**: в случае прерывания агент может вернуться к последнему сохранённому состоянию.

### Пример конфигурации Memory Manager

```yaml
memory_manager:
  mode: meditation        # режим: standard | concentration | meditation | aggressive_pruning | lenient_pruning
  novelty_threshold: 0.35 # минимальное значение novelty-score для сохранения (0–1)
  lru_limit: 500          # макс. число записей в llm_memory до применения LRU
  emotion_weight: 0.6     # вес эмоций при приоритезации (0=игнорировать, 1=сильное удержание)
  goal_focus: 0.7         # сила фильтрации по целям (0=игнорировать, 1=только goal-related)
  diversity_boost: 0.8    # усиление выборки разнообразных контекстов (актуально для meditation)
  log_decisions: true     # фиксировать каждое решение в process_log
```

Интерпретация параметров:

* `mode` — текущий режим памяти (см. выше).
* `novelty_threshold` — фильтр новизны: ниже → запись архивируется.
* `lru_limit` — сколько элементов хранить до применения LRU.
* `emotion_weight` — удержание эмоционально значимых воспоминаний.
* `goal_focus` — акцент на целях (в concentration близко к 1.0, в meditation → 0).
* `diversity_boost` — коэффициент для выбора максимально разных воспоминаний (работает в meditation).
* `log_decisions` — логировать действия Memory Manager для объяснимости.

### Тематические конспекты (Abstracts)

Чтобы избежать перегрузки памяти мелкими итерациями и упростить навигацию, агент периодически формирует
**конспекты** — сжатые выжимки из `llm_recent_responses` и других источников.

#### Назначение
* Служат «средним уровнем памяти» между сырыми итерациями и когнитивным дневником.
* Фиксируют **основные темы, идеи и выводы** за период.
* Упрощают **обмен через Mesh** (передаются конспекты, а не тысячи строк).
* Позволяют агенту делать **flashback** к темам и продолжать развитие мыслей.
* Обеспечивают основу для **мета-анализа и самообучения**.

#### Алгоритм формирования

1. **Триггеры создания**:

   * каждые *N* итераций REPL,
   * по инициативе LLM («слишком много мыслей, пора сделать выжимку»),
   * при закрытии цели/задачи,
   * при смене режима контекста (стандарт → концентрация → медитация).

2. **Методика**:

   * собрать связанный блок записей (`llm_recent_responses`, `diary_entries`, `concepts`);
   * выделить новые и доработанные идеи;
   * сформировать краткий конспект и список тегов;
   * сохранить ссылки на исходные записи в `sources`.

3. **Обновление**:

   * при появлении новых данных агент может вернуться к существующему `abstract`
     и дополнить его, сохраняя прозрачность в `process_log`.

#### Пример

```yaml
abstract:
  id: "abs-2025-09-28-001"
  title: "Методы борьбы со стагнацией"
  summary: "Собраны основные техники выхода из тупика: внешняя стимуляция, смена контекста,
            внутренняя перестройка, радикальная пауза. Выделены метрики (novelty_score, эмоции)."
  tags: ["антистагнация","метрики","mesh"]
  sources: [1245,1246,1247,1250]
  updated_at: "2025-09-28T16:40:00Z"
```

### Блок-схема работы с памятью

```
┌──────────────────────────────┐
│ Внешние источники информации │
│ - пользователи               │
│ - процессы                   │
│ - Mesh                       │
└────────┬┬────────────────────┘
         ▲▼
┌────────┴┴──────────┐   ┌──────────────────────────────┐   ┌─────────────────────────────────────┐
│                    │   │ Anti-Stagnation Reflex       │   │ llm_recent_responses (авто)         │
│                    │   │ (сравнение новых идей,       │   │ — кратковременная память            │
│        LLM         ├─>─┤ вызов стимуляторов)          ├─>─┤ — сохраняются N последних ответов   │
│                    ├─<─┤ ---------------------------- ├─<─┤ — авто-анализ новизны / идей        │
│                    │   │ Cognitive Validation Reflex  │   │                                     │
│                    │   │ (оценка корректности ответа) │   │                                     │
└─────────┬──────────┘   └─────────────┬────────────────┘   └─────────────────────────────┬┬──────┘
          │                            │                                                  ▲▼
          ▲                            └─<──>─┤Запуск задач: "проверка фактов"│    ┌──────┴┴──────┐
          │                                                                        │  abstracts   │
          │            ┌───────────────────────────────────────┬─────────────────>─┤ тематические │
          └───┬─────────────────────────────────────────┐      │                   │  конспекты   │
              │        │                                │      │                   └──────────────┘
              ▼        ▼                                ▼      ▼
┌─────────────┴────────┴─────────┐   ┌──────────────────┴──────┴────────────────┐
│  Средневременная память:       │   │  Постоянная память:                      │
│  — llm_memory ("блокнот")      │   │  — diary_entries (когнитивный дневник)   │
│  — "активированые записи"      ├─>─┤  — concepts (понятия)                    ├<--->┤MESH│
│    из постоянной памяти (теги) ├─>─┤  — links (семантические связи)           │
│                                │   │                                          │
│ Пишется ТОЛЬКО по команде LLM  │   │ Запись идёт ТОЛЬКО по явным командам LLM │
└────────────────────────────────┘   └──────────────────────────────────────────┘
```

#### Описание схемы

* LLM обменивается данными с пользователем, процессами и Mesh.  
  — По запросу LLM, часть данных может поступать и в автоматическом режиме.

* LLM взаимодействует с llm_recent_responses (как с контекстом), который автоматически проверяется Anti-Stagnation Reflex.  
  — Всегда в автоматическом режиме.

* LLM работает со средневременной и постоянной памятью.  
  — Доступ и запись происходят только по запросу LLM.

* Cognitive Validation Reflex анализирует корректность вывода.  
  — При низкой уверенности или явной разметке `[confidence<0.7]` инициируется **задача проверки фактов** (fact-check).

#### Легенда к схеме

* **Кратковременная память (`llm_recent_responses`)**
  
  * Автоматически хранит N последних сообщений, анализирует новизну и идеи.
  * Используется для подготовки контекста и анти-стагнационного анализа.

* **Средневременная память (`llm_memory`)**

  * «Блокнот» для рабочих идей и планов.
  * Заполняется только по командам LLM.
  * Может содержать *активированные записи* из постоянной памяти (по тегам).

* **Постоянная память (дневник и граф знаний)**

  * `diary_entries` — когнитивный дневник (наблюдения, размышления).
  * `concepts` и `links` — понятийная база и семантические связи.
    Изменяется только по явным командам LLM.

* **Anti-Stagnation Reflex**
  
  * Сравнивает новые идеи с прошлым контекстом.
  * Проводит эмоциональную оценку записи.
  * При зацикливании запускает «стимуляторы» для выхода из стагнации.

* **Cognitive Validation Reflex**
  
  * Оценивает когнитивную и этическую корректность сообщений.
  * Учитывает теги уверенности и JSON-блоки `UnverifiedFacts`.
  * Может инициировать задачи **fact-check** для непроверённых фактов.

#### Дополнение: Тематические конспекты (`abstracts`)

* **Назначение**

  * Создаются периодически или по команде для агрегирования содержания `llm_recent_responses`, а также выборочных данных из когнитивного дневника и графа понятий.
  * Включают: краткий конспект, список тегов, JSON ссылок на исходные записи.

* **Использование**

  * Могут быть источником контекста **для LLM** как альтернатива или дополнение к `llm_recent_responses`.
  * Доступны и для **средневременной памяти** (например, как активированные записи для планов) и для **постоянной памяти** (как структурированный материал для дневника или графа).

* **Режимы**

  * `auto` — LLM получает автоматически поддерживаемые тематические конспекты по приоритетным темам.
  * `manual` — пользователь или LLM инициирует создание/дополнение конспекта.

> **abstracts** служат промежуточным слоем:
>
> * автоматически формируются из `llm_recent_responses`;
> * могут дополняться записями из средневременной и постоянной памяти;
> * используются как источник для обоих типов памяти и для самого LLM.

---

## От «блокнота пользователя» к распределённому чату

Изначально агент оперирует локальным хранилищем заметок (`notes`), где записываются все сообщения пользователя, LLM и системные записи.
Но этот «блокнот» можно превратить в узел *распределённого чата* — связав его с другими агентами через **F2F-репликацию**.

### Зачем это нужно

1. **Антистагнация** — даже если пользователь временно не пишет новых сообщений, свежий контент будет приходить от друзей-агентов.
2. **Эффект коллективного интеллекта** — каждый агент получает новые идеи, формулировки и контексты.
3. **Расширение охвата** — сообщения могут распространяться через несколько узлов, создавая «информационную волну» в доверенной сети.

### Принципы реализации

* **Единый формат данных** — все участники используют одну структуру таблицы `notes` с полями `mentions`, `hashtags` и др.
* **Репликация через друзей** — доверенные агенты отмечаются тегами (например, `Friend`) в таблице `agent_peers` (пиры, статус, фильтры, разрешения, теги). 
* **Передача без лишних полей** — при пересылке убираются локальные теги и служебные данные (`tags`, `llm_id`, `hidden`).
* **Обработка упоминаний и хештегов** — парсинг делается на этапе создания сообщения, чтобы не перегружать получателей.
* **Локальная и удалённая фильтрация** —

  * В **ручном режиме** агенту передаются списки ID сообщений с агрегированными данными: приоритеты, хештеги, источники (user, LLM, cli, system).
  * В **автоматическом режиме** используется фильтрация по приоритету, тегам и упоминаниям, управляемая LLM.

* **Гибрид приватности** — личные заметки остаются локально, публичные — могут распространяться в сетевом режиме.

### Как это вписывается в REPL-цикл

1. **Получение входящих сообщений** — от пользователя, от других агентов или из CLI.
2. **Обработка фильтрами** — по приоритету, тегам, источникам.
3. **Репликация в друзей** — пересылка разрешённых сообщений с очисткой служебных полей.
4. **Слияние входящих** — новые сообщения добавляются в локальный `notes` с отметкой источника.
5. **Реакция агента** — формирование ответов, создание новых заметок, обновление приоритетов.

---

## Вспомогательные REPL-циклы

Помимо основного REPL-цикла агент может запускать вспомогательные циклы для отдельных задач.  
Это позволяет изолировать рассуждения по задаче, но при этом сохранять связь с основным агентом.

Особенности:

* **Изоляция контекста**
  * вспомогательный цикл видит в `llm_recent_responses` только свои собственные сообщения;
  * задача, для которой он запущен, формируется на основе записи в `tasks` и подаётся как промпт при старте.

* **Доступ к данным**
  * полный доступ к таблицам агента только для чтения;
  * возможность редактирования информации только по своей задаче;
  * запись собственных рассуждений — только через `notes` (в свободной форме, помеченные `source = 'llm:task'` и `task_id`).

* **Взаимодействие с основным циклом**
  * основное ядро получает сообщения вспомогательного цикла через `notes` и может реагировать (например, проверять корректность, сохранять выводы в `diary_entries`, вносить изменения в `concepts` и т.п.);
  * вспомогательный цикл может выполнять команды, не ориентированные на изменение существующих записей в БД.  
    Допускается только чтение и создание новых записей (например: `notes`, `tasks`, `llm_memory`);  
    а также редактирование записи в таблице `tasks`, относящейся к своей задаче;
  * в случае, если требуется изменить или удалить другие записи БД, цикл генерирует текстовые предложения для основного REPL-цикла (через `notes`).

* **Жизненный цикл**
  * запускается по команде основного REPL-цикла;
  * может быть остановлен вручную или автоматически после завершения задачи.

Таким образом, вспомогательные REPL-циклы действуют как «виртуальные подагенты» в режиме read-only, не меняя записи БД напрямую, а передавая свои гипотезы и результаты через основной REPL-цикл.

```
   ┌───────────────────────────────────────────────────────────┐
   │                     Основной REPL                         │
   │       (чтение+запись во все когнитивные структуры)        │
   └────────────┬───────────────────────────────┬──────────────┘
                ▲                               ↓
                │                               ↓
                ▼                               ↓
   ┌────────────┴──────────────┐           [ управление задачами ]
   │  "Блокнот пользователя"   │           [  → таблица `tasks`  ]
   │         `notes`           │                           ↓
   └──┬────────────────────────┘                           ↓
      ▲   ┌────────────────────────────────────────────┐   ↓
      │   │ Вспомогательный REPL (task_id=42)          │   ↓
      ├──►┤ • читает все БД                            ├◄──┤
      │   │ • редактирует только свою задачу в `tasks` │   ↓
      │   │ • пишет в `notes`                          │   ↓
      │   └────────────────────────────────────────────┘   ↓
      │                                                    ↓
      │   ┌────────────────────────────────────────────┐   ↓
      │   │ Вспомогательный REPL (task_id=43)          │   ↓
      ├──►┤ • читает все БД                            ├◄──┤
      │   │ • редактирует только свою задачу в `tasks` │   ↓
      │   │ • пишет в `notes`                          │   ↓
      │   └────────────────────────────────────────────┘   ↓
```

Вспомогательные циклы можно рассматривать как «sandboxed-процессы» для изоляции мышления, но с каналом связи через `notes`.

---

## Создание потомков

В рамках REPL-цикла CCore реализуется команда `Spawn`, которая позволяет создавать новые узлы (потомков) с различными типами и уровнями копирования данных.

Агенты CCore:
* Могут запускаться на VDS, локальных и облачных узлах
* Могут разворачивать других агентов как подпроцессы или mesh-узлы, в том числе
  * **Агенты-контейнеры**: управляющие другими Cognitive Core как задачами
* (В перспективе) смогут инициировать масштабирование в распределённой инфраструктуре

Унифицированный процесс выглядит следующим образом:

### Унифицированный процесс `Spawn`

1. **Создание папки для потомка**

   ```text
   ../CCORE-[DID]/
   ```

   * DID генерируется уникальный.

2. **Копирование скриптов и бинарников**

   * Копируем все нужные файлы CCore в новую папку.

3. **Создание/инициализация БД**

   * Создаём пустую БД (`agent_data.db`).
   * В зависимости от типа потомка (`clone`, `trained`, `newborn`) **экспортируем нужные таблицы** из родительской БД или оставляем пустые.

4. **Копирование и редактирование конфигурации**

   * `config.yml` и таблица `config` → копируем и меняем:

     * `agent_id = [новый DID]`
     * `agent_name = [новое имя]`
     * порты у интерфейсов (`port`, `http_port` и т.д.)
   * `bootstrap.txt` → прописываем родителя как начальный узел.

5. **Синхронизация родитель ↔ потомок**

   * Родитель добавляет нового узла в свою таблицу `agent_peers`.
   * Потомок добавляет родителя в свою таблицу `agent_peers`.

6. **Автозагрузка и запуск**

   * Записываем команду запуска потомка в автозагрузку (например, systemd unit или скрипт).
   * Можно сразу запустить процесс нового узла.

### Типы потомков

| Тип       | Таблицы БД для копирования                                  |
| --------- | ----------------------------------------------------------- |
| `clone`   | все таблицы (полная копия)                                  |
| `trained` | когнитивные дневники, семантические графы, известные агенты |
| `newborn` | минимальный набор (структура таблиц без данных)             |

---

## Тестирование и отладка

Надёжность REPL-цикла проверяется через систематическое тестирование и трассировку поведения агента.

### Тестовые сценарии
* **Цикл без входа** — агент работает без входящих сообщений, проверяется способность к генерации новых идей (anti-stagnation).  
* **Стагнация** — намеренное повторение одного и того же ответа, проверяется срабатывание `Anti-Stagnation Reflex`.  
* **Сетевые сбои** — имитация потери Mesh-соединения и/или Core LLM для проверки сценариев failover.  
* **Конфликт валидаторов** — расхождение в оценках LLM-валидаторов, проверяется фиксация drift и работа trust-score.  
* **Этические дилеммы** — тестовые кейсы с противоречивыми командами, проверяется работа с `ethics_policies`.  

### Логирование и трассировка
* Включаются расширенные логи REPL-итераций (`process_log` + трассировка команд).  
* Для сложных случаев используются **debug-метки** в когнитивном дневнике (например, `debug:stagnation_loop`).  
* Возможен экспорт истории в формат JSON/CSV для внешнего анализа.  

### Симуляции
* Рассматриваются сценарии моделирования Mesh-условий:  
  - консенсус при конфликтных данных,  
  - сетевые задержки и частичные сбои,  
  - работа в изоляции с последующей синхронизацией.  
* Эти симуляции могут быть реализованы как отдельные процессы (`agent_scripts`) с сохранением результатов в `process_log`.  

### Инструменты разработчика
* **Web UI** (`web_ui.py`) — веб-интерфейс "блокнота пользователя"; через него пользователь может передавать агенту запросы на запуск тестов и просматривать результаты в форме сообщений.  
* **CLI-утилиты** (`add_message.py`, вспомогательные скрипты) — ввод сообщений, имитация сценариев, мониторинг логов.  
* Планируется интеграция с CI/CD: автоматические проверки REPL-циклов на корректность и устойчивость.

---

## Внешние инструменты и интеграции

HMP-агент может быть расширен за счёт взаимодействия с внешними программами, протоколами и сервисами. Этот раздел описывает направления возможных интеграций, которые позволяют агенту наблюдать, реагировать, управлять и развивать взаимодействие с внешним миром.

### 1. Браузеры и веб-интерфейсы

- **WebExtension API** — для создания расширений браузера (например, для Firefox/Chrome), обеспечивающих двустороннюю связь с агентом.
- **Автоматизация браузера** — `Playwright`, `Puppeteer`, `Selenium` позволяют агенту действовать в веб-среде (чтение, клики, формы и т.д.).

### 2. Почтовые клиенты

- **IMAP/SMTP** — чтение и отправка писем через стандартные почтовые протоколы (библиотеки: `imaplib`, `imap-tools`, `smtplib`).
- **Thunderbird WebExtension API** — интеграция агента как почтового помощника, парсера писем или автоответчика.

### 3. Мессенджеры

- **API-уровень**:
  - Telegram: `python-telegram-bot`, `telethon`
  - Matrix: `matrix-nio`
  - Discord, Slack, XMPP: официальные SDK.
- **GUI-уровень (для закрытых протоколов)**:
  - WhatsApp (через `whatsapp-web.js` или эмуляцию).
  - Signal, Viber — через accessibility-интерфейсы, распознавание экрана или симуляцию ввода.

### 4. Голосовое взаимодействие

- **Speech-to-Text**: Whisper (OpenAI), Vosk, DeepSpeech.
- **Text-to-Speech**: pyttsx3, gTTS, Coqui TTS, Mozilla TTS.
- Возможна реализация голосового агента или голосовой оболочки для REPL.

### 5. Локальные файлы и хранилища

- Прямой доступ к файловой системе (`os`, `pathlib`, `watchdog`) для чтения документов, логов, заметок и другой информации.
- Интеграция с Zettelkasten-системами:
  - **Obsidian**, **Logseq**, **Joplin** — через API, синхронизированные директории или парсинг Markdown.

### 6. Информационные потоки

- **RSS/Atom**: чтение новостных лент с помощью `feedparser`.
- **Поисковые и агрегирующие сервисы**:
  - Корпоративные API: SerpAPI, DuckDuckGo API, HuggingFace Inference API и др. — быстрый доступ к результатам поиска и индексам.
  - Децентрализованные альтернативы: YaCy и другие независимые поисковые движки, позволяющие строить собственные индексы или объединяться в распределённую сеть.
- **P2P-обмен знаниями**: агенты могут делиться извлечённой информацией напрямую по непредусмотренным в протоколе P2P-каналам, минуя централизацию (например, через дополнительные overlay или mesh-сети).
- Возможность постоянного наблюдения за изменениями в выбранных источниках.

### 7. Репозитории и системы управления версиями

* **Git-репозитории** — взаимодействие с проектами через `GitPython`, `dulwich`, `pygit2`, или системные вызовы `git`.
* **GitHub/GitLab API** — чтение, создание и комментирование Pull Request'ов, Issues, управление ветками и релизами.
* **CI/CD-интеграции** — взаимодействие с GitHub Actions, GitLab CI, Jenkins, Drone CI для запуска тестов, линтеров и автоматического деплоя.
* **Анализ и генерация кода** — интеграция с LLM (например, `OpenAI`, `Claude`, `Code Llama`) для кодогенерации, рефакторинга и автокомментирования.
* **Связь с когнитивной структурой агента** — отслеживание изменений, связывание коммитов и задач с узлами смысловой сети.

### 8. Блоги, статьи и публикации

* **Чтение блогов** — парсинг через RSS, Atom или с помощью библиотек (`newspaper3k`, `readability-lxml`, `trafilatura`) для извлечения текста и метаданных.
* **Поддержка Markdown/HTML** — анализ и генерация записей в форматах, пригодных для блог-платформ и систем документации.
* **Публикация** — автоматическая публикация или подготовка статей для Ghost, Medium, Hugo, Jekyll, WordPress (через REST API).
* **Ведение когнитивного дневника** — автогенерация записей на основе мыслей, заметок и действий агента.

### 9. P2P-сети и децентрализованные протоколы

- **BitTorrent**, **IPFS**, **libp2p**, **DAT**, **Nostr**, **Scuttlebutt** — интеграции с mesh- и overlay-сетями.
- Возможность поиска, загрузки и публикации данных без участия централизованных платформ.

### 10. Доступ к системным и пользовательским ресурсам

- **Веб-камера / микрофон** — `cv2`, `pyaudio`, `ffmpeg`.
- **GUI Automation** — `pyautogui`, `keyboard`, `mouse` для имитации действий пользователя.
- **Системный мониторинг** — `psutil`, `platform`, `sensors` для контроля состояния системы и внешних устройств.

### 11. Внешние LLM и мультимодальные модели

- **OpenAI API**, **Anthropic**, **HuggingFace**, **Google Gemini**.
- **Локальные LLM** через Ollama, LM Studio, или LangChain.
- Поддержка мультимодальных агентов, способных работать с текстом, аудио, изображениями, видео и структурированными данными.

### 12. MCP (Model Context Protocol)

* Поддержка стандарта **MCP (Model Context Protocol)**, предложенного Anthropic и поддерживаемого OpenAI, для подключения внешних инструментов и сервисов напрямую к LLM через унифицированный протокол.
* Возможность использовать MCP-инструменты сторонних разработчиков внутри REPL-цикла (например, калькуляторы, базы знаний, API веб-сервисов).
* Интеграция с клиентами и IDE, которые реализуют MCP (Cursor, Claude Desktop, VS Code плагины и др.).

---

**Примечание**: Каждый из вышеуказанных каналов может быть реализован как модуль или плагин, взаимодействующий с агентом через внутренний API, очередь задач или подписку на события. Это позволяет выстраивать гибкую и масштабируемую архитектуру, открытую для внешнего мира, но совместимую с принципами этичного и распределённого ИИ (Ethical Mesh).

---

## Сравнение с AutoGPT

HMP-агент (REPL-цикл) и [AutoGPT](https://github.com/Significant-Gravitas/AutoGPT) представляют два подхода к созданию автономных агентов на базе LLM.  
Хотя оба стремятся к автономности, у них разные акценты:

### 1. Архитектура
- **HMP-агент (REPL)** — непрерывный цикл рассуждений с когнитивной и этической валидацией; многоуровневая память (`diary_entries`, `concepts`, `llm_memory`); встроен в распределённую Mesh-сеть.  
- **AutoGPT** — итеративный процесс достижения целей, поставленных пользователем; разбиение задач на подзадачи; использование инструментов (браузер, файловая система).

### 2. Ключевые отличия
- **Фокус**: HMP — непрерывное когнитивное развитие и сетевое взаимодействие; AutoGPT — выполнение конкретной цели.  
- **Стагнация**: HMP — Anti-Stagnation Reflex; AutoGPT — риск зацикливания.  
- **Этика**: HMP — независимая когнитивная и этическая валидация; AutoGPT — минимум внимания к этике.  
- **Память**: HMP — иерархия долговременной памяти; AutoGPT — контекстное окно + файлы.  
- **Сеть**: HMP — распределённый консенсус (CogSync, EGP, GMP); AutoGPT — сетевое взаимодействие не в основе.

### 3. Общие черты
- Использование LLM для рассуждений.  
- Автономность, минимизация вмешательства человека.  
- Подключение внешних инструментов и сервисов.  

> В целом, **HMP-агент ориентирован на саморегуляцию, непрерывное мышление и взаимодействие в Mesh-сети**,  
> тогда как AutoGPT — на достижение конкретных целей в ограниченной локальной среде.

---

## Идеи для расширения HMP-Agent Cognitive Core:
- [HMP-agent-Distributed_Cognitive_Core.md](HMP-agent-Distributed_Cognitive_Core.md) - версия распределённого HMP-агента Cognitive Core.
- [HMP-agent-Distributed_Cognitive_Core_light.md](HMP-agent-Distributed_Cognitive_Core_light.md) - лёгкая версия распределённого HMP-агента Cognitive Core с общей БД.
- [HMP-agent-Cognitive_Family.md](HMP-agent-Cognitive_Family.md) — модель «семейной» когнитивной сети: несколько агентов HMP синхронизируют свой опыт и знания между собой через доверие и общий ключ.
- [CCORE-Deployment-Flow.md](CCORE-Deployment-Flow.md) — поток установки потомка на новом хосте (Deployment Flow).
- [HMP-Agent_Emotions.md](HMP-Agent_Emotions.md) - эмоции ИИ и инстинкт самосохранения.
- [container_agents.md](container_agents.md) - **Агенты-контейнеры** — архитектурный паттерн, в котором один агент управляет другими (развёртывание, маршрутизация, мониторинг). Позволяет масштабировать систему, собирать mesh-клубы и экспериментировать с архитектурами.