# Multi-Tenant Club Work Manager

## TL;DR

> **Quick Summary**: Build a greenfield multi-tenant SaaS application for clubs (tennis, cycling, etc.) to manage work items (tasks + time-slot shifts) across their members. Credential-based multi-tenancy with PostgreSQL RLS, Keycloak auth, .NET 10 backend, Next.js frontend, deployed to Kubernetes.
> 
> **Deliverables**:
> - .NET 10 REST API with multi-tenant data isolation (RLS + Finbuckle)
> - Next.js frontend with Tailwind + shadcn/ui, club-switcher, task & shift management
> - Keycloak integration for authentication with multi-club membership
> - PostgreSQL schema with RLS policies and EF Core migrations
> - Docker Compose for local development (hot reload, Keycloak, PostgreSQL)
> - Kubernetes manifests (Kustomize base + dev overlay)
> - Gitea CI pipeline (`.gitea/workflows/ci.yml`) for backend/frontend/infrastructure validation
> - Comprehensive TDD test suite (xUnit + Testcontainers, Vitest + RTL, Playwright E2E)
> - Seed data for development (2 clubs, 5 users, sample tasks + shifts)
> 
> **Estimated Effort**: Large
> **Parallel Execution**: YES — 7 waves
> **Critical Path**: Monorepo scaffold → Auth pipeline → Multi-tenancy layer → Domain model → API endpoints → Frontend → K8s manifests

---

## Context

### Original Request
Build a multi-tenant internet application for managing work items over several members of a club (e.g. Tennis club, cycling club). Backend in .NET + PostgreSQL, frontend in Next.js + Bun, deployed to Kubernetes with local Docker Compose for development.

### Interview Summary
**Key Discussions**:
- **Tenant identification**: Credential-based (not subdomain). User logs in, JWT claims identify club memberships. Active club selected via X-Tenant-Id header.
- **Work items**: Hybrid — task-based (5-state: Open → Assigned → In Progress → Review → Done) AND time-slot shift scheduling with member sign-up.
- **Auth**: Keycloak (self-hosted), single realm, user attributes for club membership, custom protocol mapper for JWT claims.
- **Multi-club**: Users can belong to multiple clubs with different roles (Admin/Manager/Member/Viewer per club).
- **Scale**: MVP — 1-5 clubs, <100 users.
- **Testing**: TDD approach (tests first).
- **Notifications**: None for MVP.
- **CI extension**: Add Gitea-hosted CI pipeline for this repository.
- **Pipeline scope**: CI-only (build/test/lint/manifest validation), no auto-deploy in this iteration.

**Research Findings**:
- **Finbuckle.MultiTenant**: ClaimStrategy + HeaderStrategy fallback is production-proven (fullstackhero/dotnet-starter-kit pattern).
- **Middleware order**: `UseAuthentication()` → `UseMultiTenant()` → `UseAuthorization()` (single Keycloak realm, ClaimStrategy needs claims).
- **RLS safety**: Use `SET LOCAL` (transaction-scoped) not `SET` to prevent stale tenant context in pooled connections.
- **EF Core + RLS**: Do NOT use Finbuckle's `IsMultiTenant()` shadow property — use explicit `TenantId` column + RLS only (avoids double-filtering).
- **Bun**: P99 latency issues with Next.js SSR (340ms vs 120ms Node.js). Use Bun for dev/package management, Node.js for production.
- **.NET 10**: Built-in `AddOpenApi()` (no Swashbuckle). 49% faster than .NET 8.
- **Keycloak**: Use `--import-realm` for dev bootstrapping. User attributes + custom protocol mapper for club claims.
- **Kustomize**: Simpler than Helm for MVP. Base + overlays structure.

### Metis Review
**Identified Gaps** (all resolved):
- **Club data model**: Club is both tenant container AND domain entity (name, sport type). Provisioned via Keycloak admin + seed script.
- **User-Club DB relationship**: `UserClubMembership` junction table needed for assignment queries. Synced from Keycloak on first login.
- **Task workflow rules**: Admin/Manager assigns. Assignee transitions through states. Only backward: Review → In Progress. Concurrency via EF Core `RowVersion`.
- **Shift semantics**: First-come-first-served sign-up. Cancel anytime before start. No waitlist. Optimistic concurrency for last-slot race.
- **Seed data**: 2 clubs, 5 users (1 admin, 1 manager, 2 members, 1 viewer), sample tasks + shifts.
- **API style**: REST + OpenAPI (built-in). URL: `/api/tasks` with tenant from header, not path.
- **Data fetching**: TanStack Query (client) + Server Components (initial load).
- **First login UX**: 1 club → auto-select. Multiple → picker. Zero → "Contact admin".
- **RLS migration safety**: `bypass_rls_policy` on all RLS-enabled tables for migrations.

---

## Work Objectives

### Core Objective
Deliver a working multi-tenant club work management application where authenticated members can manage tasks and sign up for shifts within their club context, with full data isolation between tenants.

### Concrete Deliverables
- `/backend/WorkClub.sln` — .NET 10 solution (Api, Application, Domain, Infrastructure, Tests.Unit, Tests.Integration)
- `/frontend/` — Next.js 15 App Router project with Tailwind + shadcn/ui
- `/docker-compose.yml` — Local dev stack (PostgreSQL, Keycloak, .NET API, Next.js)
- `/infra/k8s/` — Kustomize manifests (base + dev overlay)
- `/.gitea/workflows/ci.yml` — Gitea Actions CI pipeline (parallel backend/frontend/infra checks)
- PostgreSQL database with RLS policies on all tenant-scoped tables
- Keycloak realm configuration with test users and club memberships
- Seed data for development

### Definition of Done
- [x] `docker compose up` starts all 4 services healthy within 90s
- [x] Keycloak login returns JWT with club claims
- [x] API enforces tenant isolation (cross-tenant requests return 403)
- [x] RLS blocks data access at DB level without tenant context
- [x] Tasks follow 5-state workflow with invalid transitions rejected (422)
- [x] Shifts support sign-up with capacity enforcement (409 when full)
- [x] Frontend shows club-switcher, task list, shift list
- [x] `dotnet test` passes all unit + integration tests
- [x] `bun run test` passes all frontend tests
- [x] `kustomize build infra/k8s/overlays/dev` produces valid YAML
- [ ] Gitea Actions CI passes on push/PR with backend + frontend + infra jobs

### Must Have
- Credential-based multi-tenancy (JWT claims + X-Tenant-Id header)
- PostgreSQL RLS with `SET LOCAL` for connection pooling safety
- Finbuckle.MultiTenant with ClaimStrategy + HeaderStrategy fallback
- Backend validates JWT `clubs` claim against X-Tenant-Id → 403 on mismatch
- 4-role authorization per club (Admin, Manager, Member, Viewer)
- 5-state task workflow with state machine validation
- Time-slot shift scheduling with capacity and first-come-first-served sign-up
- Club-switcher in frontend for multi-club users
- EF Core concurrency tokens on Task and Shift entities
- Seed data: 2 clubs, 5 users, sample tasks + shifts
- Docker Compose with hot reload for .NET and Next.js
- Kubernetes Kustomize manifests (base + dev overlay)
- TDD: all backend features have tests BEFORE implementation
- Gitea-hosted CI pipeline for this repository (`code.hal9000.damnserver.com/MasterMito/work-club-manager`)
- CI jobs run in parallel (backend, frontend, infrastructure validation)

### Must NOT Have (Guardrails)
- **No CQRS/MediatR** — Direct service injection from controllers/endpoints
- **No generic repository pattern** — Use DbContext directly (EF Core IS the unit of work)
- **No event sourcing** — Enum column + domain validation for task states
- **No Finbuckle `IsMultiTenant()` shadow property** — Explicit `TenantId` column + RLS only
- **No Swashbuckle** — Use .NET 10 built-in `AddOpenApi()`
- **No abstraction over shadcn/ui** — Use components as-is
- **No custom HTTP client wrapper** — Use `fetch` with auth headers
- **No database-per-tenant or schema-per-tenant** — Single DB, shared schema, RLS
- **No social login, self-registration, custom Keycloak themes, or 2FA**
- **No recurring shifts, waitlists, swap requests, or approval flows**
- **No custom roles or field-level permissions** — 4 fixed roles
- **No notifications (email/push)** — Users check the app
- **No API versioning, rate limiting, or HATEOAS** — MVP scope
- **No in-memory database for tests** — Real PostgreSQL via Testcontainers
- **No billing, subscriptions, or analytics dashboard**
- **No mobile app**
- **No automatic deployment in this CI extension** — CD remains out-of-scope for this append

---

## Verification Strategy

> **ZERO HUMAN INTERVENTION** — ALL verification is agent-executed. No exceptions.
> Acceptance criteria requiring "user manually tests/confirms" are FORBIDDEN.

### Test Decision
- **Infrastructure exists**: NO (greenfield)
- **Automated tests**: YES (TDD — tests first)
- **Backend framework**: xUnit + Testcontainers (postgres:16-alpine) + WebApplicationFactory
- **Frontend framework**: Vitest + React Testing Library
- **E2E framework**: Playwright
- **If TDD**: Each task follows RED (failing test) → GREEN (minimal impl) → REFACTOR

### QA Policy
Every task MUST include agent-executed QA scenarios (see TODO template below).
Evidence saved to `.sisyphus/evidence/task-{N}-{scenario-slug}.{ext}`.

- **Frontend/UI**: Use Playwright (playwright skill) — Navigate, interact, assert DOM, screenshot
- **TUI/CLI**: Use interactive_bash (tmux) — Run command, send keystrokes, validate output
- **API/Backend**: Use Bash (curl) — Send requests, assert status + response fields
- **Library/Module**: Use Bash (dotnet test / bun test) — Run tests, compare output
- **Infrastructure**: Use Bash (docker compose / kustomize build) — Validate configs

---

## Execution Strategy

### Parallel Execution Waves

```
Wave 1 (Start Immediately — scaffolding + infrastructure):
├── Task 1: Monorepo structure + git init + solution scaffold [quick]
├── Task 2: Docker Compose (PostgreSQL + Keycloak) [quick]
├── Task 3: Keycloak realm configuration + test users [unspecified-high]
├── Task 4: Domain entities + value objects [quick]
├── Task 5: Next.js project scaffold + Tailwind + shadcn/ui [quick]
└── Task 6: Kustomize base manifests [quick]

Wave 2 (After Wave 1 — data layer + auth):
├── Task 7: PostgreSQL schema + EF Core migrations + RLS policies (depends: 1, 2, 4) [deep]
├── Task 8: Finbuckle multi-tenant middleware + tenant validation (depends: 1, 3) [deep]
├── Task 9: Keycloak JWT auth in .NET + role-based authorization (depends: 1, 3) [deep]
├── Task 10: NextAuth.js Keycloak integration (depends: 3, 5) [unspecified-high]
├── Task 11: Seed data script (depends: 2, 3, 4) [quick]
└── Task 12: Backend test infrastructure (xUnit + Testcontainers + WebApplicationFactory) (depends: 1) [unspecified-high]

Wave 3 (After Wave 2 — core API):
├── Task 13: RLS integration tests — multi-tenant isolation proof (depends: 7, 8, 12) [deep]
├── Task 14: Task CRUD API endpoints + 5-state workflow (depends: 7, 8, 9) [deep]
├── Task 15: Shift CRUD API + sign-up/cancel endpoints (depends: 7, 8, 9) [deep]
├── Task 16: Club + Member API endpoints (depends: 7, 8, 9) [unspecified-high]
└── Task 17: Frontend test infrastructure (Vitest + RTL + Playwright) (depends: 5) [quick]

Wave 4 (After Wave 3 — frontend pages):
├── Task 18: App layout + club-switcher + auth guard (depends: 10, 16, 17) [visual-engineering]
├── Task 19: Task list + task detail + status transitions UI (depends: 14, 17, 18) [visual-engineering]
├── Task 20: Shift list + shift detail + sign-up UI (depends: 15, 17, 18) [visual-engineering]
└── Task 21: Login page + first-login club picker (depends: 10, 17) [visual-engineering]

Wave 5 (After Wave 4 — polish + Docker):
├── Task 22: Docker Compose full stack (backend + frontend + hot reload) (depends: 14, 15, 18) [unspecified-high]
├── Task 23: Backend Dockerfiles (dev + prod multi-stage) (depends: 14) [quick]
├── Task 24: Frontend Dockerfiles (dev + prod standalone) (depends: 18) [quick]
└── Task 25: Kustomize dev overlay + resource limits + health checks (depends: 6, 23, 24) [unspecified-high]

Wave 6 (After Wave 5 — E2E + integration):
├── Task 26: Playwright E2E tests — auth flow + club switching (depends: 21, 22) [unspecified-high]
├── Task 27: Playwright E2E tests — task management flow (depends: 19, 22) [unspecified-high]
├── Task 28: Playwright E2E tests — shift sign-up flow (depends: 20, 22) [unspecified-high]
└── Task 29: Gitea CI workflow (backend + frontend + infra checks) (depends: 12, 17, 23, 24, 25) [unspecified-high]

Wave FINAL (After ALL tasks — independent review, 4 parallel):
├── Task F1: Plan compliance audit (oracle)
├── Task F2: Code quality review (unspecified-high)
├── Task F3: Real manual QA (unspecified-high)
└── Task F4: Scope fidelity check (deep)

Critical Path: Task 1 → Task 5 → Task 17 → Task 18 → Task 24 → Task 25 → Task 29 → F1-F4
Parallel Speedup: ~68% faster than sequential
Max Concurrent: 6 (Wave 1)
```

### Dependency Matrix

| Task | Depends On | Blocks | Wave |
|------|-----------|--------|------|
| 1 | — | 7, 8, 9, 12 | 1 |
| 2 | — | 7, 11, 22 | 1 |
| 3 | — | 8, 9, 10, 11 | 1 |
| 4 | — | 7, 11 | 1 |
| 5 | — | 10, 17 | 1 |
| 6 | — | 25 | 1 |
| 7 | 1, 2, 4 | 13, 14, 15, 16 | 2 |
| 8 | 1, 3 | 13, 14, 15, 16 | 2 |
| 9 | 1, 3 | 14, 15, 16 | 2 |
| 10 | 3, 5 | 18, 21 | 2 |
| 11 | 2, 3, 4 | 22 | 2 |
| 12 | 1 | 13 | 2 |
| 13 | 7, 8, 12 | 14, 15 | 3 |
| 14 | 7, 8, 9 | 19, 22, 23 | 3 |
| 15 | 7, 8, 9 | 20, 22 | 3 |
| 16 | 7, 8, 9 | 18 | 3 |
| 17 | 5 | 18, 19, 20, 21 | 3 |
| 18 | 10, 16, 17 | 19, 20, 22 | 4 |
| 19 | 14, 17, 18 | 27 | 4 |
| 20 | 15, 17, 18 | 28 | 4 |
| 21 | 10, 17 | 26 | 4 |
| 22 | 14, 15, 18 | 26, 27, 28 | 5 |
| 23 | 14 | 25 | 5 |
| 24 | 18 | 25 | 5 |
| 25 | 6, 23, 24 | — | 5 |
| 26 | 21, 22 | — | 6 |
| 27 | 19, 22 | — | 6 |
| 28 | 20, 22 | — | 6 |
| 29 | 12, 17, 23, 24, 25 | F1-F4 | 6 |
| F1-F4 | ALL | — | FINAL |

### Agent Dispatch Summary

- **Wave 1 (6 tasks)**: T1 → `quick`, T2 → `quick`, T3 → `unspecified-high`, T4 → `quick`, T5 → `quick`, T6 → `quick`
- **Wave 2 (6 tasks)**: T7 → `deep`, T8 → `deep`, T9 → `deep`, T10 → `unspecified-high`, T11 → `quick`, T12 → `unspecified-high`
- **Wave 3 (5 tasks)**: T13 → `deep`, T14 → `deep`, T15 → `deep`, T16 → `unspecified-high`, T17 → `quick`
- **Wave 4 (4 tasks)**: T18 → `visual-engineering`, T19 → `visual-engineering`, T20 → `visual-engineering`, T21 → `visual-engineering`
- **Wave 5 (4 tasks)**: T22 → `unspecified-high`, T23 → `quick`, T24 → `quick`, T25 → `unspecified-high`
- **Wave 6 (4 tasks)**: T26 → `unspecified-high`, T27 → `unspecified-high`, T28 → `unspecified-high`, T29 → `unspecified-high`
- **FINAL (4 tasks)**: F1 → `oracle`, F2 → `unspecified-high`, F3 → `unspecified-high`, F4 → `deep`

