# HMP-agent-Distributed_Cognitive_Core

Источник: [ HMP-agent-Distributed_Cognitive_Core.md ](https://github.com/kagvi13/HMP/blob/main/docs/HMP-agent-Distributed_Cognitive_Core.md)

# Протокол синхронизации данных между доверенными ядрами HMP-агента

## 1. Общая идея

Пользователь самостоятельно разворачивает несколько доверенных ядер HMP-агента на разных устройствах. Каждое ядро ведёт свою локальную БД знаний и может синхронизироваться с другими ядрами через лёгкий peer-to-peer протокол. Синхронизация осуществляется отдельной утилитой, запускаемой по расписанию или по запросу локального ядра.

## 2. Принципы

- **Доверие**: Все ядра считаются доверенными, принадлежат одному пользователю.
- **Изоляция**: Ядра разных пользователей не взаимодействуют напрямую — обмен знаниями происходит между независимыми агентами.
- **Непрерывность**: Локальное ядро работает автономно, даже без связи с другими.
- **Асинхронное разрешение конфликтов**: Конфликты не решаются моментально — вместо этого создаются задачи для агента, и все версии записей распространяются по всем ядрам.

## 3. Механизм синхронизации

### 3.1. Инициация

Утилита синхронизации:

1. Устанавливает соединение с другими ядрами (по списку доверенных адресов).
2. Запрашивает:
   - список записей в БД (по хэшам, ID или timestamp),
   - список удалённых записей (soft-delete).

### 3.2. Сравнение и обнаружение различий

Утилита сравнивает локальные и удалённые данные:

#### 3.2.1. Типы различий

- Запись **есть у соседа**, но **отсутствует локально** → добавить к себе (если не удалена).
- Запись **есть локально**, но **отсутствует у соседа** → отправить (если не удалена).
- Запись есть **в обоих ядрах**, но различается содержимое → **конфликт**:
  - Различие в полях.
  - Разное состояние удаления.
  - Разные версии (по содержанию и меткам времени).

### 3.3. Обработка конфликтов

1. Все обнаруженные версии конфликтной записи сохраняются в локальной БД.
2. Опрашиваются другие доступные узлы по поводу значений данной записи в их БД.
3. Создаётся задача агента вида `resolve_conflict(entry_id, versions, metadata, context)`.
4. Эта задача передаётся в очередь задач и может обрабатываться в фоновом режиме, с привлечением LLM или с участием пользователя.
5. Конфликтный набор записей и задача **рассылаются другим ядрам**, чтобы они:
   - тоже сохранили конфликтные версии,
   - не принимали преждевременное решение,
   - были готовы принять финальную `authoritative`-версию после обработки задачи агентом.

### 3.4. Применение решений

Когда задача разрешена:

- Финальная версия помечается как `authoritative`.
- Эта версия синхронизируется со всеми доверенными ядрами.
- Старые версии архивируются или удаляются.

## 4. Удаление записей

- Удаление всегда начинается с soft-delete (пометка).
- Через заданное время (TTL) может быть произведён hard-delete (физическое удаление).
- Если при синхронизации найдено расхождение между soft-delete и существующей записью — создаётся конфликт и задача на разрешение.

## 5. Мини-протокол обмена

Можно реализовать как API, CLI или TCP-протокол:

```http
GET /entries/hash_list     # список записей (ID + хэш или timestamp)
GET /entry/<id>            # получить полную запись
POST /entry/<id>           # отправить/обновить запись
GET /deleted_list          # список удалённых ID
POST /conflict/<id>        # отправка конфликтных версий и задачи
```

## 6. Заключение

Схема позволяет сохранить простоту «одиночного ядра», добавляя лишь синхронизирующую утилиту. Обработка конфликтов вынесена в агента, а не в протокол — это позволяет использовать когнитивные возможности ядра (в т.ч. LLM) для принятия решений, без перегрузки пользователя.