Vacancy Legacy Retirement Decision
Rollback-Window Decision
Decision:
KEEP temporarily with one concrete cutoff condition
Loading module
Resolving locale, route permissions, and workspace projection.
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
Decision:
KEEP temporarily with one concrete cutoff conditionRollback is not being left indefinite.
No.
Legacy Vacancy host retirement is not approved in Sprint 72.
The blocker is operational and concrete:
svc-vacancies as part of
the default stack in dev, dev:core, and therefore dev:oneCurrent repo truth:
svc-vacanciesservices/api/.env now targets http://localhost:4023svc-tenders, not svc-vacanciesThat means deleting the old Vacancy host today would leave the normal startup flow depending on a service it does not actually launch.
Close the rollback window only after this exact condition is satisfied:
svc-vacancies normally in dev,
dev:core, and dev:oneThis is the single cutoff condition for immediate next execution.
Current compatibility-backed public Vacancy behavior remains explicit:
GET /vacanciesGET /vacancies/:idThese still preserve mixed truth through VacancyReadRepository, including
fallback to legacy vacancies where projection-backed posting truth is absent.
That compatibility-backed behavior does not block old route-host deletion by itself.
It blocks only deeper public-read cleanup later.
Once the cutoff condition is satisfied, delete:
services/svc-tenders/src/server.tsservices/svc-tenders/src/routes/registerVacancyRoutes.tsservices/svc-tenders/src/routes/support/vacancyRouteSupport.tsservices/svc-tenders/src/vacancy/commandHandlers.tsservices/svc-tenders/src/vacancy/contracts.tsservices/svc-tenders/src/vacancy/domain.tsservices/svc-tenders/src/vacancy/projections.tsservices/svc-tenders/src/vacancy/readModel.tsservices/svc-tenders/src/vacancy/readRepository.tsservices/svc-tenders/src/vacancy/validation.tsservices/svc-tenders/src/vacancy/__tests__/* if no longer retained for compatibility residue reasonspackage.json dev:api:vacancies-extractedItems likely to remain temporarily even after host retirement:
services/svc-tenders/src/vacancy/compatibilityReadRepository.tsservices/svc-tenders/src/vacancy/compatibilityApplicationRepository.tsservices/svc-tenders/src/repository.tsOnly one blocker is being carried forward as the explicit cutoff condition:
svc-vacancies by default