Как выбрать стек — или дать движку поднять его с нуля (stack-aware)

Что это

Stack-aware setup — это слой движка, который отвечает на первый вопрос новичка: «а какой вообще стек брать и что ставить?». Идея простая: движку не нужно спрашивать вас об этом заранее. На установке он сам смотрит на папку, в которую его поставили, и выбирает одну из двух дорог:

• Brownfield (проект уже есть) — движок находит манифесты (package.json, pyproject.toml, go.mod, Cargo.toml, *.csproj, Gemfile), понимает ваш стек и подстраивается: переписывает glob-паттерны правил под ваши файлы, ставит verify-команды под ваш инструментарий (tsc/eslint/test, ruff/pytest, go vet/test), выбирает подходящие MCP-серверы.
• Greenfield (пустая папка) — движок рекомендует стек под вашу цель, выдаёт команды установки (не curl | bash вслепую новичку, а объяснимые шаги), скаффолдит скелет и прогоняет verify-гейт — то есть проверяет, что собранный с нуля проект реально запускается, а не «вроде готово».

Почему это важно

Без этого слоя вы получаете либо агента, который дублирует чужой стек в вашем репозитории, либо новичка, который час гуглит «а что вообще ставить под CRM». Stack-aware снимает обе боли: опытному — не навязывает, новичку — не бросает.

Когда применять

Всегда — это встроенный слой любого движка. Осознанно думать о нём стоит в двух точках: когда ставите движок в уже большой репозиторий (проверьте, что он корректно определил ваш стек) и когда стартуете с нуля (движок предложит стек — вы утверждаете или меняете).

Честная оговорка (важно)

Решение detect-vs-bootstrap принимает целевой AI на установке, читая литеральные OS-aware инструкции и проб-сниппеты, которые движок зашил в пакет (варианты под POSIX и PowerShell, честный детект прокси/отсутствия прав/оффлайна). Это не серверный рантайм, который сам сканирует диск. Более того, сам под-слой setup.provision в схеме сейчас — roadmap-задача P0: верхнеуровневая zod-схема сегодня молча отбрасывает неизвестные ключи, поэтому provision нужно сначала сделать первоклассным полем (или включить passthrough) + добавить round-trip-тест. Первоклассным полем уже является только setup.architectureDoc (живая карта архитектуры) и базовые folders/files/access/checklist. То есть логика описана и валидна как замысел, но чтобы она доезжала в пакет без потерь, нужна промоция схемы. Помечаем честно: provision-слой — в разработке.

Worked-пример

Вход: вы купили Quest и ставите его в существующий Node-монорепо, где лежит package.json с React + Vite и tsconfig.json.

Что делает движок (по инструкции, которую исполняет ваш Claude Code / Cursor):

1. PHASE -1 — пробит окружение: ОС, шелл, сеть; честно отмечает, что вы не оффлайн и админ-права есть.
2. Находит package.json → значит brownfield, режим onDetect: adapt.
3. Переписывает glob'ы правила tenancy с общего **/*.{ts,py,go} на ваш реальный layout серверного кода.
4. Ставит verify-команды под node: typecheck → lint → test — именно они будут гоняться после каждого шага.
5. НЕ трогает то, чего не понял: маркеры монорепо повышают уверенность, но не являются жёстким гейтом.

Результат: движок готов к работе в вашем стеке без единого вопроса «какой фреймворк?». Правила и проверки уже говорят на языке вашего проекта.

Контраст — greenfield. Вход: пустая папка, цель «хочу простое SaaS с формами». Движок рекомендует стек (например, тот же React+Vite+TS+Postgres, потому что он в его рецептах-StackRecipe), выдаёт команды установки по шагам, скаффолдит, запускает verify и говорит «готово» только когда проверка зелёная — с rollback/resume, если что-то упало на полпути. Anti-YOLO по умолчанию: терминал — askEveryTime, необратимое — require-confirm.

Итого: brownfield = подстроиться, greenfield = поднять с нуля и доказать, что живо. Решает целевой AI по зашитому рецепту; enforced-гарантий тут нет — это качественная детерминированная инструкция, а provision-слой схемы дозревает в roadmap.