Initial commit

doc/cli.md

@@ -0,0 +1,87 @@
+# Gardomatic administration CLI
+
+The CLI connects directly to PostgreSQL and is implemented in `cmd/cli`.
+
+## Configuration
+
+`GARDOMATIC_DB_DSN` is required for every database command. The following
+variables are optional:
+
+| Variable | Default | Purpose |
+| --- | --- | --- |
+| `GARDOMATIC_ENV` | `development` | Enables confirmations for risky production operations |
+| `GARDOMATIC_WEB_BASE_URL` | `http://localhost:4040` | Base URL for activation links |
+| `GARDOMATIC_SMTP_MODE` | `file` | Mail delivery mode (`file` or `smtp`) |
+| `GARDOMATIC_SMTP_HOST` | empty | SMTP server hostname |
+| `GARDOMATIC_SMTP_PORT` | `25` | SMTP server port |
+| `GARDOMATIC_SMTP_USERNAME` | empty | SMTP username |
+| `GARDOMATIC_SMTP_PASSWORD` | empty | SMTP password |
+| `GARDOMATIC_SMTP_SENDER` | `gardomatic@localhost` | Sender address |
+| `GARDOMATIC_SMTP_FILE_PATH` | `/tmp/gardomatic-mails.log` | Development mail output |
+
+Global flags can override the DSN, environment, and public URL. Global flags
+must appear before the command. Use `--json` for machine-readable output and
+`--yes` to confirm an explicitly configured production operation.
+
+## Examples
+
+Create an invited user and print a generated initial password:
+
+```sh
+go run ./cmd/cli users create \
+    --name "Alice Example" \
+    --email alice@example.com \
+    --invite \
+    --generate-password
+```
+
+Create the initial active application administrator atomically:
+
+```sh
+go run ./cmd/cli users create \
+    --name "Initial Admin" \
+    --email admin@example.com \
+    --role application:admin \
+    --active \
+    --generate-password
+```
+
+Create an active development user and read the password without exposing it in
+the process list:
+
+```sh
+printf '%s\n' 'correct horse battery staple' | \
+    go run ./cmd/cli users create \
+        --name "Development User" \
+        --email dev@example.com \
+        --active \
+        --password-stdin
+```
+
+Without `--password-stdin` or `--generate-password`, the CLI securely prompts
+for the password twice. An invitation is printed by default; add `--send-email`
+to deliver it using the configured mail backend.
+
+Other common operations:
+
+```sh
+go run ./cmd/cli users list
+go run ./cmd/cli users show --email alice@example.com
+go run ./cmd/cli users invite --email alice@example.com --send-email
+go run ./cmd/cli users activate --email alice@example.com
+go run ./cmd/cli users deactivate --email alice@example.com
+go run ./cmd/cli users reset-password --email alice@example.com --generate-password
+go run ./cmd/cli users set-role --email alice@example.com --role application:admin
+go run ./cmd/cli gardens add-user --garden-id 3 --email alice@example.com --role admin
+go run ./cmd/cli db ping
+```
+
+`users create` requires exactly one of `--active` and `--invite` and accepts
+`application:user` or `application:admin` as `--role`. User creation, its role,
+and its activation token are committed in one database transaction. Password
+reset invalidates existing bearer and password reset tokens. The CLI never
+accepts passwords as command-line arguments.
+
+Application roles (`application:user`, `application:admin`) are independent of
+garden roles (`owner`, `admin`, `member`, `viewer`, `worker`). `gardens add-user`
+uses `member` when `--role` is omitted.

doc/ideen.md

@@ -0,0 +1,28 @@
+# Muss
+- Während man in den Admineinstellungen ist, soll der aktuelle Garten beibehalten werden
+
+# Demnächst und konkret
+- Garten bearbeiten soll auch mit dem Menü Links ausgestattet werden
+- Link auf git und kleiax.de
+- Seite mit Informationen zu Server Version etc Serverzeit
+- Die Instanzrolle brauchen noch eine Berechtigung, ob Gärten angelegt werden dürfen
+
+# Vielleicht 
+- Detailansicht und Bearbeitenansicht trennen?
+- Impressum
+
+# Unklar
+- pickieren? zwischen aufgabe und in stammdaten entscheiden
+
+# Später
+- Import von Pflanzen-Details z.B Pflanzmich.de und Naturadatenbank
+- Bewässerung direkt an die Orte binden
+    - Auflösen welche Pflanzen dadurch automatisch bewässert werden
+    - Zapfstellen könnten auch ein Ort sein
+- Datenschutz seite
+
+# Refactoring
+- Alle Migrationen für die v1.0 zusammenfassen
+- Module prüfen auf logisch Trennung, welche Module wären wiederverwendbar? Mailer ist ein schwieriger Fall, weil spezifische templates drin sind.
+- neues Repo für v1.0
+- gesamtes projekt dokumentieren

