# 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 |