| ### 💡 **Лёгкая версия HMP-агента с общей БД** | |
| #### 📘 Общая концепция | |
| * Все ядра работают с одной локальной базой данных (например, SQLite или PostgreSQL). | |
| * При недоступности БД ядро "спит" (в режиме ожидания). | |
| * Основная задача такой архитектуры — упрощённая параллельная работа HMP-ядер (например, несколько REPL-агентов на одной машине или кластере). | |
| --- | |
| ### 📍 Потенциальные проблемы и решения | |
| #### 🔁 1. Коллизии при одновременной записи | |
| **Проблема:** два ядра могут одновременно читать-записывать одну и ту же запись, не зная о действиях друг друга. | |
| **Решения:** | |
| * Использование транзакций и `SELECT ... FOR UPDATE`. | |
| * Ведение версии записи (`version`, `updated_at`) для обнаружения изменений между чтением и записью. | |
| * Конфликт может быть автоматически переведён в статус "нужна доработка" — и отправлен агенту. | |
| #### 🧠 2. Смысловые конфликты (двойники) | |
| **Проблема:** два ядра могут независимо создать записи с похожим смыслом, не зная о друг друге. | |
| **Решения:** | |
| * Ввести периодическую задачу **"смысловой дедупликации"**, которая запускается одним из агентов (или планировщиком). | |
| * Агент анализирует семантическую близость новых записей к уже существующим и предлагает объединение или уточнение. | |
| * Возможность помечать записи как `дубль`, `связано_с`, `вариант`. | |
| --- | |
| ### 🔗 Потенциальное расширение | |
| Эта архитектура может служить промежуточной ступенью: | |
| * В будущем к ней можно подключить модуль синхронизации между узлами (и трансформировать в полноценную распределённую сеть). | |
| * Конфликтный модуль и задачи для агента уже сейчас можно реализовать аналогично полной версии. | |
| --- | |
| ### 💬 Поддержка задач | |
| Можно ввести таблицу `tasks`, куда ядра будут ставить задания: | |
| * `resolve_conflict` | |
| * `deduplicate` | |
| * `compress_semantic_cluster` | |
| * `verify_coherence` | |
| И агенты будут выполнять эти задания асинхронно. | |