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>
pyswisseph to rozszerzenie C, a na PyPI (2.10.3.2) gotowe wheels koncza sie
na cp311 i obejmuja wylacznie i686/x86_64. Obraz stoi na python:3.12-slim,
wiec pip ZAWSZE kompilowal ze zrodel - a slim nie ma kompilatora. Stad fail.
- Dockerfile wieloetapowy: kompilacja w etapie builder (build-essential),
do runtime trafia juz tylko gotowy wheel - obraz zostaje czysty i maly.
Dziala tez na arm64, gdzie wheeli linuksowych nie ma dla zadnej wersji.
- sanity check (import swisseph) na etapie builda, zeby niedzialajacy silnik
wywracal build, a nie dopiero pierwszy request.
- CI: nowy job swisseph-image - realny docker build + smoke test /health
i /positions na horoskopie referencyjnym.
- README: udokumentowany powod wieloetapowego builda.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Punkty wirtualne (LOG-02):
- engine/points.py: mean Node (Ω) i mean Lilith (apogeum) wzorami Meeusa;
prędkości numerycznie. SN = NN + 180° (ta sama prędkość), zawsze Rx.
- DEFAULT_OBJECTS + North Node / South Node / Lilith — automatycznie dostają
domy, aspekty i A/S. Parzystość silnika B: swe.MEAN_NODE / swe.MEAN_APOG
(uwaga: stała pyswisseph to MEAN_APOG, nie MEAN_APOGEE).
- significators: tokeny [NN / [SN / [Lilith (zgodne z SIGNIFICATORS KEY).
Stacje (LOG-03):
- engine/stations.py: skan prędkości (krok 4 dni, okno ±800 dni — pokrywa
najdłuższe przerwy Marsa/Wenus) + bisekcja; klasyfikacja SD/SR; poprzednia/
następna stacja (dni, data, stopień w znaku) + flaga station_soon (<7 dni).
- /chart/positions: opt-in stations:true; UI: checkbox + tabela stacji.
Walidacja:
- mean NN vs astro-seek (Gem 8°09'24"): Δ=0,3'; vs swisseph: Δ=17";
mean Lilith vs swisseph: Δ=1,5'. NN dom 12 / SN dom 6 zgodnie z astro-seek.
- Stacje Marsa 1984 trafiają w historię: SR 5.04.1984, SD 19.06.1984;
samospójność |speed|<0,01°/d w znalezionych momentach; flaga "blisko"
działa (Merkury +5,3d, Jowisz -0,6d).
- E2E na realnej bazie: [SN 134 rekordy, trafienie w 6. domu. 54 testy przechodzą.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pierwszy increment implementacji warstwy logicznej (ścieżka A).
LOG-24: interfejs EphemerisEngine z dwoma backendami — SkyfieldEngine
(własny, permisywny: Skyfield MIT + dane JPL public domain) oraz
RemoteEngine (klient izolowanej usługi swisseph). Fabryka + leniwa
inicjalizacja; endpointy /chart/positions i /chart/compare.
LOG-01: pozycje obiektów (długość/szerokość ekliptyczna, prędkość,
kierunek, formaty: w znaku / absolutny / dziesiętny).
LOG-25/28: harness porównawczy (compare.py) z progami tolerancji oraz
wspólny kontrakt parzystości; pełen zestaw testów.
LOG-27: services/engine-swisseph — osobna, opcjonalna usługa AGPL
(pyswisseph, tryb Moshiera), licencjonowana osobno, w compose pod
profilem "comparison"; nie wchodzi do zamkniętego produktu.
Walidacja: SkyfieldEngine zgadza się ze Swiss Ephemeris co do ~1" dla
wszystkich 10 obiektów na horoskopie referencyjnym (30.04.1984, Warszawa);
12 testów przechodzi (silnik B pomijany gdy nieskonfigurowany).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gitea