DECISIONS — главные решения ресёрча (с обоснованиями)

Свод финальных архитектурных решений курса/roadmap для Лучиана. Каждое решение — что выбрано, почему именно это, и что отвергнуто. Ссылки на файлы базы для проверки деталей.

1. Выбор ядра — Claude Agent SDK

Решение: ядро оркестрации — Claude Agent SDK поверх уже существующей подписки Claude (claude -p, мульти-аккаунт failover), НЕ OpenClaw / CrewAI / LangGraph / AutoGen(AG2) / OpenAI Agents SDK как самостоятельное ядро.

Почему: Agent SDK — единственный кандидат, совместимый по всем осям сразу — это официальная библиотека поверх той же CLI-модели, которую завод уже использует, а не чужой фреймворк со своей философией состояния (analysis/frameworki.md §2.7, §6). Субагенты получают изолированный контекст (наследуют только system prompt + CLAUDE.md, не историю родителя) и лимит глубины 5 уровней — это прямое архитектурное решение его токеномической боли (frameworki.md §2.7, §6.2). OpenAI SDK отклонён сразу — несовместим с мозгом (подписка Claude, не API-ключи OpenAI) (frameworki.md §2.4). CrewAI даёт красивую ролевую модель, но доказанно неэффективна при условной маршрутизации — 15759 токенов вместо 200 на простом запросе (frameworki.md §2.2, verify/corrections-2). LangGraph хорош как язык описания графа (State/Node/Edge), но полная миграция на его абстракции состояния была бы избыточным переписыванием уже работающей инфраструктуры — оставлен как концептуальный паттерн (checkpoint), не библиотека (frameworki.md §2.1, §4.2). OpenClaw ближе всего по духу (Лучиан его уже пробовал, MEMORY.md/.learnings/ калькируют его memory-bank), но отвергнут как ядро из-за токен-бомбы параллелизма ($1.3М/мес на 100+ агентах у Steinberger) и уязвимостей 2026 года (CVE-2026-25253 RCE, 15% вредоносных skills в ClawHub) — идеи заимствуются, код не тащится (frameworki.md §2.5, §6.7, verify/corrections-2, corrections-3).

2. Архитектура автономии — короткие фазы + денежный гейт кодом

Решение: полная ночная автономия реализуется не как один долгий прогон, а как десятки коротких проверяемых фаз с чекпоинтами; единственный жёсткий стоп — денежный гейт, встроенный как код (hook), а не как обещание модели.

Почему: «100% автономность» задокументирована индустрией как ошибка (Codemanship, февраль 2026) — работающие системы держат firehose короткими проверяемыми очередями, не одним марш-броском (analysis/realnye-keysy.md §8, avtonomnaya-razrabotka.md §5.3). Математика вероятностного отказа объясняет почему: 10-шаговая цепочка с 95%-точностью на шаг даёт лишь ~60% шанс полного успеха без промежуточных проверок — иллюстративная арифметика, помечена жёлтым trust-badge, но качественный вывод верен (nadezhnost.md §5, verify/corrections-2 №9). Денежный гейт как hook (не промпт) — прямое лекарство от «монстра, кушающего $1000/мин»: hooks детерминированы и не могут галлюцинировать разрешение на трату (primenenie.md §2.2, frameworki.md §2.7). Матрица риска READ/WRITE/DELETE/ТРАТА заменяет единый бинарный APPROVAL_PENDING — публиковать/писать/менять можно автономно, тратить деньги — всегда подтверждение (nadezhnost.md §1, lucian-profile.md).

3. Токеномика — пять рычагов

Решение: дешевизна системы обеспечивается пятью рычагами одновременно, а не одним приёмом: (1) контекстная изоляция субагентов, (2) внешняя память вместо контекста (scratchpad/файлы), (3) компакция/суммаризация между этапами + свежая сессия на новый этап, (4) лестница моделей (haiku→sonnet→opus), (5) mechanical-first (скрипт/grep вместо LLM).

