They currently handle:

• POST /api/v1/auctions/create
• POST /api/v1/auctions/:id/announce
• POST /api/v1/auctions/:id/open
• POST /api/v1/auctions/:id/bids
• POST /api/v1/auctions/:id/close
• POST /api/v1/auctions/:id/award
• POST /api/v1/auctions/:id/settle

They execute against:

• gateway-local engine logic in services/api/src/auctions/engine.ts
• fixture and in-memory ledger behavior, not an extracted auction runtime

Why They Still Exist

They still exist because the public API surface preserved historical auction actions even though a canonical durable upstream auction action backend has not been separated cleanly yet.

They therefore serve as:

• compatibility behavior
• local degraded-path behavior
• bridge logic for historical public action routes

Why They Are Not Canonical Durable Backend

They are not canonical durable backend because:

• the module itself describes them as compatibility-only
• they run inside services/api, not a dedicated auction runtime
• they depend on gateway-local engine logic, fixtures, and in-memory ledger projections
• the read side already prefers upstream proxying before falling back locally

The strongest evidence is in:

• services/api/src/routes/auctions.ts
• services/api/src/auctions/localEngineRoutes.ts
• services/api/src/auctions/gateway.ts

What They Block

They block:

• a clean statement that services/api is only acting as an auction gateway
• a low-ambiguity auction extraction-prep decision
• a clean public-platform ownership story for auction mutations

They do not block:

• current extracted-service runtimes such as ICPI, Butkhuzi, Vacancy, Accommodation, and first-cut KES
• current gateway/auth behavior for those already-extracted domains

What Later Cleanup They Point To

The next logical cleanup questions are:

• should auction mutation routes remain public compatibility behavior in services/api
• if they remain, how explicitly should they be marked as compatibility-only
• if they should move later, what becomes the canonical durable auction action backend

Notes

• This document is intentionally about the auction local engine only.
• Tender legacy local-engine and gateway-emitted legacy tender events are adjacent boundary work, but they are tracked separately in API_AUCTION_TENDER_BOUNDARY_STATUS.md.