KantSites/docs/AUSBAUPLAN.md

# Ausbauplan bis zum Pilotbetrieb

Stand: 12.09.2026. Ergänzt `ENTWICKLUNGSPLAN.md` um die Aufschlüsselung der noch offenen Arbeit. Der Phasenplan bleibt die übergeordnete Reihenfolge; dieses Dokument benennt die konkreten Arbeitspakete, ihre Abhängigkeiten und ihre Abnahme. Der aktuelle Stand steht in `docs/STATUS.md`, begründete Entscheidungen in `docs/ARCHITECTURE.md`.

## Pilotwebsite: kant-it.de

Umut hat `kant-it.de` am 12.09.2026 als Pilotwebsite bestimmt. Der Ausbau richtet sich ab jetzt an dieser Website aus, nicht an einem generischen CMS-Funktionsumfang.

### Erhobener Bestand

Erhoben am 12.09.2026 ausschließlich aus der **öffentlich ausgelieferten Startseite**. Es bestand kein Zugriff auf das WordPress-Backend. Alles Folgende ist damit belegt, aber nicht vollständig: Entwürfe, nicht verlinkte Seiten, Formularkonfigurationen, Benutzerrollen, individuelle Felder und der tatsächliche Beitragsbestand sind von außen nicht sichtbar.

**Technischer Bestand**

| Bereich | Befund |
| --- | --- |
| Kern | WordPress 7.1 |
| Theme | Flatsome 3.20.9 mit Child-Theme `kant-it-flatsome-ux-child`, eigenes `kant-it-home.js` |
| Startseite | Seitenvorlage `page-blank`, vollständig im UX Builder aufgebaut |
| Formulare | WPForms Lite |
| Cookie-Banner | Complianz GDPR |
| Bewertungen | WP Google Places Review Slider (externe Google-Rezensionen) |
| Chat | `kant-nova-chat` – ein **eigenes Plugin**, kein Marktplatzprodukt |
| Suche | Flatsome Live Search |

**Inhaltlicher Bestand**

- Startseite als Onepager. Die Hauptnavigation verweist auf Ankerziele derselben Seite (`#dienstleistungen`, `#projekte`, `#kontakt`), nicht auf Unterseiten.
- Beiträge mit flachem Permalink direkt unter der Wurzel, zum Beispiel `/kanttresor-dsgvo-konforme-archivierung-fuer-moderne-unternehmen/` und `/neue-webseite-fuer-klinik-umsetzer-de-umgesetzt/`. Dazu eine Übersichtsseite `/productsolutions`.
- Rechtsseiten `/impressum/` und `/datenschutzerklaerung/`.
- Externe Ziele: `hausklar.app`, `kanttresor.kant-it.de`, TeamViewer-QuickSupport-Download.
- Kontaktdaten als Inhalt: Telefon, E-Mail, Anschrift in Baden-Baden, jeweils als `tel:`- und `mailto:`-Verweis.

**Abschnittsarten der Startseite**, die als Blöcke gebraucht werden: Hero mit Handlungsaufruf, Logoleiste, Kennzahlen, Leistungsraster mit Symbol und Text, Lösungs- und Projektkarten mit Bild, Kundenstimmen mit Bewertung und Person, Hinweisbox mit Download, Handlungsaufruf-Band, Kontaktbereich aus Kontaktdaten und Formular.

### Was daraus folgt

1. **Menüs müssen Ankerziele und externe Ziele können**, nicht nur Seitenverweise. Ein reiner Seitenbaum als Navigation reicht für diesen Piloten nicht.
2. **Beiträge liegen flach unter der Wurzel** und haben eine eigene Übersichtsseite. Das passt zum heutigen Datenmodell (`type = post`, `path` ohne Elternteil) und braucht keine Schemaänderung.
3. **Das Formular ist der Kern der Seite.** Ohne serverseitig validiertes Kontaktformular mit Einwilligung und Versand ist der Pilot nicht livefähig.
4. **Drei Fremdbausteine sind keine Inhalte, sondern Integrationen**: Cookie-Banner, Google-Rezensionen und der eigene Chat. Sie gehören hinter die Plugin-Schnittstelle, nicht in den Kern. Der Erhaltungsvertrag für unbekannte Blöcke (ADR 011) ist die Grundlage dafür.
5. **`kant-nova-chat` ist Eigenentwicklung.** Für die Migration muss sein Quellcode vorliegen; ohne ihn ist der Chat kein migrierbares Feature, sondern ein Neubau.
6. **Strukturierte Daten lohnen sich hier konkret**: Anschrift, Telefon und Öffnungszeiten eines regionalen Dienstleisters sind ein echter `LocalBusiness`-Fall, keine Pflichtübung.

### Offen und nur von Umut zu beantworten

- Zugang zum WordPress-Backend oder ein Export, um Beiträge, Formularfelder, Benutzer und Flatsome-Shortcodes tatsächlich zu inventarisieren.
- Quellcode von `kant-nova-chat`.
- Hostinganbieter, Tarif, PHP- und Datenbankversion, Dokumentenstamm, CLI- und Deploymentzugang.
- Umgang mit den Google-Rezensionen: weiter über einen externen Dienst oder als gepflegter Inhalt.
- Soll der Pilot beim Cookie-Banner bleiben, und wenn ja, mit welchem Dienst.

