Steering a Plan Instead of Just Approving It

Claude Code proposes the following plan after you ask it to "add rate limiting to our public API":

Proposed approach:
1. Add a global rate-limit middleware applied to every route,
   100 requests/minute per IP.
2. Store request counts in an in-memory Map keyed by IP.
3. Return 429 with a Retry-After header when the limit is hit.

You like the general shape but have two concerns: (a) an in-memory store won't work correctly once the API runs on more than one server instance, and (b) some internal service-to-service calls should not be rate-limited at all, but the plan doesn't mention any exemption.

1. Name two distinct, concrete mechanisms this subject describes for acting on these concerns without leaving plan mode, and explain what each is better suited for between the two concerns above.
2. Explain why raising both concerns now, before approving, is cheaper than raising them after you pick "Yes, manually approve edits" and start reviewing the resulting diff.
3. A colleague says "why not just approve it and fix the in-memory store issue in a follow-up PR once we see it's a problem in production?" Give a substantive reason this is a worse call for concern (a) specifically, referencing what kind of change swapping the storage backend later would actually require.