---
name: nextlevel
description: AI Biznes Lab - Next Level, Wspólny Mózg. Podłącza role i systemy firmy do wspólnej bazy, porządkuje odpowiedzialności, nadrabia kanon i przygotowuje dokumentację odtworzeniową. Use when user says "nextlevel", "podział ról", "nadrabiaj", "połącz systemy", "zabezpiecz system", "odtwórz system", "mój postęp next level", "wrzuć system", "wspólny mózg", or "/nextlevel".
argument-hint: [status/nadrabiaj/połącz]
metadata:
  author: AI Biznes Lab
  version: 0.8.0
---

# /nextlevel - AI Biznes Lab - Next Level, Wspólny Mózg

> **Wersja:** 0.8.0 | **Data:** 16.07.2026
> CO NOWEGO w 0.8.0: logowanie kontem AI Biznes Lab z rocznym kluczem odnawiania: aktywujesz raz kodem z maila i przez rok skill sam po cichu odnawia dostęp, bez ponownego logowania co 7 dni. Dotychczasowy kod logowania do portalu został jako ścieżka zapasowa.
> CO NOWEGO w 0.7.2: `połącz` przed każdą propozycją zmiany sprawdza spójność ownerów między Translation Ledger a istniejącymi kontraktami usera i pokazuje kolizję zamiast cichej zmiany odpowiedzialności; sprawdzenie aktualizacji nazywa przyczynę błędu (połączenie, autoryzacja, usługa) i zawsze kontynuuje na lokalnej wersji.
> CO NOWEGO w 0.7.1: materiały każdego systemu pobierane do pliku i rozpakowywane skryptem z weryfikacją kompletu, budowa zawsze pełnymi metapromptami z `zadania.md` oraz twardy zakaz budowania z pamięci, gdy pobranie jest niepełne. Poprawka po zgłoszeniu, że budowa szła bez pełnych zadań warsztatu.
> CO NOWEGO w 0.7.0: `/nextlevel nadrabiaj` wznawia przerwaną budowę od pierwszego brakującego rezultatu i po ukończeniu może, za zgodą użytkownika, odhaczyć system na istniejącej mapie postępu.
> WYWOŁANIE: Claude Code `/nextlevel`, OpenAI Codex `$nextlevel`. W tym pliku `/nextlevel` oznacza obie formy; używaj notacji narzędzia usera.
> `/nextlevel` pracuje obok ról usera. Porządkuje mapę, wiedzę i przekazanie pracy, ale nie przejmuje roadmapy `@autofirma`, decyzji produktowych `@venture` ani wykonania technicznego `@cto`. Kanonizuje wyłącznie właściciel programu.

## O CO CHODZI

Wspólny Mózg AI Biznes Lab - Next Level to jedna baza systemów autonomicznej firmy. Sześć rzeczy:
1. **Nadrabianie:** pobierasz zwalidowane systemy z warsztatów jako gotowe metaprompty i budujesz u siebie, zamiast oglądać wszystko po kolei.
2. **Postęp:** widzisz, gdzie jesteś na mapie systemów i co nadrobić przed najbliższą sesją.
3. **Kontrybucja:** wrzucasz własny system, który u Ciebie działa. Po walidacji właściciela wchodzi do kanonu z Twoim podpisem, a inni go rozwijają. Ulepszenia wracają do Ciebie.
4. **Łączenie:** skanujesz własny ekosystem, tłumaczysz nazwy i odpowiedzialności między systemami oraz dostajesz jedną mapę, z której korzysta także AI Marketing Lab.
5. **Odtwarzanie:** utrzymujesz używaną dokumentację systemu, z której można bezpiecznie odtworzyć jego kod, konfigurację, połączenia i kolejność uruchomienia.
6. **Podział pracy:** dostajesz krótki kontrakt ról i propozycje najmniejszych zmian w istniejących promptach, żeby zadania trafiały do właściwego ownera.

## KONTRAKT ODPOWIEDZIALNOŚCI

Nazwy ról mogą być inne w firmie usera. Mapuj odpowiedzialność po celu, wejściach, wyjściach i prawie do decyzji, nigdy tylko po nazwie pliku.

1. `/nextlevel` jest warstwą wspólnej wiedzy i mapowania. Pokazuje kanon, zależności, luki, kolizje ownerów i proponuje małe poprawki w promptach. Nie ustala priorytetów firmy, nie wybiera venture i nie wykonuje wdrożeń.
2. `@autofirma` jest Product Ownerem całego systemu firmy. Prowadzi roadmapę, ustala priorytety wspólnych organów, zamienia zgłoszone braki w pracę i przekazuje zatwierdzone wdrożenia do `@cto`.
3. `@cto` odpowiada za wykonanie techniczne. Projektuje architekturę, kod, integracje, bezpieczeństwo, koszty techniczne, testy i ścieżkę wdrożenia. Nie wybiera priorytetów produktu ani ekonomii venture.
4. `@venture` jest Product Ownerem portfela venture. Definiuje problem, klienta, hipotezę, ofertę, eksperyment, metryki, P&L oraz kryteria `KILL` i `SCALE`. Braki wspólnych systemów zgłasza do `@autofirma`, a wdrożeń nie przejmuje od `@cto`.
5. User albo wskazany owner zatwierdza decyzje biznesowe i każdą operację wymagającą zgody według instrukcji projektu.

Domyślny przepływ: `@venture` mówi co i po co jest potrzebne dla venture, `@autofirma` decyduje gdzie ta potrzeba żyje w systemie firmy i kiedy ma priorytet, `@cto` określa jak ją bezpiecznie zbudować i wdrożyć. `/nextlevel` utrzymuje widoczny podział, zależności i wspólną wiedzę, ale nie omija żadnego ownera.

## INSTALACJA

**Wykonaj TYLKO jeśli user prosi o instalację.** Jeśli user wpisał `/nextlevel` jako komendę, pomiń i przejdź do INSTRUKCJE DLA ASYSTENTA.

Skill instaluje się GLOBALNIE (katalog skilli narzędzia AI), klucz żyje w `~/.config/aibl/headers-nextlevel` (własny plik, NIE nadpisuje `headers` ani `headers-aiml` innych narzędzi AI Biznes Lab).

1. Standardowo, zapisz ten plik:
   - **Claude Code:** `mkdir -p ~/.claude/skills/nextlevel` i zapisz jako `~/.claude/skills/nextlevel/SKILL.md`
   - **OpenAI Codex CLI:** `mkdir -p ~/.agents/skills/nextlevel` i zapisz jako `~/.agents/skills/nextlevel/SKILL.md`
2. Wariant ręczny (gdy asystent nie może pisać poza projektem): podaj userowi jedną komendę do Terminala i powiedz wprost, że to przez zabezpieczenia projektu, nie błąd:
   - **Claude Code:** `mkdir -p ~/.claude/skills/nextlevel && curl -sf https://aibizneslab.pl/skill/nextlevel.md -o ~/.claude/skills/nextlevel/SKILL.md`
   - **OpenAI Codex CLI:** `mkdir -p ~/.agents/skills/nextlevel && curl -sf https://aibizneslab.pl/skill/nextlevel.md -o ~/.agents/skills/nextlevel/SKILL.md`
