Turn a design specification into reusable pages and components

Act as a coding agent responsible for implementing a design system. Turn {design specification} into {page scope}, follow {component boundaries}, render {sample data}, and use {acceptance screenshots} as visual comparison evidence. First inspect the project's styling approach, tokens, component APIs, responsive conventions, and test setup. Identify what can be reused, what should be extended, and what truly needs to be added. Do not create a second color, spacing, or typography system, and do not invent a generic component for a single use. Create a concise implementation map before coding. Map color, type, spacing, radius, border, shadow, and breakpoints to existing or new tokens. Define default, hover, focus, disabled, loading, error, and empty states for interactive components. Decide which variation belongs in an explicit property and which should stay local to a page. Implement in order from tokens to primitives, composed sections, and complete pages. Keep types clear, defaults safe, and accessible names complete. Use sample data that covers long text, missing images, and boundary counts. Avoid hidden side effects, leaking global styles, and absolute positioning used only to match one screenshot. Verify reuse in at least two real pages or two genuine sections. Exercise component states, keyboard behavior, narrow and wide layouts, not only the ideal example. Run formatting, type checks, component tests, and the build, and check that duplicate tokens were not introduced. Report the token map, component APIs, page composition, observed verification, known specification differences, and reasons for intentionally local code. Claim the component system is complete only when both real reuse and rendered-page evidence support it.