Praca wykonawcy na platformie SoftConcept

Ten dokument jest dla wykonawcy — programisty albo projektanta, który realizuje zlecenia na stronach klientów SoftConceptu. Opisuje, skąd biorą się zlecenia, jak pracuje się z wierszem poleceń sc, co w repozytorium strony należy do Ciebie, a co do klienta i platformy, oraz co musi być prawdą, zanim klient odbierze Twoją pracę. Szczegóły techniczne konkretnej wersji silnika masz w klonie, w AGENTS.md i ZMIANY-SILNIKA.md. Ten dokument je porządkuje, ale ich nie zastępuje.

#Zlecenie w pięciu zdaniach

1. Klient opisuje zmianę i kryteria odbioru, a zlecenie trafia do puli albo wprost do Ciebie.
2. Bierzesz je komendą sc take, która klonuje stronę na gałąź order/<id>.
3. Pracujesz lokalnie i zabezpieczasz pracę sc push. Każdy push przebudowuje podgląd zlecenia pod osobnym adresem.
4. Gdy kończysz, sc submit zgłasza pracę do odbioru. Serwer sprawdza ją i dopiero wtedy klient dostaje mail o podglądzie.
5. Klient odhacza kryteria i odbiera albo odsyła do poprawki. Odebrana praca jest scalana do main i wdrażana bez Twojego udziału, a Twój dostęp do repozytorium wygasa.

#Konto wykonawcy

Zaprasza Cię zespół SoftConcept:

1. Dostajesz link onboardingu.
2. Ustawiasz hasło i podajesz kod.
3. Logujesz się do portalu wykonawcy (ops.softconcept.eu/dev).

Portal pokazuje:

• Twoje zlecenia,
• pulę zleceń do wzięcia,
• Twoje punkty i ranking,
• komendy CLI w dokładnie takiej postaci, jakiej wymaga sc.

Stąd też pobierzesz CLI.

Telefon jest obowiązkowy. Na podglądzie zlecenia strona pokazuje Twój numer zamiast numeru gabinetu klienta. Bez numeru w koncie nie weźmiesz zlecenia ani z portalu, ani z CLI — dostaniesz odmowę z prośbą o dopisanie numeru. Numer dopiszesz sam w portalu. Numer zajęty przez inną osobę zostanie odrzucony. Ta sama skrzynka Gmail w różnych zapisach (z kropkami, z +tag) to dla nas jedna osoba.

Zamknięcie konta przez zespół odbiera dostępy do repozytoriów. Jeśli masz zlecenia w toku, wracają one do puli.

#Skąd biorą się zlecenia

Zlecenie może do Ciebie trafić na cztery sposoby:

• Pula w /dev. Widzisz otwarte zlecenia bez rozmowy i materiałów — te dostajesz dopiero po wzięciu. Wzięcie przypisuje zlecenie do Ciebie i zdejmuje je z puli. Zlecenie, które ma już wykonawcę, dostanie odmowę „zlecenie ma już wykonawcę”.
• Przydział. Platforma sama kieruje zlecenia: czysto treściowe ze specyfikacją z wywiadu do agenta AI, resztę (także zlecenia z kompozytora i panelu, które specyfikacji nie mają) do ludzi z oznaczeniem „wymaga dewelopera”. Agent, który uzna zlecenie za zbyt trudne, oddaje je do puli z powodem. Właściciel strony albo nasz zespół mogą Cię też wskazać wprost.
• Mail z przydziałem (order-assigned). Zawiera gotową komendę sc take z kluczem.
• Zlecenie założone przez nasz zespół. Też dostajesz gotową komendę sc take.

Zlecenie ma dwie warstwy opisu:

• opis i kryteria odbioru — klient je widzi i po nich odbiera,
• wskazówki i kryteria techniczne — dostajesz tylko Ty: w zleceniu, w sc take, w /info czytanym kluczem zlecenia i w swoich zleceniach w /dev.