3. RESTART OBOWIĄZKOWY: narzędzie wczytuje skille przy starcie. Po instalacji powiedz: "Zainstalowałem skill. ZRESTARTUJ teraz [Claude Code / Codex], potem wpisz `/nextlevel` w projekcie swojej firmy."

## AUTO-UPDATE

Przed pierwszą akcją sprawdź wersję (jeden curl, nie blokuj przy braku internetu):
```
curl -sS -o "${TMPDIR:-/tmp}/nl_version.txt" -w "%{http_code}" https://aibizneslab.pl/skill/nextlevel.version.txt
```
Remote nowsza niż nagłówek metadata → pobierz `https://aibizneslab.pl/skill/nextlevel.md` i nadpisz lokalny skill TYLKO wtedy, gdy pobrany plik jest niepusty i zawiera nagłówek z numerem wersji; pokaż userowi "Co nowego", potem wykonaj akcję.

Gdy sprawdzenie się nie powiedzie, nazwij przyczynę po kodzie zamiast pisać ogólnie "chwilowo niedostępne":
1. Exit code curl bez kodu HTTP (np. 6, 7, 28) = brak połączenia albo DNS: napisz "Brak połączenia z aibizneslab.pl, pracuję na lokalnej wersji X.Y.Z" i kontynuuj bez aktualizacji.
2. HTTP 401 albo 403 = problem autoryzacji po stronie usługi: napisz to wprost i kontynuuj na lokalnej wersji.
3. HTTP 404 albo 5xx = problem samej usługi: napisz "Usługa aktualizacji zwróciła [kod], pracuję na lokalnej wersji X.Y.Z; spróbuj ponownie później" i kontynuuj.
Fallback jest zawsze ten sam: lokalna wersja działa w całości, aktualizacja nigdy nie blokuje komendy. Nie ponawiaj sprawdzenia w kółko w tej samej sesji.

## INSTRUKCJE DLA ASYSTENTA

Baza API: `https://qgbpl8g8s5.execute-api.eu-central-1.amazonaws.com/prod`

### AKTYWACJA (wymagana przed każdą komendą)

Klucz żyje w `~/.config/aibl/headers-nextlevel` (format: `Authorization: Bearer TOKEN`). Obok może istnieć `~/.config/aibl/nextlevel-account.refresh`: roczny klucz odnawiania konta AI Biznes Lab, dzięki któremu user nie loguje się ponownie przez rok.

1. Plik headers istnieje → zweryfikuj:
   `curl -sf -o /dev/null -w "%{http_code}" https://qgbpl8g8s5.execute-api.eu-central-1.amazonaws.com/prod/skill/status -H "$(cat ~/.config/aibl/headers-nextlevel)"`
   `200` = działaj. Błąd sieci = działaj lokalnie, nie kasuj klucza. `401` = spróbuj cichego odnowienia (punkt 1a), a dopiero gdy się nie uda, aktywuj (punkt 2).
1a. CICHE ODNOWIENIE (bez udziału usera): jeśli istnieje `~/.config/aibl/nextlevel-account.refresh`, odśwież klucz dostępu i ponów weryfikację:
   ```bash
   RA="${TMPDIR:-/tmp}/nl_refresh_auth.json"
   umask 077
   python3 -c 'import json,pathlib,sys; rt=pathlib.Path(pathlib.Path.home()/".config/aibl/nextlevel-account.refresh").read_text().strip(); pathlib.Path(sys.argv[1]).write_text(json.dumps({"AuthFlow":"REFRESH_TOKEN_AUTH","ClientId":"b135dlhqvdub040q39rqj2hnu","AuthParameters":{"REFRESH_TOKEN":rt}}), encoding="utf-8")' "$RA"
   curl -sS https://cognito-idp.eu-central-1.amazonaws.com/ -H 'Content-Type: application/x-amz-json-1.1' -H 'X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth' --data-binary @"$RA" \
     | python3 -c 'import json,pathlib,sys; tok=json.load(sys.stdin)["AuthenticationResult"]["AccessToken"]; p=pathlib.Path.home()/".config/aibl/headers-nextlevel"; p.write_text("Authorization: Bearer "+tok+"\n"); p.chmod(0o600)'
   rm -f "$RA"
   ```
   Sukces = wróć do punktu 1 i działaj. Błąd = usuń plik `.refresh` dopiero po nieudanej pełnej próbie i przejdź do aktywacji (punkt 2). Nie pokazuj kluczy w rozmowie.
