Kairo-Jinkendo/.cursor/rules/kairo-deployment-testing.mdc

---
description: Deployment und Tests — kein lokaler Lauf; Verifikation über develop auf Raspberry
alwaysApply: true
---

# Kairo — Deployment & Tests

## Kein lokaler Test-/DB-Lauf

Backend-Tests (pytest), Migrationen und Integrationstests **können auf der Entwicklungsmaschine in der Regel nicht ausgeführt werden** — PostgreSQL/Docker ist lokal oft nicht verfügbar.

Versuche nicht wiederholt, lokale pytest-/Migration-Läufe als Abnahme zu erzwingen, wenn die DB nicht erreichbar ist.

## Verifikation über Remote-Deploy

Praktische Verifikation erfolgt durch **Deployment auf ein entferntes System (Raspberry Pi)**:

1. Änderungen **committen** und auf Branch **`develop`** pushen
2. Deployment wird dadurch ausgelöst (CI/Deploy-Pipeline auf dem Raspberry)
3. Dort laufen Migrationen, Backend-Tests und Smoke-Checks gegen echte Infrastruktur

**Dev-Instanz (kein localhost):** [https://dev.kairo.jinkendo.de](https://dev.kairo.jinkendo.de)  
Schnellcheck: `GET https://dev.kairo.jinkendo.de/api/health` (Version + DB).

**Gitea Actions** (Test-Suite läuft nach Deploy automatisch):

- Übersicht: `http://192.168.2.144:3000/Lars/Kairo-Jinkendo/actions`
- Workflows: `deploy-dev.yml` (Deploy), `test.yml` (pytest, lint, k6, Playwright)
- Filter z. B. `?workflow=test.yml` oder `?workflow=deploy-dev.yml`
- Run-Detail: `/Lars/Kairo-Jinkendo/actions/runs/{id}`

Nach Push auf `develop`: Deploy-Run grün → Health auf Dev → Test-Suite in Gitea Actions prüfen.

## Konsequenz für Agenten

- Code und Tests **schreiben** und dokumentieren — aber fehlende lokale DB nicht als Implementierungsblocker behandeln
- Frontend: `npm test` / `vite build` lokal weiterhin sinnvoll, wenn Node verfügbar
- Backend: Abnahme über Gitea Actions (`test.yml`) + Dev-Health — nicht lokales pytest erzwingen
- Funktionale Checks gegen **https://dev.kairo.jinkendo.de**, nicht localhost
- **Nicht** proaktiv committen/pushen, es sei denn, der Nutzer bittet explizit darum