These were the actual legacy HTTP-host slice. They are no longer present in svc-tenders.

Shared On Purpose

• gateway seam in services/api/src/routes/kes-orchestrator.ts
• shared auth ingress behavior and /auth/me contract
• shell-owned KYC / signature glue shape
• API-side KES proxy event publication
• svc-tenders Kafka consumer / relay / replay tooling:
  • consume:kes-events
  • consume:kes-domain-events
  • relay:kes-outbox
  • poison replay / DLQ tooling
• broader KES event catalogs and outbox/backbone docs under docs/80_chain

These are not legacy host blockers in the same sense as the old HTTP host. They are shared-backbone pieces that still live outside first-cut KES ownership on purpose.

Still Mixed Or Transitional In svc-tenders

• the former root compatibility/delegation residue and former services/svc-tenders/src/kes/* compatibility files were later removed in Sprints 98 and 99
• shared event-backbone runtime still lives in svc-tenders
• migration ownership is still partially mixed because shared backbone and historical runtime assumptions remain around the KES event path

What Can Be Retired In The Legacy Host

The actual legacy HTTP host slice has already been retired.

Any future KES cleanup in svc-tenders is no longer HTTP-host retirement work. It is deeper compatibility/backbone cleanup.

What Must Stay For Now

Until a later backbone-focused cleanup:

• shared Kafka relay / consumer / DLQ / replay tooling
• API-side KES proxy publication logic
• shared auth ingress contract
• signature / KYC semantics

These may outlive the old colocated HTTP host and should not be conflated with it.

Prerequisites For Deletion

These prerequisites were satisfied before Sprint 97 deletion:

1. svc-kes was stable as primary through the live API seam
2. normal root dev/startup truth already treated svc-kes as primary
3. KES HTTP parity and live cutover checks had already passed
4. retirement was explicitly treated as HTTP-host deletion, not shared-backbone transfer

Rollback Cutoff Criteria

Rollback is now closed because all of the following were true:

1. svc-kes was the clear primary runtime in live env/config and normal dev startup
2. no unresolved KES HTTP/runtime mismatch remained in the checked route family
3. the team explicitly advanced to the retirement decision sprint instead of leaving fallback indefinite

Shared-Backbone Notes

Shared backbone coupling does not by itself block old KES HTTP-host deletion.

It blocks later cleanup phases such as:

• removing shared Kafka/runtime consumers from svc-tenders
• claiming full KES backbone ownership transfer
• retiring shared outbox/replay tooling

That distinction remains explicit after retirement: the old KES HTTP host is gone, while deeper shared-backbone cleanup still remains separate work.