Przy odbiorze właściciel może ocenić Cię od 1 do 5 gwiazdek. Po wdrożeniu dostajesz punkty, które sumuje ranking wykonawców.

#Instalacja i logowanie CLI

Instalacja (wymaga Node 20+ i gita, instaluje się tylko w Twoim katalogu domowym):

curl -fsSL https://ops.softconcept.eu/sc-install.sh | bash
sc version          # czy instalacja jest aktualna

sc sam sprawdza przy starcie, czy jest aktualny.

Logowanie urządzenia:

sc login            # pokazuje kod — potwierdzasz go w portalu (/cli)
sc whoami           # kim jest ta sesja
sc orders           # Twoje aktywne zlecenia: strona, stan, niepotwierdzony zakres, materiały
sc logout

Token logowania odnawia się przy każdym użyciu. Unieważnisz go w portalu („Moje urządzenia”). Gdy token wygaśnie, sc orders poprosi o sc login.

Język komunikatów zmienisz komendą sc lang pl albo sc lang en. Stare polskie nazwy komend i flag dalej działają.

Ta dokumentacja jest pod ręką w terminalu:

sc docs                       # otwiera docs.softconcept.eu
sc docs granica własności     # otwiera sekcję, która najlepiej odpowiada na frazę
sc docs sc submit --print     # tylko drukuje adres sekcji

Fraza nie musi powtarzać nagłówka słowo w słowo — „jak się zalogować” trafi tutaj. Gdy nic nie pasuje, sc docs mówi to wprost i podaje adres całej dokumentacji.

#Wzięcie zlecenia

sc take <id>                                   # zalogowany: klucz CLI weźmie sam
sc take <id> --key <KLUCZ> --email ty@mail.pl  # bez logowania, z kluczem z maila
cd <katalog klonu>

Co robi sc take:

• przestawia zlecenie na „w toku”,
• zakłada osobne konto repozytorium dla tego jednego zlecenia (dwa Twoje zlecenia to dwie różne tożsamości),
• klonuje stronę na gałąź order/<id> i ustawia w klonie lokalną tożsamość zlecenia — Twój globalny git zostaje nietknięty,
• robi próbny push, zanim powie „gotowe”.

Możliwe odmowy: zły klucz, zlecenie już zamknięte, brak adresu e-mail.

W klonie dostajesz:

• .sc-order.md — opis, kryteria odbioru, całą rozmowę z klientem, uwagi z podglądu i listę materiałów. To pierwszy plik, który czytasz.
• .sc-materials/ — załączniki klienta (archiwa są już rozpakowane). Leżą poza gitem — nie commituj ich. Materiał kupiony (np. szablon HTML) to wzorzec do przerobienia, a nie plik do wrzucenia.

Kolejność czytania: .sc-order.md, potem AGENTS.md (kontrakt silnika), potem w ZMIANY-SILNIKA.md wpisy nowsze niż wersja w .sc-engine.json.

Po odbiorze albo zamknięciu zlecenia klucz przestaje działać: tracisz opis, rozmowę, załączniki i dostęp do gałęzi.

#Codzienna praca w klonie

W katalogu klonu wszystkie komendy działają bez argumentów — identyfikator i klucz zlecenia biorą się z klonu.

#Synchronizacja: sc sync

sc sync     # alias: sc pull

Komenda:

• dociąga Twoją gałąź zlecenia i bieżący main,
• odświeża .sc-order.md i materiały,
• na koniec mówi, co jest tylko na dysku, co wypchnięte, a co na podglądzie, i podaje jedno wezwanie do działania.

Uruchamiaj ją na początku pracy i przed każdym sc push.

Treść może zmienić się pod Tobą. Klient (i Ty) może edytować treść w panelu na podglądzie zlecenia, a każdy taki zapis to commit w Twojej gałęzi. Gałąź, która wyprzedza klon, to praca klienta, a nie coś do wypchnięcia.

