Starten Sie von definierter Architektur, nicht von einem leeren Repository.

Architektur im Überblick

Vier Stufen mit einer einseitigen Abhängigkeitsrichtung. Die beiden mittleren sind die Grundlage; die erste und die letzte gehören Ihnen.

1. Stage 1

   Website-Daten, Inhalte und Assets

   Identität, Navigation, Sprachen, Markdown-Inhalte und Grafiken — die adoptereigenen Eingaben, validiert bevor irgendetwas sie liest.

2. Stage 2

   Von Foundation abgeleitete Laufzeit

   Framework-unabhängige Domänenkonzepte plus die Anwendungsdienste, die sie orchestrieren, ohne eigene Framework-Importe.

3. Stage 3

   Darstellung, Routing und Integrations-Schnittstellen

   Routen, Layout-Komposition, Metadaten und die Adapter-Fabriken, die Buchung, Anfragen, Karten und Analyse aus der Konfiguration binden.

4. Stage 4

   Deployment

   Ein primär statisch generierter Build, bereitgestellt aus Ihrem eigenen Repository auf Ihr eigenes Hosting-Konto.

Die Abhängigkeitsrichtung wird durch Tests abgesichert statt angenommen: Der Kern darf React, Next.js oder eine äußere Schicht nicht importieren, und die Anwendungsschicht darf nicht in einen konkreten Adapter greifen.

ARCHITECTURE.md im Repository

Konfigurieren oder programmieren

Diese Grenze ist der Kern des Projekts. Die meisten unternehmensspezifischen Entscheidungen sind Daten; echte Erweiterungen sind Code — und Foundation sagt ausdrücklich, was was ist.

Der Engineering-Vertrag

Woran sich das Projekt selbst bindet — und was es nicht behauptet.

• Strikt validierte Konfiguration

  Ein Schema, unbekannte Schlüssel werden abgelehnt, umsetzbare Fehlermeldungen, und die Konfiguration ist nur über den Loader lesbar.

• Hexagonale Grenzen

  Ein reiner Kern, Anwendungs-Ports und -Dienste, Adapter hinter Fabriken und dünne Framework-Routen.

• Durchsetzung der Abhängigkeiten

  Architekturtests durchlaufen den Quellbaum und schlagen bei einem verbotenen Import fehl, sodass das Diagramm nicht vom Code abweichen kann.

• Server-first-Komposition

  React Server Components und statische Generierung als Standard, mit Client-Interaktivität nur in den Komponenten, die sie brauchen.

• Verifikation im echten Browser

  Eine festgeschriebene Headless-Browser-Matrix prüft Desktop-, Tablet- und Mobilbreiten, Tastatur- und Zeigerinteraktion, reduzierte Bewegung und dunkles Schema — und lässt den Lauf bei jedem Fehlschlag scheitern.

• Architektur- und Unit-Gates

  Grenz- und Unit-Tests laufen neben Assets-Prüfung, Typprüfung, Lint und Produktions-Build.

• Disziplin bei Fähigkeitsaussagen

  Dokumentierte Fähigkeitsaussagen werden gegen die eigene Aufzeichnung des Projekts geprüft, sodass eine Aussage nicht über ihre Belege hinaus angehoben werden kann.

• Ein ehrliches Upgrade-Modell

  Weil Konfiguration, Inhalte und Assets außerhalb des Anwendungskerns liegen, können Plattformverbesserungen übernommen werden, statt Ihre Arbeit zu überschreiben.

Wo Foundation endet

Dieselbe Eigentumsaufteilung, technisch formuliert. Foundation endet bewusst vor der betrieblichen Komplexität und stellt die Schnittstelle zu dem Dienst bereit, den Sie wählen.

Erweiterung funktioniert von außen nach innen: Ein neuer Anbieter ist ein Adapter plus ein Fabrikzweig und ein Schema-Aufzählungseintrag, und ein neuer Inhaltstyp oder eine Sprache sind Daten. Eine wirklich neue Fähigkeit ist Plattformarbeit.

Ablauf der Adoption

Acht Stufen. Die Details auf Befehlsebene liegen im Repository — das hier ist die Form der Arbeit.

1. 1

   Foundation beschaffen

   Klonen oder forken Sie das öffentliche Repository.

2. 2

   Installieren und starten

   Installieren Sie die Abhängigkeiten und starten Sie die Website lokal.

3. 3

   Konfigurieren

   Legen Sie Identität, Sprachen, Funktionen und Anbieterwahl fest.

4. 4

   Inhalte und Assets verfassen

   Schreiben Sie Ihre Seiten und ersetzen Sie die Marken-Asset-Rollen.

5. 5

   Anbieter verbinden

   Richten Sie die Schnittstellen auf die Dienste aus, die Sie tatsächlich nutzen.

6. 6

   Validieren

   Führen Sie das eigene Gate des Projekts lokal aus.

7. 7

   Bereitstellen

   Bauen und stellen Sie aus Ihrem eigenen Repository und Konto bereit.

8. 8

   Pflegen und aktualisieren

   Übernehmen Sie Verbesserungen aus dem Upstream, ohne Ihr Material zu überschreiben.

Die Handbücher im Repository behandeln jede Stufe, einschließlich der Fehlerbehebung.

Maßgebliche Dokumentation

GitHub ist die kanonische technische Quelle. Diese Website fasst zusammen; das Repository unterweist.

• Repository

  Der vollständige Quellcode, seine Lizenz und die eigene Aussage des Projekts, was es ist und was nicht.

• README.md

  Was das Projekt ist, Schnellstart, Aufbau des Repositorys und die Lizenzsituation.

• ARCHITECTURE.md

  Architekturstil, Grenzen, Abhängigkeitsrichtung und Integrationsmuster.

• CUSTOMIZING.md

  Der Leitfaden für Anwender und die vollständige Konfigurationsreferenz.

• DEPLOYMENT.md

  Das Runbook für den Start und die Checkliste zur Verifikation nach dem Deployment.

• BRAND_ASSETS.md

  Der Vertrag zum Austausch von Marken-Assets: jede austauschbare Grafikrolle.

• Handbücher

  Verfahren zu Adoption, Anpassung, Branding, Inhalten, Upgrade, Validierung, Deployment und Fehlerbehebung.

Jedes Ziel oben ist ein Link in das öffentliche Repository, in dem diese Dokumente gepflegt werden.