svc-tenders Route Cluster Entry Map

Purpose

This note documents the major route clusters in the densest svc-tenders route modules after Cleanup Sprint 35.

Focus:

• cluster entry points
• dominant handler sequence patterns
• broader versus stricter flow shape
• upload and ingress-sensitive differences

Labels used here:

• VERIFIED
• REAL
• TRANSITIONAL

registerTenderDeclarationRoutes.ts

Route module:

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

Cluster name:

• admin read

Dominant sequence pattern:

• parse -> auth -> broader visibility check -> repository read -> response

Classification:

• broader

Cluster name:

• draft authoring

Dominant sequence pattern:

• parse -> auth -> stricter mutation gate -> normalize -> repository write -> response

Classification:

• stricter

Cluster name:

• readiness / declare transitions

Dominant sequence pattern:

• parse -> auth -> broader or stricter helper -> readiness/state guard -> repository write -> response

Classification:

• broader and stricter mixed

Cluster name:

• evidence surface

Dominant sequence pattern:

• parse -> auth -> visibility/state check -> upload bridge or repository read -> response

Classification:

• upload
• broader read plus local state guard

Notable asymmetry:

• VERIFIED
• tender evidence upload stays on a broader visibility helper and adds a local DRAFT state guard instead of using the stricter mutation helper path

registerAuctionDeclarationRoutes.ts

Route module:

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

Cluster name:

• output-allocation admin surface

Dominant sequence pattern:

• parse -> auth -> broader read or stricter write helper -> normalization -> transitional repository handoff -> response

Classification:

• broader and stricter mixed
• transitional

Cluster name:

• admin read

Dominant sequence pattern:

• parse -> auth -> broader visibility check -> repository read -> response

Classification:

• broader

Cluster name:

• evidence surface

Dominant sequence pattern:

• parse -> auth -> stricter write or broader read helper -> upload/read handoff -> response

Classification:

• upload
• broader and stricter mixed

Cluster name:

• draft authoring

Dominant sequence pattern:

• parse -> auth -> stricter mutation gate -> normalize -> transitional repository write -> response

Classification:

• stricter
• transitional

Cluster name:

• readiness / announce transitions

Dominant sequence pattern:

• parse -> auth -> broader or stricter helper -> readiness/announce guard -> repository write -> response

Classification:

• broader and stricter mixed
• transitional

Notable asymmetry:

• VERIFIED
• auction evidence upload stays on the stricter mutation-helper path
• output-allocation administration remains colocated with declaration routes

Unresolved or transitional notes:

• TRANSITIONAL
• this remains the most composition-heavy route module in the cluster because declaration and output-allocation flows still share one boundary

registerKesRoutes.ts

Route module:

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

Cluster name:

• case entry

Dominant sequence pattern:

• auth -> parse -> light normalization -> repository write -> response

Classification:

• stricter write

Cluster name:

• operator read / control-plane surface

Dominant sequence pattern:

• parse query -> repository read/projection -> response shaping

Classification:

• broader

Cluster name:

• process-map mutation

Dominant sequence pattern:

• parse -> auth -> ordinary mutation flow -> repository write -> response

Classification:

• stricter write

Cluster name:

• case / task / inspection actions

Dominant sequence pattern:

• parse -> auth -> ordinary action guard/state validation -> repository write -> response

Classification:

• stricter write

Cluster name:

• payment-sensitive actions

Dominant sequence pattern:

• parse -> auth -> ingress verification -> repository/state validation -> response

Classification:

• ingress
• stricter

Cluster name:

• case closure

Dominant sequence pattern:

• parse -> auth -> terminal state write -> response

Classification:

• stricter write

Notable asymmetry:

• VERIFIED
• KES alone has ingress/security-sensitive clusters
• payment request is stricter than approve/settle because it adds KYC boundary enforcement before signature verification

Unresolved or transitional notes:

• TRANSITIONAL
• KES route clusters still sit over a root-repository-derived persistence slice rather than a fully isolated child repository

Current Asymmetry

VERIFIED

The cluster entry patterns remain intentionally different:

• tender declaration emphasizes broader read/check plus stricter state transitions
• auction declaration mixes declaration flow with unresolved output-allocation administration
• KES mixes broader read surfaces with a distinct ingress/security-sensitive payment cluster