← Университет

Применение: три направления заказчика

Аналитический документ для Лучиана. Задача: показать, как теория мультиагентных систем (оркестрация, память, автономия, judge panel) ложится на ЕГО конкретный завод и три цели года — (1) фабрика faceless-контента на десятках каналов с полной ночной автономией, (2) универсальный строитель приложений, (3) консультант-фабрика MVP («ночь → веер прототипов»). Не пересказ материалов — разбор архитектур с цифрами, цитатами и ошибками, спроецированный на его инфраструктуру (channel-hq, memory-bank, thumbnail-studio, resource-governor и т.д., см. _HERMES_HANDOFF).

0. Общий тезис: у Лучиана уже есть 80% архитектуры — не хватает трёх вещей

Прочитав 02-factory-overview.md, видно: завод — это уже почти учебниковая multi-agent система. Конвейер ⓪→⑨ — это Hierarchical Orchestration (channel-hq как supervisor, генераторы как workers), с Blackboard-подобным разделяемым состоянием (memory-bank — 3 банка: global / per-channel / per-generator), с ресурсным брокером (resource-governor — практически Concurrent Orchestration control-plane) и с зачатками QC-петель (thumbnail-studio StyleBank + Haiku QC). Это не абстракция из учебника — это буквально паттерны из orchestration-patterns.md, уже реализованные в коде.

Чего не хватает по документам: 1. Оркестратор выключен (channel-hq/core/orchestrator.mjs — опционален, off) — то есть завод сейчас работает как workflow с ручными гейтами, а не как agent в смысле ReAct-цикла (агент = модель сама решает число шагов; workflow = фиксированный путь). Разница объяснена в fundamentals-agents.md: агенты «проактивны и автономны», чат-боты/workflow «реактивны». У Лучиана сейчас — управляемый workflow с двумя человеческими гейтами (EDIT_PENDING, APPROVAL_PENDING). 2. LEARNING холостая — стадия ⑨ существует архитектурно, но метрики не текут автоматически в банки памяти. Это ровно тот разрыв, который описан в memory-state.md: система умеет писать в долгосрочную память, но нет замкнутого цикла «результат → урок → следующая генерация». 3. Нет agent-критика вместо ручного APPROVE — то есть человек до сих пор в петле там, где по паттерну Planner-Executor-Critic (см. ниже) его роль должна свестись к утверждению редких edge-кейсов, а не к каждому видео.

Дальше — по каждому направлению отдельно, с конкретной архитектурой поверх существующих сервисов.

Важное уточнение по терминологии, которое стоит держать в голове через весь документ: в материалах чётко разводится workflow (фиксированная последовательность шагов, заданная заранее) и agent (система, которая сама решает, сколько шагов сделать и в каком порядке, реагируя на промежуточные результаты). Конвейер ⓪→⑨ Лучиана сегодня — это workflow с точками ветвления на гейтах. Полная ночная автономия — это не «тот же workflow, но без гейтов», а качественный переход к agent-модели: система должна уметь САМА решить «этот сценарий не дотягивает — перегенерировать» или «эта тема токсична — заменить», а не слепо идти по фиксированным стадиям. Разница на практике: workflow ломается непредсказуемо на нестандартном входе, agent должен деградировать предсказуемо (откатиться, попросить уточнение, взять safe default).

1. Масштабирование фабрики контента: с 1-3 каналов до десятков с полной автономией

1.1 Включить оркестратор — но НЕ как выключатель, а как замена архитектуры гейтов

Наивная ошибка: просто включить orchestrator.mjs как есть, оставив логику «approve = кнопка человека». Это не даст автономии — просто автоматизирует до стадии APPROVAL и там же упрётся.

Правильная модель — заменить человеческий гейт на агент-критика по паттерну Planner-Executor-Critic, который в исследовании из orchestration-patterns.md даёт измеримый скачок:

«Первый проход (single-agent): 24.9% безошибочно. Внутренний цикл с critic: 87.8% перехвата ошибок. Финальная точность: 92.1% успешности. Сравнение: одноагентный подход — 60% точность; многоагентная система с critic — 92%.»

