svc-tenders Extraction Order
This document proposes a practical extraction sequence based on current code reality.
It does not assume immediate service splitting. The default strategy is:
Resolving locale, route permissions, and workspace projection.
Current scope: Guest
Category: 10_normative | Version: v1.0.0
Owner: DOCUMENT_CUSTODIAN | Review cycle: 90 days
Approval authority: GOVERNANCE_ADMIN
Documentation portal is read-only. Editing and mutation endpoints are disabled.
Kvary platform is originally created in Georgian. Where a Georgian version exists, Georgian is authoritative for platform UI, documentation, and legal interpretation.
Translations into other languages are provided for convenience. Some records may originate in other languages and carry their own source or legal locale for a specific flow, but where a Georgian version is available, the Georgian version prevails for platform-level wording and interpretation.
Metadata incomplete: Document ID, Version, Status, Owner Role, Last Review Date, Next Review Date, Change Log
svc-tenders Extraction OrderThis document proposes a practical extraction sequence based on current code reality.
It does not assume immediate service splitting. The default strategy is:
VERIFIED: one clean table family: icpi_price_pointsVERIFIED: low coupling to tender lifecycle, KES, and auctionsVERIFIED: gateway already supports ICPI_SERVICE_URL ?? TENDERS_SERVICE_URLVERIFIED: dedicated user-facing ICPI surface already exists in webrepository.tsrepository.tscode boundary firstAPI boundary firstservices/svc-tenders/src/server.ts /butkhuzi/*services/svc-tenders/src/repository.ts Butkhuzi methodsservices/api/src/routes/butkhuzi.tsVERIFIED: own table set: butkhuzi_norms, butkhuzi_chunksVERIFIED: gateway already supports BUTKHUZI_SERVICE_URL ?? TENDERS_SERVICE_URLVERIFIED: business lifecycle is distinct from tendersVERIFIED: current product use is still KES/admin-adjacent, so business ownership is less fully separated than ICPIrepository.tsAPI boundary firstservices/svc-tenders/src/vacancyservices/svc-tenders/src/accommodationservices/svc-tenders/src/server.tsservices/api/src/routes/vacancies.ts, vacancy-postings.ts, vacancy-applications.ts, accommodations.ts, accommodation-listings.ts, accommodation-bookings.tsVERIFIED: real write models and projection flows already existVERIFIED: product ownership is distinct from tender/procurementVERIFIED: gateway already has route-level separation and env indirection for vacancies/accommodationsVERIFIED: public vacancy reads still union new projections with legacy vacanciesVERIFIED: public accommodation discovery still reads legacy accommodationsVERIFIED: some accommodation booking-read endpoints still return empty arrays despite existing read-model codeVERIFIED: nearby jobs/stays coupling is still assembled at web level over mixed catalogsoutbox_events is local/in-process, not a clean shared event boundaryAccommodationReadRepositorycode boundary firstpackage boundary firstAPI boundary firstcode boundary firstservices/svc-tenders/src/server.ts and services/svc-tenders/src/repository.tsservices/api/src/auctions/*apps/web/src/ui/auctions/*VERIFIED: auctions are product-distinct from tenders long-termVERIFIED: there is already a dedicated public auction surface and internal declaration flowVERIFIED: public bidder mutation truth is still UI-first/session-backed in the web appVERIFIED: gateway and web still mix canonical reads with local-engine/fallback compatibilityVERIFIED: settlement/output allocation/entitlement boundaries are not yet cleanly separatedAPI boundary first is not safe yetcode boundary firstevent boundary first if auction events become first-classcode boundary firstservices/svc-tenders/src/server.tsservices/svc-tenders/src/repository.tsservices/svc-tenders/src/kafkaVERIFIED: this looks more like shared Kvary execution/runtime backbone than a tender-only or standalone customer-facing platformsvc-tenders as the host servicecode boundary firstpackage boundary firstshared backbone realignmentsvc-tendersThese are the parts with the strongest tender-specific invariants and the least ambiguity about current domain ownership.
packages/coreThese are better treated as shared Kvary backbone or shared contract capabilities, not independent product platforms.
services/svc-tenders/src/repository.ts into domain-owned persistence modules.services/svc-tenders/src/server.ts into domain route modules that mirror future platform boundaries.services/api env-based route indirection; it is already the best extraction seam currently present.