bootstraplisted

# bootstrap — runtime scaffold > **bootstrap or onboard?** One question: **is there a runtime to scaffold?** > No runtime yet → `bootstrap`; it scaffolds one and ends by calling > `spark setup`. Runtime already present → [`onboard`](../onboard/SKILL.md). > `spark orient` prints the answer under **Next**. `bootstrap` stands up a project's runtime by running the stack's **official scaffolder** with the right flags — it does not hand-roll a directory tree. A scaffold is an implementation artifact: it **materializes a design already accepted in `plan`** (the model → shape → design order), never discovers one — when the required choices are unresolved, route back to `plan` instead of guessing a stack. The runtime/package-manager defaults are fixed; only the framework on top is a choice. - **TypeScript / JavaScript → Bun** (runtime + package manager + test runner). - **Python → uv** (runtime/version + dependency + project manager). Concrete per-framework commands and quality-gate defaults live in [references/profiles.md](references/profiles.md). ## Do this 1. **Orient first, then decide the shape.** Before scaffolding anything, run `spark orient` and read its **Next** line. bootstrap is the *no-runtime yet* path: proceed only on a `new` verdict, or on an `ambiguous` one a human explicitly resolves. An `existing` verdict means **stop** — discover the repo's conventions instead of scaffolding over them. Confirm the verdict now but *record* it (`spark orient --set