# Implementation Phases — Overview

MW-Core is built in 6 phases over ~16 weeks. Each phase produces a working, deployable
increment. No phase leaves the system in a broken state.

---

## Timeline

```
Week  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16
      ├──────┤                                          Phase 0: Foundation
               ├────────────┤                          Phase 1: API Gateway + Auth + Banking
                             ├────────────┤             Phase 2: File & DW Adapters
                                          ├──────┤      Phase 3: WebSocket
                                                ├──────┤ Phase 4: Admin Web UI
                                                        ├──────┤ Phase 5: Mobile + Transform
                                                               ├──────┤ Phase 6: Hardening
```

---

## Phase Summary

| Phase | Weeks | Focus | End-to-End Capability | Status |
|-------|-------|-------|----------------------|--------|
| [Phase 0](phase-0-foundation.md) | 1–2 | Umbrella skeleton, kernel, infra | App boots, DB connects, telemetry runs | ✅ Complete (2026-04-26) |
| [Phase 1](phase-1-api-gateway.md) | 3–5 | REST gateway + auth + banking adapter | `POST /api/v1/transactions` → core banking → response | ✅ Complete (2026-04-26) |
| [Phase 2](phase-2-async-adapters.md) | 6–8 | File + DW adapters + Broadway queue | SFTP file → Broadway → DW insert | ✅ Complete |
| [Phase 3](phase-3-websocket.md) | 9–10 | WebSocket gateway + real-time | Client receives live transaction status | ✅ Complete (2026-04-26) |
| [Phase 4](phase-4-admin-ui.md) | 11–12 | LiveView admin + dynamic routing | Ops edits routing rules live via UI | ✅ Complete (2026-04-26) |
| [Phase 5](phase-5-mobile.md) | 13–14 | Mobile gateway + transform engine | Mobile gets compact response + push notification | ✅ Complete (2026-04-26) |
| [Phase 6](phase-6-hardening.md) | 15–16 | Production hardening | OTel export, Prometheus, clustering, Vault | ✅ Complete (2026-04-26) |
| [Phase 7](phase-7-composite-aggregation.md) | 17–19 | Composite fan-out & response merging | Multi-backend parallel dispatch, merged response with partial failure semantics | ✅ Complete (2026-04-30) |
| [Phase 8](phase-8-visual-flow-builder.md) | 20–22 | Visual flow builder (jsPlumb canvas) | Drag-and-drop composite route designer, multi-flow DB persistence, live execution overlay | ✅ Complete (2026-04-30) |
| [Phase 9](phase-9-dag-conditional-execution.md) | 23–25 | DAG / conditional execution engine | Decision node branching, slot dependencies, historical replay on canvas | ✅ Complete (2026-05-01) |
| [Phase 10](phase-10-adapter-lifecycle.md) | 26–28 | Adapter lifecycle management | Config-driven HTTP adapter (no-code), mix gen.adapter scaffold | ✅ Complete (2026-05-01) |
| [Phase 11](phase-11-generic-middleware-platform.md) | 29–34 | Generic integration middleware platform | Universal gateway, schema validation, async routing, tenant isolation, versioning, saga, webhooks | 🔲 Planned |

---

## Definition of Done (All Phases)

- [ ] All new modules have `@spec` Dialyzer specs
- [ ] `mix credo --strict` passes with no issues
- [ ] Test coverage ≥ 80% for new modules
- [ ] No hardcoded secrets in source (verified by CI secret scan)
- [ ] README updated with any new environment variables
- [ ] Architecture docs updated if design decisions changed

---

## Phase 0 — Completion Record

**Completed:** 2026-04-26
**Tests:** 16 passing, 0 failures
**Apps created:** `mw_kernel`, `infra_repo`, `infra_cache`, `infra_queue`, `infra_telemetry`
**Key fixes during implementation:**
- `:telemetry_poller` measurements must be bare atoms (`:memory`, `:total_run_queue_lengths`), not tuples
- ETS named table test cleanup: check `:ets.info(table) == :undefined` in setup rather than deleting in `on_exit`

---

## Cross-Phase Principles

**Boring technology** — use well-known Elixir/OTP patterns before reaching for exotic solutions.

**Vertical slices** — each phase delivers a working feature, not a horizontal layer.
Phase 1 delivers auth + API + one adapter fully wired, not "all auth code but no endpoints".

**Test at the boundary** — integration tests run against a real MySQL DB.
Unit tests use `Mox` to mock the `MwKernel.Adapter` behaviour — never stub the DB.

**Observability in Phase 1** — telemetry events are emitted from the first deployed feature.
Do not defer observability to Phase 6.