Применительно к заводу это означает: channel-hq уже играет роль Planner+Executor (ставит тему в очередь, гоняет через генератор). Не хватает выделенного Critic-агента, который получает финальный пакет (video + cover + SEO) и выносит вердикт по явному чек-листу — именно так, как Лучиан уже сформулировал: «хук, визуал, звук, факты». Это прямое повторение архитектуры Verifier Pattern из autonomous-coding.md:

«Same-model самопроверка неэффективна: "Any mistake made during generation is likely to persist through review — because the reviewer thinks the same way as the writer." Решение: independent verification agent, получающий только артефакт и исходные требования, без контекста генератора.»

Ключевой инженерный вывод для Лучиана: критик должен получать НЕ ту же сессию/контекст, что генератор — иначе он унаследует те же слепые пятна (типовая ошибка «same-model review»). Технически: отдельный claude -p вызов (или отдельный субагент) с чистым контекстом, входом — только final.mp4 + метаданные + чек-лист, без истории генерации сценария.

1.2 Уровни автономии по риску — не бинарный APPROVE/DENY

В case-studies-failures.md описан паттерн Tiered Autonomy, который прямо решает страх Лучиана «монстр, который тратит деньги» и одновременно его требование «публиковать можно, тратить деньги — нет»:

Read-only (анализ ниш, генерация сценария-черновика) → 100% автономия
Create/Update (публикация видео, правки SEO)          → критик-агент решает, эскалация редка
Delete/Spend (покупка Veo-кредитов, платный TTS-тир)   → всегда явное подтверждение человека

Это ровно соответствует его текущей архитектуре: voice draft/final tier (бесплатный edge-tts на тестах, платный MOSS/RunPod в бою) уже реализует этот принцип на уровне одного шва. Задача — распространить его на ВСЮ фабрику: критик автоматически approve'ит публикацию (риск = репутация, обратим — можно удалить видео), но НЕ автоматизирует ничего, что тратит деньги сверх заранее одобренного бюджета на канал/день.

1.3 Оживление LEARNING: от «холостой стадии» к реальному замкнутому циклу

Стадия ⑨ (LEARNING) описана в его же карте как «метрики → банки памяти», но не работает. По memory-state.md, для этого нужна не абстрактная «база данных», а конкретная типология памяти, применённая к его трём банкам:

Дизайн замкнутого цикла (это прямо стадия LEARNING, которую нужно оживить):

YouTube Analytics (72ч задержка, см. content-automation.md)
  → agent считывает метрики (CTR, AVD, retention)
  → пишет episodic-запись в log.jsonl канала
  → раз в N видео агент-аналитик (Sonnet, не Opus — механическая задача)
    агрегирует паттерны → обновляет semantic memory в profile.json
    (например: style_target, wedge_score veto-правила)
  → следующая генерация читает обновлённый profile.json

Критично: retrieval должен быть гибридным, не чистым semantic similarity — в memory-state.md подчёркнуто, что чистый векторный поиск даёт «ложные срабатывания», а мультисигнальный (dense + BM25 + entity matching) даёт +90% точности. Для завода это проще, чем звучит: у него уже структурированный JSON (не свободный текст), так что «поиск» по большей части — это фильтрация по полям (channel_id, format, niche), а не эмбеддинги. Экономия токенов огромная — как и требует его правило mechanical-first.

1.4 Масштабирование до десятков каналов: что ломается первым

Из content-automation.md, реальный кейс масштабирования на несколько каналов (Glissando AI) подтверждает архитектуру, которую Лучиан уже выбрал интуитивно:

«Ключевой архитектурный принцип: конвейер описывает процесс, а не конкретный контент. Каждый канал имеет собственные параметры (тон, целевая аудитория, ключевые слова), которыми оперирует система.»

Это буквально то, что делает channel-forge (ниша → profile.json) и per-channel memory-bank. Хорошая новость: архитектурно готово. Плохая новость — при переходе с 1-3 на 10+ каналов первым сломается то, что описано в 06-errors-and-gotchas.md-классе проблем и в case-studies-failures.md:

1.5 Токеномика при масштабировании — где взорвётся бюджет

