docs: Infrastrukturänderungen gehören ins Infrastruktur-Repo — und vorher
CI / TypeScript — type-check (push) Successful in 16s
CI / Publish — build & push image (push) Successful in 22s

Diese Anwendung teilt sich Netz, Datenbankcluster, öffentlichen Eingang und
Backup mit anderen Projekten. Wer dort etwas ändert, ändert es für alle, und
dem eigenen Repo sieht man es nicht an.

Die Regel steht vollständig in christianmanivong/infrastructure; hier nur der
Verweis, damit sie dort gelesen wird, wo gearbeitet wird.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-09-19 15:27:57 +02:00
co-authored by Claude Opus 5
parent 451a98c14a
commit 8aa158aa3b
+21
View File
@@ -18,6 +18,27 @@ Everything on the site should serve those three questions.
---
## Infrastruktur ändert man woanders — und vorher
Diese Anwendung läuft auf einer Infrastruktur, die sie sich mit anderen Projekten teilt:
Netz, Datenbankcluster, öffentlicher Eingang und Backup gehören keinem Projekt allein.
Dokumentiert ist sie in **`git.netork.io/christianmanivong/infrastructure`**, und dort
steht in `CLAUDE.md` auch die verbindliche Regel.
**Kurz: erst dort dokumentieren, ausdrücklich genehmigen lassen, dann ändern.** Nicht
umgekehrt, und „ja mach mal" zu einer früheren Frage deckt die nächste Änderung nicht mit
ab.
Betroffen ist alles, was über dieses Repo hinausreicht — Hosts, Netze, Firewall-Regeln,
der Patroni-Cluster samt `pg_hba` und DCS-Parametern, pgBackRest, BunkerWeb-Hosts, DNS,
CI-Runner, alles, was eine Anwendung auf den geteilten Datenbankcluster umzieht.
**Nicht** betroffen: Anwendungscode, Abhängigkeiten und Migrationen innerhalb der eigenen
Datenbank.
Der Grund für die Reihenfolge ist nicht Bürokratie. Die meisten Zwischenfälle dort waren
nicht falsche Werte, sondern richtige Werte in der falschen Reihenfolge — und das fällt
beim Aufschreiben auf, nicht beim Tippen. Im Zweifel dorthin.
## Content & Design Source of Truth
All product content (features, copy, page structure) is in `docs/`: