35 Commits

Author	SHA1	Message	Date
gitea	4c1e7f8808	feat: przegląd baz na udziale + globalne włączanie/wyłączanie (DAN-15/PRE-09) ... Wymaganie przedefiniowane pod model serwerowy (#47): nie wybiera się folderu — pliki leżą na stałym NFS. Potrzeba za to WIDZIEĆ, jakie bazy są dostępne i móc zdecydować, które biorą udział w interpretacji. Warstwa danych: `bases.py` (lista plików + metaopis: nazwa, ścieżka, rozmiar, data, stan) i endpoint `/bases`. Wyłączone bazy są ODSIEWANE z kandydatów przy wyszukiwaniu, więc naprawdę nie biorą udziału w interpretacji — nie tylko znikają z listy. Lista wyłączonych wchodzi do klucza cache zapytań: bez tego zmiana ustawień oddawałaby wynik sprzed zmiany, czyli treść bazy uznanej za wyłączoną. `list_bases()` doszło do interfejsu dostawcy jako OPCJONALNE (SQL nie operuje na plikach → pusto, zamiast wywrotki). Przelot logika → prezentacja i ekran „Ustawienia" z tabelą baz. Przez łącze idą SAME METADANE — podgląd listy nie jest kolejną drogą do wyniesienia treści. Stan przełączników jest DEKLARATYWNY (`DISABLED_BASES`), nie klikalny — i to jest świadome: udział z bazami montujemy read-only, a katalog cache to `emptyDir`, więc zapisany przełącznik ginąłby przy restarcie poda i po cichu włączał z powrotem wyłączoną bazę. Ekran mówi wprost, jak wyłączyć bazę i dlaczego nie klikaniem. Tryb klikalny wymagałby dołożenia trwałego wolumenu. Weryfikacja na żywym łańcuchu: `/bases` przechodzi przez SZYFROWANE łącze (logic→data), pokazuje 3 bazy z metaopisem i stanem; wyszukiwanie daje 3 → 2 → 0 wierszy w miarę wyłączania baz. Testy: dane +6, prezentacja +6. Dane 13, logika 277, prezentacja 249. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 22:09:27 +02:00
gitea	d3d9b365fe	feat(bezpieczeństwo): konta imienne i dziennik audytowy (PRE-17) ... Jedno wspólne hasło nie mówiło, KTO sięgał do baz, a odebranie dostępu jednej osobie wymagało zmiany hasła wszystkim. Przy bazach o realnej wartości handlowej to za mało. KONTA IMIENNE: `APP_USERS='alicja:scrypt$…,bartek:scrypt$…'`. Hash liczy scrypt ze STDLIB — zero nowych zależności; hasła nie ma w konfiguracji jawnie. Zakładanie konta: scripts/make_user.py (hasło interaktywnie, nie w historii powłoki). Odebranie dostępu = usunięcie wpisu, reszta nie zmienia haseł. Gdy APP_USERS jest ustawione, wspólne APP_PASSWORD PRZESTAJE działać (ostrzeżenie przy starcie) — działające obok kont byłoby tylnym wejściem bez śladu w dzienniku. Dopóki APP_USERS nie jest ustawione, stary tryb działa jak dotąd (zgodność wstecz). DZIENNIK AUDYTOWY: każde żądanie zostawia wpis „kto, skąd, co, status, ILE rekordów, ile ms". Liczba rekordów jest tu sednem — pojedyncze zapytanie wygląda niewinnie, suma pokazuje powolne wypompowywanie bazy przez osobę uprawnioną. Liczona dla wyszukiwarki sygnifikatorów, raportu i eksportu do Excela (ten wynosi najwięcej naraz). W logach NIE MA treści — ani rekordów, ani promptów. Dwa realne błędy złapane po drodze: - `secrets.compare_digest` rzuca TypeError na znakach spoza ASCII, więc hasło z polskimi literami wywracało logowanie błędem 500 zamiast odmowy (błąd ZASTANY, sprzed tej zmiany) — porównujemy teraz bajty; - dziennik był PUSTY na żywym serwerze: domyślna konfiguracja uvicorna nie obsługuje naszych loggerów. Niewidoczny dziennik jest gorszy niż jego brak, więc audyt dostał własny handler na stdout. Oba przypadki mają testy regresji. Instrukcja wdrożeniowa: docs/konta-i-audyt.md. Testy: +15. Prezentacja 243. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 19:57:03 +00:00
gitea	7b435d4263	feat: synastria — aspekty między dwoma horoskopami (PRE-04) ... Pierwsza technika relacyjna z pełnym UI (Returns były już w kalendarzu od LOG-12). Dwie osoby → aspekty MIĘDZY ich horoskopami (planeta osoby A do planety osoby B). Silnik: `find_cross_aspects(a, b, orb, luminary_bonus, minor)` — każdy obiekt A × każdy obiekt B. `obj1` = osoba A, `obj2` = osoba B. Statyczne (dwa natale, brak wspólnego czasu) → bez applying/separating. Par sztywnych (NN/SN) NIE wycinamy — między dwiema osobami to realny aspekt, nie artefakt definicji. Wspólny matcher `_first_aspect` (z find_aspects), więc orb/bonus/aspekty poboczne działają tak samo. Endpoint `POST /chart/synastry` (dwie osoby + zodiak + ustawienia aspektów) → pozycje obu + siatka aspektów z glifami. Prezentacja: zakładka „Synastria", formularz dwóch osób (pętla po a_/b_), tabela aspektów A · aspekt · B · orb. Weryfikacja na żywym API: 13+13 obiektów, 63 aspekty synastryczne z poprawnymi glifami i bonusem świateł (A.Sun ☌ B.Venus przy orbie 8.67 = 8+2). Testy: logika +4 (cross-aspekty, kolejność A/B, brak filtra par sztywnych, brak applying), prezentacja +7 (trasa, formularz dwóch osób, klient, tabela). Logika 277, prezentacja 228. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 20:55:49 +02:00
gitea	b36b3bee19	feat: konfigurowalne aspekty i orby (PRE-06) ... Dotąd orb (8°) i aspekty były zaszyte w silniku. Astrolodzy pracują na różnych orbach i lubią dokładać aspekty poboczne — teraz da się to ustawić w UI. Silnik (aspects.py): `find_aspects` przyjmuje orb, luminary_bonus i `minor`. Aspekty poboczne = tylko trzy (półsekstyl 30° / półkwadratura 45° / kwinkunks 150°) — bo mają już glify i barwy w prezentacji i w engine/glyphs.py, więc dokładają się bez ruszania czegokolwiek poza silnikiem. Bazy zwykle ich nie opisują (brak tokenu), więc trafiają na kosmogram i do tabeli, ale NIE tworzą faset — most sygnifikatorów po cichu je pomija (skip przy braku tokenu). Plumbing przez wszystkie warstwy: request logiki, build_chart, klient prezentacji, oba handlery (/, /compile) ORAZ PDF (/compile/pdf). Ustawienia wędrują między zakładkami (formsync) i lecą do PDF-a (compile.js) — żeby podsumowanie liczyło aspekty tym samym orbem co horoskop (ta sama zasada co fix podsumowania #46). UI: orb, bonus dla świateł, checkbox „aspekty poboczne" na obu formularzach. Weryfikacja na żywym /chart/positions: domyślnie 24 aspekty (główne); minor → 52 (dochodzą quincunx/semisextile/semisquare); orb 3 → 13, orb 12 → 32. Testy: logika +3 (minor/orb/bonus), prezentacja +6 (obecność pól, przekazanie przez warstwy, sync, PDF). Logika 273, prezentacja 220. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 13:16:32 +02:00
gitea	a0d1135db1	feat(prezentacja): cache-busting plików statycznych (PRE-26) ... Po deployu przeglądarka trzymała stare styles.css / *.js — ten sam URL, więc serwowała z cache mimo nowej wersji. Doklejamy do URL-a krótki HASH TREŚCI pliku: zmienił się plik → zmienił się URL → przeglądarka pobiera nowy; bez zmian URL zostaje ten sam i cache dalej działa (bustujemy tylko to, co się zmieniło). - `static_url(name)` + globalny helper Jinja `static()`: `/static/x?v=<md5[:8]>`. Hash liczony raz na proces (lru_cache) — nowy pod po deployu = świeży hash; brak pliku → `?v=0`, nie wywala strony. - Wszystkie odwołania w szablonach (styles.css, nasze *.js, vendor Leaflet) idą teraz przez helper zamiast surowego `/static/...`. Testy: +5 (hash w URL, zależny od treści, brak-pliku-bezpieczny, żaden szablon nie serwuje surowej ścieżki, base używa helpera). Test kolejności skryptów zaktualizowany pod nowy format. Prezentacja 214. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 11:22:38 +02:00
gitea	8ebce816cd	feat(prezentacja): eksport wyników do Excela — tabela robocza (DAN-23/PRE-10) ... Astrolog chce PRACOWAĆ z dopasowaniami: filtrować, sortować, zaznaczać, usuwać — najwygodniej w Excelu. Raport z logiki jest zagnieżdżony (obiekt → fasety → próbki), więc spłaszczamy go do JEDNEJ płaskiej tabeli: wiersz = jedno dopasowanie z bazy. Kolumny: Obiekt · Faseta · Typ · Token · Sygnifikator · Rozwinięcie · Opis/efekt. - `report_export.py`: `report_to_xlsx(report)` (openpyxl). Auto-filtr + zamrożony nagłówek = filtrowanie/sortowanie od razu; „Opis" zawijany. Bez ozdób — materiał roboczy. Plik składamy TU, w prezentacji (jak PDF idzie przez render): logika liczy, prezentacja formatuje wyjście. - `/interpret` dostaje akcję `export` → pobranie `.xlsx` (nie strona). Przycisk „Pobierz Excel" obok „Szukaj interpretacji". - Zależność: openpyxl (czysty Python). Zero swissepha, zero walidacji krzyżowej, zero danych od użytkownika — pierwsza z iteracji „czysto". Testy: +7 (round-trip pliku: nagłówek, spłaszczenie, auto- filtr/zamrożenie, pusty-bezpieczny, %, wpięcie w UI). Prezentacja 180. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-30 15:46:16 +02:00
gitea	52b7c20c2a	fix(prezentacja): podsumowanie bierze WSZYSTKIE policzone opcje (stacje, tabele, domy) ... Regresja: „Skompiluj" przeliczało horoskop od nowa z OKROJONYM zestawem opcji (tylko system domów + zodiak), więc jeśli przy horoskopie policzyłeś stacje, tabele (żywioły, faza Księżyca…) albo porównanie domów — w podsumowaniu ich NIE było. Zamiast pokazać to, co policzono, liczyło uboższą wersję. Zostaje czysty przelicz (bez trzymania dużego wyniku w przeglądarce), ale z TYMI SAMYMI opcjami co przy horoskopie: - `formsync`: synchronizuje między zakładkami też opcje — checkboxy (stacje, tabele) i wielo-checkbox (porównanie domów). Wcześniej umiał tylko `.value`. - „Skompiluj" (formularz): dostaje te same opcje; `compile_build` i `compile_pdf` przekazują je do logiki (stations/tables/house_systems). `compile.js` wysyła je w payloadzie PDF-a. - Wspólny plik `_result_tables.html`: podsumowanie renderuje DOKŁADNIE te same tabele co „Horoskop" (porównanie domów, stacje, aspekty, paralele, antyscja, żywioły/faza/godziny, Lots…). Każda sekcja pokazuje się tylko, gdy jej dane są w wyniku — opcja niepoliczona → sekcji nie ma (zgodnie z prośbą). (TODO: przełączyć też chart.html na ten include, by widoki nie mogły się rozjechać — na razie zgodność pilnowana ręcznie, jest komentarz w pliku.) Weryfikacja: render wspólnego pliku na bogatym wyniku pokazuje wszystkie sekcje. Testy: +8 (opcje niesione w /compile i /compile/pdf, sync checkboxów/multi, wspólny include). Prezentacja 202. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-30 14:01:42 +02:00
gitea	9b1e4dbb20	feat: wiele systemów domów naraz — porównanie obok siebie (PRE-05/LOG-05, A2a) ... Astrolodzy spierają się o systemy domów; teraz można policzyć kilka na raz i zobaczyć, jak różny podział przesuwa planety między domami. Domy to geometria z Asc/MC — osie są WSPÓLNE, różni się tylko podział. Prymarny system zostaje w `cusps`/`house_system`/`positions[].house` (pod kosmogram i wstecznie — nic się nie zmienia dla dotychczasowych ścieżek). Nowość: - logika: `build_chart(..., house_systems=[...])` → `result["house_systems"]` = pełen zestaw (prymarny pierwszy, bez duplikatów), a `positions[].houses[system]` mówi, w którym domu obiekt siedzi wg każdego systemu. Doklejane tylko gdy > 1. Nieznany system (np. placidus — dojdzie przez swisseph osobno, A2b) pomijany, nie wywala horoskopu. - endpoint `/chart/positions`: pole `house_systems`; klient prezentacji przekazuje. - UI: checkboxy „Porównaj systemy domów" (whole sign / equal / porphyry) + tabela kusp obok siebie (12 domów × systemy), stan zaznaczeń przeżywa submit. Na razie 3 systemy z czystej matmy (`houses.py`) — zero zależności, zero walidacji krzyżowej. Egzotyczne (Placidus/Koch/Regiomontanus/Campanus) dojdą przez endpoint `/houses` w silniku B (swisseph) jako A2b — maszyneria „naraz" jest już gotowa, egzotyczne tylko dopiszą kolejne wpisy. Weryfikacja: żywy /chart/positions — prymarny whole_sign, house_systems [whole_sign, equal, porphyry], 12 kusp/system, dom per system per obiekt. Testy: logika +5, prezentacja +6. Logika 270, prezentacja 179. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-29 00:03:47 +00:00
gitea	4bdfb673cc	feat(prezentacja): strefa czasowa z lokalizacji — DST-świadomy offset (PRE-03) ... „Logika dwóch lokalizacji": dotąd offset GMT był ręcznym polem (PRE-19) — trzeba było go znać i samemu pamiętać o czasie letnim. Teraz liczymy go z lokalizacji. Sedno wymagania: strefę ustalamy RAZ i trzymamy jako stałą liczbę, żeby drobna zmiana współrzędnych nie przerzuciła DST i nie „przeskoczyła" Ascendenta na sąsiedni znak. „Większa miejscowość z bazy" okazuje się zbędna — strefa IANA jest i tak regionalna, więc wioska daje tę samą strefę co pobliskie miasto. Jak: - `timezone.py`: współrzędne → strefa IANA (tzfpy, OFFLINE — bez sieci), a z niej offset DLA DATY URODZENIA. `zoneinfo`/`tzdata` znają reguły historyczne i DST: Kraków 1984 to +1h zimą, +2h latem; Katmandu +5:45. Degraduje się do None (brak biblioteki / punkt bez strefy / zła data) — wtedy zostaje ręczny offset. - Endpoint `GET /timezone?lat&lon&date&time` → {tz, offset, dst, label}. 404, gdy nie da się ustalić. - `geo.js`: po wyborze miejsca (mapa / wyszukiwarka / „Tu i teraz") oraz przy zmianie DATY (bo DST zależy od pory roku) pobiera offset i wypełnia pole tz_offset, pokazując wykrytą strefę („Wykryto: Europe/Warsaw · +2:00 (czas letni)"). Pole zostaje edytowalne. Na wejściu podpowiada tylko gdy offset wygląda na nieustawiony — nie nadpisuje wartości ręcznie wpisanej i wysłanej. Zależności (lekkie, offline): tzfpy (wheel Rust) + tzdata (dla zoneinfo w slim-obrazie). Weryfikacja: żywy serwer — Kraków 1984-06 → +2:00 (czas letni), 1984-01 → +1:00, Katmandu → +5:45. Testy: +12 strefa (moduł + endpoint), +5 JS. Prezentacja 187. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-28 22:42:31 +02:00
gitea	f5dec15e4d	feat: aspektarian, deklinacja i antyscja trafiają do raportu i PDF-a ... Zasada: co składamy, dodajemy i wyświetlamy, MA trafiać do finalnego raportu («Skompiluj») i do PDF-a — nie tylko na stronę /chart. Do tej pory do raportu i druku szło samo koło; aspektarian (etap 5) i deklinacja/antyscja (etap 6) były tylko w podglądzie horoskopu. RAPORT «Skompiluj» (podgląd): handler /compile liczy teraz wszystkie cztery rysunki, a szablon je pokazuje (koło, aspektarian, deklinacja, antyscja). PDF (usługa render) — uogólnienie z jednego rysunku na LISTĘ: - Kontrakt raportu: `figures = [{svg, caption}]` (uporządkowana). `wheel_svg` zostaje dla zgodności wstecznej jako pojedynczy rysunek. - `compile.py`: każdy SVG osobno przez rsvg-convert → PDF (fig0…figN); braki/ błędy pomijane (rysunek nie może wywalić raportu, tekst ważniejszy). - `latex.py build()`: rysunki w sekcji 3 (po danych, przed natalną) w PODANEJ kolejności, każdy z podpisem. Jedna reguła składania: keepaspectratio z limitem szerokości i wysokości — kwadratowe (koło, aspektarian) ogranicza wysokość, szerokie (deklinacja, antyscja) szerokość, bez zniekształceń. - `compile_pdf` (prezentacja): renderuje komplet w motywie DRUKU i wysyła jako `figures`. Testy: render +5 (kolejność, podpisy, zgodność wsteczna, pomijanie pustych), prezentacja +3 (raport pokazuje komplet, PDF składa komplet). Render 32, prezentacja 173. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-28 20:42:23 +02:00
gitea	adce568729	feat(prezentacja): wykres deklinacji i oś antyscji (LOG-07, kosmogram etap 6) ... Ostatni etap rysowania kosmogramu: wizualizacje pochodne z aspektów pozazodiakalnych (LOG-07). Do tej pory paralele i antyscja były tylko w tabelach — teraz widać je na rzut oka. WYKRES DEKLINACJI (`render_declination`): - Pionowa skala deklinacji z równikiem (0°) i zwrotnikami (±ε, kreskowane) — ε bierzemy z `obliquity` w wyniku, więc granica jest dokładna dla daty. - Obiekty na osi X ułożone wg POSORTOWANEJ deklinacji, więc paralele (ta sama wysokość) lądują obok siebie. Łączniki: paralela zielona (jak koniunkcja), kontrparalela czerwona (jak opozycja) — te same barwy co linie na kole, grubość wg orbu. Dymek z nazwą zjawiska i orbem. - Strefa poza zwrotnikami cieniowana; obiekt OOB (out-of-bounds) w kolorze wyróżnienia + „OOB" w dymku. Od razu widać ciała o skrajnej deklinacji. OŚ ANTYSCJI (`render_antiscia`): - Ekliptyka rozwinięta w poziomą oś ze znakami; pionowo zaznaczona oś przesileń (0° Raka/Koziorożca) — lustro antyscji — i oś równonocy (0° Barana/Wagi) dla kontrantyscji. Pary połączone łukiem (zielony antyscja / czerwony kontrantyscja), z dymkiem. Bez par oś i obiekty i tak coś mówią. Oba w obu motywach (screen + print), więc gotowe też do PDF-a. Pokazują się na /chart pod odpowiednimi tabelami LOG-07. Testy: +13 (etap 6). Prezentacja: 170. Domyka etapy kosmogramu (PRE-12): 1 szkielet, 2 obiekty, 3 aspekty, 4 dopracowanie, 5 aspektarian, 6 deklinacja/antyscja. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-28 18:27:40 +00:00
gitea	4b17f2dd67	feat(prezentacja): aspektarian — siatka aspektów (PRE-18, kosmogram etap 5) ... Trójkątna siatka aspektów obiekt×obiekt obok koła. Koło pokazuje GEOMETRIĘ aspektów (linie w środku), aspektarian domyka temat od drugiej strony — TABELĘ na jeden rzut oka: kto z kim i jak. Klasyczny „schodkowy" układ: glify obiektów biegną po przekątnej, a każda komórka pod nią to aspekt między obiektem ze swojego wiersza a obiektem ze swojej kolumny. Pusta komórka też niesie informację — że pary NIC nie łączy. Spójność z kołem trzymana świadomie: - te same barwy aspektów (niebieski harmonijny / czerwony napięty / zielony koniunkcja) — oko łapie ten sam kod na kole i w siatce; - ciasny aspekt (orb <1°) pogrubiony, tak jak grubsza linia na kole; - natywne dymki <title> (bez JS): „Słońce trygon Mars · orb 0.20° · aplikacyjny", polskie nazwy tylko w dymku — obliczenia trzymają angielskie; - oba motywy: „screen" (zmienne CSS aplikacji) i „print" (konkretne kolory + font glifów wprost), więc siatka jest gotowa też do PDF-a. Glify aspektów (☌ ☍ △ □ ⚹ ⚺ ⚻ ∠) trzymamy lokalnie w prezentacji — tam gdzie już są kolory i polskie nazwy — więc aspektarian jest samowystarczalny i nie zależy od tego, czy pojedynczy rekord aspektu niesie glif. Renderer degraduje się do pustego przy mniej niż dwóch obiektach; niekompletny obiekt (bez glifu) go nie wywala. Aspektarian pokazuje się na /chart i /compile pod kołem. Testy: +12 (etap 5). Całość prezentacji: 157. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 01:13:46 +02:00
gitea	15964dd0df	chore: wymuszenie nowego obrazu data/logic/presentation po incydencie z :latest ... Komentarz-marker w main.py każdej z trzech usług — zmienia zawartość obrazu, więc build.yaml wyprodukuje NOWE SHA-tagi z nowszym `created`. To odblokowuje image-updatera (strategia newest-build), który utknął: wszystkie trzy usługi mają w deployu tag `:latest`, którego build.yaml nigdy nie pcha (tylko SHA), więc nowe pody wpadły w ImagePullBackOff. Nowy build z realnym SHA da updaterowi co promować i przykryje `:latest` w kustomization — bez ręcznej zmiany w repo deploy. UWAGA: samo to NIE wystarczy. W namespace astrololo zniknął pull-secret `gitea-registry`, więc nawet z poprawnym tagiem nowe pody nie pobiorą obrazu. Trzeba go odtworzyć (kopia działającego `gitea-registry-creds` z ns argocd) — osobna, ręczna operacja, poza tym commitem. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 16:58:01 +02:00
gitea	f24616d342	feat(render): raport PDF przez LaTeX jako osobna usluga (PRE-24) ... Ostatnia z osmiu wskazowek partnerow. Nowa usluga services/render sklada raport: generuje plik posredni .tex i kompiluje go XeLaTeX-em do PDF. OSOBNY komponent, nie czesc prezentacji — ta sama zasada co przy izolacji swissepha (LOG-27). TeX Live wazy setki megabajtow; w obrazie produktu spowalnialby kazdy build, a tak aktualizuje sie niezaleznie i jego awaria nie kladzie aplikacji, tylko przycisk „Pobierz PDF". SZYFROWANIE, o ktore prosiles: lacze prezentacja↔render idzie tak samo jak pozostale, ale z WLASNYM, TRZECIM kluczem (LINK_KEY_PRESENTATION_RENDER). Osobny, bo tym laczem plynie CALY raport — dane urodzeniowe i opisy z baz — wiec przejecie go nie moze otwierac lacza do logiki ani do danych. Fail-closed: bez klucza pod nie wstaje. Test kopii link_crypto obejmuje teraz cztery uslugi. Uklad PDF wg prosby: imie i nazwisko -> wprowadzone dane -> RYSUNEK kosmogramu -> interpretacja natalna -> predykcje okresowe. Test pilnuje kolejnosci. Dwie rzeczy, ktore wyszly dopiero przy skladaniu tego kawalka: 1. KOSMOGRAM NIE NADAWAL SIE DO PDF. Uzywa zmiennych CSS (var(--line)) i klasy .glyph, ktorej font podaje styles.css — a samodzielny konwerter SVG→PDF nie zna naszego arkusza. Wyszlyby czarne kreski BEZ SYMBOLI. Stad wariant „print": konkretne kolory na bialym tle i font glifow wpisany wprost w rysunek. Przy okazji zalatwia to etap 4 planu kola (wariant do druku). 2. UCIECZKA ZNAKOW LATEXA byla zepsuta — i zlapal to moj wlasny test. Zamiana „\” na \textbackslash{} szla w tej samej petli co nawiasy, wiec kolejne podmiany ucieklyby nawiasy dopiero co wstawione: wychodzilo \textbackslash\{\}. Poprawka: ukosnik chowany pod znacznik zastepczy i rozwijany na koncu. To nie kosmetyka — niezauwazony „%” komentuje RESZTE LINII, wiec zdanie od modelu urywaloby sie w polowie, a PDF powstawalby normalnie, tylko krotszy. Test na wrogim tekscie sprawdza tez, ze \end{document} ani \input{} nie wyrwa sie z dokumentu. Usluga nie zapisuje nic poza katalogiem tymczasowym, ktory sprzata po sobie; w manifescie readOnlyRootFilesystem + emptyDir na /tmp. /health raportuje obecnosc xelatex i rsvg-convert, zeby zepsuty obraz bylo widac od razu. Zweryfikowane na zywo (TestClient uslugi render): zadanie bez szyfrowania z POPRAWNYM tokenem -> 400; obcy klucz -> 400 i tajny opis nie wraca; wlasciwy klucz -> zadanie dochodzi do aplikacji, tresci baz NIE MA na kablu, odpowiedz zaszyfrowana. Manifesty przechodza kubectl apply --dry-run=server na zywym klastrze. CZEGO NIE SPRAWDZILEM: samej kompilacji PDF. W tym srodowisku nie ma ani TeX Live, ani dzialajacego runtime'u kontenerow (docker CLI jest, daemon nie) — probowalem zbudowac obraz i sie nie dalo. Sprawdzone jest wszystko dookola: generowanie .tex, ucieczka znakow, szyfrowanie, kontrakt API, samowystarczalnosc SVG. Pierwsze uruchomienie na klastrze trzeba obejrzec — dlatego PRE-24 zostaje jako „W trakcie", nie „Zrobione". Instrukcja wdrozenia: docs/wdrozenie-render-pdf.md (klucz, obraz, merge, weryfikacja, znane ograniczenia). Testy: 15 nowych (render) + 14 (lacze i wariant druku w prezentacji). Calosc: prezentacja 131, logika 265/1 skip, render 15. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 19:21:49 +02:00
gitea	6c9029c496	feat(prezentacja): zakladka „Skompiluj" — zbiorczy raport (PRE-23) ... Czwarta wskazowka partnerow. Nowa zakladka sklada w jedno trzy kawalki liczone w roznych miejscach: policzony horoskop, interpretacje natalna z AI i wszystkie zapamietane predykcje okresowe. Uklad sekcji dokladnie wg prosby: imie i nazwisko -> wprowadzone dane -> RYSUNEK kosmogramu -> interpretacja natalna -> predykcje okresowe. Test pilnuje tej kolejnosci, bo to jedyna rzecz, ktora latwo przestawic przy refaktorze, a partnerzy podali ja wprost. Skad material: - HOROSKOP liczymy TU NA NOWO z danych formularza, zamiast go zapamietywac. To czysta funkcja wejscia — tanio powtorzyc, a odpada trzymanie w przegladarce duzego wyniku, ktory moglby sie rozjechac z aktualnym formularzem. - INTERPRETACJA NATALNA — nowy natal.js, odpowiednik predictions.js. Natalna jest JEDNA (dotyczy momentu urodzenia, nie okresu), wiec ponowne wygenerowanie podmienia slot zamiast dokladac wpis. - PREDYKCJE — z magazynu z PRE-22. compile.js czyta magazyny przez ICH API (window.astrololoNatal / astrololoPredictions), a nie siegajac wprost do localStorage — format danych ma jednego wlasciciela: modul, ktory je zapisuje. Test tego pilnuje. Zakladka MOWI, CZEGO BRAKUJE: panel gotowosci z trzema pozycjami i podpowiedzia, na ktorej zakladce uzupelnic. Bez tego uzytkownik zlozylby niekompletny raport i dowiedzialby sie o tym dopiero po otwarciu PDF-a. Tresc od modelu jest ESKEJPOWANA przed wstawieniem do DOM — to tekst z zewnatrz, wiec bez tego mielibysmy wektor wstrzykniecia. Weryfikacja na zywej aplikacji: dwie predykcje zapisane w Kalendarzu, natalna w Interpretacjach, obie odczytane na Skompiluj (panel: brak horoskopu na zolto, dwa pozostale na zielono). Po zlozeniu wszystkie trzy zielone, a raport zaczyna sie od „Jan Kowalski" i danych wejsciowych. Kolejnosc sekcji sprawdzona na wyrenderowanym HTML: naglowek 2931 < dane 3033 < kosmogram 3158 < natalna 26544 < predykcje 26575. Testy: 16 nowych. Poprawione tez trzy wlasne testy, ktore lapaly nazwy plikow w KOMENTARZACH zamiast w tagach skryptow. Calosc: prezentacja 117 passed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 18:09:56 +02:00
gitea	f34016a4a5	feat(prezentacja): wspolne dane formularza miedzy zakladkami + imie i nazwisko (PRE-21) ... Trzecia wskazowka partnerow. Kazda zakladke (Horoskop / Interpretacje / Kalendarz) wypelnialo sie od nowa — te same imie, data, godzina, strefa i miejsce. Teraz raz wpisane dane wedruja za uzytkownikiem, a zmiana w jednej zakladce przenosi sie na pozostale. Nowy formsync.js trzyma stan w localStorage. Dlaczego nie sesja na serwerze: serwer zostaje BEZSTANOWY — zadnego magazynu sesji, zadnych danych urodzeniowych trzymanych po stronie uslugi (spojne z postawa z LOG-32/PRE-16). Przy okazji dane synchronizuja sie tez miedzy osobnymi kartami przegladarki, bo zdarzenie `storage` daje to za darmo. Dolozone pole „imie i nazwisko" (wszystkie trzy zakladki) — potrzebne do naglowka raportu PDF (PRE-24). Handlery przyjmuja je i oddaja, wiec nie znika po przeliczeniu. Dwie rzeczy, ktore trzeba bylo domknac, zeby to dzialalo naprawde: 1. KOLEJNOSC SKRYPTOW. formsync.js ladowany w <head> z `defer` — skrypty defer wykonuja sie w kolejnosci dokumentu, wiec ten zdazy odtworzyc wspolrzedne, ZANIM geo.js zbuduje mape. Mapa startuje od razu we wlasciwym miejscu, zamiast przeskakiwac po chwili. 2. geo.js ustawia pola z KODU (`.value = ...`), co samo z siebie NIE wywoluje zdarzen — bez tego synchronizacja przegapilaby kazdy wybor z mapy, z wyszukiwarki i z „Tu i teraz". Dolozony setVal(), ktory jawnie zglasza `change`. Zakladka bez danego pola (np. Sygnifikatory) nie kasuje wartosci zapamietanej gdzie indziej; uszkodzony wpis w localStorage nie blokuje formularza. Q-14 rozstrzygniete: lancuch LaTeX->PDF stanie jako OSOBNA USLUGA render — spojne z izolacja swisseph (LOG-27), obraz produktu zostaje maly. Weryfikacja na zywym stacku (data+logika+prezentacja) w przegladarce: dane wpisane w Horoskopie pojawily sie w Interpretacjach; zmiana godziny w Interpretacjach dotarla do Kalendarza; pola nieobecne na zakladce (zodiak, system domow) przetrwaly; po POST imie zostalo, a horoskop policzyl sie normalnie. Testy: 22 nowe strukturalne. Calosc: prezentacja 67 passed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 15:12:49 +00:00
gitea	1d7f3e2136	feat(prezentacja): szkielet kosmogramu — koło horoskopowe SVG (PRE-12) ... Pierwszy krok rysowania wykresu (PRE-12): SZKIELET koła — pierścień znaków, podział na domy i osie. Planety i linie aspektów w kolejnych iteracjach. Rysowane po stronie serwera jako czysty string SVG (bez zależności zewnętrznych — spójne z CSP). Ciemny motyw, spójny z paletą aplikacji (kolory z --line, --accent, --muted; glify znaków barwione wg żywiołu w stonowanych kolorach czytelnych na ciemnym tle). Geometria wg konwencji astrologicznej: Ascendent po LEWEJ, długość ekliptyczna rośnie przeciwnie do ruchu wskazówek zegara. Punkt λ → kąt φ = 180° − (λ − Asc); w SVG y rośnie w dół, co formuła uwzględnia. Zakotwiczenie sprawdzone testami liczbowo: Asc po lewej, Dsc po prawej, oś pozioma; Asc+90° (II dom) na dole. Elementy: dwa okręgi + piasta, podziałki co 5°/10°, granice znaków co 30° z glifem w środku sektora, szprychy domów od pasa do piasty, numery domów w środku każdego domu, osie Asc–Dsc i MC–IC wyróżnione akcentem z etykietami AC/DC/MC/IC. Dane bierzemy WYŁĄCZNIE z wyniku /chart/positions — prezentacja nic nie liczy: - `sign_glyphs` (pierścień 12 znaków) i glify — z LOG-22, - `angles` z długością `decimal` — już były, - `cusps` z `decimal` — DOŁOŻONE w tym PR (jedna linia w build_chart). Bez tego domy dało się narysować tylko dla whole sign; z długością cuspu działa dla KAŻDEGO systemu. Zweryfikowane na porphyry: cuspy poza wielokrotnościami 30°, szprychy odchodzą od granic znaków. Degradacja: silnik bez osi/domów albo starszy wynik bez `decimal` w cuspach → brak koła (pusty string), nie wyjątek. Testy: 8 (poprawność XML, 12 glifów, 4 osie, numery domów, Asc po lewej liczbowo, CCW, degradacja). Całość: prezentacja 33 passed, logika 265 / 1 skipped. Render potwierdzony wizualnie na horoskopie referencyjnym (AC=Leo po lewej, MC=Aries u góry, domy CCW). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 12:32:47 +02:00
gitea	473d059a6a	feat(logic): tabele pomocnicze horoskopu (LOG-23) ... Komplet wyliczen, ktore astrolog czyta „obok" pozycji: - bilans zywiolow i jakosci w czterech wariantach (7 klasycznych / 10 z nowozytnymi, z Ascendentem i bez) + wykrywanie BRAKUJACYCH zywiolow — klasyczne „no air", podstawa pod scoring sily (LOG-21), - faza Ksiezyca: elongacja, nazwa fazy, procent oswietlenia, przybywa/ubywa, - stopnie krytyczne wg jakosci znaku (kardynalne 0/13/26, stale 8/21, zmienne 4/17) + 29 stopien anaretyczny i 0 stopni wejscia w znak, - dzien i godziny planetarne w porzadku chaldejskim, - syzygia prenatalna (ostatni now albo pelnia przed urodzeniem), - podzialy: dwunastniki (D12) i nawamsa (D9). Dwie rzeczy wymagaly prawdziwego liczenia, nie tabelki: * godziny planetarne sa NIEROWNE — dzien od wschodu do zachodu dzieli sie na 12, noc osobno. Bez faktycznego wschodu/zachodu wynik bylby zmyslony, wiec szukamy ich numerycznie (przejscie wysokosci Slonca przez -0°50', bisekcja jak przy stacjach z LOG-03). Doba planetarna startuje o WSCHODZIE, nie o polnocy. * syzygia prenatalna — szukanie wstecz przejscia elongacji przez 0/180 stopni. Walidacja wobec faktow NIEZALEZNYCH od naszego kodu: - 30.04.1984 to poniedzialek -> wladca dnia Ksiezyc; 5. godzina poniedzialku w porzadku chaldejskim to Slonce (Mo, Sa, Ju, Ma, Su) — zgadza sie, - wschod/zachod dla Krakowa: 03:18 / 17:57 UTC = 5:18 / 19:57 lokalnie — zgodne z rzeczywistoscia dla konca kwietnia, - syzygia: pelnia 15.04.1984 19:10:45 UTC; rzeczywista byla 19:11 — roznica ponizej minuty, - bilans przeliczony recznie: Ogien 4, Ziemia 4, Woda 3, Powietrze 0. UI: checkbox „tabele dodatkowe" na ekranie Horoskop (opt-in, bo szuka numerycznie) i sekcja wynikow. Endpoint: /chart/positions?tables=true. Testy: 28 nowych (w tym noc polarna -> brak godzin planetarnych, oraz sprawdzenie, ze w znalezionej syzygii elongacja FAKTYCZNIE wynosi 0/180). Calosc: 202 passed / 1 skipped + 17 (prezentacja). Zweryfikowane e2e w UI. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-23 13:34:01 +00:00
gitea	114b7eebdf	feat(ui): okno postepu z logiem podczas pisania horoskopu ... Generowanie trwa minutami, a zwykly POST nie dawal zadnego sygnalu — aplikacja wygladala na zawieszona. Teraz w trakcie pracy pojawia sie okno z logiem, zegarem i spinnerem. Log pokazuje RZECZYWISTE zdarzenia z serwera, nie udawany pasek postepu: - app/progress.py — strumien NDJSON; praca leci w watku roboczym, generator odpompowuje kolejke, wiec zdarzenia docz w TRAKCIE pracy, nie na koncu; heartbeat co 10s, zeby proxy nie uznalo polaczenia za martwe, - providers.generate(..., on_event) — raportuje kazda ture (start, czas trwania, liczba znakow, czy urwana), bo to tura trwa, - POST /chart/horoscope/stream w logice + proxy /horoscope/stream w prezentacji. Wynik: ostatnie zdarzenie niesie GOTOWY HTML wyrenderowany z tego samego szablonu, ktory renderuje przeladowanie strony (_prompt_result.html wydzielony z _prompt_block.html). Jedno zrodlo prawdy dla wygladu wyniku — okno wstawia go bez przeladowania. Degradacja: bez strumieniowania w przegladarce formularz idzie klasycznie i wszystko dziala jak wczesniej, tylko bez okna. Blad polaczenia konczy sie komunikatem w logu, nie cisza. BLAD ZNALEZIONY PRZY TESCIE NA ZYWO: petla kontynuacji odejmowala od budzetu ZAMOWIONY limit tury zamiast tokenow faktycznie wyprodukowanych — pierwsza tura zjadala caly budzet, wiec urwana odpowiedz nigdy nie doczekala sie dokonczenia i wracala do uzytkownika jako calosc. Naprawione i pokryte testem regresyjnym. Testy: 176 passed / 1 skipped (logika) + 17 (prezentacja). Zweryfikowane na zywo z wolna atrapa modelu: zdarzenia z poprawnymi czasami, okno z 11 liniami logu, wynik wstawiony bez przeladowania strony. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-22 22:58:56 +02:00
gitea	163ace4283	feat(ui): interaktywny wybor modelu u dostawcy ... Uzytkownik wybiera nie tylko dostawce, ale konkretny model — Fable czy Opus u Anthropica, gpt-4o-mini czy gpt-5 u OpenAI, cokolwiek ma pobrane lokalnie. - app/llm/catalog.py: podpowiedzi modeli per dostawca wraz z oknem kontekstu, nadpisywalne przez <DOSTAWCA>_MODELS; GET /llm/models wystawia je dla UI. - Pole modelu w UI jest TEKSTOWE z datalista, nie zamknietym <select> — konto moze miec dostep do modeli, o ktorych kod nie wie, a nowe wychodza szybciej, niz aktualizuje sie katalog. Puste pole = model domyslny dostawcy. - static/models.js: zmiana dostawcy przelacza podpowiedzi, podmienia placeholder na model domyslny i pokazuje okno kontekstu wybranego modelu. - build_provider(name, model) — model z zadania wygrywa nad konfiguracja. WAZNE (znalezione przy tescie e2e): liczenie budzetu „maksymalny kontekst modelu" szlo przez build_provider(), ktory WYMAGA klucza API — bez klucza budzet cicho spadal do wartosci zapasowej i byl identyczny dla wszystkich modeli Anthropic. Budzet zalezy wylacznie od okna kontekstu, wiec doszlo resolve_model(), ktore rozwiazuje nazwe modelu bez budowania dostawcy. Teraz budzet realnie sie rozni: Opus/Fable 3,48 mln znakow, Haiku 536 tys., gpt-4o-mini 438 tys., llama3.1 8 tys. Pewnosc danych w katalogu: modele Anthropic pochodza z oficjalnej dokumentacji API (okna i limity zgodne z limits.py); modele OpenAI to podpowiedzi, ktorych nie weryfikowalem; lokalne zaleza od tego, co masz pobrane. Testy: 174 passed / 1 skipped (logika) + 17 (prezentacja). Nowy test strukturalny pilnuje, ze KAZDE wywolanie w dol niesie wybrany model i dostawce — dokladnie ta klasa bledu zlapala brakujacy parametr przy horoskopie okresowym. Zweryfikowane w przegladarce: przelaczanie dostawcy podmienia liste modeli. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-22 21:40:19 +02:00
gitea	f33cdc88f4	feat(llm): horoskop powstaje zawsze — kontynuacja, okna kontekstu, budzet max ... PRZYCZYNA PUSTYCH ODPOWIEDZI NA ANTHROPICU (potwierdzona w dokumentacji API): domyslnym modelem byl `claude-sonnet-5`, ktory przy POMINIETYM parametrze `thinking` wlacza myslenie adaptacyjne, a `thinking.display` domyslnie jest "omitted". Tokeny myslenia licza sie do max_tokens, wiec przy LLM_MAX_TOKENS=2000 cala tura wychodzila jako bloki `thinking` z pustym tekstem — parser filtrowal type=="text" i zwracal pusty string. Opus 4.8 bez `thinking` nie mysli, wiec tam objaw by nie wystapil. Gwarancja niepustej odpowiedzi (wszyscy trzej dostawcy): - generate() to teraz PETLA, nie pojedynczy strzal: tura -> jesli urwana na limicie, dopisz ture „kontynuuj" w tej samej rozmowie i sklej tekst, - tura zlozona z samego myslenia traktowana jak urwana (nie jak pustka), - pusta i NIE urwana -> jedna proba z podpowiedzia, dopiero potem blad, - kontynuacja konczy sie tura UZYTKOWNIKA — Claude odrzuca prefill asystenta (400), - `thinking` konfigurowany JAWNIE (adaptive + effort=high; ANTHROPIC_THINKING=off). Okna kontekstu i rezerwa na odpowiedz (app/llm/limits.py): - tabela okien/limitow wyjscia per model + nadpisanie z ENV, - plan() liczy okno odpowiedzi jako okno - prompt - margines i NIGDY nie oddaje calego kontekstu promptowi, - Anthropic liczy tokeny DOKLADNIE (/v1/messages/count_tokens), reszta szacuje, - >90 tys. tokenow promptu -> ostrzezenie, ale wyslanie NADAL mozliwe i z pelnym oknem odpowiedzi. UI: suwak budzetu rozszerzony o „bardzo obszerny" i „maksymalny kontekst modelu" (liczony z okna wybranego modelu po odjeciu rezerwy); przy wyniku widac plan tokenow, liczbe tur i ostrzezenia. Domyslny model Anthropic: claude-opus-4-8. Testy: 170 passed / 1 skipped (logika) + 15 (prezentacja). Nowe testy pokrywaja sklejanie kontynuacji, brak prefillu asystenta, ture z samego myslenia, rezerwe na odpowiedz i prog ostrzezenia. Zweryfikowane e2e na atrapie Anthropica odtwarzajacej zgloszony objaw: 3 tury, obie czesci tekstu obecne. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-22 21:40:19 +02:00
gitea	4ef90b30bc	feat(logic): dostawcy LLM i pisanie horoskopu (LOG-31) ... Domyslnie model LOKALNY — prompt niesie oryginalne opisy z baz, wiec domyslnie NIC nie opuszcza sieci. Chmura wlaczana swiadomie (LOG-32). - app/llm/: LLMProvider (jak EphemerisEngine z LOG-24) + dwie implementacje. Lokalny serwer modelu (Ollama/vLLM/llama.cpp) i OpenAI mowia TYM SAMYM protokolem /chat/completions, wiec obsluguje je jedna klasa; Anthropic ma wlasny /v1/messages. Napisane na samym httpx — bez SDK openai/anthropic: mniej zaleznosci i pelna kontrola nad tym, co wychodzi z sieci. - Kazdy dostawca deklaruje `leaves_lan` — interfejs MUSI jawnie mowic, czy tresc baz opuszcza siec; UI na tej podstawie ostrzega. - Ponawianie z backoffem (429/5xx), timeouty, czytelne bledy zamiast stacktrace. - Klucz wylacznie z LLM_API_KEY (sekret), nigdy w repo ani w UI. - POST /chart/horoscope + GET /llm/health. WAZNE: prompt jest zwracany ZAWSZE — takze gdy model padnie lub brakuje klucza. Dzieki temu awaria dostawcy nie blokuje pracy: prompt mozna skopiowac i uzyc recznie. Prezentacja: wybor modelu (lokalny/Anthropic/OpenAI), przycisk „Napisz horoskop (AI)", wynik z informacja kto go napisal, czy dane opuscily siec, ile wskazan weszlo, oraz zastrzezenie ze to nie porada medyczna (PRE-15). Testy: 13 nowych (transport podstawiony — zaden prawdziwy model nie wolany), calosc 131 passed / 1 skipped. Zweryfikowane e2e na atrapie serwera modelu: horoskop napisany, leaves_lan=false, tokeny zliczone; a przy padnietym modelu / braku klucza / zlym dostawcy — czytelny blad i zachowany prompt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-21 20:34:07 +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	04b26afa6d	feat(logic): generator promptow do LLM + budzetowanie (LOG-29, LOG-30) ... Pierwszy krok ustalonej kolejnosci: prompt z podgladem, uzyteczny od razu BEZ integracji API (ta przyjdzie w LOG-31). LOG-29 — app/prompt.py: - profil natal (ekran Interpretacje) i period (ekran Kalendarz), - prompt po polsku: zadanie -> dane horoskopu (pozycje, osie, Lots, aspekty, sekta, zodiak) -> wskazania z baz wg wagi -> instrukcje -> zastrzezenie, - twarde reguly: kazda teza musi cytowac konkretny sygnifikator, zakaz wychodzenia poza dostarczone dane, jawne wskazanie sprzecznosci, - deterministyczny: ten sam horoskop + budzet = ten sam prompt. LOG-30 — redukcja do budzetu (concise/medium/extensive): dedup -> grupowanie z licznikiem -> sortowanie wg punktacji sily (LOG-21) -> obciecie ogona (jednostka = CALE wskazanie) -> skracanie dlugich opisow. Statystyki zwracaja ile weszlo/pominieto i jaki byl prog — takze w tresci promptu, zeby model wiedzial, ze widzi wybor. POST /chart/prompt — zwraca sam prompt + statystyki, bez wolania modelu. Prezentacja: przycisk „Generuj prompt (AI)" na obu ekranach, wybor budzetu, pole z promptem + kopiowanie (z fallbackiem dla http bez secure context). WAZNE (znalezione przy tescie e2e): padnieta warstwa danych zabiera tylko wskazania — horoskop i OS CZASU zostaja, bo sa czysto obliczeniowe. Wczesniej blad bazy gubil cala osie czasu, czyniac prognoze okresowa bezuzyteczna. Zabezpieczone testem. Testy: 19 nowych, calosc 118 passed / 1 skipped. Zweryfikowane e2e w przegladarce: profil natal (3340 znakow) i period (15 zdarzen, 4728 znakow). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-21 16:44:17 +00:00
gitea	6f87b2b323	feat(logic): systemy zodiaku — syderyczny, draconic (LOG-04) ... Jedyne wymaganie Must bez implementacji. Nowy zodiac.py + wpiecie w horoskop: - zodiac.py: ayanamsy (Lahiri, Fagan-Bradley, Krishnamurti) modelem ayan(jd)=ayan0+B*x+C*x^2 (wspolna precesja, rozna stala) — skalibrowanym do Swiss Ephemeris jako WYROCZNI: zgodnosc do ~0,02" w latach 1900-2100. Draconic = wzgledem wzla wznoszacego (wzel = 0 Barana). RA: konwersja ekliptyka->rownik (to_equatorial) na przyszly widok rownikowy. - chart.py: build_chart(..., zodiac): offset jednolicie przesuwa etykiety znakow/dlugosci obiektow, osi, cusps i Lots; DOMY licza sie po dlugosci tropikalnej (geometria niezmiennicza wzgledem obrotu -> numery domow bez zmian). Domyslnie tropical -> sciezka i wyniki bez zmian. - main.py: /chart/positions przyjmuje `zodiac`; bledny -> 422. - prezentacja: dropdown „Zodiak" + pokazanie ayanamshy w wynikach. Testy (14): ayanamsy vs wyrocznia swisseph (<0.1"), julian_day, draconic (wzel=0 Barana), niezmienniczosc domow, RA w punktach charakterystycznych, odrzucenie bledow. Cala logika: 99 passed, 1 skipped. Zweryfikowane e2e w przegladarce (horoskop syderyczny Lahiri: Slonce Aries 16°34', ayan 23.6382). RA jako osobny widok zodiaku (per-obiekt, z szerokoscia) — do osobnego PR. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-21 14:32:51 +00:00
gitea	a2aabd37a5	feat(presentation): wyszukiwarka lokalizacji + mapa (OSM/Leaflet) ... QoL 2/2: pole „Szukaj miejsca" (nazwa/adres/POI) + interaktywna mapa na formularzach horoskopu / interpretacji / kalendarza. Bez klucza API. - geocode.py: proxy OSM/Nominatim PO STRONIE SERWERA (poprawny User-Agent, throttling ~1 req/s, cache TTL 1h) — endpointy /geocode i /reverse. Wolanie z serwera, nie z przegladarki: latwiej trzymac polityke Nominatim i dziala niezaleznie od secure-context (http://<ip>). - _location_picker.html: wspolny partial (search + wyniki + mapa + atrybucja), wpiety includem do 3 formularzy z polami lat/lon. - geo.js: Leaflet — wyszukiwanie (debounce), klik na wynik ustawia lat/lon i centruje mape, klik/drag pineski ustawia wspolrzedne + /reverse pokazuje nazwe; sync z „Tu i teraz" (now.js emituje event astrololo:coords). - Leaflet 1.9.4 vendorowany lokalnie (static/vendor/leaflet, BSD-2-Clause, permisywny) — niezaleznosc od CDN; kafelki mapy z OSM. Marker jako divIcon (bez plikow PNG). - styles.css: style pod ciemny motyw. Zweryfikowane w przegladarce: domyslny widok (pineska na Szpitalu Barlickiego), wyszukanie „Wawel Krakow" -> lista -> klik ustawia 50.0547/19.9361 i przesuwa mape, klik w mape ustawia wspolrzedne + reverse wypelnia nazwe. Zero bledow w konsoli. /geocode i /reverse zwracaja szpital; cache dziala. Uwaga wdrozeniowa: pod prezentacji potrzebuje egressu do nominatim.openstreetmap.org; przegladarki — do tile.openstreetmap.org. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-21 03:32:07 +02:00
gitea	de5d58958c	feat(presentation): domyslna lokalizacja = Szpital Barlickiego, Lodz ... QoL: formularze (horoskop / interpretacje / kalendarz) maja wstepnie wpisana lokalizacje urodzenia wlasciciela — Szpital Barlickiego w Lodzi (51.7739N, 19.4829E; potwierdzone reverse-geokodowaniem OSM: Kopcinskiego 22/28). Nie trzeba jej wpisywac za kazdym razem. - config.py: jedno zrodlo prawdy (DEFAULT_LAT/LON/LABEL, nadpisywalne ENV) + helper default_form(). - main.py: GET wstrzykuje default_form() + location_label do 3 formularzy z polami lokalizacji (significators pominiete — nie ma tam lat/lon). - szablony: dyskretna podpowiedz z nazwa lokalizacji, widoczna tylko na czystym formularzu (po POST znika, wygrywa wpisana wartosc). - „Tu i teraz" nadal nadpisuje domyslne wspolrzedne geolokalizacja. Zweryfikowane TestClientem: 3 strony renderuja 51.7739/19.4829 + etykiete; POST z innymi wspolrzednymi je zachowuje i chowa podpowiedz. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-21 01:16:24 +00:00
gitea	c4a181b810	Spięcie osi czasu z bazą interpretacji i widokiem (LOG-14, 1B->2B) ... Realizuje przepływ 1B->2B z notes2: predykcyjne sygnifikatory (z datami) dopasowane do interpretacji z bazy. Logika: - timeline.py: zdarzenia niosą strukturę (directed/aspect/target dla dyrekcji, lord/sign dla profekcji) do budowy tokenów. - significators.interpret_events + _event_tokens: z każdego zdarzenia buduje tokeny bazy (dyrekcja: [planeta][aspekt][cel]; profekcja: [władca][znak]) i dopina interpretacje reużywając _facet_samples (AND tokenów, dedup, rozwinięcie). - /chart/timeline: flaga interpret=true. Prezentacja: - nowa strona /timeline "Kalendarz": formularz (urodzenie + zakres dat) -> oś czasu z technikami, datami i interpretacjami; nawigacja + wspólne now.js. Walidacja E2E na realnym main_base.xlsx (2025-2026): - dyr. Saturn kwadratura MC -> 50 interpret. ("...5th house" -> "abortion/miscarriage") - Władca Roku Saturn (wiek 42) -> 63; strona renderuje badge dat/technik. 71 testów przechodzi (nowy test_timeline_interpret). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-11 12:31:50 +02:00
gitea	a8c3072e62	Węzły księżycowe, mean Lilith i wykrywanie stacji (LOG-02/03) ... 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>	2026-07-08 10:51:29 +02:00
gitea	f6323cac10	Ranking siły (LOG-21) + grupowanie identycznych opisów + geolokalizacja ... Punktacja siły (LOG-21): - scoring.py: siła fasety z sygnałów obliczalnych (typ fasety, rodzaj aspektu, ciasnota orbu). Konfigurowalne wagi. Hook na przyszłość: kolumny countas*/level* z SIGNIFICATORS KEY (obecnie puste). - aspekty niosą orb+allowed; fasety dostają "score"; ranking faset malejąco. Grupowanie: - opcja group: zwija próbki po opisie (ten sam efekt = jedna grupa z listą sygnifikatorów i licznikiem). Checkbox "grupuj identyczne opisy" w /interpret. Geolokalizacja (bajer): - "Tu i teraz" (widok Horoskop i Interpretacje) uzupełnia lat/lon z przeglądarki (navigator.geolocation; wymaga zgody, https/localhost). Zweryfikowano na realnym main_base.xlsx: ranking sensowny (ciasna opozycja z Saturn 9.59 > szeroka koniunkcja z Moon 6.25 > znak/dom 5.0); grupowanie zwija powtórzone opisy. 41 testów przechodzi. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-05 01:16:47 +02:00
gitea	dabbaef9dd	Merge branch 'master' into feat/search-integration	2026-07-01 15:03:12 +02:00
gitea	eef67d37b5	Wyszukiwarka: wynik obliczeń szukany w bazie interpretacji ... Pierwsza wersja mostu horoskop -> sygnifikatory -> baza (zalążek LOG-16/18/19). - logic/significators.py: z pozycji generuje tokeny w składni bazy (planeta [Su, znak [Tau...), pyta warstwę danych o rekordy z tokenem planety i zawęża do tych, które wspominają też jej znak ("planeta w swoim znaku"); odsiewa szum. - logic /chart/report: nowy endpoint (pozycje -> raport dopasowań z interpretacjami). - logic DataClient.search: parametr fields (lżejszy payload). - data: naprawa str.contains regex=True -> regex=False (sygnifikatory zawierają [ + itd., metaznaki regex); podniesiony górny limit zapytania (le=50000). - prezentacja: strona /interpret (formularz -> wyszukane interpretacje per obiekt) + nawigacja. Zweryfikowano end-to-end na realnym pliku (Encyclopaedia of Medical Astrology, 53969 wierszy): dla horoskopu 30.04.1984 znaleziono m.in. Sun w Taurus 46, Mars w Scorpio 57, Saturn w Scorpio 61 dopasowań; przykłady: "[Su in [Tau" -> "the bump of amativeness prominent". 15 testów przechodzi. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-01 14:57:26 +02:00
gitea	94c3023d3a	Silnik: osie (Asc/MC) i systemy domów (LOG-05) ... Kontynuacja silnika efemeryd o osie i domy. - engine/houses.py: czysta matematyka sferyczna — Asc, MC (z RAMC + ε + φ), cusps dla Whole Sign / Equal / Porphyry, przypisanie obiektu do domu. - SkyfieldEngine.sidereal(): RAMC (lokalny apparent ST) + średnie nachylenie ekliptyki ze Skyfielda. - engine/chart.py: build_chart() składa pełny horoskop (pozycje + osie + domy). - Endpoint /chart/positions rozszerzony o house_system i zwraca angles + cusps + numer domu per obiekt. - Prezentacja: lokalizacja i wybór systemu domów w formularzu, tabela osi, kolumna Dom, rozwijane cusps. Walidacja względem astro.com (30.04.1984, Warszawa): Asc Can 22°10'43", MC Pis 22°35'29" (~1' od referencji); wszystkie przypisania domów Whole Sign zgodne (Sun 11, Mercury 10, Mars 5, ...). 20 testów przechodzi. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-01 14:06:13 +02:00
gitea	3195d9b003	Warstwa prezentacji: widok horoskopu do ręcznego testowania ... Strona główna "/" = formularz podstawowych danych momentu (data, godzina, strefa, opcjonalnie lokalizacja) → tabela policzonych pozycji w formie human-readable (znak, pozycja w znaku, absolutna, kierunek, prędkość). Woła logic /chart/positions; przelicza czas lokalny + offset na UTC. Przycisk "Tu i teraz" uzupełnia bieżącą datę/godzinę i strefę przeglądarki. Retrogradacja wyróżniona w tabeli. Wyszukiwarkę sygnifikatorów przeniesiono pod "/significants" -> /significators, dodano nawigację (base.html). Czytelny komunikat, gdy logika nie ma jeszcze endpointu silnika. Zweryfikowano end-to-end: formularz → przeliczenie UTC → render tabeli (przez stub kontraktu /chart/positions). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-27 20:08:43 +02:00
gitea	16d35c16dc	Szkielet aplikacji trójwarstwowej (prezentacja / logika / dane) ... Trzy niezależne usługi FastAPI komunikujące się przez HTTP/JSON, każda zna tylko adres warstwy bezpośrednio pod nią: - presentation (:8000) — strona WWW + formularz - logic (:8001) — reguły biznesowe, pośrednik - data (:8002) — wyszukiwanie danych za interfejsem DataProvider Warstwa danych: czytanie setek plików .xlsx z wykrywaniem nagłówka i mapowaniem układu kolumn na schemat kanoniczny, z 4-poziomowym cache (schemat L1, Parquet L2, wyniki zapytań L3, odwrócony indeks L4) i unieważnianiem po odcisku pliku. Gotowa ścieżka migracji do SQL (ingest/to_sql.py + SqlDataProvider, przełączane przez DATA_PROVIDER). Zawiera docker-compose, Makefile, generator danych przykładowych. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-26 17:35:09 +02:00