HIGI

Logika silnika i źródło prawdy

Skąd plan pacjenta bierze treść i jak warstwy uprawnień (superadmin → gabinet → higienistka) na siebie nachodzą. Strona robocza dla zespołu.

Cel, który ustalamy: źródłem prawdy jest ankieta admina (Asia / superadmin). Gabinet dziedziczy ją i dostosowuje w granicach swoich uprawnień, higienistka dziedziczy po gabinecie (lub globalnie, gdy solo) i — jeśli jej wolno — robi własne zmiany. Z tego powstaje jedna „efektywna ankieta", którą czyta silnik i generuje plan pacjenta. Excel ma zniknąć jako źródło treści.
Jak to ma działać

Graf: od ankiety admina do planu pacjenta

Treść spływa z góry na dół. Każda warstwa może coś zmienić tylko w granicach uprawnień. Plakietka po prawej = kto edytuje daną warstwę.

Warstwa 1 · źródło prawdyAnkieta globalna
Pełna ankieta: pytania, bloki, warunki, zalecenia, produkty, rutyny. W bazie: dokładnie jeden wiersz scope=global.
🔒 superadmin (Asia)
Edytuje tylko platforma-admin (lista 4 maili). /api/templates/global · draft → publish jest na DEV
dziedziczy ↓
Warstwa 2Szablon gabinetu
Gabinet dziedziczy globalną i dostosowuje pod siebie = standard kliniki. Dwa przełączniki: narzucaj/proponuj oraz czy higienistka może mieć własny.
🏢 manager gabinetu
scope=gabinet, template_mode, allow_member_private_template model jest
dziedziczy ↓
Warstwa 3Szablon higienistki
Solo: bazuje na globalnej. W gabinecie: bazuje na szablonie gabinetu. Własne zmiany tylko jeśli wolno (solo — zawsze; członek — gdy gabinet pozwoli).
👩‍⚕️ higienistka
scope=user · /api/templates/mine · draft → publish jest na DEV (solo)
scalenie warstw: USER ▸ GABINET ▸ GLOBAL ↓
WynikEfektywna ankieta
Jedna gotowa ankieta dla konkretnej higienistki — po nałożeniu jej zmian na gabinet i globalną. To ona ma karmić silnik.
⚙️ system
Publiczny odczyt opublikowanej wersji do zrobienia (E2c)
+ odpowiedzi pacjenta z ankiety (zostają w przeglądarce — RODO)
GenerowanieSilnik → Plan pacjenta
Silnik łączy efektywną ankietę z odpowiedziami pacjenta i tworzy spersonalizowany plan (HTML / PDF). Liczy się w przeglądarce — żadne dane pacjenta nie idą na serwer.
🦷 pacjent
Dostaje plan do domu
jest na DEV — działa, zweryfikowane do zrobienia — brakujące ogniwo
Uprawnienia

Kto co edytuje — i czym to jest egzekwowane

Tożsamość („kim jesteś") pochodzi z Clerk. Uprawnienie („co wolno") liczy serwer (Worker + baza D1) na podstawie roli — front tylko pokazuje/chowa.

RolaCo może edytowaćCzego nie możeSkąd autoryzacja
🔒 Superadmin
(Asia + 3 maile)
Warstwę globalną = ankietę-źródło dla wszystkich. Panel admina: treść, gabinety, „darmowe miesiące", maile. Tabela platform_admins (lista maili) + assertCanEditGlobal w Workerze.
🏢 Manager gabinetu Szablon swojego gabinetu (na bazie globalnej). Ustawia, czy narzuca go zespołowi i czy higienistka może mieć własny. Nie rusza warstwy globalnej ani innych gabinetów. Rola owner w account_members (lustro Clerk Organizations).
👩‍⚕️ Higienistka Swój własny szablon — solo zawsze; członek gabinetu tylko gdy gabinet na to pozwoli. Nie rusza globalnej ani cudzych. Członek z zablokowanym własnym szablonem korzysta z gabinetowego. Rola member + flaga allow_member_private_template gabinetu.
🦷 Pacjent Wypełnia ankietę u higienistki, dostaje plan. Nic nie edytuje. Jego dane nie trafiają na serwer. Brak konta — wszystko w przeglądarce.
Dlaczego dziś Excel — i czego brakuje

Stan dziś vs cel

Edytor i baza już są (warstwa zapisu). Brakuje strony odczytu: żeby silnik czytał efektywną ankietę z serwera zamiast z Excela.

● Dziś

📊 Excel (snapshot treści Asi)
↓ czyta
⚙️ Silnik → plan pacjenta
— — — brak połączenia — — —
✏️ Edytor (global / solo) → 💾 baza D1

Edytor zapisuje treść na serwer, ale silnik tego nie czyta — bierze plan ze starego snapshotu Excela. Dwa rozłączone światy: edycje nie zmieniają planu pacjenta.

● Cel

✏️ Ankieta admina → 🏢 gabinet → 👩‍⚕️ higienistka
↓ scalenie
📋 Efektywna ankieta (z serwera, opublikowana)
↓ czyta
⚙️ Silnik → plan pacjenta

Jedno źródło prawdy: ankieta admina. Silnik czyta efektywną ankietę z serwera (z Excelem jako zapasem na czas przejścia, potem wyłączamy Excel).

Brakujące ogniwo nr 1 — „E2b": model edytora = pełnia silnika

Edytor musi umieć wszystko, co silnik (statusy typu „pole do ręcznego wpisania" i „treść stała", bogate warunki, znak zamiast ->) + test parytetu, który pilnuje, że „edytor → silnik" daje identyczny plan co „Excel → silnik". Dla warstwy globalnej taki złoty test już istnieje (PR #42/#43) — trzeba domknąć resztę.

Brakujące ogniwo nr 2 — „E2c": silnik czyta z serwera

Publiczny odczyt opublikowanej efektywnej ankiety (content_version_id dla global jest dziś pusty — „wypełniane od E2c") + przełączenie silnika na to źródło + zapas na Excel + wyłączenie Excela, gdy parytet się zgadza. Wszystko dev-first, na bramce review, prod dopiero na „promuj".