Vacancy / Accommodation Compatibility Boundary
Purpose
Sprint 13 moved the remaining vacancy/accommodation compatibility reads out of and into explicitly named compatibility modules.
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
Sprint 13 moved the remaining vacancy/accommodation compatibility reads out of and into explicitly named compatibility modules.
services/svc-tenders/src/repository.tsThis was a structural move only.
It did not change:
VERIFIED preferred vacancy reads live in:
services/svc-tenders/src/vacancy/readRepository.tsThat repository already owns:
listAllVacancies(...)countAllVacancies(...)findVacancyById(...)listMyVacancyPostings(...)findMyVacancyPostingById(...)Sprint 13 created:
services/svc-tenders/src/vacancy/compatibilityReadRepository.tsThis module is intentionally second-class.
Its role is:
TendersRepository compatibility surfaceVacancyCompatibilityReadRepository delegates to the already-preferred:
VacancyReadRepositoryThis is truthful because the compatibility concern is now the surface, not a separate legacy SQL implementation.
VERIFIED preferred accommodation reads now live in:
services/svc-tenders/src/accommodation/readModel.tsAccommodationReadRepositoryservices/svc-tenders/src/accommodation/ownerReadRepository.tsAccommodationOwnerReadRepositorySprint 13 created:
services/svc-tenders/src/accommodation/compatibilityReadRepository.tsThis module is intentionally second-class.
It preserves older compatibility behavior that still reads from the legacy accommodations catalog for:
listAllAccommodations(...)countAllAccommodations(...)findAccommodationById(...)It delegates owner listing compatibility methods to:
AccommodationOwnerReadRepositoryfor:
listMyAccommodationListings(...)findMyAccommodationListingById(...)Vacancy compatibility in practice was mostly a compatibility wrapper around an already-preferred repository.
Accommodation compatibility still preserves a genuinely different legacy read source:
accommodation_listings_view / accommodation_listing_detail_viewaccommodations catalog tableThat distinction is now explicit in module naming.
Out of services/svc-tenders/src/repository.ts:
services/svc-tenders/src/vacancy/readRepository.tsservices/svc-tenders/src/accommodation/readModel.tsservices/svc-tenders/src/accommodation/ownerReadRepository.tsservices/svc-tenders/src/vacancy/compatibilityReadRepository.tsservices/svc-tenders/src/accommodation/compatibilityReadRepository.tsTendersRepository for stabilityStill unresolved after Sprint 13:
TendersRepository compatibility surface should later be retired entirelyThe preferred read paths and compatibility read paths are now easier to distinguish:
compatibilityReadRepository modulesrepository.ts delegates instead of embedding those behaviors inline