Purpose

This document maps the current dependency edges around ICPI and classifies whether each edge is:

• acceptable shared dependency after extraction
• something that should become an API/service contract
• something that should be duplicated or re-homed locally
• something that should be removed before extraction
• unresolved

Dependency Edges

| Dependency edge | Current source -> target | Type | Verdict | Notes | | --- | --- | --- | --- | --- | | ICPI route flow -> ICPI repository | registerIcpiRoutes.ts -> src/icpi/repository.ts | route -> repository | must move together | This is the core ICPI backend seam | | ICPI route flow -> ICPI support builder | registerIcpiRoutes.ts -> routes/support/icpiRouteSupport.ts | route -> support | must move together or collapse locally | Useful only as long as shell helpers remain external | | ICPI support builder -> shell auth helper | icpiRouteSupport.ts -> requireServiceAuth in server.ts | auth/principal | acceptable shared dependency after extraction, but direct shell dependency must be replaced | Shared auth is fine; server.ts helper reach-in is not | | ICPI support builder -> shell parser helpers | icpiRouteSupport.ts -> parseOptionalInt, parseOptionalString, parseOptionalUpper, parsePositiveNumber, clampPositiveInt in server.ts | parser/helper | should be duplicated locally inside ICPI later | These are generic enough to copy or re-home | | ICPI route flow -> mixed validation module | registerIcpiRoutes.ts -> upsertIcpiPriceSchema in validation.ts | validation/schema | should be removed before extraction | Current schema home is mixed-domain | | ICPI route flow -> root repository type exports | registerIcpiRoutes.ts -> ICPI types in repository.ts | type surface | should be removed before extraction | Mixed root type hosting is a real extraction blocker | | ICPI repository -> root repository type exports | src/icpi/repository.ts -> ICPI types in repository.ts | type surface | should be removed before extraction | Persistence already moved; types did not | | Root repository -> ICPI repository | repository.ts -> src/icpi/repository.ts | compatibility delegation | should be removed before extraction | Compatibility-only, not core ICPI ownership | | Service shell -> ICPI route registration | server.ts -> registerIcpiRoutes(...) | shell/server wiring | should be converted to API/service contract | Current monolith host seam | | Service shell -> ICPI repository instantiation | server.ts -> new IcpiRepository(pool) | shell/server wiring | should be converted to API/service contract | Current host bootstrap only | | Gateway -> ICPI host | services/api/src/routes/icpi.ts -> ICPI_SERVICE_URL ?? TENDERS_SERVICE_URL | API/service contract | acceptable shared dependency after extraction | This is the best current extraction seam | | Gateway upsert auth -> shared auth | requireGatewayAuth -> auth service /auth/me | auth/principal | acceptable shared dependency after extraction | Shared Kvary backbone concern | | Web portal client -> gateway ICPI routes | apps/web/src/portal/api.ts -> /api/v1/icpi/* | UI/client -> API | acceptable shared dependency after extraction | Preferred public contract for web should stay here | | ICPI portal page -> portal client | apps/web/src/app/[locale]/(portal)/icpi/page.tsx -> apps/web/src/portal/api.ts | UI consumption | acceptable shared dependency after extraction | Product-distinct UI already exists | | ICPI -> Kafka / outbox / KES event runtime | no direct edge found | event/runtime | acceptable as no dependency | No ICPI topic, outbox trigger, or consumer was found | | ICPI -> upload/storage | no direct edge found | upload/storage | acceptable as no dependency | No storage blocker | | Web contract types -> service contract types | apps/web/src/portal/api.ts local ICPI types vs service-side ICPI types | contract/type duplication | unresolved | Strong drift risk unless contracts are shared or generated |

Shared-Dependency Verdicts

Acceptable shared after extraction

VERIFIED

• gateway route ownership in services/api
• shared auth/session/principal resolution
• shared JWT verification rules
• public web -> gateway contract

Must separate before or during extraction

VERIFIED

• direct type imports from services/svc-tenders/src/repository.ts
• direct validation import from services/svc-tenders/src/validation.ts
• direct parser/auth helper import path that effectively reaches into services/svc-tenders/src/server.ts
• root-repository compatibility delegation

Best copied locally later

VERIFIED

• the tiny parser helpers currently passed through buildIcpiRouteSupport(...)

Those helpers are not worth keeping coupled to svc-tenders once ICPI starts to move.

Edge Summary

• Strongest keep-shared edge: services/api gateway proxy plus shared auth
• Strongest must-cut edge: ICPI types and schema rooted in mixed svc-tenders files
• Strongest non-issue: Kafka/outbox/event runtime, because ICPI is currently not tied into it