# Code Reuse Thinking Guide

Consult when adding a helper/component or changing behavior shared by multiple
consumers. Search the relevant source and tests with `rg` before creating a
second implementation; widen the search when ownership is uncertain.

## Decide From The Contract

- Compare responsibilities, inputs, failure behavior, permissions and lifecycle, not only similar syntax or visual shape.
- Reuse or extend an existing owner when the semantics agree. Keep distinct rules separate when combining them creates flags, coupling or misleading names.
- Share constants only when they represent the same business fact. A fixed repetition count or similarity percentage does not justify an abstraction.
- For a shared change, identify callers and assert the affected behaviors, including exceptions. After a batch edit, check for missed consumers and accidental out-of-scope changes.

## Asymmetric Producers

When automatic discovery/copy and a manually listed producer promise the same
output (for example init/update, screen/export or live/snapshot inputs), a
rename or added field can update only one side. Inspect both producers and
compare their observable output contract. Prefer a focused parity regression
over another copied list; do not assume generated output proves every producer
was exercised.