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-vacancies as part of the default stack in dev, dev:core, and therefore dev:one

Current repo truth:

• live API seam already points Vacancy traffic at svc-vacancies
• services/api/.env now targets http://localhost:4023
• root startup scripts still only start svc-tenders, not svc-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-vacancies normally in dev, dev:core, and dev:one

This is the single cutoff condition for immediate next execution.

Compatibility Truth

Current compatibility-backed public Vacancy behavior remains explicit:

• GET /vacancies
• GET /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.ts
• services/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.json dev:api:vacancies-extracted

Items likely to remain temporarily even after host retirement:

• services/svc-tenders/src/vacancy/compatibilityReadRepository.ts
• services/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-vacancies by default