Add T-5 (API-first tooling) and align spec with new dependency chain

Research API-first approach with Spring Boot (openapi-generator-maven-plugin)
and Vue 3 frontend (openapi-typescript + openapi-fetch). Add T-5 setup task
for scaffolding the tooling. Update T-4 to depend on T-5 (removes redundant
API client AC), update implementation phases table and mermaid dependency graph.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

spec/implementation-phases.md

@@ -10,7 +10,8 @@ All setup tasks must complete before any user story work begins. T-3 can run in
 |-------|------|------------|-------|
 | 1 | T-1: Initialize monorepo structure | — | Scaffolds empty backend + frontend projects |
 | 2 | T-2: Deployment setup (Dockerfile + config) | T-1 | Docker build, DB connection, health check |
-| 3 | T-4: Development infrastructure | T-1, T-2 | Migrations, router, API client, test infra — gates all user stories |
+| 2* | T-5: API-first tooling setup | T-1 | OpenAPI spec, codegen plugins, generated types — parallelizable with T-2 |
+| 3 | T-4: Development infrastructure | T-2, T-5 | Migrations, router, test infra — gates all user stories |
 | 3* | T-3: CI/CD pipeline | T-1, T-2 | Parallelizable with T-4. Uses Gitea Actions (per Q-5 resolution) |
 
 ## Phase 1: Core Event Flow (Vertical Slice)
@@ -110,7 +111,9 @@ graph TD
 
     %% Phase 0: Infrastructure
     T1(["T-1: Monorepo"]):::infra --> T2(["T-2: Docker & DB"]):::infra
+    T1 --> T5(["T-5: API-First Tooling"]):::infra
     T2 --> T4(["T-4: Dev Infra"]):::infra
+    T5 --> T4
     T2 --> T3(["T-3: CI/CD"]):::infra
 
     %% Phase 1: Core Event Flow
@@ -146,7 +149,7 @@ graph TD
 ```
 
 **Legend:**
-- 🔵 Infrastructure (T-1 – T-4)
+- 🔵 Infrastructure (T-1 – T-5)
 - 🟠 Core Event Flow (US-1 – US-3)
 - 🟢 Organizer & Lifecycle (US-4, US-5, US-12, US-13, US-18, US-19)
 - 🟣 Enhanced Features (US-6, US-8 – US-11)

spec/setup-tasks.md

@@ -55,18 +55,37 @@
 
 ---
 
+### T-5: API-first tooling setup
+
+**Description:** Set up the API-first development workflow. The OpenAPI spec is the single source of truth for the REST API contract. Backend server interfaces and frontend TypeScript types are generated from it. This task scaffolds the tooling and creates a minimal initial spec — the spec itself is a living document that grows with each user story.
+
+**Acceptance Criteria:**
+- [ ] `openapi-generator-maven-plugin` (v7.20.x, `spring` generator, `interfaceOnly: true`) is configured in `backend/pom.xml`
+- [ ] A minimal OpenAPI 3.1 spec exists at `backend/src/main/resources/openapi/api.yaml` (info block, placeholder path, or health-only — enough for the generator to run)
+- [ ] `mvnw compile` generates Java interfaces and model classes into `target/generated-sources/openapi/` with packages `de.fete.adapter.in.web.api` and `de.fete.adapter.in.web.model`
+- [ ] `openapi-typescript` (devDependency) and `openapi-fetch` (dependency) are installed in the frontend
+- [ ] `npm run generate:api` generates TypeScript types from the spec into `frontend/src/api/schema.d.ts`
+- [ ] Frontend `dev` and `build` scripts include type generation as a pre-step
+- [ ] A minimal API client (`frontend/src/api/client.ts`) using `openapi-fetch` with `createClient<paths>()` exists
+- [ ] Both generation steps succeed and the project compiles cleanly (backend + frontend)
+
+**Dependencies:** T-1
+
+**Notes:** The OpenAPI spec is intentionally minimal at this stage — just enough to prove the tooling works end-to-end. Each user story will extend the spec with its endpoints and schemas. Research basis: `docs/agents/research/2026-03-04-api-first-approach.md`.
+
+---
+
 ### T-4: Development infrastructure setup
 
-**Description:** Set up the development foundation needed before the first user story can be implemented with TDD (as required by CLAUDE.md). This bridges the gap between empty project scaffolds (T-1) and actual feature development.
+**Description:** Set up the development foundation needed before the first user story can be implemented with TDD (as required by CLAUDE.md). This bridges the gap between project scaffolds and actual feature development.
 
 **Acceptance Criteria:**
 - [ ] Database migration framework (Flyway or Liquibase) is configured in the backend with a first empty migration that runs successfully against a PostgreSQL instance
 - [ ] SPA router is configured in the Vue frontend (Vue Router) so pages can be navigated by URL path
-- [ ] API client layer exists in the frontend (a fetch wrapper or similar) for making requests to the backend REST API
 - [ ] Backend test infrastructure is set up: JUnit 5 with Spring Boot Test, plus integration test support using Testcontainers (PostgreSQL) so tests can run against a real database without external setup
 - [ ] Frontend test infrastructure is set up: Vitest with @vue/test-utils configured and a sample test runs successfully
 - [ ] Both test suites (backend and frontend) can be executed via their respective build tools (`mvn test` and `npm test` / `npx vitest`)
 
-**Dependencies:** T-1, T-2
+**Dependencies:** T-2, T-5
 
-**Notes:** T-4 is the prerequisite for all user story implementation. Without migration tooling, router, API client, and test infrastructure, TDD (the mandated methodology per CLAUDE.md) cannot begin. All user stories that previously depended on T-1 and/or T-2 now depend on T-4 instead, since T-4 transitively includes both.
+**Notes:** T-4 is the prerequisite for all user story implementation. Without migration tooling, router, and test infrastructure, TDD (the mandated methodology per CLAUDE.md) cannot begin. The API client layer is provided by T-5 (openapi-fetch + generated types). All user stories that previously depended on T-1 and/or T-2 now depend on T-4 instead, since T-4 transitively includes T-1, T-2, and T-5.