Co z nowych dokumentów dochodzi do wymagań, co trzeba zmienić i w jakiej
kolejności. Najważniejsze ustalenie, potwierdzone w kodzie: dopasowanie
sygnifikatorów (_facet_samples) sprawdza tylko, czy rekord zawiera
tokeny, a nie czy jego warunki są spełnione — stąd zgłoszone przez
klienta fałszywe interpretacje, które trafiają też do promptu LLM.
Rejestr wymagań celowo bez zmian do czasu akceptacji analizy.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Dwa nowe pliki od klienta, w postaci otrzymanej (bez zmian):
- astro parser TO DO LIST 2026-09-05.xlsx — lista zadań z priorytetami
(***/**/*) i 16 arkuszy-wzorców przykładowych tabel,
- astro parser_2026-09-13.docx — specyfikacja techniczna w 21 częściach
(według klienta niedokończona; do czytania razem z listą TO DO).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Astroklient przedstawiał się na stronie głównej jako „astrololo" — w tytule
karty i w nagłówku. To najpoważniejszy z możliwych śladów: mówi klientowi
wprost, że trzyma okrojoną wersję czegoś większego, i podaje frazę, po której da
się wyszukać, czego mu nie dano. Cała reszta izolacji przestaje mieć znaczenie,
gdy produkt sam się przedstawia nazwą rodzica.
Wzięło się stąd, że nazwa była wpisana na sztywno w szablony, a szablony są
WSPÓLNE — dokładnie ta sama przyczyna, co przy zaszytym w base.html warunku na
administratora. Nazwa mieszka teraz w module `produkt.py`, który nakładka
produktu nadpisuje; szablony o nią pytają, zamiast ją znać.
astrodemo NIE było dotknięte: ma własne kopie szablonów i pokazuje „astrodemo".
DRUGIE ŹRÓDŁO WYCIEKU, mniej oczywiste: nazwa siedziała też w identyfikatorach
JavaScriptu, które widzi każdy, kto otworzy narzędzia deweloperskie — zdarzenie
`astrololo:coords` i klucz `astrololo.form.v1` w localStorage. Przemianowane na
neutralne `kosmogram:*`; te identyfikatory nie mają powodu nosić nazwy rodziny
produktów. SKUTEK UBOCZNY: zmiana klucza w localStorage kasuje raz zapamiętane
wersje robocze formularza.
Sprawdzone, że NIE wyciekają: nagłówki X-Astrololo-* jadą wyłącznie między
warstwami, a dokumentacja OpenAPI (gdzie zostaje tytuł aplikacji FastAPI) oddaje
404 także zalogowanemu.
TEST rozdziela to, co widzi człowiek, od identyfikatorów wewnętrznych. Nazwa
rdzenia wolno występować w nazwach loggerów, materiale do wyprowadzania kluczy
i nagłówkach międzywarstwowych; nie wolno w szablonach, zasobach ani w treści
odpowiedzi. Zakaz na wszystko byłby albo obejściem przez zmianę nazw kluczy
kryptograficznych, albo martwą regułą wyłączaną przy pierwszej okazji.
Sprawdzony w obie strony: po cofnięciu nakładki test pada.
Testy: astroklient 15, presentation 368, astrodemo 28, logic 342, data 42,
render 41.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Testy astrodemo padały na masterze, choć lokalnie przechodzą — bo w CI nie
uruchamiały się WCALE. Dopisując blok astroklienta rozciąłem blok sąsiada:
krok „Testy (pytest)" astrodemo został z samym `working-directory`, a jego
`env` i `run` przywędrowały do zadania astroklienta.
Skutek podwójny i gorszy, niż wygląda: astrodemo zgłaszało błąd (krok bez
polecenia), a astroklient przechodził Z NIEWŁAŚCIWEGO POWODU — na cudzym `run`.
Zielone CI, które nic nie uruchomiło, jest gorsze od czerwonego, bo nie ma czego
naprawiać.
Krok bez `run` i bez `uses` jest dla Gitei krokiem pustym. Dopisana kontrola
przechodzi wszystkie pliki workflow i przerywa, gdy taki krok się trafi albo
gdy zadanie nie ma kroków w ogóle. Sprawdzona w obie strony: przepuszcza obecny
stan i wykrywa dokładnie to rozcięcie, gdy je odtworzyć.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Trzeci produkt drabiny: astrodemo (dwie funkcje) → astroklient → astrololo.
Po trzech poprzednich krokach jest cienki, bo jest ZŁOŻENIEM, a nie kopią:
własne main.py z ośmioma importami, a rdzeń — ekrany, szablony, zasoby — bierze
z warstwy prezentacji przy budowaniu obrazu. Jedno źródło, dwa produkty; inaczej
te same 2500 linii szablonów żyłyby w dwóch egzemplarzach i rozjechały się
w ciągu tygodni, po cichu.
CO MA: Horoskop, Interpretacje, Kalendarz, Synastria, Sygnifikatory, wgrywanie
plików. Wyszukiwarka miejsca i strefa czasowa zgodnie z ustaleniem.
CZEGO NIE MA I DLACZEGO NIE DA SIĘ WŁĄCZYĆ: plików usuniętych wg usun.txt nie ma
w obrazie. Nie istnieje uprawnienie, którym dałoby się je odsłonić, bo katalog
funkcji składa się ze ZGŁOSZEŃ ekranów obecnych w obrazie. To dlatego „każde
konto dostaje wszystko, co ta usługa umie" jest tu bezpieczne i nie wymaga
wypisywania listy: zbiór liczy się z katalogu, więc opisuje ten produkt.
KONTA jak w astrodemo: z konfiguracji środowiska (ASTROKLIENT_USERS), jeden
poziom dostępu, bez pliku kont i bez ekranu ich zakładania. Konta rozdziela się
po to, żeby każde miało własną pulę plików.
PULE PER KONTO — tu była realna dziura. Warstwa logiczna przenosiła pulę tylko
przy raporcie i operacjach na plikach, więc Kalendarz i Sygnifikatory czytałyby
CAŁY udział: jedno konto widziałoby pliki drugiego, mimo obietnicy izolacji.
Domknięte: TimelineRequest i QueryRequest niosą teraz pulę, a QueryService buduje
klienta danych na żądanie.
Pula jedzie w każdym żądaniu w dół i bierze się z kontekstu ustawianego przy
wejściu, nigdy z formularza. Test podstawia `tenant=ktos-inny` w POST i sprawdza,
że w dół poszedł login zalogowanego.
WARSTWA WSPÓLNA ROZDZIELONA OD POJĘCIA ADMINISTRATORA. base.html miał wpisany na
sztywno warunek `can(request, 'admin')` i odsyłacz do ekranu kont — czyli
w produkcie bez tego ekranu zostawał martwy link i nazwa czegoś, czego nie ma.
Rejestr niesie teraz wymagane uprawnienie, a szablon dostaje gotową listę.
Podstawa przestała też importować moduły służące jednemu ekranowi (konta, stany
plików), bo produkt bez tego ekranu wlókł ich zależności.
ZAPORA SŁOWNIKOWA NAD REALNYM DRZEWEM. Test buduje złożenie tak samo jak
Dockerfile i szuka słów o funkcjach, których nie ma — w odpowiedziach ORAZ
w plikach. Pierwsza wersja znalazła dziesięć trafień, w tym trzy moje własne
docstringi WYLICZAJĄCE nieobecne funkcje: zdanie „nie ma tu generowania tekstu"
mówi wprost, że coś takiego istnieje, więc jest takim samym śladem jak przycisk.
Po poprawkach: zero. Test ma kontrolę negatywną — podrzucony plik ma go wywrócić.
usun.txt jest DANYMI, nie tekstem w Dockerfile: czyta go też test pilnujący, żeby
zgadzał się ze złożeniem w main.py. Rozjazd znaczyłby albo martwy kod w obrazie,
albo błąd dopiero przy uruchomieniu.
CI: astroklient buduje się z KORZENIA repozytorium (jego Dockerfile sięga po
rdzeń), a zmiana w warstwie prezentacji też go przebudowuje — bez tego jego obraz
zostawałby ze starymi ekranami, a różnicy nie byłoby widać do zgłoszenia
użytkownika.
Testy: astroklient 12, presentation 368, astrodemo 28, logic 342, data 42,
render 41.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Rejestr obrazów rósł, bo `build.yaml` budował CZTERY obrazy przy każdym pushu do
mastera, niezależnie od tego, co się zmieniło. Zmiana w samej prezentacji dawała
nowe wersje data, logic i astrodemo — identyczne co do zawartości, różniące się
wyłącznie tagiem.
Render i silnik B miały filtry ścieżek od początku (build-render.yaml,
build-swisseph.yaml) i budują się tylko przy własnych zmianach. Ta zmiana
przenosi tę samą zasadę do głównego pipeline'u, licząc różnicę wobec poprzedniego
commita. Kontekstem budowania każdego obrazu jest wyłącznie `./services/<nazwa>`,
więc porównanie ścieżek jest dokładne, a nie przybliżone.
Sprawdzone na ośmiu ostatnich commitach mastera: dwa refaktory prezentacji dają
sam `presentation`, poprawka Dockerfile'a astrodemo daje samo `astrodemo`,
a commit ruszający link_crypto w pięciu usługach — komplet. Bez porównania
(pierwszy commit, przepisana historia) budujemy wszystko: lepiej zbudować za
dużo niż wypuścić obraz ze starym kodem pod nowym tagiem.
SKUTEK UBOCZNY DO ŚWIADOMOŚCI: tagi w kustomization mogą się teraz rozjechać
między usługami, bo nie każda dostaje nową wersję z każdego commita. Tak ma być —
image-updater śledzi każdy obraz osobno i przypina to, co istnieje.
ZABEZPIECZENIE PRZED CICHYM POMINIĘCIEM. Usługa, której nie ma na żadnej liście,
nigdy się nie zbuduje i nikt tego nie zauważy: brak obrazu wygląda potem na
problem z rejestrem albo z siecią. Ten sam mechanizm kosztował nas już raz, przy
liście obserwowanych obrazów w image-updaterze. Pętla po `services/*/` zatrzymuje
budowanie i mówi wprost, co dopisać. Sprawdzone także od strony negatywnej —
podstawiony katalog nowej usługi kończy przebieg kodem 1.
SPRZĄTANIE NA RUNNERZE, w build.yaml i w build-render.yaml, z `if: always()` —
bo to po NIEUDANYM budowaniu zostaje najwięcej śmieci, a kolejny przebieg
zaczyna od mniejszego zapasu miejsca niż poprzedni. Tak zatkał się dysk przy
renderze z TeX Live. Filtr `until=168h` zostawia tydzień, więc warstwy bazowe
i cache przeżywają i build nie zaczyna od zera.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Trzeci z pięciu kroków. Zmieniłem jego zakres wobec planu i warto wiedzieć
dlaczego: pierwotnie miała to być deduplikacja pięciu kopii link_crypto.py, ale
po zrobieniu PR 2 widać, że astroklienta blokuje co innego — ekrany, których nie
ma mieć, siedzą wewnątrz jednego main.py. Deduplikacja kryptografii jest realnym
długiem, ale niczego nie blokuje.
PODZIAŁ. main.py (1023 linie) rozpadł się na podstawa.py (wspólne obiekty
i pomocnicy), jedenaście modułów w app/ekrany/ i main.py, który jest już samym
ZŁOŻENIEM: lista importów JEST definicją produktu. Podział zrobiony mechanicznie,
z osobnym sprawdzeniem, że żadna sekcja nie wołała pomocnika z innej (nie wołała).
KATALOG Z REJESTRACJI. Dotąd wszystkie funkcje były wypisane w features.py, więc
obraz produktu, który części z nich nie ma, i tak niósł ich nazwy — spis funkcji,
których nie ma jak włączyć. Teraz ekran zgłasza siebie, swoje trasy i swoje
zasoby przy imporcie własnego modułu, a features.py nie wymienia ani jednego
ekranu. Kolejność w nawigacji jest jawna (`kolejnosc`), żeby nie rządziła nią
kolejność importów.
To samo dotyczy nawigacji administratora: odsyłacz do ekranu kont był wpisany na
sztywno w base.html, więc w węższym produkcie zostawał martwy link i nazwa
ekranu, którego nie ma.
EKSPORT JAKO MODUŁ. Zgodnie z ustaleniem eksport jest funkcją administracyjną,
więc musi dać się usunąć. app/moduly/eksport/ zabiera arkusz, trasę PDF-a i akcję
formularza. „Można, ale nie temu kontu" i „nie ma takiej możliwości" to dwie
różne gwarancje, a eksport wynosi najwięcej treści baz naraz.
MOST ODKRYWA MODUŁY. Skoro modułów jest więcej niż jeden, most nie może ich znać
z nazwy — nazwa nieobecnego modułu jechałaby do obrazu, w którym go nie ma.
Przechodzi więc po podkatalogach app/moduly/ i pyta każdy, co wnosi. Katalog
generowania przeniesiony z app/dodatki na app/moduly/dodatki.
ZNALEZIONE PRZY OKAZJI. Po wydzieleniu eksportu okazało się, że jego ścieżki
SZCZĘŚLIWEJ nie sprawdzał żaden test — badano wyłącznie odmowę dla konta bez
uprawnienia. Moduł dostaje zależności z wywołania montującego, więc brak jednej
z nich wyszedłby dopiero przy pierwszym kliknięciu. Dopisany test funkcjonalny
(realny arkusz, sprawdzany aż do nagłówka ZIP-a) i brakujące zależności.
Cztery komentarze w plikach współdzielonych wymieniały zakładkę „Skompiluj",
w tym wheelzoom.js ze wzmianką o „przyszłej zakładce" — to samo zgłoszenie, które
audyt podnosił wcześniej.
TEST ZŁOŻENIA. Buduje węższy produkt NAPRAWDĘ: kopiuje drzewo, usuwa cztery
ekrany i oba moduły, uruchamia aplikację w OSOBNYM PROCESIE (importy są
zapamiętywane, więc sprawdzanie tego w procesie, który moduł już zaimportował,
dawałoby wynik fałszywie pozytywny) i sprawdza, że wstaje, że zachowane ekrany
oddają 200, że usunięte oddają 404 (nie 403 i nie 500), że katalog opisuje ten
obraz, i że w nawigacji nie ma martwych odsyłaczy.
Napisałem najpierw ostrzejszy test — „nazwa ekranu nie pada poza jego modułem" —
i go wyrzuciłem: zgłaszał wzmianki o Horoskopie w plikach współdzielonych, choć
astroklient Horoskop MA. Ślad ma znaczenie wyłącznie wobec konkretnego złożenia,
więc sprawdzenie należy do produktu, nie do mechanizmu.
Testy: presentation 368, logic 342, data 37, render 41.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drugi z pięciu kroków budowy trzech produktów. Czysty refaktor — zachowanie
aplikacji się nie zmienia, liczba testów rośnie tylko o nowe.
DLACZEGO WARUNEK W SZABLONIE NIE WYSTARCZA. Dotąd generowanie było chowane przez
`{% if can(request, 'ai') %}`. To sprawia, że funkcji nie WIDAĆ, ale nie że jej
NIE MA: plik szablonu dalej leży w obrazie i dalej zawiera jej nazwy, więc `grep`
po kontenerze pokazuje wszystko, czego warunek nie pokazał na ekranie. Astroklient
ma nie mieć śladu, nie mieć wyłączoną funkcję — więc granica musi być KATALOGIEM.
CO SIĘ PRZENIOSŁO do app/dodatki/: dwa szablony, pięć plików statycznych, trasa
strumienia, cztery metody klienta warstwy logicznej, wpis w katalogu funkcji,
wpisy tras i zasobów, akcje formularza i reguły CSS nazywające funkcję
(`textarea.prompt`).
JAK APLIKACJA O TO PYTA. Neutralny most `app/rozszerzenia.py` odpowiada wyłącznie
na pytanie „czy coś jest podpięte i co wnosi". Sam nie wymienia ani jednej nazwy —
pilnuje tego osobny test, bo most jest w KAŻDYM obrazie. Dlatego też katalog
nazywa się `dodatki`, a nie `ai`: nazwa w instrukcji importu byłaby dokładnie tym
śladem, którego wydzielanie ma się pozbyć.
TRZY MIEJSCA, KTÓRE OKAZAŁY SIĘ TRUDNE:
1. Pola formularza. FastAPI czyta je z SYGNATURY, a wspólny handler nie może
wymieniać `prompt_budget` ani `llm_provider`. Rozwiązane zależnością: moduł
deklaruje własne pola u siebie, handler wie tylko, że dostaje słownik.
2. Klient warstwy logicznej jest wspólny, więc metody `prompt`/`horoscope`/
`llm_models` musiały z niego wyjść. Wspólny klient daje teraz samą drogę
w dół (`wywolaj`, `pobierz`, `strumien`) — z szyfrowaniem łącza i tokenem
międzywarstwowym; co nią pojedzie, jest sprawą modułu.
3. Podtytuł ekranu Skompiluj miał wariant „z AI" i wariant bez. Zamiast warunku
jedno zdanie prawdziwe niezależnie od tego, jakie moduły są w obrazie.
DOCKERFILE. `COPY . .` wnosiło do obrazu także testy — a plik testowy nazywa
funkcje wprost. Teraz wchodzi wyłącznie `app/`.
TEST GRANICY. `test_ai_tylko_w_module.py` przechodzi po wszystkim poza modułem
i szuka siedemnastu słów. Znalazł dwanaście resztek, których nie widziałem:
komentarze w main.py i security.py, przykład `models.js` w komentarzu features.py,
komentarze w compile.js i w trzech arkuszach, oraz regułę `textarea.prompt`,
która przy rozbijaniu CSS trafiła do arkuszy ekranów zamiast do modułu.
Ma też kontrolę pozytywną (te słowa MAJĄ padać w module — inaczej test
przechodziłby, gdyby funkcję wydrążono) i test odłączalności mostu.
SPRAWDZONE NA KOPII BEZ MODUŁU: aplikacja startuje, wszystkie ekrany oddają 200,
katalog ma 13 funkcji zamiast 14, trasy strumienia nie ma, spreparowane
`action=prompt` wraca do akcji domyślnej bez śladu, a `grep` po drzewie nie
znajduje ani jednego ze słów.
Testy: presentation 362, logic 342, data 37, render 41.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`COPY . .` wnosiło do obrazu cały katalog usługi, razem z tests/. Leży tam plik
pilnujący, żeby pewne słowa nie padły — wypisujący je wprost, bo inaczej nie da
się ich sprawdzić. Trafiając do obrazu, stawał się dokładnie tym wyciekiem,
przed którym broni: „pełna aplikacja", „astrololo", nazwy nieobecnych funkcji.
Obraz tej usługi się KOMUŚ ODDAJE, więc waży to więcej niż gdzie indziej.
To samo zawężenie zrobiłem wcześniej w warstwie prezentacji; astrodemo zostało
przeoczone, bo powstało przed tamtą zmianą.
Test pilnuje tego na przyszłość i czyta same instrukcje, bez komentarzy —
komentarz obok cytuje dawną postać, więc szukanie po całym pliku zgłaszałoby
własne wyjaśnienie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pierwszy z pięciu kroków budowy trzech produktów: astrodemo (dwie funkcje) →
astroklient (pełne astro bez AI) → astrololo (wszystko). Nazwa „astroklient"
zostaje zwolniona dla warstwy pośredniej, więc dotychczasowe astroklient-demo
nazywa się teraz astrodemo.
REBASE. Cztery commity demo przeniesione na aktualnego mastera. Konflikt był
jeden — rejestr wymagań (xlsx, binarny, git go nie scali). Master dodał LOG-34,
gałąź demo PRE-28 i PRE-29; żaden wspólny wiersz się nie różnił, więc scalone
ręcznie: 148 pozycji, wszystkie trzy obecne.
ZMIANA NAZWY. Katalog, ciasteczko sesji (astrodemo_sesja), zmienne
ASTRODEMO_USERS/USER/PASSWORD, CI, README, docstringi. Ponieważ PR z demo nigdy
nie został zmergowany, usługa nie jest nigdzie wdrożona — zmiana nazw niczego
nie migruje i nikogo nie wylogowuje.
WYCIEKI. astrodemo powstało przed audytem z PRE-27, więc miało komplet tych
samych dziur:
- /static omijało bramkę (PUBLIC_PREFIXES), a pierwszy komentarz w styles.css
brzmiał „Nie kopiujemy stylów pełnej aplikacji" — czyli anonimowy curl
dowiadywał się, że istnieje pełna aplikacja. Zasoby idą teraz trasą z jawną
listą, komentarze są zdejmowane przy serwowaniu.
- Komunikat awarii wypisywał na ekran treść wyjątku httpx, z nazwą usługi
i portem. Teraz jedno neutralne zdanie, szczegóły do dziennika.
- /health oddawał nazwę warstwy. Teraz samo „ok".
- Dziesięć komentarzy i docstringów tłumaczyło decyzje przez porównanie
z „pełną aplikacją". Obraz tej usługi się KOMUŚ ODDAJE, więc kto go dostanie,
przeczyta też komentarze. Przepisane tak, żeby opisywały tę usługę samą
w sobie.
- Nagłówek main.py twierdził, że demo dzieli pulę plików z produkcją. To
nieprawda od PRE-29 (pule per konto) — opis poprawiony.
ZAPORA SŁOWNIKOWA, dwupoziomowa. Poziom „wszędzie" (także w kodzie serwera, bo
obraz się oddaje) obejmuje wzmianki o większym rodzeństwie, o modelu językowym
i o funkcjach, których tu nie ma. Poziom „do przeglądarki" dokłada słownictwo
mechanizmów. Test sprawdza odpowiedzi ORAZ drzewo plików.
Jeden wyjątek jest jawny i opisany: stałe protokołu łącza (X-Astrololo-Token,
X-Astrololo-Enc, typ treści, etykieta HKDF) niosą nazwę rodziny produktów. Są
wspólne z warstwą logiczną, więc zmiana wymaga jednoczesnej podmiany we
wszystkich usługach i rotacji — osobna decyzja. Osobny test pilnuje warunku, pod
jakim to zostaje: że nie docierają do przeglądarki. Wcześniej przechodziły tylko
dlatego, że regex nie dopasowywał po myślniku — przypadek, nie decyzja.
Przy okazji: komunikat „ramka bez znacznika astrololo" zmieniony na neutralny we
WSZYSTKICH PIĘCIU kopiach link_crypto.py (presentation, astrodemo, logic, data,
render), żeby nie rozjechały się przed scaleniem w rdzeń. Te kopie to 2625 linii
tego samego kodu.
Testy: astrodemo 27, presentation 358, logic 342, data 42, render 41.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Demo idzie szeroko i do różnych osób, często na cudzych komputerach — więc
wyjście z aplikacji jest tu potrzebne bardziej niż w pełnej wersji, a Basic go
nie miał: przeglądarka zapamiętuje hasło i dosyła je sama przy każdym żądaniu.
Pierwszy klient zostawiał otwartą sesję drugiemu.
Ta sama konstrukcja co w pełnej aplikacji: własny ekran logowania, podpisane
ciasteczko (HMAC-SHA256), HttpOnly + SameSite=Strict, wylogowanie POST-em, kres
bezczynności i twardy, sito na adres powrotu, zdarzenia w dzienniku bez haseł.
Moduł session.py skopiowany, tak samo jak link_crypto — usługi są osobnymi
obrazami i nie importują się nawzajem.
DWIE RÓŻNICE WOBEC PEŁNEJ WERSJI, obie wynikające z tego, że demo nie ma
własnego wolumenu:
* nazwa ciasteczka jest inna. Gdyby obie aplikacje stanęły kiedyś pod jedną
domeną, ciasteczka o tej samej nazwie nadpisywałyby się i człowiek wypadałby
z jednej, logując się do drugiej.
* nie ma licznika pokolenia sesji, bo nie ma go gdzie zapisać. Zdalne
unieważnienie robi się przez DEMO_USERS: usunięcie konta albo zmiana hasła
NATYCHMIAST ubija jego otwarte sesje, bo odcisk poświadczenia w ciasteczku
przestaje pasować. Osobny test tego pilnuje. Wylogowanie i tak działa
natychmiast, bo polega na skasowaniu ciasteczka.
Klucz podpisu jest WŁASNY, nie ten z pełnej aplikacji: demo i produkcja nie mają
powodu uznawać nawzajem swoich sesji, a wspólny klucz znaczyłby, że sesja z demo
bywa ważna tam, gdzie nie powinna.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nazwa `astroklient` zostaje zarezerwowana dla przyszłej wersji produkcyjnej
programu; obecna, demonstracyjna nazywa się od teraz `astroklient-demo`.
Zmiana obejmuje katalog usługi, nazwę pliku testów, obraz w rejestrze
(astrololo-astroklient-demo), job w CI, pętlę budowania obrazów, tytuł i nagłówek
strony, nazwy loggerów, realm logowania, pole `layer` w /health oraz wymagania
PRE-28/29 w xlsx.
DWIE PUŁAPKI PODMIANY, obie sprawdzone po fakcie:
Zdublowany przyrostek. `astroklient-demo` zawiera `astroklient`, więc powtórna
podmiana dałaby `astroklient-demo-demo`. Sprawdziłem najpierw, że nigdzie nie ma
jeszcze nowej nazwy, i dopiero wtedy podmieniłem raz.
Polska odmiana. Ślepa podmiana zamieniła „astroklienta" na „astroklient-demoa”
w czterech miejscach; poprawione na „astroklienta-demo". Tytuł FastAPI wyszedłby
jako „astroklient-demo · demo", a nazwa jobu jako „Testy astroklienta-demo
(wersja demo)" — oba skrócone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Demo ma być rozdawane szeroko i różnym osobom, więc pierwsza wersja — jedno konto
na produkcyjnej warstwie danych — nie nadawała się do użycia: każdy dostawałby
dostęp do oryginalnych baz, a wgrania jednego klienta widzieliby wszyscy.
IZOLACJA OD PRODUKCJI. Warstwa danych i logiczna demo są osobne (manifesty w repo
deploy). Osobna musi być TEŻ LOGICZNA, bo zna ona jeden adres warstwy danych —
demo korzystające z produkcyjnej logiki i tak trafiłoby na produkcyjne bazy.
PULE PER KONTO w warstwie danych. Zapytanie i lista plików niosą nazwę puli;
puste = cały udział, czyli produkcja działa dokładnie jak dotąd i o pulach nic
nie wie. Nazwa puli przechodzi przez sito dopuszczające wyłącznie znaki bezpieczne
w nazwie katalogu — „../..” albo ukośnik wyprowadziłyby zapytanie wprost do cudzych
baz, więc sito ZAMIENIA podejrzane znaki zamiast ufać, że nikt ich nie poda.
PULA MUSI BYĆ W KLUCZU CACHE ZAPYTAŃ. Bez tego wynik policzony dla jednego konta
trafiłby z cache do drugiego — cicha wymiana treści baz między klientami,
niewidoczna w logach i nie do wykrycia z zewnątrz. Osobny test tego pilnuje.
PULA WYNIKA Z LOGINU, nigdy z żądania. Klient warstwy logicznej jest budowany
per żądanie i związany z pulą zalogowanej osoby; gdyby nazwa przychodziła
z formularza, wystarczyłoby podstawić cudzy login. Test wysyła `tenant`, `user`
i `login` w polach formularza i sprawdza, że nie mają na nią wpływu.
Pulę wstrzykujemy w INSTANCJĘ klienta, nie w sygnatury metod. Argumentem trzeba
by ją przeprowadzić przez protokół DataSource i build_report — kod, który o kontach
nie ma prawa nic wiedzieć — a każde nowe wywołanie byłoby okazją, żeby o nią
zapomnieć i sięgnąć nie tam.
Konta demo to lista `login:sekret` (DEMO_USERS), bo jedno wspólne konto oznaczałoby
wspólną pulę. Format i skrypt haseł te same, co w głównej aplikacji.
Pula klienta to JEDEN KATALOG, więc przejście na pełną wersję nie oznacza utraty
wgrań — procedurę importu opisuje runbook w repo deploy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Osobna warstwa prezentacji: dodanie pliku bazy i zapytanie o interpretację
urodzeniową. Nic więcej.
OSOBNA USŁUGA, NIE KONTO Z OGRANICZENIAMI. Mechanizm uprawnień z PRE-27 umiałby to
ukryć w pełnej aplikacji, ale ukrycie a nieobecność to dwie różne rzeczy: tutaj
pozostałych funkcji NIE MA W OBRAZIE — nie ma tras, nie ma szablonów, nie ma nawet
metod w kliencie warstwy logicznej. Demo można komuś oddać, nie oddając przy
okazji kodu reszty programu. Test porównuje zbiór tras aplikacji i zbiór metod
klienta z listą dokładną, więc dopisanie czegokolwiek zapala się od razu.
WGRANIE I WŁĄCZENIE TO JEDNA CZYNNOŚĆ. W pełnej aplikacji to dwie osobne decyzje
(DAN-27), bo tam ktoś nad tym panuje. Tutaj „dodać plik do bazy" musi znaczyć, że
plik od razu bierze udział w wyszukiwaniu — inaczej po wgraniu nic by się nie
zmieniło i demo wyglądałoby na zepsute. Walidacja zostaje: plik o złym układzie nie
wchodzi do użytku, ale też NIE JEST tracony, a komunikat nie zdradza reguł, bo te
zna wyłącznie administrator. Osobny test szuka w komunikacie śladów mechanizmu.
KONTO OSOBNE (DEMO_USER/DEMO_PASSWORD), nie współdzielone z główną aplikacją.
Demo pracuje na TEJ SAMEJ warstwie danych co produkcja — świadoma decyzja
właściciela — więc kto ma do niego dostęp, czyta oryginalne bazy, a jego wgrania
trafiają do produkcyjnego zbioru. Własne poświadczenia pozwalają odciąć demo jedną
zmienną, bez ruszania kont głównej aplikacji i bez zmiany hasła komukolwiek.
Zapisane wprost w README usługi i w manifeście, nie tylko w tej wiadomości.
Rozmowa z warstwą logiczną idzie tym samym szyfrowanym łączem (PRE-16) i pod tym
samym tokenem międzywarstwowym (LOG-32) — demo nie jest furtką omijającą ochronę.
Automatyczna dokumentacja wyłączona, jak w pełnej aplikacji: /docs wypisałoby
komplet tras, a demo ma nie zdradzać nawet własnej powierzchni.
Zależności celowo krótsze niż w prezentacji: bez Excela, bez stref czasowych
z lokalizacji, bez niczego pod kosmogram. Każda zbędna zależność w obrazie demo to
kolejna rzecz do pilnowania.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ukrywanie jest teraz nadrzędne wobec wygody i czytelności komunikatów.
Persona: konto z uprawnieniami files + files_input, zatrudnione wyłącznie do
wgrywania plików. Nie ma się dowiedzieć, po co je wgrywa ani co program będzie
robił — bo to rozgada.
Audyt sześciu kanałów wycieku (statyki, HTML, sondowanie HTTP, ekran plików,
odpowiedzi JSON i błędy, pozostałe warstwy) potwierdził 26 wycieków, każdy
odtworzony uruchomionym kodem i zweryfikowany adwersarialnie. Ani jeden nie był
przyciskiem.
ZASÓB JEST CZĘŚCIĄ FUNKCJI
/static/ omijało CAŁĄ bramkę (PUBLIC_PREFIXES), więc każdy skrypt i arkusz
pobierał ktokolwiek, także niezalogowany, pod zgadywalnym adresem — a ich treść
wymienia ekrany, dostawców modeli i przeznaczenie plików. Ruch ten nie trafiał
przy tym ani do dziennika, ani pod limit żądań, więc wyciek był niewidoczny.
Zasoby idą teraz trasą z bramką; każdy ma w features.STATIC uprawnienie swojego
ekranu. Publiczny został jeden base.css, bo potrzebuje go ekran logowania.
KOMENTARZ NIE JEDZIE NA DRUT
Komentarze w CSS/JS opisywały funkcje pełnymi zdaniami po polsku — łącznie
z „Wstrzymane widzi tylko administrator", czyli i mechanizmem kwarantanny,
i istnieniem konta o wyższych uprawnieniach. _asset_body() usuwa je przy
serwowaniu; w repozytorium zostają.
styles.css rozbity na base.css + arkusz na ekran + x-ai.css. Jeden plik z
wszystkimi selektorami był spisem treści programu. Podział zrobiony
mechanicznie, z osobnym sprawdzeniem, że żaden ekran nie stracił reguły.
base.html ładował skrypty kosmogramu na KAŻDEJ stronie — konto mające wyłącznie
Pliki pobierało je przy wejściu na swój jedyny ekran, razem ze wzmianką
o „przyszłej zakładce". Teraz dokłada je ekran, który ich używa.
RÓŻNICA JEST INFORMACJĄ
Komunikat po wgraniu pliku różnił się zależnie od wyniku walidacji — czyli był
wyrocznią do odgadywania reguł, które ma znać tylko administrator — i mówił
wprost, że plik „musi zatwierdzić administrator". Teraz jest jeden, ten sam.
_logic_error wypisywał na ekran nazwę trasy, nazwę podsystemu, nazwę gałęzi
rozwojowej i wewnętrzny host:port. Jedno zdanie dla wszystkich awarii, szczegóły
do dziennika. Odsiew w jednym punkcie, nie w siedemnastu wywołaniach.
Ponadto: stopka nie ogłasza architektury, /health nie nazywa warstwy, konto bez
ekranów dostaje 404 zamiast tłumaczenia, ekran plików mówi o plikach zamiast
o „bazach interpretacyjnych", klasy .house-warning i .account-card przemianowane
na neutralne, a logic/data/render/engine-swisseph nie wystawiają już /docs ani
/openapi.json i nie publikują portów na hoście.
ZAPORA SŁOWNIKOWA
test_slownik_zakazany.py nie sprawdza miejsc, tylko przechodzi wszystko, co dane
konto może pobrać, i szuka słów, które nie mają prawa paść (87 pozycji dla tej
persony). Nazwy funkcji, adresy ekranów i nazwy zasobów biorą się wprost
z katalogu, więc nowa funkcja obejmuje się sama. Kontrola pozytywna pilnuje, żeby
test nie przechodził dlatego, że program jest pusty.
Sprawdzone: zapora puszczona na treść sprzed poprawek daje 16 trafień na samym
styles.css i łapie każdy ze zneutralizowanych komunikatów. 358 testów zielonych,
ekrany obejrzane w przeglądarce.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Wymaganie było mocniejsze niż schowanie przycisku: po niedostępnej funkcji nie
może zostać śladu w źródle strony. Największy wyciek nie był przyciskiem —
_prompt_block wstrzykiwał w stronę CAŁY katalog modeli jako JSON (dostawcy,
nazwy modeli, rozmiary okien kontekstu), na każdym ekranie z generowaniem,
niezależnie od uprawnień konta.
Druga dziura była głębsza: handlery nie sprawdzały nic. Trasa /interpret musi
być dostępna dla konta z Interpretacjami, więc granica przebiega WEWNĄTRZ niej,
po polu `action` — spreparowany formularz z action=prompt generował tekst, a
action=export pobierał arkusz, mimo że szablon chował oba przyciski.
Akcja bez uprawnienia wraca do akcji domyślnej ekranu zamiast dawać błąd:
komunikat „brak uprawnień do generowania" sam w sobie mówiłby, że taka funkcja
istnieje.
Ślady wycięte także tam, gdzie nie były kontrolką: znaczniki natalNote/
reportNatal, pliki models.js/progress.js/natal.js/predictions.js oraz podtytuł
ekranu Skompiluj, który wymieniał interpretację od AI z nazwy.
12 testów; 9 z nich pada na kodzie sprzed poprawki (sprawdzone przez cofnięcie
zmian w app/). Kontrola pozytywna pilnuje, żeby nie przechodziły dlatego, że
generowanie jest zepsute dla wszystkich.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Basic nie miał wylogowania i nie dało się tego obejść: przeglądarka zapamiętuje
hasło i dosyła je SAMA przy każdym żądaniu, więc serwer nie ma czego zapomnieć.
Poprzednia próba (LOG-32) opierała się na nakłonieniu przeglądarki, żeby porzuciła
zapamiętane dane — zachowaniu powszechnym, ale nigdzie nie zapisanym. Teraz to
serwer decyduje, czy dana przeglądarka jest w środku, i może to cofnąć.
TRZY POZIOMY UNIEWAŻNIENIA, celowo rozdzielone, bo każdy kosztuje co innego:
1. wylogowanie = skasowanie ciasteczka. Natychmiastowe, bez magazynu.
2. zmiana hasła albo skasowanie konta = odcisk poświadczenia wpisany
w ciasteczko przestaje pasować. Dzieje się SAMO, bez pamiętania o tym.
Bez tego odebranie komuś dostępu nie odbierałoby dostępu aż do wygaśnięcia.
3. „zamknij sesje" z ekranu kont = licznik pokolenia. Jedyny wymagający zapisu,
więc jedyny opcjonalny: gdy licznika nie ma, poziomy 1 i 2 nadal działają.
KONTO ADMINISTRACYJNE ODSEPAROWANE. Sprawdzane pierwsze i BEZ DOTYKANIA pliku
kont, co daje dwie rzeczy naraz: konto z pliku o tym samym loginie nie przesłoni
administratora, a administrator zaloguje się także wtedy, gdy plik jest uszkodzony
— czyli w jedynej sytuacji, w której ktoś MUSI wejść, żeby to naprawić. Trzymanie
jego stanu w tym samym pliku dawałoby zakleszczenie: nie da się naprawić, bo nie
da się wejść. Jego odpowiednikiem „wyloguj zewsząd" jest zmiana APP_PASSWORD.
KLUCZ WYMAGANY, FAIL-CLOSED. Usługa z kontami, ale bez klucza podpisu, nie
odróżniłaby ważnej sesji od podrobionej, więc nie wstaje — i lepiej przy starcie
niż przy pierwszym logowaniu człowieka. Losowanie klucza byłoby wygodne, ale
wylogowywałoby wszystkich przy każdym restarcie poda: wygląda jak awaria i uczy
ludzi ignorować ekran logowania.
Ciasteczko HttpOnly (jeden wstrzyknięty skrypt inaczej wynosi sesję) i
SameSite=Strict (obca strona nie zadziała w imieniu zalogowanego). Wylogowanie
POST-em, nie odsyłaczem: pod adresem GET wystarczyłby obrazek na obcej stronie.
Adres powrotu po zalogowaniu przechodzi przez sito — bez tego `?dokad=https://obcy`
zamieniłby nasz ekran logowania w narzędzie do wyłudzania haseł.
Kres bezczynności 8 h i twardy 30 dni. Znacznik aktywności odświeżany z progiem,
inaczej Set-Cookie leciałby przy każdym obrazku i arkuszu stylów.
Zdarzenia logowania w dzienniku (PRE-17). Nieudane próby są tam ważniejsze od
udanych: pojedyncza nic nie znaczy, ale seria pod jednym adresem to jedyny
widoczny ślad zgadywania haseł. Test pilnuje, że hasło tam nie trafia.
Sprawdzone w przeglądarce: po zalogowaniu ciasteczko jest NIEWIDOCZNE dla
JavaScriptu, a po wylogowaniu wejście na chronioną stronę ląduje na ekranie
logowania — czyli dokładnie to, czego Basic nie potrafił.
Testy: 21 na rdzeń podpisywania (w tym podrabianie ładunku, podpisu i klucza,
ciasteczko z przyszłości, śmieci na wejściu), reszta przepisana z Basic na sesje.
Prezentacja 338 zielonych.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aplikacja nie miała jak z siebie wyjść: raz podane hasło działało do zamknięcia
przeglądarki, a na wspólnym komputerze nie było sposobu, żeby oddać ekran komuś
innemu.
HTTP BASIC NIE MA PRAWDZIWEGO WYLOGOWANIA i to jest sedno tej zmiany. Nie ma
sesji do skasowania: przeglądarka zapamiętuje login i hasło, po czym dosyła je
SAMA przy każdym żądaniu. Serwer nie ma czego zapomnieć — kolejne kliknięcie
przyszłoby z kompletem poświadczeń i weszłoby z powrotem.
Działa natomiast doprowadzenie do tego, żeby to PRZEGLĄDARKA porzuciła zapamiętane
dane, i robimy to dwutorowo, bo ani jedno, ani drugie osobno nie wystarcza:
1. /wyloguj odpowiada ZAWSZE 401 z nagłówkiem WWW-Authenticate, co wymusza
ponowne pytanie o hasło. Działa bez JavaScriptu, ale samo w sobie zostawia
stare dane w pamięci przeglądarki: po anulowaniu okienka wystarczyłoby wejść
na dowolny adres, żeby wrócić do środka.
2. wyloguj.js wysyła żądanie z CELOWO błędnymi danymi, którym przeglądarka
nadpisuje swój wpis. To jest część, która faktycznie czyści pamięć — ale
opiera się na zachowaniu powszechnym, a nie zapisanym w standardzie, więc
nie może być jedynym mechanizmem.
Strona wylogowania mówi wprost, że pewnym sposobem w KAŻDEJ przeglądarce jest
zamknięcie okna. Nie obiecujemy więcej, niż Basic potrafi — obietnica bez pokrycia
byłaby tu gorsza od braku przycisku, bo dawałaby złudzenie, że ekran jest oddany.
Trasa stoi POZA bramką logowania, celowo: inaczej dostałaby 200 od zalogowanej
sesji i nie miałaby jak odpowiedzieć 401. Odpowiada też bez logowania — inaczej
wyjście wymagałoby bycia w środku, co jest błędnym kołem. Nagłówki zakazują
zapamiętania strony, bo oddana z pamięci podręcznej nie dotarłaby do serwera
i okienko w ogóle by się nie pojawiło.
Obok wyjścia pokazujemy, KTO jest zalogowany: bez tego przycisk jest w połowie
bezużyteczny, bo na wspólnym komputerze nie wiadomo, kogo się wylogowuje. Przy
wyłączonym logowaniu nie ma ani jednego, ani drugiego — przycisk sugerowałby
ochronę, której nie ma.
Sprawdzone w przeglądarce: oba żądania wychodzą (to z błędnymi danymi i samo
przejście), oba wracają 401, strona renderuje się poprawnie. Samego unieważnienia
pamięci poświadczeń NIE dało się tu potwierdzić — wymaga okienka systemowego,
którego automat nie obsłuży.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Dwa testy z PR #71 przechodziły lokalnie i padały w CI. Przyczyna nie miała nic
wspólnego z badaną rzeczą: wymuszały awarię przez chmod 000 i chmod 555, a CI
działa jako ROOT — root omija bity uprawnień w Linuksie, więc odczyt i zapis się
udawały i asercje leciały na komunikat, którego nie było.
Test zależny od tego, KTO go uruchamia, jest gorszy niż jego brak: daje fałszywe
poczucie pokrycia i zapala się w miejscu niezwiązanym z tym, co sprawdza.
Teraz awarię wymuszamy podmianą dokładnie tego punktu, w którym system plików
mówi „nie": odczytu pliku kont (osłona przepuszcza wszystko inne, żeby szablony
nadal się wczytywały) oraz mkstemp przy zapisie. To drugie jest celowe — mkstemp
wywala się PIERWSZY przy katalogu tylko do odczytu, jeszcze zanim dojdzie do
zapisu i podmiany, i właśnie tego dotyczyła naprawiana poprawka.
Sprawdzian na PRAWDZIWYCH prawach zostaje, ale z pominięciem przy uruchomieniu
z roota — jako kontrola, że podmiana odpowiada rzeczywistości, a nie tylko sama
sobie. W CI się nie wykona i to jest w porządku: znaczyłby tam tyle co nic.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Po wdrożeniu DAN-27 przestało działać wyszukiwanie (500 z /search) i ekran
Ustawienia (502 z /bases). Ekran „Pliki" działał, co dobrze pokazuje, gdzie leżał
problem: nie w rejestrze, tylko w JEGO STYKU z kodem, który zastąpił.
1. NameError przy KAŻDYM wyszukiwaniu. Przepisując `_enabled_files` pod rejestr
usunąłem lokalny `from app import bases`, a modułowego w tym pliku nigdy nie
było. Wołanie bases.disabled_entries() wywracało się natychmiast.
2. KeyError na /bases. Rejestr oddawał `in_use`, a endpoint liczy `b["enabled"]` —
tak samo warstwa logiczna i szablon Ustawień (DAN-15/PRE-09). Rejestr wszedł
w miejsce starej listy baz, więc musi mówić jej językiem; oddaje teraz oba
pola o tej samej wartości.
3. Cache podawany jako baza. `_scan` filtrował tylko nazwę PLIKU, więc zawartość
`.cache` wchodziła do rejestru (pliki w środku nie zaczynają się od kropki),
a przy pierwszym uruchomieniu była jeszcze przyjmowana jako aktywna. Teraz
pomijamy wszystko, co leży w ukrytym KATALOGU. Ten wyszedł dopiero z nowych
testów — nie wiedziałem o nim.
DLACZEGO TESTY TEGO NIE ZŁAPAŁY. test_files.py sprawdza rejestr w IZOLACJI i był
zielony, podczas gdy produkcja leżała. Groźne w takiej podmianie nie jest to, co
nowy moduł robi w środku, tylko czy mówi tym samym językiem, co jego odbiorcy.
Doszedł więc test_rejestr_integracja.py: wyszukiwanie przez dostawcę (obie gałęzie,
także ta z DISABLED_BASES), kontrakt pól listy baz, endpoint /bases przez trasę
oraz odstawienie bazy widziane JEDNOCZEŚNIE w wyszukiwaniu i w liczniku.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bez tego wdrożenie DAN-27 WYŁĄCZYŁOBY WYSZUKIWANIE. Dotąd bazy działały domyślnie
(wyłączało się je jawnie przez DISABLED_BASES). Po przejściu na rejestr plik bez
wpisu w stanie dostaje `ready`, czyli NIE w użyciu — a stan po wdrożeniu jest
pusty. Efekt: żadna baza nie jest aktywna i program nagle niczego nie znajduje.
Ta cicha zmiana zachowania byłaby gorsza od awarii, bo wygląda jak pusta baza,
a nie jak zepsuty deploy — i szukałoby się jej w warstwie danych albo w indeksie.
Teraz brak PLIKU stanu oznacza pierwsze uruchomienie i bazy zastane są przyjmowane
jako aktywne. Pusty słownik przy ISTNIEJĄCYM pliku to co innego: ktoś świadomie
wszystko odstawił, więc nie wskrzeszamy — osobny test tego pilnuje.
Rozróżnienie jest celowe i też pod testem: `ready` dotyczy plików WGRANYCH przez
ekran (te ktoś musi świadomie włączyć), a nie zastanych przy przejściu na rejestr.
Inaczej nowa baza wchodziłaby do wyników sama, bez niczyjej decyzji.
Przyjęcie działa też na udziale tylko do odczytu: zapis stanu wtedy nie przechodzi,
więc powtórzy się przy każdym uruchomieniu — zachowanie to samo, koszt żaden.
Dwa testy opisujące STARE zachowanie zostały poprawione, bo to one były błędne.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ekran „Konta" wywalał się na produkcji błędem 500 bez słowa wyjaśnienia.
Odtworzone lokalnie: `_read()` łapał wyłącznie brak pliku i zły JSON, więc każdy
inny błąd systemu plików — a na udziale NFS to głównie prawa — leciał na wierzch
jako nieobsłużony wyjątek.
To jest szczególnie zły sposób na awarię AKURAT TUTAJ: ekran kont jest jedynym
miejscem, z którego administrator może taki problem naprawić, a gołe 500 nie mówi
mu ani co, ani gdzie.
Teraz każdy błąd magazynu ma twarz: osobny wyjątek AccountsUnavailable niosący
ŚCIEŻKĘ i powód z systemu operacyjnego, plus podpowiedź najczęstszej przyczyny
(prawa katalogu na udziale albo wolumen zamontowany tylko do odczytu). Strona
renderuje się normalnie z tym komunikatem u góry.
Objęte są wszystkie cztery drogi zapisu, a nie tylko odczyt. W szczególności
mkstemp: przy katalogu tylko do odczytu wywala się ONO pierwsze, jeszcze zanim
dojdzie do zapisu i podmiany — więc obudowanie samego os.replace nic by nie dało
(złapane testem, nie przeglądem kodu).
USZKODZONY PLIK NIE JEST NADPISYWANY. Wcześniej niepoprawny JSON dawał pusty
zbiór kont, co przy pierwszym zapisie skasowałoby WSZYSTKIE konta bez śladu.
Teraz to odmowa z komunikatem — plik zostaje nietknięty, a test tego pilnuje.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Warstwa danych ma SQLAlchemy, ale nie miała czym rozmawiać z Postgresem. Bez
psycopg adres `postgresql+psycopg://…` wywala się dopiero przy PIERWSZYM
połączeniu — już na klastrze, komunikatem o braku modułu. [binary] bierze gotowe
koło, więc obraz nie kompiluje libpq.
Sam SQL_URL niczego jeszcze nie przełącza: o dostawcy decyduje DATA_PROVIDER,
które zostaje na `excel`, dopóki lustro nie jest zaimplementowane i sprawdzone.
Dzięki temu Postgresa da się wdrożyć i obejrzeć bez ryzyka dla działającego
wyszukiwania.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ekran „Pliki" z trzema poziomami, wpiętymi w kontrolę dostępu z PRE-27:
„files" widzi listę i KLIKANIEM decyduje, z których baz program korzysta,
„files_input" dokłada wgrywanie i ARCHIWIZACJĘ,
administrator kasowanie, przywracanie z archiwum i REGUŁY WALIDACJI.
STAN JEST TERAZ TRWAŁY. DAN-15 trzymał go w zmiennej DISABLED_BASES, bo warstwa
danych nie miała gdzie zapisywać — udział był montowany read-only. Skoro stan ma
być klikany, musi przetrwać restart, więc udział jest zapisywalny, a stan leży
w pliku obok baz (zapis atomowy: plik opisuje CAŁY zbiór, więc obcięcie w połowie
skasowałoby wiedzę o wszystkich naraz). DISABLED_BASES zostaje jako awaryjne
wyłączenie z konfiguracji i odsiewa DODATKOWO — nie odwrotnie, bo inaczej ktoś
z dostępem do ekranu włączyłby bazę wyłączoną świadomie na poziomie wdrożenia.
ARCHIWIZACJA NIE KASUJE. Plik zostaje na dysku, zamrożony, ze znacznikiem czasu;
znika wyłącznie z użytku. To najdalej idąca operacja osoby wgrywającej dane —
kasować może tylko administrator. Test sprawdza, że plik po archiwizacji nadal
istnieje, bo to jest cała istota tej operacji.
WALIDACJA JEST BRAMKĄ DO UŻYTKU, NIE FILTREM NA WEJŚCIU. Plik wgrany zostaje
NIEZALEŻNIE od wyniku — nie tracimy niczego, co ktoś wgrał. Zmienia się tylko to,
czy da się go włączyć. Sprawdzenie biegnie też w chwili włączania, nie tylko przy
wgrywaniu: reguły mogą się zmienić po fakcie.
O WALIDACJI WIE TYLKO ADMINISTRATOR. Pliki wstrzymane są odsiewane W WARSTWIE
DANYCH przy for_admin=False, a nie ukrywane w szablonie — gdyby dochodziły do
przeglądarki, wystarczyłby podgląd źródła, żeby poznać reguły. Odmowa włączenia
wraca do konta bez uprawnień BEZ POWODU, bo powód zdradza regułę. Sekcja reguł
nie trafia nawet do źródła strony. Test parametryzowany po obu niższych poziomach
szuka w odpowiedzi śladów mechanizmu i wymaga, żeby żadnego nie było.
Każdy plik ma policzony sha256 — tożsamość niezależna od nazwy. Wykorzystuje ją
już odrzucanie duplikatów, a w kroku drugim posłuży do pilnowania zgodności
lustra w SQL.
Przy okazji naprawiony błąd, który dopiero co bym wprowadził: Path("") to
Path("."), czyli wartość PRAWDZIWA, więc `Path(os.getenv(...)) or domyślna`
zawsze wybierało pustą zmienną i zapisywało stan do katalogu bieżącego.
Wymaga zapisywalnego udziału — osobny PR w repo deploy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ekran „Konta" dla administratora: zakładanie, kasowanie i nadawanie uprawnień.
Zestaw funkcji zależy od konta, a konto ograniczone widzi program KOMPLETNY —
tylko mniejszy.
PODZIAŁ NA GRUPY. Ekrany to zakładki (7), bo zakładka jest naturalną jednostką —
to ją widać w nawigacji. Rozszerzenia to POZIOMY ZŁOŻONOŚCI wewnątrz ekranów:
porównanie systemów domów, wykresy dodatkowe, obliczenia zaawansowane, generowanie
tekstu przez model (kosztuje pieniądze) i eksport plików. Konto bez porównania
domów dostaje horoskop w Whole Sign i nie wie, że systemów jest trzynaście.
NIC NIE ZDRADZA, ŻE JEST WIĘCEJ:
- brak pozycji w menu zamiast pozycji wyszarzonej,
- 404 zamiast 403 — odmowa z powodem sama mówi, że coś tam jest,
- rysunki bez uprawnienia w OGÓLE NIE POWSTAJĄ, więc nie ma ich nawet w źródle,
- automatyczna dokumentacja API wyłączona. /docs, /redoc i /openapi.json wypisują
komplet tras, czyli spis wszystkich funkcji programu — ochrona zakładek nic by
nie dała, gdyby obok leżał ich katalog. Znalezione TESTEM przechodzącym po
trasach aplikacji, nie przeglądem kodu.
KONTO ADMINISTRACYJNE zostaje w APP_USER/APP_PASSWORD, jak było. Nie leży w pliku
kont, więc nie da się go skasować ani ograniczyć z ekranu. Konto założone w pliku
o tym samym loginie NIE przesłoni administracyjnego — kolejność sprawdzania jest
odwrotna, inaczej dałoby się odebrać uprawnienia jedynemu, kto może je nadawać.
Uprawnienia administracyjnego nie da się też nadać z formularza: odsiewamy je
w normalise(), a nie w handlerze, więc żadne spreparowane żądanie tam nie sięgnie.
GRANICA JEST W HANDLERZE, NIE W SZABLONIE. Ukrycie pola chroni przed przypadkiem,
nie przed kimś, kto zna nazwy pól — _limit_options() ścina opcje po stronie
serwera i test wysyła spreparowane żądanie, żeby to potwierdzić.
MAPA TRASA→UPRAWNIENIE JEST JEDNA (features.ROUTES). Rozproszenie jej po
dekoratorach kończy się trasą, o której ochronie ktoś zapomniał — a taka dziura
jest niewidoczna, dopóki ktoś jej nie znajdzie. Trasa bez wpisu wymaga
administratora: przeoczenie ma ZAMYKAĆ, nie otwierać. Test idzie po trasach
APLIKACJI, nie po wpisach mapy — inaczej potwierdzałby tylko sam siebie.
Konta w pliku JSON na własnym podkatalogu NFS (nie tam, gdzie bazy — zamontowanie
całego udziału obeszłoby bokiem DAN-25). Hasła wyłącznie jako hash scrypt, tym
samym mechanizmem co APP_USERS. Zapis atomowy, bo przerwanie zapisu na NFS
obcięłoby plik, czyli skasowało wszystkie konta naraz.
Przy okazji przepisane trzy testy, które greppowały nawigację i main.py: menu
powstaje teraz z katalogu funkcji, więc szukanie sztywnych linków w base.html
niczego już nie sprawdzało.
Wymaga wolumenu na konta — osobny PR w repo deploy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Rysunek niesie <title> przy każdym obiekcie i każdej linii aspektu i to
wystarczało, dopóki koło było statyczne. Po dodaniu powiększania na pełne okno
dymki przestały się pokazywać.
CO SPRAWDZIŁEM W PRZEGLĄDARCE (1280×900, komplet danych): elementy z <title>
SĄ osiągalne kursorem — 19 z 20 trafień w hit-teście — więc nic ich nie zasłania
i problem nie leży w geometrii ani w pointer-events. Której dokładnie reguły
przeglądarka używa do stłumienia natywnego dymka, nie ustaliłem.
Nie ma to jednak znaczenia, bo natywny dymek jest tu i tak kiepskim narzędziem:
pojawia się po sekundzie zwłoki, nie da się go stylować, nie działa na dotyku
i nie ma go czym wywołać z klawiatury. Własny dymek usuwa zależność od zachowania
przeglądarki i przy okazji jest czytelniejszy.
Tekst bierzemy z <title> JUŻ OBECNEGO w rysunku, a nie z drugiej kopii opisów
w JS — inaczej rozjechałyby się przy pierwszej zmianie treści. Na czas najechania
<title> jest odpinany i wieszany z powrotem po zejściu kursora: dzięki temu nigdy
nie widać dwóch dymków naraz, a czytniki ekranu zachowują nazwę dostępną.
Warstwa 1150 CELOWO pomiędzy: nad nakładką powiększonego koła (1100), bo tam
właśnie zgłoszono problem, i pod oknem postępu (1200), które ma zostać na wierzchu
podczas pisania horoskopu. Test pilnuje tej kolejności liczbowo.
Ścieżka PDF nietknięta — składa się po stronie serwera, <title> zostają w rysunku.
Zweryfikowane w obu stanach koła: dymek pokazuje „Sun · 12°30'00'' · dom 1" nad
glifem i „Sun trygon Moon · orb 3.64°" nad linią aspektu, po powiększeniu też
(kursor-lupa mu nie przeszkadza), a po zejściu kursora wszystkie 20 <title>
wraca na miejsce.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ETAP 5, część pierwsza: assign_house pod wyrocznią (swe_house_pos).
Osobny rodzaj błędu niż same cuspy — i od razu jeden znalazł.
BŁĄD: assign_house szło ZAWSZE do przodu. Przy dużych szerokościach systemy
dzielące koła wielkie mają kolejność domów ODWRÓCONĄ (przy φ=−84,3° cusp domu I
wypada na 174,2°, a domu II na 165,3°) — co nie jest usterką, bo wyrocznia zwraca
dokładnie te same wartości. Suma przeskoków „do przodu" wychodziła 3960° zamiast
360°, czyli każdy krok obchodził koło dookoła. Planety lądowały w złych domach
dla regiomontanusa, campanusa i topocentrica: 9,7-12,5% przypadków. Błąd cichy —
wykres wyglądał bez zarzutu. Kierunek bierzemy teraz z samych cuspów.
TOPOCENTRIC MA JEDNAK GRANICĘ DZIEDZINY — korekta tego, co pisałem wcześniej.
Cuspy są poprawne wszędzie (zgodne z wyrocznią co do zera), ale powyżej koła
podbiegunowego przestają DZIELIĆ OKRĄG: cusp VII (= I + 180°) wypada przed
cuspem VI i domy nachodzą na siebie. Przypisanie planety traci wtedy sens —
co potwierdza sama wyrocznia, której swe_house_pos przeczy tam własnym cuspom
(100% zgodności do 62°, 83,9% przy 66°, ok. 50% przy 72°; regiomontanus 100%
w tych samych punktach). Odmawiamy, z jawnym fallbackiem jak Placidus i Koch.
Próg jest WYPROWADZONY z warunku „dwanaście cuspów sumuje się do 360°", nie
dobrany pod wynik testu — i wypada na kole podbiegunowym (zmierzone: 100%
podziałów do 65°, 78% w pasie 66-67°). To inny rodzaj granicy niż u Placidusa
i Kocha: tam nie istnieją same cuspy, tu istnieją, tylko nie tworzą podziału.
Framework dostał pojęcie dziedziny WĘŻSZEJ niż wyroczni (NARROWER_THAN_ORACLE),
zamiast wyjątku „bo topocentric": skoro wyrocznia przeczy sama sobie, nie może
rozstrzygać, więc tam nie porównujemy — a nasze przypisanie jest w tym obszarze
sprawdzane testem samospójności z cuspami, bez swissepha.
UKŁAD STRONY — zmierzony na żywej stronie, nie na oko:
- tabela porównania przy 13 systemach miała 14 kolumn i 1863 px, a stała
w rodzicu bez overflow-x, więc ROZPYCHAŁA CAŁY DOKUMENT: 1713 px przy oknie
1280 px, poziomy pasek na body. Teraz ma własny kontener przewijany
(dokument 1265 px, nie przewija się), a numer domu jest przyklejony do lewej,
bo inaczej po przewinięciu nie wiadomo, który to wiersz.
- przypis „* nie działa za kołem podbiegunowym" siedział WEWNĄTRZ <label>
selektora, łamał się na dwie linie i rozciągał wiersz siatki ze 66 do 108 px,
rozjeżdżając go z sąsiednim polem. Wyjaśnienie stoi teraz raz, przy
checkboxach z gwiazdkami; wiersz wrócił do 66 px.
- 13 checkboxów na flexie zawijało się w poszarpane wiersze — jest siatka
o stałej szerokości kolumny (auto-fill, więc na wąskim ekranie kolumn mniej).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Ostatnie trzy pozycje z treści LOG-05, których wcześniej nie było:
- whole_sign_aries — znaki jako domy, ale dom I ZAWSZE na 0° Barana, niezależnie
od Ascendentu (tradycja indyjska i część szkół hellenistycznych),
- equal_mc — równe domy zakotwiczone na MC: dom X zaczyna się dokładnie na
południku, a nie ma go gdzieś w środku,
- obrót kosmogramu: Ascendent albo 0° Barana po lewej stronie koła. Zmienia
WYŁĄCZNIE rysunek, żadna liczba nie jest przeliczana. Wariant „od Barana"
unieruchamia koło względem zodiaku, więc dwa horoskopy da się porównać na oko.
Oba nowe systemy zgodne z wyrocznią co do zera od pierwszego uruchomienia.
Razem 13 systemów: 2 833 424 porównania w przemiale, zero przekroczeń.
PRZY OKAZJI — DWA BŁĘDY, KTÓRE SAM WPROWADZIŁEM I KTÓRYCH TESTY NIE WIDZIAŁY:
- linia zbierająca ostrzeżenia o fallbacku trafiła do handlera strony głównej
zamiast do compile_pdf: odwoływała się do nieistniejącej zmiennej, czyli 500
na stronie głównej, a do PDF-a ostrzeżenia nie docierały wcale,
- compile_build używał parametru formularza, którego nie miał w sygnaturze.
Oba przeszły przez komplet zielonych testów, bo żaden nie wywoływał POST-a —
testy prezentacji sprawdzały teksty w szablonach i w main.py. Doszły więc testy
uderzające w prawdziwe trasy (POST / i POST /compile ze stubowaną logiką), które
łapią tę klasę błędu.
Z tego samego powodu przepisane dwa testy PDF-a: greppowały z main.py dokładny
kształt wywołania render(chart, theme="print") i pękały przy dopisaniu argumentu,
mimo poprawnego zachowania. Teraz wołają trasę i sprawdzają, że KAŻDY z czterech
rysunków dostaje motyw druku.
LOG-05 i PRE-05 → Zrobione w docs/astrololo_wymagania.xlsx.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Topocentric był wycofany z powodu rozjazdu przy |φ| ≈ 89,9°. Ta diagnoza była
BŁĘDNA: opierała się wyłącznie na zestawie brzegowym, który próbkuje tylko wybrane
szerokości. Przemiał losowy pokazał prawdziwą skalę — błędy od ~70° w górę,
do 50% przypadków blisko biegunów, 6,5% całości. Nie dwa przypadki brzegowe.
Przyczyną nie była jednak konstrukcja, tylko wybór gałęzi: dwa koła wielkie
przecinają się w dwóch punktach antypodycznych. Kolejno zawiodły reguły „po której
stronie MC", „w łuku kwadrantu", „wschodnia połowa horyzontu" i śledzenie ciągłości
krokami (to ostatnie maskuje własną patologię — po korekcie do bliższej gałęzi
zmierzony skok ZAWSZE wychodzi ≤ 90°, więc detektor nigdy się nie zapala).
Wszystkie te reguły rozstrzygają lokalnie, a przy dużych szerokościach kolejność
domów potrafi się odwrócić: przy φ = −79,55° MC wypada na 306,8°, a dom 11 na
291,4°. To jest poprawne — wyrocznia zwraca to samo.
Rozwiązanie: nie wybierać w ogóle. Iloczyn wektorowy zenitu z biegunem ekliptyki
jest ciągłą funkcją parametru rodziny i sam niesie właściwy zwrot; dwuznaczność
wprowadza dopiero atan2. Zostajemy w wektorach, znak ustalamy raz — kotwicząc
rodzinę na MC górującym.
Wynik: 0,000000000° na 240 000 porównań, cała dziedzina, bez iteracji i bez
zawężania szerokości. Żadna granica dziedziny nie jest tu potrzebna, więc żadnej
nie udajemy — test pilnuje, że topocentric liczy się wszędzie i nie fallbackuje.
Morał do frameworka: zestaw brzegowy mówi, CZY system się psuje; dopiero przemiał
losowy mówi JAK BARDZO. Wniosek o skali wyciągnięty z samych brzegów był tu
zaniżony o trzy rzędy wielkości. Odnotowane w tests/oracle/README.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Etap 2: dwa systemy łuku dobowego — jedyne, które mają miejsca, gdzie po prostu
NIE ISTNIEJĄ. Koch zgadza się z wyrocznią co do zera; Placidus do 1,7e-6°, przy
czym to próg zbieżności WYROCZNI, nie nasz: nasze cuspy spełniają definicję
Placidusa z dokładnością 1e-12° (osobny test, działa bez swissepha).
Placidus jako jedyny nie ma wzoru zamkniętego — cusp jest zdefiniowany warunkiem
na samego siebie („punkt, który przebył 1/3 swojego półłuku"), więc iterujemy po
punkcie stałym do 1e-11°. Brak zbieżności traktujemy jako wyjście poza dziedzinę,
nie jako wynik.
Koch okazał się natomiast ZAMKNIĘTY: jego kryterium to czas od wschodu stopnia
stojącego na MC, a półłuk tego stopnia znamy wprost z jego deklinacji. Definicja
za Astrodienst (astro.com/astrowiki/en/Koch_House_System) — nie zgadywana.
Powyżej koła podbiegunowego oba odmawiają liczenia i wyrocznia odmawia dokładnie
tych samych przypadków (5245/20 000 losowych, zero rozjazdów dziedziny). Odmowa
jest wyjątkiem, nie liczbą: cicha podmiana systemu jest niewykrywalna z wykresu.
Ustępstwo wobec rzeczywistości siedzi osobno, w cusps_detailed(): podstawia
Porphyry'ego i ZAWSZE zostawia ślad. Ten ślad idzie wszystkimi trzema wyjściami —
na ekran (ramka, nie „muted"), w prompt do modelu (inaczej napisze „Twój Placidus"
o Porphyrym) i do PDF-a, w ramce PRZED rysunkami. Astrolog z Tromsø dostaje
wynik i wie, że go dostał inaczej.
Przy okazji: nazwy systemów były zaszyte w czterech szablonach naraz. Przy trzech
systemach uchodziło to na sucho, przy dziesięciu nie — jest katalog w jednym
miejscu, a testy szablonów RENDERUJĄ je zamiast szukać tekstu w źródle, więc
łapią też literówki w Jinja.
Większe jądro efemeryd (de441): świadomie zdegradowane do „nice to have" —
rozszerza wyłącznie zakres dat, nie poprawia niczego w obecnym. Odnotowane
w domain.py przy JD_MIN/JD_MAX, żeby nie wróciło po cichu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Rozszerzenie houses.SYSTEMS do ośmiu pozycji odblokowało w chart.py filtr
`house_system in H.SYSTEMS`, ale liczenie zostało na H.cusps(), które zna
wyłącznie trzy systemy dzielące ekliptykę i dla pozostałych rzuca ValueError.
Wybranie campanusa przechodziło więc walidację i dopiero potem wywalało 500.
Test parametryzowany po H.SYSTEMS zamyka tę klasę błędu na przyszłość: każdy
system ogłoszony na liście musi przejść przez build_chart, więc dopisanie
nazwy bez przepięcia liczenia od razu zapali się na czerwono.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Etap 1: systemy o zamkniętym wzorze. Dochodzą vehlow, morinus, regiomontanus,
campanus i alcabitus — każdy zgodny ze Swiss Ephemeris z maksymalnym odchyleniem
0,000000000° na 240 000 porównań (zestaw brzegowy + przemiał 20 000 losowych).
Cuspy pośrednie liczone wektorowo: koło domu to przecięcie płaszczyzny
(wyznaczonej iloczynem wektorowym normalnych) z ekliptyką. Dwa punkty przecięcia
wymagają wyboru gałęzi — rozstrzygany stroną względem MC, przy czym cztery osie
bierzemy z dokładnych wzorów, bo przy przesunięciu równym 0° albo 180° test
strony jest numerycznie niestabilny.
Dwie rzeczy, które wyszły dopiero z porównania z wyrocznią:
- swisseph zamienia MC z IC dla systemów opartych na horyzoncie, gdy punkt
kulminujący jest pod horyzontem (za kołem podbiegunowym) — stąd _culminating_mc,
- morinus wymaga bezpośredniej zamiany współrzędnych, nie rzutu po kole godzinnym.
Topocentric (Polich–Page) zaimplementowany, ale świadomie POZA houses.SYSTEMS:
rozjeżdża się z wyrocznią przy |φ| ≈ 89,9° i RAMC 90°/270°, gdzie kolejność domów
się odwraca. Powód jest rzeczywisty, nie numeryczny — jego „biegun"
atan(tan(89,9°)/3) to już 89,7°. Zawężenie dziedziny tylko po to, żeby test
przeszedł, byłoby dopasowaniem kryterium do wyniku.
Testy regresji w suicie logiki działają bez swissepha: antypodyczność domów
przeciwległych, zakotwiczenie kwadrantowych na Ascendencie, niezależność morinusa
od szerokości, odrzucanie nieznanej nazwy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
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>
Wymaganie mówiło o restarcie „WSZYSTKICH TRZECH usług" przy zmianie INTERNAL_TOKEN.
Sprawdzenie żywych deploymentów pokazuje, że token czytają CZTERY: data, logic,
presentation ORAZ render (doszedł przy PRE-24, a wymaganie tego nie nadgoniło).
Kto zrobiłby rotację literalnie, zostawiłby render ze starym tokenem i usługa po
cichu przestałaby się dogadywać — dokładnie ta awaria, przed którą wymaganie
ostrzega. Treść w arkuszu poprawiona.
docs/log33-sekrety-i-rotacja.md:
- MACIERZ zależności wyliczona z deploymentów, nie z założeń. Wniosek praktyczny:
klucze łącz rotuje się PARAMI usług (logic+data, presentation+logic,
presentation+render), a nie całą czwórką — restartu wszystkiego wymaga tylko
INTERNAL_TOKEN.
- Procedury per sekret, od najbezpieczniejszej do przećwiczenia (klucze LLM —
dotykają tylko logiki, awaria widoczna i nieszkodliwa) po INTERNAL_TOKEN.
Wszystkie zachowują pozostałe klucze przez odczyt z istniejącego sekretu —
inaczej rotacja jednego skasowałaby resztę.
- Weryfikacja: sam „Running" NIE wystarcza (pody wstaną, nawet gdy warstwy się nie
dogadują) — trzeba przeliczyć horoskop i wygenerować PDF, żeby dotknąć wszystkich
łącz.
- Kroki hartowania z jasnym podziałem: co zrobione (automount tokenów — deploy #13),
co wymaga węzła (szyfrowanie at-rest), co świadomie odłożone (Sealed Secrets —
dziś sekrety NIE są w repo GitOps, więc ta zasada już jest spełniona; Sealed
Secrets dodałyby odtwarzalność kosztem nowego pojedynczego punktu awarii).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Runbook wykonany na NAS-ie, więc wymaganie rozdziela się na to, co faktycznie
osiągnięte, i to, co zostaje jako opcja na przyszłość — mieszanie obu w jednym
wierszu kazałoby wybierać między „zrobione" a „niezrobione" dla czegoś, co jest
i jednym, i drugim.
DAN-25a (Must, ZROBIONE): udział /mnt/Tank1/astrololo wyeksportowany wyłącznie dla
trzech węzłów k3s, tylko do odczytu, z root_squash. Zamknięta najkrótsza droga
wycieku — wcześniej każdy w LAN mógł zamontować udział i wziąć kompletne bazy
z pominięciem logowania, limitów, audytu i canary. Zawężony TYLKO ten udział, bo
Tank1 obsługuje cały homelab. Procedura: docs/dan25-zabezpieczenie-nfs.md.
DAN-25b (Could, do zrobienia): NFSv4 + Kerberos albo wolumen nieosiągalny poza
klastrem. Uzasadnienie w wierszu: lista adresów IP zatrzymuje dostęp przypadkowy
i oportunistyczny, ale NIE jest uwierzytelnianiem — adres da się podszyć w tej
samej sieci, a przejęcie dowolnego węzła daje udział. Koszt (KDC + keytaby)
uzasadniony dopiero, gdy sieć przestanie być zaufana.
Bilans: 63 Zrobione · 9 W trakcie · 14 Do zrobienia.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bazy leżą na udziale osiągalnym z całej sieci — to najkrótsza droga do wycieku,
z pominięciem logowania, limitów, audytu i canary. Runbook zawęża udział
`astrololo` do trzech węzłów k3s, ustawia tylko odczyt i root_squash.
Krok po kroku, komenda po komendzie: rozpoznanie → dowód dziury (montowanie
z maszyny spoza klastra) → kopia konfiguracji → zmiana → cztery testy weryfikacyjne
→ ścieżka wycofania.
Dwie zasady wynikające z tego, że Tank1 obsługuje CAŁY homelab (Proxmox, conjurer
z zapisem, media, LXC-e, stacja robocza):
- ruszamy WYŁĄCZNIE udział astrololo, nigdy globalnych ustawień usługi NFS —
inaczej padną VM-y, bot i biblioteka mediów;
- w TrueNAS SCALE nie edytuje się /etc/exports ręcznie (middleware nadpisze) —
wszystko przez midclt albo GUI.
Runbook każe też sprawdzić nazwy pól w API PRZED zapisem, bo middleware zmieniało
je między wersjami SCALE (path vs paths).
Opisane pułapki: hookscript Proxmoxa czekający na showmount przed startem VM;
utrata możliwości wgrywania baz przez NFS po ro=true; lista IP to nie
uwierzytelnianie (docelowo NFSv4+Kerberos, jak mówi samo wymaganie).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Aktualizacja kolumny Status wobec stanu faktycznego. Bilans: 62 Zrobione ·
9 W trakcie · 14 Do zrobienia (było 52 · 9 · 24).
Zrobione (zmergowane i działające):
- PRE-03 strefa czasowa z lokalizacji (#43)
- DAN-23 + PRE-10 eksport wyników do Excela (#45)
- PRE-26 cache-busting statyki (#48)
- PRE-06 konfigurowalne aspekty i orby (#49)
- PRE-04 techniki relacyjne — synastria (#51) + Returns w kalendarzu (LOG-12)
- PRE-17 konta imienne i dziennik audytowy (#54)
- PRE-09 + DAN-15 przegląd baz na NFS i ich włączanie/wyłączanie (#55)
- PRE-24 raport PDF — obraz render wreszcie się zbudował, PDF powstaje w produkcji
Świadomie NIE oznaczone jako zrobione:
- LOG-05 / PRE-05 zostają „W trakcie": liczenie kilku systemów domów naraz działa,
ale egzotyczne (Placidus/Koch/Regiomontanus/Campanus) wymagają silnika swisseph;
- DAN-26 z „Do zrobienia" na „W trakcie": mechanizm rekordów-pułapek jest gotowy
i przetestowany, ale wstrzyknięcie pułapek do realnych baz i rejestr wariantów
to krok właściciela, nie kodu.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
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>
Zabezpieczenie DETEKCYJNE (nie prewencyjne): kilka unikalnych, wiarygodnie
wyglądających rekordów-pułapek w bazach. Nie zmieniają interpretacji (odsiewamy
je z wyników), ale jeśli pojawią się w cudzej kopii — są dowodem pochodzenia, a
przy wariancie na kopię — wskazują ŹRÓDŁO wycieku.
`canary.py`: pułapkę rozpoznajemy po MARKERZE (unikalny ciąg z ENV, nieobecny w
realnych danych). `screen(rows, query_value)`:
- ODSIEWA rekordy z markerem z wyników — i to na WYJŚCIU z warstwy danych
(`/search`), więc nie dotrą wyżej ani do promptu LLM (LOG-30), niezależnie od
dostawcy (Excel/SQL);
- TRIPWIRE: gdy zapytanie celuje wprost w marker (enumeracja bazy, nie liczenie
horoskopu) → log warning.
Bez `CANARY_MARKERS` — przezroczyste, zero kosztu dla normalnego ruchu.
Rejestr wariant→kopia (traitor tracing) i wstrzyknięcie do REALNYCH baz to krok
właściciela (poza kodem — nie ruszamy kupionych plików automatycznie);
instrukcja: docs/canary-registry.md. Mechanizm zbudowany i przetestowany na
syntetycznych pułapkach.
Testy: +7 (przezroczystość bez markerów, odsiewanie, tripwire, marker w dowolnym
polu, endpoint odsiewa przed zwrotem). Pierwsze testy w usłudze `data`.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
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>
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>
Redefinicja uzgodniona z użytkownikiem (2026-07-28), ale do tej pory żyła tylko
w notatkach — w arkuszu wciąż było desktopowe „wskazanie folderu baz + pamięć 3
ścieżek", bezcelowe w modelu serwerowym (bazy na stałym udziale NFS, nie w folderze
wybieranym przez użytkownika).
Nowe brzmienie obu wymagań:
- DAN-15 (dane): warstwa danych wystawia listę baz dostępnych na NFS (nazwa +
metaopis: rozmiar / liczba rekordów / data) i honoruje globalne włącz/wyłącz
każdej bazy przy wyszukiwaniu interpretacji.
- PRE-09 (prezentacja): ekran ustawień pokazuje te bazy i pozwala globalnie
włączać/wyłączać każdą; wyłączona nie jest brana pod uwagę przy interpretacji.
Priorytet/status bez zmian (PRE-09 Must, DAN-15 Should, oba Do zrobienia). Zmiana
tylko tekstu wymagań — plik poza dwoma wierszami nietknięty, bilans statusów ten sam.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
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>
„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>
Audyt kolumny Status wobec kodu. Jedyna realna rozbieżność od ostatniego przeglądu
(PR #24): PRE-18 „Grafika aspektów (aspectarian) i wizualizacje pochodne" wisiało
na „Do zrobienia", a jest dowiezione i zmergowane:
- aspektarian (trójkątna siatka aspektów) — PR #38,
- wizualizacje pochodne: wykres deklinacji z paralelami + oś antyscji — PR #40,
- wpięte też w raport „Skompiluj" i PDF — PR #41.
Bilans: Zrobione 52 · W trakcie 9 · Do zrobienia 24.
Reszta pozostaje bez zmian — zweryfikowane, że statusy są aktualne (m.in.
LOG-05/PRE-05 wiele domów naraz, LOG-17 asp+/-, DAN-08 jako zasób danych wciąż
częściowe). PRE-24 (PDF) celowo zostaje „W trakcie": kod kompletny i przetestowany,
ale usługa render nie składa jeszcze PDF-ów w produkcji (blokada = dysk runnera).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
Dwie realne dziury w markdown→LaTeX, obie WIDOCZNE w gotowym PDF:
1. `***mocne***` (pogrubienie+kursywa) łapało się jako `**` + zgubiona gwiazdka →
`\textbf{*mocne}*`, czyli w druku zostawał wisior `*`. Dokładam alternatywę
`\*\*\*…\*\*\*` PRZED `**` i `*` (kolejność od najdłuższego znacznika) →
`\textbf{\textit{…}}`.
2. Nagłówek bez spacji po kratkach (`##Tytuł`), zamknięty ATX (`## Tytuł ##`)
i 7+ kratek trafiały do akapitu i były eskejpowane jako `\#\#…`. Pułapka: w
LaTeXu `\#` renderuje się jako `#`, więc w PDF WIDAĆ było `##`, choć w źródle
`.tex` jest `\#\#`. Dlatego stary test (`"##" not in out`) tego nie łapał —
podłańcuch `##` nie występuje w `\#\#`. Nagłówki traktujemy teraz pobłażliwie:
dowolna liczba kratek na starcie, spacja nieobowiązkowa, końcowe kratki
ucinane, gołe kratki bez treści pomijane. Żaden znacznik nagłówka nie ostaje.
Nowa asercja w testach patrzy pod kątem RENDERU: brak `\#` i brak wiszącej
gwiazdki (poza gwiazdką poleceń `\section*` itd.). +7 testów regresji, render 34.
UWAGA DEPLOY: obraz render w rejestrze to wciąż 56131b20 (sprzed markdown, LOG-27),
bo build-render (TeX Live) padał na runnerze z „no space left on device". Ten PR
dotyka services/render/**, więc powinien wywołać build — ale najpierw trzeba
zwolnić miejsce na runnerze, inaczej i ten build padnie.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
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>
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>
Luka: usluga render (services/render) weszla w #32, ale zaden workflow nie budowal
jej obrazu — wiec astrololo-render:latest nie istnial w rejestrze, a pod zawislby
na ImagePullBackOff po wdrozeniu manifestow.
Osobny pipeline (jak build-swisseph), nie dopisanie do build.yaml: obraz dzwiga
TeX Live (setki MB), a build.yaml chodzi przy KAZDYM pushu do mastera. Budowanie
renderu za kazdym razem spowalnialoby kazdy deploy — a to wlasnie ta izolacja
miala usunac. Wyzwalany tylko zmiana w services/render/**; workflow_dispatch do
bootstrapu.
Merge tego PR zbuduje pierwszy obraz (push dotyka pliku workflow, wiec trigger sie
odpali) i wypchnie :latest — dopiero potem ma sens merge deploy#5.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
Piata wskazowka partnerow: Kalendarz ma pozwalac liczyc predykcje dla KILKU
okresow i je zachowywac, zeby wszystkie trafily potem do raportu („Skompiluj",
PRE-23/24).
Nowy predictions.js — magazyn w localStorage, tak jak wspolne dane formularza
(PRE-21): serwer zostaje bezstanowy, zadne dane urodzeniowe ani tresci z baz nie
laduja po stronie uslugi. Zakladka „Skompiluj" odczyta to samo miejsce przez
window.astrololoPredictions (jedno zrodlo prawdy).
Decyzje projektowe:
- KLUCZEM TOZSAMOSCI JEST OKRES. Ponowne policzenie tego samego zakresu podmienia
wpis zamiast dokladac duplikat — inaczej lista puchlaby przy kazdej probie
z innym modelem albo budzetem. Dzieki temu zapis jest idempotentny, wiec dziala
tez wariant bez strumienia (zapis przy wczytaniu strony z gotowym wynikiem)
i odswiezenie niczego nie mnozy.
- progress.js OGLASZA gotowy horoskop zdarzeniem `astrololo:horoscope` z profilem,
zamiast sam zapisywac. To okno postepu, a nie magazyn — zapisywanie zostaje
odpowiedzialnoscia predictions.js. Filtr po profilu pilnuje, zeby interpretacja
natalna nie trafila na liste predykcji okresowych.
- Przepelniony magazyn (horoskopy bywaja dlugie) jest ZGLASZANY uzytkownikowi,
a nie polykany — inaczej wynik znikalby po cichu.
UI: lista zapamietanych predykcji na Kalendarzu — okres, data zapisu, objetosc
i przycisk usuwania. Skrypt podpiety w timeline.html (nie w base.html), zeby nie
kolidowac z rownolegle otwartym #29.
PRE-26 — dopisane wymaganie o wersjonowaniu plikow statycznych. Przy PRE-25
przegladarka podala STARY styles.css i powiekszanie kosmogramu „nie dzialalo",
mimo ze klasa byla nakladana. Objaw jest zdradliwy: szablony sa nowe, wiec strona
wyglada na zaktualizowana, a funkcja po prostu milczy. Po wdrozeniu moze to
spotkac uzytkownikow.
Weryfikacja na zywej aplikacji: dwa okresy zapisane; powtorzenie tego samego
zakresu podmienilo wpis (dalej 2, tekst zaktualizowany); lista posortowana po
dacie; predykcje przetrwaly przejscie na inna zakladke i powrot; interpretacja
natalna NIE wpadla na liste; usuwanie zmniejszylo licznik 2 -> 1 i przerysowalo
liste. Testy: 14 nowych. Calosc: prezentacja 101 passed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Ósma wskazówka partnerów, jako małe QoL przed PRE-22. Koło rysujemy w kolumnie
tekstu, więc na mniejszym ekranie glify i stopnie robią się nieczytelne.
Kliknięcie rozciąga wykres na całe okno, ponowne wraca do strony. SVG skaluje
się bez utraty jakości, więc nie potrzeba drugiej wersji rysunku ani biblioteki.
Wyjście z powiększenia na trzy sposoby: klik w wykres, klik w tło, Esc.
Dostępne też z klawiatury (Enter/Spacja, focus-visible), bo inaczej obejrzenie
szczegółów wymagałoby myszy.
Dwie decyzje warte odnotowania:
1. WARSTWA. z-index 1100 CELOWO pomiędzy: ponad kontrolkami Leafleta (1000),
ale PONIŻEJ okna postępu (1200). Gdy trwa pisanie horoskopu, log operacji ma
zostać na wierzchu. Test pilnuje tej nierówności, bo to jedyna liczba tutaj,
którą łatwo zmienić bez zastanowienia i zepsuć coś niewidocznego na oko.
2. ROZMIAR. Koło jest kwadratowe, więc ograniczamy je KRÓTSZYM bokiem okna
(min(96vw, 92vh)) — inaczej na szerokim ekranie wystawałoby w pionie.
Skrypt podpięty globalnie w base.html i osłonięty sprawdzeniem, czy koło w ogóle
jest na stronie — zadziała też na przyszłej zakładce „Skompiluj" bez zmian.
Przy powiększeniu blokujemy przewijanie strony pod spodem.
Weryfikacja na żywej aplikacji, pomiarami w DOM: po kliknięciu .wheel-fig ma
position:fixed, display:flex, z-index:1100; SVG rośnie z 460×460 do 662×653
przy oknie 1280×720, visibility visible; body dostaje overflow:hidden. Ponowne
kliknięcie wraca do 460×460 i zdejmuje klasę. Zrzutu ekranu stanu powiększonego
NIE mam — panel przeglądarki zaciął się w trakcie (puste klatki, viewport
raportowany jako 0×0), więc opieram się na pomiarach i testach.
Testy: 10 nowych. Całość: prezentacja 87 passed, logika 265 / 1 skip.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Dwie pierwsze wskazowki od partnerow biznesowych; pozostale piec zapisane jako
wymagania (PRE-21..PRE-24) do zrobienia w kolejnych krokach.
PRE-19 — offset wzgledem GMT. Etykieta mowila „Strefa (offset h)”, czyli nie
bylo jasne, wzgledem czego liczymy przesuniecie. Teraz „Offset wzgledem GMT (h)”
z podpowiedzia. Krok juz byl 15-minutowy (0,25 h) — dolozony zakres −12…+14,
zeby nie dalo sie wpisac strefy, ktora nie istnieje. Zmiana w trzech zakladkach,
ktore maja to pole (Horoskop, Interpretacje, Kalendarz).
PRE-20 — po „Tu i teraz” wspolrzedne i pineska skakaly na biezace polozenie, ale
w polu tekstowym zostawala STARA, wczesniej wpisana nazwa. Formularz pokazywal
jedno miejsce, a liczyl dla innego — cicha pomylka, nic sie nie wywalalo.
Handler zdarzenia astrololo:coords odswieza teraz nazwe przez reverseName.
Przy okazji druga strona tego samego bledu: reverseName czysci pole ZANIM
wysle zapytanie. Gdyby /reverse nie odpowiedzialo (brak sieci), zostalaby stara
nazwa — lepiej puste pole i poprawne wspolrzedne niz nazwa, ktora klamie.
Wymagania: PRE-19/20 (zrobione), PRE-21 wspolne dane miedzy zakladkami wraz
z polem imie i nazwisko, PRE-22 wiele predykcji okresowych w pamieci sesji,
PRE-23 zakladka „Skompiluj”, PRE-24 raport PDF przez LaTeX. Dolozone pytanie
otwarte Q-14 o lancuch LaTeX→PDF (gdzie postawic TeX Live, silnik unicode owy
pod glify, konwersja SVG) — decyzja wplywa na deploy i rozmiar obrazow.
Testy: 12 nowych, strukturalnych na zrodle (JS-a nie uruchomimy, a obie regresje
sa ciche). Sprawdzone sabotazem — po cofnieciu kazdej poprawki czerwienieja.
Calosc: prezentacja 45 passed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
Kolumna Status stała na „Do przeglądu" dla wszystkiego (poza LOG-32), mimo że
kilkadziesiąt rzeczy działa w produkcji — arkusz przestał odzwierciedlać stan
projektu. Słownik statusów pochodził z fazy PRZED kodowaniem („Do przeglądu ·
Zaakceptowane · Odrzucone · W trakcie"); dodaję fazę realizacji: Zrobione ·
W trakcie · Do zrobienia.
Statusy ustawione na podstawie FAKTYCZNIE zmergeowanego kodu, nie na oko —
wątpliwe zweryfikowane w źródłach (np. LOG-13 „ascensional" okazało się tylko
„right ascension" w komentarzu; PRE-06 „Orb" to nagłówek kolumny, nie ustawienie).
Bilans: Zrobione 43 · W trakcie 8 · Do zrobienia 26.
- Logika: 26 / 4 / 3 (brakuje m.in. LOG-09 primary directions, LOG-13
ascensional, LOG-22 glify; LOG-11 ZR/Decennials i LOG-17 asp+/- w trakcie),
- Prezentacja: 7 / 2 / 9,
- Dane: 10 / 2 / 14 (dużo tabel źródłowych jeszcze niepodpiętych).
Kosmogram (PRE-12): program od początku miał rysować koło horoskopowe — umknęło.
Podnoszę z „Could/opcjonalnie" na „Should", rozpisuję zakres (SVG po stronie
serwera: znaki, domy, planety z glifami, osie, linie aspektów; docelowo znaczniki
deklinacji/antyscji z LOG-07; zależność od glifów LOG-22) i oznaczam „Do zrobienia"
jako fokus najbliższych iteracji.
Nowy PRE-18: grafika aspektów (aspectarian) i wizualizacje pochodne horoskopu —
naturalny towarzysz kosmogramu.
Przegląd: zaktualizowana legenda statusów, licznik Prezentacji 17→18, dodana
tabela postępu realizacji per warstwa.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Warstwy rozmawialy ze soba jawnym tekstem wewnatrz klastra. Token
miedzywarstwowy (LOG-32) mowil KTO pyta, ale nie ukrywal CZEGO dotyczy
odpowiedz — a plyna nia surowe wiersze oryginalnych baz interpretacyjnych,
czyli rdzen produktu. Kto podsluchal ruch wewnatrz sieci (drugi pod, mirror
portu na switchu, zrzut z wezla), mial je w calosci.
Nowy modul link_crypto (kopia w kazdej z trzech uslug — nie maja wspolnej
biblioteki; test pilnuje, ze kopie sa identyczne):
- AES-256-GCM na ciele kazdego zadania i odpowiedzi. GCM daje poufnosc I
uwierzytelnienie naraz, wiec nie ma wariantu „zaszyfrowane, ale podatne na
modyfikacje".
- DWA niezalezne klucze, po jednym na pare rozmowcow (prezentacja-logika,
logika-dane). Przejecie klucza prezentacji nie otwiera warstwy danych, gdzie
leza cale bazy. Z kazdego klucza lacza HKDF wyprowadza osobne podklucze na
kierunek, wiec zadanie i odpowiedz nigdy nie szyfruja sie tym samym kluczem.
- Do materialu uwierzytelnianego (AAD) wchodza kierunek, sciezka, znacznik
czasu i numer ramki — wiec ramki nie da sie przekleic na inny endpoint,
odtworzyc po czasie (okno MAX_SKEW) ani przestawic w strumieniu.
- Strona serwerowa to czyste ASGI: podmienia cialo zanim zobaczy je FastAPI
i przepuszcza odpowiedz strumieniowa kawalek po kawalku (okno postepu dziala
dalej). Fail-closed: przy ustawionym kluczu jawne zadanie dostaje odmowe.
Strumien postepu (okno pisania horoskopu) tez idzie przez szyfrowane lacze:
link_crypto.stream_lines() pieczetuje zadanie i odszyfrowuje odpowiedz ramka
po ramce (granice ramek != granice linii NDJSON), zachowujac dostarczanie na
zywo. Bez tego przy wlaczonym LINK_ENCRYPTION_REQUIRED serwer odrzucalby
strumien (400) i okno postepu przestaloby dzialac. Fail-closed obejmuje takze
strumien: klient bez klucza nie wysyla nic, zamiast puscic dane urodzenia
jawnym tekstem, zanim serwer zdazy odmowic.
Najgrozniejszy blad wyszedl z PODSLUCHU prawdziwego gniazda, nie z testow:
klient bez klucza wysylal pytanie jawnym tekstem, ZANIM serwer zdazyl odmowic.
Stad LINK_ENCRYPTION_REQUIRED: klient nie wysyla niczego, a usluga nie wstaje,
jesli klucza brak. Ta sama zasada co przy sekrecie logowania.
Klient prezentacji przepuszczony przez jeden punkt _post()/stream_lines: dopoki
kazda metoda skladala zadanie sama, dolozenie nowej znaczylo, ze latwo zapomniec
o tokenie albo kluczu (401 wyszedl juz raz dopiero na produkcji). Test
strukturalny: kazde wyjscie w dol musi miec i token, i klucz lacza (takze
strumien), a surowe httpx wolno tylko na sciezkach wyjetych spod szyfrowania.
Weryfikacja:
- testy link_crypto (round-trip, brak tresci baz w bajtach na sieci, odrzucenie
obcego klucza / przestawionego bitu / przekleconej sciezki / przestawionej
ramki / przeterminowanej koperty / urwanego strumienia; round-trip strumienia
i fail-closed klienta i serwera dla strumienia),
- e2e na prawdziwym uvicornie z proxy zrzucajacym gniazdo: tresci baz brak na
kablu w obie strony (grep=0), takze dla strumienia horoskopu; klucz jednej
pary nie otwiera drugiej,
- calosc: logika 234 passed / 1 skipped, prezentacja 25 passed.
docs/wdrozenie-pre16.md: instrukcja krok po kroku z uzasadnieniem kolejnosci.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Po wlaczeniu TLS aplikacja stanie za Ingressem, a wtedy `request.client.host`
to adres POD-a Traefika — jednakowy dla wszystkich. Limiter wrzucalby caly ruch
do jednego wiadra 120/min i pierwsza osoba, ktora go wyklika, odcielaby
pozostalych. Cicha regresja, ktora ujawnilaby sie dopiero na produkcji.
Nowe `client_ip()` czyta adres z naglowka, ale WYLACZNIE przy TRUST_PROXY —
bo inaczej wystarczyloby dopisywac wlasny X-Forwarded-For, zeby przy kazdym
zadaniu wygladac na kogos innego i ominac limit calkowicie. Z tego samego
powodu bierzemy OSTATNI wpis listy: to jedyny, ktory dopisal nasz proxy;
wczesniejsze mogl podstawic klient, wiec nie znacza nic.
Szesc testow, w tym dwa istotne:
- podszycie sie pod X-Forwarded-For NIE resetuje wiadra przy wylaczonym
TRUST_PROXY (inaczej baze dalo by sie pompowac bez ograniczen),
- za proxy dwa rozne adresy dostaja osobne wiadra i nie odcinaja sie nawzajem.
Oba sprawdzone celowym zepsuciem implementacji (zawsze ufaj naglowkowi +
bierz pierwszy wpis) — testy wtedy czerwienieja. 23 passed.
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>
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>
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>
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>
Objaw zgloszony przez uzytkownika: w Kalendarzu horoskop wyswietla sie
poprawnie, w Interpretacjach zapytanie wychodzi, wraca — i NIC sie nie
pokazuje. Bez zadnego komunikatu.
Przyczyna: model potrafi oddac pusta tresc (finish_reason=length,
completion_tokens=0), a generate() zwracalo wtedy pusty tekst BEZ bledu.
Widok sprawdza {% if prompt_result.horoscope %} -> falsz -> nie renderuje nic,
a llm_error nie jest ustawiony -> zero wyjasnienia. Cicha awaria.
Asymetria miedzy ekranami wynika z rozmiaru promptu: natalny (13 obiektow x
fasety x opisy z bazy) wypelnia okno kontekstu modelu lokalnego i na odpowiedz
nie zostaje miejsca; okresowy jest mniejszy i sie miesci.
- wspolny straznik _require_text() dla obu dostawcow: pusta lub bialoznakowa
odpowiedz podnosi LLMError,
- komunikat PROWADZI DO PRZYCZYNY: podaje finish_reason i zuzycie tokenow oraz
radzi zmniejszyc budzet promptu / zwiekszyc num_ctx / LLM_MAX_TOKENS,
- Anthropic sprowadzony do wspolnego ksztaltu diagnostyki (input/output_tokens).
Dzieki temu uzytkownik widzi powod ORAZ gotowy prompt do recznego uzycia.
Zweryfikowane na zywym stosie z atrapa modelu oddajaca pusta tresc: zamiast
pustej strony pojawia sie pelny komunikat z diagnostyka. Testy: 148 passed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
UI pozwala wybrac dostawce przy KAZDYM zadaniu, ale factory czytalo jedna
wspolna trojke LLM_MODEL / LLM_BASE_URL / LLM_API_KEY dla wszystkich. Na
klastrze LLM_BASE_URL trzeba ustawic na lokalny model (localhost:11434 w podzie
nie istnieje) — i wtedy:
- wybor „OpenAI" wysylal zadanie do Ollamy,
- LLM_MODEL=llama3.1:8b kazal Anthropic uzyc modelu llama,
- jeden LLM_API_KEY nie moze byc kluczem OpenAI i Anthropic naraz.
Czyli nie bylo miejsca, w ktore dalo sie sensownie wpisac klucze do chmury.
- konfiguracja per dostawca: <DOSTAWCA>_MODEL / _BASE_URL / _API_KEY
(LOCAL_*, OPENAI_*, ANTHROPIC_*),
- zgodnosc wstecz: wspolne LLM_* dziala nadal, ale stosuje sie WYLACZNIE do
dostawcy domyslnego (LLM_PROVIDER) — instalacja jednodostawcowa bez zmian,
- Anthropic dostal brakujaca walidacje klucza (mial ja tylko OpenAI),
- komunikat bledu wskazuje konkretna zmienna do ustawienia.
Testy regresyjne pilnuja, ze ustawienia jednego dostawcy NIE przeciekaja na
pozostalych. Calosc: 143 passed / 1 skipped.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Blad z mergu: _auth_headers() dodano na galezi hardeningu, ktora odbila sie
od mastera ZANIM powstaly metody prompt() i horoscope() (LOG-29/30, LOG-31).
Git zmergowal obie zmiany czysto — byly w roznych liniach — ale semantycznie
nowe metody wyszly bez tokenu i dostawaly 401 przy wlaczonej ochronie.
Skutek dla uzytkownika: przyciski „Generuj prompt (AI)" i „Napisz horoskop"
nie dzialaly po wdrozeniu INTERNAL_TOKEN, mimo ze reszta aplikacji dzialala.
- naprawione oba wywolania,
- nowy test strukturalny (AST): KAZDE wyjscie HTTP w dol musi niesc headers=.
Test jednej metody by tego nie zlapal — regula musi byc pilnowana calosciowo.
Straznik zweryfikowany sabotazem: po usunieciu naglowka test pada ze
wskazaniem konkretnej linii; po przywroceniu 15/15 przechodzi.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Obecny poziom ochrony wystarcza do developmentu, ale luki musza byc zapisane,
zeby nie wyparowaly przed produkcja.
- PRE-16 (Must) HTTPS/TLS — dzis Basic Auth leci po http, czyli haslo da sie
podsluchac. Odblokowuje przy okazji DWIE funkcje zepsute z tego samego
powodu: geolokalizacje (Tu i teraz) i kopiowanie do schowka — oba wymagaja
secure context.
- PRE-17 (Should) konta imienne + slad audytowy zamiast jednego wspolnego
hasla; bez tego nie wiadomo, kto pobieral dane, ani jak odciac jedna osobe.
- DAN-25 (Must) ograniczenie udzialu NFS — kto ma do niego dostep, bierze
komplet baz z pominieciem aplikacji. Dzis najkrotsza droga do wycieku.
- DAN-26 (Should) znakowanie baz rekordami-pulapkami — zabezpieczenie
detekcyjne: pozwala udowodnic zrodlo wycieku.
- LOG-33 (Should) sekrety w spoczynku (etcd to tylko base64) + rotacja.
Q-12 odnotowane jako rozstrzygniete: bazy zostaly KUPIONE, wiec zgoda jest —
ale to nie zwalnia z ochrony. LOG-32 przestawione na "W trakcie" z wykazem,
co juz wdrozone, a co zostaje.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
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>
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>
Nowy feature: generowanie promptow do ChatGPT/Claude z naszych wyliczen i
wolanie modelu — horoskop urodzeniowy (ekran Interpretacje) oraz horoskop
na wybrany okres (ekran Kalendarz).
Warstwa logiczna:
- LOG-29 generator promptow (profile natal + okresowy), prompt i wynik PL,
obowiazek odnoszenia kazdej tezy do konkretnego sygnifikatora
- LOG-30 ograniczanie rozmiaru: dedup -> grupowanie -> sortowanie wg wagi
(LOG-21) -> obciecie ogona -> skracanie; raportuje ile pominieto
- LOG-31 pluggable LLMProvider (OpenAI/Anthropic) + POST /chart/horoscope;
klucz tylko z sekretu, limity kosztu/tokenow, prompt zwracany zawsze
- LOG-32 (Must) poufnosc: prompt niesie WLASNOSC wspolpracownika i dane
urodzeniowe -> zgoda wlasciciela baz, API zamiast czatu konsumenckiego,
minimalizacja, podglad przed wyslaniem, tryb bez pelnych opisow
Warstwa prezentacji:
- PRE-14 przycisk generowania + budzet promptu + podglad promptu przed
wyslaniem + kopiowanie (prompt dziala takze bez wysylki do API)
- PRE-15 transparentnosc: dostawca/model, ile wskazan pominieto,
zastrzezenie ze to nie porada medyczna, ostrzezenie przed wysylka
Pytania otwarte: Q-12 (zgoda wlasciciela baz — blokuje tryb pelnych opisow),
Q-13 (dostawca/model i limit kosztow).
Zaktualizowane liczniki w arkuszu Przeglad i zakresy autofiltrow.
Decyzje wg ustalen w czacie: integracja API, pelne opisy z baz, PL, suwak.
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>
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>
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>
Buduje i pushuje obraz gitea/astrololo-engine-swisseph (tag SHA + latest).
Celowo oddzielony od build.yaml (data/logic/presentation) — odpala sie
tylko przy zmianach w services/engine-swisseph/**, wiec obraz AGPL nie
miesza sie do pipeline'u permisywnego produktu. workflow_dispatch pozwala
zbootstrapowac pierwszy obraz recznie.
Obraz konsumuje profil deployu astrololo-swisseph (repo deploy).
Uwaga: pierwszy build zadziala dopiero po zmergowaniu poprawki Dockerfile
(PR #3) — na masterze Dockerfile jeszcze sie nie buduje.
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>
pyswisseph to rozszerzenie C, a na PyPI (2.10.3.2) gotowe wheels koncza sie
na cp311 i obejmuja wylacznie i686/x86_64. Obraz stoi na python:3.12-slim,
wiec pip ZAWSZE kompilowal ze zrodel - a slim nie ma kompilatora. Stad fail.
- Dockerfile wieloetapowy: kompilacja w etapie builder (build-essential),
do runtime trafia juz tylko gotowy wheel - obraz zostaje czysty i maly.
Dziala tez na arm64, gdzie wheeli linuksowych nie ma dla zadnej wersji.
- sanity check (import swisseph) na etapie builda, zeby niedzialajacy silnik
wywracal build, a nie dopiero pierwszy request.
- CI: nowy job swisseph-image - realny docker build + smoke test /health
i /positions na horoskopie referencyjnym.
- README: udokumentowany powod wieloetapowego builda.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pierwszy run CI dał 59 passed / 20 skipped zamiast 78/1: auto-pobranie jądra
przez Skyfield nie powiodło się na runnerze, więc testy referencyjne (walidacja
względem astro.com) cicho znikały.
- workflow: jawne pobranie de421.bsp curlem z ssd.jpl.nasa.gov (naif zwraca 404),
z retry; EPHEMERIS_DIR wskazany explicite; pytest z -rs (widoczne powody skipów).
- conftest: gdy CI=true, niedostępny silnik kończy się pytest.fail zamiast skip —
żeby utrata pokrycia nigdy więcej nie przeszła niezauważona. Lokalnie (dev bez
pobranego jądra) nadal łagodny skip.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
.github/workflows/tests.yml:
- job "Testy warstwy logicznej": Python 3.12 (jak w obrazach Dockera),
instalacja requirements-dev, pytest na services/logic/tests. Cache pip oraz
cache jądra efemeryd JPL (de421.bsp ~17 MB), by nie pobierać go co run.
- job "Kontrola składni": compileall na wszystkich warstwach (bez instalowania
zależności, w tym AGPL-owego silnika swisseph).
- Triggery: każdy push (dowolna gałąź) + pull requesty do master.
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>
Przyczyna "nie pyta o zgodę": navigator.geolocation działa tylko w secure
context (https:// lub localhost). Na http://<ip> przeglądarka po cichu
odmawia — bez promptu; kod nie miał callbacku błędu, więc nic nie było widać.
- wspólny static/now.js (deduplikacja skryptu z chart.html i interpret.html)
- jawna detekcja window.isSecureContext + czytelny komunikat w #geoNote
("wymaga HTTPS lub localhost — wpisz lat/lon ręcznie")
- callback błędu (odmowa/timeout) też widoczny; status "Pobieram lokalizację…"
i potwierdzenie po sukcesie
Zweryfikowano: /static/now.js serwowany (200), obie strony referencjonują
skrypt i mają #geoNote.
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>
- abbreviations.py: słownik skrót -> pełna nazwa (z SIGNIFICATORS KEY, built-in)
+ expand(): [Su in [Tau -> "Sun in Taurus", [Sa in 6th H. -> "...6th house",
affl. -> afflicted itd.
- significators: każda próbka ma pole "expanded" (postać czytelna); hartowanie
filtra szumu (efekty zastępcze x/?/-, wiersze *MARKER, legendy/nagłówki).
- prezentacja /interpret: pokazuje rozwiniętą postać, surowy skrót w tooltipie.
Zweryfikowano na realnym main_base.xlsx: "[Sa or [Ma in the 5th H." ->
"Saturn or Mars in the 5th house". 9 testów przechodzi (w tym test_abbreviations).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Most horoskop -> sygnifikatory generuje teraz dla każdego obiektu dwie fasety:
- "w znaku": planeta + token znaku ([Su + [Tau)
- "w domu": planeta + token domu ([Su + 11th H.) — używa domów z LOG-05
- significators.build_report: przyjmuje pozycje z build_chart (z numerami domów),
generuje fasety znak/dom, filtruje szum. Ordinal helper (1st..12th).
- /chart/report: używa build_chart (pozycje z domami).
- Prezentacja /interpret: render faset (znak/dom) per obiekt.
Aspekty ([conj/[sq/[opp) na później — wymagają policzenia aspektów (LOG-06).
Zweryfikowano na realnym main_base.xlsx (53969 wierszy), 30.04.1984:
Mars w 5. domu 10 dopasowań ("[Sa or [Ma in the 5th H." -> "abortion/miscarriage"),
Neptune w 7. domu 6, Uranus w 6. domu 4. 7 testów przechodzi.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
Trzy usterki uniemożliwiające uruchomienie stosu lokalnie:
1. Warstwa danych wykładała się na starcie przy zapisie Parquet dla realnych
plików (np. Encyclopaedia of Medical Astrology) — kolumny o mieszanych
typach (int+str+NaN). frame_cache.put() zapisuje teraz ramkę jako string
(warstwa i tak wyszukuje po tekście). Dodatkowo warmup() jest odporny:
pojedynczy uszkodzony plik nie blokuje startu usługi.
2. Brakowało kroku instalacji zależności — dev-logic/dev-presentation padały na
'No module named httpx'. Nowy cel `make install` instaluje zależności
WSZYSTKICH warstw do aktywnego venv. README zaktualizowane (instalowało
wcześniej tylko warstwę danych).
3. `make up` zakładał `docker compose`, którego użytkownik nie ma. Makefile
wykrywa `docker compose` lub `docker-compose`, a przy braku obu podaje
czytelną instrukcję trybu lokalnego. Dodano `make test` i `make clean-cache`.
Zweryfikowane end-to-end na realnym środowisku (.env, Python 3.14) i danych:
warmup przechodzi (3 pliki), cały stos wstaje, formularz → logika → silnik
Skyfield zwraca poprawne pozycje.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
Dodaje per-requirement, kompletnie nietechniczne tłumaczenie do trzech
arkuszy warstw (dane 24, logika 28, prezentacja 13) jako ostatnią kolumnę.
Dla osób nietechnicznych — m.in. współpracownika dostarczającego bazy —
żeby każdy wiersz był zrozumiały bez żargonu. Autofiltr rozszerzony.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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
309 changed files with 32151 additions and 1 deletions
-`astro parser TO DO LIST 2026-09-05.xlsx` — dalej **TO DO**,
-`astro parser_2026-09-13.docx` — dalej **specyfikacja**.
Architektura (trzy warstwy) zostaje bez zmian. Uwagi klienta o architekturze i stosie technologicznym są tu celowo pominięte.
Legenda pewności: **[kod]** sprawdzone w kodzie · **[rejestr]** status z `astrololo_wymagania.xlsx`, niezweryfikowany w kodzie · **[hipoteza]** wniosek z objawów, niesprawdzony.
## TL;DR
1.**Interpretacje pokazują sygnifikatory, których w horoskopie nie ma.** Klient ma rację, mechanizm potwierdzony w kodzie. To nie nowe wymaganie, tylko błąd w działającej funkcji — i ten sam błąd zasila prompt do LLM.
2.**Specyfikacja (docx) to w ~90% wynik AI, którego klient jeszcze nie przejrzał.** W części 2 z 21 stoi znacznik „{DOTĄD SPRAWDZONE}". Nie traktować jej jako wymagań — to skorowidz do sprawdzania algorytmów.
3.**Prawdziwą listą priorytetów jest TO DO (xlsx).** Astrologia wedyjska, chińska i majańska występuje wyłącznie w specyfikacji; w TO DO jej nie ma.
4.**Trzy zmiany przekrojowe:** interfejs po angielsku, wyłącznie jasny motyw z kolorowaniem, tabele w formie „symbol + skrót".
5.**Część pozycji z TO DO już istnieje** (paralele, draconic, stacje, profekcje, zbiorcza tabela predykcji) — klient może o tym nie wiedzieć albo chce innego formatu.
## 1. Interpretacje działają źle (potwierdzone w kodzie)
**Zgłoszenie (TO DO, wiersz 11, \*\*\*).** Pod nagłówkiem „Sun w Taurus" pojawia się rekord „Sun in Gemini or Sagittarius, in square or opposition the Moon", choć żaden z warunków nie zachodzi. Fasetka „koniunkcja z Moon — 84 dopasowań" zbiera każdą koniunkcję czegokolwiek z Księżycem. Pokazują się też rekordy o dyrekcjach („by dir."), których nie liczymy, oraz o godnościach („well-dig. at B."), które w tym horoskopie nie są spełnione.
**Mechanizm [kod].**`_facet_samples` w [significators.py](../services/logic/app/significators.py#L70) przepuszcza rekord, jeśli tekst jego sygnifikatora *zawiera* wszystkie tokeny fasetki ([linia 82](../services/logic/app/significators.py#L82): `if not all(t in low for t in toks)`). Sprawdza więc, czy rekord *wspomina* te tokeny, a nie czy *wszystkie warunki rekordu* są spełnione w horoskopie. Skutki:
- Nie rozróżnia, **która** planeta jest w aspekcie. Rekord `[Ve [conj [Mo … [Su in 7th H.` trafia do fasetki „Słońce w koniunkcji z Księżycem", bo zawiera `[Su`, `[conj` i `[Mo`.
- Ignoruje **dodatkowe warunki** rekordu: inny znak („Gem or Sag"), inny aspekt („sq or opp"), kwalifikatory techniki („by dir.", „tr."), godności („at B.").
- „[Su: 5415 rekordów" w nagłówku to `planet_total` — liczba wszystkich rekordów wspominających Słońce, bez żadnego dopasowania.
Ta sama funkcja obsługuje ścieżkę kalendarza ([`interpret_events`](../services/logic/app/significators.py#L265)), więc wada dotyczy obu ekranów.
**Dlaczego to pilne.** Generator promptów (LOG-29/30) bierze dopasowania z tego samego `build_report` ([main.py](../services/logic/app/main.py#L338), [prompt.py](../services/logic/app/prompt.py#L66)), a prompt każe modelowi popierać każdą tezę konkretnym sygnifikatorem. Model z przekonaniem cytuje więc świadectwa, których w horoskopie nie ma.
**Rozbieżność z rejestrem.** LOG-15, LOG-16 i LOG-19 mają status „Zrobione", a docstring modułu sam nazywa ten kod „Zalążkiem LOG-15/16". Statusy do korekty.
**Co trzeba zrobić.** Prawdziwy ewaluator zamiast dopasowania tokenów: rozbiór sygnifikatora na drzewo warunków (koniunkcja klauzul, alternatywy „or", kwalifikatory techniki i godności) i sprawdzenie każdej klauzuli względem atomów policzonych dla horoskopu. Rekord z warunkiem, którego nie umiemy sprawdzić (dyrekcje, godności), ma zostać odrzucony albo oznaczony „nie do oceny" — nigdy pokazany jako trafienie. Przypadek testowy wprost od klienta: rekord z „by dir." nie może się pojawić w interpretacji natalnej.
## 2. Czym są te dwa dokumenty
**TO DO (xlsx)** to właściwa lista robocza: arkusz „LISTA TO DO" z priorytetami (\*\*\* / \*\* / \* / brak = na tym etapie niekonieczne) oraz 16 arkuszy-wzorców z przykładowymi tabelami (tabela stopni, synastria, lista aspektów, profekcje, tranzyty, asteroidy, dane obiektów, godziny planetarne, syzygia, żywioły, orby, obiekty). Ostatnia poprawka: 05.09.2026.
**Specyfikacja (docx)** to „Kompletna specyfikacja techniczna" w 21 częściach. Według klienta to efekt ponad 20 godzin pracy z agentem AI, wciąż niedokończony; ma być czytana razem z TO DO. Ustalenia z formatowania dokumentu [kod — odczyt XML]:
- **Legenda kolorów** (cieniowanie akapitów): pomarańczowy = „to jeszcze uzupełnię", żółty = „kompletnie do poprawki", łososiowy = „chyba out".
- Flagi występują **tylko w częściach 1–2**. W części 2, zaraz po „Accidental dignities", stoi znacznik **„{DOTĄD SPRAWDZONE}"**. Wszystko dalej — części 3–21: aspekty, Lots, midpointy, astrologia wedyjska, gwiazdy stałe, wszystkie techniki predykcyjne, dashy, numerologia, chiromancja — to **nieprzejrzany wynik AI**.
- Kolor „chyba out" nie występuje ani razu: nic nie jest jeszcze wykreślone.
- „Do poprawki" dotyczy formatu tabeli orbów (1.2). To zgodne z niespójnością tej tabeli: Słońce i Księżyc mają w niej 8°, a obok stoi „+2° bonusu dla świateł" — nie wiadomo, czy bonus jest już wliczony.
- Czerwona czcionka w częściach 1–2 to **specyfikacja kolorów UI** (osłabienia, domy kadentne i ujemne punkty na czerwono), a nie znacznik „bzdura".
- Dokument jest urwany: „TU WYWALIŁ BŁĄD, KONTYNUACJA" w części 11 i „TU SIĘ SKOŃCZYŁ LIMIT WĄTKU" w części 21.
**Specyfikacja zawiera błędy merytoryczne.** Lista aspektów pobocznych w części 1.2 podaje np. „0.5° Vigintile (1/40)" i „11.25° Undecile? (1/32)". W rzeczywistości vigintyl to 18° (1/20), a undecyl 32,73° (1/11) — arkusz „ASPECTS" w TO DO ma te wartości poprawnie. **Przy konflikcie źródłem prawdy jest xlsx; specyfikację traktujemy jako skorowidz do weryfikacji.**
## 3. Błędy w działającej aplikacji (to nie są nowe wymagania)
| 9 | \*\*\* | Pliki 5 MB i 7,75 MB kończą się „Gateway Timeout" | **[hipoteza]** Odpowiedź 504 zwraca proxy/ingress, nie aplikacja — w warstwach prezentacji i danych nie ma limitu rozmiaru. Do sprawdzenia w repo deploy (timeout ingressu, limit rozmiaru żądania). |
| 9 | \*\*\* | Komunikat „przyjęty, ale nie nadaje się do użycia" pojawia się dopiero przy ponownym wgraniu | Walidacja struktury powinna iść od razu po wgraniu, razem z opisem wymaganego układu kolumn (najlepiej jako stała podpowiedź w UI). |
| 10 | \*\*\* | Brak listy wgranych plików (usuń / sprawdź / aktywuj) | **[hipoteza]** DAN-27 i PRE-09 mają status „Zrobione". Klient najpewniej pracuje na wariancie albo koncie bez tej zakładki: astroklient jest z założenia „bez administracji" (commit 10970c5), a zakładki są bramkowane uprawnieniami (PRE-27). Ustalić, gdzie to widać. |
| 12 | \*\*\* | Ekran „Sygnifikatory" — nie wiadomo, do czego służy | UX: ekran wymaga wpisywania tokenów w składni bazy. Potrzebny opis i podpowiedzi albo przeprojektowanie. |
## 4. Zmiany przekrojowe
- **Interfejs po angielsku (TO DO 6, \*\*\*).** Cały obecny interfejs jest po polsku. Dotyczy wszystkich trzech wariantów (astrololo, astroklient, astrodemo) — najlepiej zrobić to jednym mechanizmem i18n przy okazji porządkowania wariantów, a nie trzy razy.
- **Jasny motyw i kolorowanie (TO DO 7, \*\*\*).** Bez trybu ciemnego. Kolory komórek dla grup aspektów, żywiołów znaków i planet; tło komórki to bardzo jasna wersja koloru.
- **„Symbol + skrót" w tabelach (TO DO 8, \*\*).** `☍ opp`, `☉ Su`, `♐ Sag` — nigdy pełne nazwy. Rozstrzyga pytanie Q-05 i jest zgodne z DAN-18 (Unicode jako tekst, nie emoji).
## 5. Mapowanie TO DO na rejestr wymagań
Statusy według rejestru **[rejestr]**, o ile nie zaznaczono inaczej.
### Istnieje w rejestrze — klient podnosi priorytet albo doprecyzowuje
| TO DO | Prio | Temat | ID | Status | Co się zmienia |
|---|---|---|---|---|---|
| 19–20 | \*\*\* | Baza HOROSCOPES: zapis, ulubione, ostatnie, kopiuj/wklej | DAN-04 | Do zrobienia | Realnie pierwsza kolejka. Kopiowanie i wklejanie w formacie czytelnym bez kodu (TSV albo „;"). |
| 23 | \*\* | Baza SUBHOROSCOPES (relacje: mąż, dziecko, ślub…) | DAN-05 | Do zrobienia | Klient podaje schemat: ID = ImięNazwiskoData (+ litera przy powtórce), pola TYPE i SUBJECT. |
| 24 | \*\*\* | Orby per obiekt × per aspekt | DAN-06, PRE-06 | Do zrobienia / Zrobione | Dziś jedna orba + bonus świateł. Potrzebna macierz; arkusz ORBS dokłada „metody" według autorów i szkół. |
| 25–26 | \*\*\* / \*\* | Obiekty do wyświetlania: trzy przełączniki na obiekt, bez odświeżania strony | PRE-08 | Do zrobienia | Pokaż na kole / rysuj aspekty / pokaż w aspektarianie. |
| 27, 56–65 | \*\*\* | Ascensional times + minor planetary years + kombinacje | LOG-13, DAN-07 | Do zrobienia | Z „Could" na \*\*\*. Pełny algorytm: reguła Valensa, „model A" Patricka Watsona, ułamki 1/3, 1/2 i 2/3, pomijanie znaków powyżej 66° i 78° szerokości. |
| 28–31 | \*\*\* | Synastria — przebudowa | PRE-04 | Zrobione | **[kod]** Dziś bez wyboru lokalizacji (strefa i współrzędne wpisywane ręcznie), jedna orba, aspekty poboczne włączane hurtem. Potrzebne: pełne dane obu osób, orby per aspekt, wynik „obiekt A — aspekt — obiekt B", bi-wheel (A w środku, B na zewnątrz) przełączany z widokiem obok siebie, pełny kwadrat aspektów zamiast trójkąta. |
| 35–36 | \*\*\* / \* | Wybór aspektów z grupami + okno aspektów pobocznych | PRE-06 | Zrobione | Przyciski major / hard / soft / minor medical; okno aspektów pobocznych z sortowaniem według stopni i harmonik. |
| 41 | \*\*\* | Stacje: poprzednia i następna — dni, data, stopień, link | LOG-03 | Zrobione | Dodatkowe pola, flaga „< 7 dni", hiperłącze do horoskopu na moment stacji. |
| 44 | \*\*\* | Lots z `lots astroseek.xlsx` | LOG-08, DAN-08 | Zrobione / W trakcie | Odwracanie formuły w nocy + warunki specjalne (klient uzupełni). |
| 52–54 | \*\*\* | Zunifikowana tabela predykcji, kopiowana do Excela jako jedna tabela | LOG-14 | Zrobione | Format kolumn według arkusza „transits, predictive"; typy event / period / mundane. |
| 85 | \*\*\* | Firdaria | LOG-11 | W trakcie | Klient odsyła do `fidaria calculator.xls`, którego nie ma w przekazanych plikach. |
| 87, 89, 91–93 | \*\*\* | Zodiacal Releasing, Annual Divisions, Days of the Moon, Solar Monthly Revolutions, Lord of the Orb | LOG-11, LOG-12 | W trakcie / Zrobione | Lord of the Orb w dwóch wariantach (mod 84 i mod 12). |
| 96 | \*\* | Primary Directions | LOG-09 | Do zrobienia | Pytanie Q-02 nadal otwarte. |
- nazwa strefy czasowej i informacja o DST, np. CEST (TO DO 14, \*\*\*); UT/GMT oraz lokalny czas gwiazdowy (15–16, \*);
- wklejanie danych w formacie Zet Astroprocessor (21, \*\*\*);
- kilka zapisanych lokalizacji domyślnych z edycją listy (22, \*\*\*).
**Koło horoskopu (rozszerzenia PRE-12):**
- zakotwiczenie: Asc / whole sign / Baran / Rak / Słońce / Księżyc (32);
- granice terminów i dekanatów w kolorach, symbol planety po najechaniu kursorem (33);
- style linii aspektów: pogrubiona = applying ≤ 3°, bardzo gruba = applying ≤ 1°, przerywana = separating; kolory i grubości konfigurowalne (49, \*\*\*).
**Tabele:**
- tabela stopni 30 × 12 z podglądem „zoom" wybranego stopnia (50, \*\*\*);
- tabela aspektów przez cały znak, out-of-sign, dokładność (34, \*\*\*);
- midpointy (38, \*);
- długość ekliptyczna w kilku formatach (46, \*).
**Techniki predykcyjne (\*):** progresje sekundarne, ingresy, okresy cienia retrogradacji, ekstrema szerokości ekliptycznej, OOB, fazy Księżyca i zaćmienia (73–83); profekcje ciągłe z wyborem klucza (94, \*\*).
**Poza astrologią zachodnią** (bez gwiazdek albo z jedną): numerologia (100, \*\*) z gotowym schematem tabeli wynikowej, chiromancja (101, \*), czytanie twarzy i sylwetki (102, \*), atlas medyczny i atlas historycznych krain (103–104), Astro\*Carto\*Graphy (98).
**Tylko w specyfikacji, nie ma w TO DO:** cała astrologia wedyjska (wargi D-N, 13 systemów dash, karaki, argala, shadbala, ashtakavarga, yogi), chińska (BaZi, Zi Wei, Xiu), majańska (Tzolkin) i setki nazwanych asteroid. **Do potwierdzenia z klientem, czy to w ogóle zakres.** Uwaga techniczna: numerowane asteroidy wymagają plików efemeryd Swiss Ephemeris, czyli silnika `engine-swisseph` (izolacja AGPL według LOG-27) — nasz silnik Skyfield ich nie policzy.
## 6. Brakujące materiały
Klient się na nie powołuje, ale nie ma ich w przekazanych plikach:
-`wznoszenie znaków ascensional times.xlsx` (TO DO 56) i plik „wrzucony na dysk" (27);
-`fidaria calculator.xls` (85);
- dokończenie specyfikacji od części 21 (urwana) oraz przegląd części 3–21.
## 7. Pytania do klienta
1. Czy część wedyjska, chińska i majańska ze specyfikacji to zakres, czy tylko efekt uboczny pracy z AI? W TO DO jej nie ma.
2. Interfejs po angielsku: we wszystkich trzech wariantach czy tylko w wersji dla klienta? Czy dotyczy to też raportów — prompt do LLM jest dziś po polsku (LOG-29)?
3. Na którym wariancie i koncie widać brak listy plików (TO DO 10)?
4. Tabela orbów: czy bonus +2° dla świateł dolicza się do wartości z tabeli, czy jest już w nich zawarty?
5. Kiedy będą przejrzane części 3–21 specyfikacji — i czy do tego czasu traktujemy je jako nieobowiązujące?
## 8. Proponowana kolejność
1.**Naprawa dopasowania sygnifikatorów** (sekcja 1). Psuje Interpretacje, Kalendarz i prompt do LLM; dopóki działa źle, każda funkcja budowana na nim dziedziczy błąd.
2.**Błędy wgrywania plików** (TO DO 9–10) — klient nie może wgrać własnych baz.
4.**Synastria** (28–31) i **orby per obiekt × aspekt** (24) — orby są wspólne dla obu.
5.**Zmiany przekrojowe UI** (angielski, jasny motyw, „symbol + skrót") razem z porządkowaniem wariantów astrololo / astroklient / astrodemo, żeby nie robić tego trzy razy.
6. Dalej techniki z \*\*\* według TO DO; specyfikację dopiero po jej przejrzeniu przez klienta.
Rejestr `astrololo_wymagania.xlsx` celowo **nie** jest zmieniany w tym PR. Najpierw akceptacja tej analizy, potem naniesienie zmian — zgodnie z zasadą „przegląd → poprawki → akceptacja → kod".
kubectl -n astrololo exec deploy/data -- ls /app/data_files | head -3
```
**4. Reszta homelabu nietknięta** — conjurer (zapis!) i pozostałe udziały:
```bash
kubectl -n conjurer get pods
```
```bash
midclt call sharing.nfs.query | python3 -c "import sys,json;[print(s.get('path') or s.get('paths'), '| hosts:', s.get('hosts'), '| ro:', s.get('ro')) for s in json.load(sys.stdin)]"
```
Oczekiwane: **tylko** astrololo ma zawężone `hosts` i `ro: true`; reszta bez zmian.
Powinno być `łącze szyfrowane (AES-256-GCM…)`. Jeśli widzisz ostrzeżenie
o rozmowie **jawnym tekstem** — klucz nie doszedł do poda.
---
## Dlaczego taka kolejność
| Kolejność | Skutek zamiany |
|---|---|
| Sekret **przed** manifestami | `LINK_ENCRYPTION_REQUIRED=true` bez klucza celowo wywraca start. Pody wpadną w CrashLoop i będą tak siedzieć do czasu utworzenia sekretu. |
| cert-manager **przed** manifestami | API odrzuci `Certificate`/`Issuer` jako nieznane rodzaje zasobów, ArgoCD pokaże aplikację jako niezsynchronizowaną i sam tego nie naprawi. |
| DNS **przed** manifestami | NodePort znika razem z nimi. Bez wpisu DNS zostaje tylko `port-forward`. |
| Aplikacja **przed** manifestami | Odwrotnie: manifesty włączyłyby szyfrowanie na obrazach, które go nie znają — wszystkie żądania kończyłyby się odmową do czasu przebudowy obrazów. |
Fail-closed w obie strony jest zamierzony. Usługa, która wstała i **po cichu nie
szyfruje**, jest gorsza niż pod w CrashLoop — awarii nie widać, a bazy jadą
otwartym tekstem.
---
## Wycofanie
Manifestów: `git revert` merge'a w `deploy` — ArgoCD samo wróci do NodePortu
i ruchu bez szyfrowania. Kod aplikacji **nie wymaga wycofania**: bez zmiennych
`LINK_KEY_*` moduł przepuszcza ruch jak dotąd (i głośno o tym mówi w logach).
Certyfikat i CA zostają w namespace; usunięcie: `kubectl -n astrololo delete
certificate astrololo-ca astrololo-tls`. cert-managera można zostawić — nie
przeszkadza.
---
## Gdy coś nie gra
| Objaw | Przyczyna | Co zrobić |
|---|---|---|
| Pody w `CrashLoopBackOff`, w logach `LINK_ENCRYPTION_REQUIRED … nie ustawiony` | brak sekretu `astrololo-link` | krok 1, potem `rollout restart` |
| `400 Łącze międzywarstwowe wymaga szyfrowania` przy normalnym korzystaniu | jedna warstwa ma klucz, druga nie (albo trwa rollout) | `rollout status`; sprawdź, czy wszystkie trzy pody mają zmienną |
| `400 Nie udało się odczytać zaszyfrowanego żądania` | klucze po obu stronach łącza są **różne** | wymień sekret i zrestartuj **wszystkie trzy** naraz |
| `Certificate` stoi w `READY=False` | webhook cert-managera jeszcze nie wstał | `kubectl -n cert-manager get pods`, poczekaj i sprawdź `kubectl -n astrololo describe certificate astrololo-tls` |
| Przeglądarka: „połączenie nie jest prywatne” | korzeń CA nieimportowany na tym urządzeniu | krok 6 (pamiętaj, że Firefox ma osobny magazyn) |
| `404` z Traefika pod adresem aplikacji | DNS wskazuje gdzie indziej niż LoadBalancer Traefika | porównaj `dig +short astrololo.czernobog.pl` z adresem z kroku „stan wyjściowy” |
| Limit żądań odcina wszystkich naraz | brak `TRUST_PROXY=true` — cały ruch liczony jako jeden klient | sprawdź zmienną w `deploy/presentation` |
---
## Czego to nie załatwia
- **Szyfrowane są ciała żądań, nie nagłówki.** Ścieżka (`/search`) i token
międzywarstwowy jadą czytelnie. Sam token nikomu nic nie daje — bez klucza łącza
każde żądanie kończy się odmową — ale metadanych to nie ukrywa. Pełne ukrycie
wymagałoby mTLS.
- **Własne CA to nie publiczne zaufanie.** Każde nowe urządzenie wymaga importu
korzenia. Gdyby aplikacja miała kiedyś wyjść na świat, właściwą drogą jest
Let's Encrypt przez DNS-01.
- **NFS z plikami baz** stoi obok aplikacji — kto ma dostęp do share'u, bierze
pliki z pominięciem wszystkich powyższych zabezpieczeń. Do zamknięcia po stronie
infrastruktury (eksport tylko dla IP węzłów, `root_squash`, najlepiej read-only).
- **Sekrety w etcd** są tylko zakodowane base64. Docelowo: szyfrowanie etcd
| `ASTRODEMO_USERS` | konta jako `login:sekret`, po przecinku. Sekret jawny albo hash `scrypt$sól$hash`. Każdy login = osobna pula plików |
| `ASTRODEMO_USER` / `ASTRODEMO_PASSWORD` | pojedyncze konto — zgodność wstecz, działa gdy `ASTRODEMO_USERS` jest puste. **Brak obu = aplikacja stoi otwarta** i mówi o tym głośno przy starcie |
| `INTERNAL_TOKEN` | token międzywarstwowy (LOG-32) — ten sam co reszta usług |
| `LINK_KEY_PRESENTATION_LOGIC` | klucz szyfrowanego łącza (PRE-16) — ten sam co prezentacja |
# UWAGA: pyswisseph (Swiss Ephemeris) jest na licencji AGPL-3.0 — dlatego ta
# usługa jest wydzielona i licencjonowana osobno (patrz LICENSE). Nie instaluj
# tego w obrazie permisywnego produktu.
fastapi>=0.115
uvicorn[standard]>=0.34
pyswisseph>=2.10
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.