This document records what Sprint 08 did, and intentionally did not do, around services/svc-tenders/src/repository.ts.

Stage 2 outcome

Sprint 08 did not perform a risky file-level repository breakup.

Instead, it prepared that breakup safely by:

• extracting HTTP route ownership for ICPI, Butkhuzi, and KES
• making those route modules depend on narrow repository ports
• adding explicit ownership notes inside TendersRepository around ambiguous or future-extractable blocks

Verdict:

• Repository decomposition status: VERIFIED, PARTIAL
• Risk posture: conservative by design

What changed in practice

1. Route modules now depend on narrow repository ports

• VERIFIED
• Files:
  • services/svc-tenders/src/routes/registerIcpiRoutes.ts
  • services/svc-tenders/src/routes/registerButkhuziRoutes.ts
  • services/svc-tenders/src/routes/registerKesRoutes.ts
• Effect:
  • Each route module now expresses a smaller persistence contract instead of depending on the full conceptual breadth of TendersRepository.

This is not a repository extraction yet, but it is the correct prep step because it exposes which repository surfaces are actually needed by each domain block.

2. Ownership notes were added to explicit repository blocks

• VERIFIED
• File: services/svc-tenders/src/repository.ts
• Explicit notes now mark:
  • output_allocations as unresolved ownership
  • ICPI as still hosted in TendersRepository even after route split
  • Butkhuzi as still hosted in TendersRepository even after route split
  • KES as still colocated pending broader backbone-vs-domain decision

This matters because future AI agents can now see that colocated persistence does not equal final ownership.

What did not move yet

No separate repository files yet for:

• ICPI persistence
• Butkhuzi persistence
• KES persistence
• tender declaration persistence
• auction declaration persistence
• evidence persistence

Reason:

• VERIFIED
• The file is still large and mixed, but direct extraction would have been riskier than the route-shell split.
• Several blocks still share helpers, row mappers, normalization functions, and transaction patterns.

Safe repository split candidates after Stage 2

1. ICPI repository

• Readiness: READY
• Status: VERIFIED
• Candidate scope:
  • count/list/suggest/latest/estimate/upsert ICPI methods
• Why safe:
  • Route ownership is already separated.
  • Domain surface is relatively self-contained.

2. Butkhuzi repository

• Readiness: READY
• Status: VERIFIED
• Candidate scope:
  • norms list/suggest/search
  • chunk rebuild/search
  • upsert/delete-by-source
• Why safe:
  • Route ownership is already separated.
  • Persistence block is coherent, even if large.

3. KES repository facade or module

• Readiness: PARTIAL
• Status: VERIFIED
• Candidate scope:
  • case list/detail
  • process map
  • suggestions
  • command-side case transitions
• Why only partial:
  • KES has stronger event/runtime implications than ICPI or Butkhuzi.
  • The backbone-vs-domain ownership decision is still open.

4. Tender declaration repository

• Readiness: PARTIAL
• Status: INFERRED
• Candidate scope:
  • tender declaration draft/ready/declare/evidence methods
• Why only partial:
  • This block is coherent, but still intertwined with broader tender lifecycle reads and shared declaration support patterns.

5. Auction declaration repository

• Readiness: PARTIAL
• Status: INFERRED
• Candidate scope:
  • auction declaration draft/ready/declare/evidence methods
• Why only partial:
  • Similar to tender declaration, but with the additional complication of output_allocations.

Explicitly unresolved / should not be forced yet

output_allocations

• Status: VERIFIED
• Current file: services/svc-tenders/src/repository.ts
• Why unresolved:
  • It is used by auction declaration/admin flows today.
  • Long-term owner could be future auctions, settlement/financial logic, or shared backbone capability.
• Recommendation:
  • Do not extract yet.
  • Keep the ambiguity visible.

Shared outbox/event persistence

• Status: VERIFIED
• Why unresolved:
  • Eventing helpers and persistence cut across multiple subdomains.
  • Premature movement would create artificial boundaries.

Tender/auction declaration shared helpers

• Status: VERIFIED
• Why unresolved:
  • There is conceptual symmetry, but not yet a clean shared repository abstraction.

Recommended Stage 3 repository sequence

1. Extract ICPI persistence to its own module file

• Best first move because it is coherent and lower-risk.

2. Extract Butkhuzi persistence to its own module file

• Similar risk profile to ICPI, slightly larger.

3. Reassess KES persistence split after route-shell cleanup finishes

• Avoid forcing KES into either tender-domain or shared-backbone labeling prematurely.

4. Only then split tender and auction declaration persistence

• Do this after the service-shell route shape is clearer and support helpers are more modular.

Bottom line

Sprint 08 repository work is best described as:

• not a file split
• not a domain rewrite
• a truthful decomposition-prep stage

That is the correct outcome for this sprint.