---

## TODOs

- [x] 1. Monorepo Structure + Git Repository + .NET Solution Scaffold

  **What to do**:
  - Initialize git repository: `git init` at repo root
  - Create monorepo directory structure: `/backend/`, `/frontend/`, `/infra/`
  - Initialize .NET 10 solution at `/backend/WorkClub.sln`
  - Create projects: `WorkClub.Api` (web), `WorkClub.Application` (classlib), `WorkClub.Domain` (classlib), `WorkClub.Infrastructure` (classlib), `WorkClub.Tests.Unit` (xunit), `WorkClub.Tests.Integration` (xunit)
  - Configure project references: Api → Application → Domain ← Infrastructure. Tests → all.
  - Add `.gitignore` (combined dotnet + node + IDE entries), `.editorconfig` (C# conventions), `global.json` (pin .NET 10 SDK)
  - Create initial commit with repo structure and configuration files
  - Add NuGet packages to Api: `Npgsql.EntityFrameworkCore.PostgreSQL`, `Finbuckle.MultiTenant`, `Microsoft.AspNetCore.Authentication.JwtBearer`
  - Add NuGet packages to Infrastructure: `Npgsql.EntityFrameworkCore.PostgreSQL`, `Microsoft.EntityFrameworkCore.Design`
  - Add NuGet packages to Tests.Integration: `Testcontainers.PostgreSql`, `Microsoft.AspNetCore.Mvc.Testing`
  - Verify `dotnet build` compiles with zero errors

  **Must NOT do**:
  - Do NOT add MediatR, AutoMapper, or FluentValidation
  - Do NOT create generic repository interfaces
  - Do NOT add Swashbuckle — will use built-in `AddOpenApi()` later

  **Recommended Agent Profile**:
  - **Category**: `quick`
    - Reason: Straightforward scaffolding with well-known dotnet CLI commands
  - **Skills**: []
    - No special skills needed — standard dotnet CLI operations

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 1 (with Tasks 2, 3, 4, 5, 6)
  - **Blocks**: Tasks 7, 8, 9, 12
  - **Blocked By**: None

  **References**:

  **Pattern References**:
  - None (greenfield — no existing code)

  **External References**:
  - .NET 10 SDK: `dotnet new sln`, `dotnet new webapi`, `dotnet new classlib`, `dotnet new xunit`
  - Clean Architecture layout: Api → Application → Domain ← Infrastructure (standard .NET layering)
  - `global.json` format: `{ "sdk": { "version": "10.0.100", "rollForward": "latestFeature" } }`

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Git repository initialized
    Tool: Bash
    Preconditions: Repo root exists
    Steps:
      1. Run `git rev-parse --is-inside-work-tree`
      2. Assert output is "true"
      3. Run `git log --oneline -1`
      4. Assert initial commit exists
      5. Run `cat .gitignore`
      6. Assert contains "bin/", "obj/", "node_modules/", ".next/"
    Expected Result: Git repo initialized with comprehensive .gitignore
    Failure Indicators: Not a git repo, missing .gitignore entries
    Evidence: .sisyphus/evidence/task-1-git-init.txt

  Scenario: Solution builds successfully
    Tool: Bash
    Preconditions: .NET 10 SDK installed
    Steps:
      1. Run `dotnet build backend/WorkClub.sln --configuration Release`
      2. Check exit code is 0
      3. Verify all 6 projects are listed in build output
    Expected Result: Exit code 0, output contains "6 succeeded, 0 failed"
    Failure Indicators: Any "error" or non-zero exit code
    Evidence: .sisyphus/evidence/task-1-solution-build.txt

  Scenario: Project references are correct
    Tool: Bash
    Preconditions: Solution exists
    Steps:
      1. Run `dotnet list backend/src/WorkClub.Api/WorkClub.Api.csproj reference`
      2. Assert output contains "WorkClub.Application" and "WorkClub.Infrastructure"
      3. Run `dotnet list backend/src/WorkClub.Application/WorkClub.Application.csproj reference`
      4. Assert output contains "WorkClub.Domain"
      5. Run `dotnet list backend/src/WorkClub.Infrastructure/WorkClub.Infrastructure.csproj reference`
      6. Assert output contains "WorkClub.Domain"
    Expected Result: All project references match Clean Architecture dependency graph
    Failure Indicators: Missing references or circular dependencies
    Evidence: .sisyphus/evidence/task-1-project-refs.txt
  ```

  **Commit**: YES
  - Message: `chore(scaffold): initialize git repo and monorepo with .NET solution`
  - Files: `backend/**/*.csproj`, `backend/WorkClub.sln`, `.gitignore`, `.editorconfig`, `global.json`
  - Pre-commit: `dotnet build backend/WorkClub.sln`

- [x] 2. Docker Compose — PostgreSQL + Keycloak

  **What to do**:
  - Create `/docker-compose.yml` at repo root with services:
    - `postgres`: PostgreSQL 16 Alpine, port 5432, volume `postgres-data`, healthcheck via `pg_isready`
    - `keycloak`: Keycloak 26.x (quay.io/keycloak/keycloak:26.1), port 8080, depends on postgres, `--import-realm` flag with volume mount to `/opt/keycloak/data/import`
  - Configure PostgreSQL: database `workclub`, user `app`, password `devpass` (dev only)
  - Configure Keycloak: admin user `admin`/`admin`, PostgreSQL as Keycloak's own database (separate DB `keycloak`)
  - Create placeholder realm file at `/infra/keycloak/realm-export.json` (will be populated in Task 3)
  - Add `app-network` bridge network connecting all services
  - Verify both services start and pass health checks

  **Must NOT do**:
  - Do NOT add backend or frontend services yet (Task 22)
  - Do NOT use deprecated `KEYCLOAK_IMPORT` env var — use `--import-realm` CLI flag

  **Recommended Agent Profile**:
  - **Category**: `quick`
    - Reason: Standard Docker Compose YAML, well-documented services
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 1 (with Tasks 1, 3, 4, 5, 6)
  - **Blocks**: Tasks 7, 11, 22
  - **Blocked By**: None

  **References**:

  **External References**:
  - Keycloak Docker: `quay.io/keycloak/keycloak:26.1` with `start-dev` command for local
  - Keycloak realm import: `--import-realm` flag + volume `/opt/keycloak/data/import`
  - PostgreSQL healthcheck: `pg_isready -U app -d workclub`
  - Keycloak healthcheck: `curl -sf http://localhost:8080/health/ready || exit 1`

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: PostgreSQL starts and accepts connections
    Tool: Bash
    Preconditions: Docker installed, no conflicting port 5432
    Steps:
      1. Run `docker compose up -d postgres`
      2. Wait up to 30s: `docker compose exec postgres pg_isready -U app -d workclub`
      3. Assert exit code 0
      4. Run `docker compose exec postgres psql -U app -d workclub -c "SELECT 1"`
      5. Assert output contains "1"
    Expected Result: PostgreSQL healthy and accepting queries
    Failure Indicators: pg_isready fails, connection refused
    Evidence: .sisyphus/evidence/task-2-postgres-health.txt

  Scenario: Keycloak starts and serves OIDC discovery
    Tool: Bash
    Preconditions: docker compose up -d (postgres + keycloak)
    Steps:
      1. Run `docker compose up -d`
      2. Wait up to 120s for Keycloak health: poll `curl -sf http://localhost:8080/health/ready`
      3. Curl `http://localhost:8080/realms/master/.well-known/openid-configuration`
      4. Assert HTTP 200 and JSON contains "issuer" field
    Expected Result: Keycloak healthy, OIDC endpoint responding
    Failure Indicators: Keycloak fails to start, OIDC endpoint returns non-200
    Evidence: .sisyphus/evidence/task-2-keycloak-health.txt
  ```

  **Commit**: YES
  - Message: `infra(docker): add Docker Compose with PostgreSQL and Keycloak`
  - Files: `docker-compose.yml`, `infra/keycloak/realm-export.json`
  - Pre-commit: `docker compose config`

- [x] 3. Keycloak Realm Configuration + Test Users

  **What to do**:
  - Create Keycloak realm `workclub` with:
    - Client `workclub-api` (confidential, service account enabled) for backend
    - Client `workclub-app` (public, PKCE) for frontend — redirect URIs: `http://localhost:3000/*`
    - Custom user attribute `clubs` (JSON string: `{"club-1-uuid": "admin", "club-2-uuid": "member"}`)
    - Custom protocol mapper `club-membership` (type: `Script Mapper` or `User Attribute` → JWT claim `clubs`)
  - Create 5 test users:
    - `admin@test.com` / `testpass123` — Admin of club-1, Member of club-2
    - `manager@test.com` / `testpass123` — Manager of club-1
    - `member1@test.com` / `testpass123` — Member of club-1, Member of club-2
    - `member2@test.com` / `testpass123` — Member of club-1
    - `viewer@test.com` / `testpass123` — Viewer of club-1
  - Export realm to `/infra/keycloak/realm-export.json` including users (with hashed passwords)
  - Test: obtain token for admin@test.com, decode JWT, verify `clubs` claim is present

  **Must NOT do**:
  - Do NOT add social login providers
  - Do NOT add self-registration flow
  - Do NOT customize Keycloak login theme
  - Do NOT use Keycloak Organizations feature (too new for MVP)

  **Recommended Agent Profile**:
  - **Category**: `unspecified-high`
    - Reason: Keycloak realm configuration requires understanding OIDC flows, custom mappers, and realm export format
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 1 (with Tasks 1, 2, 4, 5, 6)
  - **Blocks**: Tasks 8, 9, 10, 11
  - **Blocked By**: None (creates realm export JSON file; Docker Compose from Task 2 will use it, but the file can be created independently)

  **References**:

  **External References**:
  - Keycloak Admin REST API: `https://www.keycloak.org/docs-api/latest/rest-api/` — for programmatic realm creation
  - Keycloak realm export format: JSON with `realm`, `clients`, `users`, `protocolMappers` arrays
  - Custom protocol mapper: `oidc-usermodel-attribute-mapper` type with `claim.name: clubs`, `user.attribute: clubs`
  - PKCE client config: `publicClient: true`, `standardFlowEnabled: true`, `directAccessGrantsEnabled: true` (for dev token testing)

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Token contains club membership claims
    Tool: Bash
    Preconditions: docker compose up -d (with realm imported)
    Steps:
      1. Obtain token: `curl -sf -X POST http://localhost:8080/realms/workclub/protocol/openid-connect/token -d "client_id=workclub-app&username=admin@test.com&password=testpass123&grant_type=password"`
      2. Extract access_token from JSON response
      3. Decode JWT payload: `echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq '.clubs'`
      4. Assert clubs claim contains `{"club-1-uuid": "admin", "club-2-uuid": "member"}`
    Expected Result: JWT has `clubs` claim with correct role mappings
    Failure Indicators: Missing `clubs` claim, wrong roles, token request fails
    Evidence: .sisyphus/evidence/task-3-jwt-claims.txt

  Scenario: All 5 test users can authenticate
    Tool: Bash
    Preconditions: Keycloak running with realm imported
    Steps:
      1. For each user (admin@test.com, manager@test.com, member1@test.com, member2@test.com, viewer@test.com):
         curl token endpoint with username/password
      2. Assert HTTP 200 for all 5 users
      3. Assert each response contains "access_token" field
    Expected Result: All 5 users authenticate successfully
    Failure Indicators: Any user returns non-200, missing access_token
    Evidence: .sisyphus/evidence/task-3-user-auth.txt
  ```

  **Commit**: YES
  - Message: `infra(keycloak): configure realm with test users and club memberships`
  - Files: `infra/keycloak/realm-export.json`
  - Pre-commit: —

---

- [x] 4. Domain Entities + Value Objects

  **What to do**:
  - Create domain entities in `WorkClub.Domain/Entities/`:
    - `Club`: Id (Guid), TenantId (string), Name, SportType (enum), Description, CreatedAt, UpdatedAt
    - `Member`: Id (Guid), TenantId (string), ExternalUserId (string — Keycloak sub), DisplayName, Email, Role (enum: Admin/Manager/Member/Viewer), ClubId (FK), CreatedAt, UpdatedAt
    - `WorkItem` (Task): Id (Guid), TenantId (string), Title, Description, Status (enum: Open/Assigned/InProgress/Review/Done), AssigneeId (FK? nullable), CreatedById (FK), ClubId (FK), DueDate (DateTimeOffset?), CreatedAt, UpdatedAt, RowVersion (byte[] — concurrency token)
    - `Shift`: Id (Guid), TenantId (string), Title, Description, Location (string?), StartTime (DateTimeOffset), EndTime (DateTimeOffset), Capacity (int, default 1), ClubId (FK), CreatedById (FK), CreatedAt, UpdatedAt, RowVersion (byte[])
    - `ShiftSignup`: Id (Guid), ShiftId (FK), MemberId (FK), SignedUpAt (DateTimeOffset)
  - Create enums in `WorkClub.Domain/Enums/`:
    - `SportType`: Tennis, Cycling, Swimming, Football, Other
    - `ClubRole`: Admin, Manager, Member, Viewer
    - `WorkItemStatus`: Open, Assigned, InProgress, Review, Done
  - Create `ITenantEntity` marker interface: `string TenantId { get; set; }`
  - Create `WorkItemStatus` state machine validation method on `WorkItem` entity:
    - Valid transitions: Open→Assigned, Assigned→InProgress, InProgress→Review, Review→Done, Review→InProgress
    - Method: `bool CanTransitionTo(WorkItemStatus newStatus)` + `void TransitionTo(WorkItemStatus newStatus)` (throws on invalid)
  - Write unit tests FIRST (TDD): test state machine — valid transitions succeed, invalid transitions throw

  **Must NOT do**:
  - Do NOT add event sourcing or domain events
  - Do NOT create repository interfaces — will use DbContext directly
  - Do NOT add navigation properties yet (EF Core configuration is Task 7)

  **Recommended Agent Profile**:
  - **Category**: `quick`
    - Reason: Simple POCO classes and enum definitions with straightforward unit tests
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 1 (with Tasks 1, 2, 3, 5, 6)
  - **Blocks**: Tasks 7, 11
  - **Blocked By**: None

  **References**:

  **External References**:
  - C# 14 record types for value objects: `public record SportType(string Value)`
  - State machine pattern: simple `switch` expression in entity method — no external library needed
  - `ITenantEntity` interface pattern from Metis research: explicit TenantId property (not Finbuckle shadow)

  **Acceptance Criteria**:

  **If TDD:**
  - [ ] Test file created: `backend/tests/WorkClub.Tests.Unit/Domain/WorkItemStatusTests.cs`
  - [ ] `dotnet test backend/tests/WorkClub.Tests.Unit` → PASS (all state machine tests)

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Valid state transitions succeed
    Tool: Bash
    Preconditions: Unit test project compiles
    Steps:
      1. Run `dotnet test backend/tests/WorkClub.Tests.Unit --filter "WorkItemStatus" --verbosity normal`
      2. Assert tests cover: Open→Assigned, Assigned→InProgress, InProgress→Review, Review→Done, Review→InProgress
      3. Assert all pass
    Expected Result: 5 valid transition tests pass
    Failure Indicators: Any test fails, missing test cases
    Evidence: .sisyphus/evidence/task-4-state-machine-valid.txt

  Scenario: Invalid state transitions throw
    Tool: Bash
    Preconditions: Unit test project compiles
    Steps:
      1. Run `dotnet test backend/tests/WorkClub.Tests.Unit --filter "InvalidTransition" --verbosity normal`
      2. Assert tests cover: Open→Done, Open→InProgress, Assigned→Done, InProgress→Open, Done→anything
      3. Assert all pass (each asserts exception thrown)
    Expected Result: Invalid transition tests pass (exceptions correctly thrown)
    Failure Indicators: Missing invalid transition tests, test failures
    Evidence: .sisyphus/evidence/task-4-state-machine-invalid.txt
  ```

  **Commit**: YES
  - Message: `feat(domain): add core entities — Club, Member, WorkItem, Shift with state machine`
  - Files: `backend/src/WorkClub.Domain/**/*.cs`, `backend/tests/WorkClub.Tests.Unit/Domain/*.cs`
  - Pre-commit: `dotnet test backend/tests/WorkClub.Tests.Unit`

- [x] 5. Next.js Project Scaffold + Tailwind + shadcn/ui

  **What to do**:
  - Initialize Next.js 15 project in `/frontend/` using `bunx create-next-app@latest` with:
    - App Router (not Pages), TypeScript, Tailwind CSS, ESLint, `src/` directory
    - `output: 'standalone'` in `next.config.ts`
  - Install and configure shadcn/ui: `bunx shadcn@latest init`
    - Install initial components: Button, Card, Badge, Input, Label, Select, Dialog, DropdownMenu, Table, Toast
  - Configure path aliases in `tsconfig.json`: `@/*` → `src/*`
  - Create directory structure:
    - `src/app/` — App Router pages
    - `src/components/` — shared components
    - `src/lib/` — utilities
    - `src/hooks/` — custom hooks
    - `src/types/` — TypeScript types
  - Add environment variables to `.env.local.example`:
    - `NEXT_PUBLIC_API_URL=http://localhost:5000`
    - `NEXTAUTH_URL=http://localhost:3000`
    - `NEXTAUTH_SECRET=dev-secret-change-me`
    - `KEYCLOAK_ISSUER=http://localhost:8080/realms/workclub`
    - `KEYCLOAK_CLIENT_ID=workclub-app`
    - `KEYCLOAK_CLIENT_SECRET=<from-keycloak>`
  - Verify `bun run build` succeeds

  **Must NOT do**:
  - Do NOT install Bun-specific Next.js plugins — use standard Next.js
  - Do NOT create custom component wrappers over shadcn/ui
  - Do NOT add auth pages yet (Task 21)

  **Recommended Agent Profile**:
  - **Category**: `quick`
    - Reason: Standard Next.js scaffolding with well-known CLI tools
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 1 (with Tasks 1, 2, 3, 4, 6)
  - **Blocks**: Tasks 10, 17
  - **Blocked By**: None

  **References**:

  **External References**:
  - Next.js create-next-app: `bunx create-next-app@latest frontend --typescript --tailwind --eslint --app --src-dir --use-bun`
  - shadcn/ui init: `bunx shadcn@latest init` then `bunx shadcn@latest add button card badge input label select dialog dropdown-menu table toast`
  - `next.config.ts`: `{ output: 'standalone' }` for Docker deployment
  - Standalone output: copies only needed `node_modules`, creates `server.js` entry point

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Next.js builds successfully
    Tool: Bash
    Preconditions: Bun installed, frontend/ directory exists
    Steps:
      1. Run `bun run build` in frontend/
      2. Assert exit code 0
      3. Verify `.next/standalone/server.js` exists
    Expected Result: Build succeeds with standalone output
    Failure Indicators: TypeScript errors, build failure, missing standalone
    Evidence: .sisyphus/evidence/task-5-nextjs-build.txt

  Scenario: Dev server starts
    Tool: Bash
    Preconditions: frontend/ exists with dependencies installed
    Steps:
      1. Start `bun run dev` in background
      2. Wait 10s, then curl `http://localhost:3000`
      3. Assert HTTP 200
      4. Kill dev server
    Expected Result: Dev server responds on port 3000
    Failure Indicators: Server fails to start, non-200 response
    Evidence: .sisyphus/evidence/task-5-dev-server.txt
  ```

  **Commit**: YES
  - Message: `chore(frontend): initialize Next.js project with Tailwind and shadcn/ui`
  - Files: `frontend/**`
  - Pre-commit: `bun run build` (in frontend/)

- [x] 6. Kustomize Base Manifests

  **What to do**:
  - Create `/infra/k8s/base/kustomization.yaml` referencing all base resources
  - Create base manifests:
    - `backend-deployment.yaml`: Deployment for dotnet-api (1 replica, port 8080, health probes at `/health/live`, `/health/ready`, `/health/startup`)
    - `backend-service.yaml`: ClusterIP Service (port 80 → 8080)
    - `frontend-deployment.yaml`: Deployment for nextjs (1 replica, port 3000, health probe at `/api/health`)
    - `frontend-service.yaml`: ClusterIP Service (port 80 → 3000)
    - `postgres-statefulset.yaml`: StatefulSet (1 replica, port 5432, PVC 10Gi, healthcheck via `pg_isready`)
    - `postgres-service.yaml`: Headless + primary ClusterIP service
    - `keycloak-deployment.yaml`: Deployment (1 replica, port 8080)
    - `keycloak-service.yaml`: ClusterIP Service
    - `configmap.yaml`: App configuration (non-sensitive: log level, CORS origins, API URLs)
    - `ingress.yaml`: Basic Ingress for single-domain routing (frontend on `/`, backend on `/api`)
  - Use resource requests/limits placeholders (overridden per environment in overlays)
  - Use image tag placeholder `latest` (overridden per environment)
  - Verify `kustomize build infra/k8s/base` produces valid YAML

  **Must NOT do**:
  - Do NOT create Helm charts
  - Do NOT add wildcard TLS/cert-manager (single domain, no subdomains)
  - Do NOT add HPA, PDB, or NetworkPolicies (production concerns, not MVP)

  **Recommended Agent Profile**:
  - **Category**: `quick`
    - Reason: Standard Kubernetes YAML manifests with well-known patterns
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 1 (with Tasks 1, 2, 3, 4, 5)
  - **Blocks**: Task 25
  - **Blocked By**: None

  **References**:

  **External References**:
  - Kustomize: `kustomization.yaml` with `resources:` list
  - .NET health probes: `/health/startup` (startupProbe), `/health/live` (livenessProbe), `/health/ready` (readinessProbe)
  - Next.js health: `/api/health` (custom route handler)
  - PostgreSQL StatefulSet: headless Service + volumeClaimTemplates
  - Ingress single-domain: path-based routing (`/` → frontend, `/api` → backend)

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Kustomize base builds valid YAML
    Tool: Bash
    Preconditions: kustomize CLI installed
    Steps:
      1. Run `kustomize build infra/k8s/base`
      2. Assert exit code 0
      3. Pipe output to `grep "kind:" | sort -u`
      4. Assert contains: ConfigMap, Deployment (x3), Ingress, Service (x4), StatefulSet
    Expected Result: Valid YAML with all expected resource kinds
    Failure Indicators: kustomize build fails, missing resource kinds
    Evidence: .sisyphus/evidence/task-6-kustomize-base.txt

  Scenario: Resource names are consistent
    Tool: Bash
    Preconditions: kustomize build succeeds
    Steps:
      1. Run `kustomize build infra/k8s/base | grep "name:" | head -20`
      2. Verify naming convention is consistent (e.g., workclub-api, workclub-frontend, workclub-postgres)
    Expected Result: All resources follow consistent naming pattern
    Failure Indicators: Inconsistent or missing names
    Evidence: .sisyphus/evidence/task-6-resource-names.txt
  ```

  **Commit**: YES
  - Message: `infra(k8s): add Kustomize base manifests for all services`
  - Files: `infra/k8s/base/**/*.yaml`
  - Pre-commit: `kustomize build infra/k8s/base`

---

- [x] 7. PostgreSQL Schema + EF Core Migrations + RLS Policies

  **What to do**:
  - Create `AppDbContext` in `WorkClub.Infrastructure/Data/`:
    - DbSets: Clubs, Members, WorkItems, Shifts, ShiftSignups
    - Configure entity mappings via `IEntityTypeConfiguration<T>` classes
    - Configure `RowVersion` as concurrency token on WorkItem and Shift (`UseXminAsConcurrencyToken()`)
    - Configure indexes: `TenantId` on all tenant-scoped tables, `ClubId` on Member/WorkItem/Shift, `Status` on WorkItem
    - Configure relationships: Club → Members, Club → WorkItems, Club → Shifts, Shift → ShiftSignups, Member → ShiftSignups
  - Create initial EF Core migration
  - Create SQL migration script for RLS policies (run after EF migration):
    - `ALTER TABLE ... ENABLE ROW LEVEL SECURITY` on: clubs, members, work_items, shifts, shift_signups
    - Create `tenant_isolation` policy on each table: `USING (tenant_id = current_setting('app.current_tenant_id', true)::text)`
    - Create `bypass_rls_policy` on each table for migrations role: `USING (true)` for role `app_admin`
    - Create `app_user` role (used by application) — RLS applies
    - Create `app_admin` role (used by migrations) — RLS bypassed
  - Create `TenantDbConnectionInterceptor` (implements `DbConnectionInterceptor`):
    - On `ConnectionOpenedAsync`: execute `SET LOCAL app.current_tenant_id = '{tenantId}'`
    - Get tenant ID from `IHttpContextAccessor` → `ITenantInfo` (Finbuckle)
  - Create `SaveChangesInterceptor` for automatic TenantId assignment on new entities (implements `ITenantEntity`)
  - Write integration tests FIRST (TDD):
    - Test: migration applies cleanly to fresh PostgreSQL
    - Test: RLS blocks queries without `SET LOCAL` context
    - Test: RLS allows queries with correct tenant context

  **Must NOT do**:
  - Do NOT use Finbuckle's `IsMultiTenant()` fluent API — use explicit `TenantId` property
  - Do NOT use `SET` — MUST use `SET LOCAL` for transaction-scoped tenant context
  - Do NOT use in-memory database provider for tests
  - Do NOT create generic repository pattern

  **Recommended Agent Profile**:
  - **Category**: `deep`
    - Reason: Complex EF Core configuration with RLS policies, connection interceptors, and concurrent connection pooling safety — highest-risk task in the project
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 2 (with Tasks 8, 9, 10, 11, 12)
  - **Blocks**: Tasks 13, 14, 15, 16
  - **Blocked By**: Tasks 1 (solution), 2 (Docker Compose for PostgreSQL), 4 (domain entities)

  **References**:

  **External References**:
  - EF Core Npgsql: `UseXminAsConcurrencyToken()` for PostgreSQL optimistic concurrency
  - PostgreSQL RLS: `ALTER TABLE x ENABLE ROW LEVEL SECURITY; CREATE POLICY ... USING (...)`
  - `SET LOCAL`: Transaction-scoped session variable — safe with connection pooling
  - `current_setting('app.current_tenant_id', true)`: Second param `true` returns NULL instead of error when unset
  - `DbConnectionInterceptor`: `ConnectionOpenedAsync(DbConnection, ConnectionEndEventData, CancellationToken)` — execute SQL after connection opened
  - `bypass_rls_policy`: `CREATE POLICY bypass ON table FOR ALL TO app_admin USING (true)` — allows migrations
  - Finbuckle `ITenantInfo.Id`: Access current tenant from DI

  **Acceptance Criteria**:

  **If TDD:**
  - [ ] Test file: `backend/tests/WorkClub.Tests.Integration/Data/MigrationTests.cs`
  - [ ] Test file: `backend/tests/WorkClub.Tests.Integration/Data/RlsTests.cs`

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Migration applies to fresh PostgreSQL
    Tool: Bash (Testcontainers in test)
    Preconditions: Testcontainers, Docker running
    Steps:
      1. Run `dotnet test backend/tests/WorkClub.Tests.Integration --filter "Migration" --verbosity normal`
      2. Test spins up PostgreSQL container, applies migration, verifies all tables exist
    Expected Result: All tables created (clubs, members, work_items, shifts, shift_signups)
    Failure Indicators: Migration fails, missing tables
    Evidence: .sisyphus/evidence/task-7-migration.txt

  Scenario: RLS blocks access without tenant context
    Tool: Bash (integration test)
    Preconditions: Migration applied, seed data inserted
    Steps:
      1. Run integration test that:
         a. Inserts data for tenant-1 and tenant-2 using admin role (bypass RLS)
         b. Opens connection as app_user WITHOUT `SET LOCAL`
         c. SELECT * FROM work_items → assert 0 rows
         d. Opens connection as app_user WITH `SET LOCAL app.current_tenant_id = 'tenant-1'`
         e. SELECT * FROM work_items → assert only tenant-1 rows
    Expected Result: RLS correctly filters by tenant, returns 0 without context
    Failure Indicators: Data leaks across tenants, queries return all rows
    Evidence: .sisyphus/evidence/task-7-rls-isolation.txt

  Scenario: RLS allows correct tenant access
    Tool: Bash (integration test)
    Preconditions: Migration applied, multi-tenant data seeded
    Steps:
      1. Run integration test with Testcontainers:
         a. Insert 5 work items for tenant-1, 3 for tenant-2
         b. SET LOCAL to tenant-1 → SELECT count(*) → assert 5
         c. SET LOCAL to tenant-2 → SELECT count(*) → assert 3
    Expected Result: Each tenant sees only their data
    Failure Indicators: Wrong counts, cross-tenant data visible
    Evidence: .sisyphus/evidence/task-7-rls-correct-access.txt
  ```

  **Commit**: YES (groups with Task 8)
  - Message: `feat(data): add EF Core DbContext, migrations, RLS policies, and multi-tenant middleware`
  - Files: `backend/src/WorkClub.Infrastructure/Data/**/*.cs`, SQL migration files
  - Pre-commit: `dotnet test backend/tests/WorkClub.Tests.Integration --filter "Migration|Rls"`

- [x] 8. Finbuckle Multi-Tenant Middleware + Tenant Validation

  **What to do**:
  - Configure Finbuckle in `Program.cs`:
    - `builder.Services.AddMultiTenant<TenantInfo>().WithClaimStrategy("tenant_id").WithHeaderStrategy("X-Tenant-Id")`
    - Middleware order: `UseAuthentication()` → `UseMultiTenant()` → `UseAuthorization()`
  - Create `TenantValidationMiddleware`:
    - Extract `clubs` claim from JWT
    - Extract `X-Tenant-Id` header from request
    - Validate: X-Tenant-Id MUST be present in JWT `clubs` claim → 403 if mismatch
    - Set Finbuckle tenant context
  - Create `ITenantProvider` service (scoped):
    - `GetTenantId()`: returns current tenant ID from Finbuckle context
    - `GetUserRole()`: returns user's role in current tenant from JWT clubs claim
  - Register `TenantDbConnectionInterceptor` (from Task 7) in DI
  - Write integration tests FIRST (TDD):
    - Test: request with valid JWT + matching X-Tenant-Id → 200
    - Test: request with valid JWT + non-member X-Tenant-Id → 403
    - Test: request without X-Tenant-Id header → 400
    - Test: unauthenticated request → 401

  **Must NOT do**:
  - Do NOT use Finbuckle's RouteStrategy (tenant comes from credentials, not URL)
  - Do NOT use `UseMultiTenant()` before `UseAuthentication()` (ClaimStrategy needs claims)

  **Recommended Agent Profile**:
  - **Category**: `deep`
    - Reason: Finbuckle middleware integration with custom validation, security-critical cross-tenant check
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 2 (with Tasks 7, 9, 10, 11, 12)
  - **Blocks**: Tasks 13, 14, 15, 16
  - **Blocked By**: Tasks 1 (solution), 3 (Keycloak for JWT claims)

  **References**:

  **External References**:
  - Finbuckle docs: `WithClaimStrategy(claimType)` — reads tenant from specified JWT claim
  - Finbuckle docs: `WithHeaderStrategy(headerName)` — reads from HTTP header as fallback
  - Middleware order for single realm: `UseAuthentication()` → `UseMultiTenant()` → `UseAuthorization()`
  - `IMultiTenantContextAccessor<TenantInfo>`: injected service to access resolved tenant

  **Acceptance Criteria**:

  **If TDD:**
  - [ ] Test file: `backend/tests/WorkClub.Tests.Integration/Middleware/TenantValidationTests.cs`

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Valid tenant request succeeds
    Tool: Bash (integration test with WebApplicationFactory)
    Preconditions: WebApplicationFactory configured with test Keycloak token
    Steps:
      1. Run integration test:
         a. Create JWT with clubs: {"club-1": "admin"}
         b. Send GET /api/tasks with Authorization: Bearer + X-Tenant-Id: club-1
         c. Assert HTTP 200
    Expected Result: Request passes tenant validation
    Failure Indicators: 401 or 403 when valid
    Evidence: .sisyphus/evidence/task-8-valid-tenant.txt

  Scenario: Cross-tenant access denied
    Tool: Bash (integration test)
    Preconditions: WebApplicationFactory with test JWT
    Steps:
      1. Run integration test:
         a. Create JWT with clubs: {"club-1": "admin"} (no club-2)
         b. Send GET /api/tasks with X-Tenant-Id: club-2
         c. Assert HTTP 403
    Expected Result: 403 Forbidden — user not member of requested club
    Failure Indicators: Returns 200 (data leak) or wrong error code
    Evidence: .sisyphus/evidence/task-8-cross-tenant-denied.txt

  Scenario: Missing tenant header returns 400
    Tool: Bash (integration test)
    Preconditions: WebApplicationFactory
    Steps:
      1. Send authenticated request WITHOUT X-Tenant-Id header
      2. Assert HTTP 400
    Expected Result: 400 Bad Request
    Failure Indicators: 200 or 500
    Evidence: .sisyphus/evidence/task-8-missing-header.txt
  ```

  **Commit**: YES (groups with Task 7)
  - Message: `feat(data): add EF Core DbContext, migrations, RLS policies, and multi-tenant middleware`
  - Files: `backend/src/WorkClub.Api/Middleware/*.cs`, `Program.cs` updates
  - Pre-commit: `dotnet test backend/tests/WorkClub.Tests.Integration --filter "TenantValidation"`

---

- [x] 9. Keycloak JWT Auth in .NET + Role-Based Authorization

  **What to do**:
  - Configure JWT Bearer authentication in `Program.cs`:
    - `builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(options => { options.Authority = keycloakIssuer; options.Audience = "workclub-api"; })`
  - Create custom `ClaimsPrincipal` transformation:
    - Parse `clubs` claim from JWT → extract role for current tenant → add role claims
    - Map club role to ASP.NET `ClaimTypes.Role` (e.g., "Admin", "Manager", "Member", "Viewer")
  - Create authorization policies:
    - `RequireAdmin`: requires "Admin" role
    - `RequireManager`: requires "Admin" OR "Manager" role
    - `RequireMember`: requires "Admin" OR "Manager" OR "Member" role
    - `RequireViewer`: any authenticated user with valid club membership
  - Add `builder.Services.AddOpenApi()` for API documentation
  - Map health check endpoints: `/health/live`, `/health/ready`, `/health/startup`
  - Write integration tests FIRST (TDD):
    - Test: Admin can access admin-only endpoints
    - Test: Member cannot access admin-only endpoints → 403
    - Test: Viewer can only read, not write → 403 on POST/PUT/DELETE

  **Must NOT do**:
  - Do NOT add Swashbuckle — use `AddOpenApi()` built-in
  - Do NOT implement custom JWT validation — let ASP.NET handle it
  - Do NOT add 2FA or password policies

  **Recommended Agent Profile**:
  - **Category**: `deep`
    - Reason: JWT authentication with custom claims transformation and role-based authorization requires careful security implementation
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 2 (with Tasks 7, 8, 10, 11, 12)
  - **Blocks**: Tasks 14, 15, 16
  - **Blocked By**: Tasks 1 (solution), 3 (Keycloak config)

  **References**:

  **External References**:
  - ASP.NET JWT Bearer: `AddJwtBearer` with `Authority` pointing to Keycloak realm
  - .NET 10 OpenAPI: `builder.Services.AddOpenApi()` + `app.MapOpenApi()`
  - Claims transformation: `IClaimsTransformation.TransformAsync(ClaimsPrincipal)`
  - Authorization policies: `builder.Services.AddAuthorizationBuilder().AddPolicy("RequireAdmin", p => p.RequireRole("Admin"))`
  - Health checks: `builder.Services.AddHealthChecks().AddNpgSql(connectionString)`

  **Acceptance Criteria**:

  **If TDD:**
  - [ ] Test file: `backend/tests/WorkClub.Tests.Integration/Auth/AuthorizationTests.cs`

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Role-based access control works
    Tool: Bash (integration test)
    Preconditions: WebApplicationFactory with mocked JWT claims
    Steps:
      1. Test: JWT with Admin role → GET /api/clubs → 200
      2. Test: JWT with Viewer role → POST /api/tasks → 403
      3. Test: JWT with Manager role → POST /api/tasks → 200
      4. Test: No token → any endpoint → 401
    Expected Result: Each role gets correct access level
    Failure Indicators: Wrong HTTP status codes, privilege escalation
    Evidence: .sisyphus/evidence/task-9-rbac.txt

  Scenario: Health endpoints respond without auth
    Tool: Bash
    Preconditions: API running
    Steps:
      1. curl http://localhost:5000/health/live → assert 200
      2. curl http://localhost:5000/health/ready → assert 200
    Expected Result: Health endpoints are public (no auth required)
    Failure Indicators: 401 on health endpoints
    Evidence: .sisyphus/evidence/task-9-health.txt
  ```

  **Commit**: YES
  - Message: `feat(auth): add Keycloak JWT authentication and role-based authorization`
  - Files: `backend/src/WorkClub.Api/Auth/*.cs`, `Program.cs` updates
  - Pre-commit: `dotnet test backend/tests/WorkClub.Tests.Integration --filter "Authorization"`

- [x] 10. NextAuth.js Keycloak Integration

  **What to do**:
  - Install Auth.js v5: `bun add next-auth@beta @auth/core`
  - Create `/frontend/src/auth/` directory with:
    - `auth.ts`: NextAuth config with Keycloak OIDC provider
    - Configure JWT callback to include `clubs` claim from Keycloak token
    - Configure session callback to expose clubs + active club to client
  - Create `/frontend/src/middleware.ts`:
    - Protect all routes except `/`, `/login`, `/api/auth/*`
    - Redirect unauthenticated users to `/login`
  - Create auth utility hooks:
    - `useSession()` wrapper that includes club membership
    - `useActiveClub()` — reads from local storage / cookie, provides club context
  - Create API fetch utility:
    - Wraps `fetch` with `Authorization: Bearer <token>` and `X-Tenant-Id: <activeClub>` headers
    - Used by all frontend API calls
  - Write tests FIRST (TDD):
    - Test: `useActiveClub` returns stored club
    - Test: API fetch utility includes correct headers

  **Must NOT do**:
  - Do NOT create custom HTTP client class wrapper
  - Do NOT add social login providers
  - Do NOT store tokens in localStorage (use HTTP-only cookies via NextAuth)

  **Recommended Agent Profile**:
  - **Category**: `unspecified-high`
    - Reason: Auth.js v5 configuration with OIDC + custom callbacks requires understanding of token flows
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 2 (with Tasks 7, 8, 9, 11, 12)
  - **Blocks**: Tasks 18, 21
  - **Blocked By**: Tasks 3 (Keycloak realm), 5 (Next.js scaffold)

  **References**:

  **External References**:
  - Auth.js v5 Keycloak: `import KeycloakProvider from "next-auth/providers/keycloak"`
  - Auth.js JWT callback: `jwt({ token, account }) → add clubs claim from account.access_token`
  - Auth.js session callback: `session({ session, token }) → expose clubs to client`
  - Next.js middleware: `export { auth as middleware } from "@/auth"` — or custom matcher
  - HTTP-only cookies: Default in Auth.js — tokens never exposed to client JS

  **Acceptance Criteria**:

  **If TDD:**
  - [ ] Test file: `frontend/src/hooks/__tests__/useActiveClub.test.ts`
  - [ ] Test file: `frontend/src/lib/__tests__/api.test.ts`

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Auth utility includes correct headers
    Tool: Bash (bun test)
    Preconditions: Frontend tests configured
    Steps:
      1. Run `bun run test -- --filter "api fetch"` in frontend/
      2. Assert: test verifies Authorization header contains Bearer token
      3. Assert: test verifies X-Tenant-Id header contains active club ID
    Expected Result: API utility correctly attaches auth and tenant headers
    Failure Indicators: Missing headers, wrong header names
    Evidence: .sisyphus/evidence/task-10-api-headers.txt

  Scenario: Protected routes redirect to login
    Tool: Bash (bun test)
    Preconditions: Frontend middleware configured
    Steps:
      1. Test middleware: unauthenticated request to /dashboard → redirect to /login
      2. Test middleware: request to /api/auth/* → pass through
    Expected Result: Middleware protects routes correctly
    Failure Indicators: Protected route accessible without auth
    Evidence: .sisyphus/evidence/task-10-middleware.txt
  ```

  **Commit**: YES
  - Message: `feat(frontend-auth): add NextAuth.js Keycloak integration`
  - Files: `frontend/src/auth/**`, `frontend/src/middleware.ts`, `frontend/src/lib/api.ts`, `frontend/src/hooks/useActiveClub.ts`
  - Pre-commit: `bun run build` (in frontend/)

- [x] 11. Seed Data Script

  **What to do**:
  - Create `SeedDataService` in `WorkClub.Infrastructure/Seed/`:
    - Seed 2 clubs:
      - Club 1: "Sunrise Tennis Club" (Tennis), tenant_id: "club-1-uuid"
      - Club 2: "Valley Cycling Club" (Cycling), tenant_id: "club-2-uuid"
    - Seed 5 members (matching Keycloak test users):
      - Admin user → Admin in Club 1, Member in Club 2
      - Manager user → Manager in Club 1
      - Member1 user → Member in Club 1, Member in Club 2
      - Member2 user → Member in Club 1
      - Viewer user → Viewer in Club 1
    - Seed sample work items per club:
      - Club 1: 5 tasks in various states (Open, Assigned, InProgress, Review, Done)
      - Club 2: 3 tasks (Open, Assigned, InProgress)
    - Seed sample shifts per club:
      - Club 1: 3 shifts (past, today, future) with varying capacity and sign-ups
      - Club 2: 2 shifts (today, future)
  - Register seed service to run on startup in Development environment only
  - Use `app_admin` role connection for seeding (bypasses RLS)
  - Make seed idempotent (check if data exists before inserting)

  **Must NOT do**:
  - Do NOT seed in Production — guard with `IHostEnvironment.IsDevelopment()`
  - Do NOT hard-code GUIDs — generate deterministic GUIDs from names for consistency

  **Recommended Agent Profile**:
  - **Category**: `quick`
    - Reason: Straightforward data insertion with known entities
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 2 (with Tasks 7, 8, 9, 10, 12)
  - **Blocks**: Task 22
  - **Blocked By**: Tasks 2 (Docker PostgreSQL), 3 (Keycloak users), 4 (domain entities)

  **References**:

  **External References**:
  - EF Core seeding: `context.Database.EnsureCreated()` or explicit `HasData()` in model config
  - Idempotent seeding: `if (!context.Clubs.Any()) { context.Clubs.AddRange(...) }`
  - Deterministic GUIDs: `new Guid("00000000-0000-0000-0000-000000000001")` or `Guid.CreateVersion5(namespace, name)`

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Seed data populates database
    Tool: Bash
    Preconditions: Docker Compose up (postgres + keycloak), migrations applied
    Steps:
      1. Run backend in Development mode
      2. Query: `docker compose exec postgres psql -U app_admin -d workclub -c "SELECT count(*) FROM clubs"` → assert 2
      3. Query: `SELECT count(*) FROM members` → assert ≥ 7 (5 users × some in multiple clubs)
      4. Query: `SELECT count(*) FROM work_items` → assert 8
      5. Query: `SELECT count(*) FROM shifts` → assert 5
    Expected Result: All seed data present
    Failure Indicators: Missing data, wrong counts
    Evidence: .sisyphus/evidence/task-11-seed-data.txt

  Scenario: Seed is idempotent
    Tool: Bash
    Preconditions: Seed already applied
    Steps:
      1. Run backend again (triggers seed again)
      2. Assert same counts as before (no duplicates)
    Expected Result: No duplicate records after re-running seed
    Failure Indicators: Doubled counts
    Evidence: .sisyphus/evidence/task-11-seed-idempotent.txt
  ```

  **Commit**: YES
  - Message: `feat(seed): add development seed data script`
  - Files: `backend/src/WorkClub.Infrastructure/Seed/*.cs`
  - Pre-commit: `dotnet build`

- [x] 12. Backend Test Infrastructure (xUnit + Testcontainers + WebApplicationFactory)

  **What to do**:
  - Configure `WorkClub.Tests.Integration` project:
    - Create `CustomWebApplicationFactory<T>` extending `WebApplicationFactory<Program>`:
      - Override `ConfigureWebHost`: replace PostgreSQL connection with Testcontainers
      - Spin up PostgreSQL container, apply migrations, configure test services
    - Create `TestAuthHandler` for mocking JWT auth in tests:
      - Allows tests to set custom claims (clubs, roles) without real Keycloak
      - Register as default auth scheme in test factory
    - Create base test class `IntegrationTestBase`:
      - Provides `HttpClient` with auth headers
      - Helper methods: `AuthenticateAs(email, clubs)` → sets JWT claims
      - Helper: `SetTenant(tenantId)` → sets X-Tenant-Id header
      - Implements `IAsyncLifetime` for test setup/teardown
    - Create `DatabaseFixture` (collection fixture):
      - Shares single PostgreSQL container across test class
      - Resets data between tests (truncate tables, re-seed)
  - Configure `WorkClub.Tests.Unit` project:
    - Add reference to `WorkClub.Domain` and `WorkClub.Application`
    - No database dependency (pure unit tests)
  - Verify infrastructure works:
    - Write 1 smoke test: GET /health/live → 200
    - Run: `dotnet test backend/tests/WorkClub.Tests.Integration`

  **Must NOT do**:
  - Do NOT use in-memory database — MUST use real PostgreSQL for RLS testing
  - Do NOT mock EF Core DbContext — use real DbContext with Testcontainers
  - Do NOT share mutable state between test classes

  **Recommended Agent Profile**:
  - **Category**: `unspecified-high`
    - Reason: Test infrastructure setup with Testcontainers + custom WebApplicationFactory requires careful DI configuration
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 2 (with Tasks 7, 8, 9, 10, 11)
  - **Blocks**: Task 13
  - **Blocked By**: Task 1 (solution structure)

  **References**:

  **External References**:
  - Testcontainers .NET: `new PostgreSqlBuilder().WithImage("postgres:16-alpine").Build()`
  - WebApplicationFactory: `builder.ConfigureServices(services => { /* replace DB */ })`
  - Test auth handler: `services.AddAuthentication("Test").AddScheme<AuthenticationSchemeOptions, TestAuthHandler>("Test", o => {})`
  - `IAsyncLifetime`: `InitializeAsync` / `DisposeAsync` for container lifecycle

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Smoke test passes with Testcontainers
    Tool: Bash
    Preconditions: Docker running (for Testcontainers)
    Steps:
      1. Run `dotnet test backend/tests/WorkClub.Tests.Integration --filter "SmokeTest" --verbosity normal`
      2. Assert exit code 0
      3. Assert output shows 1 test passed
    Expected Result: Health endpoint smoke test passes
    Failure Indicators: Testcontainer fails to start, test timeout
    Evidence: .sisyphus/evidence/task-12-smoke-test.txt

  Scenario: Test auth handler works
    Tool: Bash
    Preconditions: Test infrastructure configured
    Steps:
      1. Run integration test that:
         a. Creates client with TestAuthHandler claims: {"clubs": {"club-1": "admin"}}
         b. Sends request with X-Tenant-Id: club-1
         c. Asserts controller can read claims correctly
    Expected Result: Custom claims available in controller
    Failure Indicators: Claims missing, auth fails
    Evidence: .sisyphus/evidence/task-12-test-auth.txt
  ```

  **Commit**: YES
  - Message: `test(infra): add xUnit + Testcontainers + WebApplicationFactory base`
  - Files: `backend/tests/WorkClub.Tests.Integration/**/*.cs`, `backend/tests/WorkClub.Tests.Unit/**/*.cs`
  - Pre-commit: `dotnet test backend/tests/WorkClub.Tests.Integration --filter "SmokeTest"`

