The boundary is part of the behavior.
A working function can still be in the wrong place.
Integration problems often appear outside the new function. A generated patch may bypass an adapter, repeat validation, or write data beyond the expected transaction. Trace both sides of a boundary before deciding where the implementation should live.
Reuse the established crossing point
If application code reaches a provider through an existing interface, extend that interface only when the new behavior requires it. Keep provider-specific response parsing in the adapter. This makes failures easier to translate and avoids teaching every caller about the same external detail.
Inspect the consequences of moving work
Moving a write outside a transaction can change failure behavior even when a happy-path test passes. Moving a check into a UI component can leave other callers unprotected. Ask the assistant to explain which layer owns the decision and how the patch preserves atomicity, authorization, and error translation where those concerns apply.
- CALLER
- Uses the existing application interface.
- ADAPTER
- Normalizes provider-specific details.
- FAILURE
- Preserves the established error boundary.
WORKING REQUEST / SPEC 03
Map the caller, service, and adapter for this operation. Keep provider parsing inside the adapter. Explain transaction and failure implications. Stop if the requested change needs a new public contract.
Repeated conversion code across callers is a reason to inspect the boundary.