scaffoldinglisted

# Scaffolding ## Iron Law `NO FEATURE CODE BEFORE THE TOOLCHAIN PROVES IT CAN FAIL AND PASS.` A scaffold is done only when a clean clone can install, check, test, and run the baseline without local knowledge. ## When to Use - Starting a new repo or app, or adding missing package management, linting, formatting, typechecking, testing, coverage, or CI. ## When NOT to Use - Adding a feature to a healthy project; use the domain skill plus `proof`. - Release pipeline beyond baseline CI; use `release`. - UI design choices after the framework is chosen; use `ui-design`. ## Rules 1. The user owns scaffold choices. Before creating files, installing packages, or running generators, present a Scaffold Decision Gate (project intent and kind, language/runtime, deployment assumption, framework/template, quality baseline, files and commands) with this menu, and wait: 1. Approve: create files, install packages, run generators 2. Refine: change the scaffold plan 3. Cancel: stop scaffolding 2. Research is free. Audit candidate dependencies without asking, then get approval before selecting or installing a structural runtime dependency (framework, database, ORM, auth client, SDK, state library, job queue), unless the user or the selected stack already named it. 3. Recommend one option per choice in priority order (language/runtime, deployment assumption, framework/template, framework-local choices) and name the tradeoff. Fresh web apps default to a ma