8 Commits

Author	SHA1	Message	Date
gitea	e8f868e907	docs(wymagania): realne statusy + kosmogram jako feature prezentacji ... 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>	2026-07-23 20:30:13 +02:00
gitea	56fdf01d7d	feat(bezpieczenstwo): szyfrowanie lacz miedzy warstwami AES-256-GCM (PRE-16) ... 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>	2026-07-23 17:06:11 +02:00
gitea	4da5f5fe7e	docs: braki bezpieczenstwa jako wymagania (PRE-16/17, DAN-25/26, LOG-33) ... 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>	2026-07-21 20:47:21 +02:00
gitea	2892b71be3	docs: wymagania feature'u horoskop AI (LOG-29..32, PRE-14/15, Q-12/13) ... 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>	2026-07-21 16:46:44 +02:00
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>	2026-06-27 17:16:33 +02:00
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>	2026-06-27 16:50:56 +02:00
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>	2026-06-27 12:31:37 +02:00
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>	2026-06-26 18:18:46 +02:00