Salon Black & White — SalonBW

Repozytorium produkcyjnego systemu salonu fryzjerskiego. Aktualnym stackiem jest Node.js 22, Next.js 15 i NestJS 11, a nie Laravel ani historyczny CodeIgniter. Szczegółowy stan wydań i decyzji jest w docs/PROJECT_STATE.md; każda zmiana wymaga zasad z docs/HANDOFF_PROTOCOL.md.

Aplikacje i środowiska

Komponent	Kod	Stos
Landing publiczny	apps/landing	Next.js 15 / React 18
Panel salonu	apps/panel	Next.js 15 / React 18
Backend API	backend/salonbw-backend	NestJS 11 / TypeORM / PostgreSQL
Wspólne moduły	packages	TypeScript / klient API

Środowisko	Landing	Panel	API
Produkcja	salon-bw.pl	panel.salon-bw.pl	api.salon-bw.pl
Development (staging)	dev.salon-bw.pl	dev-panel.salon-bw.pl	dev-api.salon-bw.pl

Development jest oddzielony od produkcji (osobna baza, sekrety i ciasteczka, bramka HTTP, noindex, wyłączone wysyłki oraz schedulery). Nie kopiuj prawdziwych danych klientek na development. Na hostingu mydevil.net aplikacjami zarządza Passenger; nie uruchamiaj dodatkowych procesów next start albo node app.js do diagnostyki.

Stan operacyjny: przełączenie domeny głównej na Node wykonano 2026-10-25; według zapisu z tego dnia regresja produkcyjna przeszła 23/23. To nie oznacza biznesowej zgody na start rezerwacji zamiast Booksy — potrzebne jest UAT właściciela. Przed każdą decyzją operacyjną sprawdź bieżący stan, nie polegaj na tym historycznym wyniku.

Uruchomienie lokalne

Wymagania: Node.js 22 (plik .nvmrc), pnpm 10.14.0 (package.json), PostgreSQL i ustawienia środowiska opisane w docs/ENV.md. Dodatkowe wskazówki: docs/DEV_SETUP_MAC.md.

corepack enable
pnpm install --frozen-lockfile

Skonfiguruj lokalne pliki .env na podstawie plików .example. Nie commituj sekretów i nie używaj produkcyjnej bazy jako środowiska testowego.

Osobne terminale, zgodnie z ustawieniami portów i API z dokumentacji developerskiej:

pnpm --filter salonbw-backend start:dev
pnpm --filter @salonbw/landing dev
pnpm --filter @salonbw/panel dev

Kontrola jakości

pnpm --filter @salonbw/landing lint
pnpm --filter @salonbw/landing typecheck
pnpm --filter @salonbw/landing test
pnpm --filter @salonbw/landing build

pnpm --filter @salonbw/panel lint
pnpm --filter @salonbw/panel typecheck
pnpm --filter @salonbw/panel test
pnpm --filter @salonbw/panel build

pnpm --filter salonbw-backend test
pnpm --filter salonbw-backend typecheck
pnpm --filter salonbw-backend build

Przed commitem stosuj dodatkowe zasady z AGENTS.md i Agent.md. Zmiany UI muszą uwzględniać brand system z .claude/skills/salonbw-brand/SKILL.md oraz weryfikację desktop/mobile. CI dla PR i master definiuje .github/workflows/ci.yml.

Wdrożenia — mydevil.net

Źródło prawdy: docs/DEPLOYMENT_MYDEVIL.md, docs/CI_CD.md i docs/RELEASE_CHECKLIST.md.

• Workflow: Deploy (MyDevil) w .github/workflows/deploy.yml.
• Cele: landing, panel, api, all, frontends i probe (aliasy public, dashboard, admin są zachowane dla kompatybilności).
• Środowiska: staging i production. Według bieżącej konfiguracji workflow (2026-10-29) uruchomienie deploymentu wymaga workflow_dispatch; zwykły push/merge do master nie uruchamia automatycznego deploymentu. Wymagane kontrole dostępu do Environment production i ochrony master są nadal przedmiotem #1557.
• Workflow rozwiązuje wskazany ref do pełnego SHA i wymaga sukcesu CI dla tego samego SHA przed instalacją, buildem, migracjami i przełączeniem.
• W pełnym deployu API (wraz z migracjami) musi zostać wdrożone przed frontendami. Release i smoke testy należy zweryfikować po zakończeniu workflow.

Przykład ręcznego wydania już sprawdzonego commitu na staging:

RELEASE_SHA="TU_WSTAW_ZWERYFIKOWANY_PELNY_SHA"
gh workflow run .github/workflows/deploy.yml --ref master -F ref="$RELEASE_SHA" -F environment=staging -F target=all

Produkcja wymaga osobnej decyzji o wydaniu, zweryfikowanego backupu i checklisty. Nie wykonuj ręcznie migracji bez przeglądu; wdrażaj kod przez workflow, nie przez nadpisanie plików na serwerze.

Poprzedni system PHP

Archiwalny ZIP strony zawiera CodeIgniter 3.0.4 (application/, system/). Nie jest aktualnym repozytorium SalonBW i nie zawiera aplikacji Node. W GitHubowym monorepo nie ma już katalogów wykonawczych starego PHP. Po przełączeniu domeny pliki legacy PHP usunięto z hostingu 2026-10-26 (według wykonanych operacji i ponownej inspekcji opisanych w PR #1520 i #1521). Nie jest już to ścieżka rollbacku.

Nie uruchamiaj ponownie operacji usuwania PHP; obecny rollback dotyczy tylko Node.js. Przebieg i ograniczenia weryfikacji: docs/LEGACY_PHP_RETIREMENT.md.

Dalsze prace

1. UAT biznesowe: sprawdzić kalendarz, rezerwację, historię klientki, obsługę wizyty i powiadomienia zgodnie z docs/UAT_PLAN.md.
2. Wygląd: kontynuować docs/LANDING_DESIGN_PLAN.md w osobnym PR i akceptować na staging przed produkcją.
3. Start rezerwacji: osobna zgoda ownera i finalny import przyszłych rezerwacji z Booksy; nie jest częścią prac dokumentacyjnych.

Dokumentacja

• docs/PROJECT_STATE.md — aktualny stan i blokery.
• docs/HANDOFF_PROTOCOL.md — obowiązkowy zapis zmian.
• docs/ARCHITECTURE.md — architektura.
• docs/ENV.md — konfiguracja środowisk.
• docs/DEPLOYMENT_MYDEVIL.md — produkcja i staging.
• docs/ROLLBACK_PROCEDURE.md — wycofywanie wydań Node.
• docs/LEGACY_PHP_RETIREMENT.md — wycofanie starego hostingu PHP.
• docs/journal — historia decyzji i dowodów.