4 Commits

Author	SHA1	Message	Date
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	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	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