WorkStay Dependency Edge Map

Purpose

This document traces the current dependency edges for accommodation, vacancy, booking, and worker-adjacent surfaces that are likely candidates for a future WorkStay platform.

It records what can remain shared versus what should separate later.

Dependency edges

| Source | Target | Dependency type | Verdict | Notes | | --- | --- | --- | --- | --- | | services/svc-tenders/src/routes/registerVacancyRoutes.ts | services/svc-tenders/src/vacancy/readRepository.ts | preferred read-model dependency | should move into WorkStay later | Active route-time vacancy reads already depend directly on the preferred repository. | | services/svc-tenders/src/routes/registerVacancyRoutes.ts | services/svc-tenders/src/vacancy/commandHandlers.ts | write-model dependency | should move into WorkStay later | Durable vacancy lifecycle is a clear candidate-owned dependency. | | services/svc-tenders/src/routes/registerVacancyRoutes.ts | shell requireServiceAuth / principal helpers | auth ingress dependency | can remain shared after extraction | Shared auth/principal ingress is a believable Kvary backbone dependency. | | services/svc-tenders/src/routes/registerAccommodationRoutes.ts | preferred read-model dependency | should move into WorkStay later | Public listing/detail and booking/reservation reads already use the preferred accommodation read repository. | | services/svc-tenders/src/routes/registerAccommodationRoutes.ts | owner read-model dependency | should move into WorkStay later | Owner listing reads are real but asymmetric from public reads. | | services/svc-tenders/src/routes/registerAccommodationRoutes.ts | write-model dependency | should move into WorkStay later | Durable listing and booking writes are WorkStay-candidate material. | | services/svc-tenders/src/routes/registerAccommodationRoutes.ts | shell auth/parser helpers | auth ingress dependency | can remain shared after extraction | Similar to vacancy support: route-local mapping, shell-owned ingress. | | services/svc-tenders/src/vacancy/commandHandlers.ts | outbox_events + services/svc-tenders/src/vacancy/projections.ts | local projection/event dependency | should move into WorkStay later | Real local event/projection infrastructure, but not yet a shared cross-service contract. | | services/svc-tenders/src/accommodation/commandHandlers.ts | outbox_events + services/svc-tenders/src/accommodation/projections.ts | local projection/event dependency | should move into WorkStay later | Same pattern as vacancy. | | services/svc-tenders/src/repository.ts | vacancy/accommodation compatibility repositories | root compatibility dependency | should stay temporary for now | Root repository still hosts compatibility calls for older consumers, but active routes no longer depend on it. | | services/svc-tenders/src/vacancy/readRepository.ts | legacy vacancies table | public catalog fallback dependency | unresolved | This is the largest active dual-truth blocker for extraction. | | services/svc-tenders/src/accommodation/compatibilityReadRepository.ts | legacy accommodations table | compatibility catalog dependency | should stay temporary for now | Not preferred route-time truth, but still present for old root consumers. | | services/api/src/routes/vacancies.ts, services/api/src/routes/vacancy-postings.ts, services/api/src/routes/vacancy-applications.ts, owner vacancy routes | VACANCIES_SERVICE_URL ?? TENDERS_SERVICE_URL | gateway env seam | can remain shared after extraction | Vacancy already has a credible API-first extraction seam. | | services/api/src/routes/accommodations.ts, owner accommodation read routes | ACCOMMODATIONS_SERVICE_URL ?? TENDERS_SERVICE_URL | gateway env seam | can remain shared after extraction | Accommodation public and owner read routes already have their own env seam. | | services/api/src/routes/accommodation-listings.ts | TENDERS_SERVICE_URL | gateway env seam | should become API/service contract | Accommodation listing mutations/bookings still point only at TENDERS_SERVICE_URL, so the extraction seam is incomplete. | | services/api/src/routes/accommodation-bookings.ts | TENDERS_SERVICE_URL | gateway env seam | should become API/service contract | Same blocker: no accommodation-only env seam for booking writes. | | services/api/src/routes/my-accommodation-bookings.ts | TENDERS_SERVICE_URL | gateway env seam | should become API/service contract | Applicant booking reads still follow the legacy host target. | | apps/web/src/portal/api.ts | /api/v1/vacancies, /api/v1/vacancy-postings, /api/v1/vacancy-applications | web client → gateway dependency | acceptable shared dependency after extraction | Frontend already consumes gateway routes rather than service-local internals. | | apps/web/src/portal/api.ts | fallback VACANCY_CATALOG / ACCOMMODATION_CATALOG | UI fallback/catalog dependency | should move into WorkStay later or be retired | Fallback behavior is useful for UX resilience, but it is not backend truth. | | apps/web/src/features/domains/accommodationCatalog.ts | VACANCY_CATALOG | nearby stay ↔ work UI composition | unresolved | Real product intent exists, but current implementation is frontend-only composition. | | apps/web/src/app/[locale]/(portal)/workforce/page.tsx | apps/web/src/features/domains/mockData.ts | UI mock dependency | should move into WorkStay later only after backend exists | This is not presently an extraction-ready backend surface. | | apps/web/src/features/map/layers/accommodationsLayer.ts, vacancy/workforce map layers | frontend mock datasets | map/geospatial dependency | unresolved | Map surfaces exist, but their data source is mock rather than backend contracts. | | future travel expansion | no current backend module found | travel integration dependency | unresolved | Future-facing only; no present code should be moved on this basis. |

Shared dependencies that look acceptable

These edges appear acceptable to remain shared after future extraction:

• gateway façade ownership in services/api
• auth/principal resolution behavior
• JWT / /auth/me identity expectations
• DB/bootstrap conventions at the runtime shell

Edges that should separate first

These are the most important “must separate or narrow” edges before a real WorkStay extraction:

1. vacancy public fallback dependence on legacy vacancies
2. accommodation mutation/read gateway routes still hard-wired to TENDERS_SERVICE_URL
3. root TendersRepository compatibility hosting for vacancy/accommodation residue
4. frontend-only nearby/workforce composition that currently has no backend contract

Notes

• The future combined platform boundary is easier to justify for vacancy + accommodation than for workforce + nearby + travel.
• Current code truth supports “WorkStay candidate platform” as a strategic direction, but not yet as a unified extracted package.