Erstellen einer ersten test-Komponente die in der Mockup-HTML-Seite und in Contao eingebunden werden kann

AGENTS.md

@@ -19,6 +19,15 @@ In dieses soll eine WebComponente integriert werden, die einen Terminbuchungskal
 Termininformationen kommen aus der Datenbank entweder mittels Contao oder direkt als MySQL Query.
 Es gibt zwei Kalender (je für PW/PS) und jeder Kalender enthält eigene Termine die von Besuchern gebucht werden können.
 
+### Auslieferungswege der Terminbuchungskomponente
+
+Die Terminbuchungskomponente muss in zwei gleichwertigen Varianten funktionieren:
+
+- **Apache-Vorschau:** als Bestandteil der statischen Seite im Webpfad `public/perspektivwerk/`, erreichbar unter `http://localhost:8080/perspektivwerk/`.
+- **Contao-Einbindung:** als einbettbare Komponente in einem Contao-Inhaltselement vom Typ HTML.
+
+Beide Varianten verwenden dieselben browsernativen JavaScript- und CSS-Assets aus `public/booking/`. Die Apache-Vorschau referenziert sie über `/booking/booking.js` und `/booking/booking.css`. Für Contao wird das kombinierte Snippet aus `integration/contao-html-element.html` in ein neues Inhaltselement vom Typ **HTML** eingefügt. Es muss als Roh-HTML im Feld „HTML-Code“ gespeichert werden, nicht als Textinhalt eines TinyMCE-Text-Elements. Ein zweites Kopieren in den Contao-Dateibereich `files/` ist nicht erforderlich.
+
 ### Die Oberfläche / UI
 
 - ein Kalender-view aller Tage des aktuellen Monats
@@ -70,19 +79,20 @@ Es gibt zwei Kalender (je für PW/PS) und jeder Kalender enthält eigene Termine
 
 ### Technische Fragen
 
- 1. Die verwendete Contao-Version hat bekannte Sicherheitslücken, wann wird aktualisiert?
- 2. Ich benötige eigene Datenbanken (oder Speicher direkt in Contao) für die Termine und E-Mails
- 3. E-Mail Validierung bei Buchung:
+1. Die verwendete Contao-Version hat bekannte Sicherheitslücken, wann wird aktualisiert?
+2. Zum einbinden der Terminbuchung muss in den Sicherheitseinstellungen von Contao <link> und <script> Element + deren Attribute frei gegeben werden.
+3. Ich benötige eigene Datenbanken (oder Speicher direkt in Contao) für die Termine und E-Mails
+4. E-Mail Validierung bei Buchung:
      1. Terminbuchungstool muss E-Mails schicken können (IMAP-Konto)
      2. Wann sollen Nutzerdaten gelöscht werden? (Fachlich und aus DSGVO     Sicht)
- 4. Art.13 DSGVO: festgelegte Rechtsgrundlage:
+5. Art.13 DSGVO: festgelegte Rechtsgrundlage:
      1. Nutzer die sich anmelden haben das Recht auf Dateneinsicht und     Datenlöschung, wie damit am besten umgehen?
      2. Ein Löschkonzept sowie geregelte Zugriffe der Mitarbeitenden.
      3. Datenminimierung und Speicherbegrenzung verlangen, nur     notwendige Daten und nur so lange wie erforderlich zu speichern.
- 5. Hat der Mailserver SPF, DKIM und DMARC für die Absenderdomain eingerichtet?
- 6. Serverseitige Input-Validierung, CSRF-Schutz, Rate Limits, Bot-Schutz mit Datenschutzfreundlicher Eskalation und keine preisgebenden Fehlermeldungen?
- 7. Gibt es Staging und Development Systeme für die Entwicklung?
- 8. Wer verantwortet Betrieb, Updates, Backups, Monitoring und Datenschutzanfragen?
+6. Hat der Mailserver SPF, DKIM und DMARC für die Absenderdomain eingerichtet?
+7. Serverseitige Input-Validierung, CSRF-Schutz, Rate Limits, Bot-Schutz mit Datenschutzfreundlicher Eskalation und keine preisgebenden Fehlermeldungen?
+8. Gibt es Staging und Development Systeme für die Entwicklung?
+9. Wer verantwortet Betrieb, Updates, Backups, Monitoring und Datenschutzanfragen?
 
 
 ## Projektkontext
@@ -100,8 +110,7 @@ Die folgenden Punkte sind aus einer passiven, öffentlich sichtbaren Analyse abg
 - Als CMS ist sehr wahrscheinlich Contao im Einsatz.
 - Der Webserver antwortet mit `Apache`.
 - Die Anwendung läuft sehr wahrscheinlich auf einem PHP-Stack; Contao spricht dabei typischerweise über Symfony/Doctrine mit einer MySQL- oder MariaDB-Datenbank.
