15 Commits

Author	SHA1	Message	Date
gitea	cf24c4d473	ci: buduj tylko zmienione usługi i sprzątaj po sobie na runnerze ... Rejestr obrazów rósł, bo `build.yaml` budował CZTERY obrazy przy każdym pushu do mastera, niezależnie od tego, co się zmieniło. Zmiana w samej prezentacji dawała nowe wersje data, logic i astrodemo — identyczne co do zawartości, różniące się wyłącznie tagiem. Render i silnik B miały filtry ścieżek od początku (build-render.yaml, build-swisseph.yaml) i budują się tylko przy własnych zmianach. Ta zmiana przenosi tę samą zasadę do głównego pipeline'u, licząc różnicę wobec poprzedniego commita. Kontekstem budowania każdego obrazu jest wyłącznie `./services/<nazwa>`, więc porównanie ścieżek jest dokładne, a nie przybliżone. Sprawdzone na ośmiu ostatnich commitach mastera: dwa refaktory prezentacji dają sam `presentation`, poprawka Dockerfile'a astrodemo daje samo `astrodemo`, a commit ruszający link_crypto w pięciu usługach — komplet. Bez porównania (pierwszy commit, przepisana historia) budujemy wszystko: lepiej zbudować za dużo niż wypuścić obraz ze starym kodem pod nowym tagiem. SKUTEK UBOCZNY DO ŚWIADOMOŚCI: tagi w kustomization mogą się teraz rozjechać między usługami, bo nie każda dostaje nową wersję z każdego commita. Tak ma być — image-updater śledzi każdy obraz osobno i przypina to, co istnieje. ZABEZPIECZENIE PRZED CICHYM POMINIĘCIEM. Usługa, której nie ma na żadnej liście, nigdy się nie zbuduje i nikt tego nie zauważy: brak obrazu wygląda potem na problem z rejestrem albo z siecią. Ten sam mechanizm kosztował nas już raz, przy liście obserwowanych obrazów w image-updaterze. Pętla po `services/*/` zatrzymuje budowanie i mówi wprost, co dopisać. Sprawdzone także od strony negatywnej — podstawiony katalog nowej usługi kończy przebieg kodem 1. SPRZĄTANIE NA RUNNERZE, w build.yaml i w build-render.yaml, z `if: always()` — bo to po NIEUDANYM budowaniu zostaje najwięcej śmieci, a kolejny przebieg zaczyna od mniejszego zapasu miejsca niż poprzedni. Tak zatkał się dysk przy renderze z TeX Live. Filtr `until=168h` zostawia tydzień, więc warstwy bazowe i cache przeżywają i build nie zaczyna od zera. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 20:13:27 +02:00
gitea	2e9d3706ec	astrodemo: zmiana nazwy, rebase na mastera i domknięcie wycieków ... 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>	2026-08-26 12:05:40 +02:00
gitea	16cf25468f	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-26 11:57:06 +02:00
gitea	e7b6d5013b	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-26 11:56:45 +02:00
gitea	21a00b0000	feat(silnik B): endpoint /houses + nocny przemiał; ε PRAWDZIWE zamiast średniego ... Etap 4, z jedną istotną zmianą planu i jednym znalezionym błędem. /houses W SILNIKU B Domyka kontrakt parzystości (LOG-28) po stronie domów — dotąd obejmował tylko pozycje obiektów, więc błąd w podziale na domy przechodził przez porównanie silników niezauważony. Nazwy systemów są NASZE (te same, co houses.SYSTEMS), więc wołający nie musi znać liter swissepha; rozjazd tych dwóch list oznaczałby, że parzystość przestała obejmować część systemów. Poza dziedziną (Placidus/Koch za kołem podbiegunowym) zwracamy 422 z powodem, a NIE podstawiamy po cichu innego systemu — cicha podmiana jest po stronie wołającego niewykrywalna, a to on ma zdecydować, co z tym zrobić. PRZEMIAŁ: NOCNE CI ZAMIAST CRONJOBA W KLASTRZE Plan zakładał Job w k3s, bo „duży przemiał jest kosztowny". Pomiar tego nie potwierdził: 500 000 przypadków × 13 systemów = 70 mln porównań w 64 sekundy, skalowanie liniowe (20k→2,8 s, 100k→12,3 s, 500k→64 s). Osobny obraz w rejestrze, manifest, CronJob i kopia harnessu poza repo byłyby infrastrukturą do problemu, którego nie ma — a kopia harnessu poza repo to ryzyko cichego rozjazdu z kodem, który ma testować. Workflow z harmonogramem daje to samo: co noc inne ziarno, więc dziedzina przeczesuje się z czasem gęściej niż pojedynczym przebiegiem. ε PRAWDZIWE — BŁĄD ZNALEZIONY PRZY OKAZJI Silnik liczył RAMC z GAST (czas gwiazdowy POZORNY, mierzony od równonocy PRAWDZIWEJ), ale parował go z ε ŚREDNIM, czyli bez nutacji. To nie wybór konwencji, tylko pomieszanie dwóch układów odniesienia. Skutek: do 3,2″ na cuspach domów oraz niespójne ε dla deklinacji i antyscji, liczonych z pozycji POZORNYCH. Teraz ε pochodzi z serii IAU 2000A — z tego samego źródła, którego Skyfield używa do GAST, więc oba są spójne z definicji. Framework wyroczni tego NIE MÓGŁ wykryć: z założenia podaje to samo ε obu stronom, żeby izolować samą funkcję domów. Błąd siedział w danych WEJŚCIOWYCH, nie w testowanej funkcji — i cały czas świecił na zielono. Wejście ma więc teraz własny sprawdzian, ze Skyfieldem jako niezależnym autorytetem (bez swissepha, więc działa w każdym środowisku). Luka opisana wprost w tests/oracle/README.md, bo poprzedni tekst twierdził, że ε jest testowane — nie było. Reszta ~3″ przy porównaniu „cały horoskop nasz vs swissepha" to UT1 kontra UTC: Skyfield konwertuje z tablic IERS, swisseph przyjmuje podany JD jako UT1 (dla 1984-04-30 różnica 0,181 s = 2,7″ RAMC — zgadza się co do trzeciego miejsca). Podanie swissephowi JD w UT1 kasuje ją do 0,00065″. Nasza strona jest dokładniejsza; niczego tu nie zmieniam. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-06 12:22:48 +02:00
gitea	40f5e459e0	fix(ci): wyrocznia domów — wbuduj pliki w obraz zamiast montować (-v nie działa) ... Krok padał na `python: can't open file '/oracle/run.py'`. Przyczyna jest tą samą pułapką, którą złapano już wcześniej przy `-p` i localhoście (jest o niej komentarz w tym samym pliku): job Gitea Actions SAM działa w kontenerze, więc `docker run -v $PWD/...` demon rozwiązuje na HOŚCIE, gdzie tej ścieżki nie ma. Docker nie zgłasza wtedy błędu — po cichu tworzy PUSTY katalog, przez co skrypt „znika". Zamiast montowania wbudowujemy pliki w pomocniczy obraz (FROM engine-swisseph:ci + COPY). Kontekst builda jest strumieniowany do demona, więc działa niezależnie od tego, gdzie ten demon stoi. Obraz kasujemy po użyciu. Przy okazji .dockerignore: docker NIE czyta .gitignore, więc do demona poleciałby cały korzeń repo — z lokalnym wirtualenvem (344 MB) i jądrami efemeryd włącznie. Kontekst spada z 382 MB do 5,9 MB, co na runnerze z historią „no space left on device" nie jest kosmetyką. Plik dotyczy tylko buildów z korzenia repo — obrazy usług mają własne konteksty (services/<usługa>) i go nie widzą. Zweryfikowane bez dockera: sprawdzony dokładny tekst, jaki dostanie powłoka po dedentacji YAML (terminator heredoca w kolumnie 0), istnienie ścieżek COPY oraz to, że reguły .dockerignore nie wycinają plików potrzebnych do uruchomienia. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-04 23:20:43 +02:00
gitea	86a0f16f9e	test: framework porównania domów z wyrocznią + DWA błędy, które od razu wykrył ... Etap 0 planu egzotycznych systemów domów: zanim zaczniemy implementować Placidusa i spółkę, potrzebujemy narzędzia, które powie, czy wynik jest poprawny. Błąd w domach jest CICHY — wykres wygląda dobrze, tylko planety siedzą w złych domach. FRAMEWORK (tests/oracle): liczenie cuspów jako funkcja (RAMC, ε, φ), Swiss Ephemeris jako wyrocznia. Trzy decyzje projektowe, które okazały się kluczowe: - IZOLACJA: obu implementacjom podajemy TE SAME wejścia przez swe_houses_armc. Porównywanie „naszego horoskopu" z „horoskopem swissepha" mieszałoby różnice czasu gwiazdowego i ε z błędami domów — utonęlibyśmy w fałszywych alarmach. Czas gwiazdowy i ε mają własny test. - KRYTERIUM to liczba przypadków powyżej tolerancji (1″), max odchylenie I MIEJSCE, a nie procent zgodności. Procent ukrywa kształt błędu: „97%" nie odróżnia szumu zmiennoprzecinkowego od rogu dziedziny, w którym mylimy się o 30°. - GRANICE PER DATA: koło podbiegunowe nie jest stałą 66,56° — zależy od ε, które zmienia się z datą (23,75° w 370 p.n.e.), więc przesuwa się o ~0,3°. Uruchomiony na kodzie uchodzącym za poprawny, w PIERWSZYM przebiegu znalazł dwa realne błędy: 1. ASCENDENT O 180° ZA KOŁEM PODBIEGUNOWYM. `atan2` wybierał niewłaściwy punkt przecięcia ekliptyki z horyzontem — zwracaliśmy Descendent. Planety lądowały w PRZECIWNYCH domach dla całej północnej Skandynawii (Tromsø, Rovaniemi, Murmańsk), na ~11% przypadków przy tych szerokościach. Rozstrzyga położenie względem MC: punkt wschodzący leży w półkolu (0°,180°) na wschód od MC. 2. NIEDETERMINIZM WHOLE SIGN NA GRANICY ZNAKU. Ascendent o włos od granicy (359,999999999976 vs 1e-10 — ta sama wartość, różne strony) przerzucał dom I o 30°. Ten sam horoskop na innej maszynie dawał inny wynik. Przyciąganie do granicy przy 1e-9° (3,6 mikrosekundy łuku — poniżej realnej dokładności danych). Oba mają testy regresji w zwykłej suicie, więc są łapane też bez swissepha. Po poprawkach: build 0 przekroczeń, sweep 20 000 przypadków = 760 000 porównań, max odchylenie 0.000000000°. Istniejące suity bez regresji (logika 277+3, prez. 249). CI: krok BLOKUJĄCY w jobie swisseph-image, odpalany wewnątrz obrazu silnika B z zamontowaną warstwą logiczną. pyswisseph zostaje wyłącznie wyrocznią testową — nie wchodzi do zależności produktu, izolacja z LOG-27 nienaruszona. Dodane `cusps_for(ramc, eps, lat, system)` — kanoniczne wejście, w które Etap 1 będzie tylko dopisywał kolejne systemy. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-04 18:03:08 +02:00
gitea	dd32f7e82f	ci: odpalaj testy warstwy bazodanowej (dotąd nie były uruchamiane) ... Luka wyszła przy DAN-26 (#52): dodałem pierwsze testy w usłudze `data`, ale CI odpalało tylko `logic` i `presentation` — więc testy canary NIGDY by się nie wykonały. Nietestowany kod ochronny jest gorszy niż jego brak, bo daje złudzenie zabezpieczenia; tym bardziej nie może być testowany „na niby". - nowy job `data-tests` w tests.yml (wzorowany na presentation), - `services/data/requirements-dev.txt` (którego usługa nie miała). Sprawdzone lokalnie dokładnie tą komendą co w CI: 7 testów canary przechodzi. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-03 21:38:48 +02:00
gitea	56131b209a	ci: workflow budujacy obraz uslugi render (PRE-24) ... Luka: usluga render (services/render) weszla w #32, ale zaden workflow nie budowal jej obrazu — wiec astrololo-render:latest nie istnial w rejestrze, a pod zawislby na ImagePullBackOff po wdrozeniu manifestow. Osobny pipeline (jak build-swisseph), nie dopisanie do build.yaml: obraz dzwiga TeX Live (setki MB), a build.yaml chodzi przy KAZDYM pushu do mastera. Budowanie renderu za kazdym razem spowalnialoby kazdy deploy — a to wlasnie ta izolacja miala usunac. Wyzwalany tylko zmiana w services/render/**; workflow_dispatch do bootstrapu. Merge tego PR zbuduje pierwszy obraz (push dotyka pliku workflow, wiec trigger sie odpali) i wypchnie :latest — dopiero potem ma sens merge deploy#5. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 13:30:24 +02:00
gitea	487dbb8fd3	fix(ci): smoke test silnika B bez kontenera w tle i bez sieci ... Job „Build obrazu silnika B" padal na kazdym przebiegu po pierwszym: Conflict. The container name "/swe" is already in use Dwie wady starego kroku, obie moje: 1. startowal kontener w tle (docker run -d --name swe) i NIGDY go nie usuwal, wiec nazwa zostawala zajeta na runnerze i kolejne przebiegi sie wywalaly; 2. pukal curl-em w localhost:8003, podczas gdy job Gitea Actions sam dziala w kontenerze, a -p publikuje port na HOSCIE — to nie ten sam localhost, wiec health-check i tak nie mial prawa dojsc. Teraz test biegnie WEWNATRZ obrazu (docker run --rm ... python -), wolajac funkcje endpointow wprost. Omija oba problemy, nie zostawia niczego po sobie, a sprawdza to samo i wiecej: obraz sie zbudowal, pyswisseph liczy, komplet 13 obiektow, Slonce w oczekiwanym zakresie, SN = NN + 180. Dodany krok sprzatajacy osierocony kontener „swe" ze starych przebiegow. Zweryfikowane lokalnie na realnym pyswisseph: Sun=40.2102, NN=68.1530, 13 obiektow — zgodnie z wyrocznia. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-22 17:29:27 +02:00
gitea	752f477a27	feat(security): zamkniecie dostepu do baz interpretacyjnych (LOG-32) ... Bazy sa rdzeniem produktu i wlasnie zostaly kupione — a aplikacja nie miala ZADNEGO uwierzytelniania. Prezentacja to NodePort, wiec kazdy w LAN wchodzil bez logowania, a `/search` oddawal surowe wiersze do 50 000 na zapytanie. Bazy mogly wyjsc przez sama aplikacje, bez udzialu jakiegokolwiek LLM. - prezentacja: HTTP Basic (APP_USER/APP_PASSWORD) + limit zadan na IP (RATE_LIMIT_PER_MIN, domyslnie 120/min). Limit dziala TAKZE przed uwierzytelnieniem, zeby zgadywanie hasla i sondowanie API nie bylo darmowe. - logika i dane: token miedzywarstwowy X-Astrololo-Token (INTERNAL_TOKEN) — bez niego dalo sie ominac logowanie, uderzajac wprost w warstwe nizej. Warstwa danych oddaje surowe wiersze, wiec to najwrazliwszy punkt. - /search: gorny limit 50 000 -> 5000 (tyle realnie uzywa build_report). Publiczne /api/query zostaje na 200. - /health celowo publiczny (sondy k8s go nie uwierzytelnia). - swiadomie nie logujemy tresci zadan ani promptow — logi to kolejny nosnik. Fail-open przy braku konfiguracji (zgodnosc wstecz i dev), ale z GLOSNYM ostrzezeniem przy starcie, zeby nikt nie wdrozyl tego w przekonaniu, ze jest chroniony. Wlaczenie w produkcji wymaga ustawienia sekretow w repo deploy. Testy: 12 (prezentacja, nowy katalog + job w CI) i 5 (logika). Zweryfikowane na zywym stosie: bez hasla 401, z haslem 200, logika wprost bez tokenu 401, z tokenem 200, /health 200, limit 50000 odrzucony (422), a prezentacja nadal liczy horoskop przez logike. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-21 16:50:18 +00:00
gitea	ab6fc0722c	ci(swisseph): osobny workflow budujacy obraz silnika B ... Buduje i pushuje obraz gitea/astrololo-engine-swisseph (tag SHA + latest). Celowo oddzielony od build.yaml (data/logic/presentation) — odpala sie tylko przy zmianach w services/engine-swisseph/**, wiec obraz AGPL nie miesza sie do pipeline'u permisywnego produktu. workflow_dispatch pozwala zbootstrapowac pierwszy obraz recznie. Obraz konsumuje profil deployu astrololo-swisseph (repo deploy). Uwaga: pierwszy build zadziala dopiero po zmergowaniu poprawki Dockerfile (PR #3) — na masterze Dockerfile jeszcze sie nie buduje. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-21 00:10:55 +00:00
gitea	6ced2ddd22	fix workflows	2026-07-20 18:50:54 +00:00
gitea	9323803cb4	tt	2026-07-18 21:57:33 +02:00
gitea	73f39e7df8	build	2026-07-17 19:30:14 +02:00