#Strona i panel lokalnie: sc dev, sc panel, sc links

sc dev            # strona z klonu + panel lokalnie; dostępna w sieci (sprawdzisz na telefonie)
sc dev --local    # tylko na tym komputerze
sc dev stop       # zatrzymuje wyłącznie nasz proces panelu
sc panel          # sam panel na treści TEGO zlecenia, bez logowania, zapisy do plików w klonie
sc links          # wszystkie adresy: lokalny, telefon, podgląd zlecenia, produkcja

Zajęty port przesuwa się na następny wolny. Gdy pod adresem po starcie panuje cisza, CLI zgłasza usterkę i podaje powód z dziennika. Lokalny panel pokazuje zmiany na dysku, które nie zostały wypchnięte, i podpowiada sc push — nigdy przycisk publikacji.

#Co zmieniłem: sc changes, sc log, sc undo

sc changes   # aliasy: st, status — zmiany w klonie
sc log       # historia w trzech progach: lokalnie / wypchnięte / co widzi klient na podglądzie
sc undo      # alias: restore — cofa zmiany w śledzonych plikach do stanu gałęzi

sc undo nie usuwa nowych plików — zostawia je i wymienia. Gdy podgląd jest zbudowany z wersji spoza gałęzi, sc log to zgłasza.

#Zabezpieczenie pracy: sc push

sc push -m "Sekcja cennika: układ na telefonie"   # alias: sc save

sc push robi commit i push gałęzi zlecenia, a potem przebudowuje podgląd z klonu. Nie zgłasza pracy do odbioru. Rób to na koniec dnia i po każdym większym kroku.

Co sprawdza i robi po drodze:

• granica własności jest sprawdzana przed commitem (patrz „Co jest czyje”),
• duży plik (5 MB i więcej, także w nowym folderze) wymaga świadomego --yes, bo zostałby w historii na zawsze,
• gałąź cięższa niż limit Cloudflare jedzie tunelem,
• nieudany build podglądu nie przewraca komendy — praca jest już wypchnięta.

#Rozmowa z klientem: sc comment, sc confirm

sc comment "Czy przycisk ma prowadzić do formularza, czy do telefonu?"
sc confirm      # „rozumiem zakres" — do tego czasu klient widzi „czeka na potwierdzenie"

Klient dostaje mail i widzi wpis przy zleceniu. Odpowiedzi klienta pojawią się w .sc-order.md po sc sync, a zmiany stanu zlecenia możesz śledzić na żywo w /dev.

Jeśli klient poprosi o anulowanie zlecenia w toku, dostaniesz mail. Zlecenie nie zamyka się samo — rozstrzyga to nasz zespół.

#Tłumaczenie: sc translate

sc translate en    # tłumaczy treść klonu z języka domyślnego i deklaruje język

Nowy język strony dodaje się właśnie zleceniem. Kolejność kanałów tłumaczenia:

1. domyślnie w sesji Twojego agenta AI — porcje i wyniki w plikach, bez kosztu,
2. potem Twoim własnym kluczem AI,
3. serwerem platformy tylko na wyraźną prośbę: do 200 KB na raz, do 150 tłumaczeń na zlecenie.

Wynik jest przyjmowany tylko wtedy, gdy ma identyczny kształt co źródło. Duże strony dzielone są na porcje. Z katalogu roboczego znika tylko to, co zastosowano: strona pominięta z braku wyniku zostaje ze swoimi porcjami, agent ją dokańcza, a kolejne --apply ją zapisuje.

#Nowa wersja silnika: sc upgrade

Gdy zlecenie potrzebuje funkcji z nowszego silnika, uruchom w klonie:

sc upgrade

Platforma zakłada standardowe zlecenie aktualizacji strony (albo przyspiesza już zaplanowane), a CLI czeka, aż nowa wersja wejdzie na main, i scala ją do Twojej gałęzi. Na stronę przypada jedna aktualizacja naraz. Dopóki strona się aktualizuje, nowe zlecenia klienta na niej czekają.

