It focuses on:

• which route groups use preferred read paths
• which route groups would use compatibility paths only indirectly
• where vacancy and accommodation are intentionally asymmetric

Labels used here:

• VERIFIED
• REAL
• MIXED

Vacancy routes

Source file:

• services/svc-tenders/src/routes/registerVacancyRoutes.ts

Preferred read source

VERIFIED, REAL

Preferred vacancy route-time reads come from:

• services/svc-tenders/src/vacancy/readRepository.ts

Used route groups:

• public vacancy list/detail
  • /vacancies
  • /vacancies/:id
• owner vacancy posting reads
  • /owner/vacancy-postings
  • /owner/vacancy-postings/:id
• vacancy application reads
  • /vacancy-applications/me
  • /vacancy-postings/:id/applications
  • /owner/vacancy-applications
  • /owner/vacancy-applications/:id

Compatibility read source

VERIFIED, MIXED

Compatibility vacancy readers still exist:

• services/svc-tenders/src/vacancy/compatibilityReadRepository.ts
• services/svc-tenders/src/vacancy/compatibilityApplicationRepository.ts

But those are not the preferred route-time read source.

They exist to preserve the older TendersRepository compatibility surface.

Route-level verdict

Vacancy route modules are now clearer about this truth:

• active route reads use the preferred vacancy read repository
• compatibility vacancy/application readers are second-class and indirect

Accommodation routes

Source file:

• services/svc-tenders/src/routes/registerAccommodationRoutes.ts

Preferred public + booking read source

VERIFIED, REAL

Published listing and booking/reservation reads use:

• services/svc-tenders/src/accommodation/readModel.ts

Used route groups:

• public listing reads
  • /accommodations
  • /accommodation-listings/:id
• requester booking reads
  • /my-accommodation-bookings
  • /accommodation-listings/:id/bookings
• owner reservation reads
  • /owner/accommodation-reservations
  • /owner/accommodation-reservations/:id

Preferred owner listing read source

VERIFIED, REAL

Owner listing reads use a different preferred repository:

• services/svc-tenders/src/accommodation/ownerReadRepository.ts

Used route groups:

• /owner/accommodation-listings
• /owner/accommodation-listings/:id

Compatibility read source

VERIFIED, MIXED

Compatibility accommodation reads still exist in:

• services/svc-tenders/src/accommodation/compatibilityReadRepository.ts

This remains second-class and is kept only for the older TendersRepository compatibility surface.

Real asymmetry

VERIFIED

Accommodation is intentionally asymmetric:

• public published listing reads and booking/reservation reads already use the preferred read model
• owner listing reads use a separate preferred owner repository
• there is no separate accommodation booking compatibility repository because no such root-residue path remained

This asymmetry is real and should remain visible.

What remains unresolved

VERIFIED, MIXED

Sprint 15 did not change:

• final platform extraction boundaries for vacancy/workstay
• final platform extraction boundaries for accommodation/booking
• whether compatibility reader surfaces should later be retired

Result

After Sprint 15, a reader can open the route modules and see more directly:

• which reads are preferred runtime paths
• which reads are owner/internal paths
• which compatibility surfaces still exist only for older mixed repository consumers
• where vacancy and accommodation are intentionally not symmetric