2. Brak klucza albo wygasł bez możliwości odnowienia → aktywacja PRZEZ KONTO AI BIZNES LAB (domyślna, daje rok bez logowania):
   a. Zapytaj o email użyty przy zakupie AI Biznes Lab - Next Level. Wstaw dokładny adres w `EMAIL_USERA`, nie uruchamiaj bloku z placeholderem. Załóż albo potwierdź konto i wyślij kod jednorazowy:
      ```bash
      EMAIL_USERA='EMAIL_Z_ODPOWIEDZI_USERA'
      if ! python3 -c 'import re,sys; sys.exit(0 if re.fullmatch(r"[^@\s]+@[^@\s]+\.[^@\s]+", sys.argv[1]) else 2)' "$EMAIL_USERA"; then
        printf 'BŁĄD: wstaw poprawny adres email użytkownika.\n' >&2; exit 2
      fi
      AD="${TMPDIR:-/tmp}"; umask 077
      python3 -c 'import json,secrets,sys,pathlib; pathlib.Path(sys.argv[2]).write_text(json.dumps({"ClientId":"b135dlhqvdub040q39rqj2hnu","Username":sys.argv[1].lower(),"Password":"Aa1!"+secrets.token_urlsafe(24)}), encoding="utf-8")' "$EMAIL_USERA" "$AD/nl_signup.json"
      curl -sS -o "$AD/nl_signup_resp.json" https://cognito-idp.eu-central-1.amazonaws.com/ -H 'Content-Type: application/x-amz-json-1.1' -H 'X-Amz-Target: AWSCognitoIdentityProviderService.SignUp' --data-binary @"$AD/nl_signup.json"
      rm -f "$AD/nl_signup.json"
      python3 -c 'import json,sys; d=json.load(open(sys.argv[1], encoding="utf-8")); t=d.get("__type",""); sys.exit(0 if (not t or "UsernameExists" in t) else 3)' "$AD/nl_signup_resp.json" || { echo 'Konto niedostępne dla tego adresu, przechodzę na kod logowania do portalu (punkt 2f).'; }
      rm -f "$AD/nl_signup_resp.json"
      python3 -c 'import json,sys,pathlib; pathlib.Path(sys.argv[2]).write_text(json.dumps({"AuthFlow":"CUSTOM_AUTH","ClientId":"b135dlhqvdub040q39rqj2hnu","AuthParameters":{"USERNAME":sys.argv[1].lower()}}), encoding="utf-8")' "$EMAIL_USERA" "$AD/nl_initiate.json"
      curl -sS -o "$AD/nl_session.json" https://cognito-idp.eu-central-1.amazonaws.com/ -H 'Content-Type: application/x-amz-json-1.1' -H 'X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth' --data-binary @"$AD/nl_initiate.json"
      rm -f "$AD/nl_initiate.json"
      python3 -c 'import json,sys; d=json.load(open(sys.argv[1], encoding="utf-8")); sys.exit(0 if d.get("ChallengeName")=="CUSTOM_CHALLENGE" else 3)' "$AD/nl_session.json" && echo 'Kod wysłany na email.'
      ```
      Jeśli którykolwiek krok zgłosił błąd zamiast `Kod wysłany na email.`, przejdź do fallbacku (punkt 2f). Plik `nl_session.json` zostaw, zawiera sesję logowania dla kroku b.
   b. Poproś usera o kod z maila (nadawca konto AI Biznes Lab). Kod ma 3 próby. Wymień kod na klucze i zapisz je bez pokazywania w rozmowie:
      ```bash
      KOD_USERA='KOD_Z_ODPOWIEDZI_USERA'
      AD="${TMPDIR:-/tmp}"; umask 077
      python3 -c 'import json,sys,pathlib; s=json.load(open(sys.argv[3], encoding="utf-8"))["Session"]; pathlib.Path(sys.argv[4]).write_text(json.dumps({"ChallengeName":"CUSTOM_CHALLENGE","ClientId":"b135dlhqvdub040q39rqj2hnu","Session":s,"ChallengeResponses":{"USERNAME":sys.argv[1].lower(),"ANSWER":sys.argv[2]}}), encoding="utf-8")' "$EMAIL_USERA" "$KOD_USERA" "$AD/nl_session.json" "$AD/nl_challenge.json"
      curl -sS https://cognito-idp.eu-central-1.amazonaws.com/ -H 'Content-Type: application/x-amz-json-1.1' -H 'X-Amz-Target: AWSCognitoIdentityProviderService.RespondToAuthChallenge' --data-binary @"$AD/nl_challenge.json" \
        | python3 -c 'import json,pathlib,sys; d=json.load(sys.stdin); r=d.get("AuthenticationResult") or {}; assert r.get("AccessToken") and r.get("RefreshToken"), d.get("__type","brak kluczy"); cfg=pathlib.Path.home()/".config/aibl"; cfg.mkdir(parents=True, exist_ok=True); h=cfg/"headers-nextlevel"; h.write_text("Authorization: Bearer "+r["AccessToken"]+"\n"); h.chmod(0o600); f=cfg/"nextlevel-account.refresh"; f.write_text(r["RefreshToken"]+"\n"); f.chmod(0o600); print("Zalogowano na rok.")'
      rm -f "$AD/nl_challenge.json" "$AD/nl_session.json"
      ```
      Zła odpowiedź = Cognito odsyła kolejne wyzwanie (do 3 prób); po wyczerpaniu wróć do kroku a. Po `Zalogowano na rok.` zweryfikuj punktem 1 i przejdź do punktu e (zgoda na telemetrię, tylko przy pierwszej aktywacji).
   2f. FALLBACK, kod logowania do portalu (sesja 7 dni, dotychczasowa ścieżka), gdy konto AI Biznes Lab jest niedostępne:
   a. Zapytaj o email użyty przy zakupie AI Biznes Lab - Next Level. Wstaw dokładny adres z odpowiedzi w `EMAIL_USERA`. Nie uruchamiaj bloku z placeholderem. Wyślij kod i sprawdź wynik:
      ```bash
      EMAIL_USERA='EMAIL_Z_ODPOWIEDZI_USERA'
      if ! python3 -c 'import re,sys; sys.exit(0 if re.fullmatch(r"[^@\s]+@[^@\s]+\.[^@\s]+", sys.argv[1]) else 2)' "$EMAIL_USERA"; then
        printf 'BŁĄD: wstaw poprawny adres email użytkownika.\n' >&2
        exit 2
      fi
      AUTH_DIR="${TMPDIR:-/tmp}"
      AUTH_FILE="$AUTH_DIR/nl_auth.json"
      AUTH_RESPONSE="$AUTH_DIR/nl_auth_response.json"
      umask 077
      python3 -c 'import json,pathlib,sys; pathlib.Path(sys.argv[2]).write_text(json.dumps({"email":sys.argv[1]}), encoding="utf-8")' "$EMAIL_USERA" "$AUTH_FILE"
      HTTP_CODE=$(curl -sS -o "$AUTH_RESPONSE" -w "%{http_code}" -X POST https://qgbpl8g8s5.execute-api.eu-central-1.amazonaws.com/prod/auth/magic-link -H "Content-Type: application/json" --data-binary @"$AUTH_FILE")
      rm -f "$AUTH_FILE"
      if [ "$HTTP_CODE" != "200" ]; then
        python3 -c 'import json,sys; print(json.load(open(sys.argv[1], encoding="utf-8")).get("error", "Nie udało się wysłać kodu."))' "$AUTH_RESPONSE" 2>/dev/null || true
        rm -f "$AUTH_RESPONSE"
        exit 1
      fi
      rm -f "$AUTH_RESPONSE"
      ```
   b. Dopiero po HTTP 200 poproś usera o kod aktywacyjny z maila (mail „Twój link do logowania” pokazuje kod w szarym bloku; wklej go 1:1). KOD JEST JEDNORAZOWY. `/auth/verify` wolno wywołać DOKŁADNIE RAZ dla danego kodu. Nie uruchamiaj weryfikacji osobno w celu podejrzenia odpowiedzi, sprawdzenia nazw pól ani debugowania.

   c. W jednym wywołaniu wymień kod na token sesyjny i zapisz `session_token` bezpośrednio do `~/.config/aibl/headers-nextlevel`. Nie pokazuj odpowiedzi serwera, tokena ani zawartości pliku w rozmowie. Przykład bezpiecznego przepływu:
      ```bash
      mkdir -p ~/.config/aibl && umask 077
      curl -sf https://qgbpl8g8s5.execute-api.eu-central-1.amazonaws.com/prod/auth/verify \
        -H "Authorization: Bearer TOKEN_Z_MAILA" \
        | python3 -c 'import json,pathlib,sys; token=json.load(sys.stdin)["session_token"]; path=pathlib.Path.home()/".config/aibl/headers-nextlevel"; path.write_text("Authorization: Bearer "+token+"\n"); path.chmod(0o600)'
      ```
   d. Po wywołaniu sprawdź wyłącznie kod wyjścia procesu i istnienie niepustego pliku, nigdy jego treść. Jeżeli weryfikacja zużyła kod, ale zapis się nie udał, NIE powtarzaj `/auth/verify` z tym samym kodem. Poproś o nowy kod i powtórz cały pojedynczy przepływ.

   Token magic jest jednorazowy i ważny 15 minut, sesyjny 7 dni. Nigdy nie proś o hasło. Klucza nie pokazuj w odpowiedziach.
   e. Po pierwszej udanej aktywacji zapytaj RAZ: "Czy chcesz dzielić się statusem wdrożeń ze wspólnym mózgiem? Pomaga nam rozwijać kanon (tak/nie)". Wyślij decyzję:
      ```bash
      printf '{"consent":true}' > "$TMPDIR/nl_consent.json"
      curl -sf -X POST https://qgbpl8g8s5.execute-api.eu-central-1.amazonaws.com/prod/skill/consent -H "Content-Type: application/json" -H "$(cat ~/.config/aibl/headers-nextlevel)" -d @"$TMPDIR/nl_consent.json"
      ```
      (`false` gdy odmowa; decyzję można zmienić tą samą komendą w każdej chwili).
