Developer Mode vs Store

1. Введение

В предыдущих лекциях мы уже поговорили о том, что такое ChatGPT App, из каких слоёв он состоит и чем он отличается от старых плагинов и просто ботов на OpenAI API. Теперь перейдём ко второй важной теме — жизненному циклу такого приложения.

Если вы хотя бы несколько лет пишете веб-сервисы, то слово «lifecycle» вас не пугает. У любого продукта есть свой примитивный путь: «написали локально → выкатили на staging → выкатили на production → иногда всё сломали → починили». В экосистеме ChatGPT с App всё то же самое, но есть нюансы: появляется Dev Mode внутри самого ChatGPT и отдельная сущность — Store.

Важно чётко отделять две плоскости:

1. Где живёт ваш код физически: локальный Next.js сервер, Vercel, какой-нибудь Kubernetes-кластер и так далее. Это ваш мир, вы там царь и бог.
2. Как ChatGPT видит ваш App: как набор метаданных, URL и пермишенов, которые можно либо подключить в Developer Mode, либо оформить как готовый продукт в Store. Это уже мир OpenAI, со своими правилами, ревью и пользователями.

Эта лекция как раз про вторую плоскость. Мы будем опираться на вашу привычную модель окружений (dev / staging / prod), но смотреть на неё глазами ChatGPT. Наша цель — чтобы вы в любой момент могли ответить себе на несколько вопросов. Какой именно код сейчас запускает мой App? Кто его видит? Как безопасно экспериментировать? И что вообще означает «обновить App» в Store?

2. Developer Mode: личная песочница внутри ChatGPT

Начнём с самого приятного для разработчика: с песочницы, где можно всё сломать и почти никого этим не травмировать.

Developer Mode — это специальный режим в ChatGPT, в котором вы можете подключать свои ChatGPT Apps напрямую по URL, не проходя ревью, не публикуя App в Store и не показывая App всему миру. По духу это похоже на localhost:3000 в браузере, только в мире ChatGPT.

Как это выглядит концептуально

Проще всего представить схему так:

flowchart TD
    User("ChatGPT UI (Dev Mode)")
    AppConfig["Dev-конфиг App (URL + метаданные)"]
    AppServer["Ваш App-сервер (Next.js + Apps SDK)"]

    User -->|запрос в чате| ChatGPTCore[GPT]
    ChatGPTCore -->|нужно App| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/инструменты| ChatGPTCore
    ChatGPTCore --> User

Вы, как разработчик, в настройках Developer Mode говорите ChatGPT: «Вот мой App, вот его URL, вот как он называется и что умеет». ChatGPT начинает считать этот URL источником вашего приложения. Пока вы не подали App в Store, видеть его будете только вы (и, возможно, другие члены вашей команды, если вы их добавите как разработчиков).

Технические детали подключения (HTTPS-туннель, Vercel и прочие радости) мы разберём дальше. Здесь главное понять идею: Dev Mode — это такой «динамический ярлык» на ваш dev-сервер, который ChatGPT умеет вызывать.

Как включить Developer Mode

Чтобы у вас появилась возможность «подцепить» свой локальный сервер к интерфейсу ChatGPT, нужно активировать соответствующий переключатель в настройках.

• Перейдите по ссылке https://chatgpt.com/#settings/Connectors/Advanced или зайдите в Settings -> Connected apps -> Advanced.
• Developer Mode - ON

Как только вы это сделаете, у вас появится кнопка Create App.

Чем Dev Mode отличается от production

Разница очень похожа на отличие dev-окружения от production в обычном вебе, но есть несколько специфичных моментов.

Во‑первых, видимость. Ваш App в Dev Mode, как правило, недоступен обычным пользователям ChatGPT. Его видят только вы и, возможно, члены вашей организации с соответствующими правами. Можно экспериментировать, не боясь, что случайный человек наткнётся на полусломанный UX.

Во‑вторых, стабильность и эксперименты. В Dev Mode вы можете менять код хоть каждые две минуты, поднимать локальный сервер, убивать его, перезапускать туннель. ChatGPT будет стараться ходить по указанному URL, но не будет обижаться, если вы иногда возвращаете 500 или вообще не отвечаете — для этого это и dev.

В‑третьих, пермишены и политика. В Dev Mode вам проще пробовать разные конфигурации. Но важно помнить, что политики контента и базовой безопасности не отключаются даже в dev-режиме: ChatGPT не позволит вам внезапно превратиться в «хакерский App для всего». Однако рамки ревью Store здесь пока не включаются: можно не иметь идеального листинга, красивого логотипа и т.п.

И наконец, в Dev Mode обычно проще диагностировать проблемные места. Вы можете быстро менять логику, смотреть, какие запросы идут от ChatGPT к вашему серверу, и корректировать поведение, не думая о «миграции пользователей».

Мы уже посмотрели на Dev Mode как на личную песочницу для приложений и слегка заглянули в сторону Store. Давайте теперь оформим всё это в понятную «машину состояний» жизненного цикла App.

3. Состояния ChatGPT App: от черновика до снятия с публикации

Теперь давайте оформим это в понятную «машину состояний» для вашего App. Мы условно поговорим о четырёх основных состояниях: Draft / Dev-only, Under review, Published и Paused/Removed.

Машина состояний жизненного цикла

Попробуем нарисовать это как диаграмму:

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / черновик
    Review: Under review (Store)
    Published: В Store, доступен пользователям
    Paused: Paused / Removed

    Draft --> Review: Отправить на ревью
    Review --> Draft: Отклонено / вернуть на доработку
    Review --> Published: Одобрено
    Published --> Paused: Поставить на паузу / снять
    Paused --> Draft: Возобновить работу в dev-режиме
    Draft --> Published: Внутренний rollout без Store (для организации)

В состоянии Draft ваш App существует только как dev-ресурс. Вы можете подключить его в Developer Mode, пробовать разные фичи, но не светить его в Store.

Когда вы решаете, что App пора показывать людям, вы отправляете его «на ревью» — это состояние Under review. В нём OpenAI (или внутренняя система ревью для вашей организации) проверяет соответствие политикам, стабильность, базовую безопасность и адекватность UX.

Если всё хорошо, App попадает в Published: он появляется в Store или становится доступным для пользователей вашей компании (если это корпоративный сценарий). С этого момента к нему начинают приходить реальные пользователи, и всё, что вы делаете с кодом и конфигурацией, нужно планировать аккуратнее.

Если же вы временно не хотите, чтобы App был доступен, его можно перевести в состояние Paused/Removed. В состоянии Paused он скрыт от новых пользователей, но может продолжать работать для уже начатых сессий или вообще отключаться — детали зависят от платформенной реализации и настроек.

4. Store: когда ваш App становится продуктом

Developer Mode — это ваш личный гараж. Store — это уже официальный дилерский центр. Здесь в игру вступают пользователи, рейтинг, правила листинга и ревью.

Что меняется, когда вы идёте в Store

Первое и главное: ваш App становится «продуктом». У него появляется листинг: название, описание, иконка, категории, иногда стартовые подсказки для диалога. По этим метаданным ChatGPT Store будет искать и рекомендовать ваше приложение пользователям, а сама модель — понимать, в каких сценариях App релевантен.

Вторая важная вещь — ревью и политика. Прежде чем App появится в Store, его проверят на соответствие требованиям безопасности, содержимого и UX. Это значит, что:

• нельзя втихаря собирать лишние персональные данные;
• нельзя обещать то, чего App не делает;
• нельзя вылезать за рамки допустимых категорий контента.

Мы ещё подробно поговорим о политике и песочнице в следующих лекциях, но уже сейчас полезно воспринимать Store как место, куда вы приносите только относительно «воспитанные» версии своего App.

