# Profil deployu: `swisseph` (silnik B, AGPL)

Drugi, **opcjonalny** wariant deployu astrololo. Ten sam stack co produkcja, ale
warstwa logiczna liczy na **Swiss Ephemeris** (silnik B, AGPL) zamiast na własnym
Skyfieldzie. Zbudowany jako overlay Kustomize nad bazą `../astrololo`.

## Co robi
- dokłada usługę **`engine-swisseph`** (Deployment + Service, **ClusterIP**),
- przełącza `logic` na `EPHEMERIS_ENGINE=swisseph` i ustawia
  `ENGINE_SWISSEPH_URL=http://engine-swisseph:8003`,
- data / logic / presentation oraz ich tagi obrazów **dziedziczy z bazy** — profil
  śledzi tę samą wersję co produkcja (podbija ją ten sam image-updater).

Włączenie `ENGINE_SWISSEPH_URL` uruchamia też endpoint **`/chart/compare`** — czyli
w jednej instancji logica masz porównanie own vs swisseph (LOG-25/26), bez stawiania
drugiego równoległego stacku.

## ⚠️ Licencja / izolacja
`engine-swisseph` jest **AGPL-3.0** i dlatego:
- to **osobny proces/obraz**, wołany przez HTTP — permisywny produkt nie jest z nim
  linkowany,
- Service jest **ClusterIP** (świadomie **bez** NodePort/Ingress): rozmawia z nim
  tylko `logic`, usługa nie jest wystawiona użytkownikom końcowym.

Ten profil służy do walidacji / porównań i **nie jest** dystrybucją zamkniętego
produktu.

## Aktywacja
To profil **zastępujący** bazę w tym samym namespace `astrololo` (nie dokładający się
obok). Wskaż kontroler GitOps (Argo CD / Flux) na katalog `astrololo-swisseph`
**zamiast** `astrololo`:

```yaml
# np. w Argo CD Application:
source:
  path: astrololo-swisseph        # było: astrololo
```

Ręcznie:
```bash
kubectl apply -k astrololo-swisseph
```

> **Nie** trzymaj obu reconcilerów naraz na ns `astrololo` — baza (own) i ten profil
> (swisseph) biłyby się o patch `logica`. Wybierasz jeden albo drugi.
>
> Powrót do własnego silnika: wskaż GitOps z powrotem na `astrololo` (albo
> `kubectl apply -k astrololo` — usuń wtedy ręcznie Deployment/Service
> `engine-swisseph`, bo baza go nie zna).

## Wymagania wstępne
1. **Obraz silnika B** musi istnieć w registry:
   `gitea.czernobog.pl/gitea/astrololo-engine-swisseph`. Buduje go workflow
   `.gitea/workflows/build-swisseph.yaml` w repo `astrololo` (odpala się przy zmianach
   w `services/engine-swisseph/**`; można też ręcznie przez `workflow_dispatch`).
   Overlay używa tagu `latest` — podmień w `kustomization.yaml` na przypięty SHA, gdy
   zechcesz zamrozić wersję.
2. Ten sam ns `astrololo` → reużywa istniejący pull-secret `gitea-registry` i montaż
   NFS z `data.yaml`. (Gdybyś wolał postawić profil **obok** produkcji w osobnym ns,
   odkomentuj `namespace:` w `kustomization.yaml` i utwórz w nowym ns pull-secret
   `gitea-registry` oraz upewnij się co do dostępu do NFS.)

## Weryfikacja po wdrożeniu
```bash
kubectl -n astrololo rollout status deploy/engine-swisseph
kubectl -n astrololo exec deploy/logic -- \
  sh -c 'wget -qO- http://engine-swisseph:8003/health'
# oczekiwane: {"engine":"swisseph","status":"ok","mode":"moshier",...}
```
Następnie w UI/`logic` policz dowolny horoskop i porównaj przez `/chart/compare`.