Loading module
Resolving locale, route permissions, and workspace projection.
svc-tenders Route Sequence Map
Purpose
This note documents the repeated handler-stage patterns in the densest svc-tenders route modules after Cleanup Sprint 34.
Focus:
- request parsing
- auth/principal resolution
- broader visibility checks
- stricter mutation or ingress gates
- local/domain guards
- repository read/write handoff
- response shaping
Labels used here:
VERIFIEDREALTRANSITIONAL
registerTenderDeclarationRoutes.ts
Route module:
READ 2026-03-28T23:42:21.903Z
READ 2026-03-29T04:52:41.869Z
CORE STRICT SAFE DELETE AFTER RERUN REPORT
PUBLIC | DRAFT | v1.0.0
READ 2026-03-29T03:13:33.020Z
Repeated sequence pattern:
- parse locator/body -> auth -> broader visibility helper -> repository read -> response shaping
- admin read and readiness-check surfaces that stay wider than mutation flows
Broader vs stricter notes:
VERIFIEDsupport.canCheckTenderDeclaration(...) is the broader helper for read/check routes
Repository/dependency touchpoint:
findTenderDeclarationById(...)saveTenderDeclarationAssessment(...)
Repeated sequence pattern:
- parse locator/body -> auth -> stricter mutation helper -> repository read -> readiness/preview derivation -> local state-machine guard -> repository write -> response shaping
- mark-ready and declare transitions
Broader vs stricter notes:
VERIFIEDsupport.hasTenderDeclarationCapability(...) is narrower than the broader read/check helpersupport.getTenderDeclarationCapabilities(...) feeds readiness/state derivation before the final guard
Repository/dependency touchpoint:
findTenderDeclarationById(...)markTenderDeclarationReady(...)declareTender(...)
Repeated sequence pattern:
- parse locator -> auth -> broader visibility helper -> repository read/state check -> shell upload -> local evidence parsing -> repository write -> response shaping
Broader vs stricter notes:
VERIFIED- evidence upload uses the broader declaration visibility helper, but still adds a local
DRAFT state guard before persistence
Repository/dependency touchpoint:
findTenderDeclarationById(...)- shell upload runner via
support.runMulterSingle(...)
- evidence-group parsing via declaration support
- repository evidence write
registerAuctionDeclarationRoutes.ts
Repeated sequence pattern:
- parse locator/body -> auth -> broader visibility helper -> repository read -> response shaping
- output-allocation reads, admin declaration reads, and readiness checks
Broader vs stricter notes:
VERIFIEDsupport.canCheckAuctionDeclaration(...) carries the broader read/check surface
Repository/dependency touchpoint:
- composed declaration/output-allocation read surface
findAuctionDeclarationById(...)saveAuctionDeclarationAssessment(...)
Repeated sequence pattern:
- parse locator/body -> auth -> stricter mutation helper -> repository read -> readiness/preview derivation -> local announce/state guard -> repository write -> response shaping
- draft save/update, mark-ready, and declare transitions
Broader vs stricter notes:
VERIFIEDsupport.hasAuctionDeclarationCapability(...) gates writes more narrowly than the broader read/check helper- capability snapshots are reused for readiness/preview derivation before state-machine guards
Repository/dependency touchpoint:
updateAuctionDeclarationDraft(...)markAuctionDeclarationReady(...)declareAuction(...)
Repeated sequence pattern:
- parse locator -> auth -> stricter mutation helper -> repository read/state check -> shell upload -> local evidence parsing -> repository write -> response shaping
- auction evidence upload flow
Broader vs stricter notes:
VERIFIED- unlike tender evidence upload, auction evidence upload stays on the stricter mutation helper path
Repository/dependency touchpoint:
- composed/transitional auction declaration route boundary
- shell upload runner via
support.runMulterSingle(...)
- evidence-group parsing via declaration support
Unresolved or transitional notes:
TRANSITIONAL- auction declaration remains the most composition-heavy route module in this cluster because output-allocation administration still shares the same boundary
registerKesRoutes.ts
Repeated sequence pattern:
- parse query/body -> optional auth route shell -> repository read -> response shaping
- list, control-plane, and other broader read surfaces
Broader vs stricter notes:
VERIFIED- these routes mostly stay on parser/query helper usage and do not activate stricter ingress helpers
Repository/dependency touchpoint:
- root-repository-derived KES persistence slice
Repeated sequence pattern:
- parse locator/body -> auth -> repository/state validation -> repository write -> response shaping
- ordinary KES actions such as task assignment, inspection submission, and case lifecycle actions
Broader vs stricter notes:
VERIFIED- these flows are stricter than pure reads because they require auth, but they do not add signature or KYC ingress checks
Repository/dependency touchpoint:
- KES command methods on the mixed repository surface
Repeated sequence pattern:
- parse locator/body -> auth -> signature ingress verification -> repository/state validation -> repository write -> response shaping
- payment approve and payment settle
Broader vs stricter notes:
VERIFIED- these routes are stricter than ordinary KES actions because they add
verifyIncomingSignatureGate(...)
- they are still narrower than payment request because they do not enforce the KYC boundary helper
Repository/dependency touchpoint:
approveKesOrchestratorPayment(...)settleKesOrchestratorPayment(...)
Repeated sequence pattern:
- parse locator/body -> auth -> KYC boundary enforcement -> signature ingress verification -> repository/state validation -> repository write -> response shaping
Broader vs stricter notes:
VERIFIED- this is the strictest ingress stack in the KES route module
Repository/dependency touchpoint:
requestKesOrchestratorPayment(...)
Unresolved or transitional notes:
TRANSITIONAL- KES routes still sit on a root-repository-derived persistence slice rather than a fully isolated child repository surface
Current Asymmetry
The repeated route-sequence patterns are intentionally not uniform:
- tender declaration evidence upload stays on a broader visibility helper plus local
DRAFT state guard
- auction declaration evidence upload stays on a stricter mutation-helper path
- KES payment routes add ingress/security stages that ordinary KES actions do not use
- auction declaration remains more transitional than tender declaration because its repository touchpoints are still composition-heavy