Lokal ohne Server: `127.0.0.1:8000` über `docker compose up --build -d` (siehe README).
8006/8095 waren auf dem Pi frei. 8000 ist durch Paperless belegt und darf auf dem Server nicht verwendet werden.
---
## Branch-Regel
- Entwicklung nur auf `develop`.
- Push auf `develop` startet den Dev-Build auf dem Pi.
- Produktiv nur über Merge-Commit `develop` → `main`:
```bash
git checkout main
git pull origin main
git merge --no-ff develop
git push origin main
```
Kein Fast-Forward, kein direkter Commit auf `main`, kein manuelles `git pull` auf dem Prod-Checkout. Gitea (`deploy-prod.yml`) ist der einzige Prod-Schreibpfad für Code.
---
## Einmalige Server-Einrichtung
Die Workflows legen das Verzeichnis an und klonen bei Bedarf selbst. Actions sind im Repo bereits aktiv. Derselbe Pi-Runner wie die Schwesterprodukte (`ubuntu-latest`).
Nach dem ersten erfolgreichen Deploy `.env` prüfen und für Production ein eigenes `DB_PASSWORD` setzen. PostgreSQL übernimmt User/Passwort nur beim **ersten** Start des Volumes.
| `test.yml` | nach Dev-Deploy bzw. Push `develop` | pytest auf `buyingagent_test` (Dev-Postgres, nicht Live-DB) und read-only Smoke gegen `/health/live` und `/health/ready` |
Der API-Build nutzt `ghcr.io` (nicht Docker Hub). `COMPOSE_BAKE=0 docker compose build --pull=false` verwendet vorhandene Basis-Images und vermeidet Registry-Metadatenabrufe, die auf dem Pi per IPv6-DNS timeouten.
`test.yml` folgt Kanshō: pytest läuft in einem Einweg-Container aus dem bereits deployedten `api`-Image gegen die wegwerfbare Datenbank `buyingagent_test` auf dem bereits laufenden Dev-Postgres. Die Live-Datenbank bleibt unangetastet. Es gibt kein Frontend, daher keinen Frontend-Build-Job.
