Files
astrololo/docs/analiza-klient-2026-09.md
T
gitea 1c68ca04f6
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m38s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m29s
Testy / Testy warstwy bazodanowej (ochrona baz) (push) Successful in 9m25s
Testy / Testy astrodemo (push) Successful in 9m25s
Testy / Testy astroklient (push) Successful in 9m25s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 5s
Testy / Kontrola składni wszystkich warstw (push) Successful in 5s
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m19s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m29s
Testy / Testy warstwy bazodanowej (ochrona baz) (pull_request) Successful in 9m25s
Testy / Testy astrodemo (pull_request) Successful in 9m25s
Testy / Testy astroklient (pull_request) Successful in 9m25s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 12s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 5s
docs: analiza materiałów od klienta (wrzesień 2026)
Co z nowych dokumentów dochodzi do wymagań, co trzeba zmienić i w jakiej
kolejności. Najważniejsze ustalenie, potwierdzone w kodzie: dopasowanie
sygnifikatorów (_facet_samples) sprawdza tylko, czy rekord zawiera
tokeny, a nie czy jego warunki są spełnione — stąd zgłoszone przez
klienta fałszywe interpretacje, które trafiają też do promptu LLM.

Rejestr wymagań celowo bez zmian do czasu akceptacji analizy.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 20:15:39 +02:00

