143 lines
3.7 KiB
Markdown
143 lines
3.7 KiB
Markdown
# CLAUDE.md - DrinkDeckel Projektkontext
|
|
|
|
> Fuehrende Projektvorgabe fuer dieses Repository.
|
|
> `AGENTS.md` soll inhaltlich denselben Stand halten; bei Abweichungen hat `CLAUDE.md` Vorrang.
|
|
|
|
## Ziel
|
|
|
|
SaaS-Plattform fuer Getraenkeabrechnung in Vereinen (Multi-Tenant, Mobile + Theke, Payments).
|
|
|
|
## Tech Stack (STRIKT einhalten)
|
|
|
|
- Backend: NestJS (TypeScript, strict mode)
|
|
- Datenbank: Supabase (PostgreSQL via TypeORM)
|
|
- Frontend: React + TailwindCSS
|
|
- Auth: JWT (Passport)
|
|
- Payments: Stripe (vorbereitet, spaeter SEPA)
|
|
|
|
## Architektur-Regeln
|
|
|
|
- Modulare Struktur (feature-based), keine Logik in Controllern
|
|
- DTOs + class-validator fuer alle Inputs
|
|
- Services fuer Business-Logik
|
|
- Repository-Pattern fuer DB-Zugriff
|
|
- `clubId` ueberall erzwingen (Multi-Tenant-Sicherheit)
|
|
- Keine Magic Values, Enums/Konstanten verwenden
|
|
- Starkes Typing ueberall, async/await (keine Callbacks)
|
|
|
|
## Sicherheits-Regeln
|
|
|
|
- Alle Inputs validieren
|
|
- Secrets niemals hardcoden oder ausgeben
|
|
- Nur Environment-Variablen fuer Zugangsdaten und Secrets verwenden
|
|
- Keine Framework-Mischung ausserhalb des definierten Stacks
|
|
|
|
## Projektstruktur
|
|
|
|
```text
|
|
/backend
|
|
/src
|
|
/core
|
|
/common
|
|
/modules
|
|
/members
|
|
/drinks
|
|
/bookings
|
|
/clubs
|
|
/billing
|
|
/auth
|
|
/frontend
|
|
/docs
|
|
```
|
|
|
|
## Datenbank-Schema (Supabase / PostgreSQL)
|
|
|
|
```sql
|
|
-- users
|
|
id, email, password, role
|
|
|
|
-- clubs
|
|
id, name
|
|
|
|
-- memberships
|
|
user_id, club_id
|
|
|
|
-- drinks
|
|
id, club_id, name, price
|
|
|
|
-- bookings
|
|
id, user_id, club_id, drink_id, amount, created_at
|
|
|
|
-- invoices
|
|
id, club_id, user_id, total, month, created_at
|
|
```
|
|
|
|
## API Endpoints (Uebersicht)
|
|
|
|
| Method | Endpoint | Beschreibung |
|
|
|--------|----------------|----------------------|
|
|
| POST | /auth/register | User registrieren |
|
|
| POST | /auth/login | JWT Token holen |
|
|
| POST | /bookings | Buchung erstellen |
|
|
| GET | /bookings | Buchungen abrufen |
|
|
| POST | /test | DB-Verbindung testen |
|
|
| GET | /test | DB-Verbindung testen |
|
|
|
|
## Supabase Verbindung (TypeORM)
|
|
|
|
ENV-Variablen:
|
|
|
|
```env
|
|
DB_HOST=your-supabase-host
|
|
DB_PORT=5432
|
|
DB_USER=your-user
|
|
DB_PASSWORD=your-password
|
|
DB_NAME=postgres
|
|
DB_SSL=true
|
|
|
|
SUPABASE_URL=
|
|
SUPABASE_KEY=
|
|
JWT_SECRET=
|
|
```
|
|
|
|
TypeORM-Optionen:
|
|
|
|
- `autoLoadEntities: true`
|
|
- `synchronize: true` (nur DEV!)
|
|
- SSL aktiviert
|
|
|
|
## Dependencies (Backend)
|
|
|
|
```bash
|
|
npm install @nestjs/config @nestjs/typeorm typeorm pg
|
|
npm install class-validator class-transformer
|
|
npm install @nestjs/jwt passport passport-jwt bcrypt
|
|
npm install @supabase/supabase-js
|
|
```
|
|
|
|
## Workflow-Regeln
|
|
|
|
- Immer erklaeren, was gemacht wird, BEVOR Code geschrieben wird
|
|
- Schrittweise vorgehen, einen Task nach dem anderen
|
|
- Kleine, reviewbare Commits
|
|
- Keine unnoetigen Dateien anlegen
|
|
- Keine Overengineering, keine unbenutzten Dependencies
|
|
- Bestehende Dateien bevorzugen statt neue anlegen
|
|
- Immer nur den aktuell relevanten Kontext und die noetigen Dokus laden
|
|
|
|
## Entwicklungs-Phasen
|
|
|
|
1. Phase 1 - Setup: NestJS Basis, Ordnerstruktur, ENV, DB-Verbindung
|
|
2. Phase 2 - Datenmodell: Entities fuer clubs, members, drinks, bookings, invoices
|
|
3. Phase 3 - Core Module: Members, Drinks, Bookings (CRUD)
|
|
4. Phase 4 - Multi-Tenant Security: `clubId`-Enforcement ueberall
|
|
5. Phase 5 - Auth: JWT, Rollen (admin/member), Passwort-Hashing
|
|
6. Phase 6 - Billing: Monatsabrechnung, Invoice-Generierung, Stripe-Vorbereitung
|
|
|
|
## Wie AI-Modelle dieses Projekt bearbeiten sollen
|
|
|
|
- Aktuellen Fortschritt aus den Phasen oben ableiten
|
|
- Bei unklarem Stand aktiv klaeren, welche Phase gerade relevant ist
|
|
- Detaildokumentation liegt in `/docs/` (`02-setup.md` bis `07-billing.md`)
|
|
- `CLAUDE.md` als kanonische Quelle behandeln und `AGENTS.md` bei Aenderungen synchron halten
|