Remove all em-dashes from website content and documentation

Replace ' — ' with ', ' across 40 files. Hyphens (-) untouched.
timecapsule, stefankoelle, LICENSE, CSS comments left as-is.

DESIGN.md

@@ -1,57 +1,57 @@
-# moonweb.org Hub-Konzept (v5 — fast vollständig, letzte Lücken vor SPEC.md/PLAN.md)
+# moonweb.org Hub-Konzept (v5, fast vollständig, letzte Lücken vor SPEC.md/PLAN.md)
 
 Status: Konzeptrunde nahezu abgeschlossen. Noch keine Umsetzung.
 
-## 1. Header/Layout-Prinzip — final
+## 1. Header/Layout-Prinzip, final
 
 Für alle Home-Bereich-Sites (infra, smarthome, code, retro) gilt ab jetzt ein klares Prinzip:
 
-- **Header ist das Wichtigste** — identisch über alle vier Sites (Site-Switcher, Banner, Farbakzent der jeweiligen Domain).
+- **Header ist das Wichtigste**, identisch über alle vier Sites (Site-Switcher, Banner, Farbakzent der jeweiligen Domain).
 - **Übersichtsseiten** (Domain-Root) folgen dem einheitlichen Card-Grid-Grundlayout.
-- **Detailseiten/Subseiten** übernehmen den gleichen Header, dürfen darunter aber ein **eigenes, freieres Layout** haben (wie es bei `/ledmatrix/` auf stefankoelle.de heute schon der Fall ist — Pinbelegung, API-Doku, Fotos in freier Anordnung statt starres Card-Raster).
+- **Detailseiten/Subseiten** übernehmen den gleichen Header, dürfen darunter aber ein **eigenes, freieres Layout** haben (wie es bei `/ledmatrix/` auf stefankoelle.de heute schon der Fall ist, Pinbelegung, API-Doku, Fotos in freier Anordnung statt starres Card-Raster).
 
 Das ist ein wichtiger Unterschied zu v3/v4: nicht "alles identisch", sondern **Header konsistent, Content-Layout pro Subseite flexibel**.
 
-## 2. LEDMatrix-Migration — erledigt (Phase 5)
+## 2. LEDMatrix-Migration, erledigt (Phase 5)
 
 - `/ledmatrix/` wurde vollständig ins Monorepo migriert und liegt unter `stefankoelle/de/ledmatrix/`.
 - Deploy erfolgt über IONOS SFTP alongside dem stefankoelle.de Onepager.
 - Die URL `stefankoelle.de/ledmatrix/` bleibt unverändert bestehen.
 
-## 3. Detailtiefe pro Domain — final festgelegt
+## 3. Detailtiefe pro Domain, final festgelegt
 
 | Domain | Detailseiten? | Regel |
 |---|---|---|
-| smarthome | Ja, aber nur wenn genug Content da ist | Übersicht zeigt Aufbau des Smarthomes; ein Thema bekommt sofort eine Detailseite, wenn Daten vorhanden sind — sonst wird das Thema vorerst nur in der Übersicht erwähnt (kein Platzhalter-Zwang) |
-| code | **Nie** | Nur Übersichtskarten + Link zu GitHub — bewusst kein Duplizieren von README-Inhalten |
-| infra | Kaum, eher übersichtsorientiert | Hauptteil bleibt bewusst oberflächlich, da sensible Daten (IPs, Keys, interne Topologie) nicht öffentlich dürfen — siehe Punkt 4 |
-| retro | Ja, aber bewusst rudimentär | Thema ist inhaltlich noch unausgereift — nur Grundgerüst anlegen, keine weitere Zeit investieren |
+| smarthome | Ja, aber nur wenn genug Content da ist | Übersicht zeigt Aufbau des Smarthomes; ein Thema bekommt sofort eine Detailseite, wenn Daten vorhanden sind, sonst wird das Thema vorerst nur in der Übersicht erwähnt (kein Platzhalter-Zwang) |
+| code | **Nie** | Nur Übersichtskarten + Link zu GitHub, bewusst kein Duplizieren von README-Inhalten |
+| infra | Kaum, eher übersichtsorientiert | Hauptteil bleibt bewusst oberflächlich, da sensible Daten (IPs, Keys, interne Topologie) nicht öffentlich dürfen, siehe Punkt 4 |
+| retro | Ja, aber bewusst rudimentär | Thema ist inhaltlich noch unausgereift, nur Grundgerüst anlegen, keine weitere Zeit investieren |
 
