# Source selection policy

Use this reference when selecting the basis for an extracted component.

## Decision table

| Need | Preferred source | Reason |
| --- | --- | --- |
| Existing visual presentation | Source application | It is the required baseline. |
| Existing package component | `@meyermedia/ui` | Avoid duplicate public APIs. |
| Dialog, menu, popover, tooltip, tabs, accordion, select, checkbox, radio, switch, toolbar, focus or portal behavior | Radix Primitives | Existing accessible interaction and state contracts. |
| Common Tailwind/Radix component composition | Official shadcn implementation or registry | Established composition that can be restyled to match the source. |
| Date, time, calendar, collection, locale, virtual focus, complex selection | React Aria | Specialized accessible behavior and internationalization. |
| Floating positioning not covered by the selected primitive | Floating UI | Dedicated positioning and interaction primitives. |
| Presence, layout, reordering, drag, gestures or coordinated animation | Motion | Dedicated animation behavior with reduced-motion support. |
| Application-specific visual difference | Existing source variant | Preserve it as a variant or separate pattern. |

## Candidate evaluation

Before adopting an upstream implementation, record:

1. Official source URL and current version or documentation date.
2. License compatibility.
3. Bundle and runtime implications.
4. React and Next.js SSR compatibility.
5. Accessibility and keyboard behavior.
6. RTL and internationalization requirements.
7. Styling and DOM flexibility.
8. Whether the source application already uses the dependency.
9. How closely its DOM and behavior match the current application.
10. Whether it can remain internal behind the package API.

## Conflict resolution

When sources conflict:

- Preserve the source application's current visual result.
- Prefer the official primitive's behavior and accessibility contract.
- Adapt presentation through classes, CSS variables, slots and wrappers.
- Do not preserve an inaccessible behavior merely because it is existing. Repair it with the smallest visual change and document the difference.
- Do not change interaction semantics to match a screenshot.

## No-invention test

A proposed new component is allowed only when all of these are true:

- no equivalent package component exists;
- no equivalent source application component can be generalized;
- no official upstream primitive or template covers the behavior;
- the proposed code is a thin composition or adapter;
- its visual rules come from observed source usages;
- its public API represents observed variants or a required stable contract;
- the extraction map documents why it is necessary.

If these conditions are not met, reuse or adapt an existing implementation instead.