astrololo/docs/analiza-klient-2026-09.md

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,
• dosłane 2026-10-04: wznoszenie znaków ascensional times.xlsx i fidaria calculator.xls.

Architektura (trzy warstwy) zostaje bez zmian. Uwagi klienta o architekturze i stosie technologicznym są tu celowo pominięte.

Wnioski są naniesione do rejestru astrololo_wymagania.xlsx w tym samym PR. Każda zmiana — z wartością „było / jest", powodem i dowodem — jest w arkuszu „Zmiany 2026-10".

Legenda pewności: [kod] sprawdzone 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, a ten sam błąd zasila prompt do LLM. Dodatkowo wyszukiwanie ucina rekordy limitem 5000, więc część bazy w ogóle nie jest sprawdzana.
2. Specyfikacja (docx) to w ~90% wynik AI, którego klient jeszcze nie przejrzał (znacznik „{DOTĄD SPRAWDZONE}" w części 2 z 21). Służy jako skorowidz, nie jako wymagania.
3. Priorytety bierzemy z TO DO. Astrologia wedyjska, chińska i majańska występuje tylko w specyfikacji — trafiła do pytań (Q-15), nie do wymagań.
4. Wygląd i interfejs zapisane jako opcje do wyboru: język, motyw jasny obok obecnego ciemnego, kolorowanie, „symbol + skrót", styl koła.
5. Rejestr: 56 nowych wymagań, 103 zmiany w istniejących, 34 nowe pytania (Q-15…Q-48), 21 haseł słownika.
6. 17 statusów skorygowanych w dół. Te wiersze już w pierwotnej treści obiecywały funkcje, których w kodzie nie ma.
7. Pięć plików z docs/ celowo poza repozytorium — kupione bazy i dane osobowe (sekcja 7).

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, i o godnościach („well-dig. at B."), które w tym horoskopie nie są spełnione.

Mechanizm [kod]. _facet_samples w significators.py przepuszcza rekord, jeśli tekst jego sygnifikatora zawiera wszystkie tokeny fasetki (linia 82). Sprawdza więc, czy rekord wspomina te tokeny, a nie czy wszystkie jego warunki 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".
• Ignoruje dodatkowe warunki rekordu: inny znak, inny aspekt, kwalifikatory techniki („by dir.", „tr."), godności („at B.").
• Limit 5000 [kod]. Wyszukiwanie po tokenie planety jest ucinane do 5000 rekordów (main.py, excel_provider.py). Licznik „[Su: 5415 rekordów" jest liczony przed ucięciem, więc ok. 400 rekordów Słońca nigdy nie trafia do sprawdzania, a liczba w nagłówku nie odpowiada temu, co sprawdzono.

Ta sama funkcja obsługuje Kalendarz (interpret_events), a generator promptów (LOG-29/30) bierze dopasowania z tego samego build_report (main.py, prompt.py). Model z przekonaniem cytuje więc świadectwa, których w horoskopie nie ma.

W rejestrze:

• LOG-15 (parser) → „Do zrobienia";
• LOG-16 (atomy) i LOG-19 (wypis) → „W trakcie";
• kryteria odbioru naprawy, z przykładami klienta jako testami, są w LOG-19;
• ekran opisuje PRE-36;
• przypadek „rekord nie do oceny" — pytanie Q-35.

2. Czym są te 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 tabel. Arkusz ma też legendę kolorów [kod — odczyt stylów]:

• pomarańczowy = „muszę uzupełnić ten opis — lepiej poczekać": wiersze 24, 32–34, 37, 40, 42–45, 73–76, 79, 87, 89, 91, 92, 94, 96, 98, 100;
• żółty = „jeszcze w ogóle nie ugryzione — poczekać": wiersze 27 i 38.

Wymagania z tych wierszy mają w rejestrze dopisek „opis u klienta do uzupełnienia".

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. Ustalenia z formatowania [kod — odczyt XML]:

• Legenda cieniowania akapitów: pomarańczowy = „to jeszcze uzupełnię", żółty = „kompletnie do poprawki", łososiowy = „chyba out".
• Flagi występują tylko w częściach 1–2, a w części 2 — zaraz po „Accidental dignities" — stoi znacznik „{DOTĄD SPRAWDZONE}". Części 3–21 to nieprzejrzany wynik AI.
• Kolor „chyba out" nie występuje ani razu.
• Czerwona czcionka w częściach 1–2 to specyfikacja kolorów UI (osłabienia, domy kadentne, ujemne punkty), a nie znacznik „bzdura".
• Dokument jest urwany („TU WYWALIŁ BŁĄD" w części 11, „TU SIĘ SKOŃCZYŁ LIMIT WĄTKU" w części 21).
• Zawiera błędy merytoryczne, np. „0.5° Vigintile (1/40)" zamiast 18° (1/20). Arkusz „ASPECTS" w TO DO ma to poprawnie. Przy konflikcie źródłem prawdy jest xlsx.

3. Błędy w działającej aplikacji

TO DO	Prio	Zgłoszenie	Ocena	Rejestr
11	***	Interpretacje pokazują nieobecne sygnifikatory	[kod] potwierdzone, sekcja 1	LOG-15/16/19, PRE-36
9	***	Pliki 5 MB i 7,75 MB kończą się „Gateway Timeout"	[hipoteza] 504 zwraca proxy/ingress — w aplikacji nie ma limitu rozmiaru. Rozmiary pasują do astro19 version2026.xlsm (7,76 MiB) i Encyclopaedia of Medical Astrology (4,9 MiB). [kod] Nawet po usunięciu przekroczenia czasu domyślna reguła wgrywania przyjmuje tylko .xlsx (files.py), więc .xlsm zostanie odrzucony.	DAN-29, DAN-16 (→ Must)
9	***	Komunikat „nie nadaje się do użycia" dopiero przy ponownym wgraniu	Walidacja od razu po wgraniu + stały opis wymaganego układu	DAN-30, PRE-34
10	***	Brak listy wgranych plików	[hipoteza] Lista istnieje w astrololo (DAN-27). Klient pracuje najpewniej na astrokliencie, który z założenia jest „bez administracji".	PRE-35, Q-19, Q-21
12	***	Ekran „Sygnifikatory" — nie wiadomo, do czego służy	Wymaga wpisywania tokenów w składni bazy	PRE-37

4. Wygląd i interfejs — jako opcje do wyboru

Zgodnie z decyzją: zmiany wyglądu są opcjami, nie zamiennikami — obecny wygląd zostaje dostępny.

Wymaganie	Opcja
PRE-30	język interfejsu: angielski lub polski
PRE-31	motyw jasny obok obecnego ciemnego
PRE-32	kolorowanie komórek wg planet, znaków i aspektów
PRE-33	zapis „symbol + skrót" (☍ opp, ☉ Su, ♐ Sag)
PRE-49	zakotwiczenie koła: Asc / whole sign / Baran / Rak / Słońce / Księżyc
PRE-50	granice terminów i dekanatów na kole
PRE-51	styl linii aspektów

Wartości domyślne motywu i języka oraz zasięg przełącznika języka (wszystkie warianty? raporty LLM?) — pytania Q-17 i Q-18.

5. Co zostało naniesione do rejestru

Warstwa	Wymagania przed → po	Zrobione / W trakcie / Do zrobienia — przed	po
Dane	28 → 37	14 / 3 / 11	13 / 5 / 19
Logika	34 → 51	29 / 3 / 2	18 / 12 / 21
Prezentacja	29 → 59	27 / 1 / 1	23 / 5 / 31
Pytania otwarte	14 → 48

Korekty statusów (17)

Zasada: status opisuje to, co wiersz obiecuje w swojej pierwotnej treści. Lipcowy audyt czytał te wiersze łagodnie („rdzeń działa"). Obecny czyta je ściśle, z dowodem w kodzie dla każdej korekty.

• LOG-15 → Do zrobienia: parsera nie ma (moduł sam nazywa się zalążkiem).
• LOG-17 → Do zrobienia: brak obsługi „asp" / „asp+" / „asp-".
• LOG-16, LOG-19 → W trakcie: sekcja 1.
• LOG-20 → W trakcie: brak „as-is-in-chart" i liczby trafień.
• LOG-02 → W trakcie: brak gwiazd stałych oraz węzła i Lilith w wersji true.
• DAN-09 → W trakcie: efemerydy tylko głównych ciał, bez asteroid i gwiazd.
• LOG-03 → W trakcie: brak prędkości w % ruchu i konfigurowalnej stacji umownej.
• LOG-04, PRE-07 → W trakcie: brak zodiaku RA.
• LOG-06, PRE-06 → W trakcie: z aspektów pobocznych tylko 30/45/150°, jedna orba dla wszystkich, brak harmonik, poziomów dokładności i aspektu przez znak.
• LOG-07 → W trakcie: orb paraleli stały (1°), niekonfigurowalny.
• LOG-10 → W trakcie: tylko profekcje roczne; brak miesięcznych, dziennych, ciągłych i Lord of the Orb.
• LOG-12 → W trakcie: brak monthly revolutions.
• PRE-01 → W trakcie: brak listy lokalizacji domyślnych i domyślnej daty/godziny.
• PRE-04 → W trakcie: z technik relacyjnych tylko synastria; solariusz i lunariusz nie mają ekranu.

LOG-08 i LOG-14 zostają „Zrobione" — ich pierwotna treść jest spełniona: By Degree / By Sign, odwracanie i 7 Lots hermetycznych w lots.py; tabela technique | significator | start | exact | end w timeline.py. Nowy zakres klienta wydzielony do LOG-50 (Lots z listy klienta) i LOG-51 (docelowy format tabeli predykcji).

Priorytety podniesione (13, nigdy nie obniżane)

• Dane: DAN-06 (orby), DAN-07 (czasy wznoszenia), DAN-08 (Lots), DAN-10 (katalog aspektów), DAN-16 (.xlsm).
• Logika: LOG-07, LOG-10, LOG-11, LOG-12, LOG-13, LOG-17.
• Prezentacja: PRE-06, PRE-08.

Wszystkie na Must, zgodnie z *** u klienta albo zależnością od naprawy z w.11.

Nowe wymagania według tematów

• Wgrywanie i bazy: DAN-29 (duże pliki), DAN-30 (walidacja od razu), PRE-34, PRE-35, PRE-37.
• Horoskopy i dane wejściowe:
  • DAN-31 i PRE-40: kopiuj/wklej;
  • DAN-32: format Zet;
  • DAN-33 i PRE-41: lokalizacje domyślne;
  • LOG-38 i PRE-38: strefa z DST, UT, czas gwiazdowy;
  • PRE-39: zapisane horoskopy.
• Aspekty i orby: LOG-37 (daty dokładności, tabela ASPECT LIST), PRE-43, PRE-44, PRE-45 i macierz orbów w zmianach DAN-06, LOG-06, PRE-06.
• Synastria: LOG-42 (obliczenia z pełnymi ustawieniami), PRE-46–48 (dane obu osób, tabela A–aspekt–B, koło podwójne, pełny kwadrat aspektów).
• Tabele:
  • LOG-36: godności i faza;
  • LOG-39 i PRE-53: dane obiektów;
  • LOG-40 i PRE-52: tabela stopni;
  • LOG-41: midpointy;
  • PRE-59: godziny planetarne, syzygia, żywioły, asteroidy.
• Predykcja:
  • LOG-35: Firdaria — wariant i pełny cykl, sekcja 6;
  • LOG-43: tranzyty;
  • LOG-44: ingresy, okresy cienia, OOB, lunacje;
  • LOG-45: progresje sekundarne;
  • LOG-46: Days of the Moon;
  • LOG-51 i PRE-54: zunifikowana tabela;
  • PRE-55: tabele technik okresowych.
• Poza astrologią zachodnią (niski priorytet): numerologia (LOG-47, DAN-35, PRE-56), chiromancja i fizjonomika (LOG-48, PRE-57), Astro*Carto*Graphy (LOG-49), atlasy medyczny i historyczny (DAN-36, PRE-58).
• Luka w rejestrze uzupełniona: DAN-28 (lustro baz w SQL). Numer był już używany w kodzie (services/data/requirements.txt, commit 003deb9) i w repo deploy, ale w rejestrze go brakowało.

6. Dosłane materiały

Czasy wznoszenia znaków (wznoszenie znaków ascensional times.xlsx)

• Tabela © 2004 The Golden Hind Press: szerokości 0–66° N, wartości w stopniach i minutach (1° = 1 rok życia), pary znaków o równym czasie.
• Sprawdzone wzorem [kod] (wznoszenie skośne): przy nachyleniu ekliptyki ok. 23,4465° (wartość z ok. 1945 r.) zgadza się do 0,6′ w 305 z 306 komórek.
• Jedna literówka: 40°, Lew/Skorpion — w tabeli 38°20′, powinno być 38°02′ (tylko ten wiersz nie sumuje się do 180°).
• Tabela nie wystarcza do algorytmu z TO DO w.57–65: brak szerokości ułamkowych (dla Warszawy odczyt z wiersza 52° myli się o ok. 7 tygodni), półkuli południowej i pasa 66,6°–78,5°, gdzie część znaków ma czasy ujemne.
• Rekomendacja: liczyć wzorem, a tabelę trzymać jako wyrocznię testów (DAN-07, LOG-13). Decyzja i rozbieżności spec ↔ TO DO — pytania Q-37…Q-41.
• Gotowe elementy w kodzie: _ascensional_difference i mean_obliquity w houses.py.

Kalkulator firdarii (fidaria calculator.xls)

• Arkusz liczy okresy z samej daty urodzenia, w trzech wariantach obok siebie: dzienny, nocny Zollera (węzły zaraz po Marsie — poleca go autor arkusza) i nocny Abu Ma'shara (węzły na końcu).
• Nasz firdaria.py zgadza się z arkuszem [kod] w wariancie dziennym i nocnym Abu Ma'shara: 51/51 władców okresów na przykładzie z arkusza. Daty różnią się w 2 z 51 wierszy — inna długość roku: 365,2422 u nas, 365,2425 w arkuszu.
• Braki:
  • wariant Zollera — dla przykładowego urodzenia nocnego z 1984 r. daje dziś inny okres (Węzeł Południowy zamiast Słońca);
  • liczenie po 75. roku życia — arkusz zaczyna cykl od nowa, u nas wynik się kończy;
  • ręczny wybór sekty.
• W rejestrze: LOG-35 (wariant do wyboru, pełny cykl, test referencyjny na danych arkusza), Q-42 (wariant domyślny).

7. Pliki poza repozytorium

Do repo trafiła cała zawartość docs/ poza pięcioma plikami, dopisanymi do .gitignore:

• Kupione bazy interpretacji: astro19 version2026.xlsm (ok. 50 tys. rekordów), The Encyclopaedia of Medical Astrology…xlsx (ok. 54 tys., na bazie książki Cornella), astro-excel4_4parser2.xlsm.
• Eksport opisów z baz: interpretacje.xlsx (444 opisy).
• Dane osobowe: kosmogramy z astro2019.xlsx — dane urodzeniowe ok. 49 prawdziwych osób.

Powód: pułapki (DAN-26) działają tylko wtedy, gdy każda kopia baz ma inne markery, a kopia w gicie trafiłaby do każdego klona i runnera CI. Historii gita praktycznie nie da się wyczyścić. lots astroseek.xlsx i lots astroseek 2.xlsx są identyczne — oba w repo, bo leżały w docs/.

8. Pytania do klienta

Pełna lista w arkuszu „Pytania otwarte" (Q-15…Q-48). Najważniejsze:

• Q-15 — czy astrologia wedyjska, chińska i majańska to zakres;
• Q-16 — kiedy będą przejrzane części 3–21 specyfikacji;
• Q-17, Q-18 — domyślny motyw i język, zasięg przełącznika języka;
• Q-19 — na którym wariancie i koncie widać problemy z wgrywaniem;
• Q-26 — reguły łączenia orbów i bonus świateł;
• Q-35 — co pokazywać przy rekordach nie do oceny;
• Q-37…Q-41 — czasy wznoszenia: tabela czy wzór, zamiana na datę, skrajne szerokości, małe lata Wenus;
• Q-42 — wariant firdarii nocnej;
• Q-43…Q-46 — techniki z opisem „do uzupełnienia": ZR, Annual Divisions, Days of the Moon, Solar Monthly Revolutions.

9. Proponowana kolejność

1. Naprawa dopasowania sygnifikatorów (LOG-15/16/19, PRE-36). Psuje Interpretacje, Kalendarz i prompt do LLM; dopóki działa źle, każda funkcja na nim dziedziczy błąd.
2. Wgrywanie plików (DAN-29/30, DAN-16, PRE-34/35) — klient nie może wgrać własnych baz.
3. Horoskopy, kopiuj/wklej, lokalizacje domyślne (DAN-31–33, PRE-39–41) — codzienna wygoda, ***.
4. Orby i aspekty (DAN-06, LOG-06, PRE-43/45), potem synastria (LOG-42, PRE-46–48) — synastria korzysta z tych samych orbów.
5. Opcje wyglądu (PRE-30–33, 49–51) razem z porządkowaniem wariantów astrololo / astroklient / astrodemo, żeby nie robić tego trzy razy.
6. Dalej techniki z *** według TO DO. Wiersze oznaczone u klienta kolorem „do uzupełnienia" — po uzupełnieniu opisu.