design-surfacelisted

Condensed binding of Part 5c of the edition committed in this repo. On any conflict, the edition text wins; load it with `bash "${CLAUDE_PLUGIN_ROOT}/scripts/part.sh" 5c`, or read Part 5c in the edition file committed at the repo root. Applies to UI projects that declared a design surface at bootstrap (design_surface=yes) or adopted one later. - **The routing test.** An entry is design-heavy when its risk is visual or interactional (a layout pass, a new user-facing surface, a redesign, a first-run flow); functional when its risk is plumbing (a service worker, a migration, a parser). Design-heavy entries route through a design intake BEFORE they are specced; functional entries skip straight to the spec. - **A mock is a decision, not a picture.** The design surface returns locked deliverables: redlines and mocks carrying exact values (hex, px, breakpoints, copy), numbered as decisions. The spec is written against the locked redline and cites it in its header (`Design contract:`); the redline's values become acceptance criteria. Pixel fidelity stays a QA concern checked against the mock, never an acceptance criterion. - **Design in batches, build in order.** Coherent groups of screens are designed as ONE system in a single intake, frozen, then built in engineering order. **No design happens mid-build**: a spec that starts redesigning something mid-build means an intake was skipped; stop and run it, do not improvise pixels in the build session. - **The