feat(prezentacja): zapamiętane predykcje okresowe (PRE-22) + wymaganie o cache-bustingu #30

Merged
gitea merged 1 commits from feat/pre22-saved-predictions into master 2026-07-24 18:27:40 +00:00
Owner

Piąta wskazówka partnerów: Kalendarz ma pozwalać liczyć predykcje dla kilku
okresów
i je zachowywać, żeby wszystkie trafiły potem do raportu.

Stacked na #29 — baza to feat/qol-wheel-zoom, żeby nie było kolizji
numeracji wymagań (tam PRE-25 = powiększanie koła) ani konfliktu binarnego na
xlsx. Merge #29 najpierw; Gitea przekieruje wtedy bazę na master.

Magazyn

predictions.js trzyma predykcje w localStorage, tak jak wspólne dane
formularza (PRE-21): serwer zostaje bezstanowy — żadne dane urodzeniowe ani
treści z baz nie lądują po stronie usługi. Zakładka „Skompiluj" (PRE-23) odczyta
to samo miejsce przez window.astrololoPredictions — jedno źródło prawdy.

Trzy decyzje projektowe

Kluczem tożsamości jest okres. Ponowne policzenie tego samego zakresu
podmienia wpis zamiast dokładać duplikat — inaczej lista puchłaby przy każdej
próbie z innym modelem czy budżetem. Zapis jest przez to idempotentny, więc działa
też wariant bez strumienia (zapis przy wczytaniu strony z gotowym wynikiem)
i odświeżenie niczego nie mnoży.

progress.js ogłasza gotowy horoskop zdarzeniem, zamiast sam zapisywać —
to okno postępu, a nie magazyn. Filtr po profilu pilnuje, żeby interpretacja
natalna nie trafiła
na listę predykcji okresowych.

Przepełniony magazyn jest zgłaszany, nie połykany. Horoskopy bywają długie;
gdyby wynik znikał po cichu, użytkownik straciłby pracę bez śladu.

UI

Lista na Kalendarzu: okres, data zapisu, objętość, przycisk usuwania. Skrypt
podpięty w timeline.html (nie w base.html), żeby nie kolidować z #29.

Weryfikacja na żywej aplikacji

Dwa okresy zapisane → powtórzenie tego samego zakresu podmieniło wpis (dalej 2,
tekst zaktualizowany) → lista posortowana po dacie → predykcje przetrwały
przejście na inną zakładkę
i powrót → interpretacja natalna nie wpadła na
listę → usuwanie zmniejszyło licznik 2 → 1 i przerysowało listę.

14 nowych testów. Całość: prezentacja 101 passed.

Przy okazji: PRE-26 (cache-busting)

Dopisane wymaganie, o które pytałeś. Przy PRE-25 przeglądarka podała stary
styles.css
i powiększanie kosmogramu „nie działało", mimo że klasa była
nakładana. Objaw jest zdradliwy: szablony są nowe, więc strona wygląda na
zaktualizowaną, a funkcja po prostu milczy — po wdrożeniu może to spotkać
użytkowników
.

Zostaje

PRE-23 (zakładka Skompiluj) i PRE-24 (PDF przez LaTeX jako osobna usługa
render).

