design-init

# design-init ## Language Rule Follow an explicit artifact or audience language when provided. Otherwise, write inventory, environment reports, and user-facing guidance in the conversation language according to `<agent-home>/roles/response-policy.md`. Preserve commands, paths, native tool IDs, package names, and state-schema values. ## Pre-Check Look for `design_state.yaml` under `<artifact-root>/designs/<name>/` or `<artifact-root>/spec/design/`. - If present, stop and report that initialization already exists; recommend the owning new-cycle or resume path rather than deleting the folder automatically. - If absent, continue. ## Procedure ### Step 1: Resolve the Design Name Use the explicit user input or the app name supplied by `autopilot-spec`. Ask one concise question only when the name materially affects artifact resolution and remains ambiguous. ### Step 2: Bootstrap Rendered Verification The components, tokens, and review stages require rendered evidence. Inspect the active adapter's visual harness and local renderers first, then provision only missing, in-scope dependencies. Do not abandon the design solely because one preferred harness is absent; use a proven static fallback when live preview cannot be attached. Stop only for an actual permission, network, safety, or tool-contract blocker. Prefer project-local or harness-local packages. Before installing an OS-global package such as `apt install librsvg2-bin`, tell the user what will change. Follow the acti...