Прямое применение его пятого этапа (стадия LEARNING + оркестратор включён) — самый токеноёмкий сценарий, потому что каждое видео теперь порождает: генерацию + QC + критик + запись в память + возможный re-run. По orchestration-patterns.md: «многоагентные системы потребляют 15× больше токенов чем чаты». При 10 каналах × несколько видео в день это будет расти нелинейно, если не применить его же правило лестницы моделей:

Это прямое следствие его собственного открытия («Sonnet=Opus на чётких код-задачах, ×4 дешевле») применённое не только к коду, но и ко всей фабрике контента.

2. Универсальный строитель приложений

2.1 Ядро: тот же движок, что кодит его завод, применённый к произвольным проектам

Его первый приоритет — «по одной команде строит любой сайт/тулзу/автоматизацию/игру». Это прямое применение архитектуры из autonomous-coding.md, где описаны три конвергентных подхода (Claude Code, Devin, OpenHands), сходящихся к одному и тому же набору примитивов:

«Repository memory files (CLAUDE.md, AGENTS.md), Direct tool integration (git, test-runners, shell), Sub-agent specialization, Long-running execution loops для multi-step problem solving.»

У Лучиана это уже частично есть — сам завод построен именно так («месяц стройки с Claude», git-репо с патчнотами, 5 законов как персональный аналог CLAUDE.md). Задача строителя приложений — не изобретать новую систему, а обобщить его собственный процесс строительства завода в переиспользуемый харнесс, применимый к ЛЮБОМУ новому проекту, не только к видео-заводу.

Конкретная архитектура цикла «план → код → критика → тест → визуальная проверка → доработка» (его формулировка) — это прямое совпадение с архитектурой Devin:

«Planner: разбивает размытые требования в пошаговый план с динамическим re-planning. Coder: реализует код и идентифицирует компиляционные ошибки. Critic: проводит security-review и проверяет логику. Browser Agent: синтезирует информацию из документации и интернета. Ключевая особенность: self-correcting code.»

Плюс визуальная проверка — это отдельный слой, который в материалах называется ProofShot pattern:

«ProofShot — open-source CLI-tool для visual verification работы агента... Записывает browser-сессии с видео, захватывает скриншоты на ключевых моментах... функционирует как verification layer, не как automation-tool.»

Для Лучиана это конкретно значит: агент-критик приложения не читает код глазами (LLM плохо «видит» верстку в коде), а смотрит скриншот через vision-модель — ровно тот же паттерн, что уже работает в его thumbnail-studio (Haiku vision QC для обложек). Технология одна и та же — просто применена к другому артефакту (UI вместо картинки).

2.2 Hooks вместо промптов — детерминированные гейты качества

Ключевая идея из autonomous-coding.md, которая прямо решает его боль «контроль и дожимание ИИ»:

«Hooks — это не промпты, а исполняемые скрипты в 25 точках жизненного цикла агента... "Unlike prompts, which rely on the model's interpretation, hooks execute deterministic code. They cannot hallucinate."»

Это техническое воплощение его же правила №3 («скрипт вместо ИИ где можно»). Для универсального строителя приложений это значит: линтер, тесты, security-scan, проверка «не потратил ли деньги» — всё это должно быть PreToolUse/PostToolUse hook, а не пункт в промпте, который агент может проигнорировать в 3 AM. Промпт можно «уговорить» отступить от правила; hook — физически блокирует действие (exit code).

2.3 Ночная работа: cron vs Hermes-подобная оркестрация vs cloud-native

Три подхода описаны в autonomous-coding.md (раздел «Ночная работа без человека») — и они прямо релевантны выбору инфраструктуры для Лучиана:

  1. claude -p + cron — самый простой, подходит для одношаговых задач. У него уже есть аналог для x-research-daily (systemd-таймеры). Минус: для многошаговых прогонов (веер MVP, о котором ниже) не хватает retry-logic и dependency-management.
  2. Hermes-подобная оркестрация (термин из материала, совпадающий с именем его нового агента!) — «task queues, retry logic с exponential backoff, run-history tracking, dependencies между tasks». Это ближе к тому, что ему нужно для многошагового ночного строительства: если шаг 3 из 7 упал, система не должна начинать всё с нуля (тот же принцип «resume, не удалять», который уже прописан в его 5 законах для завода).
  3. Cloud-native платформы (managed execution) — избыточны для его масштаба, дороже, меньше контроля. Не рекомендуется.

