CapaKraken/plan.md

# CapaKraken — Umsetzungsplan

Gitea-Repo: `https://gitea.hartmut-noerenberg.com/Hartmut/plANARCHY`
Stand: 2026-04-01 | Issues: #19–#27

---

## Plan: Ticket #27 — Dashboard Widget Bug (new users see empty modal)

### Anforderungsanalyse

Neue Nutzer können keine Widgets zum Dashboard hinzufügen. Root cause: `localStorage`-Key
`"capakraken_dashboard_v1"` ist **nicht user-scoped**. Wenn User A sich ausloggt und User B
auf demselben Gerät anmeldet, liest `useDashboardLayout` das Layout von User A aus
`localStorage`. Hat User A ein leeres Dashboard gespeichert, sieht User B 0 Widgets —
und nach Klick auf "Add Widget" im Modal erscheint der neue Widget **nicht** (da der
Hydrationszustand nicht sauber initialisiert wird).

**Fix:** localStorage-Key auf `capakraken_dashboard_v1_{userId}` umstellen. Vor dem Zugriff
auf `localStorage` wartet der Hook auf `trpc.user.me`, um die User-ID zu kennen.

### Betroffene Pakete & Dateien

| Paket | Datei | Art |
|-------|-------|-----|
| `apps/web` | `src/hooks/useDashboardLayout.ts` | edit — user-scoped storage key |
| `apps/web` | `e2e/dev-system/dashboard-widgets.spec.ts` | create — E2E tests |

### Task-Liste

- [x] **T-1:** `useDashboardLayout` auf user-scoped localStorage umstellen → `useDashboardLayout.ts`
- [x] **T-2:** E2E-Test für den kompletten Widget-Flow (new user, add, persist, reload) → `dashboard-widgets.spec.ts`
- [ ] **T-3:** `pnpm --filter @capakraken/web exec tsc --noEmit` — keine neuen TS-Fehler
- [ ] **T-4:** E2E-Tests gegen laufenden Dev-Server ausführen (manuell oder CI)
- [ ] **T-5:** Commit + Ticket #27 auf Gitea kommentieren + `in-review` setzen

### Akzeptanzkriterien

- [ ] Neuer Admin-User sieht nach Login das Default-Dashboard (stat-cards)
- [ ] Modal zeigt alle 11 Widgets an
- [ ] Gewählter Widget erscheint sofort auf dem Dashboard
- [ ] Nach Page-Reload ist der Widget weiterhin sichtbar
- [ ] Cross-User-Bleed: User B erbt nicht das Layout von User A

---

## Plan: In-Review-Tickets verifizieren und in main integrieren

### Anforderungsanalyse

8 Tickets sind `in-review`. Ziel: jeden Ticket-Scope im Code verifizieren, Gitea-Kommentar
mit Bewertung (✅ akzeptiert / ⚠️ Nachbesserung nötig) hinterlassen, dann alle offenen
Changes in einem sauberen Commit auf `main` integrieren.

**Umfang der Verifikation pro Ticket:**
- Code-Artefakte im Repo prüfen (Dateien, Tests)
- Quality-Gates (tsc, test:unit) müssen grün sein
- Akzeptanzkriterien aus dem Ticket-Body abgleichen
- Gitea-Kommentar: Strukturiertes Urteil mit Befunden

**Integration-Strategie:**
- Alle ungestagten Änderungen (`git status`) gehören zu den Tickets #20, #22, #25, #26
- Ein einziger Commit auf `main` mit klarer Commit-Message
- plan.md und docs/ mitcommiten

### Betroffene Pakete & Dateien

| Paket | Dateien | Art der Änderung |
|-------|---------|-----------------|
| `apps/web` | `next.config.ts`, `src/app/layout.tsx`, `src/middleware.ts`, `src/middleware.test.ts`, `src/app/api/perf/route.ts`, `src/app/api/perf/route.test.ts`, `src/components/security/MfaSetup.test.ts`, `e2e/dev-system/rbac-data-access.spec.ts`, `e2e/dev-system/helpers.ts` | Verifikation + commit |
| `packages/api` | `src/__tests__/ssrf-guard.test.ts`, `src/__tests__/webhook-procedure-support.test.ts` | Verifikation + commit |
| root | `package.json`, `docker-compose.yml`, `docs/developer-runbook.md`, `plan.md` | Verifikation + commit |

### Task-Liste (atomare Schritte in Reihenfolge)

**Phase 1 — Verifikation & Kommentierung (sequenziell, ein Ticket nach dem anderen)**

- [ ] **V-1:** Ticket #19 (MFA-QR) — Code-Check: `MfaSetup.tsx` + `MfaSetup.test.ts`; Urteil auf Gitea posten
- [ ] **V-2:** Ticket #20 (Webhook SSRF) — Code-Check: `ssrf-guard.ts` + `ssrf-guard.test.ts` + `webhook-procedure-support.test.ts`; Urteil posten
- [ ] **V-3:** Ticket #21 (/api/perf) — Code-Check: `route.ts` + `route.test.ts`; Urteil posten
- [ ] **V-4:** Ticket #22 (CSP) — Code-Check: `middleware.ts` + `middleware.test.ts` + `next.config.ts` + `layout.tsx`; Urteil posten
- [ ] **V-5:** Ticket #23 (Active-Session-Registry) — Code-Check: Session-Guard-Middleware, Auth-Flow; Urteil posten
- [ ] **V-6:** Ticket #24 (Docker reproducibility) — Code-Check: `docker-compose.yml`, Dockerfile.dev; Urteil posten
- [ ] **V-7:** Ticket #25 (Env/Migration-Strategie) — Code-Check: `docker-compose.yml`, `docs/developer-runbook.md`; Urteil posten
- [ ] **V-8:** Ticket #26 (RBAC E2E-Tests) — Code-Check: `rbac-data-access.spec.ts`; Urteil posten

**Phase 2 — Quality Gates**

- [ ] **Q-1:** `pnpm --filter @capakraken/web exec tsc --noEmit` — keine Fehler
- [ ] **Q-2:** `pnpm --filter @capakraken/api test:unit` — alle Tests grün
- [ ] **Q-3:** `pnpm --filter @capakraken/web test:unit` — alle Tests grün

**Phase 3 — Git-Integration**

- [ ] **G-1:** `git add` aller ungestagten Änderungen (alle Ticket-Artefakte)
- [ ] **G-2:** Commit mit Message: `security/platform: close audit findings #19–#26 (tests, CSP nonce, SSRF guard, runbook)`
- [ ] **G-3:** `git push origin main`

### Abhängigkeiten

- V-1 bis V-8 sind unabhängig voneinander, aber sequenziell (ein Kommentar pro Ticket)
- Q-1 bis Q-3 können nach allen V-Tasks parallel laufen
- G-1/G-2/G-3 müssen nach Q-1..3 erfolgen (kein Commit bei roten Tests)

### Akzeptanzkriterien

- [ ] Alle 8 in-review-Tickets haben einen Bewertungskommentar
- [ ] `pnpm test:unit` läuft grün (beide Pakete)
- [ ] `tsc --noEmit` ohne Fehler
- [ ] Alle neuen Dateien in einem sauberen Commit auf `main`
- [ ] `git status` danach: working tree clean

### Risiken & offene Fragen

- **Ticket #23 (Active-Session):** Die Implementierung in früheren Sessions könnte durch spätere Auth-Fixes (jti→sid) überholt worden sein — genau prüfen
- **Ticket #24 vs. #25:** Überlappen in `docker-compose.yml` — beide Tickets betreffen dieselbe Datei; ein Commit deckt beide ab
- **Push auf main:** Direkt auf `main` — kein PR da kein Remote-Review-Prozess konfiguriert. Sicherstellen dass alle Tests grün sind

---

---

## Ticket #25 — Docker/Env/Migration-Strategie

### Anforderungsanalyse

Ziel: Docker-Container-Lifecycle ohne manuelle Eingriffe.

