svc-tenders Route Dependency Map

Purpose

This note documents the dominant dependency touchpoints in the densest svc-tenders route modules after Cleanup Sprint 40.

Focus:

• repository-read-heavy clusters
• repository-write-heavy clusters
• shell upload/storage clusters
• domain/state-machine-helper-heavy clusters
• aggregate/projection-read clusters

Labels used here:

• VERIFIED
• REAL
• TRANSITIONAL

registerTenderDeclarationRoutes.ts

Route module:

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

Route cluster:

• admin read

Dominant dependency touchpoint:

• repository read

Classification:

• read

Notes:

• VERIFIED
• this cluster is mostly a straight findTenderDeclarationById(...) surface with minimal helper layering

Route cluster:

• draft authoring

Dominant dependency touchpoint:

• repository write
• derived preview/validation helpers

Classification:

• write
• domain-helper

Notes:

• VERIFIED
• draft flows normalize form data, derive validation/preview, then persist

Route cluster:

• readiness / declare transitions

Dominant dependency touchpoint:

• mixed repository read/write
• domain/state-machine helpers

Classification:

• write
• domain-helper

Notes:

• VERIFIED
• this is the most domain-helper-heavy tender cluster because it recomputes readiness, preview, and state-machine guards before write handoff

Route cluster:

• evidence surface

Dominant dependency touchpoint:

• shell upload/storage on upload/download
• repository reads for declaration/evidence lookup

Classification:

• upload
• read

Notable asymmetry:

• VERIFIED
• this cluster is the only tender cluster with a strong shell storage dependency and a stream/download branch

registerAuctionDeclarationRoutes.ts

Route module:

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

Route cluster:

• output-allocation admin surface

Dominant dependency touchpoint:

• composed transitional repository reads/writes

Classification:

• read
• write
• transitional

Notes:

• VERIFIED
• this cluster is dominated by the unresolved mixed repository surface rather than declaration state-machine helpers

Route cluster:

• admin read

Dominant dependency touchpoint:

• repository read

Classification:

• read

Route cluster:

• evidence surface

Dominant dependency touchpoint:

• shell upload/storage on upload/download
• repository reads for declaration/evidence lookup

Classification:

• upload
• read
• transitional

Route cluster:

• draft authoring

Dominant dependency touchpoint:

• repository write
• allocation lookup reads
• derived preview/validation helpers

Classification:

• write
• domain-helper
• transitional

Notes:

• VERIFIED
• this cluster combines declaration writes with allocation existence reads because the boundary is still composed

Route cluster:

• readiness / announce transitions

Dominant dependency touchpoint:

• mixed repository read/write
• declaration domain/state-machine helpers

Classification:

• write
• domain-helper
• transitional

Notable asymmetry:

• VERIFIED
• auction declaration shares the same declaration helper family as tender, but carries extra transitional dependency on output-allocation adjacency

Unresolved or transitional notes:

• TRANSITIONAL
• this module remains composition-heavy because declaration and output-allocation flows still share one boundary

registerKesRoutes.ts

Route module:

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

Route cluster:

• case entry

Dominant dependency touchpoint:

• repository write

Classification:

• write

Notes:

• VERIFIED
• helper use is comparatively light here; the cluster mostly prepares a command payload and writes

Route cluster:

• operator read / control-plane surface

Dominant dependency touchpoint:

• aggregate/projection reads

Classification:

• aggregate
• read

Notes:

• VERIFIED
• this is the most read-fan-out-heavy cluster in the dense group because it mixes count/list/detail/projection access

Route cluster:

• process-map mutation

Dominant dependency touchpoint:

• repository write

Classification:

• write

Route cluster:

• case / task / inspection actions

Dominant dependency touchpoint:

• repository write

Classification:

• write

Notes:

• VERIFIED
• these routes are action/write heavy and do not rely on the declaration-style preview/validation helper family

Route cluster:

• payment-sensitive actions

Dominant dependency touchpoint:

• repository write
• ingress/security helpers

Classification:

• write
• ingress

Notes:

• VERIFIED
• this cluster is dependency-distinct because it layers signature/KYC helpers on top of repository writes

Route cluster:

• case closure

Dominant dependency touchpoint:

• repository write

Classification:

• write

Notable asymmetry:

• VERIFIED
• KES is the only dense route module whose main special dependency shape is aggregate/projection fan-out plus ingress/security helpers rather than declaration state-machine helpers

Unresolved or transitional notes:

• TRANSITIONAL
• KES still uses a root-repository-derived persistence slice rather than a fully isolated child repository

Current Asymmetry

VERIFIED

The dependency surfaces remain intentionally different:

• tender declaration is mostly split between repository read/write clusters, domain-helper-heavy transition clusters, and shell upload/storage evidence flows
• auction declaration shares those same shapes but adds a composed transitional repository surface and allocation lookups
• KES is dominated by aggregate/projection reads, plain action writes, and ingress/security dependencies rather than declaration state-machine helpers