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/app, or adding missing package management, linting, formatting, typechecking, testing, coverage, or CI. ## When NOT to Use - Adding a feature to an already healthy project; use the domain skill plus `proof`. - Release pipeline beyond baseline CI; use `release`. - Detailed UI design choices after the framework is chosen; use `ui-design`. ## Core Ideas 1. The user owns scaffold choices. The agent recommends options in priority order, then waits for approval before creating files, installing packages, or running generators. If a structural dependency is not already specified, ask before researching or selecting it. 2. Scaffolding creates the baseline, not the feature. Decide project kind, language/runtime, deployment assumption, framework/template, quality baseline, files, and commands before feature code. 3. Named artifacts are literal requirements. Create requested files such as `tsconfig.json`, `package.json`, `pyproject.toml`, CI, or README unless the user approves a substitute. 4. Commands are part of the contract. Standardize `test`, `lint`, `format`, `typecheck`, and `coverage` where applicable; CI should run the same checks developers run locally. 5. `typecheck` must run a type checker