svc-tenders Auth Surface Map

Purpose

This note documents the route-cluster auth and gate surfaces in the densest svc-tenders route modules after Cleanup Sprint 39.

Focus:

• public/read-only boundaries
• shell requireServiceAuth boundaries
• broader visibility gates
• stricter mutation gates
• ingress/signature gates
• ingress/KYC+signature gates

Labels used here:

• VERIFIED
• REAL
• TRANSITIONAL

registerTenderDeclarationRoutes.ts

Route module:

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

Route cluster:

• admin read

Dominant auth/gate surface:

• shell requireServiceAuth
• broader visibility gate via canCheckTenderDeclaration(...)

Classification:

• service-auth
• broader

Route cluster:

• draft authoring

Dominant auth/gate surface:

• shell requireServiceAuth
• stricter mutation gate via hasTenderDeclarationCapability(..., "tender:create-draft")

Classification:

• service-auth
• stricter

Route cluster:

• readiness / declare transitions

Dominant auth/gate surface:

• shell requireServiceAuth
• readiness check on broader visibility
• mark-ready/declare on stricter mutation capabilities

Classification:

• service-auth
• broader
• stricter

Route cluster:

• evidence surface

Dominant auth/gate surface:

• shell requireServiceAuth
• list/download on broader visibility
• upload stays on broader visibility too, then adds a local DRAFT state guard

Classification:

• service-auth
• broader

Notable asymmetry:

• VERIFIED
• tender evidence upload does not add the stricter mutation gate; it stays on the broader visibility path plus local state guard

registerAuctionDeclarationRoutes.ts

Route module:

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

Route cluster:

• output-allocation admin surface

Dominant auth/gate surface:

• shell requireServiceAuth
• reads on broader visibility
• writes on stricter mutation capability

Classification:

• service-auth
• broader
• stricter
• transitional

Route cluster:

• admin read

Dominant auth/gate surface:

• shell requireServiceAuth
• broader visibility gate via canCheckAuctionDeclaration(...)

Classification:

• service-auth
• broader

Route cluster:

• evidence surface

Dominant auth/gate surface:

• shell requireServiceAuth
• upload on stricter mutation capability
• list/download on broader visibility

Classification:

• service-auth
• broader
• stricter

Route cluster:

• draft authoring

Dominant auth/gate surface:

• shell requireServiceAuth
• stricter mutation gate via hasAuctionDeclarationCapability(..., "auction:create-draft")

Classification:

• service-auth
• stricter
• transitional

Route cluster:

• readiness / announce transitions

Dominant auth/gate surface:

• shell requireServiceAuth
• readiness check on broader visibility
• mark-ready/declare on stricter mutation capabilities

Classification:

• service-auth
• broader
• stricter
• transitional

Notable asymmetry:

• VERIFIED
• unlike tender evidence upload, auction evidence upload stays on the stricter mutation-helper path
• this module also mixes output-allocation and declaration auth surfaces in one boundary

Unresolved or transitional notes:

• TRANSITIONAL
• output-allocation administration still shares the same route boundary as declaration flows

registerKesRoutes.ts

Route module:

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

Route cluster:

• case entry

Dominant auth/gate surface:

• shell requireServiceAuth only

Classification:

• service-auth

Route cluster:

• operator read / control-plane surface

Dominant auth/gate surface:

• public/read-only

Classification:

• public

Notes:

• VERIFIED
• this cluster intentionally does not use requireServiceAuth

Route cluster:

• process-map mutation

Dominant auth/gate surface:

• shell requireServiceAuth only

Classification:

• service-auth

Route cluster:

• case / task / inspection actions

Dominant auth/gate surface:

• shell requireServiceAuth only

Classification:

• service-auth

Route cluster:

• payment-sensitive actions

Dominant auth/gate surface:

• shell requireServiceAuth
• payment request on KYC + signature ingress gating
• approve/settle on signature-only ingress gating

Classification:

• service-auth
• ingress
• KYC+signature

Route cluster:

• case closure

Dominant auth/gate surface:

• shell requireServiceAuth only

Classification:

• service-auth

Notable asymmetry:

• VERIFIED
• KES is the only dense route module here with public read clusters
• KES is also the only one with ingress-specific signature/KYC gating

Unresolved or transitional notes:

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

Current Asymmetry

VERIFIED

The auth surfaces remain intentionally different:

• tender and auction declaration modules are uniformly shell-auth-gated, then split into broader versus stricter capability helpers
• tender evidence upload stays broader-gated, while auction evidence upload is stricter-gated
• KES mixes public read-only clusters with shell-auth-only mutation clusters and a narrower ingress-gated payment cluster