Those routes already depend on the preferred vacancy route-time repository:

• services/svc-tenders/src/vacancy/readRepository.ts

That is the truthful preferred runtime dependency.

However, the public read truth inside that preferred repository is still mixed:

• projection-backed vacancy postings come from:
  • vacancy_postings_view
  • vacancy_posting_detail_view
• compatibility fallback still comes from:
  • legacy vacancies

So the preferred route dependency is real, but the public discovery data source behind it is not yet fully converged onto vacancy-owned projection truth.

Exact Fallback Path

GET /vacancies

VacancyReadRepository.listAllVacancies():

1. selects projected rows from vacancy_postings_view
2. unions them with legacy rows from vacancies
3. excludes legacy rows only when a projection-backed posting already exists for that identifier

This means the public list is intentionally mixed.

GET /vacancies/:id

VacancyReadRepository.findVacancyById():

1. looks for the posting in vacancy_posting_detail_view
2. if found, maps that projection into the legacy summary shape
3. if not found, falls back to vacancies

This means the public detail route is also intentionally mixed.

Compatibility Residue

Compatibility residue still involved in public vacancy discovery:

• legacy vacancies table
• root repository vacancy compatibility methods in services/svc-tenders/src/repository.ts
• VacancyCompatibilityReadRepository
• web fallback to VACANCY_CATALOG

Important asymmetry:

• owner/internal vacancy reads and vacancy application reads are already cleaner vacancy-owned truth
• public vacancy discovery is the conspicuous mixed surface

Web Fallback Truth

Current web vacancy consumption is also mixed:

• apps/web/src/portal/api.ts prefers the backend/API vacancy routes
• if list fetching fails, it falls back to VACANCY_CATALOG
• detail rendering is further enriched in apps/web/src/features/domains/vacancyDetail.ts
• that enrichment is presentation-layer truth, not canonical backend contract truth

So the web does not yet treat backend vacancy DTOs as the only vacancy detail/catalog source.

Decision

Recommended direction:

• keep /vacancies and /vacancies/:id as an explicit compatibility seam for early extraction

Not recommended as the next step:

• forcing projection-backed public-read convergence before runtime/bootstrap prep

Rationale

Why compatibility seam first is safer:

1. vacancy postings, applications, and owner/internal reads are already a real backend core
2. the API gateway seam is already extraction-ready through VACANCIES_SERVICE_URL ?? TENDERS_SERVICE_URL
3. the mixed public read path is explicit and localised enough to carry forward honestly
4. public-read convergence would be a broader behavior-sensitive cleanup across:
   • VacancyReadRepository
   • legacy vacancies
   • web fallback and enrichment assumptions
5. runtime/bootstrap prep can proceed without pretending that public discovery is already clean

What this decision does not mean:

• it does not mean public vacancy discovery is ready for a clean final cutover
• it does not mean legacy vacancies should be treated as canonical long-term vacancy truth
• it does not remove the need for later public-read convergence

Practical Next-Step Meaning

The safe next step is:

1. prepare a vacancy runtime/bootstrap using the real vacancy core
2. carry the current public list/detail compatibility behavior forward explicitly
3. keep public discovery marked as compatibility-backed during early extraction
4. plan a later cleanup sprint that converges /vacancies onto projection-backed truth before claiming public-read cleanliness