chore: establish workflow rules, versioning and changelog

Add mandatory workflow rules (branching, versioning, docs-sync),
introduce CHANGELOG.md and VERSION file, update development
standards and CLAUDE.md accordingly.

Version: 0.1.1

CHANGELOG.md

@@ -0,0 +1,25 @@
+# Changelog
+
+Alle wesentlichen Änderungen am Projekt werden hier dokumentiert.
+Format: `[MAJOR.MINOR.PATCH] - YYYY-MM-DD`
+
+---
+
+## [0.1.1] - 2026-04-05
+
+### Changed
+- Entwicklungsstandards um Branching-Regeln, Versionierungsschema und Workflow-Regeln erweitert
+
+### Added
+- CHANGELOG.md eingeführt
+- VERSION-Datei eingeführt
+
+---
+
+## [0.1.0] - 2026-04-05
+
+### Added
+- CLAUDE.md – Guidance für Claude Code
+- docs/development-standards.md – allgemeine Entwicklungsstandards
+- docs/project-structure.md – Projektstruktur und Domänenmodell
+- docs/branching-strategy.md – Branching-Strategie

CLAUDE.md

@@ -10,8 +10,11 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 
 | Dokument | Inhalt |
 |---|---|
-| [docs/development-standards.md](docs/development-standards.md) | Allgemeine Entwicklungsstandards (Coding Style, Git, Testing) |
+| [docs/development-standards.md](docs/development-standards.md) | Entwicklungsstandards, Branching-Regeln, Versionierung, Workflow |
-| [docs/project-structure.md](docs/project-structure.md) | Projektstruktur und Architekturübersicht |
+| [docs/project-structure.md](docs/project-structure.md) | Projektstruktur, Module, Funktionsübersicht |
+| [docs/branching-strategy.md](docs/branching-strategy.md) | Branching-Diagramm |
+| [CHANGELOG.md](CHANGELOG.md) | Versionshistorie |
+| [VERSION](VERSION) | Aktuelle Versionsnummer |
 
 ## Techstack
 
@@ -41,6 +44,15 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 # <build-command>
 ```
 
+## Pflichtregeln (immer befolgen)
+
+1. **Nie direkt nach `main` pushen/mergen** – ausschließlich per Pull-Request, und nur auf explizite Anweisung.
+2. **Branching:** Jede Arbeit in einem `feature/` oder `fix/` Branch unter `develop`. Erst nach dev mergen, wenn alles fertig und alle Tests grün sind.
+3. **Nach jeder Änderung:** Versionsnummer erhöhen (`VERSION` + `CHANGELOG.md`), committen und pushen.
+4. **Vor Merge nach dev / PR nach main:** README.md, CHANGELOG.md und docs/ prüfen und aktualisieren.
+5. **Projektstruktur-Doku** (`docs/project-structure.md`) bei jeder Funktions-/Moduländerung synchron halten.
+6. **Versionierung:** `MAJOR.MINOR.PATCH` – MAJOR nur auf Anweisung, MINOR bei Features, PATCH bei Fixes/Kleinänderungen.
+
 ## Wichtige Konventionen
 
 - Sprache: Deutsch für Domänenkonzepte (Pflanzen, Beet, Aussaat …), Englisch für Code-Bezeichner und Commit-Messages

VERSION

@@ -0,0 +1 @@
+0.1.1

docs/development-standards.md

@@ -13,17 +13,26 @@ Allgemein gültige Standards für die Arbeit in diesem Repository.
 
 ---
 
-## Git
+## Git & Branching
 
-### Branching
+### Struktur
 
 ```
-main          – stabiler Produktionsstand
+main
-feature/<name> – neue Features
+└── develop
-fix/<name>     – Bugfixes
+    ├── feature/<name>   – neue Features
-chore/<name>   – Wartung, Abhängigkeiten, Konfiguration
+    ├── fix/<name>       – Bugfixes / kleine Fixes
+    └── debug/<name>     – Debugging / Fehleranalyse
 ```
 
+### Regeln
+
+1. **Nie direkt nach `main` pushen oder mergen.** Änderungen in `main` kommen ausschließlich über eine Pull-Request aus `develop`.
+2. Jede Änderung findet in einem eigenen `feature/` oder `fix/` Branch unterhalb von `develop` statt.
+3. In `develop` mergen erst, wenn die Arbeit abgeschlossen ist und alle Tests erfolgreich waren.
+4. Eine PR nach `main` wird nur auf explizite Anweisung des Nutzers geöffnet.
+5. Vor jedem Merge nach `develop` und vor jeder PR nach `main` werden alle wesentlichen Dokumente (README.md, CHANGELOG.md, docs/) geprüft und ggf. aktualisiert.
+
 ### Commit-Messages
 
 Format: `<type>: <short description>` (max. 72 Zeichen)
@@ -37,7 +46,31 @@ Format: `<type>: <short description>` (max. 72 Zeichen)
 | `docs` | Nur Dokumentation |
 | `chore` | Build, Dependencies, Konfiguration |
 
-Beispiel: `feat: add watering schedule to plant detail view`
+**Nach jedem Commit wird sofort gepusht.**
+
+---
+
+## Versionierung
+
+Schema: `MAJOR.MINOR.PATCH`
+
+| Teil | Bedeutung | Wechsel |
+|---|---|---|
+| `MAJOR` | Hauptrelease | Nur auf explizite Anweisung des Nutzers |
+| `MINOR` | Größere Updates, neue Features | Bei jeder Feature-Erweiterung oder größerem Umbau |
+| `PATCH` | Kleine Fixes, Minimalkorrekturen | Bei Bugfixes, kleinen Ergänzungen, Mini-Umbauten |
+
+- Die aktuelle Version steht in [CHANGELOG.md](../CHANGELOG.md) und in der Datei `VERSION`
+- Nach **jeder** Änderung wird die Versionsnummer eigenständig erhöht und in beiden Dateien notiert
+- Die Versionsnummer wird im Commit-Message-Footer vermerkt: `Version: x.y.z`
+
+---
+
+## Projektstruktur-Dokumentation
+
+- Alle Funktionen/Module werden kurz in [docs/project-structure.md](project-structure.md) dokumentiert
+- Ziel: Token-Effizienz in zukünftigen Conversations – nicht alles neu einlesen müssen
+- Bei jeder Änderung an Funktionen/Modulen wird die Dokumentation synchron aktualisiert
 
 ---
 
@@ -56,6 +89,7 @@ Beispiel: `feat: add watering schedule to plant detail view`
 - Integrationstests an Systemgrenzen (API, Datenbank)
 - Keine Mocks für die Datenbank in Integrationstests
 - Testdatei liegt neben der zu testenden Datei oder in einem `__tests__`/`tests`-Verzeichnis auf gleicher Ebene
+- **In `develop` wird erst gemergt, wenn alle Tests grün sind**
 
 ---