Piąta wskazówka partnerów: Kalendarz ma pozwalać liczyć predykcje dla **kilku okresów** i je zachowywać, żeby wszystkie trafiły potem do raportu. > **Stacked na [#29](https://gitea.czernobog.pl/gitea/astrololo/pulls/29)** — baza to `feat/qol-wheel-zoom`, żeby nie było kolizji > numeracji wymagań (tam PRE-25 = powiększanie koła) ani konfliktu binarnego na > xlsx. **Merge #29 najpierw**; Gitea przekieruje wtedy bazę na master. ## Magazyn `predictions.js` trzyma predykcje w **localStorage**, tak jak wspólne dane formularza (PRE-21): serwer zostaje **bezstanowy** — żadne dane urodzeniowe ani treści z baz nie lądują po stronie usługi. Zakładka „Skompiluj" (PRE-23) odczyta to samo miejsce przez `window.astrololoPredictions` — jedno źródło prawdy. ## Trzy decyzje projektowe **Kluczem tożsamości jest okres.** Ponowne policzenie tego samego zakresu **podmienia** wpis zamiast dokładać duplikat — inaczej lista puchłaby przy każdej próbie z innym modelem czy budżetem. Zapis jest przez to idempotentny, więc działa też wariant bez strumienia (zapis przy wczytaniu strony z gotowym wynikiem) i odświeżenie niczego nie mnoży. **`progress.js` ogłasza gotowy horoskop zdarzeniem**, zamiast sam zapisywać — to okno postępu, a nie magazyn. Filtr po profilu pilnuje, żeby **interpretacja natalna nie trafiła** na listę predykcji okresowych. **Przepełniony magazyn jest zgłaszany**, nie połykany. Horoskopy bywają długie; gdyby wynik znikał po cichu, użytkownik straciłby pracę bez śladu. ## UI Lista na Kalendarzu: okres, data zapisu, objętość, przycisk usuwania. Skrypt podpięty w `timeline.html` (nie w `base.html`), żeby nie kolidować z #29. ## Weryfikacja na żywej aplikacji Dwa okresy zapisane → powtórzenie tego samego zakresu **podmieniło** wpis (dalej 2, tekst zaktualizowany) → lista posortowana po dacie → predykcje **przetrwały przejście na inną zakładkę** i powrót → interpretacja natalna **nie** wpadła na listę → usuwanie zmniejszyło licznik 2 → 1 i przerysowało listę. **14 nowych testów.** Całość: **prezentacja 101 passed**. ## Przy okazji: PRE-26 (cache-busting) Dopisane wymaganie, o które pytałeś. Przy PRE-25 przeglądarka podała **stary `styles.css`** i powiększanie kosmogramu „nie działało", mimo że klasa była nakładana. Objaw jest zdradliwy: szablony są nowe, więc strona wygląda na zaktualizowaną, a funkcja po prostu milczy — **po wdrożeniu może to spotkać użytkowników**. ## Zostaje **PRE-23** (zakładka Skompiluj) i **PRE-24** (PDF przez LaTeX jako osobna usługa `render`).
gitea changed target branch from feat/qol-wheel-zoom to master 2026-07-24 16:48:45 +00:00
gitea added 1 commit 2026-07-24 16:48:45 +00:00
feat(prezentacja): zapamiętane predykcje okresowe (PRE-22) + wymaganie o cache-bustingu
build / build (push) Successful in 1m4s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 12m9s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Failing after 1m6s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 38s
Testy / Kontrola składni wszystkich warstw (push) Successful in 20s
8cc329ab17
Piata wskazowka partnerow: Kalendarz ma pozwalac liczyc predykcje dla KILKU
okresow i je zachowywac, zeby wszystkie trafily potem do raportu („Skompiluj",
PRE-23/24).

Nowy predictions.js — magazyn w localStorage, tak jak wspolne dane formularza
(PRE-21): serwer zostaje bezstanowy, zadne dane urodzeniowe ani tresci z baz nie
laduja po stronie uslugi. Zakladka „Skompiluj" odczyta to samo miejsce przez
window.astrololoPredictions (jedno zrodlo prawdy).

Decyzje projektowe:

- KLUCZEM TOZSAMOSCI JEST OKRES. Ponowne policzenie tego samego zakresu podmienia
  wpis zamiast dokladac duplikat — inaczej lista puchlaby przy kazdej probie
  z innym modelem albo budzetem. Dzieki temu zapis jest idempotentny, wiec dziala
  tez wariant bez strumienia (zapis przy wczytaniu strony z gotowym wynikiem)
  i odswiezenie niczego nie mnozy.
- progress.js OGLASZA gotowy horoskop zdarzeniem `astrololo:horoscope` z profilem,
  zamiast sam zapisywac. To okno postepu, a nie magazyn — zapisywanie zostaje
  odpowiedzialnoscia predictions.js. Filtr po profilu pilnuje, zeby interpretacja
  natalna nie trafila na liste predykcji okresowych.
- Przepelniony magazyn (horoskopy bywaja dlugie) jest ZGLASZANY uzytkownikowi,
  a nie polykany — inaczej wynik znikalby po cichu.

UI: lista zapamietanych predykcji na Kalendarzu — okres, data zapisu, objetosc
i przycisk usuwania. Skrypt podpiety w timeline.html (nie w base.html), zeby nie
kolidowac z rownolegle otwartym #29.

PRE-26 — dopisane wymaganie o wersjonowaniu plikow statycznych. Przy PRE-25
przegladarka podala STARY styles.css i powiekszanie kosmogramu „nie dzialalo",
mimo ze klasa byla nakladana. Objaw jest zdradliwy: szablony sa nowe, wiec strona
wyglada na zaktualizowana, a funkcja po prostu milczy. Po wdrozeniu moze to
spotkac uzytkownikow.

Weryfikacja na zywej aplikacji: dwa okresy zapisane; powtorzenie tego samego
zakresu podmienilo wpis (dalej 2, tekst zaktualizowany); lista posortowana po
dacie; predykcje przetrwaly przejscie na inna zakladke i powrot; interpretacja
natalna NIE wpadla na liste; usuwanie zmniejszylo licznik 2 -> 1 i przerysowalo
liste. Testy: 14 nowych. Calosc: prezentacja 101 passed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gitea merged commit 8cc329ab17 into master 2026-07-24 18:27:40 +00:00
gitea deleted branch feat/pre22-saved-predictions 2026-07-24 18:27:40 +00:00
Sign in to join this conversation.
No Reviewers
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gitea/astrololo#30