PC UI Design Spec

Problem

When a high-fidelity PC mock enters an existing admin codebase, the usual risk is not visual inaccuracy but implementation drift: too many custom controls, styles detached from existing tokens, input behavior affected by project-level replacements, and unrelated routing or service changes made while polishing a page.

How It Works

• Inspect project constraints first: read package.json and nearby src/pages, src/components, and global.less to confirm the rules of @umijs/max, React 18, Ant Design 5, Pro Components, and Less.
• Reuse project primitives: translate the design into Ant Design components, project wrappers, and @ant-design/icons; add shared tokens only when multiple screens need the same rule.
• Separate visuals from behavior: match layout, spacing, type scale, color, component states, and visible data density without changing APIs, permissions, business state, or routing.
• Verify and expose gaps: run the smallest relevant format, build, or type-check command; when feasible, run the local app and inspect it in a browser, then state which UI surfaces were matched and where assets or unclear states prevent exact restoration.

Boundaries

This is suited to visual restoration and UI-rule review for operational or admin pages, not product redesign. It should not introduce new UI libraries for ordinary pages, hard-code data only to make a screenshot look full, use oversized rounded cards, heavy gradients, decorative blobs, or marketing hero layouts, or modify unrelated pages, routes, services, models, or audit/logging behavior.