What Was Clarified

• The tender legacy route shell and the gateway-side outbox bridge are not the same responsibility.
• The route shell owns:
  • /api/v1/tenders/legacy/* mounting
  • feature-flag gating
  • gateway-local legacy engine action execution
  • route response/error shaping
• The bridge owns:
  • legacy outbox enqueue toward TENDERS_SERVICE_URL
  • event type mapping
  • intentId / dedupeKey bridge semantics
  • bridge failure semantics

What The Next Step Should Be

The next step should be:

• isolate further first

That means:

• keep behavior unchanged
• keep the route shell mounted
• keep the bridge behavior operational
• extract or group the bridge behind a narrower compatibility module/helper boundary

Why This Is Strongest Now

• removal planning is still premature while the bridge remains operationally real
• the route shell and bridge are already separable conceptually
• isolating them first will make later removal planning much lower-ambiguity

What Is Not Removable Yet

• the tender legacy route cluster as a whole
• the gateway-side legacy outbox bridge

Reason:

• the gateway still contains and documents a real bridge into the legacy tender outbox flow
• no canonical upstream replacement for these legacy actions has been established here

What May Be Removable Later

Potential later removal candidates:

• the /api/v1/tenders/legacy/* route shell
• the gateway-side legacy outbox bridge helper
• the API-local legacy tender engine paths used only by that route cluster

But only after:

• upstream/backend replacement is explicit
• bridge replacement or retirement is explicit
• runtime consumers are checked beyond in-repo TS callers

Rationale

• Sprint 103 already showed that tender legacy actions are more coupled than auction compatibility actions.
• Sprint 104 confirms the coupling point is specifically the bridge behavior, not just the route shell.
• So the truthful sequence is:
  1. isolate bridge ownership from route ownership
  2. then do removal planning
  3. then only later decide whether actual removal is safe

Decision Summary

• Current direction: isolate further first
• Not the right move yet: begin route-shell removal planning
• Not the blocker: gateway/auth rewrite
• Real blocker for early removal planning: operational legacy bridge coupling