Bauen über Gitea Actions in die Roadmap aufnehmen

Fehlte in Phase 4: das Image soll wie bei der Kantone-App über einen
Versions-Tag gebaut, vor dem Veröffentlichen getestet und in die Gitea-
Registry gestellt werden.

Der Plan hält dazu die Punkte fest, die dort nachträglich korrigiert werden
mussten - vor allem, Werte aus ${{ ... }} nicht direkt in die Shell zu
schreiben, weil Tag-Namen Sonderzeichen enthalten dürfen und der Job ein
Registry-Token hält.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GR4bNaj9GtRu57J4Niii8o

Plan.md

@@ -200,8 +200,43 @@ Die Phasen aus `projekt.md`, ergänzt um Tests und die Absicherung.
 **Phase 5 – Betrieb**
 - `Dockerfile` (Tailwind-Build inbegriffen), `docker-compose.yml`, Volumes
 - Healthcheck, Backup-Hinweise für Datenbank und Bilder
+- **Gitea Actions**: Image bauen und in die Registry stellen (siehe unten)
+- Zwei Compose-Dateien wie bei der Kantone-App: eine zum Selberbauen aus dem
+  Quellcode, eine zum blossen Starten des fertigen Images
 - README für Einrichtung und Reverse-Proxy
 
+### Bauen über Gitea Actions
+
+Gleiches Vorgehen wie bei der Kantone-App
+(`.gitea/workflows/docker-image.yml` dort als Vorlage):
+
+- **Auslöser:** nur ein Versions-Tag (`v*`) oder ein manueller Start
+  (`workflow_dispatch`) – **nicht** jeder Push auf `main`. Dadurch bleibt das
+  Zusammenführen von Branches folgenlos, und ein Release ist ein bewusster
+  Schritt.
+- **Registry:** `gitea.boing86.myds.me`, Image `docker/kleiderboerse`.
+- **Version:** aus dem Tag (`v1.2.3` → `1.2.3`), bei manuellen Läufen ein
+  Zeitstempel. Tag und Commit werden als Build-Argumente durchgereicht und in
+  der Fusszeile angezeigt – so ist sofort erkennbar, welcher Stand läuft.
+- **Test vor der Veröffentlichung:** Container starten und prüfen, bevor
+  irgendetwas in die Registry geht. Bei der Kantone-App wird die API auf
+  26 Kantone geprüft; hier wären die Entsprechungen: Startseite antwortet mit
+  200, `/api/v1/categories` liefert die vorbefüllten Kategorien, und ein
+  Testupload wird tatsächlich als WebP abgelegt. Schlägt das fehl, wird nichts
+  veröffentlicht.
+- **`latest`** nur für echte Versions-Tags, nicht für manuelle Läufe.
+- **Anmeldung** über `--password-stdin` (das Token taucht so weder in der
+  Prozessliste noch im Protokoll auf), `docker logout` mit `if: always()`.
+  Zugangsdaten als Repo-Secrets (`REGISTRY_TOKEN`, `REGISTRY_USER`), nicht im
+  Workflow.
+- **Rechte** im Job auf `contents: read` und `packages: write` begrenzen.
+- **Werte aus `${{ ... }}` nie direkt in die Shell schreiben**, sondern über
+  `env:` durchreichen. Ausdrücke werden vor der Shell ersetzt, und Tag-Namen
+  dürfen Zeichen wie `"` oder `$` enthalten – sonst lässt sich über einen
+  präparierten Tag Code auf dem Runner ausführen, in einem Job, der ein
+  Registry-Token hält. (Genau das wurde in der Kantone-App nachträglich
+  korrigiert.)
+
 ---
 
 ## Offene Punkte

projekt.md

@@ -127,3 +127,7 @@ kinderkleider-app/
 - [ ] **Phase 4: Containerisierung & Deployment**
   - [ ] `Dockerfile` & `docker-compose.yml` schreiben
   - [ ] Persistence per Volume-Mount für Datenbank & Bild-Uploads
+  - [ ] Gitea Actions: Image bei einem Versions-Tag (`v*`) bauen, testen und in
+        die Registry stellen — gleiches Vorgehen wie bei der Kantone-App
+        (`.gitea/workflows/docker-image.yml` dort als Vorlage)
+  - [ ] Zweite Compose-Datei zum Starten des fertigen Images (ohne Quellcode)