Вывод: инфраструктура его будущего строителя приложений должна повторять паттерн resume из _HERMES_HANDOFF («упал прогон → resume, не пересоздавать»), примененный не только к видео-проектам, но и к любому agentic-строительству кода.

2.4 Критичный антипаттерн: 100% автономность в кодировании — не работает

Материал case-studies-failures.md жёстко предупреждает именно про то, к чему тянет Лучиана (полная автономия строителя приложений):

«100% автономное кодирование не работает... "Out-of-distribution problems will always be a feature of generative transformers. It's an unfixable problem." ... Успешные команды отказались от поиска полной автономности: "Hold the firehose in short, controlled bursts" — небольшие автоматизированные фазы с проверками между ними.»

И конкретная эмпирика от практика (Sanity, 6 недель с Claude Code):

«First Attempt Will Be 95% Garbage... Первая попытка (95% мусора) — AI строит контекст, вы выявляете реальные проблемы. Вторая попытка (50% мусора)... Третья попытка — получается итерируемый результат.»

Для консультант-фабрики MVP (направление 3) это значит: ночной прогон НЕ должен быть «одна попытка → готово утром» — архитектурно нужно закладывать 2-3 итерации критики ВНУТРИ ночи, а не полагаться на то, что первый проход будет хорош. Это прямо согласуется с уже упомянутой цифрой 24.9% → 87.8% через internal critique cycle.

2.5 Математика вероятностного отказа — почему длинные цепочки рушатся

Ключевая формула, которую Лучиану нужно держать в голове при проектировании ЛЮБОГО многошагового ночного прогона (и строителя, и MVP-веера):

«При точности 95% на каждом шаге, 10-шаговая задача имеет вероятность полного успеха: 0.95^10 ≈ 0.60 (только 60% успеха).»

Практический вывод: чем длиннее цепочка «план → код → критика → тест → визуальная проверка → доработка», тем больше нужно чекпоинтов, которые «перезагружают» вероятность (Selective Autonomy: «каждая проверка перезагружает вероятность ошибки — 0.95^5 вместо 0.95^10»). Именно поэтому в его заводе гейты EDIT_PENDING/APPROVAL_PENDING — это не бюрократия, а математически обоснованный механизм; вопрос не «убрать гейты», а «заменить человека на автоматического критика в тех же точках».

3. Консультант-фабрика MVP: ночь → веер 3-10 прототипов

Это направление напрямую описано в mvp-factory.md под названием Multiverse Development, и цифры там удивительно точно ложатся на формулировку Лучиана («веер вариантов»):

«Вместо последовательного выбора единственной архитектуры, современные команды пробуют множественные параллельные пути разработки одновременно... Мультиверс: O(n × m) где m — число параллельных universes. Стоимость: только 2-3x больше, чем linear разработка, но exponential learning.»

3.1 Архитектура «Explorer × Critic», а не просто N параллельных генераций

Наивная реализация «веера» — просто запустить 10 одинаковых агентов на одну и ту же задачу и выбрать лучший (Best-of-N). Материалы показывают, что это неоптимально: без явной дифференциации приоритетов explorer-агенты сходятся к похожим решениям (потеря разнообразия). Правильный паттерн — из mvp-factory.md:

«Три explorer agents работают параллельно... каждый генерируя кардинально отличный approach: Explorer 1 — performance и scalability, Explorer 2 — developer experience и maintainability, Explorer 3 — cost-efficiency и быстрое time-to-market... Один critic agent оценивает все три выхода... Преимущества разных perspectiv: избегаются cognitive anchoring bias.»

Применительно к его формулировке «3-10 разных MVP-решений» — не 10 копий одного агента, а 10 явно разных углов (можно взять оси прямо из его же курса AOY «Niche Bending»: Format × Market — только тут вместо ниши видео это будет «архитектура × бизнес-модель»): например для кофейни один explorer строит записывающую CRM-систему, второй — telegram-бот для лояльности, третий — dashboard управления запасами, и т.д. Дифференциация задаётся ЯВНО в промпте каждого explorer'а, не оставляется на волю случая.

3.2 Судейская панель (Judge Panel) — турнирная, не абсолютная