-## 4. Infra-Sensitivität — Redaktionsregel (neu, wichtig für SPEC.md)
+## 4. Infra-Sensitivität, Redaktionsregel (neu, wichtig für SPEC.md)
 
-Da infra "eher oberflächlich" bleiben soll, braucht es eine einfache Faustregel, was rein darf und was nicht — sonst ist das bei der Migration der bestehenden Docs (Heimnetzwerk-Final etc.) jedes Mal eine Einzelfallentscheidung:
+Da infra "eher oberflächlich" bleiben soll, braucht es eine einfache Faustregel, was rein darf und was nicht, sonst ist das bei der Migration der bestehenden Docs (Heimnetzwerk-Final etc.) jedes Mal eine Einzelfallentscheidung:
 
 - **Darf rein:** Architektur-Ebene (Proxmox + Synology + Docker-Host, VLAN-Konzept ohne konkrete interne IP-Pläne, welche Diensttypen laufen, welche Tools genutzt werden).
 - **Darf nicht rein:** konkrete IP-Adressen, WireGuard-Keys/Preshared-Keys, Passwörter, interne Hostnamen mit Rückschlussmöglichkeit, Backup-Ziele mit Zugangsdaten.
 
 Diese Regel gilt 1:1 auch für retro/smarthome, ist aber bei infra am relevantesten, weil dort die Rohdokumente (z. B. Heimnetzwerk-Final-v3.2, GL_Flint2_Final_v2) aktuell sehr konkret sind (u. a. reale IPs, WireGuard-Keys) und beim Übertragen aktiv gekürzt werden müssen.
 
-## 5. Bilder/Assets — final
+## 5. Bilder/Assets, final
 
 Alle Bilder bleiben **im GitHub-Repo** versioniert (kein separates Cloudflare R2/Images). Einfachster Weg, passt zum ohnehin geplanten Monorepo-Ansatz.
 
-## 6. DNS — bereits bei Cloudflare
+## 6. DNS, bereits bei Cloudflare
 
 Zone liegt schon bei Cloudflare, Pages-Anbindung ist damit ohne Zusatzschritt möglich. Offen bleibt nur, wohin die nackte Domain `moonweb.org` zeigt (siehe offene Frage 1 unten).
 
-## 7. Übersetzung, Last-Updated, Analytics, Perplexity-Rückkanal — final
+## 7. Übersetzung, Last-Updated, Analytics, Perplexity-Rückkanal, final
 
 - **Übersetzung:** einmaliger KI-gestützter Durchlauf pro Dokument bei der Migration, kein wiederkehrender Prozess.
-- **Last-Updated-Anzeige:** einfachste Lösung — im Zweifel **gar keine Anzeige**. Stattdessen soll der Anspruch sein, dass Inhalte grundsätzlich aktuell gehalten werden, statt ein Datum zu zeigen, das dann veraltet wirkt.
+- **Last-Updated-Anzeige:** einfachste Lösung, im Zweifel **gar keine Anzeige**. Stattdessen soll der Anspruch sein, dass Inhalte grundsätzlich aktuell gehalten werden, statt ein Datum zu zeigen, das dann veraltet wirkt.
 - **Analytics:** keine Statistik-Erfassung, weder Cloudflare Web Analytics noch anderes.
 - **Perplexity-Rückkanal:** zurückgestellt, wird später erneut betrachtet, keine Zeit jetzt investieren.
 
-## 8. Offene Kleinigkeiten — beantwortet
+## 8. Offene Kleinigkeiten, beantwortet
 
 Die vier ursprünglich offenen Punkte wurden inzwischen in SPEC.md/PLAN.md beantwortet:
 
@@ -60,7 +60,7 @@ Die vier ursprünglich offenen Punkte wurden inzwischen in SPEC.md/PLAN.md beant
 3. **Start-Reihenfolge:** Alle Sites gleichzeitig (PLAN.md §1: "launch simultaneously")
 4. **Platzhalter-Verhalten:** Keine Platzhalter, ehrliche kurze Seiten + WIP-Hinweise (SPEC.md §5, retro/ hat WIP-Badge)
 
-## 9. Gesamtstand — Konzept vollständig
+## 9. Gesamtstand, Konzept vollständig
 
 Alle Entscheidungsgrundlagen sind in SPEC.md (was) und PLAN.md (wie/wann) umgesetzt: