How to Pick a Stack — or Let the Engine Stand One Up (Stack-Aware Setup)

In short

Stack-aware setup answers the beginner's first question, "which stack should I even use?" — and the engine doesn't need to ask you up front: at install time it looks at the folder itself. If a project already exists (brownfield), it finds the manifests (package.json, pyproject.toml, go.mod and others), reads your stack and adapts: it rewrites the glob patterns in the rules, sets verify commands matching your toolchain, and picks the right MCP servers. If the folder is empty (greenfield), it recommends a stack for your goal, gives you explainable install commands instead of a blind curl | bash, scaffolds a skeleton and runs a verify gate: it checks that the assembled project actually starts. Below: when this layer applies and where its honest limits are.

What it is

Stack-aware setup is the engine layer that answers the beginner's first question: "which stack do I take and what do I install?" The idea is simple: the engine doesn't need to ask you in advance. At install time it looks at the folder it was dropped into and picks one of two roads:

Stack-aware install: detect → adapt or bootstrap → verify

Brownfield (a project already exists) — the engine finds the manifests (package.json, pyproject.toml, go.mod, Cargo.toml, *.csproj, Gemfile), reads your stack and adapts: it rewrites the rules' glob patterns to match your files, sets verify commands for your toolchain (tsc/eslint/test, ruff/pytest, go vet/test), and picks suitable MCP servers.
Greenfield (an empty folder) — the engine recommends a stack for your goal, hands you install commands (not a blind curl | bash thrown at a beginner, but explainable steps), scaffolds a skeleton and runs a verify gate — meaning it checks that the from-scratch project genuinely starts rather than "looks done".

The two roads of stack-aware setup: what the engine actually does

Brownfield — a project already exists

→ finds the manifests (package.json, pyproject.toml, go.mod…)

→ rewrites the rules' glob patterns to match your files

→ sets verify commands for your toolchain

→ picks suitable MCP servers

Result: it adapts and imposes nothing

Greenfield — an empty folder

→ recommends a stack for your goal

→ gives explainable install commands (no blind curl | bash)

→ scaffolds the project skeleton

→ runs the verify gate: "done" only when the check is green

Result: it stands the project up and proves it's alive

The decision is made by the target AI at install time, following the recipe baked into the engine

Why this matters

Without this layer you get either an agent that clones somebody else's stack into your repository, or a beginner spending an hour googling "what do I install for a CRM". Stack-aware setup removes both pains: it doesn't impose on the experienced, and it doesn't abandon the newcomer.

When to use it

Always — it's a built-in layer of every engine. It's worth thinking about consciously at two moments: when you install the engine into an already large repository (check that it detected your stack correctly), and when you start from scratch (the engine proposes a stack — you approve or change it).

An honest caveat (important)

The detect-vs-bootstrap decision is made by the target AI at install time, reading the literal OS-aware instructions and probe snippets the engine baked into the package (POSIX and PowerShell variants, honest detection of a proxy, missing permissions or being offline). This is not a server-side runtime that scans your disk on its own. What's more, the setup.provision sub-layer in the schema is currently a P0 roadmap item: today the top-level zod schema silently drops unknown keys, so provision first has to become a first-class field (or passthrough has to be enabled), plus a round-trip test added. The only first-class fields so far are setup.architectureDoc (the living architecture map) and the basic folders/files/access/checklist. In other words, the logic is described and sound as a design, but for it to reach the package without losses the schema needs to be promoted. Stated plainly: the provision layer is in development.

A worked example

Input: you've bought Quest and are installing it into an existing Node monorepo that contains a package.json with React + Vite and a tsconfig.json.

What the engine does (per the instructions your Claude Code / Cursor executes):

PHASE -1 — probes the environment: OS, shell, network; honestly notes that you're not offline and that admin rights are available.
Finds package.json → so it's brownfield, mode onDetect: adapt.
Rewrites the globs of the tenancy rule from the generic **/*.{ts,py,go} to your real server-code layout.
Sets node verify commands: typecheck → lint → test — exactly what will run after every step.
Does NOT touch what it didn't understand: monorepo markers raise confidence but are not a hard gate.

Result: the engine is ready to work in your stack without a single "which framework?" question. The rules and checks already speak your project's language.

The contrast — greenfield. Input: an empty folder, goal "I want a simple SaaS with forms". The engine recommends a stack (say, the same React+Vite+TS+Postgres, because it's among its StackRecipe recipes), gives install commands step by step, scaffolds, runs verify, and says "done" only when the check is green — with rollback/resume if something failed halfway. Anti-YOLO by default: the terminal is askEveryTime, anything irreversible is require-confirm.

In sum: brownfield = adapt, greenfield = stand it up and prove it's alive. The target AI decides, following the baked-in recipe; there are no enforced guarantees here — it's a solid deterministic instruction, and the schema's provision layer is still maturing on the roadmap.