Phase 1.b — waveflow-server skeleton (axum + Postgres + CRUD)

[InstaZDLL]

Tracking issue for sub-phase 1.b of RFC-001.

Bootstrap the waveflow-server repository: axum HTTP server + Postgres + CRUD endpoints for the core entities. No auth yet — dev mode accepts an X-User-Id header to unblock client integration in parallel.

Scope

• New repo waveflow-server with workspace structure (depends on waveflow-core from 1.a via git dependency).
• axum 0.7+ + tokio + tower-http middleware (CORS, tracing, request-id).
• sqlx 0.8+ with postgres feature; migration framework set up at migrations/.
• Postgres impl of the *Repository traits from waveflow-core.
• REST endpoints (CRUD, no auth):
  • POST/GET/PATCH/DELETE /profiles
  • POST/GET/PATCH/DELETE /libraries
  • GET/PATCH /tracks/:id (no POST — tracks come from scanner, see future sub-phase)
  • POST/GET/PATCH/DELETE /playlists + POST/DELETE /playlists/:id/tracks
  • GET /search?q=… (basic, FTS comes later)
• utoipa annotations on every route → /openapi.json + Swagger UI at /docs.
• Dev auth: axum extractor that reads X-User-Id: <uuid> header. Real auth lands in 1.d.
• Single-binary build (cargo build --release produces one executable). Config via env vars + optional waveflow-server.toml.
• Dockerfile + docker-compose (Postgres + server) for self-host quickstart.

Dependencies

• Blocks on: Phase 1.a — Extract waveflow-core crate #128 (1.a) — needs waveflow-core extracted with repository traits.

Acceptance criteria

• cargo run boots the server, curl http://localhost:8080/healthz returns 200.
• CRUD round-trip works via curl for profiles + libraries + playlists.
• /openapi.json is valid OpenAPI 3.1 (validated with a schema linter in CI).
• Postgres migrations run on a fresh DB.
• Dockerfile + compose work on Linux + macOS + Windows.

Estimate

~3 weeks.