gitea
21a00b0000
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m36s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m28s
Testy / Testy warstwy bazodanowej (ochrona baz) (pull_request) Successful in 9m28s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 24s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 10s
build-swisseph / build (push) Successful in 18s
build / build (push) Successful in 19s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m37s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m29s
Testy / Testy warstwy bazodanowej (ochrona baz) (push) Successful in 9m29s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 16s
Testy / Kontrola składni wszystkich warstw (push) Successful in 9s
Etap 4, z jedną istotną zmianą planu i jednym znalezionym błędem. /houses W SILNIKU B Domyka kontrakt parzystości (LOG-28) po stronie domów — dotąd obejmował tylko pozycje obiektów, więc błąd w podziale na domy przechodził przez porównanie silników niezauważony. Nazwy systemów są NASZE (te same, co houses.SYSTEMS), więc wołający nie musi znać liter swissepha; rozjazd tych dwóch list oznaczałby, że parzystość przestała obejmować część systemów. Poza dziedziną (Placidus/Koch za kołem podbiegunowym) zwracamy 422 z powodem, a NIE podstawiamy po cichu innego systemu — cicha podmiana jest po stronie wołającego niewykrywalna, a to on ma zdecydować, co z tym zrobić. PRZEMIAŁ: NOCNE CI ZAMIAST CRONJOBA W KLASTRZE Plan zakładał Job w k3s, bo „duży przemiał jest kosztowny". Pomiar tego nie potwierdził: 500 000 przypadków × 13 systemów = 70 mln porównań w 64 sekundy, skalowanie liniowe (20k→2,8 s, 100k→12,3 s, 500k→64 s). Osobny obraz w rejestrze, manifest, CronJob i kopia harnessu poza repo byłyby infrastrukturą do problemu, którego nie ma — a kopia harnessu poza repo to ryzyko cichego rozjazdu z kodem, który ma testować. Workflow z harmonogramem daje to samo: co noc inne ziarno, więc dziedzina przeczesuje się z czasem gęściej niż pojedynczym przebiegiem. ε PRAWDZIWE — BŁĄD ZNALEZIONY PRZY OKAZJI Silnik liczył RAMC z GAST (czas gwiazdowy POZORNY, mierzony od równonocy PRAWDZIWEJ), ale parował go z ε ŚREDNIM, czyli bez nutacji. To nie wybór konwencji, tylko pomieszanie dwóch układów odniesienia. Skutek: do 3,2″ na cuspach domów oraz niespójne ε dla deklinacji i antyscji, liczonych z pozycji POZORNYCH. Teraz ε pochodzi z serii IAU 2000A — z tego samego źródła, którego Skyfield używa do GAST, więc oba są spójne z definicji. Framework wyroczni tego NIE MÓGŁ wykryć: z założenia podaje to samo ε obu stronom, żeby izolować samą funkcję domów. Błąd siedział w danych WEJŚCIOWYCH, nie w testowanej funkcji — i cały czas świecił na zielono. Wejście ma więc teraz własny sprawdzian, ze Skyfieldem jako niezależnym autorytetem (bez swissepha, więc działa w każdym środowisku). Luka opisana wprost w tests/oracle/README.md, bo poprzedni tekst twierdził, że ε jest testowane — nie było. Reszta ~3″ przy porównaniu „cały horoskop nasz vs swissepha" to UT1 kontra UTC: Skyfield konwertuje z tablic IERS, swisseph przyjmuje podany JD jako UT1 (dla 1984-04-30 różnica 0,181 s = 2,7″ RAMC — zgadza się co do trzeciego miejsca). Podanie swissephowi JD w UT1 kasuje ją do 0,00065″. Nasza strona jest dokładniejsza; niczego tu nie zmieniam. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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/query→QueryRequest→QueryResponsePOST /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ługiengine-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.py → QueryService.handle(): walidacja wejścia, tłumaczenie zapytania,
obliczenia i wzbogacanie wyników.