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 | | write-model dependency | should move into WorkStay later | Durable vacancy lifecycle is a clear candidate-owned dependency. |
| | shell / principal helpers | auth ingress dependency | can remain shared after extraction | Shared auth/principal ingress is a believable Kvary backbone dependency. |
| | preferred read-model dependency | should move into WorkStay later | Public listing/detail and booking/reservation reads already use the preferred accommodation read repository. |
| | owner read-model dependency | should move into WorkStay later | Owner listing reads are real but asymmetric from public reads. |
| | write-model dependency | should move into WorkStay later | Durable listing and booking writes are WorkStay-candidate material. |
| | shell auth/parser helpers | auth ingress dependency | can remain shared after extraction | Similar to vacancy support: route-local mapping, shell-owned ingress. |
| | + | local projection/event dependency | should move into WorkStay later | Real local event/projection infrastructure, but not yet a shared cross-service contract. |
| | + | local projection/event dependency | should move into WorkStay later | Same pattern as vacancy. |
| | 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. |
| | legacy table | public catalog fallback dependency | unresolved | This is the largest active dual-truth blocker for extraction. |
| | legacy table | compatibility catalog dependency | should stay temporary for now | Not preferred route-time truth, but still present for old root consumers. |
| , , , owner vacancy routes | | gateway env seam | can remain shared after extraction | Vacancy already has a credible API-first extraction seam. |
| , owner accommodation read routes | | gateway env seam | can remain shared after extraction | Accommodation public and owner read routes already have their own env seam. |
| | | gateway env seam | should become API/service contract | Accommodation listing mutations/bookings still point only at , so the extraction seam is incomplete. |
| | | gateway env seam | should become API/service contract | Same blocker: no accommodation-only env seam for booking writes. |
| | | gateway env seam | should become API/service contract | Applicant booking reads still follow the legacy host target. |
| | , , | web client → gateway dependency | acceptable shared dependency after extraction | Frontend already consumes gateway routes rather than service-local internals. |
| | fallback / | 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. |
| | | nearby stay ↔ work UI composition | unresolved | Real product intent exists, but current implementation is frontend-only composition. |
| | | UI mock dependency | should move into WorkStay later only after backend exists | This is not presently an extraction-ready backend surface. |
| , 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. |