148 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
gitea	cf24c4d473	ci: buduj tylko zmienione usługi i sprzątaj po sobie na runnerze ... 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>	2026-08-26 20:13:27 +02:00
gitea	fd79513ce2	astrololo: ekrany i eksport jako moduły, katalog z rejestracji (3/5) ... 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>	2026-08-26 16:32:49 +02:00
gitea	62d6f9d4d5	astrololo: generowanie tekstu jako moduł odłączalny (2/5) ... 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>	2026-08-26 14:25:56 +00:00
gitea	10ade55525	astrodemo: do obrazu wchodzi wyłącznie kod aplikacji ... `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>	2026-08-26 15:50:53 +02:00
gitea	2e9d3706ec	astrodemo: zmiana nazwy, rebase na mastera i domknięcie wycieków ... 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>	2026-08-26 12:05:40 +02:00
gitea	c73ba6a964	feat(astroklient-demo): sesje logowania zamiast HTTP Basic (LOG-34) ... 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>	2026-08-26 11:57:06 +02:00
gitea	16cf25468f	refactor: astroklient → astroklient-demo ... 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>	2026-08-26 11:57:06 +02:00
gitea	caf4fd80d1	feat(astroklient): pule plików per konto i izolacja od produkcji (PRE-29) ... 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>	2026-08-26 11:57:05 +02:00
gitea	e7b6d5013b	feat(astroklient): wersja demonstracyjna o dwóch funkcjach (PRE-28) ... 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>	2026-08-26 11:56:45 +02:00
gitea	320a0ab24e	PRE-27: pełne ukrycie niedostępnych funkcji (paranoja) ... 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>	2026-08-21 17:54:03 +02:00
gitea	1d0ff2f72e	PRE-27: generowanie tekstu przez model znika bez uprawnienia ... 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>	2026-08-21 13:10:16 +02:00
gitea	f0d07ee8c3	feat(bezpieczeństwo): sesje logowania zamiast HTTP Basic (LOG-34) ... 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>	2026-08-21 00:18:15 +02:00
gitea	71bb3b9c0a	feat(bezpieczeństwo): przycisk wylogowania (LOG-32) ... 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>	2026-08-20 23:52:04 +02:00
gitea	ee3c515d59	fix(testy): awaria magazynu kont wymuszana podmianą, nie prawami pliku ... 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>	2026-08-11 14:38:14 +00:00
gitea	ac8a0e9fc6	fix(dane): trzy błędy styku rejestru plików z resztą warstwy (DAN-27) ... 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>	2026-08-11 11:26:42 +02:00
gitea	b838cf4723	fix(dane): bazy zastane na udziale zostają w użyciu po przejściu na rejestr ... 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>	2026-08-09 20:44:30 +00:00
gitea	e2b50b284f	fix(konta): awaria magazynu tłumaczy się zamiast dawać gołe 500 ... 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>	2026-08-09 20:42:16 +00:00
gitea	003deb9404	feat(dane): sterownik Postgresa pod lustro w SQL (DAN-28) ... 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>	2026-08-07 15:16:43 +02:00
gitea	6466ab89a9	feat(dane): interfejs zarządzania plikami baz — trzy poziomy dostępu (DAN-27) ... 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>	2026-08-07 14:39:42 +02:00
gitea	a833965909	feat(bezpieczeństwo): konta z uprawnieniami do zakładek i funkcji (PRE-27) ... 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>	2026-08-07 12:18:14 +00:00
gitea	baf4e0e38a	fix(kosmogram): własne dymki zamiast natywnych — działają też po powiększeniu ... 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>	2026-08-06 16:31:07 +02:00
gitea	8b6ecc727d	feat(domy): przypisanie do domu przez wyrocznię + poprawki układu strony ... 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>	2026-08-06 13:55:13 +02:00
gitea	21a00b0000	feat(silnik B): endpoint /houses + nocny przemiał; ε PRAWDZIWE zamiast średniego ... 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>	2026-08-06 12:22:48 +02:00
gitea	4d1daab35a	feat(domy): warianty od Barana i od MC + obrót kosmogramu — LOG-05 zamknięte ... 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>	2026-08-05 22:38:43 +02:00
gitea	aec3f84331	feat(domy): topocentric zgodny co do zera — wybór gałęzi liczony, nie zgadywany ... 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>	2026-08-05 22:24:40 +02:00
gitea	7266f671a4	feat(domy): Placidus i Koch + jawny fallback poza kołem podbiegunowym ... 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>	2026-08-05 22:04:33 +02:00
gitea	548d9301f3	fix(domy): przepnij build_chart na cusps_for — inaczej nowe systemy dają 500 ... 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>	2026-08-05 21:53:54 +02:00
gitea	1be57a47d8	feat(domy): osiem systemów potwierdzonych co do zera wobec wyroczni ... 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>	2026-08-05 14:22:01 +02:00
gitea	40f5e459e0	fix(ci): wyrocznia domów — wbuduj pliki w obraz zamiast montować (-v nie działa) ... 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>	2026-08-04 23:20:43 +02:00
gitea	86a0f16f9e	test: framework porównania domów z wyrocznią + DWA błędy, które od razu wykrył ... 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>	2026-08-04 18:03:08 +02:00
gitea	e3114f3e7c	docs(bezpieczeństwo): runbook rotacji sekretów + poprawka nieaktualnej treści LOG-33 ... 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>	2026-08-04 17:10:23 +02:00
gitea	bc80745a94	docs(wymagania): DAN-25 rozbite na 25a (zrobione) i 25b (Kerberos, nice to have) ... 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>	2026-08-04 16:46:47 +02:00
gitea	6e7cfcbbd7	docs(bezpieczeństwo): runbook zamknięcia dostępu do baz na NFS (DAN-25) ... 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>	2026-08-04 14:43:12 +00:00
gitea	70c83cfc0c	docs(wymagania): statusy po serii iteracji „czysto" ... 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>	2026-08-04 09:59:56 +00:00
gitea	4c1e7f8808	feat: przegląd baz na udziale + globalne włączanie/wyłączanie (DAN-15/PRE-09) ... Wymaganie przedefiniowane pod model serwerowy (#47): nie wybiera się folderu — pliki leżą na stałym NFS. Potrzeba za to WIDZIEĆ, jakie bazy są dostępne i móc zdecydować, które biorą udział w interpretacji. Warstwa danych: `bases.py` (lista plików + metaopis: nazwa, ścieżka, rozmiar, data, stan) i endpoint `/bases`. Wyłączone bazy są ODSIEWANE z kandydatów przy wyszukiwaniu, więc naprawdę nie biorą udziału w interpretacji — nie tylko znikają z listy. Lista wyłączonych wchodzi do klucza cache zapytań: bez tego zmiana ustawień oddawałaby wynik sprzed zmiany, czyli treść bazy uznanej za wyłączoną. `list_bases()` doszło do interfejsu dostawcy jako OPCJONALNE (SQL nie operuje na plikach → pusto, zamiast wywrotki). Przelot logika → prezentacja i ekran „Ustawienia" z tabelą baz. Przez łącze idą SAME METADANE — podgląd listy nie jest kolejną drogą do wyniesienia treści. Stan przełączników jest DEKLARATYWNY (`DISABLED_BASES`), nie klikalny — i to jest świadome: udział z bazami montujemy read-only, a katalog cache to `emptyDir`, więc zapisany przełącznik ginąłby przy restarcie poda i po cichu włączał z powrotem wyłączoną bazę. Ekran mówi wprost, jak wyłączyć bazę i dlaczego nie klikaniem. Tryb klikalny wymagałby dołożenia trwałego wolumenu. Weryfikacja na żywym łańcuchu: `/bases` przechodzi przez SZYFROWANE łącze (logic→data), pokazuje 3 bazy z metaopisem i stanem; wyszukiwanie daje 3 → 2 → 0 wierszy w miarę wyłączania baz. Testy: dane +6, prezentacja +6. Dane 13, logika 277, prezentacja 249. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 22:09:27 +02:00
gitea	d3d9b365fe	feat(bezpieczeństwo): konta imienne i dziennik audytowy (PRE-17) ... Jedno wspólne hasło nie mówiło, KTO sięgał do baz, a odebranie dostępu jednej osobie wymagało zmiany hasła wszystkim. Przy bazach o realnej wartości handlowej to za mało. KONTA IMIENNE: `APP_USERS='alicja:scrypt$…,bartek:scrypt$…'`. Hash liczy scrypt ze STDLIB — zero nowych zależności; hasła nie ma w konfiguracji jawnie. Zakładanie konta: scripts/make_user.py (hasło interaktywnie, nie w historii powłoki). Odebranie dostępu = usunięcie wpisu, reszta nie zmienia haseł. Gdy APP_USERS jest ustawione, wspólne APP_PASSWORD PRZESTAJE działać (ostrzeżenie przy starcie) — działające obok kont byłoby tylnym wejściem bez śladu w dzienniku. Dopóki APP_USERS nie jest ustawione, stary tryb działa jak dotąd (zgodność wstecz). DZIENNIK AUDYTOWY: każde żądanie zostawia wpis „kto, skąd, co, status, ILE rekordów, ile ms". Liczba rekordów jest tu sednem — pojedyncze zapytanie wygląda niewinnie, suma pokazuje powolne wypompowywanie bazy przez osobę uprawnioną. Liczona dla wyszukiwarki sygnifikatorów, raportu i eksportu do Excela (ten wynosi najwięcej naraz). W logach NIE MA treści — ani rekordów, ani promptów. Dwa realne błędy złapane po drodze: - `secrets.compare_digest` rzuca TypeError na znakach spoza ASCII, więc hasło z polskimi literami wywracało logowanie błędem 500 zamiast odmowy (błąd ZASTANY, sprzed tej zmiany) — porównujemy teraz bajty; - dziennik był PUSTY na żywym serwerze: domyślna konfiguracja uvicorna nie obsługuje naszych loggerów. Niewidoczny dziennik jest gorszy niż jego brak, więc audyt dostał własny handler na stdout. Oba przypadki mają testy regresji. Instrukcja wdrożeniowa: docs/konta-i-audyt.md. Testy: +15. Prezentacja 243. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 19:57:03 +00:00
gitea	dd32f7e82f	ci: odpalaj testy warstwy bazodanowej (dotąd nie były uruchamiane) ... 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>	2026-08-03 21:38:48 +02:00
gitea	78af6d4755	feat(dane): mechanizm rekordów-pułapek (canary) — wykrywanie wycieku baz (DAN-26) ... 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>	2026-08-03 21:15:53 +02:00
gitea	7b435d4263	feat: synastria — aspekty między dwoma horoskopami (PRE-04) ... Pierwsza technika relacyjna z pełnym UI (Returns były już w kalendarzu od LOG-12). Dwie osoby → aspekty MIĘDZY ich horoskopami (planeta osoby A do planety osoby B). Silnik: `find_cross_aspects(a, b, orb, luminary_bonus, minor)` — każdy obiekt A × każdy obiekt B. `obj1` = osoba A, `obj2` = osoba B. Statyczne (dwa natale, brak wspólnego czasu) → bez applying/separating. Par sztywnych (NN/SN) NIE wycinamy — między dwiema osobami to realny aspekt, nie artefakt definicji. Wspólny matcher `_first_aspect` (z find_aspects), więc orb/bonus/aspekty poboczne działają tak samo. Endpoint `POST /chart/synastry` (dwie osoby + zodiak + ustawienia aspektów) → pozycje obu + siatka aspektów z glifami. Prezentacja: zakładka „Synastria", formularz dwóch osób (pętla po a_/b_), tabela aspektów A · aspekt · B · orb. Weryfikacja na żywym API: 13+13 obiektów, 63 aspekty synastryczne z poprawnymi glifami i bonusem świateł (A.Sun ☌ B.Venus przy orbie 8.67 = 8+2). Testy: logika +4 (cross-aspekty, kolejność A/B, brak filtra par sztywnych, brak applying), prezentacja +7 (trasa, formularz dwóch osób, klient, tabela). Logika 277, prezentacja 228. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 20:55:49 +02:00
gitea	a9f2a038fa	refactor(prezentacja): wspólne partiale formularza — koniec dublowania chart/compile ... Spłata długu: bloki opcji i tabele wyniku były kopiowane między „Horoskop" (/) i „Skompiluj" (/compile). Duplikat już raz spowodował regresję (podsumowanie gubiło opcje), a przy każdej nowej opcji rósł (dodawałem je 3× w dwóch miejscach). - `_form_options.html` (NOWY): bloki opcji — stacje/tabele, porównanie domów, ustawienia aspektów. Dołączany przez oba formularze. - `_result_tables.html`: chart.html PRZECHODZI na ten wspólny plik (compile już go używał od #46). Rysunki (koło/aspektarian/deklinacja/antyscja) zgrupowane razem, potem wspólne tabele. Dzięki temu widok główny i podsumowanie NIE MOGĄ się już rozjechać — jedno źródło prawdy. Zero zmian zachowania: oba szablony renderują te same pola i tabele co wcześniej (sprawdzone renderem na bogatym wyniku). Testy strukturalne przełączone na odczyt wspólnych plików. Prezentacja 221. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 18:09:54 +02:00
gitea	b36b3bee19	feat: konfigurowalne aspekty i orby (PRE-06) ... Dotąd orb (8°) i aspekty były zaszyte w silniku. Astrolodzy pracują na różnych orbach i lubią dokładać aspekty poboczne — teraz da się to ustawić w UI. Silnik (aspects.py): `find_aspects` przyjmuje orb, luminary_bonus i `minor`. Aspekty poboczne = tylko trzy (półsekstyl 30° / półkwadratura 45° / kwinkunks 150°) — bo mają już glify i barwy w prezentacji i w engine/glyphs.py, więc dokładają się bez ruszania czegokolwiek poza silnikiem. Bazy zwykle ich nie opisują (brak tokenu), więc trafiają na kosmogram i do tabeli, ale NIE tworzą faset — most sygnifikatorów po cichu je pomija (skip przy braku tokenu). Plumbing przez wszystkie warstwy: request logiki, build_chart, klient prezentacji, oba handlery (/, /compile) ORAZ PDF (/compile/pdf). Ustawienia wędrują między zakładkami (formsync) i lecą do PDF-a (compile.js) — żeby podsumowanie liczyło aspekty tym samym orbem co horoskop (ta sama zasada co fix podsumowania #46). UI: orb, bonus dla świateł, checkbox „aspekty poboczne" na obu formularzach. Weryfikacja na żywym /chart/positions: domyślnie 24 aspekty (główne); minor → 52 (dochodzą quincunx/semisextile/semisquare); orb 3 → 13, orb 12 → 32. Testy: logika +3 (minor/orb/bonus), prezentacja +6 (obecność pól, przekazanie przez warstwy, sync, PDF). Logika 273, prezentacja 220. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 13:16:32 +02:00
gitea	a0d1135db1	feat(prezentacja): cache-busting plików statycznych (PRE-26) ... Po deployu przeglądarka trzymała stare styles.css / *.js — ten sam URL, więc serwowała z cache mimo nowej wersji. Doklejamy do URL-a krótki HASH TREŚCI pliku: zmienił się plik → zmienił się URL → przeglądarka pobiera nowy; bez zmian URL zostaje ten sam i cache dalej działa (bustujemy tylko to, co się zmieniło). - `static_url(name)` + globalny helper Jinja `static()`: `/static/x?v=<md5[:8]>`. Hash liczony raz na proces (lru_cache) — nowy pod po deployu = świeży hash; brak pliku → `?v=0`, nie wywala strony. - Wszystkie odwołania w szablonach (styles.css, nasze *.js, vendor Leaflet) idą teraz przez helper zamiast surowego `/static/...`. Testy: +5 (hash w URL, zależny od treści, brak-pliku-bezpieczny, żaden szablon nie serwuje surowej ścieżki, base używa helpera). Test kolejności skryptów zaktualizowany pod nowy format. Prezentacja 214. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 11:22:38 +02:00
gitea	81e09aa6df	docs(wymagania): PRE-09/DAN-15 przedefiniowane pod model serwerowy ... 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>	2026-07-30 20:37:17 +02:00
gitea	8ebce816cd	feat(prezentacja): eksport wyników do Excela — tabela robocza (DAN-23/PRE-10) ... Astrolog chce PRACOWAĆ z dopasowaniami: filtrować, sortować, zaznaczać, usuwać — najwygodniej w Excelu. Raport z logiki jest zagnieżdżony (obiekt → fasety → próbki), więc spłaszczamy go do JEDNEJ płaskiej tabeli: wiersz = jedno dopasowanie z bazy. Kolumny: Obiekt · Faseta · Typ · Token · Sygnifikator · Rozwinięcie · Opis/efekt. - `report_export.py`: `report_to_xlsx(report)` (openpyxl). Auto-filtr + zamrożony nagłówek = filtrowanie/sortowanie od razu; „Opis" zawijany. Bez ozdób — materiał roboczy. Plik składamy TU, w prezentacji (jak PDF idzie przez render): logika liczy, prezentacja formatuje wyjście. - `/interpret` dostaje akcję `export` → pobranie `.xlsx` (nie strona). Przycisk „Pobierz Excel" obok „Szukaj interpretacji". - Zależność: openpyxl (czysty Python). Zero swissepha, zero walidacji krzyżowej, zero danych od użytkownika — pierwsza z iteracji „czysto". Testy: +7 (round-trip pliku: nagłówek, spłaszczenie, auto- filtr/zamrożenie, pusty-bezpieczny, %, wpięcie w UI). Prezentacja 180. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-30 15:46:16 +02:00
gitea	52b7c20c2a	fix(prezentacja): podsumowanie bierze WSZYSTKIE policzone opcje (stacje, tabele, domy) ... Regresja: „Skompiluj" przeliczało horoskop od nowa z OKROJONYM zestawem opcji (tylko system domów + zodiak), więc jeśli przy horoskopie policzyłeś stacje, tabele (żywioły, faza Księżyca…) albo porównanie domów — w podsumowaniu ich NIE było. Zamiast pokazać to, co policzono, liczyło uboższą wersję. Zostaje czysty przelicz (bez trzymania dużego wyniku w przeglądarce), ale z TYMI SAMYMI opcjami co przy horoskopie: - `formsync`: synchronizuje między zakładkami też opcje — checkboxy (stacje, tabele) i wielo-checkbox (porównanie domów). Wcześniej umiał tylko `.value`. - „Skompiluj" (formularz): dostaje te same opcje; `compile_build` i `compile_pdf` przekazują je do logiki (stations/tables/house_systems). `compile.js` wysyła je w payloadzie PDF-a. - Wspólny plik `_result_tables.html`: podsumowanie renderuje DOKŁADNIE te same tabele co „Horoskop" (porównanie domów, stacje, aspekty, paralele, antyscja, żywioły/faza/godziny, Lots…). Każda sekcja pokazuje się tylko, gdy jej dane są w wyniku — opcja niepoliczona → sekcji nie ma (zgodnie z prośbą). (TODO: przełączyć też chart.html na ten include, by widoki nie mogły się rozjechać — na razie zgodność pilnowana ręcznie, jest komentarz w pliku.) Weryfikacja: render wspólnego pliku na bogatym wyniku pokazuje wszystkie sekcje. Testy: +8 (opcje niesione w /compile i /compile/pdf, sync checkboxów/multi, wspólny include). Prezentacja 202. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-30 14:01:42 +02:00
gitea	9b1e4dbb20	feat: wiele systemów domów naraz — porównanie obok siebie (PRE-05/LOG-05, A2a) ... Astrolodzy spierają się o systemy domów; teraz można policzyć kilka na raz i zobaczyć, jak różny podział przesuwa planety między domami. Domy to geometria z Asc/MC — osie są WSPÓLNE, różni się tylko podział. Prymarny system zostaje w `cusps`/`house_system`/`positions[].house` (pod kosmogram i wstecznie — nic się nie zmienia dla dotychczasowych ścieżek). Nowość: - logika: `build_chart(..., house_systems=[...])` → `result["house_systems"]` = pełen zestaw (prymarny pierwszy, bez duplikatów), a `positions[].houses[system]` mówi, w którym domu obiekt siedzi wg każdego systemu. Doklejane tylko gdy > 1. Nieznany system (np. placidus — dojdzie przez swisseph osobno, A2b) pomijany, nie wywala horoskopu. - endpoint `/chart/positions`: pole `house_systems`; klient prezentacji przekazuje. - UI: checkboxy „Porównaj systemy domów" (whole sign / equal / porphyry) + tabela kusp obok siebie (12 domów × systemy), stan zaznaczeń przeżywa submit. Na razie 3 systemy z czystej matmy (`houses.py`) — zero zależności, zero walidacji krzyżowej. Egzotyczne (Placidus/Koch/Regiomontanus/Campanus) dojdą przez endpoint `/houses` w silniku B (swisseph) jako A2b — maszyneria „naraz" jest już gotowa, egzotyczne tylko dopiszą kolejne wpisy. Weryfikacja: żywy /chart/positions — prymarny whole_sign, house_systems [whole_sign, equal, porphyry], 12 kusp/system, dom per system per obiekt. Testy: logika +5, prezentacja +6. Logika 270, prezentacja 179. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-29 00:03:47 +00:00
gitea	4bdfb673cc	feat(prezentacja): strefa czasowa z lokalizacji — DST-świadomy offset (PRE-03) ... „Logika dwóch lokalizacji": dotąd offset GMT był ręcznym polem (PRE-19) — trzeba było go znać i samemu pamiętać o czasie letnim. Teraz liczymy go z lokalizacji. Sedno wymagania: strefę ustalamy RAZ i trzymamy jako stałą liczbę, żeby drobna zmiana współrzędnych nie przerzuciła DST i nie „przeskoczyła" Ascendenta na sąsiedni znak. „Większa miejscowość z bazy" okazuje się zbędna — strefa IANA jest i tak regionalna, więc wioska daje tę samą strefę co pobliskie miasto. Jak: - `timezone.py`: współrzędne → strefa IANA (tzfpy, OFFLINE — bez sieci), a z niej offset DLA DATY URODZENIA. `zoneinfo`/`tzdata` znają reguły historyczne i DST: Kraków 1984 to +1h zimą, +2h latem; Katmandu +5:45. Degraduje się do None (brak biblioteki / punkt bez strefy / zła data) — wtedy zostaje ręczny offset. - Endpoint `GET /timezone?lat&lon&date&time` → {tz, offset, dst, label}. 404, gdy nie da się ustalić. - `geo.js`: po wyborze miejsca (mapa / wyszukiwarka / „Tu i teraz") oraz przy zmianie DATY (bo DST zależy od pory roku) pobiera offset i wypełnia pole tz_offset, pokazując wykrytą strefę („Wykryto: Europe/Warsaw · +2:00 (czas letni)"). Pole zostaje edytowalne. Na wejściu podpowiada tylko gdy offset wygląda na nieustawiony — nie nadpisuje wartości ręcznie wpisanej i wysłanej. Zależności (lekkie, offline): tzfpy (wheel Rust) + tzdata (dla zoneinfo w slim-obrazie). Weryfikacja: żywy serwer — Kraków 1984-06 → +2:00 (czas letni), 1984-01 → +1:00, Katmandu → +5:45. Testy: +12 strefa (moduł + endpoint), +5 JS. Prezentacja 187. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-28 22:42:31 +02:00
gitea	9a5d61b5eb	docs(wymagania): PRE-18 → Zrobione (aspektarian + wizualizacje pochodne) ... 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>	2026-07-28 20:29:20 +00:00
gitea	bb64758fa0	stacks	2026-07-28 22:28:47 +02:00
gitea	91c4f918dc	stacks	2026-07-28 21:03:36 +02:00