Files
astrololo/services/logic
gitea 012e4f39f6
Testy / Testy warstwy logicznej (silnik) (push) Successful in 11m47s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m38s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 34s
Testy / Kontrola składni wszystkich warstw (push) Successful in 20s
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 11m34s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m37s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 32s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 20s
feat(logic): aspekty pozazodiakalne — antyscja i paralele deklinacji (LOG-07)
Aspekty głowne (LOG-06) mierzą kąt wzdłuż ekliptyki. LOG-07 dokłada dwa rodzaje
powiązań, które klasyczna astrologia liczy naprawdę, nie na oko:

- PARALELA/KONTRPARALELA DEKLINACJI — dwa ciała na tej samej („parallel") lub
  przeciwnej („contraparallel") deklinacji działają jak koniunkcja/opozycja,
  mimo że wzdłuż ekliptyki mogą stać gdziekolwiek. Deklinacja liczona PEŁNYM
  wzorem (z szerokością ekliptyczną — istotne dla Księżyca i planet schodzących
  z ekliptyki), przez to_equatorial z LOG-04. Orb konfigurowalny (domyślnie 1°,
  ciasno — to kontakty punktowe).
- ANTYSCJA/KONTRANTYSCJA — odbicie długości względem osi przesileń (0° Raka –
  0° Koziorożca) albo równonocy (0° Barana – 0° Wagi).

Liczone na współrzędnych TROPIKALNYCH of-date, bo deklinacja jest fizyczna
(równikowa, niezależna od zodiaku), a antyscja z definicji tropikalna — jej oś to
kardynalne punkty zodiaku tropikalnego. Dlatego PRZED przesunięciem na zodiak
syderyczny/draconiczny.

Dodatkowo: flaga „out of bounds" (|deklinacja| > nachylenie ekliptyki — ciało
poza zakresem Słońca) i kolumna deklinacji przy każdej pozycji.

Integracja z bazą: baza interpretacyjna ZNA paralele pod frazą „P. Dec.", więc
generujemy fasetkę paraleli (trafia też do promptu LLM). PUŁAPKA: samo „Dec." w
bazie to często DEKANAT („3rd Dec. of [Gem"), więc szukamy dokładnie „P. Dec." —
inaczej sypnęłoby fałszywymi trafieniami. Kontrparaleli i antyscji baza nie
opisuje osobnym znacznikiem, więc zostają obliczeniem display-only.

Pary z RIGID_PAIRS (węzły) odsiane: SN = NN+180° na ekliptyce → deklinacja
ZAWSZE przeciwna, czyli definicyjna kontrparalela bez informacji.

Walidacja wobec faktów NIEZALEŻNYCH od kodu:
- deklinacja Słońca 30.04.1984 = +14.88° wobec ~+14.9° z almanachu,
- antyscja to arytmetyka odbicia: inwolucja i pary znaków (Rak↔Bliźnięta,
  Baran↔Panna) sprawdzone na piechotę,
- węzły faktycznie mają przeciwną deklinację i są odsiane,
- deklinacja niezależna od zodiaku (tropikalny == syderyczny co do 1e-6°),
- realna baza: mechanizm paraleli znajduje wpisy „P. Dec." i odsiewa dekanaty
  (z 33 wpisów „P. Dec." 5 ma niepusty efekt — głównie „[conj or P. Dec.").

UI: kolumna deklinacji (+znacznik OOB), tabela paraleli/kontrparaleli i tabela
antyscji na ekranie Horoskop.

Testy: 15 nowych (out_of_zodiac) + 2 (fasetka paraleli vs pułapka dekanatu).
Całość: logika 251 passed / 1 skipped, prezentacja 25 passed. Render szablonu
sprawdzony osobno (bez błędu Jinja, wszystkie sekcje obecne).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 20:20:02 +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.