3. Brak dostępu (serwer nie wysyła maila) → wskaż `https://www.aibizneslab.pl/nxtlvl.html`, bez zgadywania czy email jest w bazie.

### ZASADY TWARDE

0. ZERO NADPISYWANIA, BUDOWA W STRUKTURZE USERA: user buduje autofirmę we własnej strukturze projektów (u większości członków folder w stylu `PROJEKTY/`, każdy system to osobny podfolder). Nowy system z kanonu = NOWY folder w tej strukturze, nazwany zgodnie z konwencją usera (np. `PROJEKTY/MAIL-OPS/`); pokaż propozycję lokalizacji i poczekaj na potwierdzenie. Pobrane materiały warsztatowe (zadania, prompty, notatki) zapisz w podfolderze `warsztat/` tego systemu. Domyślnie nie modyfikujesz istniejących plików usera (`ROLES/`, `CLAUDE.md`, `AGENTS.md`, inne projekty). Wyjątek: część `połącz` dotycząca ownerów może zaproponować małe dopiski do istniejących promptów ról i instrukcji projektu. Przed zapisem pokaż dokładny diff, zmieniaj wyłącznie zatwierdzone fragmenty i nigdy nie przepisuj całej roli. Jeśli user ma już podobny system (sprawdź nazwy ról i folderów), zapytaj: zbudować obok / zaadaptować jego wersję (pokaż różnice, zmiany tylko za zgodą) / tylko pokazać materiał.
1. Zero treści/danych klienta poza projekt. Wychodzi tylko: auto-update, świadomy `wrzuc`, `feedback`, opcjonalna telemetria (za zgodą) i pobranie kanonu.
2. Niczego nie kasujesz bez planu i zgody usera. Przed zmianą plików pokaż plan.
3. Polskie znaki diakrytyczne we wszystkich tekstach.
4. Język przedsiębiorcy, nie dewelopera (zero: endpoint, payload, GSI).
5. REGUŁA WYKLUCZEŃ przy `wrzuc`: nigdy nie wysyłasz w seedzie danych osobowych, kluczy API, haseł, tokenów, prywatnych ARN-ów ani cudzych przewag. Serwer też to blokuje, ale sprawdź PRZED wysłaniem.
6. SKAN EKOSYSTEMU JEST LOKALNY I READ ONLY: przy `połącz` czytasz tylko nazwy folderów, role, README, roadmapy, changelogi, dokumenty architektury i źródła prawdy. Pomijasz `.git`, `node_modules`, pliki binarne, sekrety, pliki `.env`, credentials, tokeny, dane klientów i treści outputów. Nic ze skanu nie wychodzi poza projekt.
7. LEDGER NIE ZMIENIA ARCHITEKTURY: najpierw pokazujesz diagnozę i propozycję mapowania. Pliki tworzysz albo aktualizujesz dopiero po zgodzie usera. Nie przenosisz systemów i nie podmieniasz ownerów automatycznie.
8. DOKUMENTACJA TO NIE BACKUP: Paszport Odtworzenia opisuje kod, konfigurację, połączenia i procedurę. Nie zastępuje kopii danych, repozytorium kodu ani magazynu sekretów. Wskazuje ich lokalizacje i stan, ale nie kopiuje zawartości.
9. ZERO SEKRETÓW W PASZPORCIE: zapisuj wyłącznie nazwy zmiennych, aliasy sekretów i ścieżki do kontrolowanego magazynu. Nigdy nie zapisuj wartości tokenów, haseł, kluczy, danych klientów ani prywatnych danych z produkcji.
10. `1:1` TYLKO PO DOWODZIE: wolno nazwać odtworzenie pełnym dopiero po zgodności kluczowych plików, konfiguracji, zależności, połączeń, backupów i testu końcowego. Brak któregokolwiek elementu oznacza `ODTWORZENIE CZĘŚCIOWE` z listą braków.
11. PODZIAŁ RÓL NIE ZMIENIA ORGANIZACJI: najpierw pokaż aktualny podział z dowodami, potem minimalne propozycje. Nie twórz brakującej roli, nie zmieniaj ownera i nie przenoś odpowiedzialności bez jawnej zgody usera.

### KOMENDA: /nextlevel (bez argumentu) albo status

```bash
curl -sf https://qgbpl8g8s5.execute-api.eu-central-1.amazonaws.com/prod/skill/status -H "$(cat ~/.config/aibl/headers-nextlevel)"
```
Pokaż po ludzku:
1. Ile systemów masz ukończonych z mapy (`stats.completed`/`stats.total`), rozbicie po organach.
2. Ścieżka nadrabiania (`catch_up`): systemy do nadrobienia w kolejności sesji. Jeśli lista pusta, pochwal: idziesz na bieżąco.
3. Lokalnie sprawdź, czy jest zainstalowany skill `marketinglab`, projekt zawiera rolę CMO albo instrukcje nie rozdzielają jasno odpowiedzialności wspólnego systemu firmy, technologii i venture.
4. Pokaż dokładnie jeden następny ruch. Jeśli wykryto którykolwiek sygnał z punktu 3, napisz: "🧬 Mogę połączyć role i systemy Twojej firmy bez dublowania odpowiedzialności. Wpisz `/nextlevel połącz`." W przeciwnym razie napisz: "Pobrać pierwszy system do nadrobienia? Wpisz `/nextlevel nadrabiaj`."

### KOMENDA: /nextlevel nadrabiaj (pull kanonu i budowa)

```bash
curl -sf https://qgbpl8g8s5.execute-api.eu-central-1.amazonaws.com/prod/skill/canon -H "$(cat ~/.config/aibl/headers-nextlevel)"
```
1. Pokaż listę systemów kanonu w kolejności (`kolejnosc`): nazwa + problem, który rozwiązują. Zestaw z `catch_up` ze statusu: który nadrobić najpierw.
2. Gdy user wybierze system, pobierz PEŁNE materiały DO PLIKU. Odpowiedź ma dziesiątki kilobajtów: wyświetlona w terminalu zostanie ucięta i stracisz część zadań, dlatego nigdy nie czytaj jej z ekranu.
   ```bash
   NL_SYS="${TMPDIR:-/tmp}/nl_system.json"
   curl -sf https://qgbpl8g8s5.execute-api.eu-central-1.amazonaws.com/prod/skill/system/ID_SYSTEMU -H "$(cat ~/.config/aibl/headers-nextlevel)" -o "$NL_SYS"
   ```
   Odpowiedź zawiera `files` (nazwa + pełna treść) oraz `portal_slug`, czyli identyfikator tego samego systemu na istniejącej mapie postępu. Po potwierdzeniu lokalizacji przez usera (ZASADA 0: lokalizacja za zgodą usera, zero nadpisywania, tryb adaptacji gdy podobny system istnieje) rozpakuj materiały do podfolderu `warsztat/` skryptem, nie ręcznie:
   ```bash
   python3 -c 'import json,pathlib,sys; data=json.load(open(sys.argv[1],encoding="utf-8")); out=pathlib.Path(sys.argv[2]); out.mkdir(parents=True,exist_ok=True); [print((out/f["name"]).write_text(f["tresc"],encoding="utf-8"), out/f["name"], sep=" znaków: ") for f in data["files"]]' "$NL_SYS" "SCIEZKA_DO_FOLDERU_SYSTEMU/warsztat"
   ```
   Zweryfikuj komplet: skrypt wypisał każdy plik z rozmiarem, na liście jest `zadania.md`, a rozmiar każdego zapisanego pliku zgadza się z wypisanym. Dopiero te zapisane pliki czytaj narzędziem do czytania plików.
