# AP0.1 – Abschlussbericht Projektgrundlage

**Status:** abgeschlossen  
**Stand:** 2026-07-04  
**Branch:** `develop` (`b5efdbb`) · Prod-Stand identisch (`main` `7b96bab`)

---

## Umgesetzt

| Anforderung (AP0.1) | Umsetzung |
|---------------------|-----------|
| Backend-Skeleton + FastAPI | `backend/main.py`, `backend/Dockerfile` |
| Health Endpoint `GET /api/health` | Liefert `status`, `app`, `db` (+ `version`, `schema`) |
| PostgreSQL-Anbindung | `backend/db.py`, Compose-Services |
| Docker Compose lokal | `docker-compose.dev-env.yml`, `docker-compose.yml` |
| Migrationsverzeichnis | `backend/migrations/` |
| Migration Runner + `schema_migrations` | `backend/run_migrations.py` |
| Erste Migration `001_init_core.sql` | `kairo_app_meta` (Schema-Phase AP0.1) |
| Testbasis | `backend/tests/` (pytest) |
| Frontend optional minimal | React/Vite-SPA + nginx-Proxy (`frontend/`) |
| Verzeichnisse `infra/`, `scripts/`, `tests/` | vorhanden |
| README „Local Development“ | `README.md` § Local Development |
| Kein Sprint-1-Fachscope | Keine Tenant/User/Actor-Logik, nur Meta-Tabelle |

**Zusätzlich (über AP0.1-Minimum, bewusst Sprint-0-Infrastruktur):**

- Gitea Actions: `deploy-dev.yml`, `deploy-prod.yml`, `test.yml`
- CI: pytest im Container, compose-smoke (PR), k6-Baseline, Playwright smoke
- Deployment-Doku: `docs/DEPLOYMENT.md`
- Dev/Prod auf Raspberry Pi (Ports 8097/3097 bzw. 8004/3004)

---

## Tests

### Unit / Integration (pytest)

| Test | Datei | Status |
|------|-------|--------|
| App importierbar | `test_health.py::test_app_importable` | ✓ |
| Health Endpoint | `test_health.py::test_health_endpoint` | ✓ |
| Runner findet Migrationen | `test_migrations.py::test_migration_runner_finds_migrations` | ✓ |
| Runner trägt Migration ein + idempotent | `test_migrations.py::test_migration_runner_is_idempotent` | ✓ |
| Core-Tabelle existiert | `test_migrations.py::test_core_table_exists` | ✓ |

### CI (Self-hosted Runner, Dev)

| Job | Status (2026-07-04) |
|-----|---------------------|
| pytest-backend | ✓ |
| k6 /api/health Baseline | ✓ (nach K6_CI-Anpassung) |
| playwright-smoke | ✓ |
| lint-backend | ✓ |
| compose-smoke | ✓ (PR, isolierte CI-Ports) |

### Prod

| Schritt | Status |
|---------|--------|
| Deploy Production (manueller Merge `develop` → `main`) | ✓ |
| Test Suite Prod-Trigger | Fix auf `develop` (`b5efdbb`): Push auf `main` startet Tests |

---

## Lokaler Start

```bash
git checkout develop
docker compose -f docker-compose.dev-env.yml up --build

curl http://localhost:8097/api/health
curl http://localhost:3097/api/health

docker compose -f docker-compose.dev-env.yml exec backend pip install -r requirements-dev.txt
docker compose -f docker-compose.dev-env.yml exec backend python -m pytest tests -ra -vv
```

Migrationen laufen beim Backend-Start automatisch (`run_migrations.main()` in `main.py`, überspringbar via `SKIP_DB_MIGRATE=1` für Tests).

---

## Offene Fragen

1. **Reverse Proxy** — Domains `kairo.jinkendo.de` / `dev.kairo.jinkendo.de` noch nicht eingerichtet; CI und Deploy nutzen localhost (bewusst ausreichend für AP0.1).
2. **Prod `.env`** — Muss auf dem Pi unter `/home/lars/docker/kairo/.env` mit sicherem `DB_PASSWORD` liegen (Deploy klont Repo, erzeugt `.env` nicht).
3. **README „Startzustand“** — Abschnitt oben in `README.md` beschreibt noch „kein Anwendungscode“; AP0.1-Tabelle unten ist aktuell — Kosmetik-Update empfohlen.
4. **`workflow_run`-Trigger** — In Gitea/act unzuverlässig; Prod-Tests hängen an Push `main` (Fix `b5efdbb`). Merge/Deploy bleibt manuell durch Product Owner.

---

## Abweichungen von der Spezifikation

| Spezifikation | Ist | Bewertung |
|---------------|-----|-----------|
| Health nur `status`, `app`, `db` | zusätzlich `version`, `schema` | Erweiterung, abwärtskompatibel |
| `db: "ok"` | auch `"error"` bei DB-Ausfall, dann `status: "degraded"` | sinnvoller Betriebszustand |
| Frontend optional | minimal umgesetzt (Health-Anzeige + nginx `/api`-Proxy) | im Scope |
| Offene Entscheidungen dokumentiert | in diesem Bericht + `docs/DEPLOYMENT.md`, kein separates ADR für AP0.1 | ausreichend für Abschluss |

Keine fachliche Sprint-1-Logik vorgezogen.

---

## Empfehlung für AP0.2

**Nächster Auftrag:** AP0.2 – Tenant, User, Actor (`Jinkendo_Kairo_04_Sprint0_Foundation_v0.3.md` § AP0.2)

Vorgehen:

1. Migration `002_tenant_user_actor.sql` — Tabellen laut Foundation, weiterhin ohne Vorhaben/Projekt-Domäne.
2. Seed für lokalen Admin-User (Dev only).
3. pytest für Migration + minimale Repository/Model-Schicht.
4. Health/version bei Schema-Bump (`DB_SCHEMA_VERSION` → `002`).
5. README-Startzustand bereinigen; optional Reverse Proxy parallel (nicht blockierend).

AP0.1 nicht erneut anfassen, außer README-Kosmetik oder Proxy-Wunsch.

---

*Erstellt im Rahmen Sprint 0 – AP0.1 Akzeptanz.*