moonweb-site/DESIGN.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

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).
• Ü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).

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)

• /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

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

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:

• 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

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

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

• Ü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.
• 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

Die vier ursprünglich offenen Punkte wurden inzwischen in SPEC.md/PLAN.md beantwortet:

1. Apex-Domain-Routing: Bleibt bei www.moonweb.org Redirect (PLAN.md §3, Phase 4)
2. URL-Konvention: domain/slug/, kleinschreibung, Bindestriche (SPEC.md §4.3)
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

Alle Entscheidungsgrundlagen sind in SPEC.md (was) und PLAN.md (wie/wann) umgesetzt:

• Sitemap, Domain-Zwecke, Namensgebung
• Header-konsistent/Content-flexibel-Prinzip
• Detailtiefe pro Domain
• Redaktionsregel für sensible infra-Inhalte
• Monorepo-Struktur, Eleventy als SSG, GitHub Actions Build, Cloudflare Pages Deploy über 6 Projekte
• Sprache komplett Englisch
• Bilder im Repo, DNS bei Cloudflare, Übersetzung einmalig, keine Last-Updated-Anzeige, keine Analytics, Perplexity-Rückkanal zurückgestellt