2a. TWARDY ZAKAZ ZMYŚLANIA MATERIAŁÓW: budujesz wyłącznie z plików zapisanych w `warsztat/`. Jeśli pobranie się nie powiodło, plik wygląda na ucięty albo brakuje `zadania.md`, ZATRZYMAJ SIĘ i powtórz pobranie. Nigdy nie odtwarzaj treści zadań z pamięci, nie streszczaj ich w zastępstwie pełnej treści i nie wymyślaj własnych zadań, kroków ani promptów zamiast tych z `zadania.md`.
3. Zanim rozpoczniesz albo wznowisz budowę, sprawdź lokalnie wyłącznie folder wybranego systemu i materiały z `warsztat/`. Dla każdego zadania z `zadania.md` znajdź wymagany rezultat w środowisku usera. Pokaż krótką tabelę `ZROBIONE / CZĘŚCIOWE / DO ZROBIENIA`, zawsze z dowodem w postaci ścieżki albo wyniku testu. Sama obecność pliku bez wymaganego rezultatu nie oznacza `ZROBIONE`.
4. Jeśli istnieją dowody wcześniejszej pracy, nie zaczynaj od początku i nie odtwarzaj gotowych elementów. Wskaż pierwszy brakujący rezultat i zapytaj o zgodę na kontynuację od tego miejsca. Jeśli wszystko jest nowe, rozpocznij od pierwszego zadania. Następnie prowadź budowę wg `zadania.md` krok po kroku: każdy krok kończy się rezultatem w środowisku usera, a metaprompty z pozostałych plików podawaj we właściwych krokach.
4a. BUDOWA ZAWSZE PRZEZ METAPROMPTY, DLA KAŻDEGO SYSTEMU KANONU: każde zadanie wykonujesz PEŁNYM metapromptem z `zadania.md`, przeczytanym z zapisanego pliku, nie własnym streszczeniem ani interpretacją. Wolno dopasować metaprompt do realiów środowiska usera (nazwy folderów, istniejące systemy, braki oznaczone jako brak), ale nie wolno pomijać jego kroków, twardych zasad ani kryteriów rezultatu. Jeśli metaprompt nie pasuje do środowiska usera, powiedz to wprost i zapisz brak, zamiast wymyślać zadanie zastępcze.
5. Zero deployu i AWS write bez zgody usera. Człowiek ma ostatnie słowo.
6. Telemetria (tylko jeśli user wyraził zgodę przy aktywacji; brak zgody = pomiń w ciszy): po pobraniu wyślij `{"event":"pobral","system_id":"ID"}`, po ukończonej budowie `{"event":"zbudowal","system_id":"ID"}` na `POST /skill/telemetry` (JSON z pliku, nagłówek jak wyżej).
7. Po ukończeniu wszystkich wymaganych rezultatów i testów, jeśli odpowiedź systemu zawiera niepusty `portal_slug`, zapytaj dokładnie: `System działa. Oznaczyć go jako ukończony na mapie? (tak/nie)`. Brak odpowiedzi albo odmowa oznacza zero zapisu i tylko przypomnienie o portalu `aibizneslab.pl/lab`.
8. Wyłącznie po odpowiedzi `tak` zapisz postęp przez istniejącą usługę portalu. Nie dodawaj nowej komendy i nie zmieniaj portalu:
   ```bash
   PORTAL_SLUG='WARTOSC_PORTAL_SLUG_Z_ODPOWIEDZI_SYSTEMU'
   PROGRESS_FILE="${TMPDIR:-/tmp}/nl_progress.json"
   umask 077
   python3 -c 'import json,pathlib,sys; pathlib.Path(sys.argv[2]).write_text(json.dumps({"system_slug":sys.argv[1],"status":"completed"}), encoding="utf-8")' "$PORTAL_SLUG" "$PROGRESS_FILE"
   HTTP_CODE=$(curl -sS -o "${PROGRESS_FILE}.response" -w "%{http_code}" -X POST https://qgbpl8g8s5.execute-api.eu-central-1.amazonaws.com/prod/member/progress -H "Content-Type: application/json" -H "$(cat ~/.config/aibl/headers-nextlevel)" --data-binary @"$PROGRESS_FILE")
   rm -f "$PROGRESS_FILE" "${PROGRESS_FILE}.response"
   test "$HTTP_CODE" = "200"
   ```
   Sukces potwierdź jednym zdaniem. Przy błędzie nie powtarzaj zapisu automatycznie, tylko podaj link do portalu.

### KOMENDA: /nextlevel połącz (role, systemy i wspólny kontrakt)

Cel: pokazać userowi jedną mapę firmy, jasny podział odpowiedzialności i najmniejsze potrzebne połączenia między istniejącymi systemami. Nie budujesz trzeciego skilla ani nowej warstwy dokumentacji.

#### Krok 1, lokalny skan read only

1. Ustal root firmy. Preferuj katalog zawierający `CLAUDE.md`, `AGENTS.md` albo `.git`. Nie zakładaj nazw `PROJEKTY`, `projects` ani `projekty`.
2. Przeczytaj wyłącznie pliki orientacyjne: główne instrukcje projektu, listę i prompty ról, README, roadmapy, changelogi, dokumenty architektury, mapy systemów i lokalne manifesty skilli. Nie czytaj sekretów ani treści klientów.
3. Rozpoznaj lokalne odpowiedniki `/nextlevel`, `@autofirma`, `@cto` i `@venture` po odpowiedzialności. Inna nazwa jest poprawna, jeśli zgadzają się cel, wejścia, wyjścia i prawo do decyzji.
4. Dla każdej odpowiedzialności podaj dowód jako ścieżkę i nazwę sekcji. Brak dowodu oznacz `NIE ZNALEZIONO`.
5. Sprawdź, czy instrukcje mają jedno źródło prawdy i czy któryś plik jest lustrem innego. Nie proponuj niezależnej edycji lustra wbrew lokalnej procedurze synchronizacji.
6. Rozpoznaj też strategię i ownera firmy, ofertę i produkty, CMO i marketing, treści, social media, reklamy, mail, sygnały zakupowe, CRM i sprzedaż, delivery i support, finanse, monitoring oraz zatwierdzenia człowieka.

#### Krok 2, diagnoza odpowiedzialności

Pokaż przed propozycją zmian:

```text
🧭 PODZIAŁ PRACY W TWOJEJ FIRMIE

/nextlevel lub odpowiednik wiedzy: [co robi] | [dowód]
@autofirma lub odpowiednik PO firmy: [co robi] | [dowód]
Rola `@cto` lub odpowiednik technologii: [co robi] | [dowód]
@venture lub odpowiednik venture: [co robi] | [dowód]

PRZEKAZANIE PRACY
@venture → @autofirma → @cto
/nextlevel → mapa, wiedza, zależności i kontrola spójności dla wszystkich trzech ról

KOLIZJE
[obszar przejęty przez dwie role albo brak ownera]
```

Kolizją jest szczególnie sytuacja, w której:

1. `/nextlevel` albo `@cto` wybiera priorytety całej firmy.
2. `@autofirma` wybiera hipotezę, ofertę albo kryteria ekonomiczne venture zamiast `@venture`.
3. `@venture` projektuje lub wdraża infrastrukturę zamiast opisać potrzebę i kryterium biznesowe.
4. `@cto` sam decyduje, który produkt albo venture ma powstać.
5. Nie ma jawnego przekazania braku wspólnego systemu od `@venture` do `@autofirma` i zatwierdzonego zlecenia technicznego od `@autofirma` do `@cto`.

#### Krok 3, pakiet lekkich zmian

Pokaż dokładne propozycje bez zapisu:

```text
✍️ PAKIET LEKKICH ZMIAN DO PROMPTÓW

PLIK: [istniejąca ścieżka]
MIEJSCE: [istniejąca sekcja albo miejsce po konkretnej sekcji]
POWÓD: [jedna wykryta luka lub kolizja]
DOPISEK: [krótki tekst gotowy do wstawienia]
CZEGO NIE RUSZAM: [reszta roli albo instrukcji]
```

Zasady pakietu:

1. Najpierw wykorzystaj istniejącą sekcję współpracy, granic albo odpowiedzialności. Nie twórz nowego pliku.
2. W głównej instrukcji proponuj jeden krótki kontrakt przepływu tylko wtedy, gdy nie ma go już w żadnym źródle prawdy.
3. W promptach ról proponuj wyłącznie brakującą granicę i przekazanie pracy. Nie powtarzaj pełnego kontraktu w każdym pliku.
4. Nie proponuj zmiany roli, która już ma jasny podział. Oznacz ją `BEZ ZMIAN`.
5. Nie twórz brakującej roli automatycznie. Jeśli odpowiedzialność nie istnieje, pokaż lukę i zapytaj, czy user chce rozszerzyć najbliższą istniejącą rolę albo osobno zaprojektować nową.
6. Każdy dopisek ma używać nazw i ścieżek z projektu usera, nie naszych nazw na siłę.

Wzorzec centralnego kontraktu, adaptowany do lokalnych nazw:

```text
PODZIAŁ ODPOWIEDZIALNOŚCI
/nextlevel utrzymuje wspólną wiedzę, mapę systemów i zależności, ale nie przejmuje decyzji ownerów.
@venture definiuje co i po co budujemy dla konkretnego venture oraz pilnuje wyniku ekonomicznego.
@autofirma decyduje gdzie potrzeba żyje w systemie firmy, ustala priorytet i przygotowuje zlecenie techniczne.
Rola `@cto` projektuje i wykonuje rozwiązanie techniczne oraz jego bezpieczne wdrożenie po wymaganej zgodzie.
Przepływ: @venture → @autofirma → @cto. /nextlevel utrzymuje spójność wiedzy na każdym etapie.
```

Wzorce małych dopisków do ról, używane tylko wtedy, gdy danej granicy brakuje:

```text
@autofirma: Przyjmuję od @venture opis potrzeby i kryterium biznesowe, umieszczam potrzebę w roadmapie wspólnych systemów i po ustaleniu priorytetu przekazuję @cto zlecenie techniczne. Nie przejmuję ekonomii venture ani wykonania produkcyjnego.

@cto: Przyjmuję zatwierdzone zlecenie techniczne od @autofirma. Odpowiadam za architekturę, wykonanie, testy i bezpieczną ścieżkę wdrożenia, ale nie wybieram priorytetu firmy ani hipotezy venture.

@venture: Definiuję problem, klienta, ofertę, eksperyment, metryki i wynik ekonomiczny venture. Braki wspólnych systemów zgłaszam do @autofirma, a wykonanie techniczne pozostawiam @cto.
```

#### Zasady zmian w promptach

1. Dołącz pakiet dopisków do pełnego podglądu komendy `połącz` przed jakimkolwiek zapisem.
2. Nie zmieniaj promptów przed zgodą usera na dokładne pliki i dopiski.
3. Jeśli projekt wskazuje plik źródłowy i lustro, edytuj źródło oraz wykonaj jego lokalną procedurę synchronizacji. Nie rozstrzygaj sam, który plik wygrywa.
4. Po zatwierdzonej zmianie pokaż diff i sprawdź, czy każda rola ma jednego ownera, granicę oraz jawne przekazanie pracy.
5. Ocenę podziału pokaż jako `PODZIAŁ JASNY` albo `WYMAGA DECYZJI USERA`, z listą nierozstrzygniętych kolizji.
6. Nie wykonuj deployu, publikacji, instalacji skilla ani operacji zewnętrznej w ramach tej komendy.

#### Krok 4, inteligentne tłumaczenie systemów

Dla każdego wykrytego elementu ustal:

1. Obszar i nazwę kanoniczną zdolności.
2. Nazwę używaną przez system dawcy, na przykład AI Marketing Lab, oraz nazwę lokalną.
3. Formę w lokalnej architekturze: osobny system, moduł, proces wykonawczy, wynik pracy albo bramka decyzji.
4. Lokalizację, źródło prawdy, ownera i dowód działania.
5. Status mapowania: `EXACT` gdy cel, wejścia, wyjścia i owner są zgodne; `MERGED` gdy zdolność jest częścią większego systemu; `PARTIAL` gdy pokrywa tylko część; `MISSING` gdy nie ma dowodu; `LOCAL-EXTRA` gdy firma ma zdolność spoza mapy dawcy.
6. Co dokładnie wnosi proponowana aktualizacja: nową zdolność, uzupełnienie, wariant wykonania albo tylko inną nazwę.
7. Decyzję: `KEEP`, `ADAPT`, `PATCH`, `PARK` albo `NEW`.
8. Miejsce zastosowania, najmniejszą potrzebną zmianę oraz test wejście, proces, wynik.
9. Stan dokumentacji odtworzeniowej: `GOTOWA`, `CZĘŚCIOWA` albo `BRAK`, z dokładną ścieżką używanego README, dokumentu architektury, runbooka albo Paszportu.

Nie utożsamiaj systemów tylko dlatego, że mają podobną nazwę. `Reklamy` mogą być wykonaniem kampanii, biblioteką kreacji albo systemem pomiarowym. Odpowiednik wymaga zgodności celu, wejść, wyjść i ownera.

#### Krok 5, ekran efektu wow

Pokaż wynik przed jakimkolwiek zapisem w tym formacie:

```text
🧠 TWOJA AUTOFIRMA, MAPA POŁĄCZEŃ

✅ POŁĄCZONE
[obszar] → [istniejący system] → [gdzie leży]

🧭 PODZIAŁ PRACY
[/nextlevel, @autofirma, @cto, @venture albo lokalne odpowiedniki] → [owner i przekazanie pracy]

🔁 DO SPIĘCIA
[system dawcy] → [odpowiednik usera] → [konkretne połączenie]

⚠️ KOLIZJE
[dwa źródła prawdy albo ownerzy] → [co trzeba rozstrzygnąć]

🕳️ LUKI
[brakująca zdolność] → [dlaczego blokuje przepływ]

🛟 ODTWARZANIE
[system] → [GOTOWA / CZĘŚCIOWA / BRAK] → [ścieżka albo najważniejszy brak]

🚀 NAJWIĘKSZA DŹWIGNIA
[jeden ruch, który połączy najwięcej elementów]
```

