• active runtime callers of KES methods through repository.ts: none found
• test-only callers through TendersRepository: none found
• docs/example residue: found in KES and historical architecture docs
• dead reference: the old TendersRepository construction in server.ts
• unresolved: none found in current TypeScript source

The verified active KES runtime callers now go through:

• services/svc-kes/src/routes/registerKesRoutes.ts
• services/api/src/routes/kes-orchestrator.ts
• apps/web/src/portal/api.ts

Those do not depend on TendersRepository KES delegation.

Decision

Decision: the remaining KES compatibility layer in svc-tenders was no longer needed and could be removed now.

That decision was grounded by the caller scan:

1. no live TypeScript caller still reached KES through TendersRepository
2. the only imports of services/svc-tenders/src/kes/* were self-hosted inside repository.ts
3. canonical KES runtime paths already live in svc-kes and the API gateway

What Was Removed

• KES delegation methods from repository.ts
• the compatibility type surface at the former services/svc-tenders/src/kes/contracts.ts path
• the compatibility persistence copy at the former services/svc-tenders/src/kes/repository.ts path
• the dead new TendersRepository(...) construction from server.ts

What Was Retained

Retained in svc-tenders on purpose:

• kesOutboxRelay.ts
• kesDomainEventConsumer.ts
• kesEventConsumer.ts
• kesDlqReplay.ts
• kesOutboxPoisonReplay.ts
• idempotencyStore.ts

These remain because they are shared backbone or shared operational infrastructure, not KES compatibility residue.

What Still Remains Shared On Purpose

• Kafka relay
• projection pipeline
• idempotency store
• DLQ/replay tooling
• shared auth ingress and /auth/me
• shared KYC/signature semantics
• API-side KES proxy publication

Notes

• svc-kes remains the canonical KES HTTP/runtime host
• old svc-tenders KES HTTP hosting remains retired
• compatibility-layer reduction is complete, but full shared-backbone transfer is still separate work