docs/AGENT-PLAN.md

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