f34016a4a571623be716ada6070df77df99126f7
11 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 gitea
|
f34016a4a5 |
feat(prezentacja): wspolne dane formularza miedzy zakladkami + imie i nazwisko (PRE-21)
build / build (push) Successful in 58s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 11m4s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m53s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 38s
Testy / Kontrola składni wszystkich warstw (push) Successful in 25s
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> |
||
|
gitea
|
5c82e8bd9f |
fix(prezentacja): offset wzgledem GMT + nazwa lokalizacji po „Tu i teraz”
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> |
||
|
gitea
|
ace76183e5 |
feat(logic): glify astrologiczne — konwersja tekst↔symbol (LOG-22)
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m55s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m43s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 37s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 21s
build / build (push) Successful in 1m22s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 11m12s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m39s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 33s
Testy / Kontrola składni wszystkich warstw (push) Successful in 24s
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> |
||
|
gitea
|
e8f868e907 |
docs(wymagania): realne statusy + kosmogram jako feature prezentacji
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 11m56s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m36s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 31s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 22s
build / build (push) Successful in 44s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m59s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m33s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 31s
Testy / Kontrola składni wszystkich warstw (push) Successful in 18s
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>
|
||
|
gitea
|
56fdf01d7d |
feat(bezpieczenstwo): szyfrowanie lacz miedzy warstwami AES-256-GCM (PRE-16)
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m45s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m31s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 31s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 15s
build / build (push) Successful in 4m15s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 11m41s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m36s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 33s
Testy / Kontrola składni wszystkich warstw (push) Successful in 15s
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> |
||
|
gitea
|
4da5f5fe7e |
docs: braki bezpieczenstwa jako wymagania (PRE-16/17, DAN-25/26, LOG-33)
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m53s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m56s
Testy / Build obrazu silnika B (swisseph) (pull_request) Failing after 44s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 34s
build / build (push) Successful in 52s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m51s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m56s
Testy / Build obrazu silnika B (swisseph) (push) Failing after 30s
Testy / Kontrola składni wszystkich warstw (push) Successful in 20s
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> |
||
|
gitea
|
2892b71be3 |
docs: wymagania feature'u horoskop AI (LOG-29..32, PRE-14/15, Q-12/13)
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m42s
Testy / Build obrazu silnika B (swisseph) (pull_request) Failing after 29s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 18s
build / build (push) Successful in 49s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m44s
Testy / Build obrazu silnika B (swisseph) (push) Failing after 29s
Testy / Kontrola składni wszystkich warstw (push) Successful in 26s
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> |
||
|
gitea
|
561d95c7f4 |
Wymagania: kolumna "Po ludzku (bez żargonu)" — nietechniczne wyjaśnienia
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> |
||
|
gitea
|
21442b35b9 |
Wymagania: dwa silniki w warstwie logicznej (własny + AGPL) do porównań
Decyzja: warstwa logiczna ma dwie wymienne implementacje silnika obliczeń — własną/permisywną (ścieżka A) i AGPL (Swiss Ephemeris) — dla wbudowanego frameworku porównań i walidacji. Prezentacja i dane pozostają wspólne. - docs/architektura-dwoch-silnikow.md: schemat, izolacja licencyjna silnika AGPL jako osobnej usługi (engine-swisseph), mechanizm dual-run, mapowanie na wymagania, profile wdrożeniowe. - astrololo_wymagania.xlsx (Warstwa logiczna): rewizja LOG-24 (EngineProvider z dwoma backendami) i LOG-25 (framework porównawczy); nowe LOG-26 (dual-run + raport różnic), LOG-27 (izolacja licencyjna silnika AGPL), LOG-28 (kontrakt parzystości silników). Licznik w Przeglądzie: 28. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
gitea
|
3655b39acf |
Rozszerz analizę warstwy logicznej: gotowce, licencje, złożoność + LOG-25
- docs/przeglad-bibliotek-i-licencji.md: przegląd istniejących bibliotek/ programów z komentarzem licencyjnym i oceną ryzyka praw autorskich; rekomendacja ścieżki A (Skyfield/Moshier permisywne) + nota o prawach do treści baz. - docs/warstwa-logiczna-analiza.md: rozwinięcie 24 wymagań LOG, przypisanie permisywnych gotowców, ocena złożoności implementacji od zera, rola B/C jako wyroczni walidacyjnej; kolejność budowy. - astrololo_wymagania.xlsx: w arkuszu "Warstwa logiczna" 4 nowe kolumny (gotowe rozwiązanie / licencja / złożoność od zera / rola B/C) oraz nowy wiersz LOG-25 (harness walidacyjny). Licznik w Przeglądzie zaktualizowany. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
gitea
|
7bda39ab46 |
Dodaj arkusz wymagań projektu (model trójwarstwowy)
docs/astrololo_wymagania.xlsx — spójna lista wymagań zsyntetyzowana z dokumentów astroparser_notes2, astroparser notes3 i astro19 version2026. Sześć arkuszy: Przegląd, Warstwa danych (24), Warstwa logiczna (24), Warstwa prezentacji (13), Pytania otwarte (11), Słownik (25). Każde wymaganie: ID, kategoria, opis, szczegóły, priorytet (MoSCoW), status, źródło. Dokument roboczy do iteracyjnego przeglądu przed implementacją. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |