• GET /api/v1/accommodations?page=1&pageSize=1
• GET /api/v1/accommodations/ACC-GE-2026-0102
• POST /api/v1/accommodations/ACC-GE-2026-0102/quote
• GET /api/v1/my-accommodation-bookings
• GET /api/v1/owner/accommodation-listings
• GET /api/v1/owner/accommodation-reservations
• POST /api/v1/accommodation-listings without bearer token

Auth observations

• authenticated owner and booking-read routes behaved the same as before
• missing-token mutation denial remained 401 missing_bearer_token
• no auth-specific regression was observed in the checked set

Response / status observations

• public list matched extracted runtime response
• public detail matched extracted runtime response
• owner listing and owner reservation reads matched extracted runtime response
• my-accommodation-bookings matched extracted runtime response
• denial-path status and body matched extracted runtime response

Quote / read observations

• quote response remained correct and matched the extracted runtime modulo request-time computedAt
• public accommodation read paths remained correct after cutover
• owner and booking read paths remained correct after cutover

Any anomalies

No blocking anomaly was observed.

Accepted request-time variance:

• quote computedAt timestamp differed by a few milliseconds between separate requests

This is not treated as backend drift.

Compatibility residue note

Compatibility residue still exists even though it did not surface in the checked cutover set:

• services/svc-tenders/src/accommodation/compatibilityReadRepository.ts
• root accommodation compatibility hosting in services/svc-tenders/src/repository.ts

The live cutover window does not mean those old-host-only compatibility surfaces are gone.

Rollback note

Rollback was not used.

Old accommodation hosting remained available during the window, so the rollback path stayed:

• revert ACCOMMODATIONS_SERVICE_URL to http://localhost:4020
• restart services/api