Customize the code you own

Owning the component source means you can change its markup, variants, classes, and behavior. It does not mean every change is harmless.

Keep product-specific composition outside the UI primitive when possible. When a change belongs in the primitive, document the reason and test its variants, ref forwarding, keyboard behavior, states, and types. A diff against a fresh registry version can help you understand future upstream changes without blindly overwriting yours.

Change the lowest owner of the decision. Product copy belongs in a domain component, repeated visual intent may belong in a variant, and behavior shared by every instance may belong in the primitive. Editing the primitive for one page creates a global exception that future callers cannot see.

Preserve the less visible contract: refs, prop types, data attributes used by CSS, primitive parts, accessible names, focus handling, and disabled behavior. A markup simplification that removes a primitive wrapper can silently break all of these while still looking correct with a mouse.

Record meaningful deviations near the component or in a maintenance note. When upstream changes, generate or view a fresh item separately and merge the relevant ideas. Re-adding over the owned file is not an update strategy.

Add a compact Button size or adjust Card spacing in the generated source. Compare it with a fresh registry version, then test types, refs, every variant, keyboard focus, disabled state, and data attributes. Record why the change belongs at this level.