svc-tenders Route Support Boundary
Purpose
This note records the route-support cleanup through Sprint 17 inside services/svc-tenders.
The goal was narrow and structural:
- reduce broad inline support-bundle assembly in services/svc-tenders/src/server.ts
- keep route behavior unchanged
- make support responsibilities easier to inspect
Labels used here:
VERIFIEDREALTRANSITIONAL
Current support modules
routes/support/vacancyRouteSupport.ts
File:
Responsibility:
- assembles the vacancy route support bundle
- owns the vacancy top-level detail key set
- groups vacancy capability checks with the route-facing support shape
Used by route groups:
Status:
VERIFIEDTRANSITIONAL
Why transitional:
- underlying auth, parsing, and error mapping functions still live in the service shell
- this module narrows the assembly boundary, not the final ownership boundary
routes/support/accommodationRouteSupport.ts
File:
Responsibility:
- assembles the accommodation route support bundle
- owns the accommodation top-level detail key set
- keeps public-mapping helpers grouped with the route-facing support shape
Used by route groups:
Status:
VERIFIEDTRANSITIONAL
routes/support/tenderRouteSupport.ts
File:
Responsibility:
- assembles the tender route support bundle
- keeps tender list parsing, declaration-check gating, portal/detail mapping, and intent-id support explicit at the route boundary
Used by route groups:
Status:
VERIFIEDTRANSITIONAL
routes/support/auctionRouteSupport.ts
File:
Responsibility:
- assembles the auction route support bundle
- keeps auction list parsing and declaration-check gating explicit at the route boundary
Used by route groups:
Status:
VERIFIEDTRANSITIONAL
routes/support/icpiRouteSupport.ts
File:
Responsibility:
- assembles the ICPI route support bundle
- keeps ICPI query parsing support explicit without merging it into generic shared helpers
Used by route groups:
Status:
VERIFIEDTRANSITIONAL
routes/support/butkhuziRouteSupport.ts
File:
Responsibility:
- assembles the Butkhuzi route support bundle
- keeps Butkhuzi query parsing support explicit without folding it into a generic route helper
Used by route groups:
Status:
VERIFIEDTRANSITIONAL
routes/support/kesRouteSupport.ts
File:
Responsibility:
- assembles the KES route support bundle
- keeps KES parser support and KYC/signature gate support explicit at the route boundary
Used by route groups:
Status:
VERIFIEDTRANSITIONAL
routes/support/declarationRouteSupport.ts
File:
Responsibility:
- assembles tender declaration route support
- assembles auction declaration route support
- keeps shared declaration-route support shape explicit:
- auth gate
- intent parsing
- upload middleware bridge
- declaration capability checks
- evidence group parsing
Used by route groups:
- services/svc-tenders/src/routes/registerTenderDeclarationRoutes.ts
- services/svc-tenders/src/routes/registerAuctionDeclarationRoutes.ts
Status:
VERIFIEDTRANSITIONAL
What remains broad
Auth/session helper hosting
Still hosted in:
Examples:
requireServiceAuth(...)requireActivePrincipal(...)- token verification / principal resolution helpers
Status:
VERIFIEDREAL
Reason still broad:
- these helpers are still shared across many route groups
- moving them this sprint would have been a bigger service-shell refactor than a support-bundle cleanup
Shared query/parser helpers
Still hosted in:
Examples:
parsePositiveInt(...)parseOptionalInt(...)parseOptionalString(...)parseOptionalUpper(...)clampPositiveInt(...)- tender/auction list-option parsers
Used by:
- tender routes
- auction routes
- KES routes
- ICPI routes
- Butkhuzi routes
- declaration routes indirectly
Status:
VERIFIEDREAL
Reason still broad:
- these are still cross-route service-shell helpers
- they were not yet split into narrower support modules in this sprint
Signature / KYC boundary helpers
Still hosted in:
Examples:
ensureThirdPartyKycBoundary(...)verifyIncomingSignatureGate(...)
Used by:
Status:
VERIFIEDREAL
Reason still broad:
- KES remains the main consumer
- final KES/shared-backbone boundary is still transitional
What was removed or narrowed
Sprint 16-17 removed broad inline support-object assembly from server.ts for:
- vacancy routes
- accommodation routes
- tender routes
- auction routes
- ICPI routes
- Butkhuzi routes
- KES routes
- tender declaration routes
- auction declaration routes
This did not remove the underlying helpers themselves.
It narrowed:
- where route-facing support objects are assembled
- where route-specific key sets are defined
- how clearly route support responsibilities are named
What remains unresolved
- whether core auth/query helper hosting should later move into dedicated HTTP support modules
- whether KES-specific support should split further from the service shell
- whether tender/auction list-route support should also get dedicated builders later
Result
After Sprint 17:
server.tsis less cluttered with inline support-object literals across all extracted route groups- vacancy/accommodation/tender/auction/ICPI/Butkhuzi/KES/declaration support boundaries are more explicit
- route modules still behave exactly the same
- future extraction work has a cleaner support-layer starting point