Platform Next Direction Decision
Recommended Sprint 102 Direction
Sprint 102 should be a platform-level gateway/local-engine boundary cleanup centered on auctions and legacy tenders in services/api.
Why This Is Strongest Now
This is the strongest next move because it targets the largest remaining active-platform ambiguity after the extracted-service wave:
- the public gateway still mixes canonical upstream routing with gateway-local auction actions, fixture-backed auction/tender logic, and legacy tender compatibility event emission
- this overlap is visible in the actual mounted public surface, not only in internal residue
- it blocks a clean decision about the next true extraction candidate inside the remaining tender/auction/declaration cluster
Grounded evidence:
- services/api/src/routes/auctions.ts
- proxies reads upstream when possible
- still mounts compatibility-only local auction mutation routes
- services/api/src/auctions/localEngineRoutes.ts
- explicitly says those mutation routes are gateway-local compatibility behavior, not canonical durable backend
- services/api/src/tenders/gateway.ts
- still falls back to a gateway-local legacy engine for tender read paths
- services/api/src/tenders/legacyRoutes.ts
- still runs legacy tender local actions and outbox emission from the gateway layer
- CURRENT_ARCHITECTURE.md
- already marks auctions as one of the dirtiest remaining overlaps in the platform
What It Is Not
It is not:
- a new service extraction sprint
- a gateway/auth rewrite
- a KES shared-backbone transfer sprint
- a Vacancy public-read convergence sprint
It is a cleanup and boundary-clarification sprint that should make the next extraction candidate much more obvious and much less risky.
Likely Follow-On Sequence After It
- Sprint 102:
clarify proxy vs local-engine auction/tender routes, ownership, and compatibility behavior in
services/api - Sprint 103: decide whether auctions or declarations are the next true extraction-prep candidate, based on the cleaner gateway boundary
- Sprint 104+: either start auction/declaration extraction prep, or, if the team prefers, pivot into KES shared-backbone transfer planning with less platform ambiguity elsewhere
Backup Direction
If the team does not want the API auction/tender boundary cleanup next, the strongest backup is KES shared-backbone transfer planning.
That remains valuable, but it is second because it improves one extracted domain’s deeper ownership story rather than cleaning the largest remaining public-platform overlap.