## Arbeitspakete

Die Reihenfolge ergibt sich aus Abhängigkeiten und aus dem Risiko, etwas später über Kundendaten ändern zu müssen. Jedes Paket endet mit einem prüfbaren Ergebnis, aktualisiertem STATUS und, wo nötig, einer Architekturentscheidung.

### A – Navigation und Menüs — **erledigt am 12.09.2026**

*Braucht: Seitenhierarchie (erledigt).*

Umgesetzt bis auf eines: Aufklappmenüs, Anker-, Seiten- und externe Ziele, Header und Footer getrennt, `aria-current`, keine öffentliche JavaScript-Abhängigkeit, gelöschte Seiten brechen das Menü nicht. **Offen geblieben:** die Sortierung läuft über Positionsnummern statt per Drag-and-drop, und es gibt nur die beiden festen Plätze. Details in ADR 012.

Menüverwaltung mit benannten Menüs und sortierbaren Einträgen. Ein Eintrag verweist auf eine Seite, auf ein Ankerziel innerhalb einer Seite oder auf eine externe Adresse; Beschriftung ist überschreibbar. Verschachtelung für Aufklappmenüs. Header- und Footermenü getrennt. Ausgabe als semantische Navigation mit `aria-current`, ohne öffentliches JavaScript für die Grundfunktion.

Abnahme: Die feste Navigation im Template ist ersetzt. Ein Menü mit Anker-, Seiten- und externem Ziel wird korrekt ausgegeben. Eine gelöschte Seite macht das Menü nicht kaputt.

### B – Beiträge

*Braucht: A für die Verlinkung.*

Beitragsdatum, Autor, Auszug und Beitragsbild im Datenmodell. Übersichtsseite mit Sortierung nach Datum und Paginierung. Ein Block „Beitragsliste“ zum Einbetten in beliebige Seiten, mit Anzahl und Filter. Einzelansicht mit Datum und Autor. Kategorien und Schlagwörter einschließlich ihrer Archivseiten. RSS-Feed.

Abnahme: Die vier bestehenden Projektbeiträge des Piloten lassen sich als Beiträge abbilden, erscheinen in der Übersicht und in einer eingebetteten Liste auf der Startseite.

### C – Blöcke für den Piloten

*Braucht: nichts; parallel möglich.*

Die oben erhobenen Abschnittsarten als Blöcke: Symbol-und-Text-Karte, Kennzahl, Kundenstimme mit Bewertung, Logoleiste, Handlungsaufruf-Band, Kontaktdatenblock, Trennlinie und Abstandhalter. Dazu Akkordeon und Tabs, weil beide im Plan stehen und ohne JavaScript über `details`/`summary` beziehungsweise Sprungmarken lösbar sind.

Abnahme: Die Startseite des Piloten ist ohne Code nachbaubar. Keine neue öffentliche JavaScript-Abhängigkeit.

### D – Formulare

*Braucht: nichts; das größte eigenständige Paket.*

Formularbaukasten mit Feldtypen Text, E-Mail, Telefon, Auswahl, Mehrzeiliges, Einwilligungskästchen und Datei. Pflichtfelder, serverseitige Validierung mit Fehlermeldungen am Feld, Beschriftungen und Fehlerauszeichnung für Screenreader. Versand per E-Mail mit Antwortadresse, dazu Speicherung der Einsendungen mit Ansicht in der Verwaltung. Spam-Schutz ohne Drittanbieter-CAPTCHA: Honeypot, Zeitschwelle, Rate-Limit pro IP. Einwilligungstext mit Verweis auf die Datenschutzerklärung, Zeitpunkt der Einwilligung wird mitgespeichert.

Abnahme: Das Kontaktformular des Piloten ist nachgebaut, funktioniert ohne JavaScript, weist ungültige Eingaben serverseitig ab und stellt eine E-Mail zu. Ein abgewiesener Versand verliert keine Eingaben.

### E – SEO und maschinelle Zugänglichkeit

*Braucht: A und B für Sitemap und Breadcrumbs.*

SEO-Felder je Seite: Titel, Beschreibung, Indexierungssteuerung, Open-Graph-Bild. Automatische `sitemap.xml`, `robots.txt`, Weiterleitungsverwaltung mit HTTP 301 und 410. Strukturierte Daten für `Organization`/`LocalBusiness` aus gepflegten Unternehmensdaten, für `Article` aus Beiträgen, für `BreadcrumbList` aus der Hierarchie. Breadcrumb-Block. `llms.txt` optional und abschaltbar, ohne jede Behauptung über Ranking oder Zitierung.

Abnahme: Sitemap und robots.txt stimmen mit dem veröffentlichten Bestand überein. Eine Adressänderung erzeugt eine Weiterleitung. Strukturierte Daten decken sich mit sichtbarem Inhalt und bestehen die Prüfung mit dem Testwerkzeug.

### F – Seiten verwalten