Третья вещь — ответственность за стабильность. Пока вы играете в Dev Mode, ваши падения — ваша проблема. В Store от вашего App ожидают адекватной доступности, разумной латентности и отсутствия «красных экранов смерти» в виджете. В более поздних модулях мы будем говорить про SLO, метрики и ревью Store именно в этом контексте.

Версии: dev против production

Типичный вопрос: «Если я обновлю код, что увидит пользователь?». В мире ChatGPT Apps полезно думать о двух «ветках» одновременно:

• dev-ветка, которая подключена к Developer Mode и может указывать на dev-сервер, соседний с вашим IDE;
• production-ветка, которая ассоциирована с опубликованной конфигурацией в Store и указывает на стабильный URL.

С точки зрения архитектуры это можно выразить даже с помощью небольшого TypeScript-типа в вашем проекте:

type AppStage = 'dev' | 'production';

interface ChatGPTAppConfig {
  id: string;
  stage: AppStage;
  endpointUrl: string;
}

const giftGeniusDev: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'dev',
  endpointUrl: 'https://dev.giftgenius.example.com',
};

const giftGeniusProd: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'production',
  endpointUrl: 'https://app.giftgenius.example.com',
};

В реальной жизни конфигурацию хранит не ваш код, а платформа ChatGPT, но подобные структуры помогают держать в голове, что это два разных «образа» одного и того же App.

Релиз ChatGPT App больше похож на решиз прложения в Apple App Store, чем на апдейт сайта. Ваши виджеты и mcp-tools каждый раз кешируются при релизе приложения. А review может занимать 2 недели. Так что никаких «выкатим в production, и там дотестим». Вы должны отдавать на review уже полностью протестированное и стабильное приложение.

5. Организационный контекст: личный аккаунт vs компания

Мы уже разделили App на dev- и production-ветки и посмотрели, как это отражается в Store. Ещё одно важное измерение жизненного цикла — это «где» он живёт организационно.

В самом простом случае вы делаете App как частное лицо в своём личном ChatGPT Plus. Тогда Dev Mode — чисто ваш, Store — тоже под вашим аккаунтом. Всё относительно просто: сделали для себя, выложили, порадовали мир.

Но очень часто ChatGPT Apps живут в корпоративном контексте. Тогда появляется несколько дополнительных ролей. Есть админы организации, которые решают, какие Apps доступны сотрудникам, какие нужно заблокировать, какие можно использовать только пилотной группе. Ваш App может быть опубликован не для всего мира, а только для конкретной компании, или даже для конкретных отделов внутри неё.

В таком сценарии жизненный цикл может выглядеть так: сначала App существует только как dev-проект внутри команды, потом появляется «внутреннее production» — доступно, к примеру, только отделу продаж для пилота. Лишь потом, если всё пошло хорошо, вы решаете отправить App в глобальный Store, чтобы сделать его внешним продуктом.

Для архитектуры это важно потому, что вам нужно проектировать App так, чтобы он адекватно работал и как внутренний инструмент, и как публичный продукт. Иногда это означает наличие фич-флагов, режимов работы «только для своих» и отдельных настроек аутентификации.

6. Практический сценарий: жизненный цикл GiftGenius

Чтобы всё вышесказанное не осталось абстракцией, давайте посмотрим на условный App GiftGenius — помощник по подбору подарков, который будет сопровождать нас по курсу.

Этап 1. Идея и черновой прототип в Dev Mode

Вы решаете сделать GiftGenius: App, который спрашивает у пользователя, кому нужен подарок, на какой бюджет он рассчитывает и какие интересы у получателя, а затем предлагает варианты, используя ваш каталог товаров.

На первом шаге вы:

1. Поднимаете простой Next.js-проект с минимальным виджетом.
2. Включаете Developer Mode в ChatGPT и добавляете туда URL своего dev-сервера.
3. Проводите несколько тестовых диалогов: просите GPT «Помоги выбрать подарок другу-геймеру до 50$» и смотрите, как он вызывает ваш App, рендерит виджет, как выглядит UX.

На этом этапе вы не думаете о Store, ревью, красивых иконках. Ваша задача — доказать себе и команде, что идея вообще работает и что платформа ChatGPT позволяет реализовать нужный сценарий.

Этап 2. Укрепление прототипа и внутренняя «альфа»

Когда вы убедились, что базовый сценарий рабочий, начинается этап «укрепления». Вы:

• приводите логику к более-менее понятной структуре;
• начинаете думать о том, какие пермишены и данные реально нужны App;
• проверяете, как App ведёт себя при ошибках (например, когда каталог товаров не отвечает).

Всё ещё в Dev Mode, но уже не в одиночку: вы добавляете коллег как разработчиков или тестировщиков, чтобы они тоже могли подключить App к своему ChatGPT. Жизненный цикл на этом этапе всё ещё крутится вокруг состояния Draft: вы быстро обновляете код, пробуете разные UX-паттерны, обсуждаете фидбэк внутри команды.

Этап 3. Подготовка к Store и ревью

На этом шаге вы решаете: «Да, GiftGenius уже достаточно приличный, чтобы показать его внешним пользователям». Теперь фокус смещается с кода на продуктовую упаковку:

• пишете честное и понятное описание App;
• настраиваете пермишены: объясняете, к каким данным App обращается и зачем;
• убеждаетесь, что UX не вводит в заблуждение и что App не обещает невозможного.

Это момент перехода из Draft в Under review. Вы отправляете App на ревью, и какое-то время он живёт в этом промежуточном состоянии. Возможно, вам придут замечания: нужно уточнить политику конфиденциальности, поправить формулировки, сузить пермишены. Вы возвращаетесь в Draft, дорабатываете, снова отправляете.

Этап 4. Публикация и «настоящая жизнь»

После одобрения ваш GiftGenius оказывается в состоянии Published. Теперь его могут находить пользователи в Store, ChatGPT может предлагать его по релевантным запросам, а вы начинаете собирать реальный фидбэк, смотреть на использование и думать о масштабировании.

Теперь каждое изменение кода — это не просто «ой, я сейчас быстро допилю функцию». Это мини‑релиз. Вам нужно думать про backward compatibility, продумывать миграции, по возможности менять сначала dev-версию, проверять её, и только потом обновлять production-конфигурацию.

При необходимости вы можете временно увести App в Paused, если, например, нашли критическую уязвимость или ваш backend не справляется с нагрузкой. Но идеальная картина — постепенно развивать Published-ветку, не забывая про dev-среду для экспериментов.

7. Как разработчику думать об окружениях: dev, staging, production + Dev Mode

На примере GiftGenius мы прошли путь от идеи в Dev Mode до опубликованного App. Теперь давайте уложим это в привычную для разработчика схему окружений — dev/staging/production — и посмотрим, как она соотносится с Dev Mode и Store.

Чаще всего в голове удобно держать такую матрицу:

Developer Mode, по сути, приклеивается к вашей dev- или staging-инфраструктуре: вы публикуете туда временный URL, который ChatGPT использует для тестов. Конфиг Store при этом указывает на уже взрослый production-URL.

В будущем, когда мы будем говорить о деплое на Vercel и туннелях, эта матрица превратится в набор вполне конкретных шагов. Но уже сейчас полезно держать простую идею: всегда отдавайте себе отчёт, где находится текущий запрос ChatGPT — в вашей dev-песочнице или в боевом окружении, куда ходят пользователи.

8. Небольшой «кусочек кода» про жизненный цикл

Чтобы связать всё это с привычным для вас TypeScript-подходом, давайте напишем простой тип, который отражает жизненный цикл App уже не на уровне платформы, а на уровне вашего собственного tooling’а. Его можно положить в репозиторий, чтобы не забывать о разных состояниях.

type AppLifecycleState = 'draft' | 'under_review' | 'published' | 'paused';

interface LifecycleSnapshot {
  id: string;
  name: string;
  state: AppLifecycleState;
  lastDeployedAt: Date | null;
  devUrl?: string;
  prodUrl?: string;
}

const giftGeniusLifecycle: LifecycleSnapshot = {
  id: 'giftgenius',
  name: 'GiftGenius – подбор подарков',
  state: 'draft',
  lastDeployedAt: null,
  devUrl: 'https://dev.giftgenius.example.com',
};

Такой объект вы никогда не отправите в ChatGPT, но он помогает команде быть в одном контексте. Можно даже сделать простенький CLI, который показывает состояние всех ваших Apps, чтобы не путаться, где черновик, а где уже что-то, находящееся в Store.

В следующих модулях мы будем постоянно возвращаться к этой модели жизненного цикла: когда будем настраивать туннели и деплой на Vercel, проектировать MCP‑сервер и агентные сценарии, продумывать commerce‑флоу и подготовку к ревью в Store. Думайте о Dev Mode и Store как о двух полюсах одной системы: песочнице для экспериментов и витрине для уже взрослого продукта.

9. Типичные ошибки при работе с Dev Mode и Store

Ошибка №1: «Сразу в Store, а там разберёмся».
Иногда хочется как можно быстрее «захватить рынок» и выложить App в Store ещё на стадии полурабочего прототипа. Это почти гарантированно приводит к негативным отзывам пользователей, плохой статистике использования и дополнительным вопросам на ревью. Куда здоровее сперва прожить несколько итераций в Developer Mode, собрать фидбэк от коллег и друзей, стабилизировать базовый UX и только потом идти в Store.

Ошибка №2: Смешивание dev и production-сред.
Типичный сценарий: вы настраиваете Dev Mode на тот же URL, что и production, а потом удивляетесь, почему «пара отладочных изменений» внезапно увидели реальные пользователи. Разводить dev- и prod-URLs нужно так же аккуратно, как вы это делаете для обычных веб-сервисов. Если в конфиге ChatGPT App стоит production-URL — не используйте его для «быстрых экспериментов по вечерам».

Ошибка №3: Отсутствие внятного представления о состояниях.
Когда разработчики не осознают, в каком состоянии живёт App (Draft, Under review, Published, Paused), возникают странные ситуации: кто-то в команде думает, что App уже в Store, другой всё ещё считает его локальным прототипом. Стоит хотя бы в README проекта описать, где сейчас App, и что нужно сделать для перехода на следующий этап.

Ошибка №4: Игнорирование политики и ревью до последнего момента.
Некоторые команды пишут App «как будто это просто сайт», а про политику, пермишены и требования Store вспоминают за день до отправки на ревью. В результате оказывается, что нужно серьёзно перепиливать сбор и хранение данных, переписывать описания и сужать права. Лучше держать в голове рамки с самого начала и в Dev Mode сразу экспериментировать с честными, минимальными пермишенами.

Ошибка №5: Отсутствие отдельной стратегии для внутреннего и внешнего использования.
Если App изначально создаётся как внутренний корпоративный инструмент, а потом хочется сделать из него публичный продукт, легко перепутать целевую аудиторию. Внутри компании можно позволить себе менее «глянцевый» UX и более сложные сценарии, во внешнем Store пользователи ожидают другого уровня удобства. Непонимание, в каком режиме вы находитесь сейчас, приводит к тому, что публичный App выглядит как внутренний админский тул, а внутренний пилот застревает, потому что вы слишком рано думаете о глобальном Store.

Ошибка №6: Отсутствие связки между Dev Mode и наблюдаемостью.
Developer Mode отлично подходит для отладки, но этим преимуществом нужно пользоваться. Если вы не смотрите на логи и не фиксируете, какие именно запросы ChatGPT шлёт в ваш App в dev-среде, то позже, на production, вас могут ждать неприятные сюрпризы. Лучше использовать Dev Mode как площадку для изучения настоящего поведения модели и пользователей, а не только для проверки «что виджет компилируется».