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 .
Resolving locale, route permissions, and workspace projection.
Current scope: Guest
Category: 10_normative | Version: v1.0.0
Owner: DOCUMENT_CUSTODIAN | Review cycle: 90 days
Approval authority: GOVERNANCE_ADMIN
Documentation portal is read-only. Editing and mutation endpoints are disabled.
Kvary platform is originally created in Georgian. Where a Georgian version exists, Georgian is authoritative for platform UI, documentation, and legal interpretation.
Translations into other languages are provided for convenience. Some records may originate in other languages and carry their own source or legal locale for a specific flow, but where a Georgian version is available, the Georgian version prevails for platform-level wording and interpretation.
Metadata incomplete: Document ID, Version, Status, Owner Role, Last Review Date, Next Review Date, Change Log
This note records the Sprint 14 compatibility-surface move for the remaining vacancy/application and accommodation/booking residue that was still hosted in .
Labels used here:
VERIFIEDREALMIXEDVERIFIED, 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:
The root repository now delegates to that compatibility module instead of carrying the SQL/mapping logic inline.
VERIFIED, REAL
The preferred active vacancy application read path remains:
This is the repository used by the active vacancy route registration layer:
Verdict:
VacancyReadRepository is the preferred runtime pathVacancyCompatibilityApplicationRepository is second-class compatibility residue kept only for the older TendersRepository surfaceVERIFIED, REAL
Accommodation booking reads are already handled on the preferred read-model path:
Relevant methods:
getMyAccommodationBookings(...)getAccommodationBookingsByListing(...)listOwnerAccommodationReservations(...)getOwnerAccommodationReservation(...)These are consumed directly by:
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:
VERIFIED, MIXED
Sprint 14 did not change:
This sprint only made the remaining compatibility surface more explicit and safer for future extraction.