svc-tenders Module Purpose Map

Purpose

This note documents the top-of-file module-purpose classifications added in Cleanup Sprint 28 for the densest route modules and their directly paired support files in svc-tenders.

Focus:

• whether a file is route flow, support assembly, composed/transitional, or unresolved/mixed
• what the file depends on
• what asymmetry or transitional hosting remains visible at the file boundary

Labels used here:

• VERIFIED
• REAL
• TRANSITIONAL
• UNRESOLVED

registerTenderDeclarationRoutes.ts

File:

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

Module purpose:

• Tender declaration route flow

Classification:

• route flow module

Key dependencies:

• tender declaration domain/state-machine helpers from @kvary/core/tender/declaration
• tender declaration validation helpers/schemas from ../validation
• narrowed declaration repository port from ../repository
• shell-owned auth and evidence-storage inputs

Notes:

• VERIFIED
• mostly dedicated route boundary
• not currently composed from unresolved repository surfaces
• still depends on shell-owned upload/storage infrastructure for evidence flow

registerAuctionDeclarationRoutes.ts

File:

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

Module purpose:

• Auction declaration route flow plus colocated output-allocation admin surface

Classification:

• route flow module
• composed transitional boundary

Key dependencies:

• auction declaration domain/state-machine helpers from @kvary/core/auction/declaration
• output-allocation normalization from @kvary/core/auction/allocation
• auction declaration validation helpers/schemas from ../validation
• composed repository port from ../repository
• shell-owned auth and evidence-storage inputs

Notes:

• VERIFIED
• this is the clearest unresolved mixed route boundary among the dense modules
• declaration-owned flow and unresolved output-allocation admin flow still share the file intentionally

registerKesRoutes.ts

File:

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

Module purpose:

• KES route flow for case ingress, control-plane reads, orchestration actions, and payment-sensitive actions

Classification:

• route flow module
• transitional/composed boundary

Key dependencies:

• KES action and case validation schemas from ../validation
• root-repository-derived KES repository port from ../repository
• shell auth typing from ../http/authTypes
• KES route support bundle

Notes:

• VERIFIED
• structurally separate route flow, but still hosted over a root-repository-derived persistence slice
• stricter payment/KYC/signature gating is applied here, not in the support module

declarationRouteSupport.ts

File:

• services/svc-tenders/src/routes/support/declarationRouteSupport.ts

Module purpose:

• Declaration support assembly for tender and auction declaration route modules

Classification:

• support assembly module
• shell-adjacent transitional boundary

Key dependencies:

• route support types from the tender and auction declaration route modules
• declaration capability types from @kvary/core
• evidence-group key types from ../../repository
• request-intent helper from ./requestIntentSupport

Notes:

• VERIFIED
• owns capability derivation and evidence-group parsing
• does not own route flow, readiness decisions, or stricter mutation sequencing
• still depends on shell-owned auth/upload helpers passed in from the service shell

kesRouteSupport.ts

File:

• services/svc-tenders/src/routes/support/kesRouteSupport.ts

Module purpose:

• KES support assembly for auth/parser inputs and KES-specific ingress helpers

Classification:

• support assembly module
• shell-adjacent transitional boundary

Key dependencies:

• KES route support type from ../registerKesRoutes
• Express request typing

Notes:

• VERIFIED
• bundles shared shell parsers/auth helpers with KES-specific ingress helpers
• does not decide which endpoints are stricter
• route flow still decides where payment-sensitive signature/KYC gates apply

Current Asymmetry

VERIFIED

The five files are intentionally not symmetrical:

• tender declaration routes are the cleanest dedicated declaration flow boundary
• auction declaration routes remain mixed because output allocations are still unresolved
• KES routes are structurally separated but still transitional at the persistence boundary
• declaration support owns capability derivation and evidence parsing
• KES support mostly assembles shell helpers plus KES-specific ingress helpers

That asymmetry is real and should stay visible.