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.

Konflikt przy scalaniu. Dziennik klienta (agreements/dziennik.md) scala się sam, gdy Ty i main tylko dopisaliście wpisy: zostają oba, nowsze na górze. Każdy inny konflikt sc sync wypisuje z nazwami plików i poleceniem, które kończy scalenie — rozwiąż konflikty w tych plikach i uruchom je:

git add <pliki z konfliktem> && git commit --no-edit && sc sync

Pliki platformy, które przyniosło scalenie, przejdą przez hook bez zmian. Scalenie cofasz przez git merge --abort.

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 prosi serwer o przebudowę podglądu i czeka na nią (zwykle około minuty). Nie zgłasza pracy do odbioru. Rób to na koniec dnia i po każdym większym kroku.

Podglądu nie budujesz u siebie. Buduje go serwer, bo tylko on ma treść sklepu przypisaną do zlecenia — build z Twojego komputera pokazałby pusty sklep.

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) i czytać całe strony zadań z .sc/docs/ (docs_search, docs_page — opis niżej, w „Dokumentacja silnika w klonie”),
• 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.