Прямая цитата из orchestration-patterns.md, релевантная его формулировке «сама их сравнивает/критикует/ранжирует»:

«PairJudge с knockout tournament (турнир выбывания) эффективнее для best-of-N: сложность O(N log N) вместо O(N²). Роль разнообразие критично: гомогенные судьи снижают качество оценки.»

Это значит: для 10 прототипов НЕ нужно, чтобы один судья сравнил все 10 попарно (45 сравнений) — нужен турнир на выбывание (пары → полуфинал → финал, ~9-13 сравнений), и желательно разные модели/роли-судьи (не один и тот же Sonnet трижды), иначе — тот же риск «эхо-камеры обучения», что уже был замечен в thumbnail-studio.

3.3 Анализ незнакомого домена — как агенты понимают «боли кофейни»

Ключевая находка из mvp-factory.md, напрямую отвечающая на вопрос «как система поймёт домен, которого никогда не видела»:

«Исследование Carnegie Mellon показало, что гибридный подход (явные процедурные правила + контекстное понимание LLM) обеспечивает 206% улучшение качества по сравнению с чисто LLM решениями... Dual implementation: явные правила в Python functions + tacit знание через prompt engineering и RAG.»

Практически: чистый «опиши боль кофейни в промпте и жди чуда» работает хуже, чем система с structured intake — то есть Лучиан вечером не просто надиктовывает боли, а система (например, через тот же client_interviewer из его сайд-проектов!) прогоняет их через полу-структурированное интервью с явными полями (workflow, decision-points, practical rules), а не свободный текст. У него УЖЕ есть client-interviewer в 09-side-projects.md — это прямой кандидат на роль intake-агента для консультант-фабрики.

3.4 «70% Problem» — честная граница возможностей

Важное отрезвляющее предупреждение из того же материала:

«ИИ раскрывает ~70% решения быстро — Остающиеся 30% (edge cases, security, production integration, user empathy) остаются так же требовательны, как раньше. Рекомендация: рассматривать ИИ как force multiplier для опытных engineers, а не как replacement.»

Для его бизнес-модели это значит: утренняя демонстрация клиенту — это не «готовый продукт», а «убедительный кликабельный прототип, который закрывает продажу», а не production-система. Roadmap должен явно разделять: (а) что можно продать как разовую консультацию/демо за одну ночь, (б) что требует недель доработки после продажи (это и есть его настоящий доход — не сам прототип, а последующий контракт на доведение).

3.5 Экономика — сравнение с индустрией

Из mvp-factory.md, ориентир по деньгам:

«Cost per MVP: $18,000–$150,000 в зависимости от complexity... Time to MVP: 2-6 недель вместо 2-4 месяцев.»

Это цена ПОЛНОЦЕННОГО MVP от агентства. Ночной веер прототипов Лучиана — это не то же самое, а гораздо более дешёвая и быстрая версия «discovery + пилот» (первая фаза из 3-фазной модели BotsCrew: Pilot/POC 1-2 недели → MVP 2-4 недели → Scaling 4-8 недель). Его настоящая монетизация — не сам ночной прогон (это его внутренняя стоимость в токенах, минимальная), а право продать вход в фазу 2 клиенту, который увидел рабочий прототип и поверил.

3.6 Opportunity scout — недостающий четвёртый агент

Профиль Лучиана прямо требует «агента-разведчика возможностей», который сканирует рынки и приносит идеи с расчётом. В архитектуре MVP-фабрики это отдельная роль, стоящая ДО explorer-агентов: не «клиент рассказал боль → веер решений», а более широкий контур — «разведчик сам находит бизнесы/ниши с болью → предлагает Лучиану, куда идти». Технически это Concurrent Fan-out того же типа, что используется в его собственном x-research-daily (уже развёрнутый сервис с systemd-таймерами и дайджестом в Telegram) — только источники другие: не X.com-тренды, а сигналы «где бизнесы теряют деньги» (форумы жалоб, отзывы, вакансии «ищем сотрудника вручную делать X» как индикатор автоматизируемой боли). Это прямое расширение уже работающего паттерна, не новая с нуля система.

4. Сквозная тема: solo-оператор и «клей» между направлениями

