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, Owner Role, Last Review Date, Next Review Date, Change Log
Status: ACTIVE
Sprint: Extraction Prep Sprint 44
Scope: current ICPI code, data, route, and dependency boundary while hosted inside services/svc-tenders
This document defines the current extraction-readiness truth for ICPI.
It is not a service-split plan by itself. It records:
svc-tendersVERIFIED: directly confirmed in code, migrations, route wiring, or runtime docs.
INFERRED: strongly suggested by code shape, but not fully proven end-to-end.
UNVERIFIED: not strong enough to treat as fact.
REAL: durable backend behavior exists.
MIXED: real behavior exists, but boundary or hosting is mixed.
UI-FIRST: primarily UI/client-owned consumption.
SHELL: mostly shell/bootstrap/support assembly rather than domain ownership.
MISSING: no real surface found.
VERIFIED: ICPI is a real backend capability, not a mock or placeholder.VERIFIED: ICPI already has one of the cleanest route and persistence boundaries in svc-tenders.VERIFIED: ICPI is still temporarily hosted inside svc-tenders; that hosting is not proof that svc-tenders is the right long-term owner.VERIFIED: the strongest existing extraction seam is the gateway proxy in services/api, because it already supports ICPI_SERVICE_URL.VERIFIED: the main blockers are not data-shape blockers. They are temporary hosting blockers:
VERIFIED: no ICPI-specific Kafka, outbox, or KES/event-backbone dependency was found.| Element | Evidence | Confidence / State | Shape | Ownership verdict | Notes |
| --- | --- | --- | --- | --- | --- |
| services/svc-tenders/src/icpi/repository.ts | dedicated ICPI repository class over icpi_price_points | VERIFIED / REAL | REAL | ICPI-owned, temporarily hosted in svc-tenders | Strongest current code owner for ICPI persistence |
| services/svc-tenders/src/routes/registerIcpiRoutes.ts | dedicated route module for /icpi/* | VERIFIED / REAL | REAL | ICPI-owned HTTP surface, temporarily hosted in svc-tenders | Public reads plus service-auth-gated upsert |
| services/svc-tenders/src/routes/support/icpiRouteSupport.ts | ICPI-specific support builder narrowing shell helpers | VERIFIED / SHELL | SHELL | temporary-hosted-in-svc-tenders | Adapter layer, not ICPI domain logic |
| services/svc-icpi/migrations/0007_icpi_price_points.sql | creates icpi_price_points | VERIFIED / REAL | REAL | ICPI-owned persistence | Single clean table family |
| services/svc-icpi/migrations/0008_icpi_latest_lookup_index.sql | latest lookup index | VERIFIED / REAL | REAL | ICPI-owned persistence | Lookup optimization stays with ICPI table family |
| services/svc-tenders/src/server.ts ICPI wiring | direct IcpiRepository instantiation and registerIcpiRoutes(...) call | VERIFIED / SHELL | SHELL | temporary-hosted-in-svc-tenders | Hosting seam, not long-term domain owner |
| ICPI type exports in services/svc-tenders/src/repository.ts | IcpiQuarter, IcpiPricePoint, UpsertIcpiPriceInput, IcpiListOptions, IcpiSuggestion | VERIFIED / MIXED | MIXED | ambiguous temporary hosting | Type surface is still rooted in the mixed repository file |
| ICPI compatibility delegation in services/svc-tenders/src/repository.ts | thin pass-through methods to IcpiRepository | VERIFIED / MIXED | MIXED | temporary-hosted-in-svc-tenders | Not a real ownership signal; mostly compatibility residue |
| services/api/src/routes/icpi.ts | dedicated gateway proxy with ICPI_SERVICE_URL ?? TENDERS_SERVICE_URL | VERIFIED / REAL | REAL | shared-Kvary-owned | Best current extraction seam |
| apps/web/src/portal/api.ts ICPI client helpers | fetchIcpiPrices, fetchIcpiSuggestions, fetchIcpiLatestPrice | VERIFIED / UI-FIRST | UI-FIRST | shared/web consumer | Uses gateway contract, not direct DB/service coupling |
| apps/web/src/app/[locale]/(portal)/icpi/page.tsx and country alias page | dedicated ICPI portal page | VERIFIED / UI-FIRST | UI-FIRST | web consumer, not backend owner | Confirms product-distinct UI surface exists |
| ICPI upsert UI consumer | no web consumer found for /icpi/upsert | VERIFIED / MISSING | MISSING | no verified UI owner | Current ingest path appears service/admin-facing only |
| ICPI Kafka/topic usage | no ICPI topic or outbox trigger found | VERIFIED / MISSING | MISSING | none | This is a major reason ICPI is extraction-friendly |
| ICPI upload/storage dependency | no ICPI upload/storage surface found | VERIFIED / MISSING | MISSING | none | No MinIO/evidence/storage blocker here |
VERIFIED
These are the minimum surfaces that already behave like an ICPI domain:
/icpi/* in svc-tendersIcpiRepository persistence moduleicpi_price_points table and lookup indexesThese should be treated as the real ICPI boundary even though they still run inside the svc-tenders process today.
VERIFIED
These dependencies are real, but they are not reasons to keep ICPI inside svc-tenders forever:
services/apisvc-auth /auth/me principal resolution behind requireServiceAuthsvc-tenders shellThese are acceptable shared backbone concerns after extraction, but ICPI should consume them through contracts or copied/re-homed helpers rather than through direct svc-tenders shell wiring.
svc-tendersVERIFIED
services/svc-tenders/src/server.tsservices/svc-tenders/src/repository.tsservices/svc-tenders/src/validation.tsIcpiRepositoryNone of these are strong ownership evidence for svc-tenders.
They are hosting and compatibility residue.
VERIFIED
services/svc-tenders/src/icpi/repository.tsservices/svc-tenders/src/routes/registerIcpiRoutes.tsservices/svc-tenders/src/routes/support/icpiRouteSupport.tsservices/svc-tenders/src/validation.tsservices/svc-tenders/src/repository.tsVERIFIED
icpi_price_points0007 and 0008VERIFIED
IcpiQuarterIcpiPricePointUpsertIcpiPriceInputIcpiListOptionsIcpiSuggestionBest extraction-ready destination:
VERIFIED
buildIcpiRouteSupport(...)requireServiceAuthThese do not need to stay in svc-tenders.
They either need:
VERIFIED
services/apiThese are acceptable shared Kvary backbone dependencies after extraction.
VERIFIED
services/api/src/routes/icpi.tsICPI_SERVICE_URLThis is the safest existing external seam and should remain the public entry point even after ICPI leaves svc-tenders.
| Blocker | Severity | Why it blocks clean extraction | How to remove it | Type |
| --- | --- | --- | --- | --- |
| ICPI types still export from mixed services/svc-tenders/src/repository.ts | MEDIUM | Route, repository, and monorepo callers still import ICPI contracts from a non-ICPI file | move ICPI contracts into an ICPI-owned module/package and update call sites | code-only |
| ICPI upsert validation lives in mixed services/svc-tenders/src/validation.ts | MEDIUM | Extraction would otherwise keep a mixed validation dependency edge | split ICPI schema into an ICPI-owned validation module | code-only |
| ICPI support builder still depends on shell-owned parser/auth helpers | MEDIUM | A future ICPI runtime cannot depend on svc-tenders/src/server.ts helper functions | copy or re-home parser/auth helpers behind a smaller interface | code-only |
| ICPI route hosting still happens in services/svc-tenders/src/server.ts | LOW | The runtime host is still the monolith even though the route boundary is clean | create an ICPI-local bootstrap module/package first, then point gateway at it later | code+infra |
| Web and service contracts are duplicated rather than shared | MEDIUM | apps/web/src/portal/api.ts defines its own ICPI shapes, which creates future drift risk | promote ICPI API contracts into a shared package or generated contract layer | code+docs |
| Gateway still falls back from ICPI_SERVICE_URL to TENDERS_SERVICE_URL | LOW | This is a good seam, but it still encodes temporary hosting | keep the route, but make dedicated ICPI_SERVICE_URL the expected deployment target when extraction begins | code+infra |
VERIFIED
The safest path is:
Why this is safest:
HIGHHIGHLOWMEDIUMBest summary:
ICPI is ready for real extraction preparation now because the hard part is no longer domain ambiguity. The remaining work is mostly about removing temporary monolith hosting edges without inventing architecture that does not yet exist.