Skąd plan pacjenta bierze treść, jak działają wersje (fabryczna Asi + własne kopie) i kto co może zmieniać (superadmin → gabinet → higienistka). Strona robocza dla zespołu.
Asia prowadzi jedną fabryczną wersję. Każdy może na jej bazie zapisać własne nazwane kopie i przełączać, która jest aktywna. To nie jest scalanie warstw — aktywna wersja to zawsze jedna kompletna ankieta. Plakietka po prawej = kto czym zarządza.
scope=global. Żywa — każda publikacja Asi to nowa wersja fabryczna, dostępna dla wszystkich./api/templates/global · draft → publish jest na DEVscope=gabinet · allow_member_private_template cel (Etap 2)scope=user · /api/templates/mine · zapis solo jest na DEVPoprawka Asi nie nadpisuje po cichu cudzych wersji. Kto ma własną wersję, dostaje popup „Asia wypuściła nową wersję" + listę co się zmieniło (bloki zmienione / dodane / usunięte). Po kliknięciu „weź poprawki Asi" wchodzą tylko bloki, które Asia zmieniła — własne zmiany zostają; a gdy ten sam blok ruszyły obie strony, user wybiera przy tym jednym: „zostaw moje / weź Asi". Dzięki temu poprawka Asi może dotrzeć do każdego, ale świadomie.
Tożsamość („kim jesteś") pochodzi z Clerk. Uprawnienie („co wolno") liczy serwer (Worker + baza D1) na podstawie roli — front tylko pokazuje/chowa.
| Rola | Co może edytować | Czego nie może | Skąd autoryzacja |
|---|---|---|---|
| 🔒 Superadmin (Asia + 3 maile) |
Wersję fabryczną (globalną) = domyślną ankietę-źródło dla wszystkich. Panel admina: treść, gabinety, „darmowe miesiące", maile. | — | Tabela platform_admins (lista maili) + assertCanEditGlobal w Workerze. |
| 🏢 Manager gabinetu | Własne nazwane wersje gabinetu (kopie fabrycznej). Ustawia, czy narzuca je zespołowi i czy higienistka może mieć własne. | Nie rusza fabrycznej (Asi) ani innych gabinetów. | Rola owner w account_members (lustro Clerk Organizations). |
| 👩⚕️ Higienistka | Własne nazwane kopie — solo zawsze; członek gabinetu tylko gdy gabinet pozwoli. Każdy może „przywrócić fabryczne". | Nie rusza fabrycznej ani cudzych. Członek z zablokowanym własnym szablonem korzysta z wersji gabinetu. | 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. |
owner dla solo/gabinetu, member dla zaproszonej higienistki) — bez ręcznej roboty. Własna wersja ankiety powstaje dopiero przy pierwszym zapisie; do tego czasu user jedzie na żywej fabrycznej. Nic się nie pre-kopiuje na zapas.
Edytor i baza już są (warstwa zapisu). Brakuje strony odczytu: żeby silnik czytał aktywną wersję z serwera zamiast z Excela.
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.
Jedno źródło prawdy: fabryczna Asi. Każdy może mieć własne kopie; silnik czyta aktywną wersję z serwera (z Excelem jako zapasem na czas przejścia, potem wyłączamy Excel).
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". Złoty test parytetu na realnej ankiecie (38 pytań) przeszedł bajt-w-bajt — to ryzyko zdjęte.
Odczyt opublikowanej aktywnej wersji za logowaniem (silnik chodzi w sesji higienistki; 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".