#Pytania do platformy: sc mcp, sc requests

Uruchom swojego agenta AI z narzędziami silnika:

sc mcp

Agent może wtedy:

• przeszukiwać prawdziwą dokumentację silnika Twojego klonu (ze wskazaniem źródła),
• sprawdzić, co doszło od Twojej wersji,
• złożyć zgłoszenie — pytanie albo prośbę o zmianę silnika. Kontekst klonu dołącza się sam.

Zgłoszenia prowadzisz komendami:

sc requests                     # lista (← przy tych, które czekają na Ciebie)
sc requests 124                 # wątek
sc requests 124 reply "…"       # dopisz do wątku
sc requests 124 accept ["uwaga"]   # zaakceptuj ustalenie
sc requests 124 reject "powód"     # odeślij ustalenie

Pytanie zamyka nasza odpowiedź. Zmiana silnika wymaga ustalenia z sześcioma polami: pisze je nasz zespół, a Ty je jawnie akceptujesz. Renegocjacja zachowuje poprzednią wersję ustalenia. Wydanie silnika, które realizuje zgłoszenie, zamyka wątek i mówi, jak dostać tę wersję. Nowa odpowiedź pokazuje się przy każdej komendzie sc.

#Co jest czyje — granica własności

Repozytorium strony ma trzech właścicieli:

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,
• 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.

#Edytowalna sekcja = dane + schemat + render

Projektuj swobodnie. Ale zanim zgłosisz pracę, każda sekcja z treścią przechodzi panelizację. Edytowalna sekcja to zawsze trzy rzeczy naraz:

1. Dane — klucz sekcji w src/content/<strona>/{pl,en}.json.
2. Schemat — wpis w src/content/settings/<strona>-schema.json. Typy pól: text, textarea, image, objectArray, stringArray, group, odwołanie do rekordu (ref), wybór. Etykiety po polsku i angielsku.
3. Render — komponent czyta wyłącznie z tych JSON-ów.

Panel sam rysuje formularz ze schematu. Klucz, którego nie ma w schemacie, jest w panelu niewidzialny, bez komunikatu. sc push wypisuje takie klucze, a kontrakt treści traktuje je jako naruszenie.

Nowa podstrona to jeszcze wpis w src/content/settings/pages.json (klucz, etykiety, katalog treści, opcjonalnie path). Strona sama pojawi się w panelu, a aktualizacje jej nie skasują.

Reguły, o których łatwo zapomnieć:

• Obrazki. Każde pole obrazka deklaruje media.ratio (np. "16:9", także w grupach i listach) — bez tego kontrakt nie przejdzie. Wartość pola to baza drabinki rozmiarów, a render robi <Pic> z właściwym sizes. Obrazek jest wspólny dla wszystkich języków.
• Reguły pól. maxLength, minLength, required, pattern z komunikatem. Panel pokazuje licznik i odmawia zapisu. Daj maxLength nagłówkom i przyciskom — to tańsze niż zgłoszenie „rozjechało się na telefonie”.
• Sekcja powtarzana ma klucz typ--instancja.
• Języki są dynamiczne (site.json, pierwszy jest domyślny). Nie wpisuj pl|en na sztywno. Kontrakt sprawdza też, że strona pod /en/ ma lang="en", a sekcje zgadzają się między językami.
• Atomy wyglądu. Elementy oznaczone data-sc-atom (plakietka, przycisk, pole) muszą mieć regułę w arkuszu.

Jeśli schemat ma uszkodzoną sekcję, panel ją pominie i nazwie powód. Reszta działa.

#Co silnik robi za Ciebie — nie dubluj

Silnik dopisuje do gotowego HTML-a sporo rzeczy. Jeśli zrobisz je drugi raz w layoucie, będą zdublowane albo sprzeczne. Ogólna zasada: to, co strona już wypisała, wygrywa, a silnik dokłada resztę.