Все три направления объединяет одна архитектурная идея из solo-operator-scale.md, прямо адресующая его боль №1 («я сам — клей между инструментами»):

«Концепция "glue person" описывает роль человека, который вручную связывает между собой разрозненные инструменты и системы... AI Glue Agent: Collaboration Plane (источник истины, читаемый человеком) + AI Glue Agent (автоматический оркестратор, который мониторит collaboration plane, вызывает API, генерирует результаты обратно).»

Практически для Лучиана: единая веб-панель/Telegram, куда он бросает задачу («новый канал», «клиент X, боли: ...», «построй мне тулзу Y») — это Collaboration Plane. Дальше единый orchestrator-агент (не три разных для трёх направлений — один диспетчер с Handoff-паттерном) маршрутизирует задачу в нужный «завод»: контент-фабрику, строитель приложений или MVP-веер. Это прямо перекликается с его собственным выбором ролей моделей («Fable — оркестратор») — верхнеуровневый диспетчер уже спроектирован концептуально, дело за реализацией Handoff между тремя направлениями как единой системой, а не тремя изолированными.

Ключевая архитектурная развилка: Shared Memory vs Message Passing. Материал прямо предупреждает:

«Agent A обрабатывает информацию, отправляет результат Agent B. Agent B видит только вывод A, теряет исходный контекст... Результат: каждый агент рассуждает из разной частичной реальности. Решение: shared knowledge graph.»

У Лучиана эта проблема уже частично решена на уровне завода (memory-bank — общий для нескольких сервисов), но при добавлении направлений 2 и 3 нужно решить: это будет ТОТ ЖЕ memory-bank (единый мозг фабрики) или отдельные банки на каждое направление с явным мостом между ними. Рекомендация из материала — единый knowledge graph, чтобы «опыт», накопленный в контент-фабрике (какие ниши денежные, какие форматы заходят), был доступен агенту-разведчику возможностей и MVP-строителю, и наоборот.

5. Типичные ошибки — сводный чек-лист по всем трём направлениям

  1. Same-model review — критик с тем же контекстом, что генератор, не ловит системные ошибки (повторяется в thumbnail-studio, строителе приложений и MVP-судействе одинаково). Решение: изолированный контекст критика.
  2. 100% автономность без tiered risk — приводит к необратимым тратам/публикациям без чек-поинта. У Лучиана это уже частично решено (draft/final voice tier), нужно распространить на все траты денег.
  3. Полная автоматизация без человека в контент-фабрике — прямой прецедент провала: «канал заблокирован через 2 недели» из-за галлюцинированных фактов при 100%-автоматизации без QA (content-automation.md). Критик-агент — не роскошь, а необходимость, даже при «полной ночной автономии».
  4. Context explosion / игнорирование токеномики — 15× рост потребления в multi-agent системах; при масштабировании на 10 каналов + строитель + MVP-веер параллельно это может реально стать «монстром, кушающим $1000 в минуту», которого боится Лучиан. Решение уже сформулировано им самим (лестница моделей, mechanical-first, стоп-краны) — нужно применить системно, а не точечно.
  5. Гомогенные судьи в Best-of-N — снижают качество ранжирования; для MVP-веера и для будущего format-radar нужно разнообразие ролей/промптов судей, не просто N копий одного критика.
  6. Полагание на чистый LLM без domain rules — 206%-разрыв в качестве между гибридным (правила+LLM) и чистым LLM-подходом в понимании незнакомого бизнес-домена. Для MVP-фабрики критично иметь structured intake, а не свободный текст.
  7. Отсутствие observability/tracing — «компания потеряла €50k, потому что агент молча вернул неверные результаты; после добавления трассировки идентифицировали проблему за 30 минут». При полной ночной автономии логирование reasoning/tool calls — не опция.

6. Практические выводы для Лучиана — конкретика по каждому направлению

Направление 1 (контент-фабрика): - Включать оркестратор ПОСЛЕ, а не ВМЕСТО критика — сначала построить изолированного Critic-агента на существующем APPROVAL-гейте, откалибровать его на нескольких неделях ручного сравнения с собственными решениями, только потом снимать гейт. - Оживить LEARNING как трёхуровневую типологию памяти (episodic/semantic/procedural), не как «просто записать метрики». - Не масштабировать каналы быстрее, чем format-radar/wedge-скоринг с формат-осями (рекомендации аудита AOY) — иначе автономия просто быстрее произведёт больше немонетизируемого контента.

