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:
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.