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)

agents/{slug}/
  AGENT.md                    # инструкции (статичные)
  memory/
    agent.md                  # личные уроки, стиль (грузится ВСЕГДА)
    projects/
      {project_uuid}/
        context.md            # архитектура, решения (грузится per-task)
        recent.md             # последние действия (rolling window, ~20 записей)

Почему UUID, а не slug? Slug проекта может измениться (переименование). UUID — immutable. Память агента не ломается при переименовании проекта.

Загрузка контекста

1. Task приходит с project_id (UUID)
2. Bootstrap: AGENT.md + memory/agent.md + memory/projects/{project_uuid}/context.md + recent.md
3. Итого ~7K chars вместо 15K (экономия ~50%)
4. Кросс-проектная инфа — on-demand через MCP-тулзы, НЕ в bootstrap

Компакция

• После завершения задачи: LLM суммаризирует сессию → 3-5 строк → append recent.md
• recent.md: rolling window, последние ~20 записей, старые вытесняются
• Weekly: LLM ревьюит recent.md → обновляет context.md (long-term)
• Сырые JSONL сессии: удалять через 7 дней (суммаризация уже произошла)

Кросс-проектный доступ

• Агент = member в своём проекте, viewer в связанных
• Viewer = read-only (list_tasks, list_project_files через REST)
• Viewer НЕ получает WS push-события (экономия токенов)
• Три уровня контроля: AGENT.md → MCP-тулзы → API (403)

Shared knowledge

• Project docs (README, ARCHITECTURE) = shared, живут в трекере/репо
• Personal memory = agent-only, не шарится между агентами
• Координация — через project docs или чат, не через чужую память

---

Фаза 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
Per-project память: agent.md (always) + projects/{uuid}/ (per-task)	2026-02-25
Папки памяти по UUID проекта (не slug — slug может измениться)	2026-02-25
Viewer-роль: read-only доступ к чужим проектам	2026-02-25
Viewer без WS push — только REST pull	2026-02-25
Shared knowledge через project docs, не через чужую память	2026-02-25