gendesign/.claude/rules/delegation.md

Delegation & task sizing

Без paths: — загружается в каждой сессии. Канон лимитов делегирования (портировано из memory-фидбека 2026-06-27, routing/effort — из верифицированного ресёрча 2026-07-02).

Routing (кому отдавать)

Задача	Агент
Разведка: найти файлы / понять структуру	Explore (Haiku, read-only, дёшев) — НЕ general-purpose
Спроектировать подход	Plan
Код	доменный worker (backend/frontend/database/devops) + isolation: "worktree"
Проверить результат	отдельный агент в fresh context — видит только diff и критерии, без bias автора

• Продолжение работы существующего агента → SendMessage по agentId (контекст цел), НЕ новый спавн с пересказом.
• Масштаб пачки: 1-3 независимых → параллельные Agent-вызовы одним сообщением; конвейер / 10+ агентов → Workflow (pipeline-default, schema-выход, adversarial verify находок). Caps на выборках — логируй отброшенное, молчаливое усечение читается как «покрыто всё».

Бюджет одного сабагента (hard limits)

• 1 сабагент = 1 узкий deliverable. Ориентиры: ~≤10 мин работы, ~≤20 tool-calls, ~≤150k токенов. Эмпирика 2026-06-27: агент-аудитор на 186k tok / 33 calls упал на StructuredOutput; 5 мелких параллельных прошли.
• Поверхность больше бюджета → дели на N узких сабагентов (parallel при непересекающихся файлах, sequential при зависимостях). НЕ один большой.
• Промпт сабагенту: конкретный deliverable + формат ответа + границы («что НЕ делать»). Расплывчатый scope = дубли и мусор.
• Бюджет живёт В ПРОМПТЕ, а не в голове оркестратора. Знать лимит недостаточно — агент его не видит. Пиши в промпт явно: потолок вызовов (~20-25) и времени, список «строго запрещено» (типично: не читать исходники приложения, не ходить в git-историю, не диффать смежное), правило деградации «бюджет кончается → отдай что есть, допиши в notes что не успел». Эмпирика 2026-08-24: два разведчика без потолка ушли на 157 и 178 ходов вместо инвентаризации — один вместо списка веток диффал SQL-миграции и разбирал Caddyfile.
• schema: требует потолка РАЗМЕРА ответа, отдельно от токенов. Payload StructuredOutput >~10k символов не парсится (InputValidationError) → повтор → вся работа агента теряется. В промпт: максимум N items, лимит символов на поле, весь ответ ≤~6000 символов, и прямым текстом «неполный ответ несравнимо лучше потерянного». Схему проектируй под краткость: длинные detail-поля провоцируют ровно этот отказ.
• Windows: очень длинный промпт субагенту может упасть на лимите командной строки (~8191 символ) — ещё один довод за компактность.

Эскалация oversized-задачи (worker)

Issue/задача выглядит больше одного захода (эвристика: >5 файлов, ИЛИ >500 строк diff, ИЛИ >2ч) → НЕ исполнять целиком:

• bot-pipeline: комментарий с планом сплита + label status/needs-analysis, снять claim
• interactive: вернуть main-сессии план сплита вместо результата

Целость результата workflow

• Завершившийся прогон ≠ успешный. Читай <failures> в уведомлении и journal.jsonl (по строке result на агента). Упавшие агенты возвращают null, parallel() их молча проглатывает, а стадия синтеза всё равно выдаёт уверенный текст с числами. Прежде чем показывать такой вердикт пользователю — проверь его несущие числа сам.
• Восстановление: TaskStop → Workflow({scriptPath, resumeFromRunId}). Готовые агенты реплеятся из кэша бесплатно, перезапускаются только упавшие. Правка промпта перезапускает ЭТОТ агент и все последующие (правило префикса) — правь точечно, не переписывай скрипт целиком.
• Диагностика зависшего агента: возраст последней записи в agent-*.jsonl + тип последнего события. assistant/tool_use без ответа при неподвижном журнале = завис. Несколько агентов замолчали одновременно = обрыв соединения, обычно лечится сам повтором — не спеши убивать.
• Windows: скрипт workflow писать только в LF. Перезапись через python даёт CRLF → запуск отбивается script contains control characters. io.open(..., 'w', newline='\n').

Единые пороги дробления (analyst / main)

• Estimate S(<2h) / M(2-8h) / L(>8h) → обязан дробиться дальше (до S/M)
• Issue ≥1.5 дня → 3-4 sub-PR (Foundation → Schema → Workers → Integration), каждый ~200-500 строк — см. git-pr.md § Split big issues
• 1 sub-issue ≈ 1-2 worker-захода, single-scope (не смешивать backend+frontend в одном issue)

Параллелизм

Default = parallel на непересекающихся файлах (per-task worktree). Sequential — только overlap / hot-files / зависимый стек (git-pr.md § Parallel vs sequential PRs).

Усилие ∝ сложности: простой факт-запрос = 1 агент / 3-10 tool-calls; сложный разбор = N узких параллельных. Ширина пачки дешева, толщина одного агента — дорога и хрупка. Параллельные сессии/окна: практический потолок 3-5 (bottleneck — review, не Claude).

Effort / model per agent

• Наследовать по умолчанию; модель НЕ переопределять без нужды (Explore и так на Haiku).
• effort: low/medium — механика: точечные правки по списку, сбор данных, mass-grep, формат-конверсии.
• effort: high+ — только verify/judge-этапы, архитектурный синтез, решения.
• Циклы/поллинг: prompt-cache живёт 5 мин — тик либо <~4.5 мин (кэш тёплый), либо сразу 20-30 мин; интервалы 5-15 мин = worst case (полный re-read контекста каждый тик без амортизации).