svc-tenders Route Local Helper Map

Purpose

This note documents the remaining route-local helper clusters adjacent to the densest route modules in svc-tenders after Cleanup Sprint 26.

Focus:

• KES list/query helpers
• declaration command/preview normalization helper usage
• route-local convenience helpers

Labels used here:

• VERIFIED
• REAL
• TRANSITIONAL

registerTenderDeclarationRoutes.ts

Route module:

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

Local helper cluster:

• none remaining in-file

Purpose:

• this module now relies on imported helpers instead of local helper bodies

Imported helper roles used nearby:

• preview / normalization helper
  • normalizeTenderDeclarationFormData(...)
  • buildTenderDeclarationPreviewResult(...)
  • buildTenderDeclarationValidationResult(...)
• command payload / guard helper
  • declareTenderCommandSchema
  • buildTenderDeclaredEvent(...)
  • canMarkTenderReady(...)
  • canDeclareTender(...)

Classification:

• preview/normalization helper usage
• command payload/helper usage

Stayed local or moved:

• no local helper cluster to move
• helper usage remains imported and route-adjacent

Notes:

• VERIFIED
• REAL
• this is intentionally asymmetric relative to KES
• the dense parts here are route flow + imported helper usage, not a leftover local helper block

registerAuctionDeclarationRoutes.ts

Route module:

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

Local helper cluster:

• none remaining in-file

Purpose:

• like tender declarations, this module relies on imported helpers rather than local helper functions

Imported helper roles used nearby:

• preview / normalization helper
  • normalizeAuctionAnnouncementFormData(...)
  • buildAuctionAnnouncementPreviewResult(...)
  • buildAuctionAnnouncementValidationResult(...)
  • normalizeOutputAllocationFormData(...)
• command payload / guard helper
  • declareAuctionCommandSchema
  • buildAuctionAnnouncedEvent(...)
  • canMarkReady(...)
  • canDeclareAuction(...)

Classification:

• preview/normalization helper usage
• command payload/helper usage

Stayed local or moved:

• no local helper cluster to move
• helper usage remains imported and route-adjacent

Unresolved / transitional notes:

• VERIFIED
• TRANSITIONAL
• helper complexity is not the main issue here
• the real remaining complexity is transitional repository composition with output allocations

registerKesRoutes.ts

Route module:

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

Local helper cluster: query/list shaping

Helpers:

• parseKesOrchestratorListOptions(...)
• parseKesRole(...)
• parseKesCaseState(...)

Purpose:

• shape Express query input into repository-facing KES list/filter options

Classification:

• query/list shaping helper

Stayed local or moved:

• stayed local

Why:

• these helpers are only used by KES read/control-plane routes
• there is no clearer shared home than the KES route module itself

Local helper cluster: route-local convenience

Helper:

• generateKesOrchestratorId(...)

Purpose:

• generate prefixed KES IDs used by route-side command creation

Classification:

• route-local convenience helper

Stayed local or moved:

• stayed local

Why:

• prefix behavior is route/action specific
• moving it would not improve truth or reuse

Unresolved / transitional notes:

• VERIFIED
• TRANSITIONAL
• these helpers are not the ownership problem
• the transitional part remains the repository input behind KES routes, not the local helper cluster itself

Honest asymmetry

VERIFIED

The dense route modules do not have matching local-helper shapes:

• tender declaration routes: no remaining local helper cluster
• auction declaration routes: no remaining local helper cluster
• KES routes: still have a legitimate local helper cluster for query/list shaping and ID generation

That asymmetry is real and should stay visible.