# 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