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>
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>
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>
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>
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>
- 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