Etap 0 planu egzotycznych systemów domów: zanim zaczniemy implementować Placidusa
i spółkę, potrzebujemy narzędzia, które powie, czy wynik jest poprawny. Błąd
w domach jest CICHY — wykres wygląda dobrze, tylko planety siedzą w złych domach.
FRAMEWORK (tests/oracle): liczenie cuspów jako funkcja (RAMC, ε, φ), Swiss
Ephemeris jako wyrocznia. Trzy decyzje projektowe, które okazały się kluczowe:
- IZOLACJA: obu implementacjom podajemy TE SAME wejścia przez swe_houses_armc.
Porównywanie „naszego horoskopu" z „horoskopem swissepha" mieszałoby różnice
czasu gwiazdowego i ε z błędami domów — utonęlibyśmy w fałszywych alarmach.
Czas gwiazdowy i ε mają własny test.
- KRYTERIUM to liczba przypadków powyżej tolerancji (1″), max odchylenie I MIEJSCE,
a nie procent zgodności. Procent ukrywa kształt błędu: „97%" nie odróżnia szumu
zmiennoprzecinkowego od rogu dziedziny, w którym mylimy się o 30°.
- GRANICE PER DATA: koło podbiegunowe nie jest stałą 66,56° — zależy od ε, które
zmienia się z datą (23,75° w 370 p.n.e.), więc przesuwa się o ~0,3°.
Uruchomiony na kodzie uchodzącym za poprawny, w PIERWSZYM przebiegu znalazł dwa
realne błędy:
1. ASCENDENT O 180° ZA KOŁEM PODBIEGUNOWYM. `atan2` wybierał niewłaściwy punkt
przecięcia ekliptyki z horyzontem — zwracaliśmy Descendent. Planety lądowały
w PRZECIWNYCH domach dla całej północnej Skandynawii (Tromsø, Rovaniemi,
Murmańsk), na ~11% przypadków przy tych szerokościach. Rozstrzyga położenie
względem MC: punkt wschodzący leży w półkolu (0°,180°) na wschód od MC.
2. NIEDETERMINIZM WHOLE SIGN NA GRANICY ZNAKU. Ascendent o włos od granicy
(359,999999999976 vs 1e-10 — ta sama wartość, różne strony) przerzucał dom I
o 30°. Ten sam horoskop na innej maszynie dawał inny wynik. Przyciąganie do
granicy przy 1e-9° (3,6 mikrosekundy łuku — poniżej realnej dokładności danych).
Oba mają testy regresji w zwykłej suicie, więc są łapane też bez swissepha.
Po poprawkach: build 0 przekroczeń, sweep 20 000 przypadków = 760 000 porównań,
max odchylenie 0.000000000°. Istniejące suity bez regresji (logika 277+3, prez. 249).
CI: krok BLOKUJĄCY w jobie swisseph-image, odpalany wewnątrz obrazu silnika B
z zamontowaną warstwą logiczną. pyswisseph zostaje wyłącznie wyrocznią testową —
nie wchodzi do zależności produktu, izolacja z LOG-27 nienaruszona.
Dodane `cusps_for(ramc, eps, lat, system)` — kanoniczne wejście, w które Etap 1
będzie tylko dopisywał kolejne systemy.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Luka wyszła przy DAN-26 (#52): dodałem pierwsze testy w usłudze `data`, ale CI
odpalało tylko `logic` i `presentation` — więc testy canary NIGDY by się nie
wykonały. Nietestowany kod ochronny jest gorszy niż jego brak, bo daje złudzenie
zabezpieczenia; tym bardziej nie może być testowany „na niby".
- nowy job `data-tests` w tests.yml (wzorowany na presentation),
- `services/data/requirements-dev.txt` (którego usługa nie miała).
Sprawdzone lokalnie dokładnie tą komendą co w CI: 7 testów canary przechodzi.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Luka: usluga render (services/render) weszla w #32, ale zaden workflow nie budowal
jej obrazu — wiec astrololo-render:latest nie istnial w rejestrze, a pod zawislby
na ImagePullBackOff po wdrozeniu manifestow.
Osobny pipeline (jak build-swisseph), nie dopisanie do build.yaml: obraz dzwiga
TeX Live (setki MB), a build.yaml chodzi przy KAZDYM pushu do mastera. Budowanie
renderu za kazdym razem spowalnialoby kazdy deploy — a to wlasnie ta izolacja
miala usunac. Wyzwalany tylko zmiana w services/render/**; workflow_dispatch do
bootstrapu.
Merge tego PR zbuduje pierwszy obraz (push dotyka pliku workflow, wiec trigger sie
odpali) i wypchnie :latest — dopiero potem ma sens merge deploy#5.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Job „Build obrazu silnika B" padal na kazdym przebiegu po pierwszym:
Conflict. The container name "/swe" is already in use
Dwie wady starego kroku, obie moje:
1. startowal kontener w tle (docker run -d --name swe) i NIGDY go nie usuwal,
wiec nazwa zostawala zajeta na runnerze i kolejne przebiegi sie wywalaly;
2. pukal curl-em w localhost:8003, podczas gdy job Gitea Actions sam dziala
w kontenerze, a -p publikuje port na HOSCIE — to nie ten sam localhost,
wiec health-check i tak nie mial prawa dojsc.
Teraz test biegnie WEWNATRZ obrazu (docker run --rm ... python -), wolajac
funkcje endpointow wprost. Omija oba problemy, nie zostawia niczego po sobie,
a sprawdza to samo i wiecej: obraz sie zbudowal, pyswisseph liczy, komplet 13
obiektow, Slonce w oczekiwanym zakresie, SN = NN + 180.
Dodany krok sprzatajacy osierocony kontener „swe" ze starych przebiegow.
Zweryfikowane lokalnie na realnym pyswisseph: Sun=40.2102, NN=68.1530,
13 obiektow — zgodnie z wyrocznia.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bazy sa rdzeniem produktu i wlasnie zostaly kupione — a aplikacja nie miala
ZADNEGO uwierzytelniania. Prezentacja to NodePort, wiec kazdy w LAN wchodzil
bez logowania, a `/search` oddawal surowe wiersze do 50 000 na zapytanie.
Bazy mogly wyjsc przez sama aplikacje, bez udzialu jakiegokolwiek LLM.
- prezentacja: HTTP Basic (APP_USER/APP_PASSWORD) + limit zadan na IP
(RATE_LIMIT_PER_MIN, domyslnie 120/min). Limit dziala TAKZE przed
uwierzytelnieniem, zeby zgadywanie hasla i sondowanie API nie bylo darmowe.
- logika i dane: token miedzywarstwowy X-Astrololo-Token (INTERNAL_TOKEN) —
bez niego dalo sie ominac logowanie, uderzajac wprost w warstwe nizej.
Warstwa danych oddaje surowe wiersze, wiec to najwrazliwszy punkt.
- /search: gorny limit 50 000 -> 5000 (tyle realnie uzywa build_report).
Publiczne /api/query zostaje na 200.
- /health celowo publiczny (sondy k8s go nie uwierzytelnia).
- swiadomie nie logujemy tresci zadan ani promptow — logi to kolejny nosnik.
Fail-open przy braku konfiguracji (zgodnosc wstecz i dev), ale z GLOSNYM
ostrzezeniem przy starcie, zeby nikt nie wdrozyl tego w przekonaniu, ze jest
chroniony. Wlaczenie w produkcji wymaga ustawienia sekretow w repo deploy.
Testy: 12 (prezentacja, nowy katalog + job w CI) i 5 (logika). Zweryfikowane
na zywym stosie: bez hasla 401, z haslem 200, logika wprost bez tokenu 401,
z tokenem 200, /health 200, limit 50000 odrzucony (422), a prezentacja nadal
liczy horoskop przez logike.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Buduje i pushuje obraz gitea/astrololo-engine-swisseph (tag SHA + latest).
Celowo oddzielony od build.yaml (data/logic/presentation) — odpala sie
tylko przy zmianach w services/engine-swisseph/**, wiec obraz AGPL nie
miesza sie do pipeline'u permisywnego produktu. workflow_dispatch pozwala
zbootstrapowac pierwszy obraz recznie.
Obraz konsumuje profil deployu astrololo-swisseph (repo deploy).
Uwaga: pierwszy build zadziala dopiero po zmergowaniu poprawki Dockerfile
(PR #3) — na masterze Dockerfile jeszcze sie nie buduje.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gitea