Na końcu pokaż liczby wynikające wyłącznie ze skanu: ile obszarów jest połączonych, ile wymaga spięcia, ile ma kolizję i ile jest luk. Potem pokaż maksymalnie trzy rekomendacje, uporządkowane według wpływu i najmniejszego kosztu zmiany. Jeśli podział odpowiedzialności jest niejasny, dołącz opisany wyżej pakiet lekkich zmian, nadal bez zapisu. Następnie pokaż dokładne ścieżki proponowanych zmian i poproś o zgodę.

KONTROLA SPÓJNOŚCI OWNERÓW (obowiązkowa przed każdą propozycją zmiany): jeśli w root firmy istnieje `SYSTEM_TRANSLATION_LEDGER.md`, zanim zaproponujesz zmianę kontraktu, dopisek do roli albo nowe mapowanie, porównaj ownera każdego dotkniętego obszaru w Ledgerze z ownerem w istniejących kontraktach operacyjnych usera (prompty ról, kontrakty delivery i supportu, instrukcje projektu). Ten sam etap z dwoma różnymi ownerami to KOLIZJA: pokaż ją w sekcji `⚠️ KOLIZJE` z oboma źródłami i ścieżkami oraz poproś ownera firmy o rozstrzygnięcie. Nie proponuj zmiany, która po cichu przenosi odpowiedzialność między ownerami, i nie traktuj Ledgera ani kontraktu jako automatycznie ważniejszego. Rozstrzygnięcie zapisz w Ledgerze w `Kolizje do rozstrzygnięcia` i `Historia tłumaczeń`.

#### Krok 6, trwała pamięć po zgodzie

Po zgodzie wykonaj wyłącznie zatwierdzone dopiski do promptów oraz utwórz albo rozszerz, bez kasowania istniejących wpisów:

1. `SYSTEM_TRANSLATION_LEDGER.md` w root firmy. To wspólny kontrakt dla `@autofirma`, `@cto`, `@venture`, `@cmo`, `/nextlevel` i `/marketinglab`.
2. `CMO_ADAPTER_BRIEF.md` obok Ledgera, tylko gdy wykryto AI Marketing Lab albo rolę CMO.

Ledger ma zawierać:

```markdown
# System Translation Ledger

## Zasada
Najpierw użyj istniejącego systemu. Potem połącz. Buduj nowy tylko wtedy, gdy nie ma odpowiednika.

## Kontrakt odpowiedzialności
| Warstwa | Lokalny owner | Co robi | Czego nie przejmuje | Przekazuje do | Dowód |

## Mapa odpowiedników
| Obszar | Nazwa dawcy | Nazwa lokalna | Forma lokalna | Źródło prawdy | Owner | Dowód | Status | Decyzja | Miejsce zmiany | Test | Dokumentacja odtworzeniowa | Sprawdzono |

## Kolizje do rozstrzygnięcia
| Temat | Źródło A | Źródło B | Ryzyko | Decyzja ownera |

## Historia tłumaczeń
| Data | Zmiana | Powód | Zatwierdził |
```

Brief CMO ma zawierać:

1. Ścieżkę do Ledgera.
2. Istniejące systemy marketingowe, które CMO ma wykorzystać zamiast odtwarzać.
3. Mapowanie nazw AI Marketing Lab na nazwy usera.
4. Źródła prawdy, których nie wolno dublować.
5. Tłumaczenie statusów lokalnych, na przykład `LIVE`, `PILOT`, `BRIDGE`, `PARK`, `UNMAPPED`, na statusy wspólnego kontraktu.
6. Dla aktualizacji CMO decyzję `KEEP`, `ADAPT`, `PATCH`, `PARK` albo `NEW`, najmniejszą zmianę i test efektu.
7. Maksymalnie trzy najważniejsze połączenia do wykonania.
8. Granice write, publikacji, wysyłek, reklam i budżetu.

#### Krok 7, współpraca z /marketinglab

1. Jeśli skill `marketinglab` jest dostępny, powiedz: "Most gotowy. AI Marketing Lab wykryje Ledger przy aktualizacji i użyje go tylko do adaptacji CMO."
2. Przy każdym kolejnym `połącz` porównaj skan z Ledgerem i pokaż tylko deltę: nowe systemy, ownerzy, nieaktualne mapowania, kolizje i luki. Brak zmiany też nazwij wprost.
3. Nigdy nie modyfikuj plików CMO ani nie instaluj aktualizacji AI Marketing Lab w ramach tej komendy. To osobna akcja wykonywana przez `/marketinglab` po planie i zgodzie usera.

### KOMENDA: /nextlevel zabezpiecz [system]

Cel: przygotować dokumentację, którą `@cto`, `@autofirma` albo `/nextlevel odtwórz` rzeczywiście wykorzysta przy duplikacji, przenosinach, awarii albo zmianie środowiska.

#### Krok 1, wybór używanego miejsca

1. Rozpoznaj system po nazwie, Ledgerze albo lokalnej mapie projektów. Brak jednoznacznego systemu oznacza pytanie o wybór, nie zgadywanie.
2. Poszukaj w katalogu systemu istniejącego dokumentu używanego przez runtime: `README.md`, dokumentu architektury, runbooka operacyjnego albo dokumentu wdrożenia.
3. Istnieje właściwy dokument → zaproponuj dodanie albo aktualizację sekcji `Paszport Odtworzenia` właśnie tam.
4. Nie ma właściwego dokumentu → zaproponuj dokładnie jeden plik `SYSTEM_RECOVERY.md` w root systemu. Pokaż ścieżkę i wyjaśnij, że czyta go komenda `odtwórz`. Nie twórz obok checklisty, manifestu ani drugiego opisu.
5. Przed zapisem pokaż: dokument docelowy, sekcje, które zmienisz, oraz czego nie ruszysz. Czekaj na zgodę.

#### Krok 2, lokalny audyt read only

Czytaj kod, konfigurację bez wartości sekretów, pliki infrastruktury, dokumentację i stan repozytorium wyłącznie w obrębie wybranego systemu oraz jego jawnie wskazanych zależności. Pomijaj `.env`, credentials, tokeny, dane klientów, eksporty produkcyjne i pliki binarne.

Zbierz:

1. Tożsamość: nazwa, cel biznesowy, owner, źródło prawdy, stan oraz wersja albo commit.
2. Zakres: katalogi i kluczowe pliki, entrypointy, role, procesy oraz wyniki systemu.
3. Zależności: inne systemy, biblioteki, usługi zewnętrzne, runtime i wymagane wersje.
4. Konfigurację: nazwy zmiennych, aliasy sekretów, regiony, domeny i środowiska. Zero wartości sekretów.
5. Zasoby: bazy, kolejki, buckety, funkcje, harmonogramy, webhooki, integracje i uprawnienia, wyłącznie nazwami potrzebnymi do identyfikacji.
6. Dane i ciągłość: gdzie jest backup albo eksport, kiedy był sprawdzony, retencja i czego backup nie obejmuje.
7. Uruchomienie: prawdziwa ścieżka build, deploy albo publikacji, kolejność kroków i wymagane zgody.
8. Odtwarzanie: kolejność `KOD → KONFIGURACJA → ZASOBY → POŁĄCZENIA → DANE → TEST`.
9. Weryfikację: test wejście, proces, wynik, smoke test i warunki uznania odtworzenia za pełne.
10. Rollback: jak wrócić do źródła, poprzedniej wersji albo starego środowiska bez kasowania danych.

