Initial commit

CONTRIBUTING.md

@@ -0,0 +1,79 @@
+# Zu Gardomatic beitragen
+
+Vielen Dank für dein Interesse an Gardomatic. Beiträge sollen klein,
+nachvollziehbar und mit der bestehenden Architektur vereinbar sein.
+
+## Vor dem ersten Beitrag
+
+1. Lies die Projektbeschreibung und den Entwicklungsablauf in der
+   [`README.md`](README.md).
+2. Beachte die verbindlichen technischen Regeln in [`AGENTS.md`](AGENTS.md).
+3. Lies die [`Contributor License Agreement`](CLA.md). Sie ist eine rechtlich
+   bindende Vereinbarung.
+
+Mit der CLA behältst du das Copyright an deinem Beitrag. Du erlaubst Alexander
+Klein zugleich, den Beitrag innerhalb von Gardomatic unter der öffentlichen
+PolyForm-Lizenz sowie unter separaten kommerziellen oder proprietären Lizenzen zu
+verwenden. Das ermöglicht das in diesem Projekt vorgesehene Dual-Licensing-Modell.
+
+### CLA annehmen
+
+Einzelpersonen nehmen Version 1.0 der CLA an, indem sie einen Pull Request mit der
+unveränderten CLA-Erklärung aus der Pull-Request-Vorlage einreichen und die
+zugehörige Checkbox selbst markieren. Die Annahme gilt auch für spätere Beiträge
+unter derselben CLA-Version.
+
+Der Workflow `.github/workflows/cla.yml` prüft diese Erklärung bei jedem Pull
+Request. Ein fehlgeschlagener CLA-Check darf nicht umgangen oder administrativ als
+Ersatz für die Zustimmung der beitragenden Person bestätigt werden.
+
+Beiträge im Namen eines Unternehmens oder einer anderen Organisation müssen vorab
+mit `alex@kleiax.de` abgestimmt werden. Dasselbe gilt, wenn dein Arbeitgeber Rechte
+an deinem Beitrag besitzen könnte. Eine Projektperson darf die CLA-Erklärung nicht
+stellvertretend für Beitragende markieren.
+
+## Entwicklungsablauf
+
+1. Erstelle einen fokussierten Branch und beschreibe das zu lösende Problem.
+2. Suche vor der Implementierung nach vorhandenen Helfern und ähnlichen Abläufen.
+3. Halte die Schichtengrenzen zwischen API, Storage, Client und Web ein.
+4. Ergänze Tests für neues oder korrigiertes Verhalten, soweit technisch möglich.
+5. Formatiere geänderten Go-Code mit `gofmt`.
+6. Führe zunächst die betroffenen Tests und anschließend `go test ./...` aus.
+7. Führe bei größeren Änderungen zusätzlich `make audit` aus.
+8. Erläutere im Pull Request Verhalten, Motivation, Tests und mögliche Risiken.
+
+Für Datenbankänderungen ist ein neues Up-/Down-Migrationspaar erforderlich.
+Bereits veröffentlichte Migrationen dürfen nicht nachträglich verändert werden.
+
+## Pull Requests
+
+Ein Pull Request sollte:
+
+- genau ein zusammenhängendes Problem lösen,
+- keine unbeabsichtigten oder fachfremden Änderungen enthalten,
+- vorhandene Tests nicht abschwächen,
+- geändertes Nutzerverhalten und Konfiguration dokumentieren,
+- alle verwendeten Quellen und Fremdmaterialien mit ihrer Lizenz offenlegen und
+- die CLA-Erklärung enthalten.
+
+Ein Beitrag kann abgelehnt oder bis zur Klärung zurückgestellt werden. Das gilt
+insbesondere bei fehlender CLA-Annahme, unklaren Rechten, Sicherheitsproblemen,
+fehlenden Tests oder Änderungen außerhalb des vereinbarten Umfangs.
+
+## Fremdmaterial und KI-gestützte Beiträge
+
+Reiche nur Material ein, an dem du die erforderlichen Rechte besitzt. Kopiere
+keinen Code, keine Texte, Bilder oder anderen Inhalte aus inkompatibel lizenzierten
+Quellen. Kennzeichne Fremdmaterial und nenne Quelle sowie Lizenz.
+
+Für KI-gestützte Beiträge bleibst du selbst verantwortlich. Prüfe den erzeugten
+Inhalt auf Korrektheit, Sicherheit, Herkunft und mögliche Lizenzkonflikte, bevor du
+ihn einreichst.
+
+## Sicherheitsprobleme
+
+Noch nicht veröffentlichte Sicherheitslücken sollten nicht als öffentlicher Issue
+oder Pull Request eingereicht werden. Melde sie zunächst vertraulich an
+`alex@kleiax.de` und füge keine echten Zugangsdaten oder personenbezogenen Daten
+bei.