# Specification: Dynamic Agent Decision Logic

## 1. Goal
Определить четкие правила выбора исполнителя для задач в целевом репозитории: когда задача выполняется силами глобального роя (универсальный `Junior`), а когда требуется генерация локального специализированного субагента.

---

## 2. Матрица принятия решений (Decision Matrix)

| Тип задачи / Контекст | Исполнитель | Алгоритм действий |
| :--- | :--- | :--- |
| **Простые задачи** (правка опечаток, README, простые баги в конфигах, мелкие скрипты) | Глобальный `Junior` | `CEO` напрямую отправляет задачу `Junior` без запуска процесса онбординга. |
| **Сложные стеко-специфичные задачи** (Next.js, FastAPI, SQL-миграции, Docker, SMTP) | Локальный Специалист *(если есть)* | `CEO` маршрутизирует задачу через A2A локальному агенту. |
| **Сложные задачи без локального спеца** | Создание локального спеца *(по согласованию)* | `Oracle` формирует system_prompt под стек и вызывает `define_subagent` для регистрации специалиста в текущей сессии. |

---

## 3. Алгоритм онбординга и генерации специалистов

При входе в репозиторий:
1.  **Librarian** сканирует файлы и выявляет маркеры стека (например, `package.json`).
2.  **Oracle** сопоставляет стек с известными специализациями (Next.js → seo-specialist, FastAPI → backend-specialist и т.д.).
3.  Если стек распознан, рой проверяет настройку авто-инициализации (`settings.json` → `"auto_bootstrap_agents"`):
    *   Если `true`: CEO автоматически вызывает `define_subagent` с готовым system_prompt.
    *   Если `false` (по умолчанию): Рой отправляет запрос пользователю через Telegram: *"Обнаружен стек Next.js. Создать локального seo-specialist? [y/n]"*. Ожидает ответа через `/confirm`. После подтверждения — `define_subagent`.

---

## 4. Предотвращение бесконечных циклов (Ignore List & .geminiignore)
Для жесткой защиты от ситуации, когда рой анализирует собственные конфигурации как код проекта:
*   **Системное ограничение (.geminiignore):** Ограничение не должно опираться только на инструкции. При онбординге в целевой репозиторий Librarian обязан автоматически сгенерировать файл `.geminiignore` в корне проекта (если он отсутствует) и добавить туда следующие пути:
    ```ignore
    .agents/
    .specify/
    MISSION_CONTROL.md
    SWARM_STATUS.md
    *_skills.md
    ```
*   Все инструменты сканирования и поиска (`glob`, `grep_search` и др.) нативно фильтруют файлы на основе созданного `.geminiignore`, гарантируя, что ни один агент (включая `Junior`, `Prometheus` и `Quality-Validator`) физически не сможет получить доступ к внутренним структурам роя.


---

## 5. Исключение конфликтов имен (Namespace Safety & Slugification)
Чтобы локальные конфигурации не перезаписывали глобальные настройки и не приводили к сбоям регистрации в движке `agy`:
*   Имя локального агента в шапке YAML должно автоматически получать префикс текущего репозитория (например, `ads_az-seo-specialist` вместо `seo-specialist`).
*   **Правило слагификации (Slugification):** Предотвращает ошибки парсинга при наличии в имени репозитория пробелов или недопустимых символов (например, `My Project`). Префикс имени репозитория обязан проходить очистку по правилу: переводится в нижний регистр (lowercase), все символы кроме латинских букв, цифр, дефиса и нижнего подчеркивания (`a-z0-9-_`) заменяются на дефис (`-`), а повторяющиеся дефисы схлопываются.
    *   *Пример:* `My Project` $\rightarrow$ `my-project-seo-specialist.md`.

---

## 6. Защита от бесконечного пинг-понга (Retry & Loop Protection)
Чтобы избежать ситуации, когда `Junior` и `Quality-Validator` бесконечно пересылают друг другу задачу, генерируя бесконечный цикл правок и сжигая лимиты токенов:
1.  **Счетчик попыток (Retry Counter):** В сессионной базе данных `sessions.db` (или в метаданных задачи `tasks.md` в формате `[Attempt: N/3]`) ведется строгий счетчик попыток исправления ошибок.
2.  **Лимит циклов:** Лимит возвратов задачи субагенту на доработку составляет максимум **3 попытки**.
3.  **Триггер прерывания:** Если счетчик достигает 3, рой прерывает выполнение задачи, записывает в `SWARM_STATUS.md` статус `BLOCKED_BY_RETRY_LIMIT`, сохраняет стейт сессии и отправляет пользователю в Telegram алерт о необходимости ручного вмешательства.