Почему: боль Лучиана эмпирическая — контекст раздувался до ~1M токенов на 12-шаговой задаче, потому что оркестратор передавал сырьё, а не выжимки (lucian-profile.md, «Токеномика»). Multi-agent режим стоит ~15× дороже простого чата — проверено дословно (orkestratsiya.md, verify/corrections-2 №12). Каждый рычаг закрывает свой слой: изоляция и внешняя память — архитектурный слой (что не передавать агенту), лестница моделей — экономика решения задачи подходящим уровнем интеллекта («Sonnet=Opus на чётких код-задачах ×4 дешевле» — его собственный замер), mechanical-first — устранение LLM там, где не нужен интеллект вовсе (его замер: LLM-аудит 10 тулок ≈ 4M токенов, grep = 0) (pamyat.md, skills-catalog/gems-orchestration.md вывод №3). Отдельно — стоп-краны как последний рубеж: бюджет на прогон, лимит ходов, мониторинг $/задача (его правило «>250k cache-read или >$0.50 — стоп») (nadezhnost.md §6, course-outline.md Модуль 5).

4. Размещение — VPS-мозг + ПК-3090-мышцы + fallback RunPod

Решение: гибридное размещение, не выбор одного узла — VPS = «мозг снаружи» (оркестрация, память, панель, 24/7, не зависит от домашнего ПК), домашний ПК с RTX 3090 = «мышцы по требованию» (локальный инференс, рендер, голос) через Tailscale, с облачным fallback (RunPod), если ПК офлайн.

Почему: оркестратор ночной автономии не должен зависеть от того, включён ли Лучиан дома компьютер — выключенный ПК не должен ронять фабрику (deploy-ui.md §1). GPU у него уже используется по требованию (ночной voice), а не простаивает 24/7 — это уже правильный режим, который стоит формализовать, а не менять (deploy-ui.md §1). Экономика размещения пересчитана честно после проверки: сборка ПК с 3090 стоит $1500-3500 (не «от $900»), аренда 3090 в облаке $0.13-0.6/час (не $15/час), из-за чего «окупаемость за 1-2 года» верна только против premium managed API, а не против честной GPU-аренды — все цифры в исходной аналитике исправлены (trust-badge красный, verify/corrections-3 №1, course-outline.md §8.1). В сравнение честно включены все варианты — Hetzner-апгрейд, новый облачный сервер, Mac mini 24/7 (тихий, низкое энергопотребление), ПК-3090, облачный GPU по требованию, гибрид — рекомендация исходит из задач и денег, а не из уже стоящего дома железа (lucian-profile.md «Хостинг — не зацикливаться», course-outline.md §11.2).

5. Порядок стройки — девять этапов

Решение: внедрение идёт по фиксированной последовательности из девяти этапов, не «всё сразу»: (1) диск + аудит 0.0.0.0-биндингов; (2) структурированный лог решений в memory-bank → замкнуть LEARNING; (3) изолированный критик на существующем APPROVAL, откалиброванный неделями; (4) брокер (Redis) между стадиями; (5) orchestrator.mjs с матрицей гейтов + budget-gate как hook; (6) mobile-панель + двусторонний Telegram; (7) отдельная песочница ночного билдера; (8) opportunity-scout; (9) веер MVP на изолированных worktree.

Почему: порядок расставлен по риску/ценности, а не по интересности — сначала дёшевые и безопасные исправления (диск на 91% — тихий убийца автономии, чинится первым, потому что дёшево), затем фундамент памяти и доверия (замкнутая LEARNING и откалиброванный критик — без них снятие гейтов небезопасно), и только потом инфраструктура параллелизма и, в самом конце, самая рискованная и дорогая часть — параллельный веер MVP на изолированных git worktree (course-outline.md Урок 11.3, nadezhnost.md §9, avtonomnaya-razrabotka.md §9). Первый кандидат «включить агентность» — одна вертикаль (evaluator-optimizer уже есть → orchestrator-workers read-only → потом полный цикл до APPROVAL), а не всё сразу — прямое следствие того, что параллелить одну кодовую базу преждевременно не работает (конфликты; урок Factory Missions, orkestratsiya.md, verify/corrections-1 №9).

