SESSION_SECRET w sekrecie astrololo-demo — WŁASNY, nie ten z pełnej aplikacji:
demo i produkcja nie mają powodu uznawać nawzajem swoich sesji.
W runbooku zapisana różnica wobec pełnej wersji: demo nie ma własnego wolumenu,
więc nie ma licznika sesji. Zdalne unieważnienie robi się przez DEMO_USERS —
usunięcie konta albo zmiana hasła natychmiast ubija jego otwarte sesje.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nazwa `astroklient` zostaje zarezerwowana dla przyszłej wersji produkcyjnej;
obecna, demonstracyjna nazywa się od teraz `astroklient-demo`.
Zmiana obejmuje nazwy plików (astroklient-demo.yaml, astroklient-demo-stack.yaml,
README-astroklient-demo.md), Deployment i Service, etykiety selektorów, obraz
w rejestrze, alias w image-updaterze, wpisy w kustomization i odsyłacze w README.
`data-demo` i `logic-demo` zostają bez zmian — nie niosły starej nazwy.
Sprawdzone: `kubectl kustomize astrololo` składa komplet 27 zasobów, obraz to
astrololo-astroklient-demo, żadnego zdublowanego przyrostka ani gołego
`astroklient` nie zostało.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zmiana wobec pierwszej wersji: demo NIE pracuje już na produkcyjnej warstwie
danych. Ma własną logikę i własne dane, na osobnym udziale astrololo-demo,
pustym na starcie. Oryginalne bazy są dla demo nieosiągalne — nie przez
uprawnienia, tylko dlatego, że nie ma do nich drogi.
DLACZEGO OSOBNA JEST TEŻ WARSTWA LOGICZNA. Zna ona JEDEN adres warstwy danych,
więc astroklient korzystający z produkcyjnej logiki i tak trafiłby na produkcyjne
bazy. Izolacja musi sięgnąć obu warstw naraz, inaczej nie ma jej wcale. Jedyną
różnicą logic-demo wobec produkcyjnej jest DATA_URL — i to jest cała izolacja,
więc wpisanie tam „logic" cofnęłoby ją jednym słowem. Stąd komentarz przy tej
linii i sąsiedztwo obu plików.
PULE PER KONTO. Każde konto demo dostaje własny podkatalog na tym udziale,
niewidoczny dla pozostałych — w liście plików i w wynikach wyszukiwania. Konta
są listą `login:sekret` w sekrecie, bo jedno wspólne oznaczałoby wspólną pulę,
czyli klientów oglądających nawzajem swoje wgrania.
Ten sam OBRAZ co produkcja dla data i logic — różni je wyłącznie konfiguracja.
Osobny obraz to drugi kod do utrzymania i pewność, że kiedyś się rozjadą.
Logika demo nie dostaje kluczy do modeli językowych: astroklient nie umie o nie
prosić, więc nie ma powodu, żeby leżały w tym podzie.
Runbook opisuje IMPORT PULI KLIENTA do pełnej aplikacji — sedno całego układu,
bo klient przechodzący na pełną wersję nie może stracić wgrań. Jego pula to jeden
katalog: sprawdzenie kolizji nazw, kopiowanie z -n (nigdy nadpisania bazy
produkcyjnej), bez pliku stanu (produkcja ma własny), a na końcu świadome
włączenie w zakładce Pliki. Nie włączają się same, bo przeniesienie jest
czynnością techniczną, a decyzja o użyciu należy do właściciela.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deployment + Service (ClusterIP), wpięcie w kustomization, obraz dopisany do
image-updatera i runbook.
Obraz na liście image-updatera CELOWO od razu: obraz, którego tam nie ma, nigdy
się nie podbije, choćby CI go budowało — tak przez chwilę wisiał render na :latest.
Token międzywarstwowy i klucz łącza brane z TYCH SAMYCH sekretów co prezentacja:
demo nie jest furtką omijającą ochronę warstwy logicznej. Hasło demo natomiast
z OSOBNEGO sekretu astrololo-demo — demo odcina się jego skasowaniem, bez ruszania
kont głównej aplikacji.
Limit żądań niższy niż w pełnej aplikacji (60/min): demo bywa udostępniane szerzej,
a każde zapytanie sięga do treści baz.
Runbook zaczyna się od ostrzeżenia, bo to jedyna rzecz, którą trzeba pamiętać za
każdym razem: demo pracuje na PRODUKCYJNEJ warstwie danych, więc kto dostaje adres,
czyta oryginalne bazy, a jego wgrania trafiają do produkcyjnego zbioru. Pełna
izolacja wymagałaby osobnej warstwy danych i nie jest dziś zrobiona.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gitea