When I compared product code with the design system, I found local additions that existed because the shared component was missing controls.
That changed how I thought about reviewing a proposal. I needed to understand whether the component could support the idea before treating the difference as a design issue.
I brought that question into reviews of coded design proposals. I look at the experience alongside the shared component library to see where a proposal depends on a library change.
Check what the component supports
I start with the component code and its documented options, then compare those with the proposed behaviour.
For an account selector, that might mean checking whether it can display another information row. I look for an existing option first, then consider whether shared components can be combined.
If neither supports the requirement, I identify what the component would need to provide.
Explain the decision it needs
I separate an unnecessary override from a missing capability. Changing button spacing when an existing size works needs a different response from adding content the component cannot display.
For each finding, I capture the component, the requested behaviour, the current limitation, and the decision needed from the team.
That gives the review a specific question to resolve. I can discuss whether the experience needs to change or whether the shared component needs to support it.
I bring the component requirement into the same review as the experience.