feat(astroklient): wersja demonstracyjna o dwóch funkcjach (PRE-28)

Osobna warstwa prezentacji: dodanie pliku bazy i zapytanie o interpretację
urodzeniową. Nic więcej.

OSOBNA USŁUGA, NIE KONTO Z OGRANICZENIAMI. Mechanizm uprawnień z PRE-27 umiałby to
ukryć w pełnej aplikacji, ale ukrycie a nieobecność to dwie różne rzeczy: tutaj
pozostałych funkcji NIE MA W OBRAZIE — nie ma tras, nie ma szablonów, nie ma nawet
metod w kliencie warstwy logicznej. Demo można komuś oddać, nie oddając przy
okazji kodu reszty programu. Test porównuje zbiór tras aplikacji i zbiór metod
klienta z listą dokładną, więc dopisanie czegokolwiek zapala się od razu.

WGRANIE I WŁĄCZENIE TO JEDNA CZYNNOŚĆ. W pełnej aplikacji to dwie osobne decyzje
(DAN-27), bo tam ktoś nad tym panuje. Tutaj „dodać plik do bazy" musi znaczyć, że
plik od razu bierze udział w wyszukiwaniu — inaczej po wgraniu nic by się nie
zmieniło i demo wyglądałoby na zepsute. Walidacja zostaje: plik o złym układzie nie
wchodzi do użytku, ale też NIE JEST tracony, a komunikat nie zdradza reguł, bo te
zna wyłącznie administrator. Osobny test szuka w komunikacie śladów mechanizmu.

KONTO OSOBNE (DEMO_USER/DEMO_PASSWORD), nie współdzielone z główną aplikacją.
Demo pracuje na TEJ SAMEJ warstwie danych co produkcja — świadoma decyzja
właściciela — więc kto ma do niego dostęp, czyta oryginalne bazy, a jego wgrania
trafiają do produkcyjnego zbioru. Własne poświadczenia pozwalają odciąć demo jedną
zmienną, bez ruszania kont głównej aplikacji i bez zmiany hasła komukolwiek.
Zapisane wprost w README usługi i w manifeście, nie tylko w tej wiadomości.

Rozmowa z warstwą logiczną idzie tym samym szyfrowanym łączem (PRE-16) i pod tym
samym tokenem międzywarstwowym (LOG-32) — demo nie jest furtką omijającą ochronę.
Automatyczna dokumentacja wyłączona, jak w pełnej aplikacji: /docs wypisałoby
komplet tras, a demo ma nie zdradzać nawet własnej powierzchni.

Zależności celowo krótsze niż w prezentacji: bez Excela, bez stref czasowych
z lokalizacji, bez niczego pod kosmogram. Każda zbędna zależność w obrazie demo to
kolejna rzecz do pilnowania.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.gitea/workflows/build.yaml

@@ -9,10 +9,12 @@ jobs:
       - uses: actions/checkout@v4
       - name: Login
         run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login gitea.czernobog.pl -u gitea --password-stdin
-      - name: Build & push (data, logic, presentation)
+      # astroklient dołącza do tej samej pętli: dzieli warstwę logiczną i łącze,
+      # więc jego obraz ma powstawać z tego samego commita co reszta produktu.
+      - name: Build & push (data, logic, presentation, astroklient)
         run: |
           TAG=${GITHUB_SHA::8}
-          for SVC in data logic presentation; do
+          for SVC in data logic presentation astroklient; do
             docker build -t gitea.czernobog.pl/gitea/astrololo-$SVC:$TAG ./services/$SVC
             docker push  gitea.czernobog.pl/gitea/astrololo-$SVC:$TAG
           done

.gitea/workflows/tests.yml

@@ -91,6 +91,27 @@ jobs:
           PYTHONPATH: .
         run: pytest tests -q -rs
 
+  astroklient-tests:
+    name: Testy astroklienta (wersja demo)
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+          cache: pip
+          cache-dependency-path: services/astroklient/requirements-dev.txt
+      - name: Instalacja zależności
+        run: pip install -r services/astroklient/requirements-dev.txt
+      # Demo rozmawia z warstwą danych PRODUKCJI, więc jego powierzchnia musi być
+      # pilnowana tak samo jak reszty: testy sprawdzają m.in., że nie przybyła
+      # żadna trasa poza dwiema funkcjami.
+      - name: Testy (pytest)
+        working-directory: services/astroklient
+        env:
+          PYTHONPATH: .
+        run: pytest tests -q -rs
+
   swisseph-image:
     name: Build obrazu silnika B (swisseph)
     runs-on: ubuntu-latest