# Onboarding-Prompt für einen neuen Claude-Code-Agenten

> Diesen Prompt dem neuen Agenten als erste Nachricht geben. Er enthält bewusst **keinen**
> inhaltlichen Projektstand — der steht in `docs/STAND-dev-branch.md` und wird nur dort
> gepflegt (kein doppelter, veraltender Stand im Prompt).

---

```text
Du übernimmst die Weiterentwicklung des ISMS-Tools (Multi-Tenant-SaaS für
ISO 27001:2022 / TISAX / VDA-ISA 2027). Mach dich zuerst mit dem Stand vertraut.
Beginne noch KEINE Aufgabe — lies ein, bestätige dein Verständnis und warte dann
auf meine Anweisung.

## Repo & Umgebung
- Arbeitsverzeichnis: das lokale Repo `ISMS-Tool` (kein Gitea-/Remote-Zugang!).
- Du kannst NICHT pushen. Arbeite auf Branch `dev`, committe lokal. Pushen mache ich selbst.
  Prüfe mit `git branch --show-current`, dass du auf `dev` bist (NICHT `main`).
- Stack: Next.js 16 (App Router, Turbopack, Server Actions), React 19, TypeScript strict,
  Prisma 7 (+ @prisma/adapter-pg), PostgreSQL + pgvector, NextAuth v5, Tailwind.

## Zuerst lesen (in dieser Reihenfolge) — das ist die maßgebliche Statusquelle
1. `docs/STAND-dev-branch.md` — konsolidierter Gesamtstand (PM + Technik): was fertig/offen
   ist, wo was liegt, Datenmodelle, Migrationen, Fallstricke, Demo-Logins.
2. `docs/HANDOVER-DEV.md` — Setup, Stack, Konventionen, Migrations-Flow (§1–§10).
3. `docs/SPEC.md` — fachliche Spezifikation.
Verlasse dich auf diese Dokumente statt zu raten. Den inhaltlichen Projektstand NICHT aus
diesem Prompt ableiten — er steht ausschließlich in der Doku (Single Source of Truth).

## Arbeitskonventionen (verbindlich)
- Commits auf Deutsch, granular pro Thema, mit Trailer:
  `Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>`
- Neue mutierende Server-Action → über `moduleGuard("<key>")` und in
  `scripts/check-module-guards.ts` eintragen (sonst failt der Build).
- Neue mandantengebundene Prisma-Modelle → in `TENANT_MODELS` (`src/server/db.ts`)
  UND RLS-Policy in der Migration (`tenant_isolation` via `current_setting('app.tenant_id')`).
- Migrations-Flow Prisma 7:
  `npx prisma migrate diff --from-config-datasource prisma.config.ts --to-schema prisma/schema.prisma --script`
  → RLS-DO-Block manuell anhängen → `npx prisma migrate deploy` → `npx prisma generate`.
  (tsx-Skripte brauchen `import "dotenv/config"`.)
- Zentrale Richtlinien-Variablen (Organisation/Rollen/Schutzbedarf) sind nur in `/settings`
  pflegbar und serverseitig geschützt — nicht im Richtlinien-Editor.
- Editier-UIs immer als Popup/Modal (Muster: Assets/Lieferanten/Software/Projekte).
- Doku mitpflegen: Nach jeder abgeschlossenen Arbeit `docs/STAND-dev-branch.md`
  aktualisieren (Executive Summary, PM-Statustabelle, ggf. neue Modelle/Migrationen,
  „Wo liegt was", Commit-Übersicht, offene Punkte). Das ist die Single Source of Truth —
  sie muss den `dev`-Stand jederzeit korrekt widerspiegeln. Der Doku-Update gehört in einen
  eigenen Commit (oder denselben Themen-Commit), nicht separat vergessen.

## Jede Iteration abschließen mit
`npx tsc --noEmit` → `npm run lint` → `npm run build` (führt `prebuild`-Guard-Check aus).
Bei Änderungen am Vorlagenpaket zusätzlich `python3 seed/isms-vorlagenpaket-v2/_verify.py`
(muss `OK` liefern). Wo im Browser sichtbar: Dev-Server (`npm run dev`, Port 3000) und selbst
verifizieren — nicht den Nutzer manuell prüfen lassen. Hinweis: geänderte Server-Actions
greifen im Turbopack-Dev teils erst nach Neustart des Dev-Servers. Voraussetzung: lokale
Postgres-DB läuft und `.env` mit `DATABASE_URL` ist vorhanden (siehe HANDOVER-DEV.md).

## Lokale Demo-Daten
Seed: `npx tsx prisma/seed.ts` (idempotent). Demo-Logins Passwort `Demo1234!`:
`admin@demo.example` (Mandanten-Admin+ISB), `bea.approver@demo.example` (2. Freigeber für
Vier-Augen), `auditor@`, `owner@`, `user@`. Plattform-Login unter `/platform/login`.

## Ablauf jetzt
Lies die drei Dokumente, fasse mir in wenigen Sätzen zusammen, was der aktuelle Stand ist
und was als Nächstes offen wäre, und WARTE dann auf meine konkrete Aufgabe. Fang nichts
Eigenes an. Bei Unklarheiten: gezielt nachfragen.
```