Przejdź do głównej zawartości

Co jest czyje — granica własności

Repozytorium strony ma trzech właścicieli:

Obszar Czyje Co to znaczy dla Ciebie
src/pages, src/components, src/layouts, src/styles, src/assets Twoje (warstwa prezentacji) Projektujesz swobodnie. Aktualizacja silnika tego nie nadpisze. Dwie strony mogą wyglądać zupełnie inaczej.
src/content/**, wgrane zdjęcia, agreements/ Klienta Każdy tekst, który klient mógłby kiedyś zmienić, musi stać tutaj — nigdy na sztywno w komponencie.
src/lib/, functions/, content.config.ts, src/i18n/, public/sc/, konfiguracja builda, package.json, .sc-engine.json, robots.txt, _headers Platformy Wraca przy każdej aktualizacji. Poprawka zrobiona tutaj zniknie — zepsutą infrastrukturę zgłaszasz (sc mcp → zgłoszenie).

W public/ Twoje są tylko images/uploads (biblioteka zdjęć) i fonts (kroje) — commit gdzie indziej w public/ zatrzyma hook. Logo, ikony i pliki do pobrania trzymaj więc w src/assets. Aktualizacja nie kasuje plików strony, których silnik nigdy nie wysłał (np. tych z założenia strony), i mówi, co zostawiła; znika tylko obcy plik w ścieżce wyłącznie platformy (src/lib/, functions/, public/sc/, public/panel/).

Granicy pilnują trzy bariery:

  • hook pre-commit — w trakcie scalania przepuszcza plik platformy taki, jak w scalanym commicie albo w origin/main (to platforma przychodzi z main); plik platformy zmieniony ponad to dalej zatrzymuje,
  • pliki tylko do odczytu w VS Code,
  • sc push / sc submit — ten sam kod odrzuca zmiany w plikach platformy i wypisuje je z powodem. Nieśledzone pliki robocze dostają radę, a nie odmowę.

Kod prezentacji nie może wołać API panelu w żadnej pisowni, bo strona klienta nie ma prawa korzystać z sesji panelu. Link do samej strony panelu jest dozwolony.

Przy odbiorze bramka integralności sprawdza, czy pliki silnika są nienaruszone (patrz „Bramki”). Przemalowany layout nie jest problemem. Podmieniony plik silnika — jest.