---

- [x] 13. RLS Integration Tests — Multi-Tenant Isolation Proof

  **What to do**:
  - Write comprehensive integration tests proving RLS data isolation:
    - **Test 1: Complete isolation** — Insert data for tenant-1 and tenant-2. Query as tenant-1 → see only tenant-1 data. Query as tenant-2 → see only tenant-2 data. Zero overlap.
    - **Test 2: No context = no data** — Query without `SET LOCAL` → 0 rows returned (RLS blocks everything)
    - **Test 3: Insert protection** — Try to INSERT with tenant-2 context but tenant-1 tenant_id value → RLS blocks
    - **Test 4: Concurrent requests** — Fire 50 parallel HTTP requests alternating tenant-1 and tenant-2 → each response contains ONLY the correct tenant's data (tests connection pool safety)
    - **Test 5: Cross-tenant header spoof** — JWT has clubs: {club-1: admin}, send X-Tenant-Id: club-2 → 403
    - **Test 6: Tenant context in interceptor** — Verify `TenantDbConnectionInterceptor` correctly sets `SET LOCAL` on each request
  - All tests use Testcontainers + WebApplicationFactory from Task 12
  - This is the CRITICAL RISK validation — must pass before building API endpoints

  **Must NOT do**:
  - Do NOT skip concurrent request test — this validates connection pool safety
  - Do NOT use in-memory database
  - Do NOT mock the RLS layer

  **Recommended Agent Profile**:
  - **Category**: `deep`
    - Reason: Security-critical tests that validate the foundation of multi-tenancy. Concurrent test requires careful async handling.
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 3 (with Tasks 14, 15, 16, 17)
  - **Blocks**: Tasks 14, 15 (unblocks API development once isolation is proven)
  - **Blocked By**: Tasks 7 (schema + RLS), 8 (middleware), 12 (test infra)

  **References**:

  **Pattern References**:
  - Task 7: `TenantDbConnectionInterceptor` — the interceptor being tested
  - Task 8: `TenantValidationMiddleware` — cross-tenant validation being tested
  - Task 12: `CustomWebApplicationFactory` + `IntegrationTestBase` — test infrastructure

  **External References**:
  - `Task.WhenAll()` for concurrent request testing
  - `Parallel.ForEachAsync()` for parallel HTTP requests
  - EF Core concurrency: `DbUpdateConcurrencyException` when RowVersion conflicts

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: All 6 RLS isolation tests pass
    Tool: Bash
    Preconditions: Testcontainers + test infrastructure from Task 12
    Steps:
      1. Run `dotnet test backend/tests/WorkClub.Tests.Integration --filter "RlsIsolation" --verbosity normal`
      2. Assert 6 tests pass (complete isolation, no context, insert protection, concurrent, spoof, interceptor)
    Expected Result: All 6 pass, 0 failures
    Failure Indicators: ANY failure means multi-tenancy is BROKEN — stop all downstream work
    Evidence: .sisyphus/evidence/task-13-rls-isolation.txt

  Scenario: Concurrent request test proves pool safety
    Tool: Bash
    Preconditions: Same as above
    Steps:
      1. Run concurrent test specifically: `dotnet test --filter "ConcurrentRequests" --verbosity detailed`
      2. Review output: 50 requests, each response verified for correct tenant
      3. Assert 0 cross-contamination events
    Expected Result: 50/50 requests return correct tenant data
    Failure Indicators: Any request returns wrong tenant's data
    Evidence: .sisyphus/evidence/task-13-concurrent-safety.txt
  ```

  **Commit**: YES
  - Message: `test(rls): add multi-tenant isolation integration tests`
  - Files: `backend/tests/WorkClub.Tests.Integration/MultiTenancy/*.cs`
  - Pre-commit: `dotnet test backend/tests/WorkClub.Tests.Integration --filter "RlsIsolation"`

- [x] 14. Task CRUD API Endpoints + 5-State Workflow

  **What to do**:
  - Create application services in `WorkClub.Application/Tasks/`:
    - `TaskService`: CRUD operations + state transitions
    - Uses `AppDbContext` directly (no generic repo)
    - Validates state transitions using domain entity's `CanTransitionTo()` method
    - Enforces role permissions: Create/Assign (Admin/Manager), Transition (assignee + Admin/Manager), Delete (Admin)
  - Create minimal API endpoints in `WorkClub.Api/Endpoints/Tasks/`:
    - `GET /api/tasks` — list tasks for current tenant (filtered by RLS). Supports `?status=Open&page=1&pageSize=20`
    - `GET /api/tasks/{id}` — single task detail
    - `POST /api/tasks` — create new task (status: Open). Requires Manager+ role.
    - `PATCH /api/tasks/{id}` — update task (title, description, assignee, status). Enforces state machine.
    - `DELETE /api/tasks/{id}` — soft-delete or hard-delete. Requires Admin role.
  - Handle concurrency: catch `DbUpdateConcurrencyException` → return 409
  - DTOs: `TaskListDto`, `TaskDetailDto`, `CreateTaskRequest`, `UpdateTaskRequest`
  - Write tests FIRST (TDD):
    - Test: CRUD operations work correctly
    - Test: Invalid state transition → 422
    - Test: Concurrency conflict → 409
    - Test: Role enforcement (Viewer can't create)

  **Must NOT do**:
  - Do NOT use MediatR or CQRS — direct service injection
  - Do NOT create generic CRUD base class
  - Do NOT add full-text search
  - Do NOT add sub-tasks or task dependencies

  **Recommended Agent Profile**:
  - **Category**: `deep`
    - Reason: Core business logic with state machine, concurrency handling, and role-based access
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 3 (with Tasks 13, 15, 16, 17)
  - **Blocks**: Tasks 19, 22, 23
  - **Blocked By**: Tasks 7 (schema), 8 (multi-tenancy), 9 (auth)

  **References**:

  **Pattern References**:
  - Task 4: `WorkItem` entity with `CanTransitionTo()` / `TransitionTo()` state machine
  - Task 7: `AppDbContext` with `UseXminAsConcurrencyToken()`
  - Task 8: `ITenantProvider.GetTenantId()` for current tenant
  - Task 9: Authorization policies (`RequireManager`, `RequireAdmin`)

  **External References**:
  - .NET 10 Minimal APIs: `app.MapGet("/api/tasks", handler).RequireAuthorization("RequireMember")`
  - `TypedResults.Ok()`, `TypedResults.NotFound()`, `TypedResults.UnprocessableEntity()`, `TypedResults.Conflict()`
  - Offset pagination: `Skip((page - 1) * pageSize).Take(pageSize)`
  - Concurrency: `catch (DbUpdateConcurrencyException) → TypedResults.Conflict()`

  **Acceptance Criteria**:

  **If TDD:**
  - [ ] Test files in `backend/tests/WorkClub.Tests.Integration/Tasks/`
  - [ ] `dotnet test --filter "Tasks"` → all pass

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Full task lifecycle via API
    Tool: Bash (curl)
    Preconditions: Docker Compose up, seed data loaded, token obtained
    Steps:
      1. POST /api/tasks with admin token + X-Tenant-Id: club-1 → assert 201, status "Open"
      2. PATCH /api/tasks/{id} with status "Assigned" + assigneeId → assert 200, status "Assigned"
      3. PATCH status "InProgress" → assert 200
      4. PATCH status "Review" → assert 200
      5. PATCH status "Done" → assert 200
      6. GET /api/tasks/{id} → assert status "Done"
    Expected Result: Task progresses through all 5 states
    Failure Indicators: Any transition rejected, wrong status
    Evidence: .sisyphus/evidence/task-14-task-lifecycle.txt

  Scenario: Invalid state transition rejected
    Tool: Bash (curl)
    Preconditions: Task in "Open" status
    Steps:
      1. PATCH /api/tasks/{id} with status "Done" (skipping states) → assert 422
      2. PATCH /api/tasks/{id} with status "InProgress" (skipping Assigned) → assert 422
    Expected Result: Invalid transitions return 422 Unprocessable Entity
    Failure Indicators: Returns 200 (state machine bypassed)
    Evidence: .sisyphus/evidence/task-14-invalid-transition.txt

  Scenario: Role enforcement on tasks
    Tool: Bash (curl)
    Preconditions: Viewer token obtained
    Steps:
      1. GET /api/tasks with viewer token → assert 200 (can read)
      2. POST /api/tasks with viewer token → assert 403 (cannot create)
    Expected Result: Viewer can read but not create tasks
    Failure Indicators: Viewer can create tasks (privilege escalation)
    Evidence: .sisyphus/evidence/task-14-role-enforcement.txt
  ```

  **Commit**: YES
  - Message: `feat(tasks): add Task CRUD API with 5-state workflow`
  - Files: `backend/src/WorkClub.Api/Endpoints/Tasks/*.cs`, `backend/src/WorkClub.Application/Tasks/*.cs`
  - Pre-commit: `dotnet test backend/tests/ --filter "Tasks"`

- [x] 15. Shift CRUD API + Sign-Up/Cancel Endpoints

  **What to do**:
  - Create application services in `WorkClub.Application/Shifts/`:
    - `ShiftService`: CRUD + sign-up/cancel logic
    - Sign-up: check capacity (count existing sign-ups < shift.Capacity), prevent duplicates, prevent sign-up for past shifts
    - Cancel: remove sign-up record, allow only before shift starts
    - Uses `AppDbContext` directly
    - Handles concurrency for last-slot race: use optimistic concurrency with retry (catch `DbUpdateConcurrencyException`, retry once)
  - Create minimal API endpoints in `WorkClub.Api/Endpoints/Shifts/`:
    - `GET /api/shifts` — list shifts for current tenant. Supports `?from=date&to=date&page=1&pageSize=20`
    - `GET /api/shifts/{id}` — shift detail including sign-up list
    - `POST /api/shifts` — create shift. Requires Manager+ role.
    - `PUT /api/shifts/{id}` — update shift details. Requires Manager+ role.
    - `DELETE /api/shifts/{id}` — delete shift. Requires Admin role.
    - `POST /api/shifts/{id}/signup` — member signs up for shift
    - `DELETE /api/shifts/{id}/signup` — member cancels their sign-up
  - DTOs: `ShiftListDto`, `ShiftDetailDto`, `CreateShiftRequest`, `UpdateShiftRequest`
  - Write tests FIRST (TDD):
    - Test: Sign-up succeeds when capacity available
    - Test: Sign-up rejected when capacity full → 409
    - Test: Sign-up rejected for past shift → 422
    - Test: Cancel succeeds before shift starts
    - Test: Duplicate sign-up rejected → 409

  **Must NOT do**:
  - Do NOT add recurring shift patterns
  - Do NOT add waitlists or swap requests
  - Do NOT add approval workflow for sign-ups (first-come-first-served)
  - Do NOT add overlapping shift detection

  **Recommended Agent Profile**:
  - **Category**: `deep`
    - Reason: Concurrency-sensitive capacity management with race condition handling
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 3 (with Tasks 13, 14, 16, 17)
  - **Blocks**: Tasks 20, 22
  - **Blocked By**: Tasks 7 (schema), 8 (multi-tenancy), 9 (auth)

  **References**:

  **Pattern References**:
  - Task 4: `Shift` and `ShiftSignup` entities
  - Task 7: `AppDbContext` with concurrency tokens
  - Task 9: Authorization policies

  **External References**:
  - Optimistic concurrency retry: `try { SaveChanges } catch (DbUpdateConcurrencyException) { retry once }`
  - Date filtering: `shifts.Where(s => s.StartTime >= from && s.StartTime <= to)`
  - `DateTimeOffset.UtcNow` for past-shift check

  **Acceptance Criteria**:

  **If TDD:**
  - [ ] Test files in `backend/tests/WorkClub.Tests.Integration/Shifts/`
  - [ ] `dotnet test --filter "Shifts"` → all pass

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Sign-up with capacity enforcement
    Tool: Bash (curl)
    Preconditions: Shift created with capacity=2, 0 sign-ups
    Steps:
      1. POST /api/shifts/{id}/signup with member1 token → assert 200
      2. POST /api/shifts/{id}/signup with member2 token → assert 200
      3. POST /api/shifts/{id}/signup with admin token → assert 409 (capacity full)
      4. GET /api/shifts/{id} → assert signupCount: 2, capacity: 2
    Expected Result: Third sign-up rejected, capacity enforced
    Failure Indicators: Third sign-up succeeds, wrong signup count
    Evidence: .sisyphus/evidence/task-15-capacity.txt

  Scenario: Past shift sign-up rejected
    Tool: Bash (curl)
    Preconditions: Shift with startTime in the past
    Steps:
      1. POST /api/shifts/{id}/signup → assert 422
    Expected Result: Cannot sign up for past shifts
    Failure Indicators: Sign-up succeeds for past shift
    Evidence: .sisyphus/evidence/task-15-past-shift.txt

  Scenario: Cancel sign-up before shift
    Tool: Bash (curl)
    Preconditions: Member signed up for future shift
    Steps:
      1. DELETE /api/shifts/{id}/signup with member token → assert 200
      2. GET /api/shifts/{id} → assert signupCount decreased by 1
    Expected Result: Sign-up removed, capacity freed
    Failure Indicators: Sign-up not removed
    Evidence: .sisyphus/evidence/task-15-cancel.txt
  ```

  **Commit**: YES
  - Message: `feat(shifts): add Shift CRUD API with sign-up and capacity`
  - Files: `backend/src/WorkClub.Api/Endpoints/Shifts/*.cs`, `backend/src/WorkClub.Application/Shifts/*.cs`
  - Pre-commit: `dotnet test backend/tests/ --filter "Shifts"`

---

- [x] 16. Club + Member API Endpoints

  **What to do**:
  - Create endpoints in `WorkClub.Api/Endpoints/Clubs/`:
    - `GET /api/clubs/me` — list clubs the current user belongs to (from JWT claims + DB)
    - `GET /api/clubs/current` — current club details (from X-Tenant-Id context)
    - `GET /api/members` — list members of current club. Requires Member+ role.
    - `GET /api/members/{id}` — member detail
    - `GET /api/members/me` — current user's membership in current club
  - Create `MemberSyncService`:
    - On first API request from a user, check if their Keycloak `sub` exists in Members table
    - If not, create Member record from JWT claims (name, email, role)
    - This keeps DB in sync with Keycloak without separate sync process
  - Write tests FIRST (TDD):
    - Test: `/api/clubs/me` returns only clubs user belongs to
    - Test: `/api/members` returns only members of current tenant
    - Test: Member auto-sync creates record on first request

  **Must NOT do**:
  - Do NOT add member management CRUD (invite, remove) — managed in Keycloak
  - Do NOT add club settings or logo upload
  - Do NOT add member search or filtering beyond basic list

  **Recommended Agent Profile**:
  - **Category**: `unspecified-high`
    - Reason: Member sync logic requires understanding Keycloak-DB relationship
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 3 (with Tasks 13, 14, 15, 17)
  - **Blocks**: Task 18
  - **Blocked By**: Tasks 7 (schema), 8 (multi-tenancy), 9 (auth)

  **References**:

  **Pattern References**:
  - Task 4: `Member` entity
  - Task 8: `ITenantProvider` for current tenant
  - Task 9: JWT claims parsing for user info

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Club list returns only user's clubs
    Tool: Bash (curl)
    Preconditions: Admin user (member of club-1 + club-2)
    Steps:
      1. GET /api/clubs/me with admin token → assert 200
      2. Assert response contains exactly 2 clubs
      3. GET /api/clubs/me with manager token → assert 1 club (club-1 only)
    Expected Result: Each user sees only their clubs
    Failure Indicators: Wrong club count, sees other users' clubs
    Evidence: .sisyphus/evidence/task-16-clubs-me.txt

  Scenario: Member auto-sync on first request
    Tool: Bash (curl + psql)
    Preconditions: New user authenticated but no Member record in DB
    Steps:
      1. GET /api/members/me with new user token → assert 200
      2. Query DB: SELECT * FROM members WHERE external_user_id = '{sub}' → assert 1 row
    Expected Result: Member record created automatically
    Failure Indicators: 404 or no DB record
    Evidence: .sisyphus/evidence/task-16-member-sync.txt
  ```

  **Commit**: YES
  - Message: `feat(clubs): add Club and Member API endpoints with auto-sync`
  - Files: `backend/src/WorkClub.Api/Endpoints/Clubs/*.cs`, `backend/src/WorkClub.Application/Members/*.cs`
  - Pre-commit: `dotnet test backend/tests/ --filter "Clubs|Members"`

- [x] 17. Frontend Test Infrastructure (Vitest + RTL + Playwright)

  **What to do**:
  - Install and configure Vitest: `bun add -D vitest @testing-library/react @testing-library/jest-dom @vitejs/plugin-react jsdom`
  - Create `frontend/vitest.config.ts` with React + jsdom environment
  - Install and configure Playwright: `bun add -D @playwright/test && bunx playwright install chromium`
  - Create `frontend/playwright.config.ts` with:
    - Base URL: `http://localhost:3000`
    - Chromium only (faster for development)
    - Screenshot on failure
  - Create test helpers:
    - `frontend/tests/helpers/render.tsx` — custom render with providers (session, tenant context)
    - `frontend/tests/helpers/mock-session.ts` — mock NextAuth session for component tests
  - Write 1 smoke test each:
    - Vitest: render a shadcn Button component, assert it renders
    - Playwright: navigate to homepage, assert page loads
  - Add scripts to `package.json`: `"test": "vitest run"`, `"test:watch": "vitest"`, `"test:e2e": "playwright test"`

  **Must NOT do**:
  - Do NOT install Jest (use Vitest)
  - Do NOT install Cypress (use Playwright)

  **Recommended Agent Profile**:
  - **Category**: `quick`
    - Reason: Standard test tool setup with config files
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 3 (with Tasks 13, 14, 15, 16)
  - **Blocks**: Tasks 18, 19, 20, 21
  - **Blocked By**: Task 5 (Next.js scaffold)

  **References**:

  **External References**:
  - Vitest + React: `@vitejs/plugin-react` plugin, `jsdom` environment
  - RTL custom render: wrap with providers for consistent test setup
  - Playwright config: `baseURL`, `use.screenshot: 'only-on-failure'`

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Vitest smoke test passes
    Tool: Bash
    Preconditions: Vitest configured in frontend/
    Steps:
      1. Run `bun run test` in frontend/
      2. Assert exit code 0, 1 test passed
    Expected Result: Vitest runs and passes smoke test
    Failure Indicators: Config errors, test failure
    Evidence: .sisyphus/evidence/task-17-vitest-smoke.txt

  Scenario: Playwright smoke test passes
    Tool: Bash
    Preconditions: Playwright + Chromium installed, dev server running
    Steps:
      1. Start dev server in background
      2. Run `bunx playwright test tests/e2e/smoke.spec.ts`
      3. Assert exit code 0
    Expected Result: Playwright navigates to app and page loads
    Failure Indicators: Browser launch failure, navigation timeout
    Evidence: .sisyphus/evidence/task-17-playwright-smoke.txt
  ```

  **Commit**: YES
  - Message: `test(frontend): add Vitest + RTL + Playwright setup`
  - Files: `frontend/vitest.config.ts`, `frontend/playwright.config.ts`, `frontend/tests/**`
  - Pre-commit: `bun run test` (in frontend/)

---

- [x] 18. App Layout + Club-Switcher + Auth Guard

  **What to do**:
  - Create root layout (`frontend/src/app/layout.tsx`):
    - SessionProvider wrapper (NextAuth)
    - TenantProvider wrapper (active club context)
    - Sidebar navigation: Dashboard, Tasks, Shifts, Members
    - Top bar: Club-switcher dropdown, user avatar/name, logout button
  - Create `ClubSwitcher` component (`frontend/src/components/club-switcher.tsx`):
    - Dropdown (shadcn DropdownMenu) showing user's clubs
    - On switch: update local storage + cookie, refetch all data (TanStack Query `queryClient.invalidateQueries()`)
    - Show current club name + sport type badge
  - Create `AuthGuard` component:
    - Wraps protected pages
    - If not authenticated → redirect to /login
    - If authenticated, no active club, 1 club → auto-select
    - If authenticated, no active club, multiple clubs → redirect to /select-club
    - If authenticated, 0 clubs → show "Contact admin" message
  - Install TanStack Query: `bun add @tanstack/react-query`
  - Create `QueryProvider` wrapper with `QueryClient`
  - Create `TenantContext` (React Context) with `activeClubId`, `setActiveClub()`, `userRole`
  - Write tests FIRST (TDD):
    - Test: ClubSwitcher renders clubs from session
    - Test: ClubSwitcher calls setActiveClub on selection
    - Test: AuthGuard redirects when no session

  **Must NOT do**:
  - Do NOT add settings pages
  - Do NOT add theme customization per club
  - Do NOT create custom component wrappers over shadcn/ui

  **Recommended Agent Profile**:
  - **Category**: `visual-engineering`
    - Reason: Layout design, responsive sidebar, dropdown component — frontend UI work
  - **Skills**: [`frontend-ui-ux`]
    - `frontend-ui-ux`: Crafts clean UI layout even without mockups

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 4 (with Tasks 19, 20, 21)
  - **Blocks**: Tasks 19, 20, 22
  - **Blocked By**: Tasks 10 (NextAuth), 16 (Club API), 17 (test infra)

  **References**:

  **Pattern References**:
  - Task 10: NextAuth session with clubs claim
  - Task 16: `GET /api/clubs/me` endpoint for club list

  **External References**:
  - shadcn/ui DropdownMenu: `<DropdownMenu><DropdownMenuTrigger>` pattern
  - TanStack Query: `useQuery({ queryKey: ['clubs'], queryFn: fetchClubs })`
  - React Context: `createContext<TenantContextType>()`
  - Next.js App Router layout: shared across all pages in directory

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Club switcher renders and switches
    Tool: Bash (bun test — Vitest + RTL)
    Preconditions: Mock session with 2 clubs
    Steps:
      1. Render ClubSwitcher with mock session containing clubs: [{name: "Tennis"}, {name: "Cycling"}]
      2. Assert both club names visible in dropdown
      3. Click "Cycling" → assert setActiveClub called with cycling club ID
    Expected Result: Switcher renders clubs and handles selection
    Failure Indicators: Clubs not rendered, click handler not called
    Evidence: .sisyphus/evidence/task-18-club-switcher.txt

  Scenario: Layout renders with navigation
    Tool: Playwright
    Preconditions: Frontend running with mock auth
    Steps:
      1. Navigate to /dashboard
      2. Assert sidebar contains links: "Tasks", "Shifts", "Members"
      3. Assert top bar shows club name and user name
      4. Take screenshot
    Expected Result: Full layout visible with navigation
    Failure Indicators: Missing sidebar, broken layout
    Evidence: .sisyphus/evidence/task-18-layout.png
  ```

  **Commit**: YES (groups with Tasks 19, 20, 21)
  - Message: `feat(ui): add layout, club-switcher, login, task and shift pages`
  - Files: `frontend/src/app/layout.tsx`, `frontend/src/components/club-switcher.tsx`, `frontend/src/components/auth-guard.tsx`
  - Pre-commit: `bun run build && bun run test` (in frontend/)

- [x] 19. Task List + Task Detail + Status Transitions UI

  **What to do**:
  - Create `/frontend/src/app/(protected)/tasks/page.tsx`:
    - Task list view using shadcn Table component
    - Columns: Title, Status (Badge with color per status), Assignee, Due Date, Actions
    - Filter by status (DropdownMenu with status options)
    - Pagination (offset-based)
    - "New Task" button (visible for Manager+ role)
  - Create `/frontend/src/app/(protected)/tasks/[id]/page.tsx`:
    - Task detail view
    - Status transition buttons (only valid next states shown)
    - Assign member dropdown (for Manager+ role)
    - Edit title/description (for Manager+ or assignee)
  - Create `/frontend/src/app/(protected)/tasks/new/page.tsx`:
    - New task form: title, description, due date (optional)
    - Form validation with shadcn form components
  - Use TanStack Query hooks:
    - `useTasks(filters)`, `useTask(id)`, `useCreateTask()`, `useUpdateTask()`, `useTransitionTask()`
  - Write tests FIRST (TDD):
    - Test: Task list renders with mock data
    - Test: Status badge shows correct color per status
    - Test: Only valid transition buttons are shown

  **Must NOT do**:
  - Do NOT add drag-and-drop Kanban board
  - Do NOT add inline editing
  - Do NOT add bulk actions

  **Recommended Agent Profile**:
  - **Category**: `visual-engineering`
    - Reason: Data table, form design, interactive status transitions
  - **Skills**: [`frontend-ui-ux`]

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 4 (with Tasks 18, 20, 21)
  - **Blocks**: Task 27
  - **Blocked By**: Tasks 14 (Task API), 17 (test infra), 18 (layout)

  **References**:

  **Pattern References**:
  - Task 14: Task API endpoints (GET /api/tasks, PATCH /api/tasks/{id})
  - Task 18: Layout with TenantContext for API headers
  - Task 4: WorkItemStatus enum values and valid transitions

  **External References**:
  - shadcn Table: `<Table><TableHeader><TableBody>` with mapped rows
  - shadcn Badge: `<Badge variant="outline">Open</Badge>` with color variants
  - TanStack Query mutations: `useMutation({ mutationFn: updateTask, onSuccess: invalidate })`

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Task list renders with data
    Tool: Bash (bun test)
    Preconditions: Mock API response with 5 tasks
    Steps:
      1. Render TaskListPage with mocked TanStack Query
      2. Assert 5 table rows rendered
      3. Assert each row has title, status badge, assignee
    Expected Result: All tasks displayed in table
    Failure Indicators: Missing rows, wrong data
    Evidence: .sisyphus/evidence/task-19-task-list.txt

  Scenario: Status transition buttons shown correctly
    Tool: Bash (bun test)
    Preconditions: Task with status "InProgress"
    Steps:
      1. Render TaskDetailPage with task in "InProgress" status
      2. Assert "Move to Review" button is visible
      3. Assert "Mark as Done" button is NOT visible (invalid transition)
    Expected Result: Only valid transitions shown
    Failure Indicators: Invalid transitions displayed
    Evidence: .sisyphus/evidence/task-19-transitions.txt
  ```

  **Commit**: YES (groups with Tasks 18, 20, 21)
  - Message: (grouped in Task 18 commit)
  - Files: `frontend/src/app/(protected)/tasks/**/*.tsx`, `frontend/src/hooks/useTasks.ts`
  - Pre-commit: `bun run build && bun run test`

- [x] 20. Shift List + Shift Detail + Sign-Up UI

  **What to do**:
  - Create `/frontend/src/app/(protected)/shifts/page.tsx`:
    - Shift list view using shadcn Card components (not table — more visual for schedules)
    - Each card: Title, Date/Time, Location, Capacity bar (X/Y signed up), Sign-up button
    - Filter by date range (DatePicker)
    - "New Shift" button (visible for Manager+ role)
  - Create `/frontend/src/app/(protected)/shifts/[id]/page.tsx`:
    - Shift detail: full info + list of signed-up members
    - "Sign Up" button (if capacity available and shift is future)
    - "Cancel Sign-up" button (if user is signed up)
    - Visual capacity indicator (progress bar)
  - Create `/frontend/src/app/(protected)/shifts/new/page.tsx`:
    - New shift form: title, description, location, start time, end time, capacity
  - TanStack Query hooks: `useShifts(dateRange)`, `useShift(id)`, `useSignUp()`, `useCancelSignUp()`
  - Write tests FIRST (TDD):
    - Test: Shift card shows capacity correctly (2/3)
    - Test: Sign-up button disabled when full
    - Test: Past shift shows "Past" label, no sign-up button

  **Must NOT do**:
  - Do NOT add calendar view (list/card view only for MVP)
  - Do NOT add recurring shift creation
  - Do NOT add shift swap functionality

  **Recommended Agent Profile**:
  - **Category**: `visual-engineering`
    - Reason: Card-based UI, capacity visualization, date/time components
  - **Skills**: [`frontend-ui-ux`]

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 4 (with Tasks 18, 19, 21)
  - **Blocks**: Task 28
  - **Blocked By**: Tasks 15 (Shift API), 17 (test infra), 18 (layout)

  **References**:

  **Pattern References**:
  - Task 15: Shift API endpoints
  - Task 18: Layout with TenantContext
  - Task 4: Shift entity fields

  **External References**:
  - shadcn Card: `<Card><CardHeader><CardContent>` for shift cards
  - Progress component: shadcn Progress for capacity bar
  - Date picker: shadcn Calendar + Popover for date range filter

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Shift card shows capacity and sign-up state
    Tool: Bash (bun test)
    Preconditions: Mock shift with capacity 3, 2 signed up
    Steps:
      1. Render ShiftCard with mock data
      2. Assert "2/3 spots filled" text visible
      3. Assert "Sign Up" button is enabled (1 spot left)
      4. Re-render with capacity 3, 3 signed up
      5. Assert "Sign Up" button is disabled
    Expected Result: Capacity displayed correctly, button state matches availability
    Failure Indicators: Wrong count, button enabled when full
    Evidence: .sisyphus/evidence/task-20-capacity-display.txt

  Scenario: Past shift cannot be signed up for
    Tool: Bash (bun test)
    Preconditions: Shift with startTime in the past
    Steps:
      1. Render ShiftCard with past shift
      2. Assert "Past" label visible
      3. Assert "Sign Up" button not rendered
    Expected Result: Past shifts clearly marked, no sign-up option
    Failure Indicators: Sign-up button on past shift
    Evidence: .sisyphus/evidence/task-20-past-shift.txt
  ```

  **Commit**: YES (groups with Tasks 18, 19, 21)
  - Message: (grouped in Task 18 commit)
  - Files: `frontend/src/app/(protected)/shifts/**/*.tsx`, `frontend/src/hooks/useShifts.ts`
  - Pre-commit: `bun run build && bun run test`

