Jak działa nasz GitHub + Cloudflare: repozytorium, środowiska, wgrywanie, sekrety, pełny przepływ zmiany.
Dane zweryfikowane 2026-06-25 z konfiguracji (wrangler.toml), repozytorium i Cloudflare. Identyfikatory zasobów nie są sekretami; klucze/tokeny tu nie występują.
github.com/numerika-ai/higi — jedno repo na całość (monorepo). Menedżer paczek: pnpm. Budowanie spina turbo.
| Folder | Co to | Technologia |
|---|---|---|
apps/web | Aplikacja w przeglądarce (logowanie, bramka dostępu, edytor ankiety, panele) | React + TypeScript + Vite |
apps/workers | Mały serwer („Worker") — API /api/* | Cloudflare Workers + Hono |
apps/legacy | Silnik pacjenta — ankieta → plan → PDF | czysty JavaScript + Excel (SheetJS) |
apps/brief | Materiały/brief produktu | statyczne |
packages/shared-types | Wspólne typy/kontrakty front↔serwer | TypeScript |
packages/ui | Wspólne elementy interfejsu | TypeScript |
docs/ | Architektura, decyzje (DECISIONS), specyfikacje | Markdown |
main — oficjalna prawda. Nigdy nie wrzucamy wprost na main — zawsze przez gałąź + PR.fe/... (front), be/... (backend/serwer), docs/... (dokumentacja)./tmp/higi-org). Tu realnie edytuję, nie psując głównego repo.Konto Cloudflare: 9dba5bd9…b4e53c17. Cztery rodzaje zasobów: Pages (strony), Workers (serwer), D1 (baza), KV (magazyn).
| Projekt | Adres | Rola |
|---|---|---|
higi | higi.com.pl · www.higi.com.pl | PRODUKCJA — prawdziwe higienistki |
higi-dev | dev.higi.com.pl | DEV — testy zespołu |
| ~15 mikrosajtów (research, specyfikacja, raporty, ten opis…) | osobne, pomocnicze strony | |
/api/*)| Worker | Adres | Baza D1 | Rola |
|---|---|---|---|
higi-api | higi.com.pl/api/* | higi · 05affe22… | PRODUKCJA |
higi-api-dev | dev.higi.com.pl/api/* | higi-dev · 27504c35… | DEV |
Worker przechwytuje tylko /api/*; całą resztę (strona, /legacy, pliki) serwuje Pages. Ten sam adres = brak problemów z CORS. R2 (pliki) świadomie odłożone — MVP go nie potrzebuje.
To są całkowicie osobne, niepołączone zestawy zasobów. Zmiana na dev nie dotyka prod — i odwrotnie.
| Element | DEV | PRODUKCJA |
|---|---|---|
| Adres | dev.higi.com.pl | higi.com.pl |
| Strona (Pages) | higi-dev | higi |
| Serwer (Worker) | higi-api-dev | higi-api |
| Baza (D1) | higi-dev | higi |
| Magazyn (KV) | c0da3925… | b95ef4fc… |
| Automat maili (cron) | tak (6:00 UTC, tryb próbny) | świadomie nie (dodamy na „promuj") |
| Kto wgrywa zmiany | każda nowa rzecz — najpierw tu | tylko na wyraźne „promuj" Bartosza |
Logowanie (Clerk) to ta sama usługa dla obu — ważne to ta sama subdomena clerk.higi.com.pl; różni się tylko „dozwolony adres" (dev vs prod).
Bierze pliki takie, jakie są w folderze — obojętne, czy zacommitowane. Dlatego u nas Git Provider: No na wszystkich projektach: commit niczego nie wgrywa, wgrywanie niczego nie commituje.
# 1. osobny folder roboczy na nowej gałęzi (z czystego main) git worktree add /tmp/higi-org -b be/nazwa origin/main # 2. budowanie pnpm --filter @higi/web build # strona (tsc + vite) pnpm --filter @higi/workers typecheck # sprawdzenie serwera # 3a. WGRYWANIE serwera (Worker) na dev wrangler deploy --env dev # prod: wrangler deploy (bez --env) # 3b. WGRYWANIE strony (Pages) na dev wrangler pages deploy apps/web/dist --project-name=higi-dev --branch=main # ŚCIEŻKA GIT (trwałość) — to było pomijane git commit -am "opis" && git push origin be/nazwa gh pr create # potem /code-review + /security-review → merge
fe/ lub be/).commit → push → PR./code-review + /security-review — poprawki w tej samej gałęzi.main (merge PR).wrangler → weryfikacja na dev.higi.com.pl.higi/higi-api.Klucz: zapis na GitHub (3–5) przed wgraniem (6) — wtedy serwer zawsze ma odpowiednik w historii.
Przeglądarka → dev.higi.com.pl
│
├─ ścieżka /api/* → Worker higi-api-dev → D1 (baza) / KV (magazyn)
│ ↳ sprawdza token logowania (Clerk)
└─ wszystko inne → Pages higi-dev (pliki strony: HTML/JS/CSS, /legacy)
Logowanie: Clerk (zewnętrzne) · Płatności: Stripe (jeszcze nieaktywne) · Maile: Resend (tryb próbny)
Dane pacjenta (odpowiedzi z ankiety, gotowy plan) zostają w przeglądarce — nie lecą na serwer. To twarda obietnica produktu (decyzja D-08).
| Sekret | Gdzie |
|---|---|
| Token Cloudflare (do wgrywania) | plik na dysku ~/.openclaw/secrets/ — nigdy w repo ani czacie |
| Klucz tajny Clerk / Resend | wrangler secret put … — żyje na Workerze, nie w plikach |
| Klucze frontu (publiczny Clerk, ceny) | apps/web/.env.local — poza repo (.gitignore) |
.gitignore).main — zawsze gałąź → PR → przegląd → merge./code-review + /security-review.Część pracy poszła tylko Ścieżką 2 (wgrywanie), bez Ścieżki 1 (git). Skutek: ~53 pliki (gabinety, maile, NIP, warstwa globalna) żyją wyłącznie w folderach /tmp na komputerze — brak na GitHubie, brak historii, brak przeglądu. Skasowanie folderu = utrata pracy.
Naprawa: przepuścić te pliki przez Ścieżkę 1 (commit → push → PR → przegląd). Szczegóły w raporcie stanu: higi-status-raport.pages.dev.
| Pojęcie | Po ludzku |
|---|---|
| commit | zapis migawki zmian w historii (na razie tylko na komputerze) |
| push | wysłanie zapisanych zmian na GitHub |
| PR (pull request) | prośba o włączenie zmian do main — moment na przegląd |
| merge | scalenie zatwierdzonych zmian do main |
| worktree | osobny folder = kopia repo na danej gałęzi |
| build | złożenie kodu w gotową paczkę dla przeglądarki/serwera |
| wrangler | narzędzie Cloudflare do wgrywania (Pages i Worker) |
| Pages / Worker | hosting strony / mały serwer w chmurze (/api/*) |
| D1 / KV | baza danych / prosty magazyn klucz-wartość |
| Clerk | zewnętrzna usługa logowania (hasła, weryfikacja, sesje) |
deploy-*.yml). Czy to najlepsza droga — i jak ją bezpiecznie przywrócić, skoro aplikacja już żyje na produkcji?
| Model | Jak działa | Plusy | Minusy |
|---|---|---|---|
| A. GitOps przez GitHub Actions (pierwotny zamysł) | merge do main → Actions → wrangler wgrywa |
jedno źródło prawdy; historia; przegląd; jeden pipeline dla strony + serwera + migracji; łatwa bramka na prod | trzeba skonfigurować + włożyć sekrety do GitHub |
| B. Ręczny wrangler z maszyny TERAZ | człowiek odpala deploy z folderu | zero konfiguracji; pełna kontrola ad-hoc | brak historii; dryf dev↔GitHub; „deploy z niezacommitowanego"; błąd ludzki |
| C. Natywne podpięcie Cloudflare↔Git | projekt Pages podpięty wprost do repo, build w chmurze CF | proste dla samych stron | tylko Pages (nie obejmuje Workera ani migracji); słabsza bramka na prod |
Jako jedyny obejmuje stronę + serwer + migracje w jednym, spójnym torze, z możliwością ręcznej bramki na produkcję. Model C można rozważyć jako uproszczenie wyłącznie dla stron pomocniczych. Model B (dziś) zostawiamy tylko jako awaryjny.
| Ryzyko | Skutek |
|---|---|
Praca tylko w /tmp, niezacommitowana | skasowanie folderu = utrata tygodni pracy (dziś ~53 pliki) |
| Dryf dev ↔ GitHub | nie wiadomo, co naprawdę jest na żywo; trudny powrót do stabilnej wersji |
| Brak przeglądu kodu/bezpieczeństwa | błędy i podatności trafiają bez kontroli (łamie zasadę #8) |
| Ręczny deploy = błąd ludzki | zły projekt, zła kolejność, pominięty krok (już się zdarzyło) |
| Token-sekret na maszynie | większa powierzchnia ryzyka niż sekret zamknięty w CI |
| Ryzyko zmiany | Zabezpieczenie |
|---|---|
| Prod wgra się sam po merge → łamie „promuj" | GitHub Environments + wymagane zatwierdzenie (albo prod tylko ręcznym workflow_dispatch) |
| Migracje bazy auto-odpalą się na prod | migracje prod zawsze ręcznie, nigdy w automacie |
| Sekrety w GitHub = nowa powierzchnia ataku | token o wąskim zakresie (tylko deploy), w GitHub Secrets, z rotacją |
| Niegotowy merge trafia na żywo | ochrona gałęzi main + wymagany review przed scaleniem |
| Pierwszy automat nadpisze niezacommitowaną pracę z dev | NAJPIERW zacommitować dług, potem włączać automat |
I tak, i nie — zależy co liczymy:
Werdykt: zmiana ŚREDNIA, ryzyko NISKIE — jeśli robiona etapami. Każdy etap jest odwracalny, a produkcja rusza dopiero na końcu i tylko ręcznie.
/tmp → PR → review. Po tym GitHub = dev. Bez tego każdy automat jest niebezpieczny.main buduje i wgrywa na higi-dev / higi-api-dev. Dev jest bezpieczny — tu testujemy sam mechanizm.apps/web; poprawić cel legacy (higienistka → higi); wyłączyć martwe/błędne workflow'y.main (wymagany PR + review).