7 Commits

Author	SHA1	Message	Date
gitea	21a00b0000	feat(silnik B): endpoint /houses + nocny przemiał; ε PRAWDZIWE zamiast średniego ... 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>	2026-08-06 12:22:48 +02:00
gitea	40f5e459e0	fix(ci): wyrocznia domów — wbuduj pliki w obraz zamiast montować (-v nie działa) ... Krok padał na `python: can't open file '/oracle/run.py'`. Przyczyna jest tą samą pułapką, którą złapano już wcześniej przy `-p` i localhoście (jest o niej komentarz w tym samym pliku): job Gitea Actions SAM działa w kontenerze, więc `docker run -v $PWD/...` demon rozwiązuje na HOŚCIE, gdzie tej ścieżki nie ma. Docker nie zgłasza wtedy błędu — po cichu tworzy PUSTY katalog, przez co skrypt „znika". Zamiast montowania wbudowujemy pliki w pomocniczy obraz (FROM engine-swisseph:ci + COPY). Kontekst builda jest strumieniowany do demona, więc działa niezależnie od tego, gdzie ten demon stoi. Obraz kasujemy po użyciu. Przy okazji .dockerignore: docker NIE czyta .gitignore, więc do demona poleciałby cały korzeń repo — z lokalnym wirtualenvem (344 MB) i jądrami efemeryd włącznie. Kontekst spada z 382 MB do 5,9 MB, co na runnerze z historią „no space left on device" nie jest kosmetyką. Plik dotyczy tylko buildów z korzenia repo — obrazy usług mają własne konteksty (services/<usługa>) i go nie widzą. Zweryfikowane bez dockera: sprawdzony dokładny tekst, jaki dostanie powłoka po dedentacji YAML (terminator heredoca w kolumnie 0), istnienie ścieżek COPY oraz to, że reguły .dockerignore nie wycinają plików potrzebnych do uruchomienia. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-04 23:20:43 +02:00
gitea	86a0f16f9e	test: framework porównania domów z wyrocznią + DWA błędy, które od razu wykrył ... 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>	2026-08-04 18:03:08 +02:00
gitea	dd32f7e82f	ci: odpalaj testy warstwy bazodanowej (dotąd nie były uruchamiane) ... 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>	2026-08-03 21:38:48 +02:00
gitea	487dbb8fd3	fix(ci): smoke test silnika B bez kontenera w tle i bez sieci ... 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>	2026-07-22 17:29:27 +02:00
gitea	752f477a27	feat(security): zamkniecie dostepu do baz interpretacyjnych (LOG-32) ... 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>	2026-07-21 16:50:18 +00:00
gitea	6ced2ddd22	fix workflows	2026-07-20 18:50:54 +00:00