Purpose

This note documents the import surfaces of the densest route modules in svc-tenders after Cleanup Sprint 27.

Focus:

• which imports are domain/state-machine logic
• which are validation/schema dependencies
• which are repository-port types
• which are shell/infra inputs
• which are route-local convenience imports

Labels used here:

• VERIFIED
• REAL
• TRANSITIONAL

registerTenderDeclarationRoutes.ts

Route module:

• services/svc-tenders/src/routes/registerTenderDeclarationRoutes.ts

Import cluster: route runtime types

Purpose:

• Express request/response/next function typing

Kind:

• route-local runtime typing

Imports:

• Express
• NextFunction
• Request
• Response

Import cluster: domain / state-machine

Purpose:

• tender declaration state-machine helpers and command/event typing

Kind:

• domain/state-machine

Imports:

• buildTenderDeclaredEvent
• canDeclareTender
• canMarkTenderReady
• normalizeTenderDeclarationFormData
• TenderDeclarationCapability
• DeclareTenderCommand

Notes:

• this module is dense partly because it directly uses domain/state-machine helpers at route level

Import cluster: shell / infra inputs

Purpose:

• service-shell auth context and shell-owned evidence storage

Kind:

• shell infra

Imports:

• RequestWithAuth
• DeclarationEvidenceStorage

Import cluster: repository / repository-port

Purpose:

• typed repository port boundary for declaration persistence

Kind:

• repository / repository-port

Imports:

• TenderDeclarationEvidenceGroupKey
• TendersRepository

Notes:

• actual route input is a narrowed port derived from TendersRepository

Import cluster: route-adjacent validation schemas / helpers

Purpose:

• request schema parsing plus route-side readiness/preview helpers

Kind:

• validation/schema

Imports:

• buildTenderDeclarationPreviewResult
• buildTenderDeclarationValidationResult
• checkTenderDeclarationReadinessSchema
• createTenderDeclarationDraftSchema
• declareTenderCommandSchema
• declareTenderSchema
• markTenderDeclarationReadySchema
• updateTenderDeclarationDraftSchema

Notable asymmetry:

• this route combines domain/state-machine imports and validation-helper imports in one file
• unlike KES, it does not have a significant remaining local helper cluster

registerAuctionDeclarationRoutes.ts

Route module:

• services/svc-tenders/src/routes/registerAuctionDeclarationRoutes.ts

Import cluster: route runtime types

Purpose:

• Express request/response/next function typing

Kind:

• route-local runtime typing

Import cluster: domain / state-machine

Purpose:

• auction declaration state-machine helpers, normalization, and command typing

Kind:

• domain/state-machine

Imports:

• buildAuctionAnnouncedEvent
• canDeclareAuction
• canMarkReady
• normalizeAuctionAnnouncementFormData
• AuctionDeclarationCapability
• DeclareAuctionCommand
• AuctionAnnouncementFormData
• normalizeOutputAllocationFormData

Notes:

• this import surface is denser than tender because it also pulls in output-allocation normalization

Import cluster: shell / infra inputs

Purpose:

• service-shell auth context and shell-owned evidence storage

Kind:

• shell infra

Imports:

• RequestWithAuth
• DeclarationEvidenceStorage

Import cluster: repository / repository-port

Purpose:

• typed repository port boundary for the composed auction declaration surface

Kind:

• repository / repository-port

Imports:

• AuctionDeclarationEvidenceGroupKey
• TendersRepository

Transitional note:

• actual route input is a composed transitional port, not a single clean repository owner

Import cluster: route-adjacent validation schemas / helpers

Purpose:

• request schema parsing plus route-side readiness/preview helpers

Kind:

• validation/schema

Imports:

• buildAuctionAnnouncementPreviewResult
• buildAuctionAnnouncementValidationResult
• checkAuctionDeclarationReadinessSchema
• createAuctionDeclarationDraftSchema
• createOutputAllocationSchema
• declareAuctionAnnouncementSchema
• declareAuctionCommandSchema
• markAuctionDeclarationReadySchema
• updateAuctionDeclarationDraftSchema
• updateOutputAllocationSchema

Notable asymmetry:

• auction declaration imports both declaration and output-allocation concerns
• that asymmetry reflects transitional composition, not import sloppiness

registerKesRoutes.ts

Route module:

• services/svc-tenders/src/routes/registerKesRoutes.ts

Import cluster: route-local convenience

Purpose:

• local ID generation helper support

Kind:

• route-local

Imports:

• randomUUID

Notes:

• KES is the only one of the three dense modules that still needs this explicit local convenience import

Import cluster: route runtime types

Purpose:

• Express request/response/next function typing

Kind:

• route-local runtime typing

Import cluster: shell / infra inputs

Purpose:

• auth context type used by authenticated KES action routes

Kind:

• shell infra

Imports:

• RequestWithAuth

Import cluster: repository / repository-port

Purpose:

• typed repository port boundary for KES orchestration persistence

Kind:

• repository / repository-port

Imports:

• KesOrchestratorCaseListOptions
• TendersRepository

Transitional note:

• this route still consumes a root-repository slice rather than a dedicated KES repository

Import cluster: route-adjacent validation schemas

Purpose:

• request schema parsing for case creation, control mutations, and payment-sensitive actions

Kind:

• validation/schema

Imports:

• approveKesOrchestratorLandownerSchema
• approveKesOrchestratorPaymentSchema
• assignKesOrchestratorTaskSchema
• closeKesOrchestratorCaseSchema
• confirmKesOrchestratorFundingSchema
• createKesOrchestratorCaseSchema
• publishKesOrchestratorAuctionSchema
• requestKesOrchestratorPaymentSchema
• settleKesOrchestratorPaymentSchema
• submitKesOrchestratorInspectionSchema
• upsertKesOrchestratorProcessMapSchema

Notable asymmetry:

• unlike the declaration route modules, KES does not import domain/state-machine helpers here
• its dense import surface is dominated by schemas, repository-port typing, and a local convenience import

Honest asymmetry

VERIFIED

These import surfaces are not symmetric, and that is correct:

• tender declaration imports domain/state-machine helpers plus validation helpers
• auction declaration imports those same classes of helpers plus output-allocation normalization
• KES imports no domain/state-machine helper layer here; it is mostly schemas, repository-port typing, shell types, and a local convenience import

Trying to force one uniform import pattern across the three files would hide the real module roles.