doc/notes.md

@@ -0,0 +1,5 @@
+#Migrate
+migrate -path=./internal/storage/postgres/migrations -database=postgres://gardomatic:pa55word@localhost/gardomatic?sslmode=disable up
+migrate -path=./internal/storage/postgres/migrations -database=postgres://gardomatic:pa55word@localhost/gardomatic?sslmode=disable force 1
+authentication -> Wer ist es?
+authorization  -> Darf er das?

doc/planung.md

@@ -0,0 +1,121 @@
+# Gardomatic — Projektbeschreibung und Fahrplan
+
+*Planungsstand: 01.09.2026*
+
+## Projektbeschreibung
+
+Gardomatic ist eine mobile, mehrbenutzerfähige Webanwendung zur Organisation von
+Gärten. Nutzer verwalten Gärten, Arten und Sorten, konkrete Pflanzen, Pflanzorte und
+anstehende Arbeiten. Artenbezogene Aufgabenvorlagen erzeugen passend zum Kalender,
+zum Pflanzdatum oder zur letzten Erledigung automatisch konkrete Aufgaben. Ein Garten
+bildet dabei einen abgeschlossenen Daten- und Berechtigungsraum.
+
+Die Anwendung besteht aus einer JSON-API und einem serverseitig gerenderten
+Web-Client in Go. PostgreSQL ist die einzige unterstützte Datenbank. Das Frontend
+ist mobile-first, funktioniert in den wesentlichen Abläufen ohne JavaScript und
+nutzt htmx für komfortable Teilaktualisierungen. Die installierbare PWA bietet eine
+Offline-App-Shell; die eigentlichen Gartendaten bleiben serverseitig geführt.
+
+Gardomatic richtet sich an Einzelpersonen und kleine Gruppen, die einen oder mehrere
+Gärten gemeinsam pflegen. Zeitfenster statt starrer Einzeltermine bilden
+gärtnerische Arbeiten realistisch ab. Rollen, Einladungen und konsequente
+Gartenisolierung ermöglichen eine sichere Zusammenarbeit.
+
+## Verbindliche Leitplanken
+
+- Go mit `internal/`-Layout und getrennten Binaries für API, Web und Administration.
+- PostgreSQL 16 mit `database/sql`, `lib/pq` und versionierten SQL-Migrationen.
+- Garten-ID im Pfad (`/v1/gardens/{gardenID}/...` und `/g/{gardenID}/...`).
+- Fremde Garten-IDs liefern 404; unzulässige Aktionen innerhalb eines sichtbaren
+  Gartens liefern 403.
+- Gartenrollen sind `owner`, `admin`, `member` und `viewer`.
+- Artenstammdaten und konkrete Pflanzen bleiben getrennt; Pflanzen dürfen ohne Art
+  angelegt werden.
+- Aufgaben verwenden Fälligkeitsfenster. Wiederkehrende Zeiträume dürfen den
+  Jahreswechsel überspannen.
+- Aus Vorlagen erzeugte Aufgaben bleiben idempotent. Ein separater Scheduler wird
+  erst bei nachgewiesenem Bedarf eingeführt.
+- Authentifizierung und Autorisierung liegen in der API. Das Web reicht nur das
+  Session-Cookie über einen request-spezifischen API-Client weiter.
+- Neue Facharbeit wird als vollständiger Vertical Slice aus Migration, Storage,
+  API, Client, Web und Tests umgesetzt.
+
+## Weiterer Fahrplan
+
+### 1. Kalenderbereitstellung über CalDAV
+
+**Ziel:** Anstehende Aufgaben können in vorhandenen Kalender- und
+Aufgabenanwendungen abonniert werden.
+
+Vorgeschlagene Umsetzung:
+
+1. Zuerst einen technischen Prototyp mit einer nur lesbaren Collection pro Nutzer
+   und Garten erstellen. Die Collection erhält stabile Ressourcen-IDs, ETags und
+   separat widerrufbare Zugangsdaten.
+2. Aufgaben als `VTODO` abbilden: Titel, Beschreibung, Fälligkeitsfenster,
+   Priorität, Status sowie Pflanzen- und Ortsbezug. Gartenrollen begrenzen auch hier
+   die sichtbaren Daten.
+3. Optional eine schreibgeschützte `VEVENT`-Ansicht für Clients ergänzen, die
+   `VTODO` nicht sinnvoll darstellen. Mehrtägige Fälligkeitsfenster bleiben dabei
+   als Zeiträume erkennbar.
+4. Einrichtung und Widerruf im Benutzerkonto ergänzen und mindestens mit DAVx⁵,
+   Apple Kalender/Erinnerungen und Thunderbird prüfen.
+5. Schreibzugriffe bewusst zurückstellen, bis Konfliktauflösung, Optimistic
+   Locking, Zeitzonen und die Semantik externer Erledigungen festgelegt sind.
+
+**Abnahmekriterien:** Eine gartenbezogene, nur lesbare Collection lässt sich in
+mindestens zwei unterstützten Clients einrichten; Änderungen erscheinen nach der
+Synchronisation; widerrufene Zugänge und Zugriffe auf fremde Gärten funktionieren
+nicht.
+
+### 2. Erstes Erweiterungsmodul: Bewässerung
+
+**Ziel:** Den modularen Ausbau mit einem klar abgegrenzten Anwendungsfall erproben.
+
+Vorgeschlagener Umfang:
+
+1. Bewässerungszonen und deren Zuordnung zu vorhandenen Orten modellieren.
+2. Manuelle Laufzeiten sowie einfache, ausführbare Zeitprogramme bereitstellen.
+3. Tabellen mit `mod_irrigation_` benennen und Routen, Migrationen und
+   Berechtigungsprüfungen vom Kern abgrenzen.
+4. Maximale Laufzeit, konkurrierende Programme und Verhalten bei fehlender
+   Geräteverbindung definieren, bevor reale Ventile angesteuert werden.
+5. Hardware-Anbindung und Wetterautomatik erst nach einer nutzbaren manuellen
+   Planung auswählen. Ein allgemeines Modul-Interface erst einführen, wenn ein
+   zweites Modul tatsächlich gemeinsame Hooks benötigt.
+
+**Abnahmekriterien:** Das Modul kann deaktiviert werden, ohne Kernfunktionen zu
+beeinträchtigen; Planung und manuelle Ausführung sind nutzbar; Sicherheitsgrenzen
+sind automatisiert getestet.
+
+### 3. Aufgabenhistorie und Auswertung
+
+**Ziel:** Wiederkehrende Gartenarbeit später auswertbar machen, ohne den aktuellen
+Aufgabenablauf unnötig zu verkomplizieren.
+
+Vorgeschlagene Umsetzung:
+
+1. Vorab entscheiden, welche Fragen beantwortet werden sollen, beispielsweise
+   Erledigungen pro Zeitraum, Pflanze oder Ort.
+2. Erst danach ein append-only Ereignismodell für Erledigen, Wiederöffnen und
+   Terminänderungen entwerfen.
+3. Einen kompakten Export und wenige zielgerichtete Auswertungen vor komplexen
+   Dashboards priorisieren.
+
+**Abnahmekriterien:** Historische Daten verändern den aktuellen Aufgabenstatus nicht
+und bleiben gartenisoliert; die gewählten Auswertungen sind durch reale
+Nutzerfragen begründet.
+
+## Empfohlene Reihenfolge
+
+1. Als nächstes den lesenden CalDAV-Prototypen umsetzen und früh mit realen Clients
+   testen. Das reduziert das größte technische Kompatibilitätsrisiko.
+2. Danach den CalDAV-Zugang im Benutzerkonto produktionsreif machen und
+   dokumentieren.
+3. Anschließend das Bewässerungsmodul zunächst ohne Hardwareintegration liefern.
+4. Aufgabenhistorie und Reporting erst beginnen, wenn konkrete Auswertungsfragen
+   gesammelt wurden.
+
+Bidirektionales CalDAV, herstellerspezifische Bewässerungshardware und eine
+allgemeine Plugin-Architektur sind ausdrücklich keine Bestandteile der jeweils
+ersten Ausbaustufe.