6. Паттерн MVP-фабрики — веер с явно разными углами + турнир судей

Решение: консультант-фабрика MVP строится как explorer×critic с ЯВНО разными приоритетами (перф/DX/дёшево-быстро и т.п.) у каждого explorer-агента → judge panel из разнородных судей → knockout-турнир O(N log N), а не полный перебор или N гомогенных копий одного и того же промпта.

Почему: урок Карпати прямо предупреждает — 8 параллельных агентов с одинаковой установкой провалились на генерации идей, потому что гомогенность судей/генераторов снижает качество результата (X-корпус, analysis/x-digest-1.md, course-outline.md Урок 2.4). Веер не удлиняет ночь (время ≈ времени самого медленного варианта), но стоит дороже по токенам — управляемая, а не бесплатная переменная («мультиверс 2-3× дороже» — эвристика, не измеренная метрика, trust-badge жёлтый, verify/corrections-3 №12) (orkestratsiya.md, avtonomnaya-razrabotka.md §6). Knockout-турнир выбран вместо попарного сравнения всех со всеми ради масштабируемости — O(N log N) против O(N²) при росте числа вариантов до 10 (orkestratsiya.md Best-of-N + Judge Panel). В каталоге готовых скиллов паттерн уже встречается дважды независимо (cs-roast-judge — 5 состязательных ролей + судья без усреднения; AgentHub hub-coordinator — N параллельных агентов в изолированных worktree + авто-мерж победителя) — это независимое подтверждение архитектуры, оба можно взять как каркас (skills-catalog/gems-orchestration.md вывод №2).

7. Что брать готовым из каталога скиллов vs писать своё

Решение: компилировать библиотеку скиллов из существующих каталогов (anthropics/skills, phuryn, sickn33, AgentHub, hyperflow и др.) там, где задача типовая, и писать своё только там, где каталог системно слаб.

Почему: для консультант-фабрики почти весь контур «боль клиента → анализ → ТЗ → веер MVP → продажа» уже покрыт готовыми скиллами без написания промптов с нуля (discovery/JTBD/SWOT → market-sizing/business-investment-advisor как opportunity-scout → lean-startup/create-prd/pre-mortem как веер и критика → pricing/deal-proposal как продажа) (skills-catalog/gems-business.md вывод №1). Для контент-фабрики есть один «золотой» пакет (youtube-strategy), почти один в один повторяющий его конвейер ⓪→⑨ — прямой кандидат на копирование, но категория на ~90% замусорена нерелевантным generic-маркетингом, и готового аналога QC-петли thumbnail-studio (сгенерировал→оценил CTR→доучился) в каталоге нет — придётся достраивать самим (skills-catalog/gems-content.md выводы №1-2, №5). Для оркестрации связка hyperflow+agent-teams закрывает ~70% архитектурных вопросов «с нуля», но денежные гейты и durable-очереди для мультиагентных ночных задач в каталоге практически не представлены — это придётся спроектировать индивидуально, компилируя из нескольких скиллов (skills-catalog/gems-orchestration.md выводы №1, №5). Для ресёрча — pulse/efficient-web-research/deep-research дают готовый ответ именно на его токеномическую боль (лид-агент + суб-агенты пишут в файлы, не в общий контекст) и должны стать первым импортом, а не переизобретаться (skills-catalog/gems-research.md выводы №1, №3); слой холодных продаж для локального консалтинга (не B2B SaaS) в каталоге почти не покрыт и потребует ручной адаптации (gems-business.md вывод №4).