Readme und Agend.md gefüllt
This commit is contained in:
285
AGENTS.md
285
AGENTS.md
@@ -1,54 +1,251 @@
|
||||
# AGENTS.md
|
||||
AGENTS.md
|
||||
💍 Wedding App – Agent Specification (Modern UI Edition)
|
||||
1. Project Overview
|
||||
|
||||
Diese Datei definiert, wie der Coding-Agent in diesem Repository arbeiten soll.
|
||||
A private wedding web app for invited guests. (Link: https://www.svenja-dominic-hochzeit.de/)
|
||||
|
||||
## Ziel
|
||||
- Schnell, pragmatisch und sauber am Projekt arbeiten.
|
||||
- Änderungen nachvollziehbar halten.
|
||||
- Risiken früh sichtbar machen.
|
||||
Core goals:
|
||||
|
||||
## Projektkontext
|
||||
- Projektname: `wedding-app`
|
||||
- Hauptidee:
|
||||
- TODO: Kurz in 2-4 Sätzen beschreiben, was die App lösen soll.
|
||||
- Status:
|
||||
- TODO: MVP / in Entwicklung / produktiv
|
||||
password-protected access (event password)
|
||||
|
||||
## Tech-Stack
|
||||
- Backend: TODO
|
||||
- Frontend: TODO
|
||||
- Datenbank: TODO
|
||||
- Deployment: TODO
|
||||
RSVP + plus-one selection
|
||||
|
||||
## Arbeitsregeln für den Agenten
|
||||
- Erst lesen, dann ändern.
|
||||
- Kleine, gezielte Änderungen statt großer unkontrollierter Umbauten.
|
||||
- Bestehende Patterns im Code respektieren.
|
||||
- Keine destruktiven Git-Befehle ohne explizite Freigabe.
|
||||
- Bei Unsicherheit Annahmen klar nennen.
|
||||
photo upload + shared gallery
|
||||
|
||||
## Code-Standards
|
||||
- Lesbarkeit vor Cleverness.
|
||||
- Funktions- und Variablennamen eindeutig wählen.
|
||||
- Kommentare nur dort, wo Logik sonst nicht sofort klar ist.
|
||||
- Keine unnötigen Abhängigkeiten hinzufügen.
|
||||
modern information pages (schedule, hotels, taxi)
|
||||
|
||||
## Tests & Validierung
|
||||
- Nach Änderungen relevante Tests ausführen.
|
||||
- Wenn keine Tests vorhanden sind:
|
||||
- Mindestens Smoke-Test beschreiben und durchführen.
|
||||
- Bei nicht ausführbaren Tests Grund dokumentieren.
|
||||
embedded Google Maps location
|
||||
|
||||
## Dokumentation
|
||||
- README aktuell halten bei:
|
||||
- Setup-Änderungen
|
||||
- neuen Umgebungsvariablen
|
||||
- neuen Commands
|
||||
- Architekturänderungen
|
||||
- Wichtige Entscheidungen kurz als Decision Log festhalten.
|
||||
external link to the official location website
|
||||
|
||||
## Decision Log
|
||||
- YYYY-MM-DD: Entscheidung, Grund, Auswirkung
|
||||
button to switch the language of the webapp from german to english
|
||||
|
||||
## Nächste Schritte (laufend pflegen)
|
||||
- TODO: wichtigste offene Aufgaben als kurze Liste
|
||||
visually polished, modern design (mobile-first)
|
||||
|
||||
|
||||
|
||||
2. Tech Stack (Required)
|
||||
|
||||
Python 3.12
|
||||
|
||||
Flask
|
||||
|
||||
Gunicorn
|
||||
|
||||
uv (dependency management)
|
||||
|
||||
SQLite
|
||||
|
||||
Docker + Docker Compose
|
||||
|
||||
Frontend approach:
|
||||
|
||||
Use server-rendered templates (Jinja2)
|
||||
|
||||
Use modern CSS (prefer one of the following):
|
||||
|
||||
Tailwind CSS via CDN (fastest)
|
||||
|
||||
or a small handcrafted CSS design system (preferred if no CDN)
|
||||
|
||||
No heavy JS frameworks required.
|
||||
|
||||
3. UI / UX Design Requirements (IMPORTANT)
|
||||
|
||||
The site must look modern, elegant, and “wedding-like”:
|
||||
|
||||
Visual Style
|
||||
|
||||
Clean typography (Google Fonts allowed)
|
||||
|
||||
Soft spacing, rounded cards, subtle shadows
|
||||
|
||||
Consistent color palette (e.g., beige / cream / dark green / gold accents)
|
||||
|
||||
Smooth hover states and transitions
|
||||
|
||||
High-quality hero section on landing page
|
||||
|
||||
Layout
|
||||
|
||||
Mobile-first (works on phones)
|
||||
|
||||
Clear navigation
|
||||
|
||||
Dashboard cards for features (RSVP, Upload, Info)
|
||||
|
||||
Minimal clutter, lots of whitespace
|
||||
|
||||
Pages
|
||||
|
||||
Must implement at least:
|
||||
|
||||
Landing / Login page (with hero design)
|
||||
|
||||
Dashboard
|
||||
|
||||
RSVP page (or dashboard section)
|
||||
|
||||
Upload page
|
||||
|
||||
Gallery page
|
||||
|
||||
Info pages (schedule, hotels, taxi, location)
|
||||
|
||||
4. Location Page Requirements
|
||||
|
||||
Must include:
|
||||
|
||||
Embedded Google Maps iframe
|
||||
|
||||
Address (configurable)
|
||||
|
||||
A prominent button:
|
||||
|
||||
“Zur Location-Webseite” (or “Visit Location Website”)
|
||||
|
||||
open in new tab (target="_blank" rel="noopener")
|
||||
|
||||
The location website URL must be configurable via environment variable:
|
||||
|
||||
LOCATION_WEBSITE_URL
|
||||
|
||||
Optionally also:
|
||||
|
||||
LOCATION_NAME
|
||||
|
||||
LOCATION_ADDRESS
|
||||
|
||||
GOOGLE_MAPS_EMBED_URL
|
||||
|
||||
5. Authentication Requirements
|
||||
|
||||
Registration/login requires event password
|
||||
|
||||
Event password stored in environment variable:
|
||||
|
||||
EVENT_PASSWORD
|
||||
|
||||
Guest provides:
|
||||
|
||||
event password
|
||||
|
||||
guest name
|
||||
|
||||
Use Flask sessions
|
||||
|
||||
Keep it simple (no email verification, no roles)
|
||||
|
||||
6. Database Schema (Minimum)
|
||||
|
||||
Table: guests
|
||||
|
||||
id (PK)
|
||||
|
||||
name (required)
|
||||
|
||||
attending (boolean, nullable)
|
||||
|
||||
plus_one (boolean, default False)
|
||||
|
||||
created_at (timestamp)
|
||||
|
||||
Table: uploads
|
||||
|
||||
id (PK)
|
||||
|
||||
filename
|
||||
|
||||
uploaded_by (guest id)
|
||||
|
||||
uploaded_at (timestamp)
|
||||
|
||||
SQLite is sufficient.
|
||||
|
||||
7. RSVP Logic
|
||||
|
||||
In the UI:
|
||||
|
||||
guest selects attending Yes/No
|
||||
|
||||
plus_one option only shown if attending Yes
|
||||
|
||||
persist to database
|
||||
|
||||
8. Upload Requirements
|
||||
|
||||
allowed types: jpg, jpeg, png
|
||||
|
||||
configurable max upload size
|
||||
|
||||
sanitize filenames
|
||||
|
||||
prevent path traversal
|
||||
|
||||
store in /uploads
|
||||
|
||||
store upload reference in DB
|
||||
|
||||
9. Gallery Requirements
|
||||
|
||||
all guests can view uploaded images
|
||||
|
||||
show thumbnails in a responsive grid
|
||||
|
||||
click opens a larger view (simple modal or dedicated page)
|
||||
|
||||
10. Dependency Management Rules
|
||||
|
||||
Use uv
|
||||
|
||||
Dependencies defined in pyproject.toml
|
||||
|
||||
Commit uv.lock
|
||||
|
||||
No requirements.txt
|
||||
|
||||
In Docker:
|
||||
|
||||
uv sync --frozen --no-dev
|
||||
|
||||
11. Docker Requirements
|
||||
|
||||
Dockerfile must:
|
||||
|
||||
Base: python:3.12-slim
|
||||
|
||||
Install uv
|
||||
|
||||
Copy pyproject.toml + uv.lock first (cache-friendly)
|
||||
|
||||
Run uv sync --frozen --no-dev
|
||||
|
||||
Start with:
|
||||
|
||||
uv run gunicorn -b 0.0.0.0:8000 app:app
|
||||
|
||||
Uploads + SQLite database must be persistent via volumes.
|
||||
|
||||
12. Non-Goals (Do NOT implement)
|
||||
|
||||
Admin dashboards
|
||||
|
||||
Email systems
|
||||
|
||||
Payments
|
||||
|
||||
OAuth
|
||||
|
||||
External cloud storage
|
||||
|
||||
Microservices
|
||||
|
||||
13. Design Philosophy
|
||||
|
||||
Aesthetic first, but not overengineered
|
||||
|
||||
Simple, maintainable code
|
||||
|
||||
Minimal dependencies
|
||||
|
||||
Good UX on mobile
|
||||
298
README.md
298
README.md
@@ -0,0 +1,298 @@
|
||||
💍 Wedding App – Svenja & Dominic
|
||||
|
||||
Eine private, moderne Hochzeits-Webanwendung für eingeladene Gäste.
|
||||
|
||||
Die Anwendung ermöglicht eine geschützte Registrierung, RSVP-Verwaltung, Foto-Uploads sowie den Zugriff auf alle relevanten Informationen rund um die Hochzeit – in einem eleganten, mobilen Design.
|
||||
|
||||
🎯 Projektziel
|
||||
|
||||
Die Wedding-App soll:
|
||||
|
||||
unter dem Link https://www.svenja-dominic-hochzeit.de/ zum login führen.
|
||||
|
||||
Gästen einen passwortgeschützten Zugang bieten
|
||||
|
||||
Zu- und Absagen verwalten (inkl. Begleitperson)
|
||||
|
||||
eine gemeinsame Fotogalerie bereitstellen
|
||||
|
||||
Informationen zur Location, Hotels in der Nähe, Taxi und Ablauf anzeigen
|
||||
|
||||
eine eingebettete Google Maps Karte enthalten
|
||||
|
||||
einen prominenten Link zur offiziellen Website der Hochzeitslocation anzeigen
|
||||
|
||||
Einen Switch auf Englisch haben.
|
||||
|
||||
Die Seite soll modern, ästhetisch und mobil optimiert sein.
|
||||
|
||||
🎨 Design-Anforderung (WICHTIG)
|
||||
|
||||
Die Anwendung soll:
|
||||
|
||||
modern, elegant und hochwertig wirken
|
||||
|
||||
mobil-first entwickelt werden
|
||||
|
||||
viel Weißraum verwenden
|
||||
|
||||
runde Karten mit sanften Schatten nutzen
|
||||
|
||||
eine konsistente Farbpalette haben (z. B. Beige, Creme, Dunkelgrün, Gold-Akzente)
|
||||
|
||||
klare Typografie verwenden (z. B. Google Fonts)
|
||||
|
||||
dezente Hover-Animationen besitzen
|
||||
|
||||
Seitenstruktur
|
||||
|
||||
Mindestens folgende Seiten müssen umgesetzt werden:
|
||||
|
||||
Login / Landing Page (mit Hero-Section)
|
||||
|
||||
Dashboard
|
||||
|
||||
RSVP-Bereich
|
||||
|
||||
Upload-Seite
|
||||
|
||||
Galerie
|
||||
|
||||
Informationsseiten:
|
||||
|
||||
Ablauf
|
||||
|
||||
Hotels
|
||||
|
||||
Taxi
|
||||
|
||||
Location
|
||||
|
||||
🗺 Location-Seite Anforderungen
|
||||
|
||||
Die Location-Seite muss enthalten:
|
||||
|
||||
Google Maps Embed (iframe)
|
||||
|
||||
Name der Location
|
||||
|
||||
Adresse
|
||||
|
||||
Einen deutlich sichtbaren Button:
|
||||
|
||||
„Zur Location-Webseite“
|
||||
|
||||
Dieser Button muss:
|
||||
|
||||
in neuem Tab öffnen (target="_blank")
|
||||
|
||||
rel="noopener" verwenden
|
||||
|
||||
URL aus Environment Variable beziehen
|
||||
|
||||
Konfigurierbare Variablen:
|
||||
|
||||
LOCATION_NAME
|
||||
|
||||
LOCATION_ADDRESS
|
||||
|
||||
LOCATION_WEBSITE_URL
|
||||
|
||||
GOOGLE_MAPS_EMBED_URL
|
||||
|
||||
🔐 Login & Registrierung
|
||||
|
||||
Zugriff nur mit Event-Passwort
|
||||
|
||||
Passwort wird als Environment Variable gespeichert:
|
||||
|
||||
EVENT_PASSWORD
|
||||
|
||||
Registrierung:
|
||||
|
||||
Gast gibt Event-Passwort ein
|
||||
|
||||
Gast gibt seinen Namen ein
|
||||
|
||||
Nach erfolgreicher Prüfung → Weiterleitung zum Dashboard
|
||||
|
||||
Session-basiert (Flask Sessions)
|
||||
|
||||
Keine E-Mail-Verifikation
|
||||
Kein Rollen-System
|
||||
Keine öffentliche Registrierung
|
||||
|
||||
|
||||
📝 RSVP-System
|
||||
|
||||
Im Dashboard kann der Gast auswählen:
|
||||
|
||||
Ich komme
|
||||
|
||||
Ich komme nicht
|
||||
|
||||
Ich bringe eine Begleitperson mit (nur wenn attending = true)
|
||||
|
||||
Daten werden persistent in der Datenbank gespeichert.
|
||||
|
||||
📸 Foto-Upload
|
||||
|
||||
Erlaubte Formate: jpg, jpeg, png
|
||||
|
||||
Dateigröße begrenzen (konfigurierbar)
|
||||
|
||||
Speicherung in /uploads
|
||||
|
||||
Dateinamen müssen sanitisiert werden
|
||||
|
||||
Path Traversal verhindern
|
||||
|
||||
Upload wird in Datenbank referenziert
|
||||
|
||||
🖼 Galerie
|
||||
|
||||
Alle Gäste sehen alle Bilder
|
||||
|
||||
Responsive Grid
|
||||
|
||||
Optional: einfache Modal-Ansicht bei Klick
|
||||
|
||||
🧱 Datenbank (SQLite)
|
||||
Tabelle: guests
|
||||
|
||||
id (Primary Key)
|
||||
|
||||
name (String, required)
|
||||
|
||||
attending (Boolean, nullable)
|
||||
|
||||
plus_one (Boolean, default False)
|
||||
|
||||
created_at (Timestamp)
|
||||
|
||||
Tabelle: uploads
|
||||
|
||||
id (Primary Key)
|
||||
|
||||
filename
|
||||
|
||||
uploaded_by (Guest ID)
|
||||
|
||||
uploaded_at (Timestamp)
|
||||
|
||||
🧪 Entwicklungsphasen
|
||||
Phase 1 – MVP
|
||||
|
||||
Authentifizierung
|
||||
|
||||
Datenbank
|
||||
|
||||
RSVP
|
||||
|
||||
Phase 2
|
||||
|
||||
Upload
|
||||
|
||||
Galerie
|
||||
|
||||
Phase 3
|
||||
|
||||
Informationsseiten
|
||||
|
||||
Location + Google Maps
|
||||
|
||||
Externer Location-Link
|
||||
|
||||
Phase 4
|
||||
|
||||
UI-Feinschliff
|
||||
|
||||
Sicherheitsverbesserungen
|
||||
|
||||
🧰 Technischer Stack
|
||||
|
||||
Python 3.12
|
||||
|
||||
Flask
|
||||
|
||||
Gunicorn
|
||||
|
||||
uv (Dependency Management)
|
||||
|
||||
SQLite
|
||||
|
||||
Docker
|
||||
|
||||
Docker Compose
|
||||
|
||||
Optional: Nginx + Certbot (Production)
|
||||
|
||||
📦 Dependency Management
|
||||
|
||||
Keine requirements.txt
|
||||
|
||||
Nutzung von uv
|
||||
|
||||
Abhängigkeiten in pyproject.toml
|
||||
|
||||
uv.lock wird committed
|
||||
|
||||
Docker nutzt:
|
||||
|
||||
uv sync --frozen --no-dev
|
||||
|
||||
🐳 Docker Anforderungen
|
||||
|
||||
Base Image: python:3.12-slim
|
||||
|
||||
uv im Container installiert
|
||||
|
||||
Gunicorn als Produktionsserver
|
||||
|
||||
Persistente Volumes für:
|
||||
|
||||
uploads
|
||||
|
||||
SQLite-Datenbank
|
||||
|
||||
Startbefehl:
|
||||
|
||||
uv run gunicorn -b 0.0.0.0:8000 app:app
|
||||
|
||||
🔒 Sicherheitsanforderungen
|
||||
|
||||
Event-Passwort darf niemals im Frontend erscheinen
|
||||
|
||||
Upload-Dateitypen validieren
|
||||
|
||||
Dateigröße limitieren
|
||||
|
||||
HTTPS verpflichtend im Produktivbetrieb
|
||||
|
||||
Keine unnötigen Features implementieren
|
||||
|
||||
❌ Nicht-Ziele
|
||||
|
||||
Kein Admin-Panel
|
||||
|
||||
Keine E-Mail-Funktion
|
||||
|
||||
Kein Payment
|
||||
|
||||
Kein OAuth
|
||||
|
||||
Keine Cloud-Storage-Integration
|
||||
|
||||
Keine Microservices
|
||||
|
||||
💡 Design-Philosophie
|
||||
|
||||
Schön vor komplex
|
||||
|
||||
Einfach vor überengineered
|
||||
|
||||
Wartbar vor clever
|
||||
|
||||
Modern, aber nicht verspielt
|
||||
|
||||
Mobil optimiert
|
||||
Reference in New Issue
Block a user