svc-tenders Function Surface Map
Purpose
This note documents the exported and local function surfaces clarified in Cleanup Sprint 31 for the dense route/support cluster in svc-tenders.
Focus:
- which functions are exported route builders
- which functions are exported support builders
- which functions are exported support-facing helpers
- which functions stay local/private implementation detail
Labels used here:
VERIFIEDREALTRANSITIONAL
declarationRouteSupport.ts
Module:
Exported functions:
canCheckAuctionDeclaration(...)canCheckTenderDeclaration(...)buildTenderDeclarationRouteSupport(...)buildAuctionDeclarationRouteSupport(...)
Local/private helpers:
getAuctionDeclarationCapabilities(...)hasAuctionDeclarationCapability(...)getTenderDeclarationCapabilities(...)hasTenderDeclarationCapability(...)parseAuctionDeclarationEvidenceGroupKey(...)parseTenderDeclarationEvidenceGroupKey(...)
Surface classification:
canCheck*: support-facing exported helperbuild*RouteSupport: exported support builder- remaining helpers: private implementation helpers
Transitional/asymmetry notes:
VERIFIED- this module is intentionally asymmetric with
kesRouteSupport.ts - it exports both builders and broader visibility-gate helpers because adjacent tender/auction route-support modules reuse those checks
kesRouteSupport.ts
Module:
Exported functions:
buildKesRouteSupport(...)
Local/private helpers:
- none
Surface classification:
buildKesRouteSupport(...): exported support builder
Transitional/asymmetry notes:
VERIFIED- this module has the narrowest function surface in the cluster
- unlike declaration support, it exports no reusable helper functions
registerTenderDeclarationRoutes.ts
Module:
Exported functions:
registerTenderDeclarationRoutes(...)
Local/private helpers:
- none
Surface classification:
registerTenderDeclarationRoutes(...): exported route builder
Notes:
VERIFIED- module complexity is in route flow, not helper sprawl
registerAuctionDeclarationRoutes.ts
Module:
Exported functions:
registerAuctionDeclarationRoutes(...)
Local/private helpers:
- none
Surface classification:
registerAuctionDeclarationRoutes(...): exported route builder
Transitional/asymmetry notes:
VERIFIED- file density comes from composed transitional repository use and output-allocation colocation, not local helper count
registerKesRoutes.ts
Module:
Exported functions:
registerKesRoutes(...)
Local/private helpers:
parseKesOrchestratorListOptions(...)parseKesRole(...)parseKesCaseState(...)generateKesOrchestratorId(...)
Surface classification:
registerKesRoutes(...): exported route builderparseKesOrchestratorListOptions(...): local query/list shaping helperparseKesRole(...): local query/list shaping helperparseKesCaseState(...): local query/list shaping helpergenerateKesOrchestratorId(...): local convenience helper
Transitional/asymmetry notes:
VERIFIED- this is the only target route module that still has a real local helper cluster
- that asymmetry is real and should stay visible
Current Asymmetry
VERIFIED
The cluster is intentionally not uniform:
- declaration support exports builders plus two reusable broader-gate helpers
- KES support exports only one builder
- tender and auction declaration routes export only route builders
- KES route module exports a builder and keeps a small private helper cluster
That is current code reality, not a documentation accident.