*Braucht: A und E für Menüs und Weiterleitungen.*

Seiten umbenennen und verschieben, mit Aktualisierung aller Kindpfade in einer Transaktion und automatischer Weiterleitung von der alten Adresse. Startseite frei wählbar. Geplantes Veröffentlichen. Revisionsliste mit Vergleich und Wiederherstellung in der Oberfläche. Papierkorb statt sofortigem Löschen.

Abnahme: Eine Seite mit Unterseiten wird verschoben; alle alten Adressen leiten weiter, Menüs bleiben intakt.

### G – Editor für die tägliche Arbeit

*Braucht: C.*

Inline-Textbearbeitung direkt in der Vorschau. Globale Farben und Schriften. Header und Footer als bearbeitbare Bereiche. Wiederverwendbare Sektionen mit Unterscheidung zwischen Kopie und globaler Verknüpfung. Autosave mit sichtbarem Zustand. Bildzuschnitt in der Mediathek, Ordner, Paginierung und Unterstützung für PDF und Video.

Abnahme: Die Pilotwebsite lässt sich vollständig ohne Code pflegen. Eine geänderte globale Farbe wirkt auf allen Seiten.

### H – Plugins und Templates

*Braucht: den Erhaltungsvertrag (erledigt).*

Registrierung von Blöcken, Einstellungen und Hooks über dokumentierte Schnittstellen. Manifest mit Versionsanforderungen, Abhängigkeitsprüfung, Aktivieren und Deaktivieren ohne Inhaltsverlust. Ressourcen werden nur dort geladen, wo der Block vorkommt. Templatepaket mit Designwerten und Seitenvorlagen; zwei Templates auf denselben Inhalten erprobt. Als Referenzplugin der Chatbaustein des Piloten.

Abnahme: Templatewechsel erhält die Inhalte. Das Referenzplugin lässt sich aktivieren, aktualisieren und deaktivieren; seine Blöcke werden bei Deaktivierung kontrolliert dargestellt statt gelöscht.

### I – Benutzer, Betrieb und Leistung

*Braucht: nichts; teils vorziehbar.*

Benutzerverwaltung und Passwortänderung in der Oberfläche. Inhaltscache mit gezielter Erneuerung beim Veröffentlichen. Bildformate und Ressourcenpakete prüfen. Sicherung und Wiederherstellung erproben. Updateverfahren mit Datenbankmigration und Rückfallstrategie dokumentieren.

Abnahme: Veröffentlichen macht die Änderung sofort sichtbar und erneuert nur die betroffenen Einträge. Eine Wiederherstellung aus dem Backup ist nachgewiesen.

### J – Hosting und MySQL

*Braucht: die Antwort von Umut.*

Anbieter und Tarif festlegen. MySQL oder MariaDB tatsächlich nachweisen statt nur vorbereiten. Deployment, Dokumentenstamm, Dateirechte, Cronjobs und E-Mail-Versand einrichten. Staging aufsetzen. Erst danach sind Leistungsmessungen aussagekräftig: die bisherigen Lighthouse-Werte stammen von einem lokalen PHP-Server mit kleinen Testinhalten und sagen über das Zielhosting nichts.

Abnahme: Die Anwendung läuft auf dem Zielhosting mit MySQL. Messungen mit realen Inhalten liegen vor, einschließlich der Bedingungen.

### K – Migration von kant-it.de

*Braucht: B, C, D, E, F, H, J und Backendzugang.*

Export und Import für Seiten, Beiträge, Medien, Adressen und SEO-Daten. Flatsome-Shortcodes inventarisieren und die tatsächlich vorkommenden Typen auf eigene Blöcke abbilden; unbekannte Inhalte im Importbericht ausweisen und erhalten, nicht verwerfen. Adressen, Medienverweise und interne Links vor und nach dem Umzug vergleichen. Weiterleitungen für alle bestehenden Adressen. Backup und Wiederherstellung erproben, Rückweg zur bisherigen Website vorbereiten.

Abnahme: kant-it.de ist vollständig geprüft migriert, der Rückweg ist erprobt. Der Livegang erfolgt erst, wenn Umut ihn ausdrücklich beauftragt.

## Bewusst nicht in Version 1

Shop und Buchungen, Mehrmandantenbetrieb, zentrale Verwaltung mehrerer Installationen, öffentlicher Pluginmarktplatz, Kommentare, Mehrsprachigkeit über das Datenmodell hinaus und redaktionelle KI. Diese Punkte stehen im Entwicklungsplan als spätere Phasen und werden erst nach dem Pilotbetrieb anhand des tatsächlichen Bedarfs geplant.

## Zum Aufwand

Der Entwicklungsplan sieht eine Aufwandsschätzung nach dem ersten durchgängigen Prototyp vor. Belastbar schätzen lässt sich erst, wenn der Backendzugang zum Piloten vorliegt: der tatsächliche Beitragsbestand, die Anzahl der Flatsome-Shortcode-Typen und der Umfang von `kant-nova-chat` bestimmen den Aufwand der Pakete B, H und K erheblich. Ohne diese Angaben wäre jede Zahl hier eine Erfindung.