Vacancy Application And Booking Compatibility Boundary

Scope

This note records the Sprint 14 compatibility-surface move for the remaining vacancy/application and accommodation/booking residue that was still hosted in services/svc-tenders/src/repository.ts.

Labels used here:

• VERIFIED
• REAL
• MIXED

Verified Boundary

Vacancy application compatibility paths

VERIFIED, MIXED

The following root-repository methods were still present as legacy compatibility surface in services/svc-tenders/src/repository.ts before Sprint 14:

• listMyVacancyApplications(...)
• listVacancyApplicationsByPosting(...)
• listOwnerVacancyApplications(...)
• getOwnerVacancyApplication(...)

These methods were moved behind a clearly named wrapper:

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

The root repository now delegates to that compatibility module instead of carrying the SQL/mapping logic inline.

Preferred vacancy application path

VERIFIED, REAL

The preferred active vacancy application read path remains:

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

This is the repository used by the active vacancy route registration layer:

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

Verdict:

• VacancyReadRepository is the preferred runtime path
• VacancyCompatibilityApplicationRepository is second-class compatibility residue kept only for the older TendersRepository surface

Accommodation booking compatibility paths

What exists

VERIFIED, REAL

Accommodation booking reads are already handled on the preferred read-model path:

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

Relevant methods:

• getMyAccommodationBookings(...)
• getAccommodationBookingsByListing(...)
• listOwnerAccommodationReservations(...)
• getOwnerAccommodationReservation(...)

These are consumed directly by:

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

What did not exist in root

VERIFIED

Sprint 14 did not create an accommodation/compatibilityBookingRepository.ts, because there was no matching booking-read residue left in the root repository to move.

That absence is intentional and truthful:

• booking reads were already using the preferred accommodation read repository
• creating a fake symmetry module would have obscured the real boundary

Current structure after Sprint 14

Preferred paths

• Vacancy public/application reads: services/svc-tenders/src/vacancy/readRepository.ts
• Accommodation booking reads: services/svc-tenders/src/accommodation/readModel.ts
• Accommodation owner listing reads: services/svc-tenders/src/accommodation/ownerReadRepository.ts

Compatibility paths

• Vacancy public/owner/applicant listing compatibility: services/svc-tenders/src/vacancy/compatibilityReadRepository.ts
• Vacancy application compatibility: services/svc-tenders/src/vacancy/compatibilityApplicationRepository.ts
• Accommodation public/owner catalog compatibility: services/svc-tenders/src/accommodation/compatibilityReadRepository.ts

What remains unresolved

VERIFIED, MIXED

Sprint 14 did not change:

• final platform ownership of vacancy/workstay capability
• final platform ownership of accommodation booking capability
• legacy public accommodation catalog behavior

This sprint only made the remaining compatibility surface more explicit and safer for future extraction.