astroklient-demo — wersja demonstracyjna z izolacją i pulami per konto (PRE-28/29) #74

Closed

gitea wants to merge 4 commits from feat/astroklient into master

pull from: feat/astroklient

merge into: gitea:master

gitea:master

gitea:feat/zarzadzanie-plikami

gitea:fix/konta-blad-magazynu

gitea:feat/placidus-koch

gitea:feat/exotic-house-systems

gitea:feat/log31-llm-provider

gitea:feat/firdaria-log11

gitea:feat/timeline-interpretations

gitea:feat/timeline-log14

gitea:feat/profections-returns

gitea:feat/nodes-lilith-stations

gitea:feat/aspects-applying

gitea:fix/geo-secure-context

gitea:feat/scoring-grouping-geo

gitea:feat/aspects

gitea:feat/noise-and-abbrev

gitea:feat/presentation-chart

gitea:feat/logic-engine

gitea:docs/plain-language-column

gitea:requirements/dual-engine

gitea:docs/requirements-spreadsheet

gitea:scaffold/three-tier-app

Conversation 0 Commits 4 Files Changed 27

+2095 -26

4 Commits

Author	SHA1	Message	Date
gitea	fee102f2ea	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-21 00:21:52 +02:00
gitea	222963d105	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-20 23:36:55 +02:00
gitea	2d7775f9b3	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-17 19:00:39 +02:00
gitea	a88ca14639	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-17 18:39:47 +02:00