ui-design-memory

OneWorks UI Design Memory

Use repository files as the team's revisioned, version-controlled design memory. Do not rely on a person, model, or current conversation to preserve standards.

Start every visual task

1. Read team-design-standards.md.
2. Read .oo/rules/frontend-standard/design-memory.md, its registry, applicable project design rules, design tokens, shared component guidance, and the nearest AGENTS.md.
3. Search existing rules before proposing a new standard. Prefer rg over broad source scans.
4. Produce a concise Visual Brief before non-mechanical visual edits:
   • target surface and viewports;
   • reference images or existing product surfaces;
   • layout hierarchy and key geometry;
   • components and tokens to reuse;
   • interaction and responsive invariants;
   • prohibited patterns;
   • expected user behaviors;
   • required screenshots and observable checks.
   • host chrome ownership: which existing header, sidebar, breadcrumb, and action slot already names or navigates the current object.
5. Keep task-specific coordinates and temporary adjustments in the Visual Brief, not durable memory.

Before adding a visible title, breadcrumb, navigation button, refresh command, or outer padding, inspect the complete host surface. Do not duplicate a title already owned by the route header, place collection navigation in object-level header actions, add manual refresh when the data layer already revalidates, or let both the host and embedded view own the same inset. Prefer the host's existing sidebar action, breadcrumb, header action, and data-query contracts.

Classify user feedback

Treat feedback as a durable-standard candidate when it uses normative language such as all, always, default, must, ensure, standard, consistent, 统一, 所有, 以后, 默认, 始终, 必须, 保证, 规范, or 不要再.

Treat feedback as task-local when it only adjusts the current composition, for example move this 2px left, crop this image slightly, or use x=278 for this reference viewport.