Lean fixes

The fix is the whole deliverable. Reviewers read the diff, not your intent. A good fix is one they approve without asking a question.

Before editing

• Scope = the findings asked for. "Crit and majors" means minors and nits stay untouched, even the easy ones. List them as left alone.
• Find the root site. Several findings often share one cause, such as three callers funnelling through one helper. Fix that site once. Don't patch every symptom.
• Check the ground. Make sure the branch builds and the dependencies (vendor, proto, generated code) match what the change expects. A fix on a broken base proves nothing.
• Look for what already exists. Before writing a filter, mapper, or helper, grep for one. A local helper that already does it wins over a new one.

Choosing the fix

Pick in this order and stop at the first one that works:

1. Delete. When the defective thing adds no value, remove it. Examples: an index that can't serve the query, a copy of a function, a dead branch.
2. Reuse. Call the existing helper, the sibling code path, or the pattern the target branch already uses. Examples: copy fields into the existing request type and call the existing encoder; call the selector the other endpoints call.
3. Inline edit. Change the lines where the bug lives. A guard, a missing field, one more entry in an allowlist, a limit stage.
4. Local extract. Pull out an unexported helper only when the fix would otherwise duplicate the same logic twice today.