6 Commits

Author	SHA1	Message	Date
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	623603b157	feat: Markdown→LaTeX w PDF + dopracowanie kosmogramu (PRE-24, PRE-12 etap 4) ... Dwie rzeczy w jednym PR (na prośbę). 1) MARKDOWN → LATEX w raporcie PDF (usługa render). Tekst od AI to markdown — świetny w przeglądarce, ale w PDF `**gwiazdki**` i `## kratki` to dosłowny szum. Nowy markdown_to_latex zamienia je na PRAWDZIWE formatowanie: nagłówki (degradowane o poziom, żeby wpadły pod nasz \section „Interpretacja natalna", nie obok), pogrubienia, kursywy, kod, listy punktowe i numerowane, linki (zostaje sam tekst, URL bezużyteczny w druku). Skaner liniowy, nie regex na całości — listy i akapity są wielolinijkowe. Ucieczka znaków LaTeXa działa TAKŻE wewnątrz formatowania: `**wzrost 50%**` daje `\textbf{wzrost 50\%}`, a nie zakomentowaną resztę linii. Sprawdzone na wrogim tekście — `\end{document}` i `\input{}` w treści nie wyrywają się z dokumentu nawet zawinięte w pogrubienie. 2) KOSMOGRAM — etap 4 (dopracowanie): - Lots na kole: Fortuna ⊗ (jedyny Lot ze standardowym glifem) na promieniu POD pierścieniem planet i w akcencie — od razu widać, że to punkt wyliczony, nie ciało. Loty bez glifu (Spirit, Eros…) pomijamy, żeby nie zaśmiecać. - Tooltipy: natywny <title> w SVG (bez JS-a). Obiekt → nazwa, pozycja, dom, retrogradacja. Linia aspektu → „Słońce trygon Mars · orb 0.20°" (polskie nazwy tylko do dymka; obliczenia trzymają angielskie). Fortuna → nazwa i pozycja. - Stopnie cuspów przy szprychach. W whole sign cuspy są na 0° znaku — wtedy pomijamy dwanaście zbędnych zer; w systemach kwadratowych (porphyry) stopień realnie coś mówi, więc go pokazujemy. Wszystko działa też w motywie druku (PDF): sprawdzone, że mimo Lotów, dymków i cuspów SVG nadal nie ma zmiennych CSS. Weryfikacja wizualna (porphyry): Fortuna przy AC, 12 stopni cuspów, 38 dymków (24 aspekty + 13 obiektów + Fortuna). Testy: +12 markdown (render), +7 etap 4 (prezentacja). Całość: prezentacja 145, render 27. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 19:26:58 +02:00
gitea	171deff2d1	feat(prezentacja): linie aspektów na kosmogramie (PRE-12, etap 3) ... Trzeci etap rysowania koła: linie aspektów w środku. Domyka rdzeń PRE-12 — kosmogram ma teraz znaki, domy, osie, obiekty i aspekty. Linie łączą PRAWDZIWE pozycje obiektów (nie rozsunięte glify — aspekt dotyczy tego, gdzie planeta faktycznie stoi) na okręgu piasty, w środku koła. Kodowanie jak w klasycznych programach: - KOLOR = charakter aspektu: niebieski harmonijny (trygon, sekstyl), czerwony napięty (kwadratura, opozycja), zielony koniunkcja. Dwa kolory na środku od razu mówią „gdzie łatwo, gdzie tarcie". - GRUBOŚĆ i JASNOŚĆ = orb: im ciaśniej, tym mocniej. Poniżej 1° wyraźne pogrubienie (wprost z wymagania) — najściślejsze aspekty rzucają się w oczy, a szerokie ledwo majaczą, żeby nie robić ze środka plątaniny. Rysowane jako pierwsze, pod resztą: obiekty siedzą na R_PLANET=150, daleko od piasty (R_HUB=48), więc glify i linie się nie stykają, a osie i szprychy lądują na wierzchu. Motyw druku (PDF, PRE-24) dostaje własne, ciemniejsze kolory aspektów bez zmiennych CSS — samodzielny konwerter SVG arkusza nie widzi. Weryfikacja na horoskopie referencyjnym: 24 aspekty, 5 ciasnych (<1°) faktycznie pogrubionych; kolory zgodne z typem (9 czerwonych napiętych, 10 niebieskich harmonijnych, 5 zielonych koniunkcji); print bez zmiennych CSS. Sprawdzone wizualnie — pełny aspektarian, czytelny. Testy: 8 nowych (linie obecne, kolor wg typu, pogrubienie <1°, prawdziwa pozycja nie rozsunięta, pominięcie aspektu do obiektu bez pozycji, brak aspektów, motyw druku). Całość: prezentacja 138 passed. PRE-12 -> Zrobione. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 17:44:25 +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	40c9bf7988	feat(prezentacja): obiekty na kosmogramie — glify, stopnie, retrogradacja (PRE-12) ... Etap 2 rysowania koła (po szkielecie): obiekty na swoich pozycjach. Każdy obiekt dostaje: kreske na wewnetrznej krawedzi pasa w PRAWDZIWEJ pozycji, glif, stopien w znaku i znacznik retrogradacji ℞ (dodatkowo kolorem, zeby dalo sie ja wylapac nie czytajac znak po znaku). ROZSUWANIE CIASNYCH SKUPISK — sedno tego etapu. W horoskopie referencyjnym Merkury i Wenus dzieli 0,41°, Wenus i Ksiezyc 3,68°: bez rozsuwania glify rysuja sie jeden na drugim. Rozsuwamy tylko GLIFY; kreska zostaje w prawdziwej pozycji, a gdy glif jest odsuniety, laczymy je cienka linia odniesienia — wykres nie moze klamac o tym, gdzie planeta faktycznie stoi. Bledy zlapane przy weryfikacji (oba wyszly z pomiarow, nie z „wyglada dobrze"): 1. PODPISY STOPNI zlewaly sie w skupiskach. O ciasnocie decyduje nie glif, tylko podpis — lezy blizej srodka (r=130), gdzie ten sam kat to mniej pikseli. Stad odstep 8° zamiast 7°, podpis bez „°" (jak w programach astrologicznych) i mniejszy font. Teraz: glify min 20,9 px, podpisy 18,1 px (prog 16). 2. ROZSUWANIE NIE DZIALALO na prawdziwych danych — Wenus ladowala DOKLADNIE na Ksiezycu (0,3 px). Przyczyna: odstep liczony modulo 360. Przesuniecie, ktore przerzucalo obiekt ZA sasiada, dawalo luke ~359,9° zamiast ujemnej, wiec algorytm uznawal, ze jest luzem, i konczyl. Poprawka: rozwijamy katy do osi MONOTONICZNEJ, gdzie ujemna luka zostaje ujemna i zawsze sie ja wylapie. Test regresyjny na dokladnie tych danych; sprawdzony sabotazem (po przywroceniu modulo czerwienieje). Etykiety osi (AC/DC/MC/IC) przeniesione POZA kolo — w srodku wchodzily w pierscien obiektow i zaslanialy glify (Ksiezyc znikal pod linia MC). ViewBox 440→470, kolo bez zmian, margines mieści etykiety. Testy: 11 nowych (regresja rozsuwania, zachowanie kolejnosci, obiekty bez kolizji nieruszone, zawiniecie przez 0°, awaryjny rowny rozklad, stopien w znaku, retrogradacja, niekompletny obiekt nie wywala rysunku). Calosc: prezentacja 44, logika 265 / 1 skip. Potwierdzone wizualnie: cale skupisko Slonce/Ksiezyc/Wenus/ Merkury czytelne i rozdzielone. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 15:49:51 +02: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