svc-tenders Server Route Shell Map

Status labels used below:

• VERIFIED
• REAL
• MIXED
• UI-FIRST
• SHELL
• MISSING

This note records the post-Sprint-08 route-shell shape of services/svc-tenders/src/server.ts.

Current route-registration shape

Extracted from the central shell in Sprint 07-08

These route groups are now registered through dedicated modules instead of living inline inside server.ts.

1. Vacancy routes

• Module: services/svc-tenders/src/routes/registerVacancyRoutes.ts
• Registered from: services/svc-tenders/src/server.ts
• Status: VERIFIED, REAL
• Notes:
  • Owns vacancy public discovery plus owner/applicant mutation surfaces.
  • Still depends on shared auth and parsing helpers passed from server.ts.

2. Accommodation routes

• Module: services/svc-tenders/src/routes/registerAccommodationRoutes.ts
• Registered from: services/svc-tenders/src/server.ts
• Status: VERIFIED, REAL
• Notes:
  • Owns accommodation listing and booking-related HTTP registration.
  • Uses the real accommodation read repository plus owner read repository.

3. ICPI routes

• Module: services/svc-tenders/src/routes/registerIcpiRoutes.ts
• Registered from: services/svc-tenders/src/server.ts
• Status: VERIFIED, REAL
• Routes:
  • /icpi/prices
  • /icpi/suggest
  • /icpi/latest/:itemCode
  • /icpi/estimate
  • /icpi/upsert
• Notes:
  • HTTP ownership is now visibly separated from tender/declaration routes.
  • Persistence still lives in TendersRepository.

4. Butkhuzi routes

• Module: services/svc-tenders/src/routes/registerButkhuziRoutes.ts
• Registered from: services/svc-tenders/src/server.ts
• Status: VERIFIED, REAL
• Routes:
  • /butkhuzi/norms
  • /butkhuzi/suggest
  • /butkhuzi/search
  • /butkhuzi/upsert
  • /butkhuzi/chunks/rebuild
• Notes:
  • Route ownership is now explicit.
  • Search, suggest, and chunk rebuild logic no longer bloat server.ts.

5. KES routes

• Module: services/svc-tenders/src/routes/registerKesRoutes.ts
• Registered from: services/svc-tenders/src/server.ts
• Status: VERIFIED, REAL
• Routes include:
  • /kes-orchestrator/cases
  • /kes-orchestrator/control-plane
  • /kes-orchestrator/process-map
  • /kes-orchestrator/suggestions
  • action routes for approve, publish, fund, tasks, inspections, payments, close
• Notes:
  • This is the biggest structural win in Sprint 08 because KES no longer visually competes with tender/auction declaration flows inside one inline shell.

What remains centralized in server.ts

1. Tender public + admin + declaration/evidence routes

• File: services/svc-tenders/src/server.ts
• Status: VERIFIED, REAL
• Representative routes:
  • /tenders
  • /tenders/submit
  • /tenders/me
  • /tenders/:id
  • /admin/tenders
  • /admin/tenders/:id
  • /admin/tenders/declarations/*
• Why still centralized:
  • Tender lifecycle, declaration readiness, declaration evidence, and review/admin checks are still tightly coupled to shared repository methods, capability checks, and storage helpers.
  • Safe split is possible, but larger than the Sprint-08 scope.

2. Auction public + admin + declaration/evidence/output-allocation routes

• File: services/svc-tenders/src/server.ts
• Status: VERIFIED, REAL for declaration/admin surfaces, MIXED for broader auction truth in the overall system
• Representative routes:
  • /auctions
  • /auctions/:id
  • /admin/auctions
  • /admin/auctions/:id
  • /admin/auctions/declarations/*
  • /output-allocations
  • /output-allocations/:id
• Why still centralized:
  • Auction declaration routes and output allocation routes still share validation helpers, declaration evidence storage, and repository methods in a way that is not yet cleanly separable.
  • output_allocations ownership remains intentionally unresolved.

3. Shared auth / validation / parsing / storage support

• File: services/svc-tenders/src/server.ts
• Status: VERIFIED, REAL
• Includes:
  • requireServiceAuth
  • active principal / permission helpers
  • shared query parsers
  • evidence upload middleware
  • signature/KYC boundary helpers used by KES
• Why still centralized:
  • These are service-shell concerns rather than domain route concerns.
  • They should likely move to dedicated support modules later, but Sprint 08 focused on domain route ownership first.

What became clearer in Sprint 08

Tender/declaration routes vs KES/ICPI/Butkhuzi routes

• VERIFIED
• Before Sprint 08, those route groups were all visually mixed inside one giant shell.
• After Sprint 08:
  • tender and auction declaration flows remain visibly central
  • KES, ICPI, and Butkhuzi are visibly separate registration units

Remaining route-shell truth

• VERIFIED
• server.ts is still large: services/svc-tenders/src/server.ts
• It is no longer mixing quite as many unrelated HTTP domains inline, but it is still not a thin bootstrap shell.

Safe next split candidates

1. Tender route module

• Candidate name: registerTenderRoutes.ts
• Status: INFERRED, safe next step
• Reason:
  • The tender public/admin/declaration routes form a coherent cluster.

2. Auction declaration/admin route module

• Candidate name: registerAuctionDeclarationRoutes.ts
• Status: INFERRED, safe next step if done carefully
• Reason:
  • The admin declaration/evidence flow is internally coherent even though overall auction truth is MIXED.

3. Shared service-shell support module

• Candidate name: http/support.ts or similar
• Status: INFERRED
• Reason:
  • Parsers, auth gates, and mapping helpers still live in server.ts and keep the file larger than necessary.

Intentionally unresolved

1. output_allocations

• Status: VERIFIED
• Why unresolved:
  • Current route hosting is in svc-tenders, but long-term domain ownership is still ambiguous.

2. KES long-term service ownership

• Status: VERIFIED
• Why unresolved:
  • KES route ownership is now structurally separated, but persistence and runtime ownership still sit inside TendersRepository.

3. Tender vs auction declaration shared support code

• Status: VERIFIED
• Why unresolved:
  • Both flows still use overlapping validation, evidence storage, and capability patterns.
  • Splitting routes further is safe; splitting support code requires more care.