Platform Next Direction Status

Candidate List

1. services/api auction and legacy-tender local-engine boundary cleanup

• Type: platform-level cleanup
• Core surface:
  • services/api/src/routes/auctions.ts
  • services/api/src/auctions/localEngineRoutes.ts
  • services/api/src/auctions/engine.ts
  • services/api/src/routes/tenders.ts
  • services/api/src/tenders/gateway.ts
  • services/api/src/tenders/legacyRoutes.ts
• Current reality:
  • services/api still mixes gateway proxying with gateway-local auction mutations, tender compatibility reads, fixture-backed projections, and legacy outbox emission.
  • CURRENT_ARCHITECTURE.md already identifies this as one of the dirtiest overlaps in the platform.
• Readiness: HIGH
• Ambiguity: MEDIUM
• Value: HIGH
• Likely sprint sequence:
  1. clarify canonical auction/tender action/read ownership at the API boundary
  2. classify proxy routes vs gateway-local compatibility routes explicitly
  3. reduce or isolate local-engine residue without changing public route shape
  4. only then decide whether auctions or tenders become the next true extraction-prep candidate

2. KES shared-backbone transfer planning

• Type: planning work
• Core surface:
  • KES_FINAL_RUNTIME_AND_BACKBONE_STATUS.md
  • EVENT_DRIVEN_ARCHITECTURE.md
  • services/svc-tenders/src/kafka/kesOutboxRelay.ts
  • services/svc-tenders/src/kafka/kesDomainEventConsumer.ts
  • services/svc-tenders/src/kafka/kesEventConsumer.ts
  • services/svc-tenders/src/kafka/idempotencyStore.ts
• Current reality:
  • KES HTTP/runtime ownership is now clear in svc-kes.
  • The main remaining KES ambiguity is no longer host extraction; it is shared backbone ownership.
• Readiness: MEDIUM
• Ambiguity: MEDIUM
• Value: HIGH
• Likely sprint sequence:
  1. classify what remains shared by necessity vs operator convenience
  2. decide whether outbox relay, projection consumer, or replay tooling moves first
  3. define migration/operator impact before any code move

3. Vacancy public-read convergence

• Type: cleanup work
• Core surface:
  • VACANCY_PUBLIC_READ_STATUS.md
  • services/api/src/routes/vacancies.ts
  • services/svc-vacancies/src/vacancy/readRepository.ts
• Current reality:
  • Vacancy extraction is real, but GET /vacancies and GET /vacancies/:id remain compatibility-backed.
• Readiness: MEDIUM
• Ambiguity: MEDIUM
• Value: MEDIUM
• Likely sprint sequence:
  1. tighten preferred projection-backed read truth
  2. reduce compatibility fallback only where response parity stays safe
  3. then revisit remaining web-side fallback truth

4. Auth and identity façade alignment

• Type: platform-level cleanup
• Core surface:
  • AUTH_AND_IDENTITY_BOUNDARY.md
  • services/api/src/routes/stakeholder-applications.ts
  • packages/identity-infra/src/server.ts
• Current reality:
  • Reviewer workflow exists in identity-infra, but the public gateway still returns 501 not_implemented for reviewer actions.
• Readiness: MEDIUM
• Ambiguity: HIGH
• Value: MEDIUM
• Likely sprint sequence:
  1. decide canonical gateway exposure policy
  2. align authz expectations
  3. proxy or explicitly retire the hidden reviewer surface

5. Remaining mixed migration cleanup for Vacancy and Accommodations

• Type: cleanup work
• Core surface:
  • SHARED_SHELL_RESIDUE_MAP.md
  • POST_EXTRACTION_SPRINT_85_ACCOMMODATION_REPORT.md
  • POST_EXTRACTION_SPRINT_86_VACANCY_REPORT.md
• Current reality:
  • Mixed migrations still exist, but the operational ownership story is already explicit enough for current extracted runtimes.
• Readiness: MEDIUM
• Ambiguity: LOW
• Value: LOW
• Likely sprint sequence:
  1. separate mixed vacancy/accommodation migrations carefully
  2. update migrate ownership docs

Readiness / Ambiguity / Value Summary

| Candidate | Readiness | Ambiguity | Value | Why | | --- | --- | --- | --- | --- | | API auction and legacy-tender boundary cleanup | HIGH | MEDIUM | HIGH | It addresses the largest remaining public-platform overlap after the extracted-service wave | | KES shared-backbone transfer planning | MEDIUM | MEDIUM | HIGH | Biggest remaining KES ambiguity, but it is heavier operationally and not required for current runtime truth | | Vacancy public-read convergence | MEDIUM | MEDIUM | MEDIUM | Useful cleanup, but narrower than the API boundary split | | Auth/identity façade alignment | MEDIUM | HIGH | MEDIUM | Real mismatch, but broader authz/product implications raise risk | | Mixed migration cleanup | MEDIUM | LOW | LOW | Worth doing later, but not the highest-leverage next platform move |

Primary Recommendation

Choose services/api auction and legacy-tender local-engine boundary cleanup as the primary next direction.

Rationale

• It is the strongest remaining topology ambiguity in the active public platform path.
• It affects the user-facing gateway directly, not just an internal residue layer.
• The code is already explicit about the problem:
  • services/api/src/routes/auctions.ts proxies reads but still mounts compatibility-only local mutation routes.
  • services/api/src/auctions/localEngineRoutes.ts says those routes are not the canonical durable backend.
  • services/api/src/tenders/gateway.ts falls back to a gateway-local legacy engine for read paths.
  • services/api/src/tenders/legacyRoutes.ts still emits legacy outbox events from the gateway layer.
• Cleaning this boundary first will lower ambiguity before the team tries to extract another remaining svc-tenders domain such as auctions or declarations.

Secondary Recommendation

Choose KES shared-backbone transfer planning as the backup direction.

Rationale

• KES host extraction is already materially complete.
• The next real KES question is backbone ownership, not route/runtime extraction.
• This is valuable, but it is a heavier operational decision and does not unblock the broader platform topology as directly as the API auction/tender cleanup does.

Notes

• The strongest next move is not another small residue cleanup inside an already-extracted service.
• The strongest next move is also not a fresh extraction from svc-tenders yet, because auctions and legacy tenders are still entangled with gateway-local engines and fixture-backed compatibility behavior.
• Sprint 102 should therefore reduce platform ambiguity first, then let the next extraction candidate emerge from a cleaner boundary.