Files
astrololo/services/logic
gitea 1d7f3e2136
build / build (push) Successful in 1m26s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 11m10s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m55s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 38s
Testy / Kontrola składni wszystkich warstw (push) Successful in 25s
feat(prezentacja): szkielet kosmogramu — koło horoskopowe SVG (PRE-12)
Pierwszy krok rysowania wykresu (PRE-12): SZKIELET koła — pierścień znaków,
podział na domy i osie. Planety i linie aspektów w kolejnych iteracjach.

Rysowane po stronie serwera jako czysty string SVG (bez zależności zewnętrznych
— spójne z CSP). Ciemny motyw, spójny z paletą aplikacji (kolory z --line,
--accent, --muted; glify znaków barwione wg żywiołu w stonowanych kolorach
czytelnych na ciemnym tle).

Geometria wg konwencji astrologicznej: Ascendent po LEWEJ, długość ekliptyczna
rośnie przeciwnie do ruchu wskazówek zegara. Punkt λ → kąt φ = 180° − (λ − Asc);
w SVG y rośnie w dół, co formuła uwzględnia. Zakotwiczenie sprawdzone testami
liczbowo: Asc po lewej, Dsc po prawej, oś pozioma; Asc+90° (II dom) na dole.

Elementy: dwa okręgi + piasta, podziałki co 5°/10°, granice znaków co 30° z
glifem w środku sektora, szprychy domów od pasa do piasty, numery domów w środku
każdego domu, osie Asc–Dsc i MC–IC wyróżnione akcentem z etykietami AC/DC/MC/IC.

Dane bierzemy WYŁĄCZNIE z wyniku /chart/positions — prezentacja nic nie liczy:
- `sign_glyphs` (pierścień 12 znaków) i glify — z LOG-22,
- `angles` z długością `decimal` — już były,
- `cusps` z `decimal` — DOŁOŻONE w tym PR (jedna linia w build_chart). Bez tego
  domy dało się narysować tylko dla whole sign; z długością cuspu działa dla
  KAŻDEGO systemu. Zweryfikowane na porphyry: cuspy poza wielokrotnościami 30°,
  szprychy odchodzą od granic znaków.

Degradacja: silnik bez osi/domów albo starszy wynik bez `decimal` w cuspach →
brak koła (pusty string), nie wyjątek.

Testy: 8 (poprawność XML, 12 glifów, 4 osie, numery domów, Asc po lewej liczbowo,
CCW, degradacja). Całość: prezentacja 33 passed, logika 265 / 1 skipped. Render
potwierdzony wizualnie na horoskopie referencyjnym (AC=Leo po lewej, MC=Aries
u góry, domy CCW).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-24 12:32:47 +02:00
..

Warstwa logiczna (logic)

Niezależna usługa pośrednicząca. W górę udostępnia API dla prezentacji, w dół woła warstwę bazodanową. Tu żyją reguły biznesowe — nie w prezentacji i nie w bazie.

API

  • POST /api/queryQueryRequestQueryResponse
  • POST /chart/positions{when_utc, lat, lon, house_system?} → pełny horoskop: pozycje (LOG-01) + osie i domy (LOG-05) + aspekty główne z applying/separating (LOG-06) + opcjonalnie stacje planet (stations:true, LOG-03). Zwraca też sektę i 7 Lots hermetycznych z domami (LOG-08). Obiekty: 10 planet + mean NN/SN/Lilith (LOG-02). house_system: whole_sign (dom.) / equal / porphyry.
  • POST /chart/report{when_utc, lat, lon, limit?} → wynik obliczeń wyszukany w bazie: fasety sygnifikatorów w znaku / w domu / w aspekcie, z rozwinięciem skrótów, odsiewaniem duplikatów (ten sam sygnifikator i opis), rankingiem siły (LOG-21) oraz opcją group (grupowanie identycznych opisów)
  • POST /chart/profections{when_utc, lat, lon, start_age?, count?} → profekcje roczne: wiek, profektowany Asc, Władca Roku (+MC/Su/Mo) (LOG-10)
  • POST /chart/return{when_utc, lat, lon, kind, around?} → Solar/Lunar Return: moment powrotu + pełny horoskop na ten moment (LOG-12)
  • POST /chart/firdaria{when_utc, lat, lon} → Firdaria: sekta (dzień/noc), okresy główne i podokresy time-lordów (LOG-11)
  • POST /chart/timeline{when_utc, lat, lon, from_date, to_date, techniques?} → zbiorcza oś czasu: profekcje + Solar Return + dyrekcje solar-arc + Firdaria, posortowane (technique | significator | start | exact | end); z interpret=true dopina interpretacje z bazy do dat (LOG-14, 1B->2B)
  • POST /chart/compare → jak wyżej → raport różnic dwóch silników (LOG-26; wymaga silnika B)
  • GET /health (sprawdza też warstwę bazodanową)

Silnik efemeryd (LOG-24, „wymienny silnik liczący")

W app/engine/ żyje pluggable silnik za interfejsem EphemerisEngine:

  • SkyfieldEngine — własny, permisywny (Skyfield MIT + dane JPL public domain). Domyślny.
  • RemoteEngine — klient OSOBNEJ, izolowanej usługi engine-swisseph (AGPL), używany tylko w trybie porównawczym.

Wybór: EPHEMERIS_ENGINE=own|swisseph. Silnik B włącza się przez ENGINE_SWISSEPH_URL.

Walidacja (LOG-25/28): app/engine/compare.py zestawia oba silniki z progiem tolerancji; ten sam kontrakt parzystości obowiązuje każdy silnik. Nasz SkyfieldEngine zgadza się ze Swiss Ephemeris co do ~1″ na horoskopie referencyjnym (patrz tests/).

pip install -r requirements-dev.txt
PYTHONPATH=. pytest tests -q            # silnik B pomijany, jeśli ENGINE_SWISSEPH_URL nieustawiony

Zależności w dół

Zna wyłącznie DATA_URL (adres warstwy bazodanowej) i jej kontrakt /search. Nie wie, czy pod spodem jest Excel czy SQL.

Uruchomienie

pip install -r requirements.txt
export DATA_URL=http://localhost:8002
uvicorn app.main:app --port 8001

Gdzie rozbudowywać domenę

service.pyQueryService.handle(): walidacja wejścia, tłumaczenie zapytania, obliczenia i wzbogacanie wyników.