add logging and database migration

README.md

@@ -1,3 +1,151 @@
 # co_app
 
-Controlling-App
+## Insallation
+
+1. Git-Repository clonen
+2. 
+
+## Entwicklungs- und Produktionsumgebung steuern (APP_ENV)
+Die App unterscheidet zwischen Entwicklung und Produktion über die Umgebungsvariable APP_ENV.
+
+### Entwicklung (lokal)
+Im Terminal setzen:
+```bash
+export APP_ENV=dev
+```
+Die Variable gilt, solange das Terminal geöffnet ist.
+Beim Starten der App:
+```bash
+streamlit run app/main.py
+```
+Die App erkennt automatisch den Dev-Modus.
+
+### Produktion (Systemd-Dienst)
+
+Für den produktiven Betrieb setzt systemd die Variable dauerhaft auf prod:
+```ini
+Environment=APP_ENV=prod
+```
+In prod-Modus laufen z. B. Logging und Pfade anders als lokal.
+
+### systemd-Dienst einrichten
+``/etc/systemd/system/myapp.service``
+```ini
+[Unit]
+Description=MyApp Streamlit Service
+After=network.target
+
+[Service]
+User=co_app
+Group=co_app
+WorkingDirectory=/opt/co_app
+Environment=APP_ENV=prod
+ExecStart=/usr/bin/python3 -m streamlit run app/main.py --server.port=8501
+Restart=on-failure
+
+[Install]
+WantedBy=multi-user.target
+```
+**Installation & Start**
+```bash
+sudo systemctl daemon-reload
+sudo systemctl enable co_app.service
+sudo systemctl start co_app.service
+```
+**Logs ansehen**
+Da streamlit + python ins systemd-Journal loggen:
+```bash
+journalctl -u co_app.service -f
+```
+**Wichtig**
+- APP_ENV=dev → Entwicklung, lokale Logs, lokale DB
+- APP_ENV=prod → Systemd-Betrieb, serverseitige Pfade, Logging ins Journal
+- Die App liest die Variable mit:
+```python
+import os
+APP_ENV = os.environ.get("APP_ENV", "dev")
+```
+
+## Database Setup & Migration Guide
+
+Dieses Projekt verwendet SQLite für die interne App-Datenbank.
+Das Schema wird vollständig über SQL-Migrationsdateien verwaltet, die automatisch in der richtigen Reihenfolge ausgeführt werden.
+
+### Ordnerstruktur
+
+```bash
+data/             ← enthält die erzeugte SQLite-Datenbank (app.db)
+migrations/       ← enthält alle SQL-Migrationsdateien
+migrate.py        ← Python-Skript zum Anwenden der Migrationen
+```
+### Erstellen der Datenbank (Initial Setup)
+
+```bash
+python migrate.py
+```
+Das Skript:
+
+1. erstellt den Ordner db/ (falls nicht vorhanden)
+2. erzeugt eine neue Datei db/app.db
+3. führt alle SQL-Dateien im Ordner migrations/ der Reihe nach aus
+4. protokolliert die angewendeten Migrationen in der Tabelle schema_version
+
+Danach ist die Datenbank vollständig initialisiert und einsatzbereit.
+
+### Arbeiten mit Migrationen (Änderungen am Schema)
+
+Änderungen an der Datenbankstruktur werden nie direkt an der DB vorgenommen.
+Stattdessen erzeugst du eine neue Migrationsdatei im Ordner migrations/.
+
+**Beispiel: neue Spalte hinzufügen**
+
+Lege eine Datei an
+
+```bash
+touch /migrations/20250301_101500_add_last_login.sql
+```
+Dateiinhalt
+```sql
+BEGIN;
+
+ALTER TABLE users ADD COLUMN last_login DATETIME;
+
+INSERT INTO schema_version (version)
+VALUES ('20250301_101500_add_last_login');
+
+COMMIT;
+```
+Migration anwenden
+```bash
+python migrate.py
+```
+Das Skript erkennt automatisch, dass diese Migration neu ist und führt sie aus.
+
+### Erneutes Ausführen (Updates)
+Wenn eine bestehende Installation aktualisiert werden soll:
+```bash
+git pull
+python migrate.py
+```
+Das Skript:
+
+- liest die Tabelle schema_version
+- führt nur Migrationen aus, die noch nicht angewendet wurden
+
+Bestehende Strukturen bleiben unberührt.
+
+### Entwicklungsphase: Hinweise
+
+Solange das Projekt noch nicht produktiv genutzt wird, gilt:
+- du kannst Migrationsdateien löschen/zusammenführen
+- du kannst die komplette app.db jederzeit löschen
+- vor dem ersten echten Deploy kannst du alle Migrationen zu einer sauberen initial.sql zusammenfassen
+
+👉 **Nach dem ersten produktiven Einsatz** werden Migrationen nie mehr gelöscht, sondern nur ergänzt.
+
+### Optional: DB neu erzeugen für Tests
+Um eine frische Datenbank zu bekommen:
+```bash
+rm -f data/app.db
+python migrate.py
+```