Auto-commit: 2026-05-20 21:35

memory/gitea-specs/issue-15.md

@@ -0,0 +1,79 @@
+# Spezifikation: Issue #15 – Kontaktformular Backend-Integration
+
+**Repo:** greggy/landingpage-haus-schleusingen  
+**Issue:** [#15](https://git.home.kies-media.de/greggy/landingpage-haus-schleusingen/issues/15)  
+**Komplexität:** S (Small)  
+**Datum:** 2026-05-13
+
+## Problem
+Das Kontaktformular simuliert den Versand nur mit `setTimeout`. Anfragen gehen verloren.
+
+## Lösung: mailto:-Link mit vorformatierter E-Mail
+
+Da das Projekt eine **statische Landingpage** (HTML/CSS/JS) ohne Backend ist, wird der Formular-Submit so umgebaut, dass ein `mailto:`-Link generiert wird. Der E-Mail-Client des Nutzers öffnet sich mit einer vorausgefüllten E-Mail an `mki@kies-media.de`.
+
+### Warum mailto: statt Formspree?
+- Keine externe Abhängigkeit, kein Account nötig
+- Funktioniert zuverlässig auf allen Geräten
+- Kein Privacy-Problem (Daten gehen nicht über Drittanbieter)
+- Keine Limits (Formspree: 50/Monat kostenlos)
+
+### Warum kein eigenes Backend?
+- Statische Seite (nginx serves HTML only)
+- Extra Infrastruktur nötig (PHP/Node.js + SMTP)
+- Overkill für eine Vermietungs-Landingpage
+
+## Technische Umsetzung
+
+### Formular-HTML (haus-schleusingen.html)
+- Form bleibt wie vorhanden (fname, lname, email, phone, interest, message)
+- Keine Änderung an name-Attributen nötig (alle bereits kompatibel)
+
+### JavaScript (js/haus-schleusingen.js)
+Form-Submit-Handler wird ersetzt:
+
+```javascript
+$("#contactForm").on("submit", function (e) {
+  e.preventDefault();
+  var fname = $("#fname").val().trim();
+  var lname = $("#lname").val().trim();
+  var email = $("#email").val().trim();
+  var phone = $("#phone").val().trim();
+  var interest = $("#interest").val();
+  var message = $("#message").val().trim();
+
+  var subject = "Kontaktanfrage: " + interest;
+  var body = "Von: " + fname + " " + lname + "\n";
+  body += "E-Mail: " + email + "\n";
+  if (phone) body += "Telefon: " + phone + "\n";
+  body += "Anliegen: " + interest + "\n\n";
+  body += message;
+
+  var mailto = "mailto:mki@kies-media.de"
+    + "?subject=" + encodeURIComponent(subject)
+    + "&body=" + encodeURIComponent(body);
+
+  window.location.href = mailto;
+
+  // Erfolgsmeldung anzeigen
+  $("#contactForm").hide();
+  $("#formSuccess").fadeIn(400);
+});
+```
+
+### Edge Cases
+- **Kein E-Mail-Client installiert:** mailto:-Link tut nichts → Nutzer sieht trotzdem Erfolgsmeldung (suboptimal, aber bei statischer Seite akzeptabel)
+- **Leere Felder:** HTML5 `required` auf fname, lname, email verhindert leeren Submit
+- **Sonderzeichen:** `encodeURIComponent` kodiert Umlaute und Sonderzeichen korrekt
+- **Lange Nachrichten:** mailto:-Body hat praktische Limits (~2000 Zeichen URL), für Kontaktformulare ausreichend
+
+### Akzeptanzkriterien
+1. ✅ Bei Submit öffnet sich der E-Mail-Client mit vorformatierter E-Mail
+2. ✅ Betreff enthält Art des Anliegens
+3. ✅ Body enthält alle Formulardaten strukturiert
+4. ✅ Erfolgsmeldung wird angezeigt
+5. ✅ Kein setTimeout-Simulatoren mehr
+6. ✅ Bestehendes CSS/Styling bleibt unverändert
+
+## Branch: `feature/issue-15-kontaktformular-backend`
+## Target: `main`

memory/gitea-specs/issue-16-final.md

@@ -0,0 +1,46 @@
+# Abschlussbericht: Issue #16 – SEO-Grundlagen: Meta Tags, Open Graph und Schema.org
+
+**Repo:** `greggy/landingpage-haus-schleusingen`
+**PR:** [#23](https://git.home.kies-media.de/greggy/landingpage-haus-schleusingen/pulls/23)
+**Branch:** `feature/issue-16-seo-meta-schema`
+**Komplexität:** S (Small)
+**Datum:** 2026-05-13
+
+---
+
+## Was wurde gemacht
+
+SEO-Grundlagen für die Landingpage implementiert:
+
+1. **Meta Description** – Aussagekräftiger Text mit allen Key-Daten (227 m², 6 Zimmer, 1.300 €, Adresse)
+2. **Canonical URL** – `https://haus-schleusingen.de/haus-schleusingen.html`
+3. **Open Graph Tags** – 7 Tags für Social-Sharing (Facebook, LinkedIn, etc.)
+4. **Schema.org JSON-LD** – RealEstateListing Structured Data für Google Rich Results
+5. **Title-Tag optimiert** – `Einfamilienhaus mieten Schleusingen | 227 m², 6 Zimmer | 1.300 € Kaltmiete`
+6. **robots.txt** – Neu erstellt mit Sitemap-Referenz
+
+## Offene Punkte für Martin
+
+- ⚠️ **Domain bestätigen:** Aktuell Platzhalter `haus-schleusingen.de` – Martin muss die tatsächliche Domain nennen
+- Nach Deploy: Google Rich Results Test manuell prüfen
+- Nach Deploy: URL bei Google Search Console einreichen
+
+## Pipeline-Verlauf
+
+| Phase | Dauer | Ergebnis |
+|---|---|---|
+| Phase 1 (Analyse) | ~5 min (vorab erledigt) | ✅ Spezifikation erstellt |
+| Phase 2 (Implementierung) | ~3 min | ✅ 1 Commit, 2 Dateien geändert |
+| Phase 3 (Code Review) | ~2 min | ✅ APPROVED |
+| Phase 4 (QA) | übersprungen (S) | – |
+| Phase 5 (Merge/PR) | ~1 min | ✅ PR #23 erstellt |
+| Phase 6 (Abnahme) | ~1 min | ✅ ACCEPTED |
+| Phase 7 (Closing) | ~1 min | ✅ |
+| **Gesamt** | **~13 min** | |
+
+## Nächste Schritte
+
+1. Martin mergt PR #23 nach Review
+2. Domain bestätigen und URLs ggf. anpassen
+3. Deploy durchführen
+4. Google Search Console + Rich Results Test

memory/gitea-specs/issue-17-final.md

@@ -0,0 +1,85 @@
+# Abschlussbericht: Issue #17 – Bildoptimierung WebP + Lazy Loading + Caching
+
+**Repo:** `greggy/landingpage-haus-schleusingen`
+**Issue:** #17
+**PR:** #22
+**Branch:** `feature/issue-17-bildoptimierung-webp`
+**Datum:** 2026-05-13
+**Komplexität:** M (Medium)
+
+---
+
+## Zusammenfassung
+
+Die Landingpage der Haus-Schleusingen-Website wurde umfassend für Performance optimiert. Alle Bilder wurden nach WebP konvertiert, Lazy Loading implementiert, nginx-Caching und Gzip aktiviert, und defekte Bildreferenzen wurden repariert.
+
+---
+
+## Was wurde gemacht
+
+### 1. WebP-Konvertierung (41 Dateien)
+- Alle 40 Originalbilder (PNG/JPG/JPEG) nach WebP konvertiert (Qualität 80)
+- **21,6 MB → 2,8 MB (87% Reduktion)**
+- Originale als Fallback beibehalten
+- Thumbnails und Grundrisse inkludiert
+
+### 2. HTML-Modernisierung
+- 21 `<picture>` Elemente mit WebP-Source + Original-Fallback
+- `loading="lazy"` auf 22 below-the-fold Bildern
+- Hero-Bild (CSS background) direkt auf WebP aktualisiert
+
+### 3. Defekte Referenzen repariert
+- `bad3.jpg` (404) → `Bad-3.webp` (existierende Datei)
+- `WhatsApp Image 2026-03-30...jpeg` (404) → `Bad-4.webp` (existierende Datei)
+
+### 4. nginx-Optimierung
+- Gzip aktiviert für CSS, JS, SVG, JSON, XML
+- 30-Tage Cache-Headers für alle statischen Assets
+- `Cache-Control: public, immutable`
+
+### 5. Cleanup
+- `js/masonry.pkgd.min.js` (24 KB) gelöscht – wurde nie referenziert
+
+### 6. Lightbox WebP-Support
+- Error-Handler mit `.off('error')` zur Vermeidung von Stacking
+- Fallback: WebP → PNG bei Ladefehlern
+
+---
+
+## Commits (4)
+
+1. `938e701` – `feat(images): convert all images to WebP with 87% size reduction`
+2. `dd6b816` – `fix(images): update nginx with gzip and 30d cache headers`
+3. `f84f4ed` – `fix(images): remove unused masonry.js and fix broken references`
+4. `b6a4d9b` – `fix(js): improve lightbox WebP fallback error handler`
+
+---
+
+## Zeit-Tracking
+
+| Phase | Dauer |
+|---|---|
+| Phase 1 (Analyse) | Vorab durch Main-Agent erledigt |
+| Phase 2 (Implementierung) | ~15 Min |
+| Phase 3 (Code Review) | ~5 Min |
+| Phase 5 (Merge/PR) | ~2 Min |
+| Phase 6 (Abnahme) | ~3 Min |
+| Phase 7 (Dokumentation) | ~5 Min |
+| **Gesamt** | **~30 Min** |
+
+---
+
+## Ergebnis
+
+- **Status:** PR #22 erstellt, wartet auf Martins Merge
+- **Review:** APPROVED
+- **Validierung:** ACCEPTED
+- **Alle Akzeptanzkriterien:** Erfüllt ✅
+
+---
+
+## Nächste Schritte
+
+1. **Martin** merged PR #22 via Gitea
+2. Nach Merge: Docker neu builden und deployen
+3. Issue #17 wird nach Martins Merge geschlossen

memory/gitea-specs/issue-18-final.md

@@ -0,0 +1,83 @@
+# Abschlussbericht: Issue #18 – Accessibility
+
+**Datum:** 2026-05-14  
+**Repo:** `greggy/landingpage-haus-schleusingen`  
+**PR:** [#24](https://git.home.kies-media.de/greggy/landingpage-haus-schleusingen/pulls/24)  
+**Branch:** `feature/issue-18-accessibility`  
+**Commit:** `9e146ac`
+
+---
+
+## Zusammenfassung
+
+Umsetzung aller Accessibility-Verbesserungen für die Landingpage nach WCAG 2.1 AA. 8 Teilaufgaben vollständig implementiert, reviewt und validiert.
+
+---
+
+## Was wurde gemacht
+
+| Teilaufgabe | Beschreibung | Status |
+|---|---|---|
+| TA-1 | Skip-to-Content Link | ✅ |
+| TA-2 | ARIA-Landmarks & Rollen | ✅ |
+| TA-3 | Akkordeon Keyboard + ARIA | ✅ |
+| TA-4 | Lightbox Focus-Trap + Management | ✅ |
+| TA-5 | Galerie Keyboard-Bedienung | ✅ |
+| TA-6 | Alt-Texte optimiert | ✅ |
+| TA-7 | Focus-Visible Styles | ✅ |
+| TA-8 | Farbkontrast-Fix (WCAG AA) | ✅ |
+
+### Geänderte Dateien
+- `haus-schleusingen.html` – Skip-Link, `<main>`, ARIA-Attribute, Alt-Texte
+- `css/haus-schleusingen.css` – Skip-Link-Styles, `:focus-visible`, `--stone` Kontrast-Fix
+- `js/haus-schleusingen.js` – Keyboard-Handler, Focus-Trap, `aria-expanded` Toggling
+
+### Code-Stats
+- **+170 Zeilen / -53 Zeilen** über 3 Dateien
+
+---
+
+## Architektur-Entscheidungen
+
+1. **`--stone` Farbänderung:** `#9e9485` → `#7a7062` – dunklere Variante für WCAG AA Kontrast. Warme/erdige Palette bleibt erhalten.
+2. **Lightbox `alt=""`:** Leerer Alt-Text auf dem Lightbox-Bild, da der Kontext durch `aria-label="Bildansicht"` auf dem Dialog bereitgestellt wird.
+3. **Floor-Plan-Bilder:** Keine Keyboard-Interaktivität hinzugefügt – informative Bilder innerhalb des Akkordeons, nicht primär interaktiv.
+
+---
+
+## Zeit-Tracking
+
+| Phase | Dauer |
+|---|---|
+| Phase 1 (Analyse) | Bereits abgeschlossen (vor Pipeline-Start) |
+| Phase 2 (Implementierung) | ~20 Min |
+| Phase 3 (Code Review) | ~10 Min |
+| Phase 4 (QA) | Übersprungen (keine automatisierten Tests für statische Seite) |
+| Phase 5 (PR erstellt) | ~2 Min |
+| Phase 6 (Abnahme & Validierung) | ~5 Min |
+| Phase 7 (Dokumentation & Closing) | ~5 Min |
+| **Gesamt:** | **~42 Min** |
+
+---
+
+## Bekannte Einschränkungen
+
+- **Mobile Navigation:** `.nav-links { display: none }` ab 900px ohne Hamburger-Menü. Empfehlung: Folgeticket erstellen.
+- **Keine automatisierten Tests:** Statische Seite ohne Test-Framework. Manuelle Tests empfohlen (Keyboard, Screenreader, axe DevTools).
+
+---
+
+## Nächste Schritte
+
+1. **Martin merged PR #24**
+2. Issue #18 wird nach Merge geschlossen
+3. Optional: Folgeticket für mobile Navigation erstellen
+
+---
+
+## Referenzen
+
+- Spezifikation: `memory/gitea-specs/issue-18.md`
+- Review: `memory/gitea-specs/issue-18-review.md`
+- Validierung: `memory/gitea-specs/issue-18-validation.md`
+- PR: https://git.home.kies-media.de/greggy/landingpage-haus-schleusingen/pulls/24

memory/gitea-specs/issue-19-final.md

@@ -0,0 +1,66 @@
+# Abschlussbericht: Issue #19 – jQuery entfernen und Masonry.js auflösen
+
+**Repo:** `greggy/landingpage-haus-schleusingen`
+**Issue:** [#19](https://git.home.kies-media.de/greggy/landingpage-haus-schleusingen/issues/19)
+**PR:** [#21](https://git.home.kies-media.de/greggy/landingpage-haus-schleusingen/pulls/21)
+**Komplexität:** S
+**Datum:** 2026-05-13
+**Status:** ✅ Wartet auf Martins Merge
+
+---
+
+## Zusammenfassung
+
+jQuery 3.7.1 (CDN) und die ungenutzte Masonry.js wurden vollständig entfernt. Der gesamte JavaScript-Code (~130 Zeilen) wurde in Vanilla JS neu geschrieben mit verbesserter Performance (IntersectionObserver statt scroll-Event).
+
+### Änderungen
+| Datei | Aktion |
+|---|---|
+| `js/haus-schleusingen.js` | Komplett neu in Vanilla JS |
+| `haus-schleusingen.html` | jQuery CDN `<script>` entfernt |
+| `js/masonry.pkgd.min.js` | Gelöscht (dead code) |
+| `eslint.config.js` | jQuery-Globals entfernt |
+
+### Performance-Gewinn
+- **~30KB** weniger (jQuery CDN + Masonry.js entfallen)
+- IntersectionObserver statt scroll-Event für Animationen
+- Keine externe Abhängigkeit mehr
+- 1 HTTP-Request weniger (jQuery CDN)
+
+### 6 Funktionsbereiche migriert
+1. Navbar-Scroll → `window.addEventListener("scroll", ...)` + `window.scrollY`
+2. Hero-Animation → `classList.add` mit `setTimeout(200)`
+3. Scroll-Animationen → `IntersectionObserver` (performanter als jQuery-Scroll)
+4. Akkordeon → `classList.toggle` + `display`-Wechsel
+5. Lightbox → Native Event-Listener + `dataset.img`
+6. Kontaktformular → Native `value`/`addEventListener` + CSS-FadeIn
+
+---
+
+## Pipeline-Verlauf
+
+| Phase | Dauer | Status |
+|---|---|---|
+| Phase 1: Analyse | *(bereits abgeschlossen)* | ✅ |
+| Phase 2: Implementierung | ~4 Min | ✅ Code committed & pushed |
+| Phase 3: Code Review | ~2 Min | ✅ APPROVED |
+| Phase 4: Test & QA | *(übersprungen, Komplexität S)* | ⏭️ |
+| Phase 5: Merge & Release | ~1 Min | ✅ PR #21 erstellt, mergeable |
+| Phase 6: Abnahme & Validierung | ~1 Min | ✅ ACCEPTED (11/11 Kriterien) |
+| Phase 7: Dokumentation & Closing | ~1 Min | ✅ Dieser Bericht |
+
+**Gesamtzeit Phase 2–7:** ~9 Minuten
+
+---
+
+## Nächste Schritte
+- **Martin merged PR #21** → Issue wird danach geschlossen
+- Nach Merge: Issue #19 via API schließen
+- Feature Branch nach Merge im Remote löschen
+
+---
+
+## Lessons Learned
+- IntersectionObserver ist ein klarer Performance-Gewinn gegenüber scroll-basierten Sichtbarkeits-Checks
+- CSS `display: none/block` für Akkordeon ist einfacher als jQuery slideUp/slideDown, verzichtet aber auf die Slide-Animation
+- `masonry.pkgd.min.js` war dead code – gut dass das aufgeräumt wurde

memory/gitea-specs/issue-27-final.md

@@ -0,0 +1,41 @@
+# Abschlussbericht Issue #27: Mobile Navigation – Hamburger-Menü
+
+## Zusammenfassung
+Implementierung eines Hamburger-Menüs für die mobile Navigation der Landingpage Haus Schleusingen.
+
+## Was wurde gemacht
+- **HTML:** Hamburger-Button (`nav-hamburger`) + Overlay (`nav-mobile-overlay`) in der Navbar eingefügt
+- **CSS:** Vollständiges mobiles Styling mit Slide-Down-Animation, 44px Tap-Targets, Scroll-State-Farben (weiß auf Hero, dunkel gescrollt), Overlay
+- **JS:** Vanilla-JS IIFE für Toggle, Escape-Taste, Outside-Click (Overlay), Link-Klick schließt Menü, Resize-to-Desktop schließt Menü
+
+## Akzeptanzkriterien
+- [x] Hamburger-Menü auf Mobile (≤768px) sichtbar (Breakpoint bei ≤900px)
+- [x] Nav-Links in Slide-down-Menü
+- [x] Alle Tap-Targets mindestens 44px
+- [x] Desktop-Navigation bleibt unverändert
+- [x] Escape/Outside-Click schließt Menü
+- [x] Kein jQuery, nur Vanilla-JS
+
+## Ergebnis
+**ACCEPTED** – Alle Kriterien erfüllt.
+
+## PR
+- PR #32 → gemergt von Martin
+
+## Komplexität
+S (Small) – QA übersprungen, vereinfachter Validierungs- und Closing-Flow
+
+## Abnahme
+- Code-Review des deployten Stands auf `http://178.104.150.0:6427/`
+- HTML, CSS, JS vollständig geprüft
+- Browser-Snapshot validiert (Desktop: Desktop-Navi sichtbar, kein Hamburger)
+
+## Zeit-Tracking
+- Phase 1 (Analyse): ~5 min
+- Phase 2 (Implementierung): ~15 min
+- Phase 3 (Review): ~10 min
+- Phase 4 (QA): übersprungen (S)
+- Phase 5 (Merge): ~2 min
+- Phase 6 (Abnahme): ~5 min
+- Phase 7 (Closing): ~5 min
+- **Gesamt:** ~42 min

memory/gitea-specs/issue-28-final.md

@@ -0,0 +1,27 @@
+# Issue #28 – Abschlussbericht: CTA-Button auffälliger gestalten
+
+**Issue:** #28  
+**PR:** #30  
+**Branch:** feature/issue-28-cta-button  
+**Komplexität:** S (Small)  
+**Status:** ✅ Geschlossen
+
+## Zusammenfassung
+Der CTA-Button „JETZT ANFRAGEN" im Header wurde visuell aufgewertet:
+- Schriftgröße 0.78→0.82rem, Schriftgewicht 500→600
+- Padding erhöht (0.8rem 2rem), border-radius, box-shadow hinzugefügt
+- Hover-Effekt: translateY(-2px), intensivierter Shadow
+
+## Pipeline-Verlauf
+| Phase | Status | Dauer |
+|---|---|---|
+| 1. Analyse | ✅ | ~2 Min |
+| 2. Implementierung | ✅ | ~5 Min |
+| 3. Code Review | ✅ APPROVED | ~2 Min |
+| 4. QA | ⏭ übersprungen (S) | – |
+| 5. Merge & Release | ✅ PR #30 | Martin gemergt |
+| 6. Abnahme | ✅ ACCEPTED | ~3 Min |
+| 7. Closing | ✅ | ~2 Min |
+
+## Ergebnis
+Alle Akzeptanzkriterien erfüllt. Keine Regressions. Keine bekannten Einschränkungen.

memory/gitea-specs/issue-29-final.md

@@ -0,0 +1,28 @@
+# Issue #29 – Abschlussbericht: Impressum und Datenschutz
+
+**Issue:** #29  
+**PR:** #31  
+**Branch:** feature/issue-29-impressum-datenschutz  
+**Komplexität:** S (Small)  
+**Status:** ✅ Geschlossen
+
+## Zusammenfassung
+Zwei neue rechtliche Seiten erstellt:
+- `impressum.html` – Vollständiges Impressum gemäß §5 TMG
+- `datenschutz.html` – DSGVO-konforme Datenschutzerklärung
+- Footer-Links in der Hauptseite aktualisiert
+- Beide Seiten mit `meta robots noindex`
+
+## Pipeline-Verlauf
+| Phase | Status | Dauer |
+|---|---|---|
+| 1. Analyse | ✅ | ~2 Min |
+| 2. Implementierung | ✅ | ~8 Min |
+| 3. Code Review | ✅ APPROVED | ~3 Min |
+| 4. QA | ⏭ übersprungen (S) | – |
+| 5. Merge & Release | ✅ PR #31 | Martin gemergt |
+| 6. Abnahme | ✅ ACCEPTED | ~3 Min |
+| 7. Closing | ✅ | ~2 Min |
+
+## Ergebnis
+Alle Akzeptanzkriterien erfüllt. Rechtlich konform. Design konsistent. Keine Regressions.

memory/gitea-specs/issue-34.md

@@ -0,0 +1,110 @@
+# Issue #34 – Kontaktformular: E-Mail-Versand via PHP
+
+- **Repo:** `greggy/landingpage-haus-schleusingen`
+- **Issue:** #34
+- **Titel:** Kontaktformular: E-Mail-Versand via PHP
+- **Komplexität:** **M**
+- **Stand:** Analyse abgeschlossen
+- **Datum:** 2026-05-14
+
+## Kurzbewertung
+
+Das Issue ist **Medium (M)**: Es ist kein großer Architekturumbau, aber es ist mehr als ein kleiner Bugfix, weil serverseitige PHP-Logik, Spam-Schutz, Validierung, sichere Header-Behandlung und UI-Feedback zusammen umgesetzt werden müssen.
+
+## Abhängigkeiten
+
+- **Keine blockierenden offenen Issues gefunden.**
+- `index.php` existiert bereits auf `main` und ist die richtige Basis für die PHP-Umsetzung.
+- Hinweis: Das bestehende Docker/Nginx-Setup dient weiter als statisches Preview, verarbeitet aber kein PHP-Mail-Handling. Für den echten Versand ist eine PHP-fähige Laufzeit nötig (Testumgebung: Apache/PHP).
+
+## Anforderungen aus dem Issue
+
+1. Kontaktformular verschickt E-Mails serverseitig via PHP.
+2. Empfänger ist `mki@kies-media.de`.
+3. Absender (`From`) ist die E-Mail-Adresse aus dem Formular.
+4. Pflichtfeld-Validierung für Name, E-Mail und Nachricht.
+5. Spam-Schutz via Honeypot und zusätzlicher Missbrauchsschutz.
+6. Erfolgsmeldung nach erfolgreichem Versand.
+7. Verständliche Fehlermeldungen bei ungültigen oder fehlenden Eingaben.
+
+## Implizite Anforderungen / Edge Cases
+
+- Header-Injection über Name/E-Mail darf nicht möglich sein.
+- Ungültige E-Mail-Adressen müssen serverseitig abgelehnt werden.
+- Leere oder nur aus Leerzeichen bestehende Nachrichten müssen abgelehnt werden.
+- Bots sollen am Honeypot scheitern.
+- Sehr schnelle Direkt-Submits sollen als verdächtig behandelt werden.
+- Mehrfach-Submits in kurzer Zeit sollen begrenzt werden.
+- Bei Mail-Fehlern darf kein falscher Erfolg angezeigt werden.
+- Formulardaten sollen bei Validierungsfehlern im Formular erhalten bleiben.
+
+## Technischer Plan
+
+### Backend / PHP
+
+- `index.php` bekommt einen serverseitigen POST-Handler.
+- `session_start()` wird verwendet für:
+  - Formular-Timestamp
+  - einfaches Rate-Limit zwischen Submits
+- Hilfsfunktionen:
+  - `normalizeContactValue()` für Trim/Sanitizing
+  - `escapeContactValue()` für sichere Ausgabe ins HTML
+  - `containsHeaderInjection()` für Header-Schutz
+- Versand über `mail()` mit Headern:
+  - `From: <Formular-E-Mail>`
+  - `Reply-To: <Formular-E-Mail>`
+  - `Content-Type: text/plain; charset=UTF-8`
+- Bei Erfolg: Formular leeren und Erfolgsmeldung rendern.
+- Bei Fehlern: Fehlerliste oberhalb des Formulars rendern.
+
+### Frontend / HTML
+
+- Formular auf `method="post"` umstellen.
+- Honeypot-Feld ergänzen (visuell versteckt, für Screenreader ebenfalls ausgeschlossen).
+- Hidden-Feld für Formular-Token/Timestamp ergänzen.
+- Bestehende Erfolgsmeldung auf serverseitig gesteuerten Zustand umbauen.
+- Pflichtfelder klar markieren und `required` beibehalten.
+
+### Frontend / JS
+
+- Bestehende `mailto:`-Logik entfernen.
+- Sonstige Interaktionen (Lightbox, Navigation, Scroll) unverändert lassen.
+
+### Styling
+
+- Styles für:
+  - Fehlermeldungsbox
+  - serverseitige Erfolgsmeldung
+  - Honeypot-Hilfsklasse
+
+## Sicherheitsbetrachtung
+
+- Pflicht: serverseitige Validierung, nicht nur HTML5.
+- Pflicht: Schutz vor Header-Injection in Mail-Headern.
+- Pflicht: Honeypot leer + Mindestzeit bis Submit + Session-Rate-Limit.
+- Keine sensiblen Daten in Logs oder im Frontend ausgeben.
+
+## Teilaufgaben
+
+1. `main`-Stand prüfen und Feature-Branch anlegen.
+2. `index.php` serverseitig auf POST/Mailversand umbauen.
+3. Formular um Honeypot, Hidden-Felder, Fehler-/Erfolgsausgabe ergänzen.
+4. `js/haus-schleusingen.js` von `mailto:`-Submit befreien.
+5. CSS für Meldungszustände ergänzen.
+6. Linting / Formatierung / PHP-Syntaxcheck ausführen.
+7. Self-Review dokumentieren.
+8. QA inkl. Happy Path, Validierungsfehler und Spam-Schutz dokumentieren.
+9. PR erstellen und Martin zur Freigabe vorlegen.
+
+## Akzeptanzkriterien
+
+- [ ] Formular sendet serverseitig eine E-Mail an `mki@kies-media.de`.
+- [ ] `From` verwendet die eingegebene Formular-E-Mail.
+- [ ] E-Mail enthält Name, E-Mail, optional Telefon, Anliegen und Nachricht.
+- [ ] Honeypot + zusätzlicher Missbrauchsschutz aktiv.
+- [ ] Erfolgsmeldung nach erfolgreichem Versand sichtbar.
+- [ ] Fehlermeldungen bei fehlenden/ungültigen Pflichtfeldern sichtbar.
+
+## Architekturentscheidung
+
+Es wird bewusst **kein** SMTP-Layer oder externer Mailer eingebaut, weil das Issue explizit `mail()` erlaubt und für dieses Projekt eine schlanke, servernahe Lösung genügt. Falls Zustellbarkeit oder Hosting-Limits später Probleme machen, wäre ein Folge-Issue für SMTP/PHPMailer sinnvoll.

memory/gitea-specs/issue-36.md

@@ -0,0 +1,58 @@
+# Issue #36: Favicon erstellen und einbinden
+
+## Komplexität: **S** (Small)
+
+## Analyse
+- Keine Abhängigkeiten zu anderen Issues
+- Reine Frontend-Aufgabe: Favicon generieren + `<link>` Tags einfügen
+- Keine Tests nötig (visuell überprüfbar)
+
+## Spezifikation
+
+### 1. Favicon erstellen
+- Design: Haus-Symbol oder initiales "HS" passend zur Landingpage
+- Formate:
+  - `favicon.ico` (16x16, 32x32) – Fallback für ältere Browser
+  - `favicon-32x32.png`
+  - `favicon-16x16.png`
+  - `apple-touch-icon.png` (180x180)
+  - `site.webmanifest` (für Android Chrome)
+- Speicherort: `/bilder/favicon/`
+
+### 2. Einbindung in `index.php`
+Nach Zeile 129 (`<meta charset="UTF-8" />`) einfügen:
+```html
+<link rel="icon" type="image/png" sizes="32x32" href="/bilder/favicon/favicon-32x32.png">
+<link rel="icon" type="image/png" sizes="16x16" href="/bilder/favicon/favicon-16x16.png">
+<link rel="icon" type="image/x-icon" href="/bilder/favicon/favicon.ico">
+<link rel="apple-touch-icon" sizes="180x180" href="/bilder/favicon/apple-touch-icon.png">
+<link rel="manifest" href="/bilder/favicon/site.webmanifest">
+```
+
+### 3. webmanifest
+```json
+{
+  "name": "Haus Schleusingen",
+  "short_name": "HS",
+  "icons": [
+    { "src": "/bilder/favicon/favicon-32x32.png", "sizes": "32x32", "type": "image/png" },
+    { "src": "/bilder/favicon/favicon-16x16.png", "sizes": "16x16", "type": "image/png" }
+  ],
+  "theme_color": "#1c1917",
+  "background_color": "#fafaf9"
+}
+```
+
+### Akzeptanzkriterien
+- [ ] Favicon wird im Browser-Tab angezeigt
+- [ ] Alle Formate vorhanden (ico, png 16+32, apple-touch)
+- [ ] In `index.php` eingebunden
+- [ ] webmanifest vorhanden
+
+## Pipeline
+- ✅ Phase 1: Analyse (Komplexität S)
+- ⬜ Phase 2: Implementierung
+- ⬜ Phase 3: Code Review
+- ⬜ Phase 5: Merge & Release
+- ⬜ Phase 6: Abnahme
+- ⬜ Phase 7: Closing

memory/gitea-specs/issue-6.md

@@ -0,0 +1,9 @@
+# Issue #6: Datenschutz-Link im Footer aktualisieren
+
+## Komplexität: S
+
+## Änderung
+- Footer: `<a href="#">Datenschutz</a>` → `<a href="/datenschutz" target="_blank">Datenschutz</a>`
+## Akzeptanzkriterien
+- [ ] Link verweist auf /datenschutz
+- [ ] Link öffnet in neuem Tab

memory/gitea-specs/issue-8.md

@@ -0,0 +1,11 @@
+# Issue #8: Telefonnummer im Footer hinzufügen
+
+## Komplexität: S
+
+## Änderung
+- Telefonnummer `0176-45853923` im Footer neben der Adresse ergänzen
+- Als `<a href="tel:...">` für Mobile-Klickbarkeit
+
+## Akzeptanzkriterien
+- [ ] Telefonnummer sichtbar im Footer
+- [ ] Klickbar auf Mobile (tel: Link)