WorkStay Gateway Seam Status
Purpose
This document records the current extraction-seam status at the API gateway for the vacancy and accommodation surfaces that are the real backend candidates for future WorkStay extraction.
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 document records the current extraction-seam status at the API gateway for the vacancy and accommodation surfaces that are the real backend candidates for future WorkStay extraction.
Vacancy already had the stronger gateway seam coming into Sprint 58.
Current vacancy gateway target contract:
VACANCIES_SERVICE_URL ?? TENDERS_SERVICE_URL ?? "http://localhost:4020"Route families currently using that seam:
Vacancy seam verdict:
env-seam-readyImportant caveat:
vacanciesSprint 57 truth:
my-accommodation-bookings were still pinned directly to TENDERS_SERVICE_URLSprint 58 hardening:
Added shared accommodation gateway helper:
Current accommodation gateway target contract:
ACCOMMODATIONS_SERVICE_URL ?? TENDERS_SERVICE_URL ?? "http://localhost:4020"Route families now using that seam:
Accommodation seam verdict:
env-seam-readyAdditional hardening added in the helper:
localhost and 127.0.0.1my-accommodation-bookingsNo inspected accommodation gateway routes remain pinned directly to TENDERS_SERVICE_URL after this sprint.
What remains mixed is not the gateway target seam, but the backend truth behind it: