Выбор стека

После модуля 7 у Бориса уже есть docs/design.md. Внутри — первый сценарий JobTrack: что происходит с карточкой вакансии, какие статусы, какой следующий шаг, что уходит в список не сейчас. Дизайн есть. Осталось выбрать, на чём это делать.

Борис открывает агента и хочет спросить:

Какой стек лучше?

Плохой вопрос.

Один агент уверенно скажет Next.js. Уверенно скажет SvelteKit. Уверенно — Supabase. А ещё один вообще предложит начать с localStorage. И каждый подаст свой вариант так, будто других на свете нет.

Никто из них не врёт. В своих условиях зайдёт любой — и Next, и Svelte, и тот же localStorage. Дело в вопросе.

какой стек лучше — ленивый запрос: прячет критерии выбора и заставляет агента гадать, что тебе важнее. И это не безобидно — на голом вопросе модель уверенно несёт чушь. Что важнее: быстрый локальный старт, публичное демо — ну то есть кинуть ссылку и показать, нормальная база, цена хостинга, синхронизация потом? Агент не знает — и берёт первое, что звучит солидно.

А JobTrack не про модный стек. Ему нужен тот, что не утащит первый MVP в auth, деплой и миграции — и оставит дорогу к показу продукта потом.

Короче, дело не в стеке. Борис завис между критериями, которые сам ещё не назвал. Пока не назовёт — выбирает по логотипу.

После brainstorming у тебя уже есть design draft: что делает MVP, какие продуктовые решения приняты, что не входит в первый релиз.

Дальше — стек.

Эта работа — фаза stack-selection в SPP.

SPP держит память о проекте в docs/spp/pipeline-state.md: что за продукт, что уже сделано, какие решения приняты. Поэтому работу можно прервать и продолжить в новой сессии.

Этот этап проще перепрыгнуть, чем сделать. Не перепрыгивай: агент без стека выберет его сам. Я один раз так словил полный фулстек с авторизацией на проект, где кроме меня не было ни одного пользователя. Агент выбрал уверенно. Мимо продукта.

Например, для JobTrack это может выглядеть так:

Создам Next.js-приложение, подключу Supabase, Prisma,
авторизацию, dashboard и деплой на Vercel.

А в docs/design.md написано совсем другое: в первом MVP нет аккаунтов, нет dashboard, нет внешних пользователей. Нужен простой сценарий: вручную вести вакансии, статус и следующий шаг.

И тогда половина стека обслуживает не MVP, а фантазию агента.

Короче, стек нужен не для красоты. Он нужен, чтобы ограничить реализацию:

— где живёт frontend; — где хранятся данные; — нужен ли backend прямо сейчас; — как проект запускается локально; — насколько легко человеку и агенту чинить ошибки; — как потом показать MVP пользователю.

ОК: что делаем в этом модуле

Следующий модуль — это следующая фаза того же пайплайна, а не отдельный кусок, который внезапно прилетел из космоса.

В этом модуле мы выбираем, на чём собираем первый MVP.

Продуктовую логику не пишем. Домен и продакшен-инфраструктура — не сейчас. И точно не сравниваем все сервисы на свете: прямой путь в бесконечную табличку, где вариантов много, а решения нет.

Разобраться надо в пяти вещах: какие стеки вообще подходят под такой MVP, по каким критериям их сравнивать, что берём для первого проекта, как стартует локальная разработка и куда это потом деплоить.

Зачем выбирать стек до реализации

Почему стек — до спеки? Потому что часть спеки зависит от того, на чём ты собираешь.

Локальное хранение, управляемая база, только фронтенд или фулстек-фреймворк — каждый по-своему влияет на то, где живут состояния и данные, как сделать экспорт, как пересобрать всё с нуля и как потом показать demo.

Чем это отличается от дизайн-брейншторма

Дизайн-брейншторм ответил, что MVP должен делать. Стек отвечает, на чём это начать.

Если смешать эти этапы, стек начинает управлять продуктом. Например, выбрали BaaS — и внезапно появились аккаунты, роли и правила доступа, хотя первый MVP мог жить без авторизации.

Порядок один: discovery, потом design с продуктовыми решениями MVP, потом стек, и только за ним — спека, план, код.

Критерии MVP

Критерии простые. Восемь штук:

— локальный старт: как запустить проект на своём компьютере и увидеть первый экран; — простота: сколько движущихся частей до первой рабочей версии; — данные: где живут вакансии, статусы и следующий шаг; — путь к demo: как показать MVP другому человеку — локально, через preview URL или публичную ссылку; — Цена и лимиты: какие тарифы и ограничения проверить перед показом; — поддержка агентом: много ли примеров, docs и типовых ошибок, которые агент сможет чинить; — риск переделки: что придётся переписать, если станет понятно, что этим реально пользуются; — и отдельно «не сейчас»: какие возможности стека будут соблазнять раздуть MVP.

Критерии пишутся до выбора. Если сначала выбрать любимый стек, а потом подобрать аргументы — это самообман с табличкой.

Сначала узнай варианты стеков

Сначала разберись, какие стеки вообще бывают под такое.