-- Im Frontend sind Bootstrap-5-Elemente sowie jQuery erkennbar.
-- Zusätzliche Frontend-Bausteine wie Slick-Slider und eigene CSS-Bundles sind eingebunden.
+- Zusätzliche Frontend-Bausteine wie Slick-Slider und eigene CSS-Bundles sind auf der Bestandswebsite eingebunden.
 - Ein selbst gehostetes Matomo-Tracking ist sichtbar.
 - Der genaue Contao- und PHP-Versionsstand ist von außen nicht belastbar bestimmbar und sollte für die Implementierung als offen behandelt werden.
 - Der Host wirkt nach der Infrastruktur sehr wahrscheinlich wie eine IONOS-Umgebung, auch das ist aber nur eine Wahrscheinlichkeitsannahme.
@@ -109,13 +118,13 @@ Die folgenden Punkte sind aus einer passiven, öffentlich sichtbaren Analyse abg
 Für die weitere Umsetzung bedeutet das:
 
 - Die Terminbuchung sollte sich sauber in eine klassische CMS-Seite einbetten lassen.
-- Ein kleines, eigenständiges TypeScript-Frontend ist hier voraussichtlich passender als eine große neue Framework-Schicht.
+- Ein kleines, eigenständiges JavaScript-Frontend ist hier voraussichtlich passender als eine große neue Framework-Schicht.
 - Backend- und Kalenderanbindung sollten entkoppelt geplant werden, damit ein späterer Wechsel von Google Kalender zu Exchange möglich bleibt, ohne das UI neu bauen zu müssen.
 
 ## Lokales Entwicklungssystem
 
 - Das lokale Setup bildet die vermutete Komponentenfamilie mit Docker Compose nach: Apache/PHP 8.3, Contao Managed Edition 5.3, MariaDB 10.11 und Adminer.
-- Frontend-Abhängigkeiten für die angenommene Originalseite sind in `package.json` vorgesehen: Bootstrap 5, jQuery und Slick Carousel; die eigene Logik bleibt in TypeScript.
+- Für die Buchungskomponente wird eigene Logik als browsernatives JavaScript ohne Build-Schritt ausgeliefert.
 - Start über `docker compose up --build`; CMS auf Port 8080, Adminer auf Port 8081, MariaDB zusätzlich auf Host-Port 3307.
 - Das Setup ist eine reproduzierbare Entwicklungsbasis und keine Kopie der Produktivinstallation. Exakte Contao-/PHP-Versionen, Templates, Erweiterungen und Hosting-Einstellungen der Originalseite müssen bei Zugriff auf die Produktivumgebung abgeglichen werden.
 
@@ -137,14 +146,15 @@ Für die weitere Umsetzung bedeutet das:
 
 - Mobile-first und barrierearm entwickeln.
 - Eine in Contao CMS funkionierende Lösung sein.
-- Die Frontend-Logik in TypeScript umsetzen.
-- Für die Oberfläche möglichst einfache, weit verbreitete Technologien nutzen: HTML, CSS und TypeScript ohne unnötige Framework-Schicht.
+- Die Frontend-Logik in browsernativem JavaScript (ES-Module) umsetzen.
+- Für die Oberfläche möglichst einfache, weit verbreitete Technologien nutzen: HTML, CSS und JavaScript ohne unnötige Framework-Schicht oder verpflichtenden Build-Schritt.
 - Performance hat Priorität: geringe Dateigrößen, wenig JavaScript, keine unnötigen Abhängigkeiten, schnelle Rendering- und Ladezeiten.
 - Die Lösung soll modular, testbar und leicht ins Contao Backend integriert werden können.
 
 ## Technische Anforderungen
 
 - Die Lösung muss im Contao CMS sauber einbindbar sein.
+- Die Lösung muss zusätzlich als Apache-Vorschau unter `/perspektivwerk/` funktionieren.
 - Die Terminliste soll klar, verständlich und mobil kompatibel sein.
 - Zugriffsdaten und Zugangsspezifika sind als Umgebungsvariablen bzw. sichere Konfiguration zu behandeln.
 - Die technische Architektur soll die Integration ins Contao Backend sauber abbilden, ohne dass das Frontend später neu geschrieben werden muss falls die Kommunikation zu Datenbank angepasst werden muss. (Separation of concerns)
@@ -197,7 +207,7 @@ Die Aufgabe gilt als abgeschlossen, wenn:
 - auf der Contao-Webseite die Terminbuchung angezeigt wird.
 - die Terminarten auswählbar sind,
 - die Oberfläche mobil-first, performant und barrierearm ist,
-- das Frontend in TypeScript umgesetzt wurde,
+- das Frontend in browsernativem JavaScript umgesetzt wurde,
 - die Konfiguration sicher, dokumentiert und nachvollziehbar ist,
 - die Kernfunktionen durch Tests abgesichert sind.