Konkrete Mängel:
1. `REDIS_URL` in `docker-compose.yml` nutzt `${REDIS_URL:-redis://redis:6379}` — Host-Env-Var kann Docker-internen Wert überschreiben (gleiche Klasse wie das behobene `DATABASE_URL`-Problem)
2. Migration-Strategy undokumentiert: DB per `db push` aufgebaut, dann Migration hinzugefügt → `migrate deploy` scheitert mit P3005, erforderte `migrate resolve --applied`
3. Kein Developer-Runbook (Setup, Restart, DB-Ops fehlen)

### Betroffene Dateien

| Datei | Änderung |
|---|---|
| `docker-compose.yml` | `REDIS_URL` hardcoden |
| `docs/developer-runbook.md` | create |

### Task-Liste

- [ ] **#25-T1:** `docker-compose.yml` — `REDIS_URL: redis://redis:6379` (Literal, kein `${}`)
- [ ] **#25-T2:** `docs/developer-runbook.md` erstellen mit: Erstmaligem Setup, DB-Migration-Strategie inkl. P3005-Recovery, E2E_TEST_MODE-Erklärung, Container-Neustart-Checkliste

---

## Ticket #26 — RBAC Datenzugriffs-Matrix E2E-Tests

### Anforderungsanalyse

Neue Testdatei `apps/web/e2e/dev-system/rbac-data-access.spec.ts` mit **Netzwerk-Ebene** tRPC-Response-Assertions (nicht nur UI-Sichtbarkeit).

Grundlage `docs/route-access-matrix.md`:

| tRPC-Prozedur | Audience | Admin | Manager | Viewer |
|---|---|---|---|---|
| `user.list` | `admin-only` | ✓ 200 | FORBIDDEN | FORBIDDEN |
| `allocation.listView` | `planning-read` | ✓ 200 | ✓ 200 | FORBIDDEN |
| `resource.listSummaries` | `resource-overview` | ✓ 200 | ✓ 200 | FORBIDDEN |
| `user.listAssignable` | `manager-write` | ✓ 200 | ✓ 200 | FORBIDDEN |

Technik: `page.evaluate()` mit `fetch()` gegen `/api/trpc/<proc>?batch=1&input=...` — läuft im Browser-Kontext der gespeicherten Session.

tRPC GET-Format:
```
GET /api/trpc/<proc>?batch=1&input={"0":{"json":null}}
Erfolg: [{"result":{"data":{"json":[...]}}}]
Fehler: [{"error":{"json":{"data":{"code":"FORBIDDEN","httpStatus":403}}}}]
```

### Betroffene Dateien

| Datei | Änderung |
|---|---|
| `apps/web/e2e/dev-system/rbac-data-access.spec.ts` | create |

### Task-Liste

- [ ] **#26-T1:** Datei erstellen mit `trpcQuery(page, procedure, input?)` Helper-Funktion
- [ ] **#26-T2:** Admin-Describe-Block (4 Tests: alle 4 Prozeduren → Erfolg erwartet)
- [ ] **#26-T3:** Manager-Describe-Block (4 Tests: `user.list` → FORBIDDEN, Rest → Erfolg)
- [ ] **#26-T4:** Viewer-Describe-Block (4 Tests: alle → FORBIDDEN)
- [ ] **#26-T5:** Smoke-Run: `pnpm exec playwright test e2e/dev-system/rbac-data-access.spec.ts --config=playwright.dev.config.ts`

### Risiken

- `allocation.listView` könnte ein Pflicht-Input-Objekt erfordern → Falls `BAD_REQUEST` statt FORBIDDEN, Schema im Router prüfen und minimalen Input übergeben
- Viewer-Permissions aus DB-Seed (SystemRoleConfig) — prüfen ob VIEWER tatsächlich kein `VIEW_PLANNING` hat

---

---

## Anforderungsanalyse