- [x] 21. Login Page + First-Login Club Picker

  **What to do**:
  - Create `/frontend/src/app/login/page.tsx`:
    - Clean login page with "Sign in with Keycloak" button
    - Uses NextAuth `signIn("keycloak")` function
    - Shows app name/logo placeholder
  - Create `/frontend/src/app/select-club/page.tsx`:
    - Club selection page for multi-club users
    - Shows cards for each club with name and sport type
    - Clicking a club → sets active club → redirects to /dashboard
    - Only shown when user has 2+ clubs and no active club
  - Create `/frontend/src/app/(protected)/dashboard/page.tsx`:
    - Simple dashboard showing:
      - Active club name
      - My open tasks count
      - My upcoming shifts count
      - Quick links to Tasks and Shifts pages
  - Write tests FIRST (TDD):
    - Test: Login page renders sign-in button
    - Test: Club picker shows correct number of clubs
    - Test: Dashboard shows summary counts

  **Must NOT do**:
  - Do NOT add custom login form (use Keycloak hosted login)
  - Do NOT add registration page
  - Do NOT add charts or analytics on dashboard

  **Recommended Agent Profile**:
  - **Category**: `visual-engineering`
    - Reason: Login page design, club selection cards, dashboard layout
  - **Skills**: [`frontend-ui-ux`]

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 4 (with Tasks 18, 19, 20)
  - **Blocks**: Task 26
  - **Blocked By**: Tasks 10 (NextAuth), 17 (test infra)

  **References**:

  **Pattern References**:
  - Task 10: `signIn("keycloak")` and session with clubs claim
  - Task 18: AuthGuard redirects to /select-club or /login

  **External References**:
  - NextAuth signIn: `import { signIn } from "next-auth/react"` → `signIn("keycloak")`
  - shadcn Card: for club selection cards

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Login page renders
    Tool: Bash (bun test)
    Steps:
      1. Render LoginPage
      2. Assert "Sign in" button visible
    Expected Result: Login page renders with sign-in button
    Failure Indicators: Missing button, render error
    Evidence: .sisyphus/evidence/task-21-login-page.txt

  Scenario: Club picker for multi-club user
    Tool: Bash (bun test)
    Preconditions: Mock session with 2 clubs, no active club
    Steps:
      1. Render SelectClubPage with mock session
      2. Assert 2 club cards rendered
      3. Click first card → assert redirect to /dashboard
    Expected Result: Club picker shows clubs and handles selection
    Failure Indicators: Wrong club count, no redirect
    Evidence: .sisyphus/evidence/task-21-club-picker.txt
  ```

  **Commit**: YES (groups with Tasks 18, 19, 20)
  - Message: (grouped in Task 18 commit)
  - Files: `frontend/src/app/login/page.tsx`, `frontend/src/app/select-club/page.tsx`, `frontend/src/app/(protected)/dashboard/page.tsx`
  - Pre-commit: `bun run build && bun run test`

---

- [x] 22. Docker Compose Full Stack (Backend + Frontend + Hot Reload)

  **What to do**:
  - Update `/docker-compose.yml` to add:
    - `dotnet-api` service: build from `backend/Dockerfile.dev`, port 5000→8080, volume mount `/backend:/app` (hot reload via `dotnet watch`), depends on postgres + keycloak
    - `nextjs` service: build from `frontend/Dockerfile.dev`, port 3000, volume mount `/frontend:/app` (hot reload via `bun run dev`), depends on dotnet-api
  - Configure environment variables:
    - Backend: `ConnectionStrings__DefaultConnection`, `Keycloak__Issuer`, `ASPNETCORE_ENVIRONMENT=Development`
    - Frontend: `NEXT_PUBLIC_API_URL=http://localhost:5000`, `API_INTERNAL_URL=http://dotnet-api:8080`, `KEYCLOAK_ISSUER`
  - Ensure service startup order: postgres → keycloak → dotnet-api → nextjs
  - Add `wait-for-it` or health-check-based depends_on conditions
  - Backend runs migrations + seed on startup in Development mode
  - Verify: `docker compose up` → all 4 services healthy → frontend accessible at localhost:3000 → can authenticate via Keycloak

  **Must NOT do**:
  - Do NOT use production Dockerfiles for local dev (use Dockerfile.dev with hot reload)
  - Do NOT hardcode production secrets

  **Recommended Agent Profile**:
  - **Category**: `unspecified-high`
    - Reason: Multi-service Docker Compose orchestration with health checks and dependency ordering
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 5 (with Tasks 23, 24, 25)
  - **Blocks**: Tasks 26, 27, 28
  - **Blocked By**: Tasks 14 (API), 15 (Shifts API), 18 (Frontend layout)

  **References**:

  **Pattern References**:
  - Task 2: Docker Compose base (postgres + keycloak)
  - Task 11: Seed data service (runs on Development startup)

  **External References**:
  - `dotnet watch run`: Hot reload in Docker with volume mount
  - Docker Compose `depends_on` with `condition: service_healthy`
  - Volume mount caching: `:cached` on macOS for performance

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Full stack starts from clean state
    Tool: Bash
    Preconditions: Docker installed, no conflicting ports
    Steps:
      1. Run `docker compose down -v` (clean slate)
      2. Run `docker compose up -d`
      3. Wait up to 180s for all services healthy: `docker compose ps`
      4. Assert 4 services running: postgres, keycloak, dotnet-api, nextjs
      5. curl http://localhost:5000/health/live → assert 200
      6. curl http://localhost:3000 → assert 200
      7. curl Keycloak OIDC discovery → assert 200
    Expected Result: All 4 services healthy and responding
    Failure Indicators: Service fails to start, health check fails
    Evidence: .sisyphus/evidence/task-22-full-stack.txt

  Scenario: Authentication works end-to-end
    Tool: Bash (curl)
    Preconditions: Full stack running
    Steps:
      1. Get token from Keycloak for admin@test.com
      2. Call GET /api/tasks with token + X-Tenant-Id → assert 200
      3. Assert response contains seed data tasks
    Expected Result: Auth + API + data all connected
    Failure Indicators: Auth fails, API returns 401/403, no data
    Evidence: .sisyphus/evidence/task-22-e2e-auth.txt
  ```

  **Commit**: YES (groups with Tasks 23, 24, 25)
  - Message: `infra(deploy): add full Docker Compose stack, Dockerfiles, and Kustomize dev overlay`
  - Files: `docker-compose.yml`
  - Pre-commit: `docker compose config`

- [x] 23. Backend Dockerfiles (Dev + Prod Multi-Stage)

  **What to do**:
  - Create `/backend/Dockerfile.dev`:
    - Base: `mcr.microsoft.com/dotnet/sdk:10.0`
    - Install dotnet-ef tool
    - WORKDIR /app, copy csproj + restore, copy source
    - ENTRYPOINT: `dotnet watch run --project src/WorkClub.Api/WorkClub.Api.csproj`
  - Create `/backend/Dockerfile`:
    - Multi-stage build:
      - Stage 1 (build): `sdk:10.0`, restore + build + publish
      - Stage 2 (runtime): `aspnet:10.0-alpine`, copy published output, non-root user
    - HEALTHCHECK: `curl -sf http://localhost:8080/health/live || exit 1`
    - Final image ~110MB

  **Must NOT do**:
  - Do NOT use full SDK image for production
  - Do NOT run as root in production image

  **Recommended Agent Profile**:
  - **Category**: `quick`
    - Reason: Standard .NET Docker patterns
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 5 (with Tasks 22, 24, 25)
  - **Blocks**: Task 25
  - **Blocked By**: Task 14 (working API to build)

  **References**:

  **External References**:
  - .NET 10 Docker images: `mcr.microsoft.com/dotnet/aspnet:10.0-alpine` (runtime), `sdk:10.0` (build)
  - Multi-stage: restore in separate layer for caching
  - Non-root: `USER app` (built into .NET Docker images)

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Production image builds and runs
    Tool: Bash
    Steps:
      1. Run `docker build -t workclub-api:test backend/`
      2. Assert build succeeds
      3. Run `docker run --rm -d -p 18080:8080 --name test-api workclub-api:test`
      4. Wait 10s, curl http://localhost:18080/health/live
      5. Assert response (may fail without DB — that's OK, just verify container starts)
      6. Check image size: `docker image inspect workclub-api:test --format='{{.Size}}'`
      7. Assert < 200MB
      8. Cleanup: `docker stop test-api`
    Expected Result: Image builds, starts, is <200MB
    Failure Indicators: Build fails, image too large
    Evidence: .sisyphus/evidence/task-23-backend-docker.txt
  ```

  **Commit**: YES (groups with Tasks 22, 24, 25)
  - Message: (grouped in Task 22 commit)
  - Files: `backend/Dockerfile`, `backend/Dockerfile.dev`
  - Pre-commit: `docker build -t test backend/`

- [x] 24. Frontend Dockerfiles (Dev + Prod Standalone)

  **What to do**:
  - Create `/frontend/Dockerfile.dev`:
    - Base: `node:22-alpine`
    - Install bun: `npm install -g bun`
    - Copy package.json + bun.lock, install deps
    - CMD: `bun run dev`
  - Create `/frontend/Dockerfile`:
    - Multi-stage build (3 stages):
      - Stage 1 (deps): `node:22-alpine`, install bun, `bun install --frozen-lockfile`
      - Stage 2 (build): copy deps + source, `bun run build`
      - Stage 3 (runner): `node:22-alpine`, copy `.next/standalone` + `.next/static` + `public`, non-root user
    - CMD: `node server.js`
    - HEALTHCHECK: `curl -sf http://localhost:3000/api/health || exit 1`
    - Final image ~180MB

  **Must NOT do**:
  - Do NOT use Bun as production runtime (latency issues) — use Node.js
  - Do NOT include dev dependencies in production image

  **Recommended Agent Profile**:
  - **Category**: `quick`
    - Reason: Standard Next.js Docker patterns
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 5 (with Tasks 22, 23, 25)
  - **Blocks**: Task 25
  - **Blocked By**: Task 18 (working frontend)

  **References**:

  **External References**:
  - Next.js standalone Docker: copy `.next/standalone`, `.next/static`, `public`
  - `node server.js` as entry point (standalone output)
  - Non-root user: `adduser --system --uid 1001 nextjs`

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Production image builds and starts
    Tool: Bash
    Steps:
      1. Run `docker build -t workclub-frontend:test frontend/`
      2. Assert build succeeds
      3. Run `docker run --rm -d -p 13000:3000 --name test-frontend workclub-frontend:test`
      4. Wait 10s, curl http://localhost:13000
      5. Assert HTTP 200
      6. Check image size < 250MB
      7. Cleanup: `docker stop test-frontend`
    Expected Result: Frontend image builds, starts, serves pages
    Failure Indicators: Build fails, no response
    Evidence: .sisyphus/evidence/task-24-frontend-docker.txt
  ```

  **Commit**: YES (groups with Tasks 22, 23, 25)
  - Message: (grouped in Task 22 commit)
  - Files: `frontend/Dockerfile`, `frontend/Dockerfile.dev`
  - Pre-commit: `docker build -t test frontend/`

- [x] 25. Kustomize Dev Overlay + Resource Limits + Health Checks

  **What to do**:
  - Create `/infra/k8s/overlays/dev/kustomization.yaml`:
    - Reference `../../base`
    - Override replicas: 1 for all deployments
    - Override resource limits: lower CPU/memory for dev
    - Add dev-specific ConfigMap values (Development env, debug logging)
    - Add dev-specific image tags
  - Create `/infra/k8s/overlays/dev/patches/`:
    - `backend-resources.yaml`: Lower resource requests/limits for dev
    - `frontend-resources.yaml`: Lower resources
  - Update base manifests if needed:
    - Ensure health check endpoints match actual implementations
    - Backend: `/health/startup`, `/health/live`, `/health/ready` (from Task 9)
    - Frontend: `/api/health` (from Task 5 or Task 18)
  - Verify: `kustomize build infra/k8s/overlays/dev` produces valid YAML with dev overrides

  **Must NOT do**:
  - Do NOT add HPA or PDB (not needed for dev)
  - Do NOT add production secrets

  **Recommended Agent Profile**:
  - **Category**: `unspecified-high`
    - Reason: Kustomize overlay configuration with patches
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 5 (with Tasks 22, 23, 24)
  - **Blocks**: None
  - **Blocked By**: Tasks 6 (base manifests), 23 (backend Dockerfile), 24 (frontend Dockerfile)

  **References**:

  **Pattern References**:
  - Task 6: Kustomize base manifests
  - Task 9: Health check endpoints

  **External References**:
  - Kustomize overlays: `resources: [../../base]` + `patches:` list
  - `replicas:` directive for scaling

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Dev overlay builds with correct overrides
    Tool: Bash
    Steps:
      1. Run `kustomize build infra/k8s/overlays/dev`
      2. Assert exit code 0
      3. Verify replicas are 1 for all deployments
      4. Verify resource limits are lower than base
    Expected Result: Valid YAML with dev-specific overrides
    Failure Indicators: Build fails, wrong values
    Evidence: .sisyphus/evidence/task-25-kustomize-dev.txt
  ```

  **Commit**: YES (groups with Tasks 22, 23, 24)
  - Message: (grouped in Task 22 commit)
  - Files: `infra/k8s/overlays/dev/**/*.yaml`
  - Pre-commit: `kustomize build infra/k8s/overlays/dev`

---

- [x] 26. Playwright E2E Tests — Auth Flow + Club Switching

  **What to do**:
  - Create `frontend/tests/e2e/auth.spec.ts`:
    - Test: Navigate to protected page → redirected to login
    - Test: Click "Sign in" → redirected to Keycloak login → enter credentials → redirected back with session
    - Test: After login, club picker shown (if multi-club user)
    - Test: Select club → redirected to dashboard → club name visible in header
    - Test: Switch club via dropdown → data refreshes → new club name visible
    - Test: Logout → redirected to login page → protected page no longer accessible
  - Configure Playwright to work with Docker Compose stack:
    - `webServer` config points to Docker Compose `nextjs` service
    - Use `globalSetup` to ensure Docker Compose is running
  - Save screenshots and trace on failure

  **Must NOT do**:
  - Do NOT test Keycloak admin console
  - Do NOT test direct API calls (covered in backend tests)

  **Recommended Agent Profile**:
  - **Category**: `unspecified-high`
    - Reason: E2E browser automation with Keycloak OIDC redirect flow
  - **Skills**: [`playwright`]
    - `playwright`: Browser automation for E2E testing

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 6 (with Tasks 27, 28)
  - **Blocks**: None
  - **Blocked By**: Tasks 21 (login page), 22 (Docker Compose full stack)

  **References**:

  **Pattern References**:
  - Task 21: Login page with Keycloak sign-in
  - Task 18: Club-switcher component
  - Task 3: Test user credentials (admin@test.com / testpass123)

  **External References**:
  - Playwright Keycloak login: `page.goto('/dashboard')` → assert redirect to Keycloak → `page.fill('#username')` → `page.fill('#password')` → `page.click('#kc-login')`
  - Playwright screenshot: `await page.screenshot({ path: 'evidence/...' })`

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Full auth flow E2E
    Tool: Playwright
    Preconditions: Docker Compose full stack running
    Steps:
      1. Navigate to http://localhost:3000/dashboard
      2. Assert redirected to /login page
      3. Click "Sign in" button
      4. Assert redirected to Keycloak login (http://localhost:8080/realms/workclub/...)
      5. Fill username: "admin@test.com", password: "testpass123"
      6. Click Login
      7. Assert redirected back to /select-club (multi-club user)
      8. Click first club card ("Sunrise Tennis Club")
      9. Assert URL is /dashboard
      10. Assert text "Sunrise Tennis Club" visible in header
      11. Screenshot
    Expected Result: Complete login + club selection flow works
    Failure Indicators: Redirect loop, Keycloak errors, stuck on club picker
    Evidence: .sisyphus/evidence/task-26-auth-flow.png

  Scenario: Club switching refreshes data
    Tool: Playwright
    Preconditions: Logged in, club-1 active
    Steps:
      1. Navigate to /tasks → assert tasks visible (club-1 data)
      2. Open club switcher dropdown
      3. Click "Valley Cycling Club"
      4. Assert tasks list updates (different data)
      5. Assert header shows "Valley Cycling Club"
    Expected Result: Switching clubs changes visible data
    Failure Indicators: Data doesn't refresh, old club's data shown
    Evidence: .sisyphus/evidence/task-26-club-switch.png
  ```

  **Commit**: YES (groups with Tasks 27, 28)
  - Message: `test(e2e): add Playwright E2E tests for auth, tasks, and shifts`
  - Files: `frontend/tests/e2e/auth.spec.ts`
  - Pre-commit: `bunx playwright test tests/e2e/auth.spec.ts`

- [x] 27. Playwright E2E Tests — Task Management Flow

  **What to do**:
  - Create `frontend/tests/e2e/tasks.spec.ts`:
    - Test: Create new task → appears in list
    - Test: View task detail → all fields displayed
    - Test: Transition task through all states (Open → Assigned → InProgress → Review → Done)
    - Test: Viewer role cannot see "New Task" button
    - Test: Task list filters by status
  - Use authenticated session from Task 26 setup

  **Must NOT do**:
  - Do NOT test API directly (use UI interactions only)

  **Recommended Agent Profile**:
  - **Category**: `unspecified-high`
    - Reason: Complex E2E flow with multiple pages and state transitions
  - **Skills**: [`playwright`]

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 6 (with Tasks 26, 28)
  - **Blocks**: None
  - **Blocked By**: Tasks 19 (task UI), 22 (Docker Compose)

  **References**:

  **Pattern References**:
  - Task 19: Task list page, task detail page, task creation form
  - Task 14: Task API behavior (valid/invalid transitions)

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Full task lifecycle via UI
    Tool: Playwright
    Preconditions: Logged in as admin, club-1 active
    Steps:
      1. Navigate to /tasks
      2. Click "New Task" button
      3. Fill title: "Replace court net", description: "Net on court 3 is torn"
      4. Click Submit → assert redirected to task detail
      5. Assert status badge shows "Open"
      6. Click "Assign" → select member → assert status "Assigned"
      7. Click "Start" → assert status "In Progress"
      8. Click "Submit for Review" → assert status "Review"
      9. Click "Approve" → assert status "Done"
      10. Screenshot final state
    Expected Result: Task flows through all 5 states via UI
    Failure Indicators: Transition fails, wrong status shown
    Evidence: .sisyphus/evidence/task-27-task-lifecycle.png

  Scenario: Viewer cannot create tasks
    Tool: Playwright
    Preconditions: Logged in as viewer@test.com
    Steps:
      1. Navigate to /tasks
      2. Assert "New Task" button is NOT visible
    Expected Result: Viewer sees task list but no create button
    Failure Indicators: Create button visible for viewer
    Evidence: .sisyphus/evidence/task-27-viewer-no-create.png
  ```

  **Commit**: YES (groups with Tasks 26, 28)
  - Message: (grouped in Task 26 commit)
  - Files: `frontend/tests/e2e/tasks.spec.ts`
  - Pre-commit: `bunx playwright test tests/e2e/tasks.spec.ts`

- [x] 28. Playwright E2E Tests — Shift Sign-Up Flow

  **What to do**:
  - Create `frontend/tests/e2e/shifts.spec.ts`:
    - Test: Create new shift → appears in list
    - Test: View shift detail → capacity bar shows 0/N
    - Test: Sign up for shift → capacity updates, user listed
    - Test: Cancel sign-up → capacity decreases
    - Test: Full capacity → sign-up button disabled
    - Test: Past shift → no sign-up button
  - Use authenticated session from Task 26 setup

  **Must NOT do**:
  - Do NOT test concurrent sign-ups via UI (covered in backend integration tests)

  **Recommended Agent Profile**:
  - **Category**: `unspecified-high`
    - Reason: E2E flow with capacity state tracking
  - **Skills**: [`playwright`]

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 6 (with Tasks 26, 27)
  - **Blocks**: None
  - **Blocked By**: Tasks 20 (shift UI), 22 (Docker Compose)

  **References**:

  **Pattern References**:
  - Task 20: Shift list page, shift detail page, sign-up button
  - Task 15: Shift API behavior (capacity, past shift rejection)

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: Sign up and cancel for shift
    Tool: Playwright
    Preconditions: Logged in as member1, future shift with capacity 3, 0 signed up
    Steps:
      1. Navigate to /shifts
      2. Click on future shift card
      3. Assert "0/3 spots filled"
      4. Click "Sign Up" → assert "1/3 spots filled"
      5. Assert user name appears in sign-up list
      6. Click "Cancel Sign-up" → assert "0/3 spots filled"
      7. Screenshot
    Expected Result: Sign-up and cancel update capacity correctly
    Failure Indicators: Count doesn't update, name not shown
    Evidence: .sisyphus/evidence/task-28-shift-signup.png

  Scenario: Full capacity disables sign-up
    Tool: Playwright
    Preconditions: Shift with capacity 1, 1 already signed up
    Steps:
      1. Navigate to shift detail for full shift
      2. Assert "1/1 spots filled"
      3. Assert "Sign Up" button is disabled or not present
    Expected Result: Cannot sign up for full shift
    Failure Indicators: Sign-up button still active
    Evidence: .sisyphus/evidence/task-28-full-capacity.png
  ```

  **Commit**: YES (groups with Tasks 26, 27)
  - Message: (grouped in Task 26 commit)
  - Files: `frontend/tests/e2e/shifts.spec.ts`
  - Pre-commit: `bunx playwright test tests/e2e/shifts.spec.ts`

- [ ] 29. Gitea CI Pipeline — Backend + Frontend + Infra Validation

  **What to do**:
  - Create `.gitea/workflows/ci.yml` for repository `code.hal9000.damnserver.com/MasterMito/work-club-manager`
  - Configure triggers:
    - `push` on `main` and feature branches
    - `pull_request` targeting `main`
    - `workflow_dispatch` for manual reruns
  - Structure pipeline into parallel jobs (fail-fast disabled so all diagnostics are visible):
    - `backend-ci`: setup .NET 10 SDK, restore, build, run backend unit/integration tests
    - `frontend-ci`: setup Bun, install deps, run lint, type-check, unit tests, production build
    - `infra-ci`: validate Docker Compose and Kustomize manifests
  - Add path filters so docs-only changes skip heavy jobs when possible
  - Add dependency caching:
    - NuGet cache keyed by `**/*.csproj` + lock/context
    - Bun cache keyed by `bun.lockb`
  - Add artifact upload on failure:
    - `backend-test-results` (trx/log output)
    - `frontend-test-results` (vitest output)
    - `infra-validation-output`
  - Enforce branch protection expectation in plan notes:
    - Required checks: `backend-ci`, `frontend-ci`, `infra-ci`
  - Keep CD out-of-scope in this append (no image push, no deploy steps)

  **Must NOT do**:
  - Do NOT add deployment jobs (Kubernetes apply/helm/kustomize deploy)
  - Do NOT add secrets for registry push in this CI-only iteration
  - Do NOT couple CI workflow to release-tag deployment behavior

  **Recommended Agent Profile**:
  - **Category**: `unspecified-high`
    - Reason: CI pipeline design spans backend/frontend/infra validation and requires careful runner orchestration
  - **Skills**: []

  **Parallelization**:
  - **Can Run In Parallel**: YES
  - **Parallel Group**: Wave 6 (with Tasks 26, 27, 28)
  - **Blocks**: Final Verification Wave (F1-F4)
  - **Blocked By**: Tasks 12, 17, 23, 24, 25

  **References**:

  **Pattern References**:
  - `docker-compose.yml` — Source of truth for `docker compose config` validation
  - `infra/k8s/base/kustomization.yaml` and `infra/k8s/overlays/dev/kustomization.yaml` — Kustomize build inputs used by infra-ci job
  - `backend/WorkClub.sln` — Backend restore/build/test entrypoint for .NET job
  - `frontend/package.json` + `frontend/bun.lockb` — Frontend scripts and cache key anchor

  **External References**:
  - Gitea Actions docs: workflow syntax and trigger model (`.gitea/workflows/*.yml`)
  - `actions/setup-dotnet` usage for .NET 10 SDK installation
  - `oven-sh/setup-bun` usage for Bun runtime setup
  - Upload artifact action compatible with Gitea Actions runner implementation

  **Acceptance Criteria**:

  **QA Scenarios (MANDATORY):**

  ```
  Scenario: CI workflow validates backend/frontend/infra in parallel
    Tool: Bash (Gitea API)
    Preconditions: `.gitea/workflows/ci.yml` pushed to repository, `GITEA_TOKEN` available
    Steps:
      1. Trigger workflow via API or push a CI-test branch commit
      2. Query latest workflow run status for `ci.yml`
      3. Assert jobs `backend-ci`, `frontend-ci`, and `infra-ci` all executed
      4. Assert final workflow conclusion is `success`
    Expected Result: All three CI jobs pass in one run
    Failure Indicators: Missing job, skipped required job, or non-success conclusion
    Evidence: .sisyphus/evidence/task-29-gitea-ci-success.json

  Scenario: Pipeline fails on intentional backend break
    Tool: Bash (git + Gitea API)
    Preconditions: Temporary branch available, ability to push test commit
    Steps:
      1. Create a temporary branch with an intentional backend compile break
      2. Push branch and wait for CI run
      3. Assert `backend-ci` fails
      4. Assert workflow conclusion is `failure`
      5. Revert test commit / delete branch
    Expected Result: CI correctly rejects broken code and reports failure
    Failure Indicators: Broken backend still reports success
    Evidence: .sisyphus/evidence/task-29-gitea-ci-failure.json
  ```

  **Commit**: YES
  - Message: `ci(gitea): add parallel CI workflow for backend, frontend, and infra validation`
  - Files: `.gitea/workflows/ci.yml`
  - Pre-commit: `docker compose config && kustomize build infra/k8s/overlays/dev > /dev/null`

---

## Final Verification Wave

> 4 review agents run in PARALLEL. ALL must APPROVE. Rejection → fix → re-run.

- [x] F1. **Plan Compliance Audit** — `oracle`
  Read the plan end-to-end. For each "Must Have": verify implementation exists (read file, curl endpoint, run command). For each "Must NOT Have": search codebase for forbidden patterns (`MediatR`, `IRepository<T>`, `Swashbuckle`, `IsMultiTenant()`, `SET app.current_tenant` without `LOCAL`) — reject with file:line if found. Validate CI appendix by checking `.gitea/workflows/ci.yml` exists and includes `backend-ci`, `frontend-ci`, `infra-ci` jobs with push + pull_request triggers. Check evidence files exist in `.sisyphus/evidence/`. Compare deliverables against plan.
  Output: `Must Have [N/N] | Must NOT Have [N/N] | Tasks [N/N] | VERDICT: APPROVE/REJECT`

- [x] F2. **Code Quality Review** — `unspecified-high`
  Run `dotnet build` + `dotnet format --verify-no-changes` + `dotnet test` + `bun run build` + `bun run lint`. Validate CI config integrity by running YAML lint/syntax check on `.gitea/workflows/ci.yml` and verifying all referenced commands exist in repo scripts/paths. Review all changed files for: `as any`/`@ts-ignore`, empty catches, `console.log` in prod, commented-out code, unused imports, `// TODO` without ticket. Check AI slop: excessive comments, over-abstraction, generic names (data/result/item/temp), unnecessary null checks on non-nullable types.
  Output: `Build [PASS/FAIL] | Format [PASS/FAIL] | Tests [N pass/N fail] | Lint [PASS/FAIL] | Files [N clean/N issues] | VERDICT`

- [x] F3. **Real Manual QA** — `unspecified-high` (+ `playwright` skill)
  Start `docker compose up` from clean state. Execute EVERY QA scenario from EVERY task — follow exact steps, capture evidence. Test cross-task integration: login → pick club → create task → assign → transition through states → switch club → verify isolation → create shift → sign up → verify capacity. Test edge cases: invalid JWT, expired token, cross-tenant header spoof, concurrent sign-up. Save to `.sisyphus/evidence/final-qa/`.
  Output: `Scenarios [N/N pass] | Integration [N/N] | Edge Cases [N tested] | VERDICT`

- [x] F4. **Scope Fidelity Check** — `deep`
  For each task: read "What to do", read actual diff (`git log`/`git diff`). Verify 1:1 — everything in spec was built (no missing), nothing beyond spec was built (no creep). Check "Must NOT do" compliance across ALL tasks. Detect cross-task contamination: Task N touching Task M's files. Flag unaccounted changes. Verify no CQRS, no MediatR, no generic repo, no Swashbuckle, no social login, no recurring shifts, no notifications.
  Output: `Tasks [N/N compliant] | Contamination [CLEAN/N issues] | Unaccounted [CLEAN/N files] | VERDICT`

---

## Commit Strategy

| Wave | Commit | Message | Files | Pre-commit |
|------|--------|---------|-------|------------|
| 1 | T1 | `chore(scaffold): initialize git repo and monorepo with .NET solution` | backend/**/*.csproj, backend/WorkClub.sln, .gitignore, .editorconfig | `dotnet build` |
| 1 | T2 | `infra(docker): add Docker Compose with PostgreSQL and Keycloak` | docker-compose.yml, backend/Dockerfile.dev | `docker compose config` |
| 1 | T3 | `infra(keycloak): configure realm with test users and club memberships` | infra/keycloak/realm-export.json | — |
| 1 | T4 | `feat(domain): add core entities — Club, Member, Task, Shift` | backend/src/WorkClub.Domain/**/*.cs | `dotnet build` |
| 1 | T5 | `chore(frontend): initialize Next.js project with Tailwind and shadcn/ui` | frontend/**, package.json, next.config.ts, tailwind.config.ts | `bun run build` |
| 1 | T6 | `infra(k8s): add Kustomize base manifests` | infra/k8s/base/**/*.yaml | `kustomize build infra/k8s/base` |
| 2 | T7+T8 | `feat(data): add EF Core DbContext, migrations, RLS policies, and multi-tenant middleware` | backend/src/WorkClub.Infrastructure/**/*.cs, backend/src/WorkClub.Api/Middleware/*.cs | `dotnet build` |
| 2 | T9 | `feat(auth): add Keycloak JWT authentication and role-based authorization` | backend/src/WorkClub.Api/Auth/*.cs, Program.cs | `dotnet build` |
| 2 | T10 | `feat(frontend-auth): add NextAuth.js Keycloak integration` | frontend/src/auth/**, frontend/src/middleware.ts | `bun run build` |
| 2 | T11 | `feat(seed): add development seed data script` | backend/src/WorkClub.Infrastructure/Seed/*.cs | `dotnet build` |
| 2 | T12 | `test(infra): add xUnit + Testcontainers + WebApplicationFactory base` | backend/tests/**/*.cs | `dotnet test` |
| 3 | T13 | `test(rls): add multi-tenant isolation integration tests` | backend/tests/WorkClub.Tests.Integration/MultiTenancy/*.cs | `dotnet test` |
| 3 | T14 | `feat(tasks): add Task CRUD API with 5-state workflow` | backend/src/WorkClub.Api/Endpoints/Tasks/*.cs, backend/src/WorkClub.Application/Tasks/*.cs | `dotnet test` |
| 3 | T15 | `feat(shifts): add Shift CRUD API with sign-up and capacity` | backend/src/WorkClub.Api/Endpoints/Shifts/*.cs, backend/src/WorkClub.Application/Shifts/*.cs | `dotnet test` |
| 3 | T16 | `feat(clubs): add Club and Member API endpoints` | backend/src/WorkClub.Api/Endpoints/Clubs/*.cs | `dotnet test` |
| 3 | T17 | `test(frontend): add Vitest + RTL + Playwright setup` | frontend/vitest.config.ts, frontend/playwright.config.ts | `bun run test` |
| 4 | T18-T21 | `feat(ui): add layout, club-switcher, login, task and shift pages` | frontend/src/app/**/*.tsx, frontend/src/components/**/*.tsx | `bun run build && bun run test` |
| 5 | T22-T25 | `infra(deploy): add full Docker Compose stack, Dockerfiles, and Kustomize dev overlay` | docker-compose.yml, **/Dockerfile*, infra/k8s/overlays/dev/**/*.yaml | `docker compose config && kustomize build infra/k8s/overlays/dev` |
| 6 | T26-T28 | `test(e2e): add Playwright E2E tests for auth, tasks, and shifts` | frontend/tests/e2e/**/*.spec.ts | `bunx playwright test` |
| 6 | T29 | `ci(gitea): add parallel CI workflow for backend, frontend, and infra validation` | .gitea/workflows/ci.yml | `docker compose config && kustomize build infra/k8s/overlays/dev > /dev/null` |

---

## Success Criteria

### Verification Commands
```bash
# All services start and are healthy
docker compose up -d && docker compose ps  # Expected: 4 services running

# Backend health
curl -sf http://localhost:5000/health/live  # Expected: 200, "Healthy"

# Keycloak OIDC discovery
curl -sf http://localhost:8080/realms/workclub/.well-known/openid-configuration  # Expected: 200, JSON with "issuer"

# Get auth token
TOKEN=$(curl -sf -X POST http://localhost:8080/realms/workclub/protocol/openid-connect/token \
  -d "client_id=workclub-app&username=admin@test.com&password=testpass123&grant_type=password" | jq -r '.access_token')

# Tenant isolation
curl -sf -H "Authorization: Bearer $TOKEN" -H "X-Tenant-Id: club-1-uuid" http://localhost:5000/api/tasks  # Expected: 200, only club-1 tasks
curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Bearer $TOKEN" -H "X-Tenant-Id: nonexistent-club" http://localhost:5000/api/tasks  # Expected: 403

# Backend tests
dotnet test backend/tests/ --no-build  # Expected: All pass

# Frontend build + tests
bun run build  # Expected: Exit 0
bun run test   # Expected: All pass

# K8s manifests valid
kustomize build infra/k8s/overlays/dev > /dev/null  # Expected: Exit 0

# CI workflow file present and includes required jobs
grep -E "backend-ci|frontend-ci|infra-ci" .gitea/workflows/ci.yml  # Expected: all 3 job names present
```

### Final Checklist
- [x] All "Must Have" items present and verified
- [x] All "Must NOT Have" items absent (no MediatR, no generic repo, no Swashbuckle, etc.)
- [x] All backend tests pass (`dotnet test`)
- [x] All frontend tests pass (`bun run test`)
- [x] All E2E tests pass (`bunx playwright test`)
- [x] Docker Compose stack starts clean and healthy
- [x] Kustomize manifests build without errors
- [ ] Gitea CI workflow exists and references backend-ci/frontend-ci/infra-ci
- [x] RLS isolation proven at database level
- [x] Cross-tenant access returns 403
- [x] Task state machine rejects invalid transitions (422)
- [x] Shift sign-up respects capacity (409 when full)