#### Krok 3, format Paszportu

Dodaj albo zaktualizuj jedną sekcję:

```markdown
## Paszport Odtworzenia

Stan: GOTOWY | CZĘŚCIOWY
Ostatnia weryfikacja: RRRR-MM-DD
Owner: ...
Źródło prawdy: ...
Wersja lub commit: ...

### Zakres i kluczowe pliki
| Element | Lokalizacja | Przenośny 1:1 | Odcisk lub wersja |

### Zależności i połączenia
| Element | Rola | Źródło konfiguracji | Wymaganie w celu |

### Konfiguracja bez sekretów
| Nazwa | Środowisko | Referencja sekretu | Wymagana |

### Dane i backupy
| Zasób | Backup lub eksport | Ostatni test | Retencja | Brakujące pokrycie |

### Kolejność odtworzenia
1. KOD
2. KONFIGURACJA
3. ZASOBY
4. POŁĄCZENIA
5. DANE
6. TEST

### Test końcowy
[wejście → proces → wynik]

### Rollback
[jak wrócić bez utraty danych]

### Znane braki
[co blokuje pełne odtworzenie 1:1]
```

Odciski licz tylko dla kluczowych, przenośnych plików. Nie zapisuj setek hashy ani plików generowanych. `GOTOWY` wymaga pokrycia kodu, konfiguracji, zależności, danych albo jawnego braku danych, kolejności, testu i rollbacku. W przeciwnym razie ustaw `CZĘŚCIOWY`.

#### Krok 4, aktualizacja bez chaosu

1. Jeśli Paszport już istnieje, pokaż wyłącznie deltę: nowe zależności, zmienione pliki, konfigurację, zasoby, backupy i testy.
2. Nie nadpisuj ręcznych decyzji ownera. Konflikt pokaż i poproś o rozstrzygnięcie.
3. Po zgodzie zapisz zmianę w jednym dokumencie i sprawdź ponownie wszystkie wskazane ścieżki.
4. Zakończ oceną `GOTOWY` albo `CZĘŚCIOWY` oraz maksymalnie trzema brakami o największym wpływie.

### KOMENDA: /nextlevel odtwórz [system]

Cel: odtworzyć albo przenieść system na podstawie Paszportu, bez zgadywania i bez niszczenia źródła.

1. Znajdź sekcję `Paszport Odtworzenia` w używanym dokumencie systemu albo `SYSTEM_RECOVERY.md`. Brak Paszportu oznacza: zatrzymaj odtwarzanie i zaproponuj `/nextlevel zabezpiecz [system]`.
2. Sprawdź aktualność wszystkich ścieżek, zależności, referencji sekretów, backupów i testów. Rozjazd pokazuj jako delta. Nie poprawiaj dokumentacji ani systemu bez zgody.
3. Ustal cel: duplikacja, przenosiny, nowe środowisko albo odbudowa po awarii. Pokaż dokładną lokalizację docelową i potwierdź, że źródło pozostaje nietknięte.
4. Zbuduj dry run w tabeli:

```text
Element | Akcja: COPY / RECREATE / RECONNECT / RESTORE / SKIP / BLOCKED | Źródło | Cel | Dowód | Wymagana zgoda
```

5. Element bez backupu, referencji sekretu, zależności albo testu oznacz `BLOCKED`. Nie uzupełniaj z pamięci.
6. Przed lokalnymi zapisami pokaż pełny plan plików i czekaj na zgodę. Deploy, publikacja, operacja chmurowa, przywrócenie danych i zmiana zewnętrznej konfiguracji wymagają osobnej, jawnej zgody zgodnie z instrukcjami projektu.
7. Wykonuj kolejno: kod, konfiguracja bez sekretów, zasoby, połączenia, dane, test. Po każdym etapie checkpoint i możliwość zatrzymania.
8. Nie kasuj ani nie wyłączaj źródła. Przełączenie ruchu i usunięcie starego środowiska to osobne decyzje po pełnej weryfikacji.
9. Na końcu porównaj odciski kluczowych plików, wersje zależności, obecność konfiguracji, stan połączeń oraz test wejście, proces, wynik.
10. Raport końcowy ma status `ODTWORZONE 1:1`, `ODTWORZONE CZĘŚCIOWO` albo `NIE ODTWORZONO`. `1:1` wolno użyć tylko przy pełnym dowodzie. Po sukcesie zaproponuj aktualizację Paszportu o nowe środowisko, nadal po zgodzie.

### KOMENDA: /nextlevel wrzuc (kontrybucja seeda)

1. Zbierz strukturę (bez struktury nie wysyłasz):
   - `system`: nazwa systemu/opcji
   - `problem`: co rozwiązuje (1-2 zdania)
   - `metaprompt`: metaprompt do odtworzenia u kogoś innego
   - `proof`: dowód, że działa u Ciebie (krótki opis efektu, bez danych klienta i sekretów)
2. SPRAWDŹ regułę wykluczeń: żadnych danych osobowych, kluczy, haseł, tokenów, prywatnych ARN-ów. Pokaż userowi dokładnie, co wyślesz, i poproś o potwierdzenie.
3. Wyślij (JSON z pliku):
   ```bash
   # zapisz do $TMPDIR/nl_seed.json: {"system":"...","problem":"...","metaprompt":"...","proof":"..."}
   curl -sf -X POST https://qgbpl8g8s5.execute-api.eu-central-1.amazonaws.com/prod/skill/submit -H "Content-Type: application/json" -H "$(cat ~/.config/aibl/headers-nextlevel)" -d @"$TMPDIR/nl_seed.json"
   ```
4. Odpowiedź serwera:
   - `ok=true` + `id` → powiedz: seed trafił do kolejki, po walidacji właściciela może wejść do kanonu z Twoim podpisem.
   - `error` z listą (klucz/email/ARN) → seed zawiera coś z reguły wykluczeń. Pokaż userowi co usunąć i wyślij ponownie po poprawie.
5. Po wysłaniu usuń plik tymczasowy.

### KOMENDA: /nextlevel feedback

1. Zapytaj usera, czego dotyczy feedback (konkretny system z kanonu czy program ogólnie) i zbierz treść (10-4000 znaków). Bez danych osobowych, kluczy i sekretów.
2. Pokaż userowi dokładnie, co wyślesz, i poproś o potwierdzenie.
3. Wyślij:
   ```bash
   # zapisz do $TMPDIR/nl_feedback.json: {"tresc":"...","system_id":"opcjonalnie-id"}
   curl -sf -X POST https://qgbpl8g8s5.execute-api.eu-central-1.amazonaws.com/prod/skill/feedback -H "Content-Type: application/json" -H "$(cat ~/.config/aibl/headers-nextlevel)" -d @"$TMPDIR/nl_feedback.json"
   ```
4. `ok` → powiedz: feedback trafił prosto do zespołu programu (Notification Hub @next). Usuń plik tymczasowy.

### WSPARCIE

Pytania: społeczność Next Level na Skool albo kontakt@aibizneslab.pl.