Alle 6 Issues stammen aus einem Security-Audit und einem Plattform-Review.  
5 davon sind Security-Findings (OWASP A02/A05/A07/A09), 1 ist ein Plattform-Thema (Docker-Reproduzierbarkeit).  
Die Security-Issues sind weitgehend unabhängig voneinander; lediglich #23 greift in den tRPC-Request-Pfad ein und sollte zuletzt umgesetzt werden, da es den Haupt-Auth-Pfad berührt.

---

## Betroffene Pakete & Dateien

| Issue | Paket/Pfad | Datei | Art |
|-------|-----------|-------|-----|
| #21 | `apps/web` | `src/app/api/perf/route.ts` | edit |
| #19 | `apps/web` | `src/components/security/MfaSetup.tsx` | edit |
| #19 | `apps/web` | `package.json` | edit (neue Dep: `qrcode` + `@types/qrcode`) |
| #20 | `packages/api` | `src/lib/webhook-dispatcher.ts` | edit |
| #20 | `packages/api` | `src/router/webhook-support.ts` | edit |
| #20 | `packages/api` | `src/lib/ssrf-guard.ts` | create |
| #22 | `apps/web` | `next.config.ts` | edit |
| #23 | `apps/web` | `src/app/api/trpc/[trpc]/route.ts` | edit |
| #23 | `apps/web` | `src/server/auth.ts` | edit (Doku/Cleanup) |
| #24 | root | `Dockerfile.dev`, `Dockerfile.prod`, `docker-compose.yml`, `docker-compose.prod.yml`, `tooling/docker/app-dev-start.sh` | edit |

---

## Task-Liste (in empfohlener Reihenfolge)

### Issue #21 — /api/perf fail-closed + Query-Token entfernen

- [ ] **Task 1:** `GET`-Handler in `apps/web/src/app/api/perf/route.ts` ändern:
  - `if (cronSecret)` → `if (!cronSecret) return 401/403` (fail-closed)
  - `queryToken`-Zweig vollständig entfernen
  - Nur noch `Authorization: Bearer <secret>` prüfen
  - → Datei: `apps/web/src/app/api/perf/route.ts`

- [ ] **Task 2:** Unit-Tests für `/api/perf`:
  - Test: autorisiert per Header → 200
  - Test: kein Secret → 401
  - Test: Query-Param-Token → 401 (nicht mehr akzeptiert)
  - Test: fehlende `CRON_SECRET`-Env → fail-closed (kein Metrics-Leak)
  - → Datei: `apps/web/src/app/api/perf/route.test.ts` (neu)

---

### Issue #19 — MFA QR lokal rendern

- [ ] **Task 3:** `qrcode`-Paket und `@types/qrcode` zu `apps/web/package.json` hinzufügen, `pnpm install` ausführen.

- [ ] **Task 4:** `MfaSetup.tsx` umschreiben:
  - `<img src="https://api.qrserver.com/...">` durch lokale QR-Generierung ersetzen
  - `qrcode.toDataURL(uri)` im Client-Effekt aufrufen und als `<img src={dataUrl}>` rendern
  - Sicherstellen: der `otpauth://`-URI verlässt den Browser nicht mehr
  - → Datei: `apps/web/src/components/security/MfaSetup.tsx`

- [ ] **Task 5:** Test sicherstellen, dass kein Rendering-Request an externe QR-URL geht:
  - Unit-Test oder Playwright-Test der prüft, dass kein `<img src>` mit `qrserver.com` oder `chart.googleapis.com` gerendert wird
  - → Datei: `apps/web/src/components/security/MfaSetup.test.tsx` (neu oder bestehend ergänzen)

---

### Issue #20 — Webhook SSRF-Schutz

- [ ] **Task 6:** `ssrf-guard.ts` erstellen mit einer `assertWebhookUrlAllowed(url: string): void`-Funktion:
  - Parst die URL, löst Hostname auf (DNS-Check via Node `dns.lookup`)
  - Blockt: Loopback (`127.0.0.0/8`, `::1`), RFC1918 (`10.x`, `172.16–31.x`, `192.168.x`), Link-Local (`169.254.x`), Cloud-Metadata (`169.254.169.254`)
  - Blockt: alle Schemes außer `https` (und `http` nur wenn expliziter Dev-Override gesetzt)
  - Wirft `TRPCError({ code: "BAD_REQUEST" })` mit allgemeiner Fehlermeldung (ohne IP preiszugeben)
  - → Datei: `packages/api/src/lib/ssrf-guard.ts`

