VACANCY PUBLIC READ CLEANUP

• EXPLICIT COMPATIBILITY WRAP

That means the public vacancy read surface still keeps its current behavior, including compatibility-backed fallback to legacy vacancies, but the preferred path and the fallback path are now more clearly separated in code and documentation.

Current public-read path

For GET /vacancies:

1. services/api/src/routes/vacancies.ts forwards the request through the existing seam: VACANCIES_SERVICE_URL ?? TENDERS_SERVICE_URL
2. services/svc-vacancies/src/routes/registerVacancyRoutes.ts resolves the request through VacancyReadRepository.
3. services/svc-vacancies/src/vacancy/readRepository.ts now makes the branch explicit:
   • preferred branch: vacancy_postings_view
   • compatibility branch: legacy vacancies rows where no projection-backed posting exists
4. The merged rows are shaped into the public summary contract through toVacancySummary.

For GET /vacancies/:id:

1. services/api/src/routes/vacancies.ts forwards unchanged.
2. services/svc-vacancies/src/routes/registerVacancyRoutes.ts calls VacancyReadRepository.findVacancyById.
3. services/svc-vacancies/src/vacancy/readRepository.ts now makes the branch explicit:
   • preferred branch: projection-backed detail from vacancy_posting_detail_view
   • compatibility branch: legacy vacancies lookup if no posting projection exists
4. The preferred projection path still maps into the legacy public summary/detail shape through mapVacancyPostingProjectionToLegacySummary.

Preferred truth vs compatibility truth

Preferred public-read truth currently exists, but it is not yet the only source:

• preferred list truth comes from vacancy_postings_view
• preferred detail truth comes from vacancy_posting_detail_view
• compatibility truth still comes from legacy vacancies
• output shape still targets the current public contract rather than a new projection-native contract

This is why the public read surface is cleaner than before, but still not projection-only truth.

Cleanup performed

The cleanup in Sprint 74 was intentionally narrow:

• services/svc-vacancies/src/vacancy/readRepository.ts now isolates public-read compatibility behavior behind explicitly named helper paths instead of leaving the fallback mixed inline.
• services/svc-vacancies/src/routes/registerVacancyRoutes.ts now documents that the extracted runtime still serves current public behavior through separate preferred and compatibility branches.
• apps/web/src/portal/api.ts now states explicitly that frontend fallback to static catalog truth is UI-side resilience, not canonical backend truth.

No route shape changed. No gateway behavior changed. No auth behavior changed.

What still remains compatibility-backed

The following still remain compatibility-backed today:

• GET /vacancies
• GET /vacancies/:id
• the legacy-row fallback logic inside services/svc-vacancies/src/vacancy/readRepository.ts
• compatibility residue still mirrored in services/svc-tenders/src/vacancy/readRepository.ts, services/svc-tenders/src/vacancy/compatibilityReadRepository.ts, and services/svc-tenders/src/repository.ts

That compatibility residue no longer blocks Vacancy route-host extraction, but it still blocks claiming fully converged public-read truth.

Web-side fallback truth

Web vacancy discovery still carries richer UI-side fallback truth:

• apps/web/src/portal/api.ts falls back to static catalog data if backend reads fail
• apps/web/src/features/domains/vacancyCatalog.ts carries a richer VacancyListing shape than the backend public vacancy contract

That means the web can still render vacancy catalog and detail experiences from UI-side truth in some failure modes. This is useful operationally, but it is not evidence that backend public-read cleanup is complete.

Notes

Sprint 74 makes the boundary easier to reason about, but it does not overstate progress:

• Vacancy host extraction is complete
• public-read behavior is still compatibility-backed
• the preferred path is now easier to isolate from the fallback path
• deeper convergence remains a later cleanup decision