Vacancy Code Boundary Hardening

What Was Hardened

Sprint 67 hardened the Vacancy route boundary without changing behavior.

Route-facing ports now live in vacancy-owned contracts

Added route-facing dependency ports to:

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

Specifically:

• VacancyRouteReadRepository
• VacancyRouteCommandHandlers

This means:

• registerVacancyRoutes.ts no longer needs to type its dependencies as concrete classes
• the vacancy route module now depends on vacancy-owned contracts rather than implementation classes

Public read mixed truth is now clearer in code

Clarified in:

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

The code now states more directly that:

• public list/detail routes use the preferred vacancy repository
• that preferred repository still contains an explicit legacy vacancies fallback for public compatibility
• owner/applicant/internal reads are cleaner vacancy-owned truth and do not share that same fallback path

Web fallback truth is now clearer in code

Clarified in:

• apps/web/src/portal/api.ts

The code now states more directly that:

• backend/API vacancy routes are the preferred path
• fallback to VACANCY_CATALOG is UI compatibility only
• the backend route contract should not be confused with the web’s richer presentation layer

Gateway seam truth is now clearer in code

Clarified in:

• services/api/src/routes/vacancies.ts

The code now states more directly that:

• the gateway seam is extraction-ready
• upstream public vacancy truth may still be compatibility-backed internally

What Still Remains Mixed

Still mixed after this sprint:

• GET /vacancies
• GET /vacancies/:id
• root repository compatibility hosting for vacancy reads
• web fallback to VACANCY_CATALOG
• richer UI-side vacancy detail/catalog enrichment

Those remain mixed because this sprint was a boundary-hardening and decision sprint, not a public-read rewrite.

What Still Blocks Runtime / Bootstrap Prep

This sprint did not find a blocker that prevents vacancy runtime/bootstrap prep entirely.

The real blockers are narrower:

• public vacancy discovery is not yet clean canonical vacancy-owned truth
• legacy vacancies still participates in public reads
• root repository compatibility residue still exists
• web vacancy catalog/detail truth is still not fully backend-contract-driven

Runtime Prep Implication

After Sprint 67, the truthful position is:

• vacancy runtime/bootstrap prep can come next
• but public list/detail should be carried as an explicit compatibility seam
• final public-read cleanliness should be handled later rather than faked now