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>
Warunek wstępny pod kosmogram (PRE-12): planety i znaki na kole rysujemy
symbolami. Nowy moduł engine/glyphs.py:
- forward: nazwa → glif (planety, punkty, Loty, znaki, aspekty, retro ℞),
- reverse: glif → nazwa (znosi obecność/brak selektora wariantu),
- glyphify(): tokeny [XX z bazy → glify; przyklad z wymagan
„[Sa [Pis 26°08' [conj [PF" → „♄ ♓ 26°08' ☌ ⊗" (stopnie nietkniete).
DAN-18 „tylko tekst, nigdy emoji" potraktowane serio, TRZEMA warstwami — bo
sam selektor NIE wystarcza (potwierdzone wizualnie w przegladarce):
1. w danych: selektor wariantu tekstowego U+FE0E na znakach zodiaku oraz ♀/♂
(maja wariant emoji); ☉ i reszta go nie dostaja (zbedny),
2. CSS font-variant-emoji:text,
3. CSS font-family celujacy w MONOCHROMATYCZNE fonty symboli PRZED emoji.
Bez pkt. 3 macOS/Chromium i tak renderowal znaki ♈–♓ jako kolorowe kafelki
Apple Color Emoji mimo VS15 — planety wychodzily tekstem, znaki nie. Stack
„Apple Symbols / Segoe UI Symbol / Noto Sans Symbols2" naprawia render.
NIGDZIE nie emitujemy U+FE0F (emoji) — pilnuje tego test.
Wpiete w build_chart: kazda pozycja dostaje glyph (planeta) + sign_glyph (znak,
zalezny od zodiaku, wiec po przesunieciu), osie i Loty tak samo (Fortuna ⊗,
reszta Lotow bez standardowego symbolu → None), aspekty dostaja glif,
result[„sign_glyphs"] to pierscien 12 znakow pod kolo.
UI: kolumna „Sym." w tabeli pozycji (planeta + znak) i symbol przy aspekcie.
Testy: 14 (kompletnosc — kazdy obiekt/znak/aspekt ma glif; dwukierunkowosc;
DAN-18 brak FE0F, znaki maja VS15, ☉ nie; przyklad glyphify z wymagan).
Calosc: logika 265 passed / 1 skipped, prezentacja 25. Render znakow
potwierdzony wizualnie (czarno-biale symbole, nie emoji).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Aspekty głowne (LOG-06) mierzą kąt wzdłuż ekliptyki. LOG-07 dokłada dwa rodzaje
powiązań, które klasyczna astrologia liczy naprawdę, nie na oko:
- PARALELA/KONTRPARALELA DEKLINACJI — dwa ciała na tej samej („parallel") lub
przeciwnej („contraparallel") deklinacji działają jak koniunkcja/opozycja,
mimo że wzdłuż ekliptyki mogą stać gdziekolwiek. Deklinacja liczona PEŁNYM
wzorem (z szerokością ekliptyczną — istotne dla Księżyca i planet schodzących
z ekliptyki), przez to_equatorial z LOG-04. Orb konfigurowalny (domyślnie 1°,
ciasno — to kontakty punktowe).
- ANTYSCJA/KONTRANTYSCJA — odbicie długości względem osi przesileń (0° Raka –
0° Koziorożca) albo równonocy (0° Barana – 0° Wagi).
Liczone na współrzędnych TROPIKALNYCH of-date, bo deklinacja jest fizyczna
(równikowa, niezależna od zodiaku), a antyscja z definicji tropikalna — jej oś to
kardynalne punkty zodiaku tropikalnego. Dlatego PRZED przesunięciem na zodiak
syderyczny/draconiczny.
Dodatkowo: flaga „out of bounds" (|deklinacja| > nachylenie ekliptyki — ciało
poza zakresem Słońca) i kolumna deklinacji przy każdej pozycji.
Integracja z bazą: baza interpretacyjna ZNA paralele pod frazą „P. Dec.", więc
generujemy fasetkę paraleli (trafia też do promptu LLM). PUŁAPKA: samo „Dec." w
bazie to często DEKANAT („3rd Dec. of [Gem"), więc szukamy dokładnie „P. Dec." —
inaczej sypnęłoby fałszywymi trafieniami. Kontrparaleli i antyscji baza nie
opisuje osobnym znacznikiem, więc zostają obliczeniem display-only.
Pary z RIGID_PAIRS (węzły) odsiane: SN = NN+180° na ekliptyce → deklinacja
ZAWSZE przeciwna, czyli definicyjna kontrparalela bez informacji.
Walidacja wobec faktów NIEZALEŻNYCH od kodu:
- deklinacja Słońca 30.04.1984 = +14.88° wobec ~+14.9° z almanachu,
- antyscja to arytmetyka odbicia: inwolucja i pary znaków (Rak↔Bliźnięta,
Baran↔Panna) sprawdzone na piechotę,
- węzły faktycznie mają przeciwną deklinację i są odsiane,
- deklinacja niezależna od zodiaku (tropikalny == syderyczny co do 1e-6°),
- realna baza: mechanizm paraleli znajduje wpisy „P. Dec." i odsiewa dekanaty
(z 33 wpisów „P. Dec." 5 ma niepusty efekt — głównie „[conj or P. Dec.").
UI: kolumna deklinacji (+znacznik OOB), tabela paraleli/kontrparaleli i tabela
antyscji na ekranie Horoskop.
Testy: 15 nowych (out_of_zodiac) + 2 (fasetka paraleli vs pułapka dekanatu).
Całość: logika 251 passed / 1 skipped, prezentacja 25 passed. Render szablonu
sprawdzony osobno (bez błędu Jinja, wszystkie sekcje obecne).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Węzły księżycowe są z definicji w dokładnej opozycji (SN = NN + 180°),
więc wpis "North Node opposition South Node orb 0.00°" nie niósł żadnej
informacji astrologicznej — zaśmiecał /chart/positions i UI horoskopu,
a w generatorze promptów LLM zjadał budżet znaków i mógł zostać wzięty
przez model za realne świadectwo.
- aspects.py: RIGID_PAIRS + pomijanie takich par w find_aspects;
struktura zbioru pozwala dopisać kolejne pary definicyjne,
- aspekty węzłów do pozostałych obiektów bez zmian,
- testy: jawne sprawdzenie braku pary NN/SN (jednostkowo i na
horoskopie referencyjnym).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
- engine/lots.py: formuła Lot = C + A − B z odwracaniem w horoskopach nocnych
(zamiana A<->B); 7 Lots hermetycznych (Fortuna, Duch, Eros, Konieczność,
Odwaga, Zwycięstwo, Nemezis) — Fortuna i Duch liczone pierwsze, bo pozostałe
się do nich odwołują. Dwa warianty: degree (domyślny) i sign (całe znaki).
- build_chart: liczy sektę (reużyta is_day_birth z Firdarii) i zwraca lots
ze znakiem, pozycją i domem; parametr lots_method.
- wyszukiwarka: token [PF (tak Fortuna występuje w realnej bazie) + rozwinięcie
skrótu do "Part of Fortune".
- widok Horoskop: tabela Lots z formułami i sektą.
Walidacja (dwie niezależne wyrocznie z notes3):
- Fortuna = Can 12°35'27" vs astro-seek Can 12°35'24" (3 sekundy różnicy), dom 1;
- Duch potwierdzony przez swoją antyscję (Taurus 28°14' z tabeli antyscji);
- odwracanie nocne: Fortuna nocna == Duch dzienny i odwrotnie;
- Lots pochodne faktycznie używają Fortuny/Ducha; wariant sign trafia w 0° znaku.
85 testów przechodzi (nowy test_lots).
Odblokowuje Zodiacal Releasing (LOG-11), które startuje z Fortuny/Ducha.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- engine/firdaria.py: sekta (dzień = Słońce nad horyzontem, ta sama półkula
osi Asc-Dsc co MC); kolejność diurnalna/nokturnalna; klasyczne długości
okresów (Su10 Ve8 Me13 Mo9 Sa11 Ju12 Ma7 + NN3 + SN2 = 75 lat); okresy główne
planet dzielone na 7 podokresów (sub-lord od władcy okresu), węzły bez sub.
- endpoint /chart/firdaria.
- oś czasu: firdaria_events — starty (pod)okresów w oknie; wpięte w build_timeline
(domyślnie) + tokeny [major][sub] do dopięcia interpretacji (1B->2B).
Walidacja:
- sekta = day dla horoskopu referencyjnego (zgodnie z notes3 "Day birth");
night gdy Słońce po stronie IC; sumy i przyleganie okresów; podokresy 7x
sumujące się do okresu; wiek 42 w okresie Saturna.
- E2E: okresy Sun 1984-1994 ... Saturn 2024-2035; w osi czasu
"Firdaria: Saturn / Mars" 2027 -> 223 interpretacje ([Sa+[Ma -> "injury").
- 78 testów przechodzi (nowy test_firdaria).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
engine/timeline.py: scala w jedną posortowaną oś czasu (technique | significator |
start | exact | end):
- profekcje roczne (LOG-10) — Władca Roku per rok życia,
- Solar Return (LOG-12) — moment powrotu Słońca,
- dyrekcje solar-arc — daty dokładnych aspektów kierowanych planet do punktów
natalnych (klucz Naiboda 0°59'08"/rok, konfigurowalny; okno orbowe ±1 rok).
Endpoint /chart/timeline (zakres from_date..to_date, wybór technik).
Walidacja:
- profekcje spójne z tabelą notes3; dyrekcja Sun koniunkcja MC (łuk 312°) słusznie
poza życiem; oś posortowana po dacie dokładnej; wiek = łuk/klucz spójny z datą.
- E2E: dla 2025-2026 zwraca 19 zdarzeń (m.in. Władca Roku 42 Saturn 30.04.2026,
Solar Return, dyr. Venus koniunkcja North Node 27.05.2025). 66 testów przechodzi.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pierwsze techniki predykcyjne.
Profekcje (LOG-10):
- engine/profections.py: Whole Sign, wiek mod 12; profektowany Asc + Władca Roku
(władca domicylowy) + profekcje MC/Su/Mo. Obsługa 29 lutego.
- endpoint /chart/profections (zakres lat: start_age, count).
Returns (LOG-12):
- engine/returns.py: moment powrotu Słońca/Księżyca do długości natalnej;
skan dobowy + bisekcja do ~sekundy, z pominięciem artefaktu zawinięcia 0/360.
- endpoint /chart/return (kind solar|lunar, around) — zwraca pełny horoskop
na znaleziony moment (oba warianty użycia po stronie technik wyżej).
Walidacja:
- profekcje zgodne co do joty z tabelą astro-seek z notes3 (wiek 0..42:
Asc + Władca Roku + MC/Su/Mo).
- Solar Return 2026: Słońce wraca do Tau 10°08'22" = natalny stopień;
Lunar Return trafia natalny Księżyc <2'; samospójność potwierdzona.
- 62 testy przechodzą (nowe: test_profections, test_returns).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
- aspects.py: _is_applying — odchyłka od dokładnego kąta teraz vs po małym
kroku czasu (prędkość·dt, dt=0,01 doby by szybki Księżyc nie przeskoczył
dokładności); aspekt niesie applying (bool) i "as": A/S. Bez prędkości —
brak flagi (None).
- scoring: aspekt aplikacyjny silniejszy (APPLYING_BONUS 1.15) — zgodnie z
notatkami projektu ("impact considered more powerful").
- significators: faseta aspektu niesie applying, etykieta z sufiksem (A)/(S).
- widok Horoskop: kolumna A/S w tabeli aspektów (tooltip z objaśnieniem).
Walidacja: flagi A/S wszystkich 16 aspektów horoskopu referencyjnego
(30.04.1984, Warszawa) zgodne z tabelą astro-seek z notes3 (test regresyjny
REFERENCE_AS). 45 testów przechodzi.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Aspekty:
- engine/aspects.py: aspekty główne (conj/sex/sq/tri/opp) z orbami
(bonus dla luminarzy), separacja z obsługą zawinięcia. Applying/sep na później.
- build_chart zwraca listę aspektów; /chart/positions je udostępnia;
widok Horoskop pokazuje tabelę aspektów.
Bogatsze sygnifikatory:
- trzecia faseta "w aspekcie": dla każdego aspektu głównego obiektu filtruje
rekordy po tokenie aspektu + drugiej planety ([conj + [Mo). Cookbook
komplet: znak + dom + aspekt.
Dopieszczenie wyników:
- ODSIEWANIE DUPLIKATÓW: duplikat = ten sam sygnifikator ORAZ ten sam opis
(po normalizacji). Dedup wewnątrz fasety, działa też na wynikach z wielu baz.
- _facet_samples przyjmuje wiele tokenów (AND); dedup + istniejące odsiewanie szumu.
Zweryfikowano na realnym main_base.xlsx (30.04.1984): 16 aspektów zgodnych z
astro.com (Sun conj Moon 9.59°, Sun opp Saturn 3.17°); faseta aspektu daje
bogate trafienia (Sun koniunkcja z Moon 84, opozycja z Saturn 43); dedup obniżył
duplikaty (Sun w znaku 46->44). 36 testów przechodzi.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Pierwszy increment implementacji warstwy logicznej (ścieżka A).
LOG-24: interfejs EphemerisEngine z dwoma backendami — SkyfieldEngine
(własny, permisywny: Skyfield MIT + dane JPL public domain) oraz
RemoteEngine (klient izolowanej usługi swisseph). Fabryka + leniwa
inicjalizacja; endpointy /chart/positions i /chart/compare.
LOG-01: pozycje obiektów (długość/szerokość ekliptyczna, prędkość,
kierunek, formaty: w znaku / absolutny / dziesiętny).
LOG-25/28: harness porównawczy (compare.py) z progami tolerancji oraz
wspólny kontrakt parzystości; pełen zestaw testów.
LOG-27: services/engine-swisseph — osobna, opcjonalna usługa AGPL
(pyswisseph, tryb Moshiera), licencjonowana osobno, w compose pod
profilem "comparison"; nie wchodzi do zamkniętego produktu.
Walidacja: SkyfieldEngine zgadza się ze Swiss Ephemeris co do ~1" dla
wszystkich 10 obiektów na horoskopie referencyjnym (30.04.1984, Warszawa);
12 testów przechodzi (silnik B pomijany gdy nieskonfigurowany).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gitea