- [ ] **Task 7:** `ssrf-guard` in `webhook-support.ts` und `webhook-dispatcher.ts` integrieren:
  - Vor Speicherung + vor Dispatch `assertWebhookUrlAllowed(url)` aufrufen
  - → Dateien: `packages/api/src/router/webhook-support.ts`, `packages/api/src/lib/webhook-dispatcher.ts`

- [ ] **Task 8:** Unit-Tests für `ssrf-guard.ts`:
  - Erlaubt: `https://example.com/hook`
  - Blockt: `http://localhost/…`, `http://127.0.0.1/…`, `http://10.0.0.1/…`, `http://192.168.1.1/…`, `http://169.254.169.254/…`, `ftp://…`
  - → Datei: `packages/api/src/__tests__/ssrf-guard.test.ts` (neu)

---

### Issue #22 — CSP härten

- [ ] **Task 9:** CSP in `apps/web/next.config.ts` überarbeiten:
  - `unsafe-eval` entfernen oder nur für `NODE_ENV === "development"` erlauben
  - `unsafe-inline` aus `script-src` entfernen
  - Nonce-basierte Inline-Scripts prüfen: Next.js 15 unterstützt CSP-Nonces via `nonce`-Prop auf `<Script>` — recherchieren ob tatsächliche Inline-Scripts existieren, die Nonces brauchen
  - Unnötige `connect-src`-Origins bereinigen
  - → Datei: `apps/web/next.config.ts`

- [ ] **Task 10:** Smoke-Test: App unter gehärteter CSP starten, Browser-DevTools auf CSP-Violations prüfen (mindestens Login → Dashboard → Timeline → Allocations).  
  Gefundene Violations entweder beheben (Move to external file / Nonce) oder als Known Exception dokumentieren.

---

### Issue #23 — Active-Session-Registry bei jedem Request prüfen

- [ ] **Task 11:** Im tRPC-Route-Handler (`apps/web/src/app/api/trpc/[trpc]/route.ts`) nach dem `auth()`-Call die `jti` aus dem Session-Token lesen und gegen `prisma.activeSession` validieren:
  ```ts
  const jti = session?.user?.jti as string | undefined;
  if (jti) {
    const active = await prisma.activeSession.findUnique({ where: { jti } });
    if (!active) {
      return NextResponse.json({ error: "Session revoked" }, { status: 401 });
    }
  }
  ```
  - Gilt für alle authentisierten tRPC-Requests
  - Gilt auch für nicht-tRPC Auth-Pfade wenn vorhanden (Route-Handler prüfen)
  - → Datei: `apps/web/src/app/api/trpc/[trpc]/route.ts`

- [ ] **Task 12:** Unit-/Integrations-Tests:
  - gültige aktive Session → Request durch
  - ausgeloggte (gelöschte) Session → 401
  - durch Concurrent-Session-Limit verdrängte Session → 401
  - → Datei: `apps/web/src/app/api/trpc/[trpc]/route.test.ts` (neu oder ergänzen)

---

### Issue #24 — Docker-Setup host-unabhängig

- [ ] **Task 13:** `Dockerfile.dev` prüfen und absichern:
  - `pnpm install` muss im Container ablaufen (kein Volume-Mount der Host-`node_modules`)
  - `prisma generate` muss Teil des Starts sein (nicht als Host-Voraussetzung)
  - Fehlende Systempakete (z. B. OpenSSL für Prisma) explizit installieren
  - → Datei: `Dockerfile.dev`

