svc-tenders Root Repository Hardening

Date: 2026-03-17 Sprint: Cleanup Sprint 11

Purpose

This document records the state of the remaining root repository after Sprint 11:

• services/svc-tenders/src/repository.ts

The goal of Sprint 11 was not to make the root repository look “clean.”
The goal was to make it truthful.

VERIFIED current root-repository categories

After Sprint 11, remaining root responsibility is explicitly partitioned into these buckets:

1. Unresolved cross-domain logic

These remain root-owned by policy even if their implementation now delegates to named submodules.

output_allocations

Implementation module:

• services/svc-tenders/src/repository/outputAllocations.ts

Root surface:

• services/svc-tenders/src/repository.ts
  • createOutputAllocation
  • updateOutputAllocation
  • findOutputAllocationById
  • listOutputAllocations

Why still root-owned:

• ownership is still ambiguous between auction-admin/declaration flow, settlement/financial logic, and a possible shared registry capability

Verdict:

• VERIFIED
• REAL
• unresolved cross-domain

settleAuction(...)

Implementation module:

• services/svc-tenders/src/repository/settlementBridge.ts

Root surface:

• services/svc-tenders/src/repository.ts
  • settleAuction

Why still root-owned:

• current logic updates auction settlement state and linked tender entitlement state
• that makes it a bridge, not a clean auction-only method

Verdict:

• VERIFIED
• REAL
• unresolved cross-domain settlement bridge

2. Shared infrastructure / mixed transitional persistence

KES persistence block

Current location:

• services/svc-tenders/src/repository.ts

Representative methods:

• countKesOrchestratorCases
• listKesOrchestratorCases
• getKesOrchestratorCaseDetail
• getKesOrchestratorCaseProjection
• getKesOrchestratorProcessMap
• upsertKesOrchestratorProcessMap
• command-side case/task/inspection/payment transitions

Why this is not labeled tender-owned:

• KES persistence is durable and real
• but it also touches orchestration runtime, eventing, projections, and execution-layer behavior beyond narrow tender lifecycle ownership

Verdict:

• VERIFIED
• REAL
• shared infrastructure / mixed transitional persistence

3. Legacy compatibility residue

Vacancy compatibility readers

Current location:

• services/svc-tenders/src/repository.ts

Representative methods:

• listAllVacancies
• countAllVacancies
• findVacancyById
• owner/applicant compatibility read helpers

Preferred active path today:

• services/svc-tenders/src/vacancy/readRepository.ts

Verdict:

• VERIFIED
• MIXED
• legacy compatibility residue

Accommodation compatibility readers

Current location:

• services/svc-tenders/src/repository.ts

Representative methods:

• listAllAccommodations
• countAllAccommodations
• findAccommodationById
• findMyAccommodationListingById

Preferred active paths today:

• services/svc-tenders/src/accommodation/readModel.ts
• services/svc-tenders/src/accommodation/ownerReadRepository.ts

Verdict:

• VERIFIED
• MIXED
• legacy compatibility residue

4. Deferred extraction candidates / residual helper layer

Still present in the root file:

• shared type exports
• some ranking/portal helper functions
• some declaration normalization/helper functions
• some residual private helpers from earlier pre-split ownership

Verdict:

• VERIFIED
• mixed utility residue
• deferred extraction candidate

Reason:

• Sprint 11 prioritized truth and boundary clarity over risky dead-code surgery

What Sprint 11 improved

Output allocations are now structurally isolated

Even though ownership is unresolved, the SQL/persistence is no longer mixed directly into the central root class body.

This improves clarity without pretending the final owner is known.

Auction settlement bridge is now structurally isolated

settleAuction(...) remains root-owned in meaning, but its implementation is no longer just another anonymous block inside the root repository.

That makes the cross-domain nature more obvious.

KES classification is now explicit

KES still lives in the root repository, but the code comments and docs now describe it as a shared/mixed transitional persistence block rather than silently treating it as ordinary tender persistence.

Legacy residue is visibly second-class

Vacancy/accommodation compatibility readers remain, but they are now explicitly framed as residue rather than peers of the active read repositories.

What Sprint 11 intentionally did not do

• did not force output_allocations into auction ownership
• did not force KES into shared-backbone final ownership
• did not force legacy vacancy/accommodation residue removal
• did not mass-delete older helper blocks from the root repository

Recommended next move

Sprint 12 should focus on:

• residual helper inventory inside repository.ts
• removing or relocating only helper blocks that are clearly dead or clearly child-owned
• preserving the same honesty about unresolved ownership