Purpose

This document defines what still remains on the legacy colocated ICPI host inside svc-tenders, what that residue is still doing, and what must happen before the old ICPI hosting path can be deleted safely.

It does not propose removing svc-tenders as a whole. It only concerns the ICPI-specific slice still mounted there.

Remaining Legacy-Host Items

| Legacy item | Current location | Current role | Classification | Retirement notes | | --- | --- | --- | --- | --- | | Legacy ICPI server registration | services/svc-tenders/src/server.ts | mounts /icpi/* routes inside svc-tenders | needed temporarily for rollback | remove only after rollback window closes | | Legacy ICPI route module | services/svc-tenders/src/routes/registerIcpiRoutes.ts | serves colocated ICPI reads/writes | needed temporarily for rollback | retire with server registration | | Legacy ICPI route support | services/svc-tenders/src/routes/support/icpiRouteSupport.ts | adapts shell auth for legacy ICPI route path | needed temporarily for rollback | retire with legacy route module | | Legacy ICPI persistence copy | services/svc-tenders/src/icpi/repository.ts | serves fallback ICPI reads/writes against icpi_price_points | needed temporarily for rollback | retire after no rollback need remains | | Legacy ICPI contracts copy | services/svc-tenders/src/icpi/contracts.ts | keeps legacy route/repository path source-compatible | safe to retire soon | remove with legacy route/persistence slice | | Legacy ICPI validation copy | services/svc-tenders/src/icpi/validation.ts | validates fallback write path | safe to retire soon | remove with legacy route slice | | Legacy ICPI parser copy | services/svc-tenders/src/icpi/queryParsers.ts | supports fallback route parsing | safe to retire soon | remove with legacy route slice | | Legacy ICPI migrations still present in svc-tenders | removed after migration invocation was made explicit | historical migration ownership residue | retired | canonical owner is now svc-icpi only | | Gateway fallback target | services/api/src/routes/icpi.ts using TENDERS_SERVICE_URL | rollback seam | shared on purpose | keep until rollback cutoff is approved | | Explicit fallback startup script | package.json dev:api:icpi-fallback | fast operational rollback | shared on purpose | keep until fallback is formally retired | | Old-host references in ICPI docs/runbooks | multiple docs updated over time | explain fallback state | safe to retire soon | prune once old host is removed |

What Can Be Retired Next

Once the rollback window is intentionally closed, the following ICPI-specific items are the first retirement set:

• services/svc-tenders/src/routes/registerIcpiRoutes.ts
• services/svc-tenders/src/routes/support/icpiRouteSupport.ts
• services/svc-tenders/src/icpi/repository.ts
• services/svc-tenders/src/icpi/contracts.ts
• services/svc-tenders/src/icpi/validation.ts
• services/svc-tenders/src/icpi/queryParsers.ts
• the registerIcpiRoutes(...) call and related ICPI wiring inside services/svc-tenders/src/server.ts

Those are the clearest legacy-host-only artifacts now that svc-icpi is primary.

What Must Stay For Now

These must stay during the current stabilization phase:

• gateway ICPI route in services/api/src/routes/icpi.ts
• gateway auth middleware in services/api/src/auth/middleware.ts
• TENDERS_SERVICE_URL as rollback target for ICPI
• package.json dev:api:icpi-fallback
• old colocated ICPI mounting inside svc-tenders

Reason:

• rollback is still intentionally preserved in this phase

Prerequisites For Deletion

Before deleting legacy ICPI hosting from svc-tenders, all of the following should be true:

1. svc-icpi remains the default primary runtime through at least one stabilization window that the team considers sufficient
2. gateway read behavior remains stable on the extracted runtime
3. gateway authenticated write behavior remains stable on the extracted runtime
4. no active operator workflow still depends on the fallback ICPI path
5. the team explicitly accepts that ICPI rollback will no longer target svc-tenders
6. migration ownership for ICPI is explicitly documented so duplicate migration residue can be retired safely
7. docs and onboarding scripts no longer imply the old ICPI host is an active runtime path

Rollback Cutoff Criteria

Rollback to legacy colocated ICPI hosting should be considered safe to remove only when:

• the team no longer requires dev:api:icpi-fallback
• the gateway seam has been stable on svc-icpi
• no unresolved ICPI-specific anomaly remains open against the extracted runtime
• there is an approved replacement rollback posture, or the team explicitly accepts rollback loss for the legacy ICPI path

That fallback posture has now been retired.

Notes

• svc-tenders continues to exist for non-ICPI domains regardless of this retirement plan.
• Legacy-host retirement here means removing the ICPI slice from svc-tenders, not removing the entire service.
• This plan has now been superseded on both runtime retirement and migration cleanup.