Направление 2 (строитель приложений): - Взять за основу его же процесс строительства завода (git, patch-notes, 5 законов) и формализовать как харнесс (аналог CLAUDE.md + hooks + subagents), применимый к произвольному новому репо. - Визуальная проверка — обязательный отдельный шаг (vision-QC артефакта UI), не полагаться на то, что агент «прочитал» код и решил, что он верный. - Ночные многошаговые прогоны — по паттерну resume, не restart; закладывать 2-3 внутренних цикла критики за ночь, не одну попытку.

Направление 3 (MVP-фабрика): - Веер должен быть explorer×critic с явно РАЗНЫМИ приоритетами для каждого варианта, не N одинаковых прогонов. - Судейство — турнир на выбывание с разнородными судьями, не попарное сравнение всех со всеми одним судьёй. - Intake болей клиента — через структурированное интервью (использовать существующий client-interviewer), а не свободный пересказ. - Продавать нужно не «готовый продукт за ночь», а «убедительное демо + вход в оплачиваемую фазу доработки» — реалистичная граница 70%-проблемы.

Сквозное: единая Collaboration Plane (веб-панель/Telegram) + один orchestrator с Handoff между тремя направлениями + общий knowledge graph памяти — это то, что превращает три отдельных «завода» в одну операционную систему, а не в три параллельных проекта, которые Лучиану придётся клеить руками.

7. Карта: какой сервис завода становится «органом» какого направления

Полезно явно провести мост между текущей инфраструктурой (_HERMES_HANDOFF/03-services) и тремя целевыми направлениями — это снижает риск строить «с нуля» то, что уже наполовину существует.

Существующий сервис Роль сейчас Роль в целевой системе
channel-hq Оркестрация видео-конвейера, SEO, upload Прообраз общего orchestrator/Handoff-диспетчера всех трёх направлений — уже умеет ставить задачи в очередь и вести стадии
memory-bank (3 банка) Память завода (global/per-channel/per-generator) Ядро единого knowledge graph — по структуре типологии памяти (episodic/semantic/procedural) переносится на строитель приложений и MVP-фабрику почти без переделки схемы
resource-governor Честная раздача пулов FastGen/render/brain/voice Универсальный брокер ресурсов — тот же принцип нужен, когда параллельно крутятся контент-генерация, ночная сборка приложения и веер MVP-прототипов, деля один и тот же бюджет токенов/GPU
thumbnail-studio (Haiku vision QC) Визуальный QC обложек Прямой шаблон для visual-verification строителя приложений (скриншот UI вместо обложки, тот же принцип vision-критика)
client-interviewer Сайд-проект, сбор требований клиента Готовый intake-слой для консультант-фабрики MVP — структурированное превращение болей бизнеса в ТЗ
x-research-daily Разведка X.com, дайджест в Telegram Прямой прототип для «агента-разведчика возможностей» — тот же паттерн (периодический скан + дайджест), только источники и критерии другие
orchestrator.mjs (выключен) Опциональный дирижёр стадий видео После добавления Critic-агента и снятия ручных гейтов — становится ядром автономии направления 1, шаблоном для аналогичных дирижёров направлений 2 и 3

Источники (корпус, не точные сноски)

Синтез поверх всех analysis-файлов (§1–§7 каждого) плюс:

Документ — сводная проекция теории на завод Лучиана, не отчёт по конкретным источникам; см. source-блоки отдельных analysis-файлов (orkestratsiya.md, osnovy.md, pamyat.md, realnye-keysy.md, avtonomnaya-razrabotka.md) для дословных цитат по темам.

Вывод из таблицы: у Лучиана нет задачи «построить универсального строителя и MVP-фабрику с нуля» — есть задача обобщить уже работающие паттерны завода (оркестрация стадий, трёхуровневая память, resource governor, vision-QC, intake) на новые типы артефактов (код вместо видео, прототип вместо ролика). Это резко снижает объём новой разработки и риск архитектурных ошибок, потому что каждый паттерн уже боевые протестирован на реальном производстве, а не выдуман заново.