- [ ] **Task 14:** `Dockerfile.prod` prüfen:
  - Multi-Stage-Build: Build-Stage hat pnpm + alle Dev-Deps; Runtime-Stage nur Prod-Artefakte
  - Generierte Prisma-Artefakte (`node_modules/.prisma`) korrekt aus Build-Stage kopiert
  - → Datei: `Dockerfile.prod`

- [ ] **Task 15:** `docker-compose.yml` absichern:
  - `node_modules`-Volume-Override korrekt gesetzt damit Host-Modules nicht reinmappen
  - `app-dev-start.sh` ausführbar und alle Schritte (generate, migrate, start) enthalten
  - → Dateien: `docker-compose.yml`, `tooling/docker/app-dev-start.sh`

- [ ] **Task 16:** Frischer-Checkout-Smoke-Test dokumentieren:
  ```bash
  git clone … && cd capakraken
  docker compose up --build
  # → App erreichbar, Login funktioniert, keine Host-Abhängigkeiten
  ```
  → Schritt in `docs/` oder `README.md` festhalten

---

## Abhängigkeiten

```
Task 1 → Task 2          (Tests setzen fertige Impl voraus)
Task 3 → Task 4 → Task 5 (Dep-Install → Impl → Test)
Task 6 → Task 7 → Task 8 (Guard-Lib → Integration → Tests)
Task 9 → Task 10         (CSP-Änderung → Smoke-Test)
Task 11 → Task 12        (Session-Impl → Tests)
Task 13–16 unabhängig von allen anderen (Docker-only)

Parallel möglich (nach Task-Gruppe):
- #21 (Tasks 1–2) || #19 (Tasks 3–5) || #24 (Tasks 13–16)
- #20 (Tasks 6–8) || #22 (Tasks 9–10) — erst nachdem #21/#19 fertig sind (separater Branch)
- #23 (Tasks 11–12) — zuletzt, da Auth-Pfad berührt
```

---

## Akzeptanzkriterien

- [ ] `pnpm test:unit` läuft grün
- [ ] `pnpm --filter @capakraken/web exec tsc --noEmit` — keine neuen Errors
- [ ] `pnpm lint` — sauber
- [ ] **#21:** `/api/perf` ohne `CRON_SECRET` gibt 401/403, Query-Token wird nicht mehr akzeptiert
- [ ] **#19:** `MfaSetup` macht keinen Request an `qrserver.com` oder `chart.googleapis.com`
- [ ] **#20:** Webhook-Save und Dispatch für `http://127.0.0.1/…` gibt `BAD_REQUEST`
- [ ] **#22:** Browser-DevTools zeigt keine CSP-Violations für Haupt-User-Flows in Production-Mode
- [ ] **#23:** Request mit gelöschter `ActiveSession`-`jti` gibt 401
- [ ] **#24:** `docker compose up --build` auf sauberem Checkout bootet die App ohne Host-Abhängigkeiten

---

## Risiken & offene Fragen

| Risiko | Einschätzung | Maßnahme |
|--------|-------------|----------|
| CSP-Nonces in Next.js 15: `<Script>` und Tailwind CSS benötigen ggf. Nonces | Mittel | Vor Task 9 in Next.js-15-Doku recherchieren; ggf. nur `unsafe-eval` entfernen als erster Schritt |
| Session-Registry-Check (#23) erhöht DB-Load: jeder tRPC-Request = 1 DB-Read | Mittel | Redis-Cache mit kurzer TTL (30s) als Opt-in; erst messen ob nötig |
| SSRF-Guard DNS-Lookup: async, könnte Race-Condition durch DNS-Rebinding haben | Niedrig | Nach DNS-Lookup Socket-Verbindung ebenfalls gegen IP prüfen (defense-in-depth) |
| Docker #24: `node_modules`-Volume-Semantik bei pnpm-Workspaces komplex | Mittel | Symlink-Struktur von pnpm in Container testen; ggf. `--shamefully-hoist` Flag |
| `jti` im Session-Token: Auth.js-Version muss `jti` ins JWT schreiben | Offen | In `auth.ts` prüfen ob `token.jti` tatsächlich im JWT-Callback persistiert wird |