147 lines
15 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Analiza materiałów od klienta — wrzesień 2026
Źródła:
- `astro parser TO DO LIST 2026-09-05.xlsx` — dalej **TO DO**,
- `astro parser_2026-09-13.docx` — dalej **specyfikacja**.
Architektura (trzy warstwy) zostaje bez zmian. Uwagi klienta o architekturze i stosie technologicznym są tu celowo pominięte.
Legenda pewności: **[kod]** sprawdzone w kodzie · **[rejestr]** status z `astrololo_wymagania.xlsx`, niezweryfikowany w kodzie · **[hipoteza]** wniosek z objawów, niesprawdzony.
## TL;DR
1. **Interpretacje pokazują sygnifikatory, których w horoskopie nie ma.** Klient ma rację, mechanizm potwierdzony w kodzie. To nie nowe wymaganie, tylko błąd w działającej funkcji — i ten sam błąd zasila prompt do LLM.
2. **Specyfikacja (docx) to w ~90% wynik AI, którego klient jeszcze nie przejrzał.** W części 2 z 21 stoi znacznik „{DOTĄD SPRAWDZONE}". Nie traktować jej jako wymagań — to skorowidz do sprawdzania algorytmów.
3. **Prawdziwą listą priorytetów jest TO DO (xlsx).** Astrologia wedyjska, chińska i majańska występuje wyłącznie w specyfikacji; w TO DO jej nie ma.
4. **Trzy zmiany przekrojowe:** interfejs po angielsku, wyłącznie jasny motyw z kolorowaniem, tabele w formie „symbol + skrót".
5. **Część pozycji z TO DO już istnieje** (paralele, draconic, stacje, profekcje, zbiorcza tabela predykcji) — klient może o tym nie wiedzieć albo chce innego formatu.
## 1. Interpretacje działają źle (potwierdzone w kodzie)
**Zgłoszenie (TO DO, wiersz 11, \*\*\*).** Pod nagłówkiem „Sun w Taurus" pojawia się rekord „Sun in Gemini or Sagittarius, in square or opposition the Moon", choć żaden z warunków nie zachodzi. Fasetka „koniunkcja z Moon — 84 dopasowań" zbiera każdą koniunkcję czegokolwiek z Księżycem. Pokazują się też rekordy o dyrekcjach („by dir."), których nie liczymy, oraz o godnościach („well-dig. at B."), które w tym horoskopie nie są spełnione.
**Mechanizm [kod].** `_facet_samples` w [significators.py](../services/logic/app/significators.py#L70) przepuszcza rekord, jeśli tekst jego sygnifikatora *zawiera* wszystkie tokeny fasetki ([linia 82](../services/logic/app/significators.py#L82): `if not all(t in low for t in toks)`). Sprawdza więc, czy rekord *wspomina* te tokeny, a nie czy *wszystkie warunki rekordu* są spełnione w horoskopie. Skutki:
- Nie rozróżnia, **która** planeta jest w aspekcie. Rekord `[Ve [conj [Mo … [Su in 7th H.` trafia do fasetki „Słońce w koniunkcji z Księżycem", bo zawiera `[Su`, `[conj` i `[Mo`.
- Ignoruje **dodatkowe warunki** rekordu: inny znak („Gem or Sag"), inny aspekt („sq or opp"), kwalifikatory techniki („by dir.", „tr."), godności („at B.").
- „[Su: 5415 rekordów" w nagłówku to `planet_total` — liczba wszystkich rekordów wspominających Słońce, bez żadnego dopasowania.
Ta sama funkcja obsługuje ścieżkę kalendarza ([`interpret_events`](../services/logic/app/significators.py#L265)), więc wada dotyczy obu ekranów.
**Dlaczego to pilne.** Generator promptów (LOG-29/30) bierze dopasowania z tego samego `build_report` ([main.py](../services/logic/app/main.py#L338), [prompt.py](../services/logic/app/prompt.py#L66)), a prompt każe modelowi popierać każdą tezę konkretnym sygnifikatorem. Model z przekonaniem cytuje więc świadectwa, których w horoskopie nie ma.
**Rozbieżność z rejestrem.** LOG-15, LOG-16 i LOG-19 mają status „Zrobione", a docstring modułu sam nazywa ten kod „Zalążkiem LOG-15/16". Statusy do korekty.
**Co trzeba zrobić.** Prawdziwy ewaluator zamiast dopasowania tokenów: rozbiór sygnifikatora na drzewo warunków (koniunkcja klauzul, alternatywy „or", kwalifikatory techniki i godności) i sprawdzenie każdej klauzuli względem atomów policzonych dla horoskopu. Rekord z warunkiem, którego nie umiemy sprawdzić (dyrekcje, godności), ma zostać odrzucony albo oznaczony „nie do oceny" — nigdy pokazany jako trafienie. Przypadek testowy wprost od klienta: rekord z „by dir." nie może się pojawić w interpretacji natalnej.
## 2. Czym są te dwa dokumenty
**TO DO (xlsx)** to właściwa lista robocza: arkusz „LISTA TO DO" z priorytetami (\*\*\* / \*\* / \* / brak = na tym etapie niekonieczne) oraz 16 arkuszy-wzorców z przykładowymi tabelami (tabela stopni, synastria, lista aspektów, profekcje, tranzyty, asteroidy, dane obiektów, godziny planetarne, syzygia, żywioły, orby, obiekty). Ostatnia poprawka: 05.09.2026.
**Specyfikacja (docx)** to „Kompletna specyfikacja techniczna" w 21 częściach. Według klienta to efekt ponad 20 godzin pracy z agentem AI, wciąż niedokończony; ma być czytana razem z TO DO. Ustalenia z formatowania dokumentu [kod — odczyt XML]:
- **Legenda kolorów** (cieniowanie akapitów): pomarańczowy = „to jeszcze uzupełnię", żółty = „kompletnie do poprawki", łososiowy = „chyba out".
- Flagi występują **tylko w częściach 1–2**. W części 2, zaraz po „Accidental dignities", stoi znacznik **„{DOTĄD SPRAWDZONE}"**. Wszystko dalej — części 3–21: aspekty, Lots, midpointy, astrologia wedyjska, gwiazdy stałe, wszystkie techniki predykcyjne, dashy, numerologia, chiromancja — to **nieprzejrzany wynik AI**.
- Kolor „chyba out" nie występuje ani razu: nic nie jest jeszcze wykreślone.
- „Do poprawki" dotyczy formatu tabeli orbów (1.2). To zgodne z niespójnością tej tabeli: Słońce i Księżyc mają w niej 8°, a obok stoi „+2° bonusu dla świateł" — nie wiadomo, czy bonus jest już wliczony.
- Czerwona czcionka w częściach 1–2 to **specyfikacja kolorów UI** (osłabienia, domy kadentne i ujemne punkty na czerwono), a nie znacznik „bzdura".
- Dokument jest urwany: „TU WYWALIŁ BŁĄD, KONTYNUACJA" w części 11 i „TU SIĘ SKOŃCZYŁ LIMIT WĄTKU" w części 21.
**Specyfikacja zawiera błędy merytoryczne.** Lista aspektów pobocznych w części 1.2 podaje np. „0.5° Vigintile (1/40)" i „11.25° Undecile? (1/32)". W rzeczywistości vigintyl to 18° (1/20), a undecyl 32,73° (1/11) — arkusz „ASPECTS" w TO DO ma te wartości poprawnie. **Przy konflikcie źródłem prawdy jest xlsx; specyfikację traktujemy jako skorowidz do weryfikacji.**
## 3. Błędy w działającej aplikacji (to nie są nowe wymagania)
| TO DO | Prio | Zgłoszenie | Ocena |
|---|---|---|---|
| 11 | \*\*\* | Interpretacje pokazują nieobecne sygnifikatory | **[kod]** potwierdzone — sekcja 1. |
| 9 | \*\*\* | Pliki 5 MB i 7,75 MB kończą się „Gateway Timeout" | **[hipoteza]** Odpowiedź 504 zwraca proxy/ingress, nie aplikacja — w warstwach prezentacji i danych nie ma limitu rozmiaru. Do sprawdzenia w repo deploy (timeout ingressu, limit rozmiaru żądania). |
| 9 | \*\*\* | Komunikat „przyjęty, ale nie nadaje się do użycia" pojawia się dopiero przy ponownym wgraniu | Walidacja struktury powinna iść od razu po wgraniu, razem z opisem wymaganego układu kolumn (najlepiej jako stała podpowiedź w UI). |
| 10 | \*\*\* | Brak listy wgranych plików (usuń / sprawdź / aktywuj) | **[hipoteza]** DAN-27 i PRE-09 mają status „Zrobione". Klient najpewniej pracuje na wariancie albo koncie bez tej zakładki: astroklient jest z założenia „bez administracji" (commit 10970c5), a zakładki są bramkowane uprawnieniami (PRE-27). Ustalić, gdzie to widać. |
| 12 | \*\*\* | Ekran „Sygnifikatory" — nie wiadomo, do czego służy | UX: ekran wymaga wpisywania tokenów w składni bazy. Potrzebny opis i podpowiedzi albo przeprojektowanie. |
## 4. Zmiany przekrojowe
- **Interfejs po angielsku (TO DO 6, \*\*\*).** Cały obecny interfejs jest po polsku. Dotyczy wszystkich trzech wariantów (astrololo, astroklient, astrodemo) — najlepiej zrobić to jednym mechanizmem i18n przy okazji porządkowania wariantów, a nie trzy razy.
- **Jasny motyw i kolorowanie (TO DO 7, \*\*\*).** Bez trybu ciemnego. Kolory komórek dla grup aspektów, żywiołów znaków i planet; tło komórki to bardzo jasna wersja koloru.
- **„Symbol + skrót" w tabelach (TO DO 8, \*\*).** `☍ opp`, `☉ Su`, `♐ Sag` — nigdy pełne nazwy. Rozstrzyga pytanie Q-05 i jest zgodne z DAN-18 (Unicode jako tekst, nie emoji).
## 5. Mapowanie TO DO na rejestr wymagań
Statusy według rejestru **[rejestr]**, o ile nie zaznaczono inaczej.
### Istnieje w rejestrze — klient podnosi priorytet albo doprecyzowuje
| TO DO | Prio | Temat | ID | Status | Co się zmienia |
|---|---|---|---|---|---|
| 19–20 | \*\*\* | Baza HOROSCOPES: zapis, ulubione, ostatnie, kopiuj/wklej | DAN-04 | Do zrobienia | Realnie pierwsza kolejka. Kopiowanie i wklejanie w formacie czytelnym bez kodu (TSV albo „;"). |
| 23 | \*\* | Baza SUBHOROSCOPES (relacje: mąż, dziecko, ślub…) | DAN-05 | Do zrobienia | Klient podaje schemat: ID = ImięNazwiskoData (+ litera przy powtórce), pola TYPE i SUBJECT. |
| 24 | \*\*\* | Orby per obiekt × per aspekt | DAN-06, PRE-06 | Do zrobienia / Zrobione | Dziś jedna orba + bonus świateł. Potrzebna macierz; arkusz ORBS dokłada „metody" według autorów i szkół. |
| 25–26 | \*\*\* / \*\* | Obiekty do wyświetlania: trzy przełączniki na obiekt, bez odświeżania strony | PRE-08 | Do zrobienia | Pokaż na kole / rysuj aspekty / pokaż w aspektarianie. |
| 27, 56–65 | \*\*\* | Ascensional times + minor planetary years + kombinacje | LOG-13, DAN-07 | Do zrobienia | Z „Could" na \*\*\*. Pełny algorytm: reguła Valensa, „model A" Patricka Watsona, ułamki 1/3, 1/2 i 2/3, pomijanie znaków powyżej 66° i 78° szerokości. |
| 28–31 | \*\*\* | Synastria — przebudowa | PRE-04 | Zrobione | **[kod]** Dziś bez wyboru lokalizacji (strefa i współrzędne wpisywane ręcznie), jedna orba, aspekty poboczne włączane hurtem. Potrzebne: pełne dane obu osób, orby per aspekt, wynik „obiekt A — aspekt — obiekt B", bi-wheel (A w środku, B na zewnątrz) przełączany z widokiem obok siebie, pełny kwadrat aspektów zamiast trójkąta. |
| 35–36 | \*\*\* / \* | Wybór aspektów z grupami + okno aspektów pobocznych | PRE-06 | Zrobione | Przyciski major / hard / soft / minor medical; okno aspektów pobocznych z sortowaniem według stopni i harmonik. |
| 41 | \*\*\* | Stacje: poprzednia i następna — dni, data, stopień, link | LOG-03 | Zrobione | Dodatkowe pola, flaga „< 7 dni", hiperłącze do horoskopu na moment stacji. |
| 44 | \*\*\* | Lots z `lots astroseek.xlsx` | LOG-08, DAN-08 | Zrobione / W trakcie | Odwracanie formuły w nocy + warunki specjalne (klient uzupełni). |
| 52–54 | \*\*\* | Zunifikowana tabela predykcji, kopiowana do Excela jako jedna tabela | LOG-14 | Zrobione | Format kolumn według arkusza „transits, predictive"; typy event / period / mundane. |
| 85 | \*\*\* | Firdaria | LOG-11 | W trakcie | Klient odsyła do `fidaria calculator.xls`, którego nie ma w przekazanych plikach. |
| 87, 89, 91–93 | \*\*\* | Zodiacal Releasing, Annual Divisions, Days of the Moon, Solar Monthly Revolutions, Lord of the Orb | LOG-11, LOG-12 | W trakcie / Zrobione | Lord of the Orb w dwóch wariantach (mod 84 i mod 12). |
| 96 | \*\* | Primary Directions | LOG-09 | Do zrobienia | Pytanie Q-02 nadal otwarte. |
### Już jest — klient może o tym nie wiedzieć
| TO DO | Prio | Temat | ID |
|---|---|---|---|
| 37 | \*\*\* | Paralele i kontrparalele | LOG-07 (Zrobione) |
| 40 | — | Zodiak drakoniczny | LOG-04 (Zrobione; **[kod]** draconic w `chart.py`) |
| 45 | — | Solariusze, lunariusze | LOG-12 (Zrobione) |
### Nowe — nie ma ich w rejestrze
**Dane horoskopu i wejście:**
- nazwa strefy czasowej i informacja o DST, np. CEST (TO DO 14, \*\*\*); UT/GMT oraz lokalny czas gwiazdowy (15–16, \*);
- wklejanie danych w formacie Zet Astroprocessor (21, \*\*\*);
- kilka zapisanych lokalizacji domyślnych z edycją listy (22, \*\*\*).
**Koło horoskopu (rozszerzenia PRE-12):**
- zakotwiczenie: Asc / whole sign / Baran / Rak / Słońce / Księżyc (32);
- granice terminów i dekanatów w kolorach, symbol planety po najechaniu kursorem (33);
- style linii aspektów: pogrubiona = applying ≤ 3°, bardzo gruba = applying ≤ 1°, przerywana = separating; kolory i grubości konfigurowalne (49, \*\*\*).
**Tabele:**
- tabela stopni 30 × 12 z podglądem „zoom" wybranego stopnia (50, \*\*\*);
- tabela aspektów przez cały znak, out-of-sign, dokładność (34, \*\*\*);
- midpointy (38, \*);
- długość ekliptyczna w kilku formatach (46, \*).
**Techniki predykcyjne (\*):** progresje sekundarne, ingresy, okresy cienia retrogradacji, ekstrema szerokości ekliptycznej, OOB, fazy Księżyca i zaćmienia (73–83); profekcje ciągłe z wyborem klucza (94, \*\*).
**Poza astrologią zachodnią** (bez gwiazdek albo z jedną): numerologia (100, \*\*) z gotowym schematem tabeli wynikowej, chiromancja (101, \*), czytanie twarzy i sylwetki (102, \*), atlas medyczny i atlas historycznych krain (103–104), Astro\*Carto\*Graphy (98).
**Tylko w specyfikacji, nie ma w TO DO:** cała astrologia wedyjska (wargi D-N, 13 systemów dash, karaki, argala, shadbala, ashtakavarga, yogi), chińska (BaZi, Zi Wei, Xiu), majańska (Tzolkin) i setki nazwanych asteroid. **Do potwierdzenia z klientem, czy to w ogóle zakres.** Uwaga techniczna: numerowane asteroidy wymagają plików efemeryd Swiss Ephemeris, czyli silnika `engine-swisseph` (izolacja AGPL według LOG-27) — nasz silnik Skyfield ich nie policzy.
## 6. Brakujące materiały
Klient się na nie powołuje, ale nie ma ich w przekazanych plikach:
- `wznoszenie znaków ascensional times.xlsx` (TO DO 56) i plik „wrzucony na dysk" (27);
- `fidaria calculator.xls` (85);
- dokończenie specyfikacji od części 21 (urwana) oraz przegląd części 3–21.
## 7. Pytania do klienta
1. Czy część wedyjska, chińska i majańska ze specyfikacji to zakres, czy tylko efekt uboczny pracy z AI? W TO DO jej nie ma.
2. Interfejs po angielsku: we wszystkich trzech wariantach czy tylko w wersji dla klienta? Czy dotyczy to też raportów — prompt do LLM jest dziś po polsku (LOG-29)?
3. Na którym wariancie i koncie widać brak listy plików (TO DO 10)?
4. Tabela orbów: czy bonus +2° dla świateł dolicza się do wartości z tabeli, czy jest już w nich zawarty?
5. Kiedy będą przejrzane części 3–21 specyfikacji — i czy do tego czasu traktujemy je jako nieobowiązujące?
## 8. Proponowana kolejność
1. **Naprawa dopasowania sygnifikatorów** (sekcja 1). Psuje Interpretacje, Kalendarz i prompt do LLM; dopóki działa źle, każda funkcja budowana na nim dziedziczy błąd.
2. **Błędy wgrywania plików** (TO DO 9–10) — klient nie może wgrać własnych baz.
3. **Baza HOROSCOPES, kopiuj/wklej, lokalizacje domyślne** (19–22) — codzienna wygoda, priorytet \*\*\*.
4. **Synastria** (28–31) i **orby per obiekt × aspekt** (24) — orby są wspólne dla obu.
5. **Zmiany przekrojowe UI** (angielski, jasny motyw, „symbol + skrót") razem z porządkowaniem wariantów astrololo / astroklient / astrodemo, żeby nie robić tego trzy razy.
6. Dalej techniki z \*\*\* według TO DO; specyfikację dopiero po jej przejrzeniu przez klienta.
Rejestr `astrololo_wymagania.xlsx` celowo **nie** jest zmieniany w tym PR. Najpierw akceptacja tej analizy, potem naniesienie zmian — zgodnie z zasadą „przegląd → poprawki → akceptacja → kod".