3 Commits

Author	SHA1	Message	Date
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	a9f2a038fa	refactor(prezentacja): wspólne partiale formularza — koniec dublowania chart/compile ... Spłata długu: bloki opcji i tabele wyniku były kopiowane między „Horoskop" (/) i „Skompiluj" (/compile). Duplikat już raz spowodował regresję (podsumowanie gubiło opcje), a przy każdej nowej opcji rósł (dodawałem je 3× w dwóch miejscach). - `_form_options.html` (NOWY): bloki opcji — stacje/tabele, porównanie domów, ustawienia aspektów. Dołączany przez oba formularze. - `_result_tables.html`: chart.html PRZECHODZI na ten wspólny plik (compile już go używał od #46). Rysunki (koło/aspektarian/deklinacja/antyscja) zgrupowane razem, potem wspólne tabele. Dzięki temu widok główny i podsumowanie NIE MOGĄ się już rozjechać — jedno źródło prawdy. Zero zmian zachowania: oba szablony renderują te same pola i tabele co wcześniej (sprawdzone renderem na bogatym wyniku). Testy strukturalne przełączone na odczyt wspólnych plików. Prezentacja 221. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 18:09:54 +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