Accommodation Legacy Host Retirement Plan

Purpose

This document inventories what remained on the old accommodation host inside svc-tenders before the Sprint 65 retirement cut and defines the removal package that was executed.

Remaining legacy-host items

| Item | Current location | Classification | Why it remains | | --- | --- | --- | --- | | legacy accommodation mount and runtime wiring | services/svc-tenders/src/server.ts | needed temporarily for rollback | This is the live fallback host while the rollback window remains open. | | legacy accommodation route registration | services/svc-tenders/src/routes/registerAccommodationRoutes.ts | needed temporarily for rollback | The fallback host cannot serve accommodation traffic without it. | | legacy route-support copy | services/svc-tenders/src/routes/support/accommodationRouteSupport.ts | needed temporarily for rollback | Required by the fallback route host and still mirrors active route mapping behavior. | | copied accommodation runtime module tree | services/svc-tenders/src/accommodation | needed temporarily for rollback | Includes command handlers, preferred read repositories, quote logic, validation, and projections used by the fallback host. | | compatibility accommodation read repository | services/svc-tenders/src/accommodation/compatibilityReadRepository.ts | unresolved | This is legacy residue behind root compatibility hosting, not the active primary route path. | | root accommodation compatibility methods | services/svc-tenders/src/repository.ts | unresolved | Root hosting still exposes older accommodation compatibility reads even though active route-time truth no longer depends on it. | | accommodation-related migrations under svc-tenders | services/svc-tenders/migrations | unresolved | Migration ownership has not been transferred to svc-accommodations, and several files are mixed with vacancy/legacy detail concerns. | | gateway route family | services/api/src/routes/accommodations.ts and adjacent accommodation routes | shared on purpose | The gateway façade and env seam stay outside the extracted accommodation runtime. | | gateway target helper and env seam | services/api/src/routes/accommodationsServiceTarget.ts, services/api/.env | shared on purpose | This remains the rollback-safe contract for routing accommodation traffic. | | shared auth / identity resolution | shared /auth/me contract and JWT ingress | shared on purpose | Auth semantics must stay consistent across fallback and extracted hosts. |

What can be retired next

Safe retirement candidate once the rollback window is explicitly closed:

• legacy accommodation registration in services/svc-tenders/src/server.ts
• legacy route file services/svc-tenders/src/routes/registerAccommodationRoutes.ts
• legacy route-support file services/svc-tenders/src/routes/support/accommodationRouteSupport.ts
• copied active accommodation module tree under services/svc-tenders/src/accommodation, excluding any residue that is intentionally deferred

These are all fallback-host artifacts rather than shared contracts.

What must stay for now

• gateway route shape in services/api
• gateway env seam ACCOMMODATIONS_SERVICE_URL ?? TENDERS_SERVICE_URL
• shared auth/identity contract behind /auth/me
• old svc-tenders accommodation mount until the rollback window is explicitly closed

What must be verified before deletion

Before deleting the legacy host slice:

1. confirm the team is intentionally closing the rollback window
2. confirm svc-accommodations remains the live primary target in services/api/.env
3. re-check accommodation read, owner-read, quote, booking-read, and denial-path smoke behavior against svc-accommodations
4. confirm no operational runbook still tells operators to route accommodation traffic through the old svc-tenders host
5. decide whether root compatibility residue will be removed with the host slice or deferred as a separate cleanup
6. decide migration ownership and whether any accommodation migrations remain canonically under svc-tenders

Rollback cutoff criteria

The rollback window is ready to close only when all of the following are true:

• the team accepts svc-accommodations as the sole supported accommodation runtime
• no active operator/runbook still depends on svc-tenders as an accommodation fallback host
• parity and live-cutover evidence remain accepted without an open request for another fallback rehearsal
• any remaining accommodation residue in svc-tenders is either included in the deletion package or explicitly deferred as non-routing residue

Notes

• The biggest retirement distinction is between the old route host and the older compatibility residue. They are related, but they are not the same cleanup.
• The fallback host can be removed before every last compatibility residue decision is resolved, but only if the team is comfortable separating “legacy route host retirement” from “root compatibility residue cleanup.”
• Mixed accommodation migrations remain the main reason the retirement story is still less clean than the ICPI retirement path.