Treść klienta potrafi być nieprzyjemna: długie tytuły, nierozrywalne adresy, tabele. Silnik daje style dla tych konstrukcji — nie wyłączaj ich.

#Twarde wymogi techniczne

• Strona czysto statyczna. SC_CLIENT_STATIC=1 npm run build musi przechodzić. Żadna strona nie może żądać serwera (prerender = false wywróciłby build).

• Zero skryptu inline i zero atrybutów on… w zbudowanym HTML-u. Polityka bezpieczeństwa strony i tak by ich nie wykonała, a kontrakt sprawdza wynik buildu. Interakcje to osobne pliki przez <script src>.

• Żadnych stron trzecich poza Turnstile. Żądania do obcych hostów zatrzymują aktualizację i audyt. Osadzenia idą wyłącznie jako ramki.

• Build bez sekretów. Build biegnie na kopii bez .git i .env, jako osobny użytkownik, bez skryptów instalacyjnych. Dowiązanie symboliczne w wyniku blokuje wysyłkę.

• Bezpieczniki, które wywrócą build. Kontrakt łapie przed scaleniem:

  • moduł skopiowany ręcznie z monorepo,
  • własny plik niedodany do commita,
  • znacznik {% … %} w treści wpisu (pokazany w bloku kodu jest w porządku — panel zapisuje go zabezpieczony: {% process=false %} na płotku, \{% we wciętej linii).

• Otwieracz z filmem — reguły sprawdzane przy każdym sc submit:

  • żadnego <source> w <video> (WebKit trzyma przez nie load ok. 3 s),
  • plakat z tego samego pliku co pod spodem,
  • osobne kadry telefon/komputer przez media.

  Media przygotujesz jednym poleceniem z jednego mastera (AV1/VP9/H.264, plakat z pierwszej klatki, AVIF). Szczegóły i polecenia są w AGENTS.md klonu oraz w skillu media-otwieracza.

• Rytm i skala. Każda sekcja ma pionowe wcięcie, a odstępy biorą wartości ze skali systemu stylów zamiast przypadkowych liczb.

Do pomiaru szybkości zbudowanej strony służą przyrządy (budżet CSS, LCP, sonda otwieracza). Przy stronie ze sklepem runner mierzy CSS i LCP przed odbiorem sam.

#Moduły na zleceniu

Moduł to typ treści z rekordami (np. zespół, zabiegi, realizacje), edytowany przez klienta w osobnej sekcji panelu. Strona może zdefiniować własny moduł bez kodu — wystarczy plik _definition.json w src/content/modules/<strona>--<nazwa>/.

sc module-new realizacje   # zakłada definicję z pierwszym modelem
sc module-check            # moduły, modele, liczba rekordów, adresy; błędy z plikiem i kodem wyjścia
sc clinic-pages            # wkłada do klonu strony-ziarno kliniki (/treatments, /team), nie nadpisując Twoich plików

Jak działają moduły:

• Rekord to record.json z polami wspólnymi i tłumaczonymi (i18n) plus osobne pliki tekstu bogatego. Panel i build stosują tę samą walidację: czego build nie przyjmie, tego panel nie zapisze.
• Adresy rekordów liczą się z routable. Konflikt adresów zatrzymuje build z nazwą.
• SEO stron rekordów bierze pola z seo modelu.
• Strony modułu (lista, strona rekordu) są prezentacją. Przychodzą jako ziarno z paczki modułu i nie nadpisują plików, które strona już ma. Upgrade ich nie dotyka.
• Strony kliniki czytają wyłącznie z magazynu modułu, a zdjęcia idą przez <Pic>.
• sc module-check wymaga silnika 1.103.1 lub nowszego. Na starszym poprosi o upgrade zlecenia.

#Podgląd zlecenia

Każde zlecenie ma własny podgląd: osobną budowę gałęzi order/<id> pod osobnym adresem, który nie dotyka produkcji.

Kto buduje podgląd. Serwer buduje podgląd przy wzięciu zlecenia i po każdym pushu. Adres pojawia się dopiero wtedy, gdy podgląd odpowiada. Każda budowa to numerowany wpis z commitem i powodem.

Z czego się składa. Podgląd buduje kod platformy z main, a z Twojej gałęzi bierze tylko prezentację i treść. Pliki podrzucone gdzie indziej znikają przed budową.

Co jest na podglądzie:

• plakietka z numerem zlecenia i SHA wersji (do podyktowania przez telefon). Nie ma jej na domenie klienta,
• klik-do-edycji — tekst, który w całości pochodzi z pola treści, po kliknięciu otwiera to pole w panelu. Mapa pól powstaje tylko w buildzie podglądu,
• telefon wykonawcy (Twój) zamiast numeru gabinetu. Ruch reklamowy dostaje numer z puli podglądów, a rozmowy z podglądu nie trafiają do raportów klienta,
• poczta z formularzy idzie do Ciebie, a statystyki podglądu mają osobną tabelę.

Panel na podglądzie. Zalogowany na podglądzie panel czyta i zapisuje wyłącznie gałąź zlecenia i działa w zawężonym zakresie: treść i media, bez publikacji, ustawień i danych biznesowych klienta. Przycisk Pokaż na podglądzie przebudowuje tylko ten podgląd.

Test drogi z reklamy. sc ads-test sprawdza drogę „kliknięcie z reklamy → rozmowa → wynik → konwersja” na koncie testowym platformy, nigdy klienta. Bez --naprawde Google tylko sprawdza paczkę. Linki testowe z podglądu mają zakres testowy i nie trafiają do kolejki gabinetu.

#Uwagi z podglądu

Klient (albo recenzent) przypina uwagi do pól na podglądzie. Każda uwaga i odpowiedź trafia do rozmowy zlecenia z informacją „gdzie i co”, a druga strona dostaje mail.

Po sc sync uwagi są w .sc-order.md, w sekcji „Uwagi z podglądu”: otwarte jako nieodhaczone (z miejscem, autorem i wątkiem), rozwiązane jako odhaczone. Odpowiadasz i rozwiązujesz je w panelu, na ekranie Uwagi. W wątku jesteś stroną „dev”.

Otwarta uwaga to sprzeciw. sc submit zatrzyma się, nazwie otwarte uwagi i wyjdzie z kodem 1. Świadomie przejdziesz flagą:

sc submit --despite-comments

#Zgłoszenie do odbioru: sc submit

sc submit

Przed wysłaniem CLI sprawdza:

• granicę własności,
• build,
• kontrakt (w tym reguły otwieracza),
• świeżość względem main.

Serwer zapisuje wersję bazową i adres podglądu, po czym robi własne sprawdzenie. Klient dostaje mail o gotowym podglądzie dopiero wtedy, gdy ono przejdzie. Drugi submit tego samego zlecenia zostanie odrzucony.

Po submicie dopisz w rozmowie krótkie podsumowanie: co zrobione, decyzje po drodze, jak sprawdzić na podglądzie, które sekcje są edytowalne w panelu. Wzór masz w AGENTS.md.

Zgłosiłeś za wcześnie?

sc unsubmit nie skończyłem stopki

Zlecenie wraca do pracy. Pamiętaj, że klient dostał już mail o podglądzie. Wycofać można tylko zgłoszenie czekające na odbiór.

#Bramki przed odbiorem

Klient może odebrać pracę dopiero wtedy, gdy spełnione są cztery warunki:

1. Zielony check serwera dla tego commitu. Liczy się wyłącznie sprawdzenie zrobione przez serwer, nie werdykt z Twojego CLI. Po poprawce liczy się najnowszy check. sc submit zapisuje na zleceniu zgłoszony commit, więc ponowne zgłoszenie nie przejdzie na zielonym checku poprzedniego commitu (odświeżony podgląd ten commit zeruje). Czerwony check cofa zgłoszenie do Ciebie z powodem.
2. Nienaruszony silnik. Przy odbiorze pliki silnika w gałęzi są porównywane z zaufanym manifestem wersji silnika tej strony. Podmieniony, dodany w obszarze silnika albo usunięty plik zatrzymuje scalenie.
3. Świeża gałąź. Gdy main pójdzie dalej (np. klient opublikował zmiany), platforma sama odświeża Twoją gałąź i podgląd. W tym czasie odbiór jest zablokowany („Podgląd właśnie się aktualizuje…”).
4. Brak konfliktów. Konflikty w plikach treści scala AI, a niezależny weryfikator musi jawnie potwierdzić wynik. Konflikt poza treścią trafia do człowieka — klient widzi „Zmiana wymaga ręcznego scalenia…”, a Ty dostajesz zlecenie z powrotem.

#Odbiór, poprawka i wejście na żywo

Klient przechodzi po kryteriach i oznacza każde: „ok”, „nie ok” z komentarzem albo „na później”. Punkty „na później” stają się osobnymi zgłoszeniami.

• Odesłanie do poprawki zawsze ma powód. Trafia do rozmowy jako „Do poprawki: …”, do .sc-order.md i do Ciebie mailem. Poprawiasz, pushujesz i zgłaszasz ponownie.
• Odbiór (teraz albo o godzinie) zamyka Ci dostęp do repozytorium. To normalne, nie awaria. Kolejka zadań scala gałąź do main jednym commitem (z listą Twojej pracy i współautorami), wdraża stronę i dopisuje wpis do dziennika klienta w agreements/.
• Konflikt przy scaleniu cofa zlecenie z „odebranego” do „zgłoszonego”. Poprawiasz gałąź i zgłaszasz jeszcze raz. Nic nie wchodzi w połowie.
• Odrzucenie ostateczne zamyka zlecenie i odbiera dostęp.
• Odbiór o godzinie. Gdy klient odbierze zlecenie „o godzinie”, wchodzi ono dokładnie w tym kształcie, w jakim je odebrano. Może też samo się cofnąć o wskazanej porze (kampania).
• Sprzątanie. 30 dni po zamknięciu platforma usuwa podglądy zlecenia. Gałąź, która weszła, jest kasowana, a ta, która nie weszła, chowana w archiwum.

Aktualizacje silnika przychodzą jako wewnętrzne zlecenia platformy i nie budzą klienta mailami. Ty dostajesz je przez sc sync (scalony main) albo sc upgrade.

#Zlecenie na stronie ze sklepem

Na stronie ze sklepem zmiany katalogu też są częścią zlecenia, ale nie trafiają od razu do sklepu.

Wydanie zlecenia. Wszystko, co zmienisz w katalogu przez panel zlecenia, trafia do wydania zlecenia trzymanego obok żywego katalogu. Panel zlecenia pokazuje „produkcja + zmiany zlecenia”, a każdy zapis to nowa rewizja z autorem. Zmiany właściciela w innych polach widzisz od razu. Zmiana właściciela w polu, które ruszyłeś, wyjdzie przy odbiorze jako konflikt — nie zostanie nadpisana.

Co wolno w wydaniu:

• nowy produkt (istnieje tylko w wydaniu, bez zdjęć i nie na sprzedaż),
• nowy adres produktu lub kategorii (po wejściu sam dostaje przekierowanie 301),
• cena wariantu, opis, kategorie,
• producent wybrany z istniejących,
• reguły sklepu.

Czego nie wolno — dostaniesz odmowę: promocje, nowi producenci, zdjęcia, stany magazynowe, klienci, zamówienia, pieniądze, ustawienia. Dane osobowe kupujących są dla zlecenia niedostępne.

Własne pola produktu dopisujesz w settings/shop-product-schema.json. Sklep przyjmie je przy wejściu zlecenia, ale tylko jako dodanie — usunięcie albo zmiana typu pola zostanie odrzucona.

Podgląd i kopia sklepu.

• Build podglądu nakłada zmiany zlecenia na katalog. Bez odpowiedzi o zmianach nie zbuduje podglądu wcale.
• Panel mówi np. „zapis r18 jest w budowie #6”.
• Kopia sklepu (shop-<strona>-o<8 znaków>) powstaje dopiero przy pierwszej próbie zakupu na podglądzie. To produkcja bez ludzi i pieniędzy: bez danych osobowych, z płatnością testową, bez prawdziwej poczty i SMS-ów. Zasypia po godzinie bez użycia i budzi się w około minutę. Działa na tym samym silniku sklepu co produkcja: gdy produkcja dostanie nowszy, kopia powstaje od nowa. Znika kilka minut po zamknięciu zlecenia.
• Na innych adresach podglądu sklep jest tylko do oglądania.

sc twin           # stan kopii jednym zdaniem: czeka na pamięć / powstaje / gotowa / uśpiona / błąd
sc twin wake      # obudź
sc twin reset     # postaw od nowa
sc twin retry     # ponów po błędzie
sc twin mail [<id>]   # poczta, którą kopia „wysłałaby” kupującym
sc twin changes   # zmiany sklepu w zleceniu (wejdą przy odbiorze)
sc twin pull      # dociągnij zmiany właściciela do kopii (starsze zlecenia pracujące w kopii)

sc dev budzi kopię. Gdy kopia nie odpowiada, CLI powie, że koszyk lokalnie nie zadziała.

Przed odbiorem runner przechodzi drogę kupującego na podglądzie (do końca w kopii) i mierzy CSS oraz LCP. Gdy kopia dopiero startuje, bramka na nią czeka (do 8 minut). Czerwony zakup blokuje odbiór. Pomiar ponad sufit strony wymaga od klienta świadomego „przyjmij mimo to”.

Po odbiorze zmiany sklepu wchodzą na żywy sklep przed budową produkcji, w bezpiecznej kolejności, bez ruszania stanów magazynowych. Poprawka po odesłaniu to po prostu nowa rewizja wydania.

#Czego nie robisz nigdy

• Nie commitujesz do main i nie używasz surowego git pull ani git push. Od tego są sc sync i sc push.
• Nie zmieniasz plików platformy (src/lib/, functions/, konfiguracja builda, package.json, .sc-engine.json). Brak w silniku zgłaszasz.
• Nie wpisujesz tekstów klienta na sztywno w kodzie.
• Nie wgrywasz sekretów i nie commitujesz .env.
• Nie wrzucasz materiałów klienta (.sc-materials/) do repozytorium.
• Nie dodajesz skryptów inline ani zasobów z obcych domen.
• Nie wołasz API panelu z kodu strony.

Utknąłeś albo zlecenie wykracza poza zakres? Napisz to wprost w rozmowie (sc comment) albo w podsumowaniu przy sc submit. Jasne „to wymaga decyzji klienta” jest lepsze niż zgadywanie.

#Ściąga komend

# konto
sc login · sc whoami · sc logout · sc orders · sc lang pl|en · sc version · sc docs [fraza]

# zlecenie
sc take <id> [--key K --email E]
sc sync                     # na start i przed każdym push
sc dev [--local] · sc dev stop · sc panel · sc links
sc changes · sc log · sc undo
sc push [-m "opis"] [--yes]
sc comment "…" · sc confirm
sc translate <język>
sc upgrade
sc module-new <nazwa> · sc module-check · sc clinic-pages
sc ads-test [--naprawde]
sc twin [wake|reset|retry|mail|changes|pull]
sc submit [--despite-comments]
sc unsubmit [powód]

# platforma
sc mcp · sc requests [<id> reply|accept|reject …]

sc nie ma flagi --help przy komendach wykonujących akcje. Na przykład sc confirm --help po prostu wykona potwierdzenie.