gitea
2e9d3706ec
Pierwszy z pięciu kroków budowy trzech produktów: astrodemo (dwie funkcje) → astroklient (pełne astro bez AI) → astrololo (wszystko). Nazwa „astroklient" zostaje zwolniona dla warstwy pośredniej, więc dotychczasowe astroklient-demo nazywa się teraz astrodemo. REBASE. Cztery commity demo przeniesione na aktualnego mastera. Konflikt był jeden — rejestr wymagań (xlsx, binarny, git go nie scali). Master dodał LOG-34, gałąź demo PRE-28 i PRE-29; żaden wspólny wiersz się nie różnił, więc scalone ręcznie: 148 pozycji, wszystkie trzy obecne. ZMIANA NAZWY. Katalog, ciasteczko sesji (astrodemo_sesja), zmienne ASTRODEMO_USERS/USER/PASSWORD, CI, README, docstringi. Ponieważ PR z demo nigdy nie został zmergowany, usługa nie jest nigdzie wdrożona — zmiana nazw niczego nie migruje i nikogo nie wylogowuje. WYCIEKI. astrodemo powstało przed audytem z PRE-27, więc miało komplet tych samych dziur: - /static omijało bramkę (PUBLIC_PREFIXES), a pierwszy komentarz w styles.css brzmiał „Nie kopiujemy stylów pełnej aplikacji" — czyli anonimowy curl dowiadywał się, że istnieje pełna aplikacja. Zasoby idą teraz trasą z jawną listą, komentarze są zdejmowane przy serwowaniu. - Komunikat awarii wypisywał na ekran treść wyjątku httpx, z nazwą usługi i portem. Teraz jedno neutralne zdanie, szczegóły do dziennika. - /health oddawał nazwę warstwy. Teraz samo „ok". - Dziesięć komentarzy i docstringów tłumaczyło decyzje przez porównanie z „pełną aplikacją". Obraz tej usługi się KOMUŚ ODDAJE, więc kto go dostanie, przeczyta też komentarze. Przepisane tak, żeby opisywały tę usługę samą w sobie. - Nagłówek main.py twierdził, że demo dzieli pulę plików z produkcją. To nieprawda od PRE-29 (pule per konto) — opis poprawiony. ZAPORA SŁOWNIKOWA, dwupoziomowa. Poziom „wszędzie" (także w kodzie serwera, bo obraz się oddaje) obejmuje wzmianki o większym rodzeństwie, o modelu językowym i o funkcjach, których tu nie ma. Poziom „do przeglądarki" dokłada słownictwo mechanizmów. Test sprawdza odpowiedzi ORAZ drzewo plików. Jeden wyjątek jest jawny i opisany: stałe protokołu łącza (X-Astrololo-Token, X-Astrololo-Enc, typ treści, etykieta HKDF) niosą nazwę rodziny produktów. Są wspólne z warstwą logiczną, więc zmiana wymaga jednoczesnej podmiany we wszystkich usługach i rotacji — osobna decyzja. Osobny test pilnuje warunku, pod jakim to zostaje: że nie docierają do przeglądarki. Wcześniej przechodziły tylko dlatego, że regex nie dopasowywał po myślniku — przypadek, nie decyzja. Przy okazji: komunikat „ramka bez znacznika astrololo" zmieniony na neutralny we WSZYSTKICH PIĘCIU kopiach link_crypto.py (presentation, astrodemo, logic, data, render), żeby nie rozjechały się przed scaleniem w rdzeń. Te kopie to 2625 linii tego samego kodu. Testy: astrodemo 27, presentation 358, logic 342, data 42, render 41. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.0 KiB
astrodemo — wersja demonstracyjna (PRE-28)
Osobna warstwa prezentacji o dwóch funkcjach:
- dodanie pliku bazy — wgranie i włączenie do użytku jedną czynnością,
- zapytanie o interpretację urodzeniową dla podanych danych wejściowych.
I na tym koniec. Nie ma tu kosmogramu, synastrii, kalendarza, promptów do modelu, eksportu ani kont — nie są ukryte, tylko nie istnieją w tym obrazie.
Dlaczego osobna usługa, a 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 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.
Izolacja: własne dane, pula na konto
astrodemo → logic-demo → data-demo → udział astrololo-demo (pusty na starcie)
└── klientA/ ← pula konta
└── klientB/ ← pula konta
Oryginalne bazy interpretacyjne są dla demo nieosiągalne. Nie chodzi o uprawnienia: demo ma własną warstwę danych, pracującą na osobnym udziale. Osobna jest też warstwa logiczna, bo zna ona JEDEN adres warstwy danych — demo korzystające z produkcyjnej logiki i tak trafiłoby na produkcyjne bazy.
Każde konto ma własną pulę plików: swój podkatalog na tym udziale. Konta nie widzą swoich baz nawzajem ani w liście, ani w wynikach wyszukiwania. Dlatego demo można rozdawać szeroko.
Pula bierze się z loginu zalogowanej osoby i z niczego innego. Gdyby
przychodziła z żądania, wystarczyłoby podstawić cudzy login, żeby czytać cudze
bazy — osobny test wysyła tenant, user i login w formularzu i sprawdza, że
nie mają na nią wpływu.
Nazwa puli przechodzi przez sito dopuszczające wyłącznie znaki bezpieczne
w nazwie katalogu: ../.. czy ukośnik wyprowadziłyby zapytanie poza udział.
Pula klienta to jeden katalog, więc przejście na pełną wersję nie oznacza
utraty wgrań — procedura importu jest w runbooku wdrożenia (repo deploy,
astrololo/README-astrodemo.md).
Konfiguracja
| zmienna | znaczenie |
|---|---|
LOGIC_URL |
adres warstwy logicznej (domyślnie http://localhost:8001) |
ASTRODEMO_USERS |
konta jako login:sekret, po przecinku. Sekret jawny albo hash scrypt$sól$hash. Każdy login = osobna pula plików |
ASTRODEMO_USER / ASTRODEMO_PASSWORD |
pojedyncze konto — zgodność wstecz, działa gdy ASTRODEMO_USERS jest puste. Brak obu = aplikacja stoi otwarta i mówi o tym głośno przy starcie |
INTERNAL_TOKEN |
token międzywarstwowy (LOG-32) — ten sam co reszta usług |
LINK_KEY_PRESENTATION_LOGIC |
klucz szyfrowanego łącza (PRE-16) — ten sam co prezentacja |
RATE_LIMIT_PER_MIN |
limit żądań na adres, domyślnie 60; 0 wyłącza |
REPORT_LIMIT |
górny limit rekordów w jednej odpowiedzi, domyślnie 2000 |
TRUST_PROXY |
true za Ingressem — inaczej limit liczy wszystkich do jednego wiadra |
Hash hasła zrobisz tym samym skryptem, co dla głównej aplikacji:
cd services/presentation && python scripts/make_user.py demo
Uruchomienie lokalne
cd services/astrodemo
pip install -r requirements-dev.txt
ASTRODEMO_PASSWORD=tajne LOGIC_URL=http://localhost:8001 \
uvicorn app.main:app --port 8005
Testy:
cd services/astrodemo && PYTHONPATH=. pytest tests -q
Co pilnują testy
Poza zwykłą poprawnością — dwie własności, które łatwo zepsuć bez zauważenia:
- powierzchnia: zbiór tras aplikacji musi być dokładnie taki, jak dwie funkcje wymagają; klient warstwy logicznej ma tylko te metody, których używa. Trasa, o której nikt nie pamiętał, jest tu realnym ryzykiem, bo ta usługa rozmawia z produkcyjną warstwą danych.
- milczenie o regułach walidacji: plik odrzucony daje komunikat bez powodu. Reguły zna wyłącznie administrator w pełnej aplikacji (DAN-27), a demo nie ma prawa ich zdradzić nawet mimochodem.