Vacancy Legacy Retirement Decision
Rollback-Window Decision
Decision:
KEEP temporarily with one concrete cutoff condition
Rollback is not being left indefinite.
Is Retirement Approved Now
No.
Legacy Vacancy host retirement is not approved in Sprint 72.
Why Retirement Is Not Approved Now
The blocker is operational and concrete:
- normal root startup paths still do not provision
svc-vacanciesas part of the default stack indev,dev:core, and thereforedev:one
Current repo truth:
- live API seam already points Vacancy traffic at
svc-vacancies services/api/.envnow targetshttp://localhost:4023- root startup scripts still only start
svc-tenders, notsvc-vacancies
That means deleting the old Vacancy host today would leave the normal startup flow depending on a service it does not actually launch.
Exact Cutoff Condition
Close the rollback window only after this exact condition is satisfied:
- root startup/dev flows provision
svc-vacanciesnormally indev,dev:core, anddev:one
This is the single cutoff condition for immediate next execution.
Compatibility Truth
Current compatibility-backed public Vacancy behavior remains explicit:
GET /vacanciesGET /vacancies/:id
These 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.
Exact Deletion Package For The Next Sprint
Once the cutoff condition is satisfied, delete:
- Vacancy mount from
services/svc-tenders/src/server.ts services/svc-tenders/src/routes/registerVacancyRoutes.tsservices/svc-tenders/src/routes/support/vacancyRouteSupport.ts- fallback Vacancy runtime copy in
services/svc-tenders/src/vacancy/commandHandlers.ts - fallback Vacancy runtime copy in
services/svc-tenders/src/vacancy/contracts.ts - fallback Vacancy runtime copy in
services/svc-tenders/src/vacancy/domain.ts - fallback Vacancy runtime copy in
services/svc-tenders/src/vacancy/projections.ts - fallback Vacancy runtime copy in
services/svc-tenders/src/vacancy/readModel.ts - fallback Vacancy runtime copy in
services/svc-tenders/src/vacancy/readRepository.ts - fallback Vacancy runtime copy in
services/svc-tenders/src/vacancy/validation.ts - fallback Vacancy runtime tests in
services/svc-tenders/src/vacancy/__tests__/*if no longer retained for compatibility residue reasons - optional follow-up cleanup:
package.jsondev:api:vacancies-extracted
Items likely to remain temporarily even after host retirement:
services/svc-tenders/src/vacancy/compatibilityReadRepository.tsservices/svc-tenders/src/vacancy/compatibilityApplicationRepository.ts- root Vacancy compatibility residue in
services/svc-tenders/src/repository.ts
Remaining Blockers
Only one blocker is being carried forward as the explicit cutoff condition:
- root startup/dev orchestration still does not launch
svc-vacanciesby default