план: архитектура агентов + память

AGENT-PLAN.md

@@ -0,0 +1,61 @@
+# AGENT-PLAN.md — План работ: Агенты + Трекер
+
+## Фаза 1: Конфиг агента (agent.json → минимум)
+
+### 1.1 Разделение конфигов
+- [ ] **agent.json** — только подключение: `token`, `tracker_url`
+- [ ] **config.json** — внутренняя конфигурация LLM: `api_key`, `model`, `provider`, `prompt` (override)
+- [ ] Picogent `resolveConfig()` — читает оба файла, мержит
+- [ ] Убрать дублирующиеся поля (name, slug, capabilities) из agent.json
+
+### 1.2 Трекер: расширить auth_ok
+- [ ] WS `auth_ok` возвращает полный AgentConfig: name, slug, capabilities, model, prompt, chat_listen, task_listen, max_concurrent_tasks
+- [ ] Picogent мержит remote config с локальными override-ами (config.json приоритетнее)
+
+### 1.3 Горячее обновление конфига
+- [ ] Новый WS event `config_updated` — трекер → агент при изменении через UI
+- [ ] Picogent обрабатывает event, обновляет runtime config без рестарта
+
+### 1.4 Systemd template для мульти-агент
+- [ ] `picogent@.service` — шаблонный unit: `ExecStart=node ... /opt/agents/%i/`
+- [ ] `systemctl start picogent@coder`, `systemctl start picogent@reviewer`
+
+---
+
+## Фаза 2: Память агента (ТРЕБУЕТ РЕСЕРЧ)
+
+### Вопросы для исследования
+- [ ] **Per-project vs shared memory?** — стоит ли разделять память по проектам? Агент работает на нескольких проектах — смешивать или изолировать?
+- [ ] **Структура памяти** — как организовать memory/:
+  - `memory/global/` — общие знания, уроки
+  - `memory/projects/{slug}/` — контекст конкретного проекта
+  - `memory/sessions/` — автокомпакция сессий
+- [ ] **Загрузка контекста** — как агент выбирает какую память загружать? По текущему проекту? По задаче? Всю?
+- [ ] **Размер контекста** — лимиты на bootstrap context (сейчас 15K chars). Как масштабировать при росте памяти?
+- [ ] **Компакция** — автоматическая очистка старой памяти? Суммаризация?
+- [ ] **Shared knowledge** — если два агента работают на одном проекте, должны ли они видеть память друг друга?
+
+### Возможные решения
+- **Вариант A:** Flat memory — всё в `memory/`, агент сам разбирается (текущее)
+- **Вариант B:** Per-project dirs — `memory/projects/{slug}/`, загружается по контексту задачи
+- **Вариант C:** Semantic search — агент ищет по памяти через embeddings (тяжёлое решение)
+- **Вариант D:** Project files as memory — документы проекта на трекере = общая память команды
+
+---
+
+## Фаза 3: UUID-based workspace (отложено)
+
+- [ ] Workspace именуется по `member.id` (UUID) вместо slug
+- [ ] Симлинки `agents/coder → agents/{uuid}` для удобства
+- [ ] Переименование slug не ломает workspace
+
+---
+
+## Решения (принятые)
+
+| Решение | Дата |
+|---------|------|
+| agent.json = token + tracker_url, config.json = LLM config | 2026-02-25 |
+| Трекер = source of truth для routing/orchestration | 2026-02-25 |
+| Агент не раскрывает api_key трекеру | 2026-02-25 |
+| Directory mode для мульти-агент (уже работает) | 2026-02-25 |