Не проси сравнить 4 готовых стека, если сам не понимаешь, что это за стеки. Сначала попроси агента разложить варианты:

У меня есть MVP JobTrack и docs/design.md.
Код ещё не начат.

Объясни, какие варианты стеков вообще подходят для такого MVP.
Не выбирай сразу.

Для каждого варианта объясни:
- из каких частей он состоит;
- как выглядит локальная разработка;
- где хранятся данные;
- как потом показать MVP пользователю;
- что будет сложно для новичка;
- в каких случаях этот вариант не подходит.

Не пиши код.

Для JobTrack агент может предложить такие варианты:

— статический frontend с localStorage; — fullstack framework с локальной/файловой базой; — он же, но с управляемой базой; — frontend плюс BaaS; — отдельные frontend, backend и база.

Вот теперь выбирай, какие 3–4 варианта разбирать подробно.

Сравнение опирается на docs/discovery.md и docs/design.md.

Потом сравни и выбери

Дальше сравнение — второй prompt:

Теперь сравни варианты, которые подходят JobTrack.

Контекст:
- docs/discovery.md;
- docs/design.md;
- первый MVP: вручную вести вакансии, статус и следующий шаг;
- код ещё не начат.

Сравни 3-4 подходящих стека по критериям:
локальный старт, простота, данные, путь к demo, цена/лимиты,
поддержка агентом, риск переделки, соблазн раздуть MVP.

Не выбирай по популярности.
Сначала таблица сравнения, потом рекомендация.
Для цены и лимитов не выдумывай цифры: укажи, какие официальные страницы нужно проверить и когда.
Не пиши код.

Нормальный ответ сравнивает по критериям. Плохой — говорит: возьми Next.js, потому что современно.

Современно — это не критерий. Это наклейка на ноутбуке.

Как проверить решение

Получил рекомендацию — перепроверь её:

Проверь выбранный стек против docs/design.md.

Ищи:
- стек добавляет функции, которых нет в MVP;
- стек требует авторизацию, хотя она не нужна;
- данные можно потерять;
- локальный запуск слишком сложный;
- нет понятного пути к demo;
- цены/лимиты не проверены;
- решение принято по популярности, а не по критериям.

Не пиши код. Дай замечания и предложи правки в раздел docs/design.md.

Если агент не может объяснить, как стек помогает первому сценарию MVP, — значит, решение сырое.

Как записать решение

И записать это — в docs/design.md.

Не где-то в чате, не у себя в голове, не в великой памяти агента, которая сгорит при следующем контекстном пожаре. В документ.

Раздел может выглядеть так:

## Стек

Дата выбора: <YYYY-MM-DD>

Критерии:
- локальный старт:
- простота:
- данные:
- путь к demo:
- цена/лимиты:
- поддержка агентом:
- риск переделки:
- не сейчас:

Рассмотренные варианты:
| Вариант | Локальный старт | Данные | Путь к demo | Что хорошо | Что сложно | Решение |
|---|---|---|---|---|---|---|

Выбранный стек:
<короткое решение>

Почему выбран:
<2-4 причины, связанные с MVP>

Как начинается локальная разработка:
<что агент должен будет создать/запустить на следующем этапе>

Путь к будущему показу:
<локально сейчас; preview/public URL позже; домен пока не нужен>

Что проверить перед публичным показом:
- актуальные цены и лимиты;
- условия хранения данных;
- способ бэкапа/экспорта;
- ограничения free tier;
- подходит ли выбранный хостинг для этого стека.

Почему не альтернативы:
- <вариант>: <почему не сейчас>

На этом этапе не надо выбирать домен и финальный хостинг. В модуле 8 финальный хостинг не выбираем — первый деплой это модуль 15. Здесь фиксируем только направление: куда этот стек можно будет задеплоить потом.

Что делать с ценами, лимитами и хостингом

Но если стек завязан на облако, управляемую базу или BaaS — не пиши бесплатно или дёшево, пока не проверил. Запиши, что проверить перед показом:

— цены (pricing); — лимиты и квоты; — docs по деплою; — хранение и бэкапы; — экспорт данных; — ToS и DPA, если есть персональные данные.

Если у агента есть веб-поиск — проси ссылки на первоисточники и дату проверки. Если веб-поиска нет — записывай открытый пункт: проверить цены и лимиты перед публичным demo.

Практичный ориентир для JobTrack

Ориентир для JobTrack простой: первый стек нужен для одного — не как построить SaaS, а как быстро запустить локально первый сценарий.

Продукт только для себя — хватит простого локального варианта. Нужно показать 2–3 людям — закладывай путь к preview или public URL. А если данные чувствительные или долгоживущие, localStorage слишком хрупкий.

Главное одно: стек обслуживает первый сценарий. Всё сверх этого — лишняя платформа, которую потом тащить тебе.

В этом модуле ты выбираешь стек для первого MVP и записываешь решение в docs/design.md.

Цель — понять, на чём начнётся локальная разработка. Хостинг и домен пока не выбираем окончательно, но фиксируем, к чему выбранный стек должен привести. Стек тут не игрушка для самоутверждения, а способ довести первый сценарий до demo.

Шаг 1. Проверь входные документы

Перед выбором должны быть:

• docs/discovery.md;
• docs/design.md из модуля 7;
• в docs/design.md есть первый сценарий MVP и design-решения;
• код приложения ещё не начат.

Если docs/design.md пустой, вернись к модулю 7. Выбирать стек без design draft — это гадание по логотипам фреймворков.

Шаг 2. Запусти SPP workflow для выбора стека

Сначала попроси SPP определить рабочий процесс. Не проси сразу выбрать стек:

Используй /spp.

Мы на модуле 8. После brainstorming уже есть docs/discovery.md и docs/design.md с MVP и design-решениями. Код ещё не начат.

Нужно выбрать стек для первого MVP и локального старта:
- сначала объяснить варианты стеков;
- затем согласовать критерии выбора;
- затем сравнить 3-4 подходящих варианта;
- затем записать решение в docs/design.md;
- не писать код;
- не выбирать хостинг окончательно.

Для этого шага в SPP есть отдельный скилл stack-selection. Если агент его не видит, это проблема окружения: остановись, проверь установку SPP и не принимай подмену ручным workflow.

Шаг 3. Попроси агента объяснить варианты стеков

Сначала не проси выбрать. Попроси объяснить карту вариантов.

У меня есть MVP и docs/design.md.
Код ещё не начат.

Объясни, какие варианты стеков подходят для такого MVP.
Не выбирай сразу.

Для каждого варианта объясни:
- из каких частей он состоит;
- как выглядит локальная разработка;
- где хранятся данные;
- как потом показать MVP пользователю;
- что будет сложно для новичка;
- когда этот вариант не подходит.

Не пиши код.

Шаг 4. Запиши критерии MVP

Попроси агента предложить критерии для выбора именно твоего MVP:

На базе docs/discovery.md и docs/design.md предложи критерии выбора стека.

Обязательно учти:
- локальный старт;
- простоту;
- хранение данных;
- путь к demo;
- цены и лимиты, которые надо проверить позже;
- поддержку агентом;
- риск переделки;
- что может раздуть MVP.

Не выбирай стек, пока критерии не согласованы.

Шаг 5. Сравни подходящие варианты

Когда варианты и критерии понятны, попроси сравнить 3–4 подходящих стека:

Теперь сравни 3-4 подходящих стека для моего MVP.

Контекст:
- docs/discovery.md;
- docs/design.md;
- код ещё не начат.

Сравни по критериям:
локальный старт, простота, данные, путь к demo, цена/лимиты,
поддержка агентом, риск переделки, соблазн раздуть MVP.

Верни таблицу:
| Вариант | Локальный старт | Данные | Путь к demo | Что хорошо | Что сложно | Когда подходит |

Сначала таблица, потом рекомендация.
Для цены и лимитов не выдумывай цифры: напиши, какие официальные страницы нужно проверить и когда.
Не пиши код.

Если агент сразу выбирает стек без сравнения, останови:

Стоп. Не выбирай по вкусу.
Сначала объясни варианты, потом сравни по критериям MVP.

Шаг 6. Выбери стек и путь локального старта

После сравнения попроси решение:

На базе сравнения выбери стек для первого MVP.

Ответь:
1. какой стек берём;
2. почему он подходит первому сценарию;
3. как начнётся локальная разработка;
4. что будет хранить данные;
5. как позже показать MVP пользователю;
6. какие цены/лимиты/условия надо проверить перед публичным demo;
7. почему альтернативы не берём сейчас.

Код не пиши. Решение нужно для docs/design.md.

Шаг 7. Запиши раздел в docs/design.md

Добавь раздел:

## Стек

Дата выбора: <YYYY-MM-DD>

Критерии:
- локальный старт:
- простота:
- данные:
- путь к demo:
- цена/лимиты:
- поддержка агентом:
- риск переделки:
- не сейчас:

Рассмотренные варианты:
| Вариант | Локальный старт | Данные | Путь к demo | Что хорошо | Что сложно | Решение |
|---|---|---|---|---|---|---|

Выбранный стек:

Почему выбран:

Как начинается локальная разработка:

Путь к будущему показу:

Что проверить перед публичным показом:

Почему не альтернативы:

Шаг 8. Проведи review решения

Попроси агента проверить раздел:

Проведи review раздела Стек в docs/design.md против docs/discovery.md и docs/design.md.

Ищи:
- стек добавляет функции, которых нет в MVP;
- локальный старт не описан;
- данные можно потерять;
- путь к demo непонятен;
- цены/лимиты записаны без проверки;
- решение принято по популярности, а не по критериям.

Не пиши код. Предложи точечные правки текста.

Внеси правки после review.

Шаг 9. Попроси агента закоммитить документ

Когда раздел Стек готов, попроси агента сделать Git-шаг маленько:

Проверь git status.
Покажи diff по docs/design.md.
Если в diff только решение по стеку, подготовь docs/design.md к commit.
Покажи staged diff.
После моего подтверждения сделай commit с сообщением:
docs: выбрать стек первого MVP

Если в diff попали код, scaffold, зависимости